From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "tcmail73.telekom.de", Issuer "TeleSec ServerPass CA 1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D928B201A85 for ; Tue, 17 May 2011 00:40:05 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 17 May 2011 09:49:21 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 17 May 2011 09:49:11 +0200 From: To: Date: Tue, 17 May 2011 09:49:10 +0200 Thread-Topic: [Bloat] Jumbo frames and LAN buffers (was: RE: Burst Loss) Thread-Index: AcwSeGr5GRAV4kjKS3WEXWDfi+zxIgB6xnFQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E2CF76@HE111648.emea1.cds.t-internal.com> 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> In-Reply-To: <8A928839-1D91-4F18-8252-F06BD004E37D@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 17 May 2011 07:40:06 -0000 (I think) Fred wrote: > Well, the extra delay is solvable in the transport. The question isn't re= ally what the impact on the > network is; it's what the requirements of the= application are. For voice, if a voice sample is > delayed 50 ms the jitter buffer in the codec resolves that - microseconds= are irrelevant. If you meant 50 microseconds, ignore the rest of this post. 50 milliseconds is a *long* time in VoIP. The total mouth-to-ear delay budg= et is only 150 ms. Adaptive jitter buffer algorithms choose a buffer size t= hat is bigger than the observed delay variation. So the additional delay wi= ll be even higher than 50 ms. Big frames are a problem on slower upstream links, even if you strictly pri= oritize VoIP and don't use jumbo frames. Some DSL providers resort to using= two ATM VCs, just to prevent TCP packets from delaying VoIP. Wolfgang Beck -- Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 61516282832 (Tel.) http://www.telekom.com Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, = Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Erleben, was verbindet.