From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.217.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5265221F181 for ; Fri, 28 Jun 2013 16:17:16 -0700 (PDT) Received: from [96.50.69.82] (port=50083 helo=[192.168.145.118]) by biz82.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ushuj-000377-RF for bloat@lists.bufferbloat.net; Fri, 28 Jun 2013 16:17:14 -0700 Message-ID: <51CE1970.8010606@callenish.com> Date: Fri, 28 Jun 2013 16:17:04 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <20130628215451.7B40E406061@ip-64-139-1-69.sjc.megapath.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - lists.bufferbloat.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com X-Get-Message-Sender-Via: biz82.inmotionhosting.com: authenticated_id: bruce+callenish.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Bloat] Google's QUIC has reached NANOG X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 23:17:16 -0000 On 28/06/2013 3:05 PM, Justin Andrusk wrote: > > So am I the only one concerned that they are looking to use udp > instead of tcp? > > It is an important part of the design. They want to multiplex streams into a single connection, and ordered packets means one lost packet in one stream holds up all the streams. Only way around that is with something other than TCP right now. This is a major downside of multiplexing SPDY over using multiple connections, which I believe was one of the prime motivators to develop QUIC. In the FAQ, they mention that they are hoping once they get a good design in QUIC some of its ideas can be moved into TCP. Someday.