Re: [tcpm] bit length for byte counter fields in accurate ecn

Yoshi,

While searching for a recent email from you just now, I found this one 
unanswered. My apologies.
In case you are still interested in the answer... inline tagged [BB]...

On 30/04/2020 10:06, Yoshifumi Nishida wrote:
> Hi,
> I am still a bit wondering about the length of the field for the byte 
> counter.
> In my understanding, the length of the counter is (at least) 32 bits 
> and encoded into 24 bits field.
> So, I am thinking that reducing the bit size doesn't affect accuracy 
> directly while the potential risks for miscalculation will be 
> increased. Is this incorrect?

Here's the calculations we went through to determine the 24b field size.

Each lowest 24b of the counter are sent every time the receiver sends an 
AccECN Option. Both ends start a connection from the same value, so they 
can maintain 24-bit counters locally just with simple modulo arithmetic 
(example in appendix A). So the field only has to be large enough that, 
if it wraps, the sender can tell, even if some ACKs were lost around the 
time it wrapped.

Each feedback counter increments by the size in bytes of each data 
segment carrying that codepoint.
Theoretical max packet size is 2^16 (IPv4 & IPv6).
You detect wrap most easily by detecting the counter going from the top 
quarter of the range to the bottom quarter (i.e. perhaps highest two 
bits transitioning 0b11->0b00).
So you would have to lose 2^(24-16-2) = 2^6 = 64 ACKs of max size 
packets in a row to miss a wrap.

Losing 64 ACKs in a row is pretty unlikely.

Notice I haven't said that packets of size 2^16 are pretty unlikely. 
'Cos if we get there they won't be.
9000B is fairly common in DCs. That's >2^13.

Bob

>
> Thanks,
> --
> Yoshi
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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