Re: spin bit in QUIC: troubleshooting

[Spencer Dawkins at IETF <[e-mail]>]

Speaking as a curious individual,

On Thu, Nov 16, 2017 at 6:54 AM, Martin Duke <[e-mail]>
wrote:

> Packet numbers are unencrypted and monotonically increasing. It is
> therefore relatively straightforward to measure reordering between any two
> points in the network if you have instruments there.
>

And that's certainly the way carriers were monitoring large networks when I
was working in that space in the mid-2000s. It's also the direction I see
in recent IPPM docs I've shepherded, IIUC.

Monitoring at one point in the network would be awesome, but it would be a
pleasant surprise if operators are doing it now.

Spencer


>
> On Tue, Nov 14, 2017 at 9:59 PM, Piotr Galecki <piotr_galecki@
> affirmednetworks.com> wrote:
>
>> How would a network probe be able to measure the level of packet
>> reordering in QUIC stream with only a spin bit?
>>
>> I'm asking because one of the common techniques to diagnose network issues
>> is to insert a probe in different points in the network and measure:
>> * RTT
>> * TCP segment loss
>> * TCP segment retransmissions
>> * TCP segment out-of-order
>> as a few basic data points.
>> With measurements in point A and point B one can determine for example if
>> a network device is misordering packets.
>>
>> -Piotr
>>
>> -----Original Message-----
>> From: QUIC [mailto:[e-mail]] On Behalf Of Gorry Fairhurst
>> Sent: Wednesday, November 15, 2017 12:48 AM
>> To: MORTON, ALFRED C (AL) <[e-mail]>
>> Cc: Ian Swett <[e-mail]>; QUIC WG <[e-mail]>;
>> [e-mail]
>> Subject: Re: spin bit in QUIC: troubleshooting
>>
>> As I said at the mic: I think the spin-bit analysis was helpful, thanks.
>>
>> I can see how spin-bit is really useful to get basic diagnostics of RTT
>> if it can be relied to be present in every packet. (It is important to
>> measure latency within the network).
>>
>> There are places where 1-bit gives restricted value, and using more would
>> help: My additional comment at the Mic related to how much extra would be
>> the gain from an additional one or two bits?
>>
>> In particular, I'd like to see a method that can let me detect some loss
>> patterns and measure reordering, at least I think it is important to know
>> and measure when there is small-scale reordering <3.
>>
>> A suggestion:is to use a 2-bit counter for the spin (
>> 00->01->10->11->00), that would help detect these path anomlies.
>>
>> Gorry
>>
>> On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote:
>> >
>> > I’d like to offer support for Spin Bit (and one or two
>> >
>> > bits for management if they can be justified quickly) in v1.
>> >
>> > On this topic of more bits,
>> >
>> > asking further clarification from Emile, below [ACM].
>> >
>> > Al
>> >
>> > *From:*QUIC [mailto:[e-mail]] *On Behalf Of *Ian Swett
>> > *Sent:* Tuesday, November 14, 2017 4:21 PM
>> > *To:* [e-mail]
>> > *Cc:* QUIC WG
>> > *Subject:* Re: spin bit in QUIC: troubleshooting
>> >
>> > Thanks for clarifying Emile.
>> >
>> > On Tue, Nov 14, 2017 at 1:06 PM, <[e-mail]
>> > <mailto:[e-mail]>> wrote:
>> >
>> > Hi Ian,
>> >
>> > It was suggested in the latest discussion on the RTT design team
>> > mailing list to have one bit for packet lost, one for latency (spin
>> > bit or eq.) and one for congestion.
>> >
>> > */[ACM] /* There may be some overlap with ECN and « one bit for
>> > congestion ».
>> >
>> > Did you also consider this dependency, Emile ? (I’m echoing a hallway
>> > discussion)
>> >
>> > It seems a simplistic approach on one hand but an invariant on the
>> > long term.
>> >
>> > Regards
>> >
>> > Emile
>> >
>> > *De :*Ian Swett [mailto:[e-mail]
>> > <mailto:[e-mail]>] *Envoyé :* mardi 14 novembre 2017 22:51
>> > *À :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin bit in
>> > QUIC: troubleshooting
>> >
>> > What would the other bit or two be used for?  If there is no
>> > standardized use of those bits in v1, then I believe we should wait to
>> > reserve them when their usage is defined, given we'd need a version
>> > bump to specify how they were being used.  At the moment, the
>> > management use case is not competing with anyone else for bits in the
>> > short header.
>> >
>> > On Tue, Nov 14, 2017 at 5:14 AM, <[e-mail]
>> > <mailto:[e-mail]>> wrote:
>> >
>> > Hi
>> >
>> > Last week Orange experienced a fallback of QUIC to TCP on one of its
>> > networks. The issues were not visible in QUIC traffic. The
>> > troubleshooting was made using TCP packets information. This is not
>> > sustainable on the long term when numerous applications using
>> > different versions of QUIC will stop to fallback to TCP.
>> >
>> > Based on the exchange we had in the RTT design team and in today
>> > meeting , it sounds reasonable to reserve at least 2 bits (ideally 3
>> > bits as discussed in the design team) for manageability in the QUIC
>> > invariants and to start experimenting the spin bit in QUIC V1.
>> >
>> > Regards
>> >
>> > Emile
>> >
>> > ______________________________________________________________________
>> > ___________________________________________________
>> >
>> > Ce message et ses pieces jointes peuvent contenir des informations
>> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> > exploites ou copies sans autorisation. Si vous avez recu ce message
>> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> que les pieces jointes. Les messages electroniques etant susceptibles
>> d'alteration, Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>> >
>> > This message and its attachments may contain confidential or
>> > privileged information that may be protected by law; they should not be
>> distributed, used or copied without authorisation.
>> > If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> > As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> > Thank you.
>> >
>> > ______________________________________________________________________
>> > ___________________________________________________
>> >
>> > Ce message et ses pieces jointes peuvent contenir des informations
>> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> > exploites ou copies sans autorisation. Si vous avez recu ce message
>> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> que les pieces jointes. Les messages electroniques etant susceptibles
>> d'alteration, Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>> >
>> > This message and its attachments may contain confidential or
>> > privileged information that may be protected by law; they should not be
>> distributed, used or copied without authorisation.
>> > If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> > As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> > Thank you.
>> >
>>
>
>