Re: Idea for packet numbers

[Ian Swett <[e-mail]>]

Agreed Al, but as long as the packet number(or a portion of it) is exposed,
the middlebox can easily detect the reordering and realize where the real
edge is.  If it wasn't exposed, it has to use some heuristics and do some
filtering(ie: it seems unlikely the RTT decreased from 40 milliseconds to
100 microseconds) to filter out false edges.

On Tue, Jul 25, 2017 at 10:33 AM, MORTON, ALFRED C (AL) <[e-mail]>
wrote:

> 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
>
>
>
>
>