Re: [EToSat] QUIC Spin and Loss Bits

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 06 February 2020 17:22 UTC

MIME-Version: 1.0
References: <BL0PR11MB3394C91C3F6D3C99CF5461FC901D0@BL0PR11MB3394.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB3394C91C3F6D3C99CF5461FC901D0@BL0PR11MB3394.namprd11.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 06 Feb 2020 11:21:55 -0600
Message-ID: <CAKKJt-c5KYfvwQ2qtVO678hURCQ_SGaWwFjqkNEGLMz1hLvKJg@mail.gmail.com>
To: "Border, John" <John.Border@hughes.com>
Cc: "etosat@ietf.org" <etosat@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000006f708059deb843c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/s7NlHc-dy1OR_fJpeL0naf4JlvY>
Subject: Re: [EToSat] QUIC Spin and Loss Bits
Precedence: list

Hi, John,

On Thu, Feb 6, 2020 at 6:17 AM Border, John <John.Border@hughes.com> wrote:

>
>
> Something to think about…  How do network operators incentivize the
> servers and clients to deploy these tools?
>

That's an interesting question.

FWIW, PANRG has been kicking
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ around
for a bit (the current state is RG Last Call), and
https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-07#section-2 is
a summary of what we've learned about deployment. The subsections are
short, and several seem directly applicable to your question.*

What I kind of expect to happen, based on no inside information, is that
servers and clients will (continue to?) shoot for acceptable performance
using end-to-end mechanisms, which will work most of the time (see gQUIC
deployments today), and will not work some of the time (see your/Gorry's
testing), and then decide how much they care about the cases that don't
work.

The awkward part of this, is that because we chartered HTTP/3-over-QUIC,
either endpoints can decide their performance sucks and failover to
HTTP/2-over-TCP, which you can handle now, or operators get tired of
receiving complaints, and block QUIC, forcing the same failover to
HTTP/2-over-TCP.

But that would make me sad. More to the point, it's basically saying that
we can't use QUIC for new application protocols that don't have a failover
to non-QUIC transport, which would make other people sad as well.

So I'm glad you're asking this question now. If I might make a suggestion -
the newly chartered MOPS working group had a session on "troubleshooting
QUIC" at IETF 106 (minutes at
https://datatracker.ietf.org/doc/minutes-106-mops/, presentation at
https://datatracker.ietf.org/meeting/106/materials/slides-106-mops-quic-and-streaming-00)
led by Igor Lubashev and Emile Stephan, with good interest from the MOPS
participants**. It's likely that involving these folks earlier, rather than
later, would be productive.

IMO, of course.

Best,

Spencer

* full disclosure, I ended up as editor for this draft
** full disclosure, I'm also a MOPS participant

[EToSat] QUIC Spin and Loss Bits Border, John
Re: [EToSat] QUIC Spin and Loss Bits Spencer Dawkins at IETF