From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by huchra.bufferbloat.net (Postfix) with ESMTP id C6CFE21F212 for ; Thu, 31 Oct 2013 01:43:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 97700105EA8; Thu, 31 Oct 2013 09:38:13 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3sshVFvlXX7; Thu, 31 Oct 2013 09:38:13 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7C0FB105D49; Thu, 31 Oct 2013 09:37:58 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.11]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 31 Oct 2013 09:43:20 +0100 From: Dirk Kutscher To: Mikael Abrahamsson , Stephen Hemminger Thread-Topic: [Bloat] T-Mobile LTE buffer bloat Thread-Index: AQHO1cdwxZK/Ar+1DkCwjpttrYP3y5oN1MAAgAAGjwCAAAE9AIAAnqMA Date: Thu, 31 Oct 2013 08:43:20 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524963829BA1@PALLENE.office.hd> References: <20131030162534.29f34ada@nehalam.linuxnetplumber.net> <20131030165740.26505b62@nehalam.linuxnetplumber.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] T-Mobile LTE buffer bloat 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: Thu, 31 Oct 2013 08:43:58 -0000 Also, it would be important to understand what radio access technology the = LTE-WiFi-GW was really using at the time of the measurement. In hybrid GSM/= UMTS/LTE networks (like T-Mobile's), mobile phones frequently fall back to = GSM (GPRS), so you cannot blame LTE in this case. There are many myths around bufferbloat in mobile networks. You really need= to understand the specifics of the network, its utilization at a given tim= e -- and the deficiencies of the gear you are using. Having said that, in LTE there are apparently significant differences in la= tency (variation) depending on the operator and equipment vendor. For examp= le, I have seen LTE measurements from hotspot areas in Tokyo that still loo= ked much better (max 60 ms uplink delay) than what I hear sometimes from fr= iends in the US. It's about time for structured measurement campaign that helps us to analyz= e this better. Best regards, Dirk > -----Original Message----- > From: bloat-bounces@lists.bufferbloat.net [mailto:bloat- > bounces@lists.bufferbloat.net] On Behalf Of Mikael Abrahamsson > Sent: Donnerstag, 31. Oktober 2013 01:02 > To: Stephen Hemminger > Cc: bloat@lists.bufferbloat.net > Subject: Re: [Bloat] T-Mobile LTE buffer bloat >=20 > On Wed, 30 Oct 2013, Stephen Hemminger wrote: >=20 > > There is zero configuration of proxy, it is just a LTE <-> wifi hotspot= . > > I suspect some caching (or commercial interest) at their end. >=20 > I have no insight in how T-Moble does things, but I know that vendors pit= ch > video/image compression stuff and you want to put it *before* it goes out > the radio network (because that's the expensive resource), so that's why = my > guess it's doing the image-rewriting not in the end user box, but in a ce= ntrally > placed device in their network. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat