Re: [tsvwg] ECN encapsulation draft - proposed resolution

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

To clarify the second algorithm, "full packet size" could have 2 meanings: the size of the inner packet or the max packet size, independent of this packet's size.
This results in 3 algorithms:
- only mark if the first byte of the inner (reassembled) packet is marked (ignore marks on any other bytes/segments)
- apply a random probability on the inner packet based on the ratio of marked bytes in the inner packet and the inner packet size
- apply a random probability on the inner packet based on the ratio of marked bytes in the inner packet and the maximum inner packet size

Thinking further on this, it seems that the first 2 algorithms keeps both packet and byte probability, only if there is a strong correlation between the sizes of the inner and outer packets. If there is no correlation, these first two algorithms will carry the outer packet probability to the inner packets independent from their sizes, and the third algorithm will mark the inner depending on their size (gives more marking/dropping probability to larger packets).

If there is a strong correlation of packet sizes and the AQM marks with a byte probability, the second algorithm, will square the byte based probabilities. If the AQM marked with packet probability the tunnel decapsulation will mark with inner packet size dependent probability.

Assuming there is usually a large correlation between packet sizes and that AQMs that apply byte based probabilities are not often used, the first 2 are probably recommended? The third is quite tricky as you need to know exactly what is going on to avoid giving short packets an advantage.

Also taking into account why AQMs in routers would mark byte based or packet based is usually dependent on their capacity limit (being packets or bytes for buffer sizes and packets/second or bits/second for rates). If there is a packet size correlation in the tunnel, then it is logical to pass that through to the original senders, but if there isn't, it is logical to also spread the rate or buffer limit over all flows independent of their sizes (as they don't matter and are reshuffled by the tunnel anyway).

Koen.

-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Wednesday, June 9, 2021 6:08 PM
To: Jonathan Morton <[e-mail]>; Bob Briscoe <[e-mail]>
Cc: [e-mail]; Markku Kojo <[e-mail]>
Subject: Re: [tsvwg] ECN encapsulation draft - proposed resolution

Not having followed the full discussion/history, for me preserving the probability of marks is important (whether on bytes or packets), and as marking/dropping is usually applied in the network according to a probability in a closed control loop, it is probably the best way forward. Even if marking is applied by time distance and/or number of bytes or a count algorithm, it will converge to the "right" probability. This means any reassembly that preserves the average probability is good enough. Due to multiple bottlenecks and RTT dependencies, marking/dropping probability to rate/throughput is not an exact science anyway (though we should try to approach this as much as possible in a reasonable way).

So for me following simple algorithms would be ok to use:
- only mark if the first (even partial) segment of the reassembled packet is marked (ignore marks on any other segments)
- apply a random probability on the packet based on the ratio of marked bytes in the packet and full packet size

I believe both algorithms keep both byte and packet probability equal. It might not fulfil the immediate requirement, but since an AQM applying a low probability is not an immediate action anyway, it is not so important. An immediate AQM like the step threshold is marking with a high marking probability (100%) a series of packets, which is then also immediately carried forward during decapsulation by both algorithms.

Koen.


-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Jonathan Morton
Sent: Sunday, June 6, 2021 5:02 AM
To: Bob Briscoe <[e-mail]>
Cc: [e-mail]; Markku Kojo <[e-mail]>
Subject: Re: [tsvwg] ECN encapsulation draft - proposed resolution

> On 6 Jun, 2021, at 2:06 am, Bob Briscoe <[e-mail]> wrote:
> 
> Before we do, can we make sure we're all on the same page regarding some basics that I believe are /facts/ about preserving markings when PDU boundaries change. Do you agree with the following table that I asked about earlier:
> 
>                   | marked    marked
>                   | PDUs      bytes
> -------------------+------------------
> preserving prop'n  |  ==        ==
> preserving number  |  !=        ==
> 
> 
> IOW, do you agree that the three that are tagged as '==' are equivalent ways of expressing the same thing, but different from the one tagged '!=' ?

This question just tells me that you are still focusing on the wrong metrics.  The number and/or proportion of marked bytes is IRRELEVANT.  What matters are the number of bytes and/or time interval BETWEEN marks.

I explained this in more detail in my previous post.

 - Jonathan Morton