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

["Black, David" <[e-mail]>]

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?

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://mailarchive.ietf.org/arch/msg/tsvwg/btsauScSUsHaQIt0YE8eH5f-_Uc/
>> 
>> "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://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17*section-4.6), 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]