Re: [tsvwg] Progress with draft-ietf-tsvwg-ecn-encap-guidelines

[Sebastian Moeller <[e-mail]>]

HI Koen,


> On Sep 26, 2023, at 03:16, Koen De Schepper (Nokia) <koen.de_schepper=[e-mail]> wrote:
> 
> As L4S is the way forward


	[SM] That is certainly a valid subjective opinion, but so is my stance L4S is too little too late and the "experiment" will peter out inconclusively but will leave a legacy of increases RTT-bias over the internet... neither is objective fact.


> and is the dominant use of ECN,

	[SM] Again valid opinion, but too confidently "dressed" as a fact. Also by most meanings of "dominance" this seems to be incorrect (I see no hierarchy of ECN users/using signaling pathways). But humor me and explain how you came to that conclusion.
	I also note that L4S was apparently heavily inspired by DCTCP and its ECN signaling approach. In the "natuaral niche" DCTCP developed ultra-short RTT data centers however DCTCP seems not considered to be the end all of congestion signaling any more (if ever) evident in the ongoing work on more refined methods, seen in multiple IETF drafts on that topic like https://datatracker.ietf.org/doc/draft-ravi-ippm-csig/ or the poseidon work (https://www.usenix.org/conference/nsdi23/presentation/wang-weitao). These alternative methods tend to use unambiguous per packet congestion information that does not do L4S'/DCTCPs rate encoding of congestion severity into a stream of packets and hence will have different congestion mark propagation desires than rfc3168 or L4S (but since we are talking about ECN in this draft this just counters the "dominance" claim, for draft-ietf-tsvwg-ecn-encap-guidelines we certainly need to look at both current users of the ECN bitfield for ECN en-/de-framing, so L4S and rfc3168).


> it should be clear to NW designers which 'alternative' is to be implemented for L4S and typical Classic AQMs, and which is recommended for Classic ECT(0) with CoDel AQMs (is there indeed broad consensus that the latter is necessary?).

	[SM] Let me remind you of the issue we are discussing here: 
a stream of IP packets is transmitted over a link that uses L2 frames that are not aligned with IP packet boundaries, so we have two situations:
	a) L2 frames > IP packets -> multiple IP packets per L2 frame
	b) L2 frames < IP packets -> fractional IP packet(s) per L2 frame

So clearly the number of marked L2-payload octests is not going to be naturally aligned with IP packets. And that IMHO is a problem that needs to be a solution that is at least "good enough".


> For L4S it is important that the marking probability is preserved (both in ratio of marked/total packets and bytes).

	[SM] But this applies only if the marking entity actually saw the same packet granularity as the end-points, and that is exactly not the case we are discussing. The IMHO real question you need to answer is:
How would the marking entity have marked, had it seen the actual IP packets individually. If the unequivocally answer to that is that the marking entity put meaning into the fraction of marked octets (over a sequence of frames) then extracting that information at reframing makes sense, if the marking entity did not do that however, then pretending it did does not really help congestion control (where I claim the goal needs to be to get as veridical an estimate about the real congestion situation as reasonably possible). This is the core of my objection to rfc7141 recommendations as well, inventing information that is not actually there does IMHO not lead to robust and reliable solutions.
	Also for fixed packet sizes ratio of marked/total packets and ratio of marked/total octets is essentially identical, for our example however it is not as the marking frequency per frame and per octets results in different outcomes at the de-framer, unless we know what the marking entity aimed for we DO NOT KNOW whether propagating the number of marks (goal 1) or the number of marked octets (goal 2) is the correct thing to do. Pretending method/goal 2 the the way forward makes assumptions that should IMHO be verified. As would be the actual difference in behavior between method 1 and method 2 propagation methods. My gut feeling is that method 2 will not result in significantly better congestion control signaling than method 1 but comes at a considerably higher implementation complexity, whether we "hide" some of that complexity by off-loading it to the en-framer does not really matter IMHO. I also note that Bob's pseudo-code was buggy (by trying to be too comprehensive and dealing with corner-cases instead of focussing on the main problem) supporting my view that we should aim at keeping things as simply as possible...



> Only one scheme supports this. The other will increase the probability for recomposed packets. So, if both schemes are included in the draft, then the above should be very clear for the readers.

	[SM] I am not convinced that the current draft is clear enough on that. If the argument is that this behaviour is intended to help with end to end L4S signaling the draft should state so explicitly and not argue that this behaviour is dictated by rfc7141. But see above why this assertion that method/goal 2 actually does help for L4S signaling is contested...


> 
> Koen.
> 
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Gorry Fairhurst
> Sent: Thursday, August 31, 2023 11:44 AM
> To: [e-mail]
> Cc: Bob Briscoe <[e-mail]>
> Subject: [tsvwg] Progress with draft-ietf-tsvwg-ecn-encap-guidelines
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> Bob, & TSVWG,
> 
> Here is a follow-up on the above draft:
> 
> 1. We expect Bob to review the wording of his update, and especially whether the wording of the text needs to be improved following the feedback, and then to submit a revised ID as requested.
> 
> 2. In addition, the Chairs have noted that Sebastian raised concerns about the current relevance of RFC7141 (BCP 41) during the WGLC, his concerns were also described in a proposed Errata and in several emails sent to the list.  The WG did not decide to update BCP 41 at this time.
> We expect Sebastian's position to be noted in the working group write-up that we are now preparing.
> 
> We will continue the IETF process when the new revision is posted.
> 
> Best wishes,
> Gorry & Marten
> (TSVWG Chairs)
> 
>