From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 22747200968 for ; Sun, 15 May 2011 11:19:46 -0700 (PDT) Received: by fxm3 with SMTP id 3so4273126fxm.16 for ; Sun, 15 May 2011 11:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=10ODBShtL4nHm9xCncWZCdC2/PUdTD1omlqgRm6SvyM=; b=Rq3F/0MTEWc5iuSb3KY4Z2ywvEffFdeVARb0lx8O8osv3DBfrYDmPw2Zc6zSbyQw2O tnB0ZEF7howuIZ+Z/dgwplQ8l57gGiFEzptCU1ll7hV9yjPGpZWm1EGuH4dw1VtYEM9S X3b61hPBhnbkbQ9y+Tb8o7Mker90TUI0cywR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=tle7SGdyfYZdCG3RCRkH/1gy7g8qnL1o98l9qK5V7R3Byn0D+dfDv230lPNQ/yQ/1i XRk60+AalFxEiRWD1v4MpD7TKbEh1rAhJVA08XbuNbbnFNOtPRoEN4HrnQ7OWSPScw5Q 7D01N4Bu3lXkJzjVtuiXUYS0zsLMV5rTFUsFM= Received: by 10.223.92.148 with SMTP id r20mr1013400fam.64.1305484141093; Sun, 15 May 2011 11:29:01 -0700 (PDT) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id j18sm1547359faa.18.2011.05.15.11.28.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 May 2011 11:28:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <8A928839-1D91-4F18-8252-F06BD004E37D@cisco.com> Date: Sun, 15 May 2011 21:28:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org> <20110505091046.3c73e067@nehalam> <6E25D2CF-D0F0-4C41-BABC-4AB0C00862A6@pnsol.com> <35D8AC71C7BF46E29CC3118AACD97FA6@srichardlxp2> <1304964368.8149.202.camel@tardy> <4DD9A464-8845-49AA-ADC4-A0D36D91AAEC@cisco.com> <1305297321.8149.549.camel@tardy> <014c01cc11a8$de78ac10$9b6a0430$@gross@avanw.com> <8A928839-1D91-4F18-8252-F06BD004E37D@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Jumbo frames and LAN buffers (was: RE: Burst Loss) 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: Sun, 15 May 2011 18:19:47 -0000 On 14 May, 2011, at 11:48 pm, Fred Baker wrote: > My suspicion is that the right approach is something akin to 802.2 at = the link layer, but with NACK retransmission - system A enumerates the = data it sends to system B, and if system B sees a number skip it asks A = to retransmit the indicated datagram. You might take a look at RFC = 5401/5740/5776 for implementation suggestions. This sounds like "reliable datagram" semantics to me. It also sounds a = lot like ARQ as used in amateur packet radio. I believe similar = mechanisms are built into 802.11. The fundamental thing is that the sender must be able to know when sent = frames can be flushed from the buffer because they don't need to be = retransmitted. So if there's a NACK, there must also be an ACK - at = which point the ACK serves the purpose of the NACK, as it does in TCP. = The only alternative is a wall-time TTL, which is doable on single hops = but requires careful design. Let's face it. UDP is unreliable by design - applications using it = *must* anticipate and cope with dropped and delayed packets, either by = exponential RTO or ARQ or NACK or FEC, all at the application layer. = And, in a congested network, some UDP packets *will* be lost. TCP is reliable but needs to maintain appropriate window sizes - which = it doesn't at present because a lossless network without ECN provides = insufficient feedback (and AQM, which is required for good ECN signals, = is usually absent), and in the quest for performance, the trend has been = inexorably towards more aggressive window sizing (of which TCP-Fit is = the latest example). At the receiver end, it is possible to restrain = this trend by reducing the receive window. Unfortunately, it's useless to expect Ethernet switches to turn on ECN. = They operate at a lower stack level than IP, so they will not modify the = IP TOS headers. However, recent versions of Ethernet *do* support a = throttling feedback mechanism, and this can and should be exploited to = tell the edge host or router that ECN *might* be needed. Also, with = throttling feedback throughout the LAN, the Ethernet can for practical = purposes be treated as almost-reliable. This is *better* in terms of = packet loss than ARQ or NACK, although if the Ethernet's buffers are = large, it will still increase delay. (With small buffers, it will just = decrease throughput to the capacity, which is fine.) - Jonathan