From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "tcmail53.telekom.de", Issuer "TeleSec ServerPass CA 1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9144520017C for ; Tue, 14 Jun 2011 00:27:03 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jun 2011 09:49:24 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.66]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 14 Jun 2011 09:49:24 +0200 From: To: , Date: Tue, 14 Jun 2011 09:49:21 +0200 Thread-Topic: [Bloat] If you were me, and talking at NANOG.... Thread-Index: AcwnraOq3Fa3kccKQs2NJkGaIy3wugCtSlJQ Message-ID: References: <4DF27F62.9040408@freedesktop.org> In-Reply-To: <4DF27F62.9040408@freedesktop.org> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Bloat] If you were me, and talking at 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: Tue, 14 Jun 2011 07:27:04 -0000 > I have yet another talk to give next week at NANOG. http://www.nanog.org/ > > Some of you on this list have lots more experience running networks than > I do, and are at least noddingly familiar with bufferbloat, or would not > have subscribed. > > What points would you make to a group like NANOG? Send to me privately > unless you think your insights are of general interest. some random points: - Some regulatory bodies require that an operator can only charge for packe= ts that are really delivered to the customer. If you sell volume-based plan= s, you better queue packets, even if that means non-optimal service for you= r customer.. - ISPs often sell/provide home routers; the buffering behaviour varies a lo= t. Specifying -- and testing -- proper buffering is necessary. - slow upstream links cause a lot of inherent delay that looks like bufferb= loat (well, the slow link *is* a buffer); some home routers fragment packet= s into small chunks so that real-time flows don't get delayed too much. Thi= s does not work with IPv6 as the minimum fragment size is pretty large. Man= ipulating TCP headers (MSS, receive window) might help. Regards, Wolfgang Beck