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

[Sebastian Moeller <[e-mail]>]

Hi Bob,


see [SM2]

> On Nov 9, 2022, at 19:16, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastian, see [BB]
> 
> On 07/11/2022 16:29, Sebastian Moeller wrote:
>> Hi Bob,
>> 
>> see [SM] below.
>> 
>> 
>>> On Nov 7, 2022, at 11:59, Bob Briscoe <[e-mail]>
>>>  wrote:
>>> 
>>> 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).
>>> 
> 
> [BB] Based on our discussions below, here's a better proposed para:
> 
> At encapsulation, if frame boundaries will not necessarily align 
> with IP packet boundaries:
> 
> * CE markings SHOULD NOT be propagated from the arriving IP header 
>   to the lower layer outer header. This is contrary to the recommendations 
>   in Section 4.3, which were intended to ease subnet monitoring. It makes no 
>   difference to the marking outcome beyond the subnet.

	[SM2] That makes sense but complicates things for the encapsulator.

> 
> * Implementations SHOULD be able to separate ECN-capable and non-ECN-capable IP 
>   packets so that they are not packed into the same frame (see Section 4.2). 

	[SM2] Again let me ask why? Let's assume an (non-IP) L2-layer that employs its own congestion marking scheme and knows the properties of the AQM (e.g. knows whether AQM's mark rfc3168 style or L4S style or completely differently) so the decapsulator will see the inner ECN state, and then can do the right thing dependent on the inner ECN indicators, that IMHO would even allow to map a gradual congestion signal intelligently to encapsulated IP packets, e.g.:
A) for a mild congestion signal change ECT(1) to CE, but leave ECT(0) and Not-ECT packets alone
B) for intermediate congestion change ECT(1) to CE, and randomly set ECT(0) to CE or drop Not-ECT packets with low probability
C) for high congestion change ECT(1) to CE (or even drop it to get a stronger window reduction from L4S style senders), set ECT(0) to CE and drop Not-ECT.

or similiar. Mind you this sketch above is incomplete but just serves to illustrate the idea of mapping non-ECN congestion signals onto IP packets. All of this is obviously also possible if Not-ECT, ECT(10), and ECT(1) are always framed independently, but then we have complexity on both ends...


>   Nonetheless, where an operator knows that ECN marking is not applied over a 
>   particular link, such separation would not be necessary. 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).
> 
> Both bullets are non-mandatory because they might depend on the specifics of 
> the L2 marking scheme.
> 
> 
>>> 	[SM] Assuming the decapsulator actually accounts properly for Not-ECN-PDU why add this restriction? I would add that DSCPs often are used to denote different priorities and hence require separate queueing/forwarding, I am not sure whether generally ECN-enabled should unconditionally be treated differently from ECN-disabled at least traditional single queue rfc3168 AQMs are not set up for such a differential treatment. 
>>> 	I wonder what is more realistic to implement an encapsulator that will steer packets into different frames based on ECN-capability or a decapsulator that drops non-ECT packets (and accounts for them properly, according to your proposal there needs to be a counter/timeout mechanism there already anyway, also accounting for not-ECT octets should not raise complexity much).
>>> 	I naively? assume that to use different frames an (aggregating) encapsulator would need to:
>>> a) send short aggregates when the worst case traffic of interleaved Not-ECT ECT packets arrives foregoing the benefit of aggregation (probably costing throughput)
>>> b) or try to hold half-filled frames of either type for some time hoping to fill them up (introducing addition delay) and hopefully forego the aggregation benefit less often
>>> 	but also risking some amount of reordering (probably benign, unless flows toggle/drop the ECT bits somehow).
>>> 
>>> 
>>> I am not convinced that mixing non-ECT and ECT packets in an aggregate can not work well with ECN propagation. The trick is simply to make the consequence of the aggregation truly invisible for the end-points.
>>> 
> 
> [BB] Yes, it's possible someone can invent a way to make a mix of non-ECT and ECT work well with ECN propagation, without having to drop CE-marked 'franken-packets'.

	[SM2] How about this: since our lower-layer needs coordination between encapsulator and decapsulator already ("2.  SHOULD NOT apply explicit congestion notifications to PDUs if the egress of the subnet might not propagate congestion notifications onward into the higher layer." seems to imply that) it is likely that the style of AQM is also known, then the decapsulator knows whether an outer "CE" is rfc3168 or L4S type and can do the right thing (e.g. drop the respective non-matching ECT(N) packets as well as ECT(0) packets at decapsulation or for L4S style marking only drop ECT(0) and Not-ECT with a low probability). It will introduce a requirement for knowing the AQM marking style, but the decapsulator can work serially as can the decapsulator, no additional queues for Not-ECT, ECT(0), ECT(1) required (which only matter for aggregating L2 framing, for 1-to-1 framing the issue does not arise).

> But we don't have to make that call, because this draft gives guidance to protocol designers, who will write the spec for their particular ECN propagation scheme. We so have to explain the recommendations clearly (and you are helping greatly with that), but we can say exceptions might be appropriate, depending on the specifics of the particular scheme). 

	[SM2] Not argueing against allowing exceptions, my main objection is that we should not ratify an RFC with incomplete methods on board. IMHO the only/best way to check a method for "coverage" is to implement it and employ it on real world data (aka testing), this will be way more thorough than iterating over the mailing list...

> 
> Without such an invention, if ECN marking is being applied at L2 and if the encap is allowing parts of ECN and non-ECN packets into the same frames, the decap will be dropping some proportion of CE-marked frames. The harm from unnecessary drop would then surely outweigh the benefits of more optimal aggregation.

	[SM] That depends, for a L4S style shallow marker that would not have dropped the Non-ECT I agree, but for an rfc3168 AQM that is different as it likely would have dropped the non-ECT packet. But splitting all non-CE ECN codepoints into independent units clearly makes life simpler at decapsulation.
	I honestly do not know about "surely outweigh the benefits of more optimal aggregation"; but from extrapolating from WiFi I think that some link technologies have non-neglieable aggregation benefits where it might be still more efficient to transmit one "wrong" packet only to drop it later than to split one aggregate into three or more. But that is admittedly pretty hand-wavy. Also WiFI here severs as example of a technology with massive aggregation benefit, with its 4 AC queues, WiFi in theory could easily be rigged to split all 4 ECN codepoints into separate queues.

The question is where to put the complexity, at en- or de-capsulation (plus what is known about the AQM's marking style at decapsulation).

> 
>> Now for the octet-counting method, mixed aggregates are still problematic, even with drop accounting implemented and Not-ECT "verboten":
>> 
>> Lets assume the case from section 4.6 again this time purely for ECT(0)/ECT(1) input packets, assuming your "make separate aggregates for ECN enabled and non-ECN packets proposal" was actually implemented.
>> 
>> Let's assume further that our L2 aggregates over 10 full IP packets and that we just encapsulated 9 ECT(0) and 1 CE packet. (We could complicate things by looking at non IP-packet aligned framing with say just enough header of the last packet in the aggregate to qualify for CE-propagation on encapsulation, but I think this is not actually required to illustrate my point).
>> According to the encapsulation rules in section 4.3 we propagate the CE mark to the outer packet.
>> 
> 
> [BB] The requirement in 4.3 that I think you're referring to is:
>        [the ingress] SHOULD encode the same level of
>        congestion in outer headers as is arriving in incoming headers.

	[SM2] Yes that part.

> 
> Again, I think you've identified that in 4.6. we should have dealt with encap more fully. Specifically we should have said that CE-marking SHOULD NOT be propagated to the outer when there's re-framing (as I've suggested in the new proposed text at the start).
> 
> Not propagating ECN down the layers doesn't alter the outcome after decap. It was only a SHOULD in 1:1 cases to improve  network monitoring.. However, in non-1:1 cases, it complicates encap, so it's best avoided.

	[SM2] Here opinions from actual operators would be interesting to hear, I wonder what would be preferable, simpler propagation rules like "never propagate CE to the outer layer at encapsulation" or your "facilitate monitoring with exception" proposal.

> 
>> Now the following decapsulation will, according to the current rules, label all 10 packets CE when it back-propagates the outer header to the inner headers, effectvely inflating the number of marked octets by a factor ~10. 
>> 
>> So I see why, octet-counting does not play well with aggregation. "Method 1" propagations, like mark/drop any one packet or mark/drop all packets of the aggregate however are less affected by mixed aggregates (and mixed both Not-ECT& ECN as well as the current example 9 ECT(0)+ 1 CE). 
>> 
>> We can argue whether drop one or drop all are better suited, but the point is they do not aim to veridically transmit the number of marked octets and hence it is no failure if they end up not mark as many octets, so over- and under-marking are acceptable, which both are problematic for the counting method.**
>> 	So let me ask, do we consider the hard to achieve* goal of veridical counting of congestion-marked octets (information which end-points are told they are not required to act on) over a simpler and less restrictive ECN propagation rule? I have a hunch what the WG will opt for.
>> 
> 
> [BB] Once we fix the clarifications that you've made me realize I omitted, octet counting would achieve its goal just as well as 'existence' propagation would achieves its goal.

	[SM2] So I had a look at this section essentially after Last Call (sorry for that tardiness), and identified a number of issues. This gives my pause as I would hope such issues in proposed standards would have been caught and corrected well before issuing a Last Call on a draft. I appreciate your confidence in my ability to find problems but I do not think or clam that I comprehensively looked at all potentially problematic conditions, so I am not sure we found and fixed all issues yet.

> I'd happily reopen the debate about why both existence and probability propagation are necessary, but David wants the draft to just allow either,

	[SM2] Yes, I see a certain "let's get this draft ratified for the sake of other drafts queued up behind" attitude even if this means including an incomplete method. I had more sympathy with that approach if at the same time we would not take a similarly incomplete method (from rfc7141) as "must-honor" precedent. Either we cavalierly allow some imprecision into RFCs AND do not feel bound to strongly by such sections, OR we should not allow such stuff in. Doing both results in situations like we are in now.


> so I won't go there.

	[SM2] My main argument against including a section on the "counting method" in the draft is not primarily that I think its goals are not generally achievable (which I do think), but that the method as proposed is incomplete and will not be much help for an implementer of ECN encapsulation, so unless it can be shown to actually work and to actually cover all cases important in the real world it offers little utility. This is a bit of a "Chekhov's gun" argument, unless a proposed method can easily be put to action and will do the right thing, I consider it better not to include it in a draft no matter how clever the core idea. It has happened that an apparently good and elegant idea has been brought down in implementation when handling of all required special cases added sufficient complexity to result in something that can not be described as "good and elegant" anymore. Having a working implementation at hand allows to make a judgement on whether the whole thing is worth it.

Regards
	Sebastian


> 
> Cheers
> 
> 
> Bob
> 
>> 
>> Regards
>> 	Sebastian
>> 
>> 
>> *) I am being generous here, the goal is unconditionally unachievable, but requires careful restriction of the inputs to not fail on its nose with aggregate L2 frames.
>> 
>> **) All methods suffer from bad accuracy, in the example above only a hypothetical mark-any-one-unless-packet(s)-are-already-marked method end up marking packets that the AQM did not mark and that might be from completely different network-paths that do not even traverse the AQM in question.
>> 
>> 
>> 
>> 
>>> 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 in https://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 in https://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 in 
>>>>>>>>> 
>>>>>>>>> https://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 [phone] 
>>>>>>>>>> 
>>>>>>>>>> [e-mail]
>>>>>>> -- 
>>>>>>> ________________________________________________________________
>>>>>>> Bob Briscoe                               
>>>>>>> 
>>>>>>> https://urldefense.com/v3/__http://bobbriscoe.net/__;!!LpKI!n5hkdkO2gKyQ5sXuCN2VtjvgZGKGu9YTwrMBRqFWqa3gQLAy-zsQJ9yRrBSuUT57-LLzbfw3Po2coQ$
>>>>>>> 
>>>>>>>  [bobbriscoe[.]net]
>>>>>>> 
>>>>>>> 
>>> 
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe                               
>>> 
>>> http://bobbriscoe.net/
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/