Re: [tsvwg] ECN encapsulation drafts - update and next step

[Bob Briscoe <[e-mail]>]

David,

Thank you for summarizing the current state of this, and proposing text 
to try to move this along. And many apologies for tuning out for quite a 
while.

The problem that Sebastian identified (about mixing Not-ECT and ECT 
packets in the same frame) would be avoided at encap. The earlier "§4.2 
Wire Protocol Design: Indication of ECN Support"
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17#section-4.2
already says:

  A lower layer (or subnet) congestion notification system:

    1.  SHOULD NOT apply explicit congestion notifications to PDUs that
        are destined for legacy layer-4 transport implementations that
        will not understand ECN, and...

It was my presumption that, at encap, IP-layer PDUs with and without ECN 
support would not be mixed into the same layer-2 frame if the operator 
had arranged the logical link to apply ECN marking. (Just as an operator 
would not mix packets of different DSCPs into the same frame if it had 
arranged to queue them separately.) Nonetheless, I guess the re-framing 
section (§4.6) needs to say that (see suggested text at the end), 
because one cannot necessarily expect a protocol designer to read the 
whole document (!).

At decap, a frame containing a mix of ECN and non-ECN IP packets could 
still occur in two main cases:
1. links where ECN is not being applied at L2
2. in error conditions (e.g. where the ingress or an intermediate L2 
node has been wrongly configured).

In case #1, there would be no CE marking applied to the L2 header, so it 
would be quite OK to decapsulate frames with a mix of Non-ECN and ECN 
packets inside.

In case #2, 'franken-frames' containing a mix of ECN and non-ECN packets 
AND with CE marking on the L2 header would need to be discarded. So text 
like you suggested would certainly also be needed:
https://mailarchive.ietf.org/arch/msg/tsvwg/hY2CcxMqwHpUXhwTIn28jxPfCxw/

In summary, I believe adding the following text in §4.6 before "Where 
ECN marking has had to be applied ..." (as well as your text) would 
solve all this:

    At encapsulation, if frame boundaries will not necessarily align
    with IP packet boundaries, mixtures of parts of ECN-capable and
    non-ECN-capable IP packets SHOULD NOT be packed into the same
    frame (see Section 4.2). This is expressed as 'SHOULD NOT' because
    it might depend on the specifics of the L2 marking scheme and there
    are circumstances where it might not be of concern, e.g. where it
    is known that ECN marking is not applied over a particular link.
    This is similar to the practice where IP packets with different
    DSCPs would not be mixed into the same frame if they were going
    to be queued separately at non-IP-aware nodes within a subnet
    (for example, in an LTE or 5G radio access network they might be
    classified into separate bearers).



On byte-v-packet congestion marking, I'll respond separately.

Thank you again


Bob



On 06/11/2022 12:02, Black, David wrote:
> This note summarizes my understanding of what has happened here and what comes next.  Reminder: We are primarily dealing with Section 4.6 of the ecn-encap draft (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17#section-4.6), specifically goal #2 and the example algorithm provided for it.
>
> Back in July, Sebastian found a serious problem with the example algorithm for goal #2, and I wound up proposing text to fix it:https://mailarchive.ietf.org/arch/msg/tsvwg/hY2CcxMqwHpUXhwTIn28jxPfCxw/
> In mid-August, Sebastian objected to the inclusion of goal #2 and asked that all mention of it and the example algorithm be removed:https://mailarchive.ietf.org/arch/msg/tsvwg/RIHxa3qmL43BlU7GU2K-Yjfokpg/
>
> ... several months elapsed ...
>
> Discussion resumed, leading to the conclusion that discussion of the overall technique of byte-counting congestion control in RFC 7141 (a Best Current Practice RFC) provides a foundation for inclusion of goal #2 in the ecn-encap draft:https://mailarchive.ietf.org/arch/msg/tsvwg/bVwxnY0zzlk3nBerEMPTSmisx_I/.  In that message, Sebastian suggested using errata to RFC 7141 to get rid of that underlying material that he views as clearly wrong.   An errata item was submitted to do that:https://www.rfc-editor.org/errata/eid7237  .  Subsequent discussion indicates that this errata item is not going to move forward, so Sebastian is going to instead write an individual draft proposing changes to RFC 7141:https://mailarchive.ietf.org/arch/msg/tsvwg/-NErVJnMgT8RwqvspiFfVJN3MLQ/  (near bottom of that long message).
>
> A normative reference to this ecn-encap draft has been holding up another draft at the RFC Editor for several years (https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/history/).  This ecn-encap draft is past WG Last Call, with this discussion being the only remaining open issue, so it's high time to move the draft onward to our AD and towards IETF Last Call.
>
> The authors should submit a revised version of this ecn-encap draft with the text from July that fixes the serious problem with the example algorithm.  Assuming that is done quickly (hint), I will wait about a month to see happens with the proposed changes to RFC 7141, so that I can summarize that situation accurately in the Shepherd write-up for this draft.  I intend to produce that Shepherd's write-up in mid-December with the goal of submitting this draft (and the related rfc6040update-shim draft) for publication (i.e., to our AD and towards IETF Last Call) before the end of the year.
>
> Comments and questions are welcome.
>
> Thanks, --David
>
> -----Original Message-----
> From: Sebastian Moeller<[e-mail]>  
> Sent: Thursday, November 3, 2022 12:11 PM
> To: Black, David
> Cc: Bob Briscoe;[e-mail]
> Subject: Re: [tsvwg] ECN encapsulation drafts - update and next step
>
>
> [EXTERNAL EMAIL]
>
> Hi David,
>
>
>> On Nov 3, 2022, at 15:45, Black, David<[e-mail]>  wrote:
>>
>> Hi Sebastian,
>>
>>>> RFC 3168 is a Proposed Standard RFC and RFC 7141 is a Best Current Practice RFC.  I believe the two cited RFCs provide sufficient foundation for including the goal #2 concept.
>>> 	[SM] But that illustrates my point exceptionally well, because "we" accepted
>>> an untested unimplemented recommendation in RFC7141 we now pretend this to be a viable alternative.
>>> IMHO the failure clearly was in RFC7141 adding this text without proper justification.
>>> The way to handle this, IMHO is an erratum to RFC7141 to get rid of that problem where it was introduced.
>> That's a fine opinion - feel free to submit that erratum:https://www.rfc-editor.org/errata.php*reportnew  .  Further discussion here should avoid assuming that the (not yet submitted) erratum has already been approved.
> 	[SM2] Fair enough. But see my follow-up email, about my probable mis-interpretation what "Best Current Practice" documents are intended for (spoiler, not (only)documentation of established best practices in the field, but also policy setting to steer the community into specific directions). So I am not clear anymore whether a) an erratum should be raised against the text in section 2.4, because if that was a policy decision back then no amount of it-not-working can invalidate that decision b) the text in RFC7141 needs an erratum at all as it might be simply considered a policy steering approach that lead no where (again assuming that we do not find a working implementation of the method).
>
> That however still leaves the issue that the current text is quite long and the proposed method still seems untested and unimplemented (as is probably also true the method described in RFC7141 2.4). As I said before, if we can convincingly show that the method as described works and does the right thing, let's add the section, if we can not show that, leave the section it out. IMHO it is fine to offer (roughly) equally valid and demonstrably working alternatives to implementers, but why bother enumerating (some) theoretical possible solutions that are untested? As seen in this argument adding such text to RFCs leads to problems down the line what to do, so I think ignoring it (baring evidence of it actually working) seems an acceptable fudge. (After all the rules give considerable leeway to the IETF and WG's to interpret its rules as they like, so why not put this flexibility to good use here?).
>
>
>>>> OTOH, I think it's reasonable to add text to indicate the absence of known "running code", if that is indeed the case.
>>> 	[SM] I thought "running code" was sort of an unofficial requirement, preferably 2 independent implementations?
>> That's not correct, although it's always a very good idea to have "running code."  Some working groups do impose "running code" requirements, but that definitely varies by WG, and may vary by draft within a WG.
> 	[SM] Then I must say RFC 2026's section 1.2:
> The goals of the Internet Standards Process are:
>     o  technical excellence;
>     o  prior implementation and testing;
>     o  clear, concise, and easily understood documentation;
>     o  openness and fairness;  and
>     o  timeliness.
>
> confused me. Yes it does not say "prior implementation and testing is absolutely required" but it seems to indicate that it is expected. And yes, I have by now understood that the whole process is set-up to give the IETF and its WG's maximal flexibility (no argument or judgment against that, it is a decent way to avoid painting one-self into a corner by sheer rule mechanics). But that means if "does not work" is not an argument to exclude text then surely "is implied/mentioned by older RFCs" must not strictly be a reason to include something either, flexibility to interpret rules cuts both ways, no?
>
> Regards
> 	Sebastian
>
> P.S.: If the method can be shown to actually work in practice all of this is moot, in that case add the section and be done with.
>
>
>> Thanks, --David
>>
>> -----Original Message-----
>> From: Sebastian Moeller<[e-mail]>  
>> Sent: Thursday, November 3, 2022 3:57 AM
>> To: Black, David
>> Cc: Bob Briscoe;[e-mail]
>> Subject: Re: [tsvwg] ECN encapsulation drafts - update and next step
>>
>>
>> [EXTERNAL EMAIL]
>>
>> Hi David,
>>
>> first thanks for your response.
>>
>>
>>> On Nov 2, 2022, at 23:24, Black, David<[e-mail]>  wrote:
>>>
>>> Hi Sebastian,
>>>
>>> Getting back to this after having been diverted by too many other things ... and taking up the requests in reverse order:
>>>
>>>> I would also like to understand, why a standard document is a good place to publish untested hypotheses.
>>> While that might have been intended as rhetorical, it does deserve a response.
>> 	[SM] This was not intended as a rhetorical question, but I really want to know what our justification is of doing that. My emphasis on the "untested" part, although I probably should have been more verbose and added "non-trivial, non-obvious" to "untested", not everything needs empirical back-up.
>>
>>
>>> Please review the text that introduces the two goals:
>>>
>>>   Two possible design goals for propagating congestion indications,
>>>   described in section 5.3 of [RFC3168] and section 2.4 of [RFC7141],
>>>   are:
>>>
>>> RFC 3168 is a Proposed Standard RFC and RFC 7141 is a Best Current Practice RFC.  I believe the two cited RFCs provide sufficient foundation for including the goal #2 concept.
>> 	[SM] But that illustrates my point exceptionally well, because "we" accepted an untested unimplemented recommendation in RFC7141 we now pretend this to be a viable alternative. IMHO the failure clearly was in RFC7141 adding this text without proper justification. The way to handle this, IMHO is an erratum to RFC7141 to get rid of that problem where it was introduced.
>> 	RFC7141 is from 2014 and in 2022 we apparently still have no implementation of that method and the method seems to be contentious.
>>
>> I do not think that errors we made in the past need to bind us on the way forward.
>>
>>
>>> Continuing to the first request ...
>>>
>>>> Given the complete lack of an actually working and tested implementation of a byte-fraction evaluating CC algorithm,
>>>> I request the goal #2 part and its example dropped or at the very least re-phrased so that it is clear that this is an untested hypothesis.
>>> That's certainly a valid concern, although removing that material entirely seems excessive.
>> 	[SM] Respectfully why" I count three strikes against including it:
>> 1) the proposed method was so glaringly wrong that even I* detected the flaw
>> 2) there is apparently no implementation. let alone two implementations or an open-source one that can be scrutinized
>> 3) the method was not universally accepted as valid in the respective iccrg WG by members other than me**.
>>
>> What more justification do we need to request removal of text?
>>
>> IIUC the goal of that draft is to give guidance to implementers, and I would argue that the fewer implementation choices we offer the less complicated following a RFC is going to be. Especially when essentially the whole multi page RFC (and a number of sibling RFCs) could be condensed to more or less a single sentence:
>> "Aim to conserve ECN marks as veridical as possible, at decapsulation, if in doubt, try to recreate what the marking node would have done to the inner packet(s) as much as computationally acceptable"
>>
>> *) It should cause the WG some pause that nobody else noticed that obvious error though, makes me wonder how close a reading the rest of the draft has been exposed to.
>> **) So this is not an "ax to grind" issue one might assume behind my actions. Which honestly is not my motivation, I just try to make the internet a better place by doing my best to make internet standards as good as they can reasonably get and that means arguing against obvious deficient text.
>>
>>
>>> OTOH, I think it's reasonable to add text to indicate the absence of known "running code", if that is indeed the case.
>> 	[SM] I thought "running code" was sort of an unofficial requirement, preferably 2 independent implementations?
>>
>>> Bob - is it correct that there is no known "running code" for byte-counting congestion mark propagation (similar to the example implementation of goal #2 provided in Section 4.6 of the draft)?
>> 	[SM] I think it is established that there is no end-point protocol that acts on the assumption of byte-counting congestion marking, as of the cited iccrg post not even TCP Prague seems to implement that.
>>
>>
>>
>> Regards
>> 	Sebastian
>>
>>
>>> Thanks, --David
>>>
>>> -----Original Message-----
>>> From: Sebastian Moeller<[e-mail]>  
>>> Sent: Saturday, August 13, 2022 2:16 AM
>>> To: Black, David
>>> Cc: Bob Briscoe;[e-mail]
>>> Subject: Re: [tsvwg] ECN encapsulation drafts - update and next step
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> Dear David, dear Bob,
>>>
>>>
>>> Over in iccrg mailing list a relevant discussion was started:
>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/iccrg/ePpX9rC9mTc_RPOZrIaa2i2KRWk/__;!!LpKI!hTqTEj2YxmzBSduuzkeuBsRHKCAJ3f4cOX1EJIlKKmW21cl56Iu92BaWej5-fE71K89jCQSUfuL4oC4ZgA$   [mailarchive[.]ietf[.]org]
>>> This affects the fact that the current TCP Prague draft seems to recommend to interpret the fraction of ECN marks within a RTT as fraction of ECN-marked bytes. And hence appears to be the reason to including goal #2 into section 4.6
>>>
>>> However as noted in the linked thread:
>>> a) currently no protocol uses byte-fraction:
>>> 	in current Linux BBRv2, DCTCP and surprisingly TCP Prague all do use packet-based fractions
>>> b) that thread argues that packet-based fractions are actually a better choice here; the thread is still active so it is well possible that in the end byte-fracton mkght prevail, but at the moment byte-fraction does not appear to be an accepted solution to the problem.
>>>
>>>
>>> So instead of phrasing this as a question again (and getting no response) I am going to phrase this differently:
>>>
>>> Given the complete lack of an actually working and tested implementation of a byte-fraction evaluating CC algorithm, I request the goal #2 part and its example dropped or at the very least re-phrased so that it is clear that this is an untested hypothesis.
>>>
>>> I would also like to understand, why a standard document is a good place to publish untested hypotheses.
>>>
>>>
>>> Regards
>>> 	Sebastian
>>>
>>>
>>>
>>>> On Jul 27, 2022, at 22:41, Black, David<[e-mail]>  wrote:
>>>>
>>>> It appears to fall to me to propose some text to address the problem that Sebastian found. OK, here goes ...
>>>>
>>>> AFTER:
>>>> Where ECN marking has had to be applied at non-IP-aware nodes and
>>>> framing boundaries do not necessarily align with packet boundaries,
>>>> the decapsulating IP forwarding node SHOULD propagate ECN markings
>>>> from layer-2 frame headers to IP packets that may have different
>>>> boundaries as a consequence of reframing.
>>>> ADD:
>>>> ECN marking propagation logically occurs before application of rule 1
>>>> in Section 4.4.  An important case is that if ECN marking propagation would
>>>> cause an ECN congestion indication to be applied to an IP packet that is a
>>>> Not-ECN-PDU, then that IP packet is dropped in accordance with rule 1.
>>>>
>>>> That appears to cover the goal #1 examples.  The goal #2 example needs
>>>> further tweaking to fix the problem that Sebastian found:
>>>>
>>>> *  A counter ('in') tracks octets arriving within the payload of
>>>>     marked L2 frames and another ('out') tracks octets departing in
>>>>     marked IP packets.
>>>>
>>>> At the end of that sentence, add "and contained in IP packets that are dropped
>>>> because ECN congestion indications cannot be applied to IP packets that are
>>>> Not-ECN-PDUs."
>>>>
>>>>    While 'in' exceeds 'out', forwarded IP packets
>>>>     are ECN-marked.
>>>>
>>>> At the end of that sentence, add "or are dropped if they are unable to be ECN marked."
>>>>
>>>>     If 'out' exceeds 'in' for longer than a timeout,
>>>>     both counters are zeroed, to ensure that the start of the next
>>>>     congestion episode propagates immediately;
>>>>
>>>> With those modifications, I think the 'out' counter now functions as intended
>>>> in the presence of IP packets that cannot be marked because they are
>>>> Not-ECN-PDUs - the basic idea is to count octets in those packets as 'out' even
>>>> though they are dropped instead of being forwarded.
>>>>
>>>> With WG chair hat on, I would the draft authors to make those changes please ... or explain what I've missed.
>>>>
>>>> Thanks, --David
>>>>
>>>> -----Original Message-----
>>>> From: Bob Briscoe<[e-mail]>  
>>>> Sent: Monday, July 25, 2022 2:33 PM
>>>> To: Black, David; Sebastian Moeller
>>>> Cc:[e-mail]
>>>> Subject: Re: [tsvwg] ECN encapsulation drafts - update and next step
>>>>
>>>>
>>>> [EXTERNAL EMAIL]
>>>>
>>>> David,
>>>>
>>>> On 18/07/2022 22:27, Black, David wrote:
>>>>> Hi Sebastian,
>>>>>
>>>>>> This is quite a lot of text. I still think that recommending quite different methods here is increasing ambiguity of the signal
>>>>>> (making the job of the end-points interpreting that signal harder); but if these methods are not interpreted as "incompatible" that is no show stopper*.
>>>>> Good, thanks!
>>>>>
>>>>>> However the text is clearly on an abstract level and appears to be incomplete.:
>>>>>>
>>>>>> *  A counter ('in') tracks octets arriving within the payload of
>>>>>>      marked L2 frames and another ('out') tracks octets departing in
>>>>>>      marked IP packets.  While 'in' exceeds 'out', forwarded IP packets
>>>>>>      are ECN-marked.  If 'out' exceeds 'in' for longer than a timeout,
>>>>>>      both counters are zeroed, to ensure that the start of the next
>>>>>>      congestion episode propagates immediately;
>>>>>>
>>>>>> If the issue arises that the L2-layer supports and exercises ECN, but all packets it carries are Not-ECT packets and will be dropped instead of marked,
>>>>>> the out counter will not increase, the in counter however will accumulate quite some debt,
>>>>> Yes, it will, and that's part of a larger structural problem for all of Section 4.6, as one cannot propagate any ECN marking to a Not-ECT packet via any algorithm.  For this (goal #2) algorithm, something would need to be done, e.g.:
>>>>>> 	So surely such tracking would need to count marked and dropped octets...
>>>>> Beyond that:
>>>>>> The text for goal #1 above that paragraph used the phrase "propagation of congestion signal" which can be more easily understood to be either a CE-mark or a drop,
>>>>>> than "('out') tracks octets departing in marked IP packets" which to me reads clearly as not encompassing drops.
>>>>> Since it's necessary to modify text here, let's put in some more direct text to explicitly state that rule 1 in Section 4.4 requires that Not-ECT IP packets be dropped instead of marked with CE.  It might be possible to write that text once in Section 4.6 in a way that applies to both goals and all three examples.  Bob - care to suggest some changes to accomplish that?
>>>> [BB] AQMs and tail-drop queues do drops. An ECN propagation algo
>>>> doesn't, at least it doesn't explicitly/propagate/ drops. It would only
>>>> explicitly drop packets in one case:
>>>> #1 Where a protocol error prevents a valid packet from being constructed
>>>> (e.g. frames with the L2 equivalent of Not-ECT and ECT contributing to
>>>> the same packet, which implies there has been a corruption since the
>>>> original IP packet was broken down into frames).
>>>>
>>>> Where part of a target packet never arrives (thus preventing the packet
>>>> from being completed and forwarded - i.e. once a partially constructed
>>>> packet has sat in memory for more than a timeout), it would be
>>>> discarded. This is what I would call /implicit/ propagation of drop.
>>>>
>>>>
>>>> Bob
>>>>
>>>>> Thanks, --David
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sebastian Moeller<[e-mail]>
>>>>> Sent: Saturday, July 16, 2022 4:57 PM
>>>>> To: Black, David
>>>>> Cc:[e-mail]
>>>>> Subject: Re: [tsvwg] ECN encapsulation drafts - update and next step
>>>>>
>>>>>
>>>>> [EXTERNAL EMAIL]
>>>>>
>>>>> Hi David,
>>>>>
>>>>>
>>>>>> On Jul 15, 2022, at 23:40, Black, David<[e-mail]>  wrote:
>>>>>>
>>>>>> Hi Sebastian,
>>>>>>
>>>>>> This might have a quick resolution ...
>>>>>>
>>>>>>> To clarify, we are talking about what you called paragraph 2 inhttps://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tsvwg/btsauScSUsHaQIt0YE8eH5f-_Uc/__;!!LpKI!n5hkdkO2gKyQ5sXuCN2VtjvgZGKGu9YTwrMBRqFWqa3gQLAy-zsQJ9yRrBSuUT57-LLzbfx9qh3m_g$  [mailarchive[.]ietf[.]org]
>>>>>>>
>>>>>>> "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."
>>>>>>>
>>>>>>> This is the part where I object to continuing with if we recommend incompatible approaches. I am NOT objection to the rest of the draft.
>>>>>> Thank you for clarifying. The text quoted above is not present in the -17 version of the draft.
>>>>>>
>>>>>> Please check section 4.6 of the -17 version (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17*section-4.6__;Kg!!LpKI!n5hkdkO2gKyQ5sXuCN2VtjvgZGKGu9YTwrMBRqFWqa3gQLAy-zsQJ9yRrBSuUT57-LLzbfzxKKeg8w$  [datatracker[.]ietf[.]org]), and let us know if you have any further problems with the text in that section.
>>>>> 	This is quite a lot of text. I still think that recommending quite different methods here is increasing ambiguity of the signal (making the job of the end-points interpreting that signal harder); but if these methods are not interpreted as "incompatible" that is no show stopper*.
>>>>>
>>>>> However the text is clearly on an abstract level and appears to be incomplete.:
>>>>>
>>>>> *  A counter ('in') tracks octets arriving within the payload of
>>>>>      marked L2 frames and another ('out') tracks octets departing in
>>>>>      marked IP packets.  While 'in' exceeds 'out', forwarded IP packets
>>>>>      are ECN-marked.  If 'out' exceeds 'in' for longer than a timeout,
>>>>>      both counters are zeroed, to ensure that the start of the next
>>>>>      congestion episode propagates immediately;
>>>>>
>>>>> If the issue arises that the L2-layer supports and exercises ECN, but all packets it carries are Not-ECT packets and will be dropped instead of marked, the out counter will not increase, the in counter however will accumulate quite some debt, that will be imposed on later IP packets, potentially constructed out of un-marked L2-frames. That in spite of congestion already being signaled by dropped Not-ECT IP packets. And the zeroing condition does not apply here since IN >> OUT.
>>>>> 	So surely such tracking would need to count marked and dropped octets...
>>>>>
>>>>> I believe this is not the intended method, but a consequence of trying to keep this concise, still this is not ideal.
>>>>> The text for goal #1 above that paragraph used the phrase "propagation of congestion signal" which can be more easily understood to be either a CE-mark or a drop, than "('out') tracks octets departing in marked IP packets" which to me reads clearly as not encompassing drops.
>>>>>
>>>>>
>>>>> I would rather describe less here than more, but it is the clearly the decision of the authors how deep they want to go here.
>>>>>
>>>>>
>>>>> Regards
>>>>> 	Sebastian
>>>>>
>>>>>
>>>>> *) Also he differences in markings/drops emitted from such an reframing node will probably be relatively small, compared to say changing how a single received CE mark is to be interpreted.
>>>>>
>>>>>
>>>>>> Thanks, --David
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Sebastian Moeller<[e-mail]>
>>>>>> Sent: Friday, July 15, 2022 3:29 AM
>>>>>> To: Black, David
>>>>>> Cc:[e-mail]
>>>>>> Subject: Re: [tsvwg] ECN encapsulation drafts - update and next step
>>>>>>
>>>>>>
>>>>>> [EXTERNAL EMAIL]
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>>
>>>>>> it seems like there is considerable confusion about the course of the recent discussion on the mailing list regarding this topic, thanks for giving me the opportunity to summarize it. See below [SM]
>>>>>>
>>>>>>
>>>>>>> On Jul 15, 2022, at 01:55, Black, David<David.Black=[e-mail]>  wrote:
>>>>>>>
>>>>>>> Writing as the WG chair responsible for these two drafts … the two ECN encapsulation drafts are:
>>>>>>> 	• draft-ietf-tsvwg-ecn-encap-guidelines; and
>>>>>>> 	• draft-ietf-tsvwg-rfc6040update-shim .
>>>>>>> Both drafts have been through WG Last Call with each emerging with a single open issue around propagation of ECN codepoints.
>>>>>>>
>>>>>>> The rfc6040update-shim draft issue around reassembly of fragments was resolved well over a year ago. The text that resolves the issue initially appeared in Section 5 of the -13 version of the draft, and has not been changed since.
>>>>>>>
>>>>>>> The open issue in the ECN encap draft is how to specify propagation of ECN codepoints across reframing of L2 frames to IP packets when L2 framing boundaries do not necessarily align with IP packet boundaries. I believe that the current -17 version of the ecn-encap draft contains text (in Section 4.6) that reflects the current situation – there are two possible design approaches, both approaches yield implementations that are workable in practice, and the WG as a whole is not recommending one approach over the other, much as individual working group members have strong individual preferences for each approach.
>>>>>> 	[SM] I interpret this as your position is the two approaches are "compatible enough" (I will get to the confusion about compatibility below).
>>>>>>
>>>>>>> Sebastian Moeller has strongly objected to moving forward with that text
>>>>>> 	[SM] To clarify, we are talking about what you called paragraph 2 inhttps://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tsvwg/btsauScSUsHaQIt0YE8eH5f-_Uc/__;!!LpKI!mCzIJj85D64iWM4gj90WbV_HnSFuqXSiscgq-frpcGHetSubcmkJekbZtfhdafFKaI6gFEfEtZLNyR4DLw$  [mailarchive[.]ietf[.]org]
>>>>>>
>>>>>> "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."
>>>>>>
>>>>>> This is the part where I object to continuing with if we recommend incompatible approaches. I am NOT objection to the rest of the draft.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> on the grounds that it amounts to "two incompatible methods/implementations." The text in the draft definitely describes multiple ways to implement the same functionality and the results can be expected to exhibit different behavior under similar circumstances. That leaves the question of whether the multiple methods/implementations are incompatible, which requires consideration of what they could be incompatible with.
>>>>>> 	[SM] As far as I am concerned the issue is that end points should be able to deduce the kind of signal the marking node in the network intended to convey to them, since communication is already a challenge, it helps if any signal sent is as unambiguous as possible. A congestion control algorithm can work better and/or faster the more it knows about the veridical situation at the marking node when the marking was performed, I hope this is an uncontentious statement.
>>>>>>
>>>>>>
>>>>>>> Multiple implementations of reframing L2 frames to IP packets do not directly interact with each other – the crucial area of compatibility is interaction of the reframing ECN codepoint propagation behavior with congestion control functionality that reacts to ECN congestion indications.
>>>>>> 	[SM] May I ask why? If for whatever reason multiple non-IP encapsulations (with different frame sizes) are stacked on top of each other that employ some ECN marking the propagation problem would apply here as well. However that is rather theoretical and a case probably not worth caring for.
>>>>>>
>>>>>>> Different ECN codepoint propagation approaches can be expected to interact differently with different congestion control algorithms, but I've not seen any evidence of an incompatibility (e.g., congestion control algorithm failure) in that interaction. I'll observe that some amount of variability in this area is a feature (not a bug), e.g., there is not a single standard congestion control algorithm for all traffic on the entire Internet, nor should there be.
>>>>>> 	[SM] This is about the information content of the received signal, the less ambiguous it is the better for the end points, independent on how the endpoints react to that signal.
>>>>>>
>>>>>>
>>>>>>> I'm going to stop here to allow Sebastian to restate and summarize his objection – in its current form, it does not appear to be a well-grounded technical objection, but that conclusion is based almost entirely on his use of one word, "incompatible", which might have been a poor word choice on his part.
>>>>>> 	[SM] Let me try to re-cap this:
>>>>>>
>>>>>> Starting inhttps://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tsvwg/kIegjead67IfIS7XTx9g6Gw5qeY/__;!!LpKI!mCzIJj85D64iWM4gj90WbV_HnSFuqXSiscgq-frpcGHetSubcmkJekbZtfhdafFKaI6gFEfEtZKhXLa7qA$  [mailarchive[.]ietf[.]org]:
>>>>>>
>>>>>>>> Jonathan:
>>>>>>>>>> Two possible implementation approaches to propagating congestion
>>>>>>>>>> indications are packet counting (e.g., proportion of IP PDUs sent with
>>>>>>>>>> congestion indications approximately matches the proportion of layer-2
>>>>>>>>>> frames received with congestion indications) and byte counting (e.g.,
>>>>>>>>>> number of payload bytes in IP PDUs that have congestion indications
>>>>>>>>>> is approximately equivalent to the number of bytes in layer-2 frames
>>>>>>>>>> received with congestion indications).
>>>>>>> Bob:
>>>>>>> [BB]
>>>>>>> 1) "Two possible" avoids saying that they are incompatible. I think it's
>>>>>>> best to say it how it is.
>>>>>>> And I think the text ought to refer to the two relevant RFCs (§2.4 of
>>>>>>> RFC7141 and §5.3 of RFC3168) that are the source of the disagreement.
>>>>>> It was Bob, the author of the draft, that classified the two approaches as incompatible. So I argue that "incompatible" has not been a poor word choice on my part, if it was a poor choice at all.
>>>>>>
>>>>>>
>>>>>> I then took Bob at his word, and accepted his classification in good faith:
>>>>>>
>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tsvwg/B4wELnQhE9lxOkv-drwqF9dSpT0/__;!!LpKI!mCzIJj85D64iWM4gj90WbV_HnSFuqXSiscgq-frpcGHetSubcmkJekbZtfhdafFKaI6gFEfEtZL_VBO5QA$  [mailarchive[.]ietf[.]org]
>>>>>>
>>>>>>>>> [BB]
>>>>>>>>> 1) "Two possible" avoids saying that they are incompatible. I think it's best to say it how it is.
>>>>>>>> [snipped here because this is addressed at the idea of having two "incompatible" methods proposed]
>>>>>>> 	[SM] I respectfully disagree, an RFC should not propose two incompatible methods/implementations. I consider this to be really fundamental, the endpoints are supposed to interpret the "congestion signal" from the network and act appropriately, a requirement that will work much better if the network employs unambiguous behavior in creating and handling such marks. I understand that real life implementations might differ from an RFC's SHOULD (and that is fine) but I would think it wise for the RFC to not sow the seeds of confusion by proposing incompatible implementations. So IMHO if we can not come to an agreement we are indeed better off by not mentioning any method at all because that would be less confusing.
>>>>>> To which Bob replied:
>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tsvwg/H-m5E3OSH-oBjYjsvLb1vKOPKaw/__;!!LpKI!mCzIJj85D64iWM4gj90WbV_HnSFuqXSiscgq-frpcGHetSubcmkJekbZtfhdafFKaI6gFEfEtZLXXdUI7w$  [mailarchive[.]ietf[.]org]
>>>>>>
>>>>>>> [BB] David already said that the chairs have decided to wrap this up.
>>>>>>> There are loads of RFCs and standards from other bodies where a choice
>>>>>>> is left open and written up as 'for further study'.
>>>>>>> Not everyone has infinite time to continually write to a mailing list.
>>>>>>> The world is not perfect.
>>>>>> This does not imply that Bob changed his assessment of these approaches as incompatible, but simply that he is fine with just publishing the RFC with contradictory recommendations.
>>>>>>
>>>>>>
>>>>>> 	I do not see that a request to make sure we publish useful and contradiction-free RFCs could be in any way controversial, so I am a bit puzzled about the turn of the discussion here.
>>>>>> 	So the question is, is Bob correct in that the two approaches are incompatible or does your opinion that they are "compatible enough" (if that is an acceptable re-phrasing of your position) carry the WG's consensus.
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> 	Sebastian
>>>>>>
>>>>>>
>>>>>> P.S.: For what it is worth, at this point in time, I personally would mildly prefer to drop that paragraph and carry on with the rest. Partly because I do not think that the situation we are discussing here is more than a rare corner-case, and it seems wiser to first empirically figure out what works than giving recommendations mostly built on theoretical considerations. If working implementations of both proposed approaches should exist that confirm they both work (equally well) re-adding such a paragraph might make sense, but lacking such data not saying anything might be the more conservative approach.
>>>>>>
>>>>>>
>>>>>>> Thanks, --David
>>>>>>>
>>>>>>> David L. Black, Sr. Distinguished Engineer, Technology & Standards
>>>>>>> Infrastructure Solutions Group, Dell Technologies
>>>>>>> mobile +1 [e-mail]
>>>> -- 
>>>> ________________________________________________________________
>>>> Bob Briscoehttps://urldefense.com/v3/__http://bobbriscoe.net/__;!!LpKI!n5hkdkO2gKyQ5sXuCN2VtjvgZGKGu9YTwrMBRqFWqa3gQLAy-zsQJ9yRrBSuUT57-LLzbfw3Po2coQ$  [bobbriscoe[.]net]


-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/