RE: Idea for packet numbers

["Swindells, Thomas (Nokia - GB/Cambridge, UK)" <[e-mail]>]

That is partly my concern, if implementations/mechanisms are assuming a low level of reordering (such as middle boxes using a spin bit) how confident are we that those assumptions are accurate and a good thing to ossify?
With a multi-threaded multi-nic system I’m not certain it is actually that it is necessarily easy to (performantly) avoid re-ordering - even if the implementation doesn’t deliberately intend to introduce it.

One solution is to decide that spin bit and less complex lost packet tracking (and whatever else benefits from low amounts of packet reordering) are worthwhile properties and so mandate clearly that packet generation must be serialised and the egress of the packets strictly ordered as much as possible (e.g. each connection is locked to a nic with the packets sent in the correct order). I’ve no idea if this is a property current implementations actually have today or if multiple streams are encrypted on different threads with just the implicit assumption the output will end up in the right order.

Thomas

From: MORTON, ALFRED C (AL) [mailto:[e-mail]]
Sent: 25 July 2017 15:34
To: Ian Swett <[e-mail]>; Swindells, Thomas (Nokia - GB/Cambridge, UK) <[e-mail]>
Cc: Magnus Westerlund <[e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>; IETF QUIC WG <[e-mail]>; Dmitri Tikhonov <[e-mail]>
Subject: RE: Idea for packet numbers

Hi Ian, Thomas,

From: QUIC [mailto:[e-mail]] On Behalf Of Ian Swett
Sent: Tuesday, July 25, 2017 8:25 AM
To: Swindells, Thomas (Nokia - GB/Cambridge, UK)
Cc: Magnus Westerlund; Mikkel Fahnøe Jørgensen; IETF QUIC WG; Dmitri Tikhonov
Subject: Re: Idea for packet numbers

Some thoughts.

1) Sending packet numbers in order is not required, but the farther out of order packets get, the more acks the receiver is going to send, the larger they'll be, and the more complex loss detection is.  In particular, you won't be able to rely on QUIC's packet numbers being in time order.  TLDR; It's easier to send packets in order than it is to correctly deal with the implications of sending them out of order.
<snip>
[ACM]
Although this thread is on longer packet numbers,
I think it’s worth pointing out that
routine reordering at the Sender would have
implications for the single-bit alternate marking
(Spin-bit) approach. The boundary between
packets marked “0” and “1” would not be reliable;
there would appear to be very short RTTs along with longer RTTs:

  ... 0 0 0 1 1 0 1 1 1 1 1 ...
            ^ ^
   ^ = reordered
The single bit doesn’t have enough info to
restore order. Avoid reordering if possible.

Al