Re: [Int-area] [tsvwg] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

Joe,

Sorry I missed this posting at the time (my mail filters moved both 
cross-postings into my int-area box which I check only rarely).

On 27/04/2019 18:13, Joe Touch wrote:
> Cross-posting to let both communities know:
>
> - it would be useful for these documents to address how fragmentation 
> and reassembly affects these signals
> (esp. if reassembling fragments with different ECN values)
>
[BB] This is addressed by the re-framing section 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-12#section-4.6> 
in ecn-encap-guidelines, altho it doesn't give examples of what might 
have caused frame boundary misalignment, so fragmentation is not 
specifically mentioned. I think I will add an explicit mention of 
fragmentation (if only so a search finds that section).

Actually I've realized that this highlights an inconsistency between the 
advice on ECN and fragment reassembly in RFC3168 and in 
ecn-encap-guidelines.:

  * RFC3168 requires that the ECN marking of a reassembled packet is the
    logical OR of the ECN marks on the fragments,
  * whereas ecn-encap-guidelines recommends marking the same number of
    outgoing as incoming octets when reassembling L2 frames or tunnelled
    packets with different boundaries - using a simple counter to track
    the balance.

In fact, it was the review of RFC3168 by me and Jon Crowcroft back in 
2001 that originally raised the question of how to handle reassembly of 
ECN-marked fragments 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-ip-00#section-11>. 
I'll quote a passage from the review, which I think justifies the 
recommendation in ecn-encap-guidelines to count marked bytes, rather 
than use the logical OR of RFC3168:

    To use the logical OR of the marking of all fragments might be a pragmatic
    solution, particularly for congestion control protocols like TCP where one
    loss per round trip is treated identically to many. However, it is becoming
    more common to see large numbers of packets per round trip time as data
    rates increase while packet sizes and the speed of light haven't increased
    for many years. Therefore it is to be expected that newer congestion
    control protocols might take more accurate account of the number of packets
    marked in a round trip. Hence, the inaccuracy of a logical OR during
    re-assembly at the IP layer is best avoided.

I'm not too worried about the inaccuracy of using a logical OR, but I 
think it best to recommend more accurate and no less costly counting. 
The only justification for the logical OR was that TCP only reacted to 
one ECN mark per RTT. But that is changing now, and the behaviour of one 
transport should not be embedded in lower layers anyway.

> - it would be useful for these documents to consider 
> draft-ietf-intarea-tunnels (which relates to the above) and its 
> discussion on many of the protocols cited
I can't find anything in draft-ietf-intarea-tunnels that ought to be 
cited from ecn-encap-guidelines or rfc6040-update-shim. Did you have 
something specific in mind?

I do want to raise a question about the following sentence, which 
precedes the mention of ECN:

    There are exceptions to this rule that are explicitly intended to
    relay signals from inside the tunnel to the network outside the
    tunnel, typically relevant only when the tunnel network N and the
    outer network M use the same network.

Was that last word meant to say "network protocol"?

Then, if that is what you meant, I would disagree. Many different 
network protocols include concepts similar to Diffserv and/or ECN (e.g. 
IEEE802.1p, MPLS and TRILL support both, etc), and there's rarely a 
reason /not/ to propagate the concept between different network 
protocols when they encapsulate each other, even tho it's not always 
straightforward to do so.

Bob

Bob
>
> Joe
>
>> On Apr 26, 2019, at 1:50 PM, Black, David <David.Black@dell.com 
>> <mailto:David.Black@dell.com>> wrote:
>>
>> This may be of interest to INT folks who are interested in tunnels 
>> and encapsulations.
>> Comments by the WGLC deadline are encouraged, but comments after the 
>> deadline are ok, as they’d have to be dealt with anyway at IETF Last 
>> Call.
>> Thanks, --David
>> *From:*tsvwg <tsvwg-bounces@ietf.org 
>> <mailto:tsvwg-bounces@ietf.org>>*On Behalf Of*Black, David
>> *Sent:*Wednesday, April 17, 2019 2:51 PM
>> *To:*tsvwg@ietf.org <mailto:tsvwg@ietf.org>
>> *Subject:*[tsvwg] 2nd WGLC on ecn-encap-guidelines and 
>> rfc6040-update-shim drafts, closes 6 May 2019
>>
>> [EXTERNAL EMAIL]
>>
>> This email announces a 2nd TSVWG Working Group Last Call (WGLC) on 
>> two drafts:
>> [1] Guidelines for Adding Congestion Notification to Protocols that
>> Encapsulate IP
>> draft-ietf-tsvwg-ecn-encap-guidelines-12
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/
>> This draft is intended to become a Best Current Practice RFC
>> [2] Propagating Explicit Congestion Notification Across IP Tunnel Headers
>> Separated by a Shim
>> draft-ietf-tsvwg-rfc6040update-shim-08
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>> This draft is intended to become a Proposed Standard RFC.
>> This WGLC will run through the end of the day on Monday, May 6, 2019.
>> Comments should be sent to thetsvwg@ietf.org 
>> <mailto:tsvwg@ietf.org>list, although purely
>> editorial comments may be sent directly to the author. Please cc: the
>> WG chairs attsvwg-chairs@ietf.org <mailto:tsvwg-chairs@ietf.org> if 
>> you would like the chairs to
>> track such editorial comments as part of the WGLC process.
>> No IPR disclosures have been submitted directly on either draft
>> Thanks,
>> David, Gorry and Wes
>> (TSVWG Co-Chairs)
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org <mailto:Int-area@ietf.org>
>> https://www.ietf.org/mailman/listinfo/int-area
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/