TCP-Minion as an alternate datagram substrate for QUIC?

[Bryan Ford]

Hi Jim et al,

I just learned that you'd started making your QUIC documentation public, and took a look through the specs - good stuff.  It looks like it's introducing a lot of latency-reducing ideas similar to but extending those I had started in my Structured Stream Transport, but never got around to developing fully or deploying a practical implementation for the Real World(tm).

I noticed from your Design Document that avoiding TCP's head-of-line-blocking (understandably) appears to be your primary motivation for going with UDP as a substrate, but the problem of NAT traversal and the need for frequent keep-alives to maintain NAT bindings seems to be a big challenge.  Have you considered generalizing QUIC slightly to permit it to run atop multiple datagram substrates, and exploring support for TCP and/or TCP-Minion (our out-of-order delivery extension to TCP) as alternative, complementary substrates for QUIC?  TCP-Minion would basically allow QUIC to achieve the same goal of avoiding cross-stream head-of-line-blocking, while looking and behaving like TCP to the network, which sometimes has advantages (and also sometimes has disadvantages of course).

Even if QUIC sticks with UDP as the normal/preferred substrate, for example, QUIC might want to switch to a TCP-Minion substrate when a mostly-idle logical connection needs to stay open for long periods of time; this could save a lot of power for mobile devices since NATs' TCP idle timeouts are typically an order of magnitude longer than for UDP (e.g., hours instead of minutes).  You might still need exactly the same types of algorithms it looks like you're already using to detect and adapt to different NATs' varying idle timeouts, but that algorithm will almost certainly "find" that its keepalives can be much less frequent when it's running over TCP[-Minion].  Having TCP[-Minion] as an alternative could also ensure that QUIC remains operable and able to communicate even across Internet paths that block or do other bad things to UDP traffic.

Besides our original NSDI paper on Minion, my colleague Jana Iyengar has recently been working with some folks at Apple, who have put out some Internet-Drafts with interesting improvements to Minion such as byte-granularity preemptability for traffic prioritization and such.  (I know Apple's your competition, but I hope we can get past while designing open Internet protocols. :) )  Here are the pointers:

Minion - Service Model and Conceptual API - draft-iyengar-minion-concept-01

http://tools.ietf.org/html/draft-iyengar-minion-concept-01

Minion - Wire Protocol - draft-iyengar-minion-protocol-01

http://tools.ietf.org/html/draft-iyengar-minion-protocol-01

Anyway, once again, interesting protocol, and I look forward to taking a closer look at the prototype when we have time.

Cheers

Bryan

[Jim Roskind]

The out-of-order delivery is indeed a critical reason for using UDP encapsulation... but a second apparent advantage over TCP based protocols is the ability to innovated and rapidly extend various congestion avoidance strategies, as well as the ability to experiment more easily with FEC.  

We also hope that any exceptional results may be fed back to TCP, hopefully making it better.. which may (eventually) reduce the advantage of UDP encapsulation.

We're starting to run some experiments now to quantify the NAT binding issue.  Depending on how those results shake out, we'll decide how hard we need to work on handling NAT unbinding.

Minion is indeed an impressive effort.  I agree that the use of TCP may be helpful with some issues, but it also ties your hands with other issues.  Changing the TCP stack to acquire some of the greatest benefits of Minion requires kernel changes, and hence slower real-world deployment.  QUIC has the advantage of using application-space level changes. [... but also paying a price as QUIC doesn'tt get ACKs and such handled in the kernel ;-/ ]

In my heart, I also see the integration of the various levels of the protocol in QUIC, such as aligning crypto block boundaries with packet boundaries, and often with stream boundaries, as notably advantageous.  There is probably a small bandwidth inefficiency to specify the stream identifier time and again (rather than having a long sequential block across numerous packets, as might be seen in SPDY or Minion), but we've recently reduced that QUIC data-framing overhead significantly. The fact that packet loss appears at exactly packet boundaries seems like a good thing to tie into the protocol, especially when considering FEC (which is more difficult with TCP, unless kernel changes use or give visibility into packetization).

Bottom line: consideration of using other protocols, or tricks from other protocols, is constantly on our minds. 

Jim

Bryan

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.
 
 

[Sargun Dhillon]

I actually have a question which is somewhat off-topic from the group topic a bit, but what's the status of TCP Mingle?