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

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

On 3/13/20, 12:45 PM, "Jonathan Morton" <[e-mail]> wrote:
>    If you assume the AQM on the tunnel path is marking probabilistically,
> then doubling the packet rate over time (by fragmenting the original packets
> into two smaller ones each) also doubles the marking rate over time, and
> (assuming sufficiently independent probability of marking) the number of
> reassembled packets carrying marks also doubles.

Ah, thanks Jonathan.  I agree this is a good guess at the model.

I'll try my own phrasing to see if there's a chance I might be caught up now:

(1) If we consider 2 flows, one whose packets are all fragmented into 2 packets
each, and another that's unfragmented, but otherwise identically sending across an
identically congested AQM, an AQM that marks 2% of the packets in the unfragmented
one could end up causing marks on up to 4% of the packets in the fragmented flow,
as counted after reassembly.


If that successfully gets us all on roughly the same page, can we also agree
that logical-OR reassembly preserves the property below?

(2) If a receiver sees N CE-marked packets in a sequence of packets, the network
emitted at least N separate CE-marks while forwarding those packets.

To clarify one of my previous messages, (1) addresses what I was calling
"proportion of CE-marked packets" and (2) speaks to what I meant by "number of
CE-marked packets" in my response.  I was thrown by the "both number and proportion"
claim in the "long response" email.

In retrospect this looks like a semantics debate I'm happy to now abandon, though
I'm grateful for having my confusion about the discussion cleared up, if that
has indeed happened.


Anyway, coming back to the original thread: I certainly do think the (B) option
(from https://mailarchive.ietf.org/arch/msg/tsvwg/RFmIUiPb0vss7xt16yeK2TGJSJU/ )
as expressed in draft-ietf-tsvwg-rfc6040update-shim-10#section-5 takes positions that
don't seem backed by wg consensus.

I also think that David's suggested approach (in 
https://mailarchive.ietf.org/arch/msg/tsvwg/-EgX4VHHMLEGmj4IbeRNruLd86A/) sounds
like the best option on offer.

FWIW, I prefer David's suggestion to the (C) option of deleting any mention of
fragmentation in hopes that nobody implements something 3168-compliant, on the theory
that it's something we might later update.  Clarity about the existing relevant specs
seems just better to me, and this doc can also be updated if we do indeed update the
reassembly rules at some point.

Best regards,
Jake