Subject: Re: Comments on draft-briscoe-tsvwg-ecn-encap-guidelines-00

From: Bob Briscoe <[email-masked]>
Date: Mon, 28 Mar 2011 09:31:26 +0100

Gorry,

Yes, we're either agreeing, or deferring to later for details.

Thanks again.

cc'd to list as agreed.

Bob

At 08:40 28/03/2011, Gorry Fairhurst wrote:
>We seem to agree mostly. See brief notes below:
>
>On 28/03/2011 03:01, Bob Briscoe wrote:
>>Gorry,
>>
>>Thank you for your v useful (as always) and comprehensive (as always)
>>review and chair comments.
>>
>>Inline responses...
>>
>>
>>At 18:55 27/03/2011, Gorry Fairhurst wrote:
>>
>>>draft-briscoe-tsvwg-ecn-encap-guidelines-00
>>>
>>>Thanks for uploading the draft on Congestion Notification for link
>>>layers. I have some comments and suggestions below.
>>>
>>>Best wishes,
>>>
>>>Gorry
>>>
>>>I have reviewed the above draft as a member of TSVWG (Chair hat
>>>comments at the end).
>>>
>>>- I'm interested in this topic and would be happy to read and
>>>contribute to the evolution of this draft.
>>>
>>>" Even a whole
>>>meshed subnetwork can be made immune to interior congestion by
>>>careful network design; interior links can be sufficiently
>>>provisioned relative to the edge capacities to absorb even worst-case
>>>patterns of load."
>>>- This seems to imply internal congestion can always be avoided. Is
>>>this always the case? I'm not sure I believe this. In contrast, I'd
>>>suggest the "worst-case" is that the interface/subnetwork drops
>>>packets under load.
>>
>>I only said 'a network can be'. I was thinking of a 3-stage clos network
>>as discussed in S.8 of the (long but highly interesting) paper below
>>[Reid05]. It becomes prohibitive to scale this to keep it guaranteed
>>non-blocking, but such a multipath topology does strongly reduce the
>>chances of congestion on interior links.
>>
>>Reid, A., "Economics and Scalability of QoS Solutions," BT Technology
>>Journal 23(2):97--117 (April 2005) ((access requires registration but no
>>fee)) Abstract URL:
>>http://www.btplc.com/Innovation/Journal/BTTJ/archive/Abstract.aspx?JType=BTTJ&IDVol=23&IDArt=2&IDAbs=19
>I just didn't want to give the impression that 
>L2 offered a generic solution in all cases.
>
>>
>>>- RFC3819 S 13 says something about L2 buffers and congestion, and may
>>>also be useful reference point on some terminology.
>>
>>Thank you - I had completely forgotten about that.
>>
>>
>>>"Also it might be costly to find an IP
>>>header (v4 or v6) when it may be encapsulated by more than one
>>>Ethernet header (e.g. when using multiple encapsulations of MAC in
>>>MAC [IEEE802.1Qah])."
>>>- IP encapsulation in its various forms also makes this deep pack
>>>inspection more complex. The IP router at the L2 edge of subnet needs
>>>to do this anyway?
>>
>>Well no, the whole point is that if the marking is being done in a L3
>>queue, the IP header is the one being acted on - it's already been
>>decapsulated and doesn't have to be looked for - it *is* the outer. But
>>if marking is being done by a switch that is acting on a L2 header,
>>there's no saying how deep it will have to bury to find the first IP
>>header to mark.
>This was probably just language clarity - we agree.
>
>>>"the end-station"
>>>- I wonder if we can find a better term? Can you describe this as the
>>>L2 destination, link egress or the L2 network edge or something like
>>>this? Later sections speak of "subnets" - how does this relate to
>>>these terms?
>>
>>OK. I mentioned all this, when I defined the terms encapsulator &
>>decapsulator, but then I've been inconsistent in the text itself. Thanks.
>>
>>>"reaches the destination transport"
>>>- I think this would be a good place to mention "endpoint" or "host"
>>>or something.
>>>
>>>"the source transport"
>>>- Would transport layer at the sending endpoint be better, since
>>>destination transport is a term that can have multiple meanings to L2
>>>people.
>>
>>Good point. I'll work on these.
>>
>>
>>>Page 4:
>>>
>>>- I think the word "transport" would benefit from being very clearly
>>>explained including a diagram to show what the IETF means by
>>>transport. I suspect many in the intended group of "users" for the
>>>document will think of transport as being below IP, in contrast to
>>>where the IETF places this term.
>>
>>Yes - I argue with them that they should disambiguate, so I should.
>>
>>[However, I must add that when I challenge them to refer to any document
>>at all for a definition for their use of the word transport, they have
>>absolutely nothing formal to cite. It's just a general word for stuff
>>that carries things, much like we talk of cars and buses as transport.
> >
>Agree.
>>
>>>- Inner header and outer header are also terms that may benefit from a
>>>little more detail for a layer 2 audience?
>>
>>I assume you are saying the terminology section entries are not even
>>enough.
>>
>>
>>>- Congestion baseline: I didn't understand this definition, and
>>>suspect this is important, can you explain?
>>
>>OK, yes, the definition is unclear. "Congestion notification baseline"
>>would be a more intuitive but longer phrase. The place where congestion
>>notification was last zeroed (typically at the ultimate source endpoint).
>The shorter form seems OK, but more info, e.g. a picture may help.
>
>>
>>>Page 5:
>>>"If the lower layer has its own
>>>feedback and load regulation, there is no need to propagate
>>>congestion signalling up the layers. "
>>>- Is this *always* true?
>>
>>There is no need to have a *deliberate* mechanism to propagate
>>signalling up the layers. But that doesn't mean it won't happen
>>naturally - when the lower layer cannot clear the load, the higher layer
>>queue at the subnet ingress will back-up and *it* might then signal
>>congestion (without any direct link to the lower layer congestion
>>notification signalling).
>>
>>I've seen this approach described in a patent filed by someone working
>>on QCN (IEEE 802.1Qau).
>>
>>
>>>S 3.1
>>>
>>>- The statement that lower layer protocols need to distinguish ECN
>>>support by PDU seems harsh? I'd have thought that many do not not, and
>>>the implication is that the egress of the L2 network then needs to
>>>take appropriate action.
>>
>>You're right - I had evolved my thinking since writing that, but
>>overlooked changing it. Will do next rev.
>>
>>
>>>- Is the sentence below correct?
>>>"For instance, ECN-
>>>capable transports might only be allowed to use PDUs identified by a
>>>particular set of labels or tags."
>>>- Or is it "For instance, Only ECN-capable transports may be allowed…"
>>
>>you're right
>>
>>
>>>"This strategy might not be appropriate for
>>>other link technologies targeted at zero-configuration deployment by
>>>the general public (e.g. "
>>>- I wonder if the issue here is more about "zero-configuration
>>>deployment" and the "general public" is an example of typical usage,
>>>i.e. I'd have expected any zero-conf approach to have these properties.
>>
>>yes. The general public ought to be an example of users of zero-conf.
>>
>>
>>>S 3.2 bullet 1.
>>>
>>>- I think my comment may resemble ones for other sections, but I'd
>>>like to understand: This talks about copying ECN markings, but is it
>>>acceptable also to discard packets that are marked at this point?
>>
>>Ooh no. At ingress, an arriving marking will arrive in the IP header, so
>>one has to assume it was put there after safely checking the IP header
>>said the transport was ECN aware.
>>
>>At the ingress, the issue is about checking whether the ECN capability
>>of the lower layer (the one about to encapsulate) would be appropriately
>>handled when it is decapsulated. There's no need to resort to drop for
>>that - just turn off ECN capability in the outer.
>I see. We can thrash-out the guidance detail later.
>
>>
>>>S 3.2 bullet 2.
>>>- Is the assumption that the outer header does carry an ECN marking?
>>>Is it possible that the ECN properties of a flow could be in the
>>>control plane and therefore not part of the PDU, but would be visible
>>>at the egress. How would this best be handled?
>>
>>Yes, I need to treat in- and out-of-band congestion signalling as two
>>separate cases. So far I've only dealt with the former.
>>
>>You'll see I say in my slides I need help making this doc less
>>prescriptive about what the lower layer looks like (without making it so
>>abstract it becomes confusing).
>>
>>
>>>S 3.2 final para.
>>>- The actors and intention for this point were not clear to me.
>>
>>OK, I need to flesh this out - perhaps I'll use an example like an ATM
>>subnet.
>>
>>>/the whole path/ - is this end-to-end path or something else?
>>
>>e2e
>>
>>>/divided into segments/ - i.e. several segments combine to make the
>>>path or do you mean several L2 functions combine together (i
>>>parallel?) to provide the subnet service? /start of segment/, I
>>>presume this is ingress to the L2?
>>
>>"segments" aren't necessarily congruent with L2 subnets. They can be
>>aligned with the scope of tunnels (e.g. pseudowires). A sequence of PCN
>>domains would be another case. They are characterised by a load
>>regulator at the segment ingress and a feedback loop between segment
>>egress and ingress.
>>
>>
>>>S 3.3 bullet 1
>>>
>>>" * If the outer header carries an explicit congestion marking,
>>>the packet SHOULD be dropped--the only indication of
>>>congestion the transport will understand."
>>>- Why isn't this a MUST?
>>>- If the intention is to indicate something to the endpoint, then the
>>>packet needs to be dropped. Otherwise don't pass the marking upwards
>>>to IP. Am I missing something?
>>
>>Because I said I would say nothing as a MUST :)
>>
>>Even in RFC6040, this ended up being a SHOULD in one case (where the
>>marking wasn't the most severe).
> >
>Not sure, but can be thrashed-out later.
>
>>
>>>S 3.3 bullet 1
>>>- Is it possible to insist that the Highest marking MUST either set an
>>>IP marking or result in discard (using the above rule to decide
>>>which), lesser levels MAY have the same behaviour. That way we have
>>>more "sense" that the endpoint will react.
>>
>>Seriously, I don't like MUST in guidelines. But you're right, SHOULD
>>gives a liberal impression that is unwarranted. Your solution is one
>>approach - I'll think about it.
>I think it's more than "should".
>
>>
>>>S 3.3 bullet 4
>>>- I think this should also refer to the RFC that defines alternate ECN
>>>markings with DS.
>>
>>Yup.
>>
>>
>>>--- Chair comments ---
>>>
>>>I didn't do a complete review of this revision as a TSVWG Chair, and I
>>>am making no judgement at this time about whether this should be made
>>>a TSVWG work item. I suggest it would be first good to see more
>>>discussion on the contents voa the TSVWG list.
>>>
>>>I have the following comments that may be useful to consider for the
>>>next edit:
>>>
>>>- The draft proposes work on a topic that has been brought to the IETF
>>>before, although I am not aware of a published IETF document on this.
>>>However, this does not alone justify why the IETF should work on this
>>>topic: What are the risks and threats of NOT publishing this document?
>>
>>I've addressed this in my slides.
>>We need a place for temporal motivation text. It's not appropriate for
>>RFCs which are meant to be timeless, but we need to record somewhere why
>>we did something at a particular time.
>Exactly. it's best handled in email/meeting notes.
>
>>I have the same problem with trying to find a motivation for RSVP drafts.
>>
>>Perhaps there ought to be a requirement for a motivation statement on
>>the mailing list when a draft is first posted.
>That would suit me.
>
>>
>>>- This document does not appear to change an existing IETF
>>>specification, are there any current or proposed IETF documents that
>>>would be updated if this were to be published?
>>
>>Amazingly, I couldn't find one. Altho I'll have to look at 3819.
>>
>>
>>>- Section 1 says "The IETF would like to encourage this trend." - This
>>>is a consensus judgement that maybe needs to be confirmed by TSVWG.
>>
>>Of course. The idea of putting it in is to allow people to either agree
>>or not.
>OK
>>
>>>- The topic may benefit from coordination with other groups outside of
>>>he IETF.
>>
>>Yup - if it is adopted as WG item, it could benefit from a note at least
>>to IEEE, and possibly 3GPP (see slides about next steps - to include
>>propagating ECN through tunnelling protocol modules in the stack, even
>>tho they aren't ever the outer on the wire, e.g. GTP).
>>
>>Even if they aren't working on this, the statement to the IEEE might say
>>they ought to consider it, because switch vendors are putting out kit
>>that is getting used for this without a standard.
>OK
>
>>>--- END Chair comments ---
>>
>>Excellent - thank you - as always highly useful comments.
>>
>>
>>Bob
>>
>>
>>________________________________________________________________
>>Bob Briscoe, BT Innovate & Design
>
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design