Re: spin bit in QUIC: troubleshooting

["Brian Trammell (IETF)" <[e-mail]>]

hi Gorry, Piotr, all,

> On 15 Nov 2017, at 14:40, Gorry Fairhurst <[e-mail]> wrote:
> 
> I think (even pathological) reordering would be largely undetected with 1-bit. Since in thsi case, the bit simply flips 1->0 and 0->1,
> 
> With 2 bits the first flip is 0->1 and then the next RTT , the flip is 1->2, then re-ordering of the spin may become detectable. It's not perfect, but you may see some pathologies for low additional cost.
> 
> ACK visibility is needed for some of the things below.

Only for RTX as far as I can tell, and RTX works fundamentally differently in QUIC, so I'm not sure it's useful; see below.

> 
> Gorry
> 
> On 15/11/2017, 13:59, Piotr Galecki 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

This is the spin bit (whether one bit, or two bits as gorry suggests)

>> * TCP segment loss
>> * TCP segment retransmissions

RTX is only really interesting for detecting loss, so I'll treat these as the same.

For upstream loss (loss occurring before the observation point), you can do one-point measurement and just look at the packet numbers, which (absent rebinding) go up by one per packet. (Note that this is a current feature of v1, not an invariant, so if we decide we really want one-point passive upstream loss measurement we should state that packet number increment-by-one behavior is invariant, either now or later.

For two-point loss, you can compare the packet number sequence, as you can sequence numbers in TCP.

>> * TCP segment out-of-order

A two-bit spin does this. Network reordering can also be detected by looking at the packet numbers; indeed, this is *easier* than doing reordering detection than with TCP sequence numbers since a QUIC RTX uses a new packet number. Same caveats apply to packet number increment-by-one behavior as above.

If we want reordering detection without adding increment-by-one to the packet number invariants, then the two-bit spin is a good way to do that IMO.

Cheers,

Brian


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