Subject: Re: [QUIC] Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice

From: Brian Trammell <[email-masked]>
Date: Thu, 2 Jun 2016 12:11:34 +0200

hi Mark,

Thanks for raising this. Seeing no reply...

I've taken a look at 5405-bis with this question in mind. While it *really* isn't written with the idea of using UDP as a substrate for a transport protocol, one can read it replacing "application" with "transport". So my answer to (a) is yes.

Since an application using UDP is really an application that has decided to take the responsibilities of the transport layer into its own hands, 5405bis can also be seen as a set of guidelines for building Internet-deployable transport protocols written with application developers in mind. IMO, looking at the current state of the charter and the current draft protocol, QUIC seems already to meet the applicable guidelines, with the exception of the following in Section 3:

"  ...the RECOMMENDED
   alternative to the UDP usage described in the remainder of this
   section is the use of an IETF transport protocol..."

which is kind of circular in QUIC's case, and I'm sure not the intent of the document (on which see a late last-call comment, to be posted shortly...)

Cheers,

Brian

> On 31 May 2016, at 04:54, Mark Nottingham <[email-masked]> wrote:
> 
> Apologies if I missed discussion about this.
> 
> If this is to be a BCP, is it safe to assume that a) it will apply to QUIC if chartered, and b) that folks here are comfortable with its requirements?
> 
> Cheers,
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: The IESG <[email-masked]>
>> Subject: Last Call: <draft-ietf-tsvwg-rfc5405bis-13.txt> (UDP Usage Guidelines) to Best Current Practice
>> Date: 18 May 2016 at 10:17:06 AM AEST
>> To: "IETF-Announce" <[email-masked]>
>> Cc: [email-masked], [email-masked], [email-masked]
>> Reply-To: [email-masked]
>> Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-announce/ahGfkYGwGGV_F0XanpqWTyZTwFA>
>> 
>> 
>> The IESG has received a request from the Transport Area Working Group WG
>> (tsvwg) to consider the following document:
>> - 'UDP Usage Guidelines'
>> <draft-ietf-tsvwg-rfc5405bis-13.txt> as Best Current Practice
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2016-05-31. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>> 
>> Abstract
>> 
>> 
>>  The User Datagram Protocol (UDP) provides a minimal message-passing
>>  transport that has no inherent congestion control mechanisms.  This
>>  document provides guidelines on the use of UDP for the designers of
>>  applications, tunnels and other protocols that use UDP.  Congestion
>>  control guidelines are a primary focus, but the document also
>>  provides guidance on other topics, including message sizes,
>>  reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
>>  and ports.
>> 
>>  Because congestion control is critical to the stable operation of the
>>  Internet, applications and other protocols that choose to use UDP as
>>  an Internet transport must employ mechanisms to prevent congestion
>>  collapse and to establish some degree of fairness with concurrent
>>  traffic.  They may also need to implement additional mechanisms,
>>  depending on how they use UDP.
>> 
>>  Some guidance is also applicable to the design of other protocols
>>  (e.g., protocols layered directly on IP or via IP-based tunnels),
>>  especially when these protocols do not themselves provide congestion
>>  control.
>> 
>>  This document obsoletes RFC5405 and adds guidelines for multicast UDP
>>  usage.
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/
>> 
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> 
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic

---

From: Brian Trammell <[email-masked]>
Date: Thu, 2 Jun 2016 12:11:40 +0200

Greetings, all,

Apologies for the late last call comment; I have only one, relatively minor. I hope it's still useful.

I understand that Section 3 was written to encourage application developers not to roll their own transports ("trust us when we say this is hard, this document is a list of reasons why") but as written it would seem to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data channel, anything-over-PLUS), which I very much hope was not the intent. The problematic recommendation is in the second paragraph:

   These mechanisms are difficult to implement correctly.  For most
   applications, the use of one of the existing IETF transport protocols
   is the simplest method of acquiring the required mechanisms.  Doing
   so also avoids issues that protocols using a new IP protocol number
   face when being deployed over the Internet, where middleboxes that
   only support TCP and UDP are not rare.  Consequently, the RECOMMENDED
   alternative to the UDP usage described in the remainder of this
   section is the use of an IETF transport protocol such as TCP
   [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and
   SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram
   Congestion Control Protocol (DCCP) [RFC4340] with its different
   congestion control types [RFC4341][RFC4342][RFC5622].

First, this paragraph ignores potential deployment issues with any of these other than TCP, which risks seeming out of touch, but this is a minor point and probably not worth a late edit. Second, I'm concerned this recommendation could be taken as broader than intended, against the definition of any new transport protocol encapsulated within UDP that performs substantially the same function as the listed protocols.

I think this can be made clearer by simply adding to the list of examples:

NEW:

   These mechanisms are difficult to implement correctly.  For most
   applications, the use of one of the existing IETF transport protocols
   is the simplest method of acquiring the required mechanisms.  Doing
   so also avoids issues that protocols using a new IP protocol number
   face when being deployed over the Internet, where middleboxes that
   only support TCP and UDP are not rare.  Consequently, the RECOMMENDED
   alternative to the UDP usage described in the remainder of this
   section is the use of an IETF transport protocol such as TCP
   [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and
   SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram
   Congestion Control Protocol (DCCP) [RFC4340] with its different
   congestion control types [RFC4341][RFC4342][RFC5622], or transport
   protocols specified by the IETF in the future.

and removing the examples from the summary in section 7:

OLD:

   | SHOULD use a full-featured transport (TCP, SCTP, DCCP)  |         |

NEW:

   | SHOULD use a full-featured transport                    |         |

Thanks, cheers,

Brian

> On 18 May 2016, at 02:17, The IESG <[email-masked]> wrote:
> 
>

---

From: Ca By <[email-masked]>
Date: Fri, 3 Jun 2016 08:15:33 -0700

On Thursday, June 2, 2016, Brian Trammell <[email-masked]> wrote:

> I understand that Section 3 was written to encourage application
> developers not to roll their own transports ("trust us when we say this is
> hard, this document is a list of reasons why") but as written it would seem
> to discourage transport innovation atop UDP (e.g. QUIC, the RTCWEB data
> channel, anything-over-PLUS), which I very much hope was not the intent.
> The problematic recommendation is in the second paragraph:
>
> First, this paragraph ignores potential deployment issues with any of
> these other than TCP, which risks seeming out of touch, but this is a minor
> point and probably not worth a late edit. Second, I'm concerned this
> recommendation could be taken as broader than intended, against the
> definition of any new transport protocol encapsulated within UDP that
> performs substantially the same function as the listed protocols.
>
> > On 18 May 2016, at 02:17, The IESG <[email-masked]
> <javascript:;>> wrote:
> >
> >
> > [email-masked] <javascript:;> mailing lists by 2016-05-31.
> Exceptionally, comments may be
> > sent to [email-masked] <javascript:;> instead. In either case, please
> retain the

I disagree.  The text as-is is best and represents a prudent period of
review in the WG.  As suggested many times to both spud and quic, extending
udp is not recommended. We have multiple L4 transport protocols for a
reason, you should innovative in that space without UDP.

CB

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 03 Jun 2016 16:28:09 +0100

It is certainly not too late, many thanks - to both Brian and you!

We have various pending comments to look through, and will make sure all 
comments are also taken into consideration, -  next week we'll be 
resolving the conflicts between comments and seeing how best to 
accommodate these in updated text, comments then may be late!

Gorry

On 03/06/2016 16:15, Ca By wrote:
>
>
> On Thursday, June 2, 2016, Brian Trammell <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Greetings, all,
>
>     Apologies for the late last call comment; I have only one,
>     relatively minor. I hope it's still useful.
>
>     developers not to roll their own transports ("trust us when we say
>     this is hard, this document is a list of reasons why") but as
>     written it would seem to discourage transport innovation atop UDP
>     (e.g. QUIC, the RTCWEB data channel, anything-over-PLUS), which I
>     very much hope was not the intent. The problematic recommendation
>     is in the second paragraph:
>
>     First, this paragraph ignores potential deployment issues with any
>     of these other than TCP, which risks seeming out of touch, but
>     this is a minor point and probably not worth a late edit. Second,
>     I'm concerned this recommendation could be taken as broader than
>     intended, against the definition of any new transport protocol
>     encapsulated within UDP that performs substantially the same
>     function as the listed protocols.
>
>     > sent to [email-masked] <javascript:;> instead. In either case,
>     please retain the
> review in the WG.  As suggested many times to both spud and quic, 
> extending udp is not recommended. We have multiple L4 transport 
> protocols for a reason, you should innovative in that space without UDP.
>
> CB

---

From: Tom Herbert <[email-masked]>
Date: Sat, 4 Jun 2016 17:25:39 -0700

> First, this paragraph ignores potential deployment issues with any of these other than TCP, which risks seeming out of touch, but this is a minor point and probably not worth a late edit. Second, I…
I would agree, this paragraph also seems a little self
contradictory.There is an acknowledgment that "middleboxes that only
support TCP and UDP are not rare", but then the next sentence
recommends the use of several other protocols besides UDP and TCP. If
I put these two together, the only congested controlled protocol that
is recommended and expected to work on the Internet is TCP.

Tom

> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Jim Roskind <[email-masked]>
Date: Sun, 5 Jun 2016 22:18:17 -0700

> is recommended and expected to work on the Internet is TCP.

+1   TCP (implemented in kernel space) can't possibly evolve congestion
avoidance as fast as the Internet has changed, or will change (example:
good handling of middle boxes that use "policers" rather than some flavor
of buffer-size based packet-drop).
The rationale for using UDP for QUIC was indeed that a new IP number would
never make it through the Internet (other protocol deployment attempts have
commonly verified this).  It turns out that even UDP is partially blocked
(as recently as 2011) by paths to 5-7% of all chrome clients, which lead to
the "automated fallback" elements of QUIC,

Hopefully the benefits that QUIC is bringing to the Internet will not be
outlawed (precluded by such commentary).

Jim

---

From: Michael Welzl <[email-masked]>
Date: Mon, 6 Jun 2016 09:44:46 +0200

Hi,

I narrow down the recipient list to QUIC only and change the subject, because I don't think this is about making a recommendation for the text in the RFC5405bis draft anymore:

> On 06 Jun 2016, at 07:18, Jim Roskind <[email-masked]> wrote:
> 
> 
> 
> +1   TCP (implemented in kernel space) can't possibly evolve congestion avoidance as fast as the Internet has changed, or will change (example: good handling of middle boxes that use "policers" rather than some flavor of buffer-size based packet-drop). 
> The rationale for using UDP for QUIC was indeed that a new IP number would never make it through the Internet (other protocol deployment attempts have commonly verified this).

"never" isn't true. We recently did measurements where about half of TCP connection attempts succeeded when the protocol didn't really claim to be TCP at all but we used an unknown protocol number. This wasn't a huge measurement campaign, just approx. 100 different Internet paths. Still, "never" just ain't true; the question is really if the other protocol deployment attempts that you mention used (efficient) fallbacks.

>  It turns out that even UDP is partially blocked (as recently as 2011) by paths to 5-7% of all chrome clients, which lead to the "automated fallback" elements of QUIC,   

You could fall back 1) QUIC/native, 2) QUIC/UDP, 3) TCP

- but this would require some intelligence in how to do this fall back, e.g. with a useful caching strategy. Of course, the question is if this is really worth the effort.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Mon, 6 Jun 2016 09:54:17 +0200

hi Michael,

> On 06 Jun 2016, at 09:44, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 

Interesting; I would actually have expected more than half to succeed, but I suppose this is entirely a function of how present (and clueful) the NAT boxes along your chosen path are. We're planning on doing a larger-scale study of exactly this question soon, both on the open Internet and in the lab on a set of captive middleboxes.

> - but this would require some intelligence in how to do this fall back, e.g. with a useful caching strategy. Of course, the question is if this is really worth the effort.

At least in our (ongoing, under submission) work on UDP impairment (see BA maprg talk), it appears that the *vast* majority of cases are access-network linked. So each peer can cache its "UDP works" bit on a per-interface or per-connection-profile basis (and servers, of course, can have it configured as a matter of policy). I suspect the picture with other protocol numbers is similar (but need to see data to believe it).

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Mon, 6 Jun 2016 11:18:37 +0200

> On 06 Jun 2016, at 09:54, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 

Cool!

> At least in our (ongoing, under submission) work on UDP impairment (see BA maprg talk), it appears that the *vast* majority of cases are access-network linked.

We saw something similar.

> So each peer can cache its "UDP works" bit on a per-interface or per-connection-profile basis (and servers, of course, can have it configured as a matter of policy). I suspect the picture with other protocol numbers is similar (but need to see data to believe it).

Well ...   maybe ?   Interesting thought anyway!

Cheers,
Michael

---

From: Ian Swett <[email-masked]>
Date: Mon, 6 Jun 2016 10:26:57 -0400

On Mon, Jun 6, 2016 at 5:18 AM, Michael Welzl <[email-masked]> wrote:

> >> I narrow down the recipient list to QUIC only and change the subject,
> because I don't think this is about making a recommendation for the text in
> the RFC5405bis draft anymore:
> >>
> >>
> >>> +1   TCP (implemented in kernel space) can't possibly evolve
> congestion avoidance as fast as the Internet has changed, or will change
> (example: good handling of middle boxes that use "policers" rather than
> some flavor of buffer-size based packet-drop).
> >>> The rationale for using UDP for QUIC was indeed that a new IP number
> would never make it through the Internet (other protocol deployment
> attempts have commonly verified this).
> >>
> >> "never" isn't true. We recently did measurements where about half of
> TCP connection attempts succeeded when the protocol didn't really claim to
> be TCP at all but we used an unknown protocol number. This wasn't a huge
> measurement campaign, just approx. 100 different Internet paths. Still,
> "never" just ain't true; the question is really if the other protocol
> deployment attempts that you mention used (efficient) fallbacks.
> >
> > Interesting; I would actually have expected more than half to succeed,
> but I suppose this is entirely a function of how present (and clueful) the
> NAT boxes along your chosen path are. We're planning on doing a
> larger-scale study of exactly this question soon, both on the open Internet
> and in the lab on a set of captive middleboxes.
>
> Cool!
>
>
> >>> It turns out that even UDP is partially blocked (as recently as 2011)
> by paths to 5-7% of all chrome clients, which lead to the "automated
> fallback" elements of QUIC,
> >>

But Chrome his privileges to write QUIC over a dedicated protocol number on
~0% of the clients it's running on, which further increases the barrier
beyond the complexity of a 3-way race.  A 2-way race with  v4/v6 happy
eyeballs is quite complex and difficult to get right.

> >> - but this would require some intelligence in how to do this fall back,
> e.g. with a useful caching strategy. Of course, the question is if this is
> really worth the effort.
> >
> > At least in our (ongoing, under submission) work on UDP impairment (see
> BA maprg talk), it appears that the *vast* majority of cases are
> access-network linked.
>

We've seen something similar, though sometimes there are other
issues(server config issues, network config issues, etc) that come up and
effect one server or set of servers but not others.  Chrome tries to handle
this by marking some as broken and not others, but this logic has proven
hard to get exactly right.

> > So each peer can cache its "UDP works" bit on a per-interface or
> per-connection-profile basis (and servers, of course, can have it
> configured as a matter of policy). I suspect the picture with other
> protocol numbers is similar (but need to see data to believe it).
>

---

From: Michael Welzl <[email-masked]>
Date: Mon, 6 Jun 2016 22:22:40 +0200

> On 6. jun. 2016, at 16.26, Ian Swett <[email-masked]> wrote:
> 
> On Mon, Jun 6, 2016 at 5:18 AM, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 06 Jun 2016, at 09:54, Brian Trammell <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > hi Michael,
> >
> >> On 06 Jun 2016, at 09:44, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Hi,
> >>
> >>> On 06 Jun 2016, at 07:18, Jim Roskind <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>>
> >>>
> >>> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
> >>> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell <[email-masked] <mailto:[email-masked]>> wrote:
> >>>> Greetings, all,
> >>>>
> But Chrome his privileges to write QUIC over a dedicated protocol number on ~0% of the clients it's running on, which further increases the barrier beyond the complexity of a 3-way race.  A 2-way race with  v4/v6 happy eyeballs is quite complex and difficult to get right.

Of course; I’m not complaining about the choice made by QUIC, just pointing out that in principle, such a thing could be done  (and I think it should be provided by some layer below, in the OS - but this is just wishful thinking). Sorry for saying “you could” - I know you couldn’t.  Plus I agree about the complexity and I’m not sure this would be worth the effort; again I’m dreaming of some magic thing in the OS that does that for you...

Cheers,
Michael

> We've seen something similar, though sometimes there are other issues(server config issues, network config issues, etc) that come up and effect one server or set of servers but not others.  Chrome tries to handle this by marking some as broken and not others, but this logic has proven hard to get exactly right.
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/quic <https://www.ietf.org/mailman/listinfo/quic>
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 7 Jun 2016 10:23:11 +0200

Actually - now I have more questions, below; I'm just curious about these things -

(snip)

> But Chrome his privileges to write QUIC over a dedicated protocol number on ~0% of the clients it's running on, which further increases the barrier beyond the complexity of a 3-way race.  A 2-way r…

So Chrome can't even be a root process on Android? I know almost nothing about Android but I find that strange - Google develops an OS and its own browser is then so limited in it?

And a thought about the "3-way race": I understand that you're working hard to get QUIC to operate ASAP, which explains the complexity of your 2-way race. However, if you were to try QUIC/native too, this could have a much lower priority - you could send an occasional SYN-type packet much later, and cache a positive result if you get one. Surely this cache will be valid for some time, and surely browsers open many connections to the same site, not only all in one go but also with delay (e.g.: I go to Google, I type in a search, I click on a result - 3 consecutive interactions with the same server, all with delay in between).

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 7 Jun 2016 11:15:30 +0200

Hi Michael,

I don’t even really see your point in using e.g. quic natively. I mean sure that was the original idea, but all that UDP gives is you is port numbers, at a well defined position in the header. Given that a bunch of things operate on a 4- or 5-tuple, you need port numbers anyway and they are basically not really end-to-end anymore.

Mirja

> Am 07.06.2016 um 10:23 schrieb Michael Welzl <[email-masked]>:
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 7 Jun 2016 12:03:36 +0200

ACK that - just talking about possibilities but maybe it's a waste of time to even talk about it - I was just curious, that's why I asked my questions below.
But I don't have an issue with using UDP and agree with you.

> On 07 Jun 2016, at 11:15, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Michael,
>

---

From: Ian Swett <[email-masked]>
Date: Tue, 7 Jun 2016 09:45:37 -0400

On Tue, Jun 7, 2016 at 6:03 AM, Michael Welzl <[email-masked]> wrote:

> ACK that - just talking about possibilities but maybe it's a waste of time
> to even talk about it - I was just curious, that's why I asked my questions
> below.
> > I don’t even really see your point in using e.g. quic natively. I mean
> sure that was the original idea, but all that UDP gives is you is port
> numbers, at a well defined position in the header. Given that a bunch of
> things operate on a 4- or 5-tuple, you need port numbers anyway and they
> are basically not really end-to-end anymore.
> >
> > Mirja
> >
> >
> >>>>>> It turns out that even UDP is partially blocked (as recently as
> 2011) by paths to 5-7% of all chrome clients, which lead to the "automated
> >>> But Chrome his privileges to write QUIC over a dedicated protocol
> number on ~0% of the clients it's running on, which further increases the
> barrier beyond the complexity of a 3-way race.  A 2-way race with  v4/v6
> happy eyeballs is quite complex and difficult to get right.
> >>
> >> So Chrome can't even be a root process on Android? I know almost
> nothing about Android but I find that strange - Google develops an OS and
> its own browser is then so limited in it?
> >>
>

I don't believe so.  Chrome is just a normal app.  If it was root, I think
that would increase the chances of cross-app security issues.

> >> And a thought about the "3-way race": I understand that you're working
> hard to get QUIC to operate ASAP, which explains the complexity of your
> 2-way race. However, if you were to try QUIC/native too, this could have a
> much lower priority - you could send an occasional SYN-type packet much
> later, and cache a positive result if you get one. Surely this cache will
> be valid for some time, and surely browsers open many connections to the
> same site, not only all in one go but also with delay (e.g.: I go to
> Google, I type in a search, I click on a result - 3 consecutive
> interactions with the same server, all with delay in between).
>

On a desktop, today this likely works ok because one's connectivity rarely
changes.  On a laptop, it's probably not terrible, though you may change a
few times a day.  On a phone, it's much harder, because phones change IPs
and networks all the time.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 7 Jun 2016 22:59:19 -0700

Just adding my 2c if this still isn't too late: I agree with Brian that the
wording in the draft seems limiting. His suggested wording does make things
better, but there still is the contradiction that Tom pointed out:

> is recommended and expected to work on the Internet is TCP.

This caught my attention as well. As it stands, the recommendation in this
paragraph is very unclear.

What exactly is the goal here? If it is to ensure that the recommendations
allow for deployable protocols, then UDP-based ones must be allowed.
Otherwise, the recommendation seems to be to only use TCP. I don't think
that was the intent... but then what is the intent in this paragraph?

- jana

---

From: Ca By <[email-masked]>
Date: Wed, 8 Jun 2016 05:20:38 -0700

> the "automated fallback" elements of QUIC,
I think this changes with ipv6, no?  Google sees over 26% ipv6 in the usa
and growing quickly

http://www.google.com/intl/en/ipv6/statistics.html

And there is evidence that middle boxes go away in ipv6. .... So perhaps
the world is changing and your assuptions do not hold

---

From: Brian Trammell <[email-masked]>
Date: Wed, 8 Jun 2016 18:40:24 +0200

> 
>> On 08 Jun 2016, at 14:20, Ca By <[email-masked]> wrote:
>> 
>> 
>> 
>> On Sunday, June 5, 2016, Jim Roskind <[email-masked]> wrote:
>> 
>> 
>> The rationale for using UDP for QUIC was indeed that a new IP number would never make it through the Internet (other protocol deployment attempts have commonly verified this).  It turns out that even UDP is partially blocked (as recently as 2011) by paths to 5-7% of all chrome clients, which lead to the "automated fallback" elements of QUIC,
>> 
> 
> I think this changes with ipv6, no?  Google sees over 26% ipv6 in the usa and growing quickly
> 
> And there is evidence that middle boxes go away in ipv6. .... So perhaps the world is changing and your assuptions do not hold

(dropping ietf@, saving my Narten points since we're a bit off topic on the draft last call)

I'd like to see evidence, if you can share it.

We've done a few measurements with Atlas that suggest the brokenness on v6 is different, but not necessarily better, but don't have enough data points to make an informed statement on the fact. Any time you touch a NAPT (which lives at the core of any transition technology for v6-only access to the v4 Internet), you run into the "only TCP and UDP have ports" fallacy. But yes, we need to compare and contrast v4 and v6 access network impairments for non-(6,17) protocol numbers.

Cheers,

Brian

---

From: Ca By <[email-masked]>
Date: Sat, 11 Jun 2016 16:24:09 -0700

On Wednesday, June 8, 2016, Brian Trammell <[email-masked]> wrote:

> >
> >> On 08 Jun 2016, at 14:20, Ca By <[email-masked] <javascript:;>>
> wrote:
> >>
> >>
> >>
> >> On Sat, Jun 4, 2016 at 5:25 PM, Tom Herbert <[email-masked]
> <javascript:;>> wrote:
> >> On Thu, Jun 2, 2016 at 3:11 AM, Brian Trammell <[email-masked]
> <javascript:;>> wrote:
> >> > Greetings, all,
> >> >
> attempts have commonly verified this).  It turns out that even UDP is
> partially blocked (as recently as 2011) by paths to 5-7% of all chrome
> clients, which lead to the "automated fallback" elements of QUIC,
> >>
> >
" Verizon uses transparent proxy servers on IPv4 but not on IPv6"

https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html

We've done a few measurements with Atlas that suggest the brokenness on v6
> is different, but not necessarily better, but don't have enough data points
> to make an informed statement on the fact. Any time you touch a NAPT (which
> lives at the core of any transition technology for v6-only access to the v4
> Internet), you run into the "only TCP and UDP have ports" fallacy. But yes,
> we need to compare and contrast v4 and v6 access network impairments for
> non-(6,17) protocol numbers.
>
>
NAPT is an edge case for v6 users, less than 30% and shrinking by bit
volume as the whales have moved to v6 already

https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html