From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-01-iad.dyndns.com (mxout-085-iad.mailhop.org [216.146.32.85]) by lists.bufferbloat.net (Postfix) with ESMTP id C1ED02E2D3C for ; Sun, 20 Mar 2011 18:56:48 -0700 (PDT) Received: from scan-02-iad.mailhop.org (scan-02-iad.local [10.150.0.207]) by mail-01-iad.dyndns.com (Postfix) with ESMTP id 6A36F6E786 for ; Mon, 21 Mar 2011 01:56:49 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 205.178.146.57 Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by mail-01-iad.dyndns.com (Postfix) with ESMTP id 98DDF6DBB7 for ; Mon, 21 Mar 2011 01:56:48 +0000 (UTC) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2L1ulCg025643 for ; Sun, 20 Mar 2011 21:56:47 -0400 Authentication-Results: cm-omr5 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.80.150] ([174.130.80.150:54875] helo=[192.168.1.101]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 17/E4-29099-F50B68D4; Sun, 20 Mar 2011 21:56:47 -0400 Message-ID: <4D86B05F.7060004@mti-systems.com> Date: Sun, 20 Mar 2011 21:56:47 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <4D7F4121.40307@freedesktop.org><20110315175942.GA10064@goldfish><1300212877.2087.2155.camel@tardy><20110315183111.GB2542@tuxdriver.com><29B06777-CC5F-4802-8727-B04F58CDA9E3@gmail.com><20110315205146.GF2542@tuxdriver.com><219C7840-ED79-49EA-929D-96C5A6200401@gmail.com><20110315151946.31e86b46@nehalam><1300228592.2087.2191.camel@tardy><1300229578.2565.29.camel@edumazet-laptop><87fwqo54n7.fsf@cruithne.co.teklibre.org><823E2A7B-4F46-4159-8029-BD3B075CC4CE@gmail.com><87bp1b6fo0.fsf@cruithne.co.teklibre.org><87bp1b4yh4.fsf@cruithne.co.teklibre.org> <7480559F-1F3B-4CE5-939F-FD9FD3E68E52@cisco.com> <909F3A19-C7DA-4E38-9BB0-A2EA5F625B7F@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps? 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: Mon, 21 Mar 2011 01:56:49 -0000 On 3/20/2011 9:28 PM, david@lang.hm wrote: > On Mon, 21 Mar 2011, Jonathan Morton wrote: > >> On 21 Mar, 2011, at 12:18 am, david@lang.hm wrote: >> >>>> 0) Buffering more than 1 second of data is always unacceptable. >>> >>> what about satellite links? my understanding is that the four round >>> trips to geosync orbit (request up, down, reply up down) result in >>> approximatly 1 sec round trip. >> >> That is true, but it doesn't require more than a full second of >> buffering, just lots of FEC to avoid packet loss on the link. At those >> timescales, you want the flow to look smooth, not bursty. Bursty is >> normal at 100ms timescales. >> >> What I've heard is that most consumer satellite links use split-TCP >> anyway (proxy boxes at each end) thus relieving the Internet at large >> from coping with an unusual problem. However, it also seems likely >> that backbone satellite links exist which do not use this technique. I >> heard something about South America, maybe? > > I've heard that they do proxy boxes at each end for common protocols > like HTTP, but they can't do so for other protocols (think ssh for example) > >> Anyway, with a 1-second RTT, the formula comes out to max 1 second of >> buffering because of the clamping. > > and what if you have a 1 second satellite link plus 'normal internet > latency', or worse, both ends are on a satellite link, giving you a > 2-second+ round trip time? > > if you don't have large enough buffers to handle this, what happens? > Propagation delay to a geosynchronous relay is ~125 ms. Round-trip propagation delay contributes ~500 ms, so it isn't quite as bad as you think, though still long. Many tricks are played with accelerator gateways to improve bulk transfer throughput for TCP users (see e.g. RFC 3135). There may be a challenge in debloating the devices that support such links, as their buffers and the functions they serve optimize other metrics (e.g. low packet loss rate, bulk transfer throughput, etc.). -- Wes Eddy MTI Systems