Re: spin bit in QUIC: troubleshooting

[Ian Swett <[e-mail]>]

Thanks for clarifying Emile.

On Tue, Nov 14, 2017 at 1:06 PM, <[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.
>
> It seems a simplistic approach on one hand but an invariant on the long
> term.
>
>
>
> Regards
>
> Emile
>
>
>
>
>
> *De :* Ian Swett [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]> 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.
>
>