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

["Holland, Jake" <[e-mail]>]

Hi Bob,

On 3/13/20, 10:56 AM, "Bob Briscoe" <[e-mail]> wrote:
> Same answer as for Jonathan - I'm talking e2e, not just reassembly, 
> taking account of frag and re-assembly relative to another 
> non-fragmented flow. All carefully defined in the email (so pls don't 
> question this sentence, 'cos I didn't want to re-write all the carefully 
> defined stuff again). You have to read the build-up to the scenario too.
>
> Of course, if I'm wrong, I'll admit it. However, not if someone just 
> asserts that the summary is wrong without pointing to the flaw in the 
> body of the argument.

I guess I'll try again with the example from further down the body of the
email, which seems to contain a more explicit form of the claim in question:
(From https://mailarchive.ietf.org/arch/msg/tsvwg/B2Gnb-jYPiZFYuA3YXNRhktKaT4/ )

   The tunnel ingress doubles the packet rate of the flows it fragments. 
   Therefore, during any congestion event, the AQM marks twice as many 
   packets from the fragmented flows as the others {Note 1}. Reassembly 
   restores the packet rate to that at the origin sender. And it removes 
   some of the extra congestion markings that fragmentation added.

   For example, if 100 packets of the unfragmented flow received 2 marks, 
   100 packets of the fragmented flow would turn into 200 fragments, 4 
   would be marked, then reassembly would turn them back into 100 packets 
   and a little more than 2 would be marked (because of the extra size of 
   the inner headers).

   If reassembly used "logical OR" instead, of the 100 forwarded packets, 4 
   would be marked (3.96% to be precise).

This seems mistaken to me.

If 2 of the 100 packets are marked pre-fragmentation, then fragmentation makes
it 4 of 200, then logical-OR reassembly will result in marking only for 2 packets
of the 100 post-reassembly.

There's no opportunity to increase the count of marked packets without receiving
new CE marks while fragmented because the reassembly doesn't cross the un-fragmented
packet boundaries.

It seems to me you're asserting that this would happen, but using a count-based
model (or maybe stream-based model?) that mistakenly fails to account for the way
reassembly avoids crossing IP packet boundaries of the pre-fragmented packets.

Also, since it seems to be an issue:  I don't think this line of inquiry is just
disagreeing with a summary or nitpicking at a minor point--the assertion that the
count of CE-marked packets can increase e2e because of fragmentation and reassembly
seems fundamental to the claim that logical-OR reassembly is broken.

I still leave open the possibility that I've misunderstood, so I'm asking for an
example of a packet sequence e2e that demonstrates how the count of CE-marked packets
can increase due to fragmentation and reassembly, because until I can understand that
it's possible, I tentatively conclude that the bulk of the argument presented was
built on a fundamental error.

I have read the email in its entirety and found no explanation of a fragmentation+
reassembly chain of events that allows a sequence of packets containing 2
pre-fragmented marked packets to turn into a sequence with 4 post-reassembly marked
packets, unless at least 2 extra marks were added while fragmented (the quoted part
above merely asserts it can happen, without an explanation of how anywhere I could
find).

If this is possible in a conformant network, I'm asking anyone who can explain it to
please do so, of course I don't limit my request to Bob.

Best regards,
Jake