Re: Idea for packet numbers

[Mikkel Fahnøe Jørgensen <[e-mail]>]

For other reasons I would like the packet numbers to be close, preferably
without gaps except during connection migration.

This relates to storing interval maps as groups of bitmaps instead of
binary trees to track already received packets. This both provides are more
efficient implementation, and it reduces some modes of DoS where an
attacker can create a lot of small intervals which cause the data structure
to inflate.

If packet numbers can only jump in higher bits and if we make a constraint
that such jumps must not be happen without filling at least one full packet
block, then it is possible to pack received packets efficiently into their
respective lower bit groups and the DoS concern would be mitigated, and it
would be easy to reject abuse. There is still the issue of blocks of lost
packets - so it is not that simple in praxis.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 20 July 2017 at 12.00.04, Magnus Westerlund (
[e-mail]) wrote:

Hi,

There has been some discussion around packet numbers. For passive
detection of packet loss in measurements and network management, it
would be really good if the packet numbers where continuous and not only
monotonically increasing. As this enables one to determine losses
upstream of the measurement point. At the same time I understand there
are benefits with being able to introduce gaps into the packet number to
test the receiver's behaviour.

To enable both of these capabilities I would propose that the N least
significant bits of the packet number are strictly increased by one.
Then one can introduce gaps in the bits above the N ones. Yes, that will
burn through the packet number space faster as the gaps may become
larger than was the case without this. However, I don't see that this
will have significant effect unless the sender introduce gaps very
frequently so that the length of the packet number field needs to be
much larger due to the outstanding sequence number space is much larger.

The value of N can clearly be discussed but it should be selected so
that reordering and common burst durations are shorter than the time to
wrap the strictly increase amount of bits. If the higher bits are
available to measurement node, some possibility to infer gaps will also
be possible. It might be that N needs to be scaled with throughput with
a minimal value. N=8 would mean 256 packets between wraps. I think that
is a reasonable minimal value. However, that will wrap in 28 ms at 100
mbps of payload (assuming 1400 bytes of payload per packet).

So what people think about this idea?


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB | Phone [phone]
Torshamnsgatan 23 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------