Subject: [conex] Fwd: Re: Comments on draft-briscoe-tsvwg-ecn-encap-guidelines-00

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

ConEx list,

I'm cross-posting this from tsvwg.

One of Nandita's points was that ConEx should 
work equally if the underlying congestion 
signalling is forwards or backwards. This intial 
draft aims to make recommendations on the 
interface between lower layer congestion signalling and ECN in IP.

It's also relevant to the two talks Lei Zhu gave 
a couple of ConEx meetings ago.

Links to slides for tsvwg (Thu) and to the draft are here:
<http://www.bobbriscoe.net/present.html#1103ecn-encap-guidelines>

Cheers

Bob

>Date: Mon, 28 Mar 2011 09:27:18 +0100
>To: Gorry Fairhurst <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Re: Comments on draft-briscoe-tsvwg-ecn-encap-guidelines-00
>Cc: <[email-masked]>
>
>Gorry,
>
>I'm about to rspond to you cc the list.
>
>This is just an off-list response to say I said 
>at the top of my mail (still quoted in your 
>reply) that you could reply on-list :)
>
>
>Bob
>
>At 08:40 28/03/2011, Gorry Fairhurst wrote:
>>I'm sending this to you off-list (only because your mail was off-list).
>>
>>I suspect some of this should be posted to the 
>>list (feel free to post some or all of my response).
>>
>>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.
>>>
>>>I'd be happy for any future response to cc the discussion so far to the
>>>list.
>>>
>>>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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design