From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailgw1.ericsson.se", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C07F120064E for ; Tue, 5 Jun 2012 07:32:56 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-d9-4fce18931740 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 83.67.28636.3981ECF4; Tue, 5 Jun 2012 16:32:51 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.2.32]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 5 Jun 2012 16:32:51 +0200 From: Ingemar Johansson S To: "bloat@lists.bufferbloat.net" , "hqjiang1988@gmail.com" Date: Tue, 5 Jun 2012 16:32:49 +0200 Thread-Topic: Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution Thread-Index: Ac1ChEaWB90hB7t4RfOt6+w/UXUCPgAoo7wA Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvre5kiXP+Brs3q1j0/7rParFw2w9G i7Nnn7Fa7Nl4ksXia+dmVgdWj9Nnmpg8ds66y+6x/eIZpgDmKC6blNSczLLUIn27BK6M1s/v 2AteiFf0P+pnb2B8L9zFyMkhIWAiseHMH0YIW0ziwr31bCC2kMApRomdHVEQ9nxGiWs7PEFs NgEbiZWHvoPViwgUSWz8d5S1i5GLg1mgH6j+bxtYgkVARWLj700sILawQIjEg2vn2SAaQiUe vbvOCmEbSfxpuANWwysQLvH69xxWiGXOEh/mfWYCsTkFXCR+r1wLNpNRQFbi/vd7YPXMAuIS t57MZ4I4WkBiyZ7zzBC2qMTLx/9YIeplJE4t+s8KUa8jsWD3JzYIW1ti2cLXzBB7BSVOznzC MoFRbBaSsbOQtMxC0jILScsCRpZVjMK5iZk56eWGeqlFmcnFxfl5esWpmxiBMXZwy2/dHYyn zokcYpTmYFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXH2BLl7Fj0PPHnaTwpO /tx+8+9zy4/MF57ZKO917uhW2OexoOlp0qQvmhfOc86Pl9n1ZeZL90t726RuNrR+vLImZfaW mKtJrw9MOKduEid9yNJcoHRHglN28zPF5Vnc93dtXVy48m+8fmeE5sKciESZpTVvHwfN3fjq iXXm5s2Fu1dfTu6u0DdWYinOSDTUYi4qTgQAn/sdrn8CAAA= Cc: "dada1@cosmosbay.com" Subject: Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution 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, 05 Jun 2012 14:32:58 -0000 Hi And thanks for an interesting report. I must say that this resembles LEDBAT= quite a lot, with the exception that LEDBAT is a (mainly) sender based mod= ification and may thus be easier to deploy. Like commented on this list (by= Jonathan Morton for instance) it could be interesting to see how they comp= are.=20 One flaw with delay based algos (which LEDBAT tries to solve) is the sensit= ivity to reverse path delay (similar issue with Vegas I believe), I guess y= our algorithm can have the same problem or. Does not mean that LEDBAT is fr= ee of problem... Regards /Ingemar Johansson =20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Sun, 3 Jun 2012 18:32:49 -0700 > From: Haiqing Jiang > To: Eric Dumazet , Dave Taht > > Cc: bloat@lists.bufferbloat.net > Subject: [Bloat] Tackling bufferbloat in 3G/4G networks: A > receiver-based TCP solution. > Message-ID: > =09 > > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Hi, All, >=20 > Recently the researchers from Networking Research Group of=20 > North Carolina State University (NCSU) have proposed an=20 > interesting receiver-based TCP solution to tackle bufferbloat=20 > in 3g/4g networks. >=20 > They conducted extensive measurements in four major carriers=20 > in US and the largest carrier in Korea to verify the severe=20 > bufferbloat problem in currently commercial cellular=20 > networks. They cited the work from Bufferbloat group and=20 > further extended the work to cellular networks. Furthermore,=20 > they revealed the untold implementation of TCP, an ad-hoc=20 > solution to mitigate bufferbloat, in smartphone's network=20 > stack (Android platform). The ad-hoc solution is sub-optimal=20 > in many scenarios. > Actually it merely mitigate bufferbloat problem in some scenarios. > Therefore, the guys from NCSU propose a "Dynamic Receive=20 > Window Adjustment" > scheme to tackle bufferbloat problem. The extensive=20 > experiment results prove that the scheme is efficient and=20 > light-weight. >=20 > It's really excited to find the new direction to tackle=20 > bufferbloat, on TCP layer instead of routers (like AQM). The=20 > bufferbloat problem actually seems to be the most prominent,=20 > comparing with other networks. > Therefore, we suggest the more efforts to tackling=20 > bufferbloat problem in cellular networks and seeking a good=20 > solution in TCP layer space. >=20 > The link is attached: > ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2012/TR > -2012-6.pdf >=20 > Thanks, >=20 > -- > ----------------------------------- > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > 20603/e71887b8/attachment-0001.html> >=20 > ------------------------------ >=20