Subject: RE: spin bit in QUIC: troubleshooting

From: <[email-masked]>
Date: Tue, 14 Nov 2017 10:14:10 +0000

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.

---

From: Ian Swett <[email-masked]>
Date: Tue, 14 Nov 2017 09:50:56 -0500

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, <[email-masked]> 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
>
>
>

---

From: Roni Even <[email-masked]>
Date: Tue, 14 Nov 2017 15:26:35 +0000

I think that latency is what we need right now.
Once we understand more about quic and packet loss (will ECN be used reducing packet loss) and other functionality we can see what else is needed. This may be done in next version using variants.
Roni

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: יום ג 14 נובמבר 2017 16:51
To: [email-masked]
Cc: QUIC WG
Subject: 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, <[email-masked]<mailto:[email-masked]>> wrote:
Hi

Regards
Emile

Thank you.

---

From: Marcus Ihlar <[email-masked]>
Date: Tue, 14 Nov 2017 16:20:39 +0000

+1 on Ronis statement below. 
Let us begin with latency, which is the most crucial component to have in place. 
As V1 gets deployed we will get a better understanding of what else might be needed. 

> On 14 Nov 2017, at 23:27, Roni Even <[email-masked]> wrote:
>

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 14 Nov 2017 16:54:07 +0000

+1

Latency is the most crucial component needed in Quic version 1

Also considering the fact that QUIC will be either most likely adopted in 3GPP for 5G SBA

and the majority of the traffic in 5G networks QUIC (per Georg Mayer mail on those points)

Operators will have to make sure to keep the latency really low in 5G networks and they

will be measured on latency.

/Sal

From: QUIC [mailto:[email-masked]] On Behalf Of Marcus Ihlar
Sent: den 14 november 2017 17:21
To: Roni Even <[email-masked]>
Cc: Ian Swett <[email-masked]>; QUIC WG <[email-masked]>; [email-masked]
Subject: Re: spin bit in QUIC: troubleshooting

On 14 Nov 2017, at 23:27, Roni Even <[email-masked] <mailto:[email-masked]> > wrote:

Roni

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: יום ג 14 נובמבר 2017 16:51
To: [email-masked] <mailto:[email-masked]> 
Cc: QUIC WG
Subject: Re: spin bit in QUIC: troubleshooting

On Tue, Nov 14, 2017 at 5:14 AM, <[email-masked] <mailto:[email-masked]> > wrote:

Hi

Regards

Emile

---

From: <[email-masked]>
Date: Tue, 14 Nov 2017 18:06:20 +0000

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.
It seems a simplistic approach on one hand but an invariant on the long term.

Regards
Emile

De : Ian Swett [mailto:[email-masked]]
Envoyé : mardi 14 novembre 2017 22:51
À : STEPHAN Emile IMT/OLN
Cc : QUIC WG
Objet : Re: spin bit in QUIC: troubleshooting

Regards
Emile

Thank you.

---

From: Ian Swett <[email-masked]>
Date: Tue, 14 Nov 2017 16:20:50 -0500

Thanks for clarifying Emile.

On Tue, Nov 14, 2017 at 1:06 PM, <[email-masked]> 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.
>
> *De :* Ian Swett [mailto:[email-masked]]
> *Envoyé :* mardi 14 novembre 2017 22:51
> *À :* STEPHAN Emile IMT/OLN
> *Cc :* QUIC WG
> *Objet :* Re: spin bit in QUIC: troubleshooting
>
>
>

---

From: "DRUTA, DAN" <[email-masked]>
Date: Wed, 15 Nov 2017 01:10:46 +0000

I will add my support for the inclusion of the spin bit into V1 and make a few more points.
Considering that the design team analysis concluded that the spin bit does not add any additional privacy risk and the very specific need addressing latency has been documented and validated by a large number of WG members, I believe the QUIC working group has a unique opportunity to show that we can design protocols that are efficient, privacy sensitive and network management friendly.
This particular design, while not perfect does have the biggest benefit relative to the risks and it should be adopted from the beginning.

Best Regards,
Dan

On Nov 15, 2017, at 5:21 AM, Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Nov 14, 2017 at 1:06 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ian,

Regards
Emile

De : Ian Swett [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 14 novembre 2017 22:51
À : STEPHAN Emile IMT/OLN
Cc : QUIC WG
Objet : Re: spin bit in QUIC: troubleshooting

Regards
Emile

Thank you.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Wed, 15 Nov 2017 01:55:05 +0000

+1 for the reasons stated up-thread as well as yesterday at the mic.

(And thanks Brian for the great analysis on the privacy implications.)

On 15/11/2017, 09:10, "QUIC on behalf of DRUTA, DAN" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Regards
Emile

Regards
Emile

Thank you.

Thank you.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 15 Nov 2017 01:51:54 +0000

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:[email-masked]] On Behalf Of Ian Swett
Sent: Tuesday, November 14, 2017 4:21 PM
To: [email-masked]
Cc: QUIC WG
Subject: Re: spin bit in QUIC: troubleshooting

On Tue, Nov 14, 2017 at 1:06 PM, <[email-masked]<mailto:[email-masked]>> 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)

Regards
Emile

Regards
Emile

Thank you.

Thank you.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 15 Nov 2017 13:48:24 +0800

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:
> *From:*QUIC [mailto:[email-masked]] *On Behalf Of *Ian Swett
> *Sent:* Tuesday, November 14, 2017 4:21 PM
> *To:* [email-masked]
> *Cc:* QUIC WG
> *Subject:* Re: spin bit in QUIC: troubleshooting
>
> On Tue, Nov 14, 2017 at 1:06 PM, <[email-masked] 
> <mailto:[email-masked]>> 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 ».
>
> *De :*Ian Swett [mailto:[email-masked] <mailto:[email-masked]>]
> 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, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi
>
> 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
>

---

From: Piotr Galecki <[email-masked]>
Date: Wed, 15 Nov 2017 05:59:51 +0000

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:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: Wednesday, November 15, 2017 12:48 AM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: Ian Swett <[email-masked]>; QUIC WG <[email-masked]>; [email-masked]
Subject: Re: spin bit in QUIC: troubleshooting

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.

Gorry

On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote:
> *De :*Ian Swett [mailto:[email-masked] 
> <mailto:[email-masked]>] *Envoyé :* mardi 14 novembre 2017 22:51 
> *À :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin bit in 
> QUIC: troubleshooting
>
> ______________________________________________________________________
> ___________________________________________________
>   
> 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.
> ______________________________________________________________________
> ___________________________________________________
>   
> 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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 15 Nov 2017 14:40:08 +0800

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.

Gorry

On 15/11/2017, 13:59, Piotr Galecki wrote:
> To: MORTON, ALFRED C (AL)<[email-masked]>
> Cc: Ian Swett<[email-masked]>; QUIC WG<[email-masked]>; [email-masked]
> 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.
>
>> On Tue, Nov 14, 2017 at 1:06 PM,<[email-masked]
>> On Tue, Nov 14, 2017 at 5:14 AM,<[email-masked]

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 15 Nov 2017 07:03:21 +0000

good way to measure the reordering with 1 or 2 bits.
In addition, to answer the previous question, draft-ietf-ippm-alt-mark suggests how to use 1 or 2 bits for packet loss and  RTT calculation.

Giuseppe

-----Messaggio originale-----
Da: QUIC [mailto:[email-masked]] Per conto di Gorry Fairhurst
Inviato: mercoledì 15 novembre 2017 07:40
A: Piotr Galecki
Cc: Ian Swett; QUIC WG; MORTON, ALFRED C (AL); [email-masked]
Oggetto: Re: spin bit in QUIC: troubleshooting

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,

Gorry

>> invariants and to start experimenting the spin bit in QUIC V1.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 15 Nov 2017 15:12:43 +0800

hi Gorry, Piotr, all,

> On 15 Nov 2017, at 14:40, Gorry Fairhurst <[email-masked]> wrote:
> 
> 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.
> 

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.

>> is to insert a probe in different points in the network and measure:

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

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

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 15 Nov 2017 07:34:34 +0000

+1 for adding support for spin-bit(s) in V1. For monitoring and diagnostics in IaaS scenario it is quite useful to be able to measure latency fluctuations and reorder/loss.

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Wednesday, November 15, 2017 3:13 PM
To: Gorry Fairhurst <[email-masked]>
Cc: Piotr Galecki <[email-masked]>; Ian Swett <[email-masked]>; QUIC WG <[email-masked]>; Al Morton <[email-masked]>; [email-masked]
Subject: Re: spin bit in QUIC: troubleshooting

hi Gorry, Piotr, all,

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

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

Cheers,

Brian

>>> Did you also consider this dependency, Emile ? (I’m echoing a 
>>> hallway
>>> discussion)
>>> 
>>> <mailto:[email-masked]>] *Envoyé :* mardi 14 novembre 2017 
>>> 22:51 *À :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin 
>>> bit in
>>> QUIC: troubleshooting
>>> 
>>> 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.
>>> 
>>> ____________________________________________________________________
>>> __ ___________________________________________________
>>> 
>>> 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.
>>> 
>>> ____________________________________________________________________
>>> __ ___________________________________________________
>>> 
>>> 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.
>>>

---

From: Martin Duke <[email-masked]>
Date: Wed, 15 Nov 2017 14:54:49 -0800

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.

On Tue, Nov 14, 2017 at 9:59 PM, Piotr Galecki <
[email-masked]> wrote:

> How would a network probe be able to measure the level of packet
> reordering in QUIC stream with only a spin bit?
>
> 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?
>
> patterns and measure reordering, at least I think it is important to know
> and measure when there is small-scale reordering <3.
>
> > 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.
> >
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> > 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.
> >
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Nov 2017 08:28:45 +0800

Speaking as a curious individual,

> 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:
>
>> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> que les pieces jointes. Les messages electroniques etant susceptibles
>> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> que les pieces jointes. Les messages electroniques etant susceptibles

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 08:37:29 +0000

+1

De : Salvatore Loreto [mailto:[email-masked]]
Envoyé : mercredi 15 novembre 2017 00:54
À : Marcus Ihlar; Roni Even
Cc : Ian Swett; QUIC WG; STEPHAN Emile IMT/OLN
Objet : RE: spin bit in QUIC: troubleshooting

+1

/Sal

From: QUIC [mailto:[email-masked]] On Behalf Of Marcus Ihlar
Sent: den 14 november 2017 17:21
To: Roni Even <[email-masked]<mailto:[email-masked]>>
Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: spin bit in QUIC: troubleshooting

On 14 Nov 2017, at 23:27, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
I think that latency is what we need right now.
Once we understand more about quic and packet loss (will ECN be used reducing packet loss) and other functionality we can see what else is needed. This may be done in next version using variants.
Roni

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: יום ג 14 נובמבר 2017 16:51
To: [email-masked]<mailto:[email-masked]>
Cc: QUIC WG
Subject: Re: spin bit in QUIC: troubleshooting

Regards
Emile

Thank you.

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 13:51:54 +0000

Speaking as an operator,

As it turns out, we do use dichotomy  every day for troubleshooting, moving a single capture point around where possible.
For this reason, we are very anxious to see the necessary clear fields land in QUIC to keep doing this.
Isabelle HAMCHAOUI
Orange<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%0F%04D%0A%07q%10-%1D%19%1C%0C%17%3FY%27%0AM%01%0B%06%3E%14-%07%05%09%0C%00%29Y%27%0AM%0E%17%13%22%16%26%1D%15%04%00%11%23%18o%0D%13U%03%00>/IMT<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%06%1C%06%06%5E%23%00%7E%0F%04D%0A%07q%10-%1D%19%1C%0C%17%3FY%27%0AM%01%0B%06%3E%14-%07%05%09%0C%00%29Y%27%0AM%0E%17%13%22%16%26%1D%15%04%00%11%23%18o%0D%13U%03%00>/OLN<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%06%1C%06I%1D9H%2C%05%1E%0BI%1D9H%25%1D%5C%07%10O%29%1B7%00%04%01%00%01%60%11+T%19%06%11%00-%1B-%1C%11%01%17%17%60%11+T%16%1A%04%1C%2F%107%0C%1C%0D%06%1D%21Y%27%0AM%0E%17>/WTC<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%1E%04%0BI%1D9H%2C%05%1ED%0A%07q%1A%2F%07%13D%0A%07q%137E%1F%1DX%17%22%01*%1D%19%0D%16%5E%28%16%7E%00%1E%1C%17%13%22%1B6%08%19%1A%00%5E%28%16%7E%0F%02%09%0B%11%29%01%26%05%15%0B%0A%1F%60%11+T%16%1A>/IEE
tél. +33 2 96 07 14 92
Mob. +33 6 85 37 02 92
[email-masked]<mailto:[email-masked]>

De : Spencer Dawkins at IETF [mailto:[email-masked]]
Envoyé : jeudi 16 novembre 2017 01:29
À : Martin Duke
Cc : Piotr Galecki; [email-masked]; Ian Swett; QUIC WG; MORTON, ALFRED C (AL); STEPHAN Emile IMT/OLN
Objet : Re: spin bit in QUIC: troubleshooting

On Thu, Nov 16, 2017 at 6:54 AM, Martin Duke <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
How would a network probe be able to measure the level of packet reordering in QUIC stream with only a spin bit?

-Piotr

-----Original Message-----
From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gorry Fairhurst
Sent: Wednesday, November 15, 2017 12:48 AM
To: MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>>
Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: spin bit in QUIC: troubleshooting

Gorry

On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote:
> *From:*QUIC [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Ian Swett
> *To:* [email-masked]<mailto:[email-masked]>
> *Cc:* QUIC WG
> On Tue, Nov 14, 2017 at 1:06 PM, <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> Hi Ian,
>
> *De :*Ian Swett [mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>] *Envoyé :* mardi 14 novembre 2017 22:51
> On Tue, Nov 14, 2017 at 5:14 AM, <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> Hi
>