Subject: Re: [QUIC] Network Path Requirements for QUIC

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 1 Jul 2016 09:18:36 +0000

On 2016-06-30, at 18:34, Ted Hardie <[email-masked]> wrote:
> 
> On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars <[email-masked] <mailto:[email-masked]>> wrote:
> (And - pet peeve - there is really no need for binding timeouts for TCP or UDP to begin with. No binding needs to be timed out until the middlebox runs out of memory, because as long as there are sufficient resources, why bother managing all these timeouts? <snip>)
> 
> If I understand this correctly, this is largely because many of  these are NAT+FW boxes which combine the binding and the firewall permission; leaving them up for long periods of time leaves the pinhole up.  If you really relied on state exhaustion, it might never happen at all for small networks.  Eliminating the firewall permission to receive traffic and leaving the binding to send would be odd, so they don't.

Well, they could leave the binding up and check whether inbound traffic after idle still elicits response traffic. But I think I took us down the rathole of building a better mousetrap (how's that for an analogy :-)

Lars

> 
> Joe H. might well be able to get you better and fersher data, but that's why I think the timers were put in in the first place.
> 
> Ted
> 
> 
> 
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 1 Jul 2016 11:18:53 +0000

Hi,

On 2016-06-30, at 18:42, Joe Hildebrand (jhildebr) <[email-masked]> wrote:
> On Jun 30, 2016, at 9:21 AM, Eggert, Lars <[email-masked]> wrote:
>> On 2016-06-30, at 16:46, DRUTA, DAN <[email-masked]> wrote:
>>> What's important is to understand and capture the reasons why IT Administrators are blocking UDP. Some are as you pointed out not related to the technology but we need to make sure they get the right level of manageability with QUIC in order troubleshooting legitimate traffic and prevent attacks.
>> 
>> again: why? We're talking about less than 10% of the paths, and HTTPS over TCP readily available as an alternative on those paths, supposedly with all the manageability that IT admins need.
> 
> We're talking about less than 10% of the paths that were measured by one experiment.  I don't yet know how reproducible that is.

fair point. I hope we hear from Akamai and others who are experimenting with QUIC currently.

>  Again, it's 100% of the flows on my network, and on that of many other enterprise networks where I have deployed software in the past.

I don't debate that - you're part of the less-than-10% though.

> I guarantee that we will deploy new software for our firewall if it's possible to do so in a way that we don't have to update for every newly-popular version number that someone in the QUIC world decides to deploy.

That's both encouraging and discouraging. Encouraging, because better software is better. Discouraging because one of the stated strong points of QUIC is rapid deployment of improved versions, and limiting future evolvability of part of the protocol because "corporate middleboxes need to do stuff" isn't a really good starter here.

> Mostly, I would like to see the assumptions that folks are making about how the path might interact with the bits that are already explicitly exposed to the path by the current protocol be discussed, then written down.

I'm with you on that. Writing down assumptions makes design decisions clearer.

> 
>> I'd be open to the WG reviewing concrete proposals someone may have in this space once the WG is underway, but I wouldn't want to see charter text making it a requirement for QUIC to do anything about such paths, since we really don't know what fulfilling this requirement may actually entail.
> 
> Brian's proposed text here:
> 
> https://github.com/IETF-QUIC/Charter/pull/14/files
> 
> says "This work will consider deployability, manageability and diagnosability of the wire format, including how the wire format will be processed by devices on path".  I don't think that makes doing anything for the path required, but it does make it possible to have the conversation.  If we're worried about this language requiring changes to the protocol, rather than allowing for the conversation, we can of course continue to tweak the language.

That's at least my personal worry - that text is pretty broad. I'd be happier with a statement along the lines you stated above, i.e., that the WG may document assumptions about how boxes along the path might interact with exposed protocol information. That - to me - makes it clearer that it isn't a goal to make protocol changes in the hopes of making it comply with whatever enterprise IT admins may define as policy, based on the knobs their middlebox software is at the moment exposing.

> From a previous message of yours:
> 
>> And - pet peeve - there is really no need for binding timeouts for TCP or UDP to begin with. No binding needs to be timed out until the middlebox runs out of memory, because as long as there are sufficient resources, why bother managing all these timeouts?
> 
> One of the reasons people give for this is the concern that traffic will be allowed in from the outside to boxes and applications that are no longer expecting the traffic.  Since they believe that many older UDP protocols don't have adequate security measures in place to authenticate, authorize, or sessionize traffic, they just block it all except for the protocols where they do deeper inspection, such as DNS.  It is not because these administrators are idiots, or because they have misconfigured their boxes unintentionally.

I didn't mean to imply that - they use the knobs they have. But there are other ways to mitigate the attack surface here, such as rate limiting inbound traffic on idle bindings, only fully activating idle bindings after outbound traffic indicates an active listener, etc.

> Many of the folks that block UDP *do* update their firewall software often, and do review their security stance on blocked protocols periodically.  They will want their users to be able to take advantage of the benefits of QUIC, so they will have incentives to do the review.  We need to at least provide them with the tools to do this review, such as security considerations that tell an administrator how to continue to protect their network from unknown UDP protocols while allowing QUIC.

But "we need to at least provide the tools" again sounds like the intent here is that QUIC will need to change to satisfy some currently under-defined requirements, rather than documenting assumptions about how boxes along the path might interact with exposed protocol information (my attempt to summarize what you wrote above).

Personally, I'd like to understand in much more detail what these "tools to do this review" are and how they would change the current QUIC protocol, before I'd feel comfortable adding this to the charter as anything more than a thought experiment the WG may undertake (and, do we really need this in the charter? WGs can always discuss work related to their chartered work). Once we have some clarity here - maybe also because PLUS will have gotten chartered and we've gained some understanding through that effort - a future version of QUIC could decide to incorporate those changes.

Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 1 Jul 2016 07:52:04 -0500

So, I'm not typing much, as folks prepare for the BOF, but I am current on
what other people are typing ... so, a couple of questions ...

On Fri, Jul 1, 2016 at 6:18 AM, Eggert, Lars <[email-masked]> wrote:

> >>> What's important is to understand and capture the reasons why IT
> Administrators are blocking UDP. Some are as you pointed out not related to
> the technology but we need to make sure they get the right level of
> manageability with QUIC in order troubleshooting legitimate traffic and
> prevent attacks.
> >>
> >> again: why? We're talking about less than 10% of the paths, and HTTPS
> over TCP readily available as an alternative on those paths, supposedly
> with all the manageability that IT admins need.
> >
> > We're talking about less than 10% of the paths that were measured by one
> experiment.  I don't yet know how reproducible that is.
>
> >  Again, it's 100% of the flows on my network, and on that of many other
> enterprise networks where I have deployed software in the past.
>
> > I guarantee that we will deploy new software for our firewall if it's
> possible to do so in a way that we don't have to update for every
> newly-popular version number that someone in the QUIC world decides to
> deploy.
>
> That's both encouraging and discouraging. Encouraging, because better
> software is better. Discouraging because one of the stated strong points of
> QUIC is rapid deployment of improved versions, and limiting future
> evolvability of part of the protocol because "corporate middleboxes need to
> do stuff" isn't a really good starter here.

One of the reasons I was given for not just sending QUIC to the ISE so
there's an RFC that describes what's deployed, was the desire to support
new functionality without bumping a protocol version number (an easy way to
evolve the protocol when you control the QUIC implementation at both
endpoints and centralize software development, but one that doesn't scale
to support evolving protocols the way we do that, at IETF).

The current charter talks about both versioning and option negotiation.

I had assumed, perhaps incorrectly, that most experimentation would make
use of option negotiation, and bumping the version number would be
possible, but relatively rare. The first two extensions I saw proposed were
multipath and FEC, and I understood both of those to be possible to
implement using option negotiation.

Am I misunderstanding what the intention is here?

Thanks,

Spencer

> > Mostly, I would like to see the assumptions that folks are making about
> how the path might interact with the bits that are already explicitly
> exposed to the path by the current protocol be discussed, then written down.
>
> >> I'd be open to the WG reviewing concrete proposals someone may have in
> this space once the WG is underway, but I wouldn't want to see charter text
> making it a requirement for QUIC to do anything about such paths, since we
> really don't know what fulfilling this requirement may actually entail.
> >
> > says "This work will consider deployability, manageability and
> diagnosability of the wire format, including how the wire format will be
> processed by devices on path".  I don't think that makes doing anything for
> the path required, but it does make it possible to have the conversation.
> If we're worried about this language requiring changes to the protocol,
> rather than allowing for the conversation, we can of course continue to
> tweak the language.
>
> That's at least my personal worry - that text is pretty broad. I'd be
> happier with a statement along the lines you stated above, i.e., that the
> WG may document assumptions about how boxes along the path might interact
> with exposed protocol information. That - to me - makes it clearer that it
> isn't a goal to make protocol changes in the hopes of making it comply with
> whatever enterprise IT admins may define as policy, based on the knobs
> their middlebox software is at the moment exposing.
>
> >> And - pet peeve - there is really no need for binding timeouts for TCP
> or UDP to begin with. No binding needs to be timed out until the middlebox
> runs out of memory, because as long as there are sufficient resources, why
> bother managing all these timeouts?
> >
> > One of the reasons people give for this is the concern that traffic will
> be allowed in from the outside to boxes and applications that are no longer
> expecting the traffic.  Since they believe that many older UDP protocols
> don't have adequate security measures in place to authenticate, authorize,
> or sessionize traffic, they just block it all except for the protocols
> where they do deeper inspection, such as DNS.  It is not because these
> administrators are idiots, or because they have misconfigured their boxes
> unintentionally.
>
> I didn't mean to imply that - they use the knobs they have. But there are
> other ways to mitigate the attack surface here, such as rate limiting
> inbound traffic on idle bindings, only fully activating idle bindings after
> outbound traffic indicates an active listener, etc.
>
> > Many of the folks that block UDP *do* update their firewall software
> often, and do review their security stance on blocked protocols
> periodically.  They will want their users to be able to take advantage of
> the benefits of QUIC, so they will have incentives to do the review.  We
> need to at least provide them with the tools to do this review, such as
> security considerations that tell an administrator how to continue to
> protect their network from unknown UDP protocols while allowing QUIC.
>
> But "we need to at least provide the tools" again sounds like the intent
> here is that QUIC will need to change to satisfy some currently
> under-defined requirements, rather than documenting assumptions about how
> boxes along the path might interact with exposed protocol information (my
> attempt to summarize what you wrote above).
>
> Personally, I'd like to understand in much more detail what these "tools
> to do this review" are and how they would change the current QUIC protocol,
> before I'd feel comfortable adding this to the charter as anything more
> than a thought experiment the WG may undertake (and, do we really need this
> in the charter? WGs can always discuss work related to their chartered
> work). Once we have some clarity here - maybe also because PLUS will have
> gotten chartered and we've gained some understanding through that effort -
> a future version of QUIC could decide to incorporate those changes.
>
> Lars
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Jul 2016 08:34:07 -0700

On Fri, Jul 1, 2016 at 2:18 AM, Eggert, Lars <[email-masked]> wrote:

> On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars <[email-masked]> wrote:
>
>> (And - pet peeve - there is really no need for binding timeouts for TCP
>> bother managing all these timeouts? <snip>)
>>
>
> If I understand this correctly, this is largely because many of  these are
> NAT+FW boxes which combine the binding and the firewall permission; leaving
> them up for long periods of time leaves the pinhole up.  If you really
> relied on state exhaustion, it might never happen at all for small
> networks.  Eliminating the firewall permission to receive traffic and
> leaving the binding to send would be odd, so they don't.
>
>
> Well, they could leave the binding up and check whether inbound traffic
> after idle still elicits response traffic.
>

Given that the risk here is partly that attack traffic would elicit
responses (/trigger memory overflows/allow the device to be owned/etc),
allowing the inbound traffic that would enable this check is exactly what
they're trying to limit.

> But I think I took us down the rathole of building a better mousetrap
> (how's that for an analogy :-)
>
> I can think of no better place to trap a rodent than in that rodent's
hole, but I can think of several places that would be better places to have
the "what should a firewall do, really?" conversation.  Perhaps over a beer
in Berlin we can discuss them.

Ted

> Lars
>
>
> Joe H. might well be able to get you better and fersher data, but that's
> why I think the timers were put in in the first place.
>
> Ted
>
>
>
>
>
>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 5 Jul 2016 21:03:09 +0000

> On Jul 1, 2016, at 5:18 AM, Eggert, Lars <[email-masked]> wrote:
> 

Which is why it's understandable that I'd want to talk about these issues.  I'll note that I'm not alone in having the problem, and there are probably lots of different networks involved even in the 10% that was measured.

> That's both encouraging and discouraging. Encouraging, because better software is better. Discouraging because one of the stated strong points of QUIC is rapid deployment of improved versions, and…

It could also provide a guideline for how to design the version negotiation in a slightly different way.

Anything that we expose to the path will ossify in the short term.  Planning for that, rather than fighting against human nature might get us further.

For example (note: here I'm proposing a protocol change, but not saying that this is something that we should do, just providing an example of the sort of discussion we might have), we could set the version number that is currently exposed to the path to a constant, to be used like the SPUD magic number.  We could then provide version negotiation inside the crypto boundary.  I bet this approach wouldn't meet the needs of load balancers, so more engineering would be required.

> That's at least my personal worry - that text is pretty broad. I'd be happier with a statement along the lines you stated above, i.e., that the WG may document assumptions about how boxes along the…

Can you propose text that you would find appropriate, please?

> I didn't mean to imply that - they use the knobs they have. But there are other ways to mitigate the attack surface here, such as rate limiting inbound traffic on idle bindings, only fully activati…

These sorts of approaches would need security analysis, which would likely only come after the approach had be thought through and documented.  If there are generic versions of these that we think might work, a potential PLUS working group might be a good place to get the analysis done.

> But "we need to at least provide the tools" again sounds like the intent here is that QUIC will need to change to satisfy some currently under-defined requirements, rather than documenting assumpti…

Later in that sentence, I said "such as security considerations".  The doc will certainly have to change, but whether the protocol will have to change will rely on what we learn in the discussion.

As to whether draft-wing-quic-network-req is under-defined, of course it is.  It's a -00 draft for a topic that hasn't had any public discussion yet.  It talks about the ways that people have treated TCP in the past, and I hope asks the question whether any of the things we've learned from TCP might be applied to QUIC. 

> Personally, I'd like to understand in much more detail what these "tools to do this review" are and how they would change the current QUIC protocol, before I'd feel comfortable adding this to the c…

I guess I'll repeat myself then:

- Is this traffic QUIC?  Can a firewall try to advantage it over all of the other UDP that I'm blocking or deep-queueing?

- Is this QUIC connection being initiated from inside the firewall?  Does it imply an intent-to-receive?

- Is this QUIC traffic coming in the firewall from outside related to a previous intent-to-receive?  Should the firewall allow it in because of that?

- Is this QUIC connection finished?  Can the firewall release the state it is holding?  If not, when?

- A firewall or application got some QUIC traffic I wasn't expecting, and am willing to return an error.  What do I do?

- A firewall or application got an ICMP related to a QUIC connection.  What do I do?

- (optional) A firewall or load balancer is releasing the state for this QUIC connection due to a timeout.  Should it tell anyone?

- (optional) Suppose QUIC got multi-path capabilities. Do all of the above still work when part of the connection is through a new firewall?

- As an application, my network connection changed.  What do I do?  If I do nothing, will the firewall on the new path just work?  Will it let me know that I need to do something to re-establish the connection?

That list seems pretty short.  We can argue over whether there needs to be more or less stuff on it.  Much of it just requires us writing down the assumptions that the protocol designers made.  Some of the discussion about questions like these may lead us to wanting to tweak the protocol slightly, but that's true of any discussion in a potential working group.

Some of the work that QUIC would need to do might be informed by things we learn about in a potential PLUS working group, but that doesn't mean that the working group shouldn't be responsible for having the conversation.

-- 
Joe Hildebrand

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 5 Jul 2016 16:43:53 -0700

A couple of things that were raised in this thread that Id like to clarify:

- As I wrote earlier, the 94% reachability in the client-server scenario
has been independently verified by WebRTC deployments, by measuring the
percentage of connections that go over a TURN server. This ends up being
~15%, which is makes sense given that it's p2p and therefore encounters ~2x
the number of middleboxes than client-server connections do.

- Calling the current QUIC deployment "one unrepeatable experiment" is
technically accurate, but doesn't really reflect the scale of things. Most
Chrome->Google traffic flows over QUIC, and that's a pretty massive and
diverse population.

- The network-requirements draft has two separable parts: (i) which
middlebox behaviors are important, and (ii) what information is necessary
for that middlebox behavior to be implemented.  (ii) makes no sense without
(i), and we do not have consensus on (i)... and that discussion should
happen elsewhere, not in the QUIC wg, since any of these considerations
ought to apply to *any* protocol over UDP, including WebRTC's SRTP/UDP or
SCTP/DTLS/UDP stacks, Tom Herbert's Transports-over-UDP stacks, and also
proprietary FaceTime, RTMFP, Skype, Xbox protocols.

More thoughts inline:

On Tue, Jul 5, 2016 at 2:03 PM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> Which is why it's understandable that I'd want to talk about these
> issues.  I'll note that I'm not alone in having the problem, and there are
> probably lots of different networks involved even in the 10% that was
> measured.
>
> Anything that we expose to the path will ossify in the short term.
> Planning for that, rather than fighting against human nature might get us
> further.
>
> For example (note: here I'm proposing a protocol change, but not saying
> that this is something that we should do, just providing an example of the
> sort of discussion we might have), we could set the version number that is
> currently exposed to the path to a constant, to be used like the SPUD magic
> number.  We could then provide version negotiation inside the crypto
> boundary.  I bet this approach wouldn't meet the needs of load balancers,
> so more engineering would be required.
>

I agree with Lars, but there's something else that's implicit in here which
I don't think we have a handle on. Which interactions are important to
describe? Personally, I don't think this is the right working group to have
that discussion, modulo the considerations that will happen organically
anyways (as I said, similar to what happened with MPTCP.) I still don't
think it's necessary to have that language in the charter to "protect" that
conversation. OTOH, I worry as Lars that leaving broad text will cause
folks to bring up various middlebox-related conversations that really
shouldn't be in this wg.

PLUS is a great place to have the conversation about which middlebox
interactions are important to describe; any outcomes of that wg will
naturally influence QUIC later.

> >> One of the reasons people give for this is the concern that traffic
> will be allowed in from the outside to boxes and applications that are no
> longer expecting the traffic.  Since they believe that many older UDP
> protocols don't have adequate security measures in place to authenticate,
> authorize, or sessionize traffic, they just block it all except for the
> protocols where they do deeper inspection, such as DNS.  It is not because
> these administrators are idiots, or because they have misconfigured their
> boxes unintentionally.
> >
> > I didn't mean to imply that - they use the knobs they have. But there
> are other ways to mitigate the attack surface here, such as rate limiting
> These sorts of approaches would need security analysis, which would likely
> only come after the approach had be thought through and documented.  If
> there are generic versions of these that we think might work, a potential
> PLUS working group might be a good place to get the analysis done.
>
> Later in that sentence, I said "such as security considerations".  The doc
> will certainly have to change, but whether the protocol will have to change
> will rely on what we learn in the discussion.
>

... and as I said earlier, that discussion should happen elsewhere, not in
the QUIC wg, since any of these considerations ought to apply to *any*
transport protocol.

As to whether draft-wing-quic-network-req is under-defined, of course it
> is.  It's a -00 draft for a topic that hasn't had any public discussion
> yet.  It talks about the ways that people have treated TCP in the past, and
> I hope asks the question whether any of the things we've learned from TCP
> might be applied to QUIC.
>
> - Is this traffic QUIC?  Can a firewall try to advantage it over all of
> the other UDP that I'm blocking or deep-queueing?
>
> - Is this QUIC traffic coming in the firewall from outside related to a
> previous intent-to-receive?  Should the firewall allow it in because of
> that?
>
> - A firewall or application got some QUIC traffic I wasn't expecting, and
> am willing to return an error.  What do I do?
>
> - (optional) A firewall or load balancer is releasing the state for this
> QUIC connection due to a timeout.  Should it tell anyone?
>
> - (optional) Suppose QUIC got multi-path capabilities. Do all of the above
> still work when part of the connection is through a new firewall?
>
> - As an application, my network connection changed.  What do I do?  If I
> do nothing, will the firewall on the new path just work?  Will it let me
> know that I need to do something to re-establish the connection?
>
> That list seems pretty short.  We can argue over whether there needs to be
> more or less stuff on it.  Much of it just requires us writing down the
> assumptions that the protocol designers made.  Some of the discussion about
> questions like these may lead us to wanting to tweak the protocol slightly,
> but that's true of any discussion in a potential working group.
>

I'll repeat myself on my response to your list from an earlier email in
this thread. Some of these questions will be raised naturally, simply
because it's unavoidable for a deployable protocol to engage with some of
these. Agreeing on a list of such behaviors however is problematic  on at
least two counts: (i) it needs consensus on which behaviors are important,
and (ii) QUIC is not the only protocol that will need to answer these
questions. This list applies to UDP-based transports, and as such, the
conversation belongs not just with one protocol.

As I've pointed out repeatedly in the past, you are trying to argue that
certain middlebox behaviors are important and should be addressed in
protocol design. I completely agree that we should have that conversation
at the IETF, but the venue has to be broader than the QUIC wg.

Some of the work that QUIC would need to do might be informed by things we
> learn about in a potential PLUS working group, but that doesn't mean that
> the working group shouldn't be responsible for having the conversation.

Having the same conversation in two places does not make sense. QUIC wg's
work will naturally be influenced by ones happening in PLUS or elsewhere
about extant middlebox behaviors. But deriving a list of such behaviors
should happen elsewhere.

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 5 Jul 2016 17:05:35 -0700

On Thu, Jun 30, 2016 at 9:42 AM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> experiment.  I don't yet know how reproducible that is.  Again, it's 100%
> of the flows on my network, and on that of many other enterprise networks
> where I have deployed software in the past.
>
> > My personal viewpoint is that I wouldn't want to complicate the protocol
> or even slightly weaken its security for such a small subset of paths (some
> of which may end up unblocking UDP port 443 anyway.)
>
> If QUIC was only ever going to be used on 443/udp, some of the detection
> issues would be easier.  Right now, the prototype code I've seen for the
> QUIC state tracker hardcodes individual version numbers to look for the
> traffic that needs to be tracked - but the developer is just trying to
> intuit what he's supposed to do from what has been written so far.
>
> I don't think anyone has proposed weakening QUIC's security yet.  If they
> did, the working group should have a thoughtful discussion of the tradeoffs
> involved, and I would expect security to win out almost every time.  It may
> be that certain security measures could be implemented in different ways to
> solve multiple problems, for instance.
>

It's fairly straightforward to work around NAT binding timeouts by
considering the 4-tuple as transient over the lifetime of a connection. We
routinely see NAT rebindings during live QUIC connections, and as long as
the server infrastructure routes based on ConnectionID and not on the
4-tuple, things ought to work out just fine.

Resilence to NAT rebindings will be required anyways, since no matter what
you specify NATs do, there will be a long and heavy tail of those that will
continue to drop bindings. Geoff Huston pointed out a little while ago that
there is a localized preponderance of NATs (don't recall exactly where)
that currently drop bindings every some seconds. QUIC, or any transport for
that matter, will have to handle the common case of NATs that don't follow
any specified behavior or constants.

- jana

---

From: Brian Trammell <[email-masked]>
Date: Wed, 6 Jul 2016 09:08:39 +0200

hi Jana,

One tiny point, inline...

(All: note that quoting is completely hosed by some long-standing incompatibility between Gmail and Apple's MUA that I *really* wish someone would fix already. Refer to other messages in the thread on [email-masked] to figure out who said what.)

> On 06 Jul 2016, at 01:43, Jana Iyengar <[email-masked]> wrote:

<snip>

> - As I wrote earlier, the 94% reachability in the client-server scenario has been independently verified by WebRTC deployments, by measuring the percentage of connections that go over a TURN server. This ends up being ~15%, which is makes sense given that it's p2p and therefore encounters ~2x the number of middleboxes than client-server connections do.
> 
> - Calling the current QUIC deployment "one unrepeatable experiment" is technically accurate, but doesn't really reflect the scale of things. Most Chrome->Google traffic flows over QUIC, and that's a pretty massive and diverse population.
> 
> - The network-requirements draft has two separable parts: (i) which middlebox behaviors are important, and (ii) what information is necessary for that middlebox behavior to be implemented.  (ii) makes no sense without (i), and we do not have consensus on (i)... and that discussion should happen elsewhere, not in the QUIC wg, since any of these considerations ought to apply to *any* protocol over UDP, including WebRTC's SRTP/UDP or SCTP/DTLS/UDP stacks, Tom Herbert's Transports-over-UDP stacks, and also proprietary FaceTime, RTMFP, Skype, Xbox protocols.

<snip>

> I agree with Lars, but there's something else that's implicit in here which I don't think we have a handle on. Which interactions are important to describe? Personally, I don't think this is the right working group to have that discussion, modulo the considerations that will happen organically anyways (as I said, similar to what happened with MPTCP.) I still don't think it's necessary to have that language in the charter to "protect" that conversation. OTOH, I worry as Lars that leaving broad text will cause folks to bring up various middlebox-related conversations that really shouldn't be in this wg.
> 
> PLUS is a great place to have the conversation about which middlebox interactions are important to describe; any outcomes of that wg will naturally influence QUIC later.

<PLUS BoF proponent hat> I completely and wholeheartedly agree! </PLUS BoF proponent hat>

<QUIC BoF co-chair hat> There seems to be a concern here about the effects of QUIC deployment on currently deployed middleboxes used in network operations, and the operational practices surrounding them, as well as the effects devices currently deployed will have on QUIC when QUIC servers are widely operated by more than a single content provider. Consensus on the details of the problem, I agree, are much wider than QUIC, and as such should happen elsewhere. But addressing this concern *within the scope of the QUIC protocol design* seems to be very much in the scope of a QUIC WG. Using your terminology above, if (ii) depends on (i), even if (i) is out of scope, this does not automatically absolve the QUIC WG of responsibility to address (ii) with respect to QUIC. </QUIC BoF co-chair hat>

<no hats>

(On the "single content provider" point: I buy your argument that Chrome represents a relatively diverse client population. I strongly suspect that Chrome->Google traffic is comparatively blind to precisely the kind of managed access environments that Joe is concerned about: you have zero data about networks where users are not allowed by policy to install Chrome, for example. But there is an implicit assumption made in QUIC's detection and fallback mechanisms that the problem lies close to the client, which is completely valid in Google's case. Diversity of server environments will test this assumption, and will need to be considered in protocol design.)

Since we've identified PLUS as a great place to have this conversation, we could also anchor that in the charter to address this concern. If PLUS had already been chartered was a running WG, and had a milestone to define the properties of middlebox functions with which transports should cooperate (which I note the draft PLUS charter does not yet), we could do this with a reference thereto in the QUIC charter:

NEW (new para 10 inserted after para 9, beginning with "Note that consensus is required..."):

The working group will consider the output of the PLUS working group in determining how the protocol will interact with devices on path.

(Perhaps with a reference to QUIC in the PLUS charter to make it clear to the future PLUS WG that they should play nice, too. :) )

But (1) PLUS isn't chartered yet, and (2) we won't even know how likely it is to be chartered until after the PLUS BoF, which takes place after the QUIC BoF. Further, (3) this would add a dependency on a working group we have reason to suspect will take longer to come to consensus on (i) than QUIC should be willing to wait on. Of course, versioning allows us to tweak the protocol to be more explicitly cooperative in the future (unless, of course, as Joe points out, on-path abuse of the versioning mechanism makes it difficult to actually use in practice, which may require ), so a future QUIC can certainly depend on PLUS. None of this fixes the problem today, though, which is why I proposed PR #14.

If there's concern that PR #14 opens the door to doing things in QUIC that really are outside the scope of making QUIC widely deployable, then I'd also like to see a counterproposal. I've been staring at it for a while and can't come up with a meaningful way to restrict it without losing its essence: "QUIC's design should consider how it interacts with current operational practice and the subset of stuff on path that it makes sense to interact with." (Indeed, IMO that phrasing is a good deal less restrictive, because "current operational practice" can be interpreted to well beyond "manageability and diagnosability".)

Cheers,

Brian

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Fri, 15 Jul 2016 12:14:12 -0400

Agree with Brian's statement below:

".... But addressing this concern *within the scope of the QUIC protocol design* seems to be very much in the scope of a QUIC WG. Using your terminology above, if (ii) depends on (i), even if (i) is out of scope, this does not automatically absolve the QUIC WG of responsibility to address (ii) with respect to QUIC. </QUIC BoF co-chair hat>".

It is best to ensure the working group (if formed) charters its position that lays foundation for QUIC evolution and importantly quicker deployment.

-Sanjay

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Wednesday, July 06, 2016 3:09 AM
To: Jana Iyengar
Cc: DRUTA, DAN; [email-masked]; Eggert, Lars; Joe Hildebrand (jhildebr)
Subject: [E] Re: [QUIC] Network Path Requirements for QUIC

hi Jana,

<snip>

<snip>

<no hats>

Cheers,

Brian