Re: [tsvwg] ECN encapsulation draft - proposed resolution

[Bob Briscoe <[e-mail]>]

David, tsvwg list,

As promised yesterday, we just posted a new rev of 
ecn-encap-guidelines-16, with text based on your (David's) suggestions 
below. To add the references and to avoid some repetition, I twiddled 
the order round, but otherwise kept the text intact.

I also took the opportunity to post a new rev of rfc6040update-shim, 
'cos I noticed Geneve has been published as an RFC. There were also a 
couple of words edited in my local copy as agreed on the list a few 
months ago.

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim

Cheers



Bob

On 24/05/2021 13:50, Bob Briscoe wrote:
> David, Thx for bringing this one up. See [BB] inline,
>
> On 22/05/2021 01:02, Black, David wrote:
>>
>> On another topic, I believe that I have good news to pass along on 
>> the ECN encapsulation drafts.
>>
>> The current situation is that the 6040update-shim draft is ready for 
>> RFC publication to be requested, but there's an open issue in the 
>> ecn-encap draft on the contents of this paragraph in Section 4.6 
>> (Reframing and Congestion Markings), 
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-15#section-4.6 
>> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-15#section-4.6>:
>>
>>    Congestion indications SHOULD be propagated on the basis that an
>>
>>    encapsulator or decapsulator SHOULD approximately preserve the
>>
>>    proportion of PDUs with congestion indications arriving and leaving.
>>
>> Digging further, this area appears to be dealt with in greater length 
>> and detail by RFC 7141 (Byte and Packet Congestion Notification) 
>> Section 2.4 (Recommendation on Handling Congestion Indications When 
>> Splitting or Merging Packets), 
>> https://datatracker.ietf.org/doc/html/rfc7141#section-2.4 
>> <https://datatracker.ietf.org/doc/html/rfc7141#section-2.4>. The 
>> short summary is that the quoted sentence is generally correct with 
>> RFC 7141 containing a more comprehensive discussion including an 
>> exception.  As RFC 7141 is a BCP, I suggest treating it as 
>> authoritative on this matter for now, leaving redesign in this area 
>> to a possible future draft (as we did in the 6040update-shim draft 
>> wrt RFC 3168 fragment reassembly requirements).
>>
>> To carry this out, here's an initial ecn-encap draft text change 
>> suggestion (begins with last two sentences in second paragraph of 
>> Section 4.6):
>>
>> OLD
>>
>>       Where framing boundaries do not necessarily align
>>
>>    with packet boundaries, the following guidance will be needed.  It
>>
>>    explains how to propagate ECN markings from layer-2 frame headers
>>
>>    when they are stripped off and IP PDUs with different boundaries are
>>
>>    reassembled for forwarding.
>>
>>    Congestion indications SHOULD be propagated on the basis that an
>>
>>    encapsulator or decapsulator SHOULD approximately preserve the
>>
>>    proportion of PDUs with congestion indications arriving and leaving.
>>
>>    The mechanism for propagating congestion indications SHOULD ensure
>>
>>    that any incoming congestion indication is propagated immediately,
>>
>>    not held awaiting the possibility of further congestion indications
>>
>>    to be sufficient to indicate congestion on an outgoing PDU.
>>
>> NEW
>>
>>     Where framing boundaries do not necessarily align
>>
>>    with packet boundaries, the provisions of Section 2.4 of RFC 7141
>>
>>    apply to propagation of ECN markings from layer-2 frame headers
>>
>>    when they are stripped off and IP PDUs with different boundaries are
>>
>>     reassembled for forwarding. Those provisions include: "The general
>>     rule to follow is that the number of octets in packets with
>>     congestion indications SHOULD be equivalent before and after merging
>>     or splitting." See RFC 7141 for the complete provisions and related
>>     discussion, including an exception to that general rule.
>>
>>    In addition to adhering to the provisions of RFC 7141 Section 2.4,
>>
>>    the mechanism for congestion indication propagation SHOULD ensure
>>
>>    that any incoming congestion indication is propagated immediately,
>>
>>    and not held awaiting possible arrival of further congestion
>>
>>    indications sufficient to indicate congestion for all of the octets
>>
>>    of an outgoing IP PDU.
>>
>> END
>>
>
> [BB] OK, this is indeed progress.
>
>> RFC 7141 (a BCP) would be added as a normative reference.
>>
>
> [BB] I'll write that up now. And post a revised draft.
>
>
> Bob
>
>
>> Comments?
>>
>> Thanks, --David (as draft shepherd)
>>
>> *David L. Black, *Sr. Distinguished Engineer, Technology & Standards
>>
>> Infrastructure Solutions Group,*Dell Technologies*
>>
>> mobile [phone] [e-mail] <mailto:[e-mail]>
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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