Subject: [EToSat] QUIC Spin and Loss Bits

From: "Border, John" <[email-masked]>
Date: Thu, 6 Feb 2020 12:17:32 +0000

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Feb 2020 11:21:55 -0600

Hi, John,

On Thu, Feb 6, 2020 at 6:17 AM Border, John <[email-masked]> 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