Re: [tsvwg] ecn-encap-guidelines reframing section

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

Bob,


>> [BB2] I'm afraid not, because this is not about some niche environment.

>> Both the SHOULDs in the current draft are intended to apply to all known

>> AQMs and all known congestion controls including standard TCP.


I understand and agree with that objection to the "For environments in which protocol and/or application response to congestion is sensitive to ..." text that I suggested - in 20/20 hindsight, that text won't work :-(.


It appears to me that you and Jonathan are debating a marked-PDUs/packets vs. marked-bytes topic which is roughly analogous to the reassembly marking topic that was avoided in the 6040update-shim draft by deferring the decision on whether or not to update RFC 3168's fragment reassembly text.  This was due in part to RFC 3168 limiting what we could do in that draft - while I don't see analogous limits on this draft, I would still like to find a deferral approach that is roughly analogous to what was done in the 6040shim-update draft for consistency ... and in the hope of moving both of these drafts onward out of this WG in short order.



Much as I'm sure you believe that byte-mode marking is the proverbial "right thing to do," could you suggest more neutral text that defers the byte-mode vs. packet-mode marking decision for reframing, please?  I don't want to see these drafts still being in the WG at IETF-111 in July ... and the blocking WG Last Call issue wrt RFC 3168 has been resolved via the agreed text for the 6040update-shim draft.

Thanks, --David

From: Jonathan Morton <[e-mail]>
Sent: Wednesday, March 24, 2021 6:35 AM
To: Bob Briscoe
Cc: Black, David; Markku Kojo; Joe Touch; Markku Kojo; [e-mail]; [e-mail]
Subject: Re: ecn-encap-guidelines reframing section




[EXTERNAL EMAIL]



> On 24 Mar, 2021, at 11:48 am, Bob Briscoe <[e-mail]<mailto:[e-mail]>> wrote:

>

> Before we discuss the requirement, can we make sure we're all on the same page regarding some basic facts about preserving markings when PDU boundaries change:

>

>                    | marked    marked

>                    | PDUs      bytes

> -------------------+------------------

> preserving prop'n  |  ==        ==

> preserving number  |  !=        ==

>

> For those who prefer writing, this means that, when the boundaries between PDUs change, preserving the proportion of marked PDUs, the proportion of marked bytes, and the number of marked bytes all mean the same thing. But preserving the number of marked PDUs is not the same as any of the others. And note that preserving the timing is the same as preserving the number of marked PDUs.

>

> Does everyone agree on these factual points, at least?



I'm unclear what "PDU" means in this context.  I think we should use "inner packet", "outer packet" and "link frame" to be unambiguous, at least during the discussion.



Clearly, if one marked link frame results in two marked inner packets, when the link frame itself is smaller than either of the inner packets - as in your illustration earlier - then that preserves *neither* number nor proportion.  An argument could be made either way where the link frame is large enough to enclose more than one complete inner packet, but I'm going to argue for preserving the number of marks.



> For instance, consider CoDel counting 200 PDUs between marks on the outer headers, then imagine that on decap the boundaries between the PDUs are changed to create half as many PDUs...

> Then, if each single mark is preserved as a single marked PDU, it will result in only 100 PDUs between marks. This is because the total number of PDUs has changed, so you cannot preserve both the number of marked PDUs and the number of unmarked PDUs.



This is a straw man.  If Codel marked the inner packets before encapsulation, those inner packets will still carry CE marks after passing through a re-framing link, before any processing of congestion marking subsequently applied to the link frames.  Number and proportion are therefore *both* preserved without having to do any extra work.



What we need to consider is the application of *new* congestion marking to the link frames or outer packets, and transferring those congestion indications adequately to the inner packets they encapsulated.  The link frames don't need to carry any indication that the inner packet was already marked for this to work; only that a congestion mark may be applied and will be honoured at decapsulation.



Hence my suggestion that one marked link frame should result in one marked inner packet.  One mark was applied by the AQM; one mark should be seen by the transport.  This behaviour is easy to predict and analyse; knowing the marking frequency of the AQM, you can derive the behaviour of the congestion control algorithm.  It should also be straightforward to specify and implement.



- Jonathan Morton