Subject: RE: spin bit in QUIC

From: <[email-masked]>
Date: Wed, 15 Nov 2017 08:54:23 +0000

Hi Al,

It's a good catch. My point is to have room for it in the invariant to address the ossification concern.

Emile

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:[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
>
> Thanks for clarifying Emile.
>
> 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)
>
> It seems a simplistic approach on one hand but an invariant on the 
> long term.
>
> 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
>
> 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
>
> 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.
>

_________________________________________________________________________________________________________________________

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: Mirja Kühlewind <[email-masked]>
Date: Wed, 15 Nov 2017 18:40:50 +0800

Hi all,

we use two bits in ConEx for congestion exposure (however, that’s in an IPv6 option that has its own (deployment) problems; see rfc7837). The same scheme can be directly applied in QUIC. See also rfc7713 that describes the abstract mechanisms behind this; however, note that this was designed for congestion-based policing, but it also provides a really nice measurement signal, especially when you can’t rely on knowledge about retransmissions (which is the way congestion is measured in TCP today). Just as some background information the mechanisms that could be applied here.

Mirja

> Am 15.11.2017 um 16:54 schrieb [email-masked]:
> 
> Hi Al,
>