Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

[Jonathan Morton <[e-mail]>]

> On 13 Mar, 2020, at 3:03 pm, Bob Briscoe <[e-mail]> wrote:
> 
> Specific problem: End-to-end, taking into account both fragmentation and reassembly, the "logical OR" reassembly process required in RFC3168 roughly doubles boththe number and the proportion of CE marked packets and the number and proportion of CE-marked bytes (relative to a parallel flow with slightly smaller packets that is not fragmented).

Before I attempt to address your arguments in detail, I want to clarify something fundamental.  I think this may be one good reason why David Black wants to separate the concerns of reassembly (covered by RFC-3168) and decapsulation (covered by RFC-6040) - a sentiment I completely agree with.

Let's consider two original, consecutive IP packets: A B.  They are encapsulated by a tunnel, producing TA TB.  These are both larger than the MTU, so are fragmented into TA1 TA2 TB1 TB2.  On the tunnel path, an AQM applies a CE mark to TB1.  Eventually these packets are decapsulated, prior to which they must be reassembled, and the CE mark must be preserved somehow.

What you seem to imply is that somehow, TA2 and TB1 can be reassembled into one CE-marked packet, leaving TA1 and TB2 separate, and that decapsulation may then apply the CE mark to both A and B.

But this does not jive with what I know about IP-layer fragmentation, in which TA1(ECT) TA2(ECT) always reassembles into TA(ECT), and TB1(CE) TB2(ECT) reassembles into TB, which is then CE marked by the RFC-3168 bitwise-OR rule.  We would then have A(ECT) and B(CE) transmitted onward, which seems to match the intent of the AQM - in particular, the number of CE marks is preserved, not doubled.

What am I missing from the context of your objections?

 - Jonathan Morton