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

[Bob Briscoe <[e-mail]>]

Jonathan,

On 13/03/2020 14:03, Jonathan Morton wrote:
>> 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.
Yup. As I said in that conversation, that's not in question.
>
> 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.
Eh? Where do you think I've implied that? Nah.

I've just re-read, and maybe you've assumed that the single counter 
implies I'm just reassembling any fragment with any other. No. Obviously 
it only reassembles the fragments of one packet back together. I didn't 
think I'd have to say that!

Anyway, the implementation is only an example for people who find it 
easier to understand something concrete - the point is about the 
requirement, not how to implement it.

Nonetheless, just in case, I ought to say what does /not/ happen in the 
example implementation: A non-CE fragment arriving to be reassembled 
cannot cause the reassembled packet to be CE-marked. So there is no need 
to check the counter unless an arriving fragment is CE-marked. Also, 
regarding complexity, I've realized that both the "logical OR" and the 
"CE-byte-preserving" algorithms require per packet state (whether the 
re-assembled packet will be CE marked). The CE-byte-preserving algo adds 
one counter per-interface (probably two counters in practice, so writing 
by the incoming and outgoing processes can be decoupled).

>
> 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?
Well, I don't know, 'cos I don't know how you came to that 
interpretation (you'll need to point to the sentence that made you think 
that, if it's still not clear).


Bob
>
>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/