From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp120.iad.emailsrvr.com (smtp120.iad.emailsrvr.com [207.97.245.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 342AC208AAD for ; Thu, 10 Jan 2013 05:48:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp52.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D76C0240493; Thu, 10 Jan 2013 08:48:18 -0500 (EST) X-Virus-Scanned: OK Received: from legacy21.wa-web.iad1a (legacy21.wa-web.iad1a.rsapps.net [192.168.2.207]) by smtp52.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id BB1ED2405EE; Thu, 10 Jan 2013 08:48:18 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy21.wa-web.iad1a (Postfix) with ESMTP id ABE681CE806A; Thu, 10 Jan 2013 08:48:18 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 10 Jan 2013 08:48:18 -0500 (EST) Date: Thu, 10 Jan 2013 08:48:18 -0500 (EST) From: dpreed@reed.com To: "Keith Winstein" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130110084818000000_42824" Importance: Normal X-Priority: 3 (Normal) X-Type: html Message-ID: <1357825698.70265109@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "end2end-interest@postel.org" , "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] [e2e] bufferbloat paper 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, 10 Jan 2013 13:48:20 -0000 ------=_20130110084818000000_42824 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A=0AThese observations are easily explained by a) excessive refusal to si= gnal congestion on each separate link (multiple seconds of buffering withou= t drops or ECN), plus b) a contended upstream bottleneck.=0A =0AIn other wo= rds, exactly the same phenomenon encountered in Comcast's "DOCSIS plant".= =0A =0AI appreciate the actual willingness to look at data, despite the lac= k of cooperation of Verizon Wireless in providing access to the actual desi= gn and its parameters.=0A =0ATrue expermental work, rather than presuming t= his has to do with "interference" in the radio space, and not bothering to = verify that. Yay!=0A =0AHowever, I worry aboutect those with a huge person= al investment in seeing "wireless" as different, and in promoting research = based on false assumptions will continue to try to explain the observations= with bizarre and complex explanations. If there is a different explanatio= n, develop an experiment that will discriminate between that hypothesis and= the one above (the bufferbloat is important on LTE systems hypothesis), an= d *do the experimental measurement*.=0A =0A-----Original Message-----=0AFro= m: "Keith Winstein" =0ASent: Thursday, January 10, 2013 2:3= 7am=0ATo: "Michael Richardson" =0ACc: "bloat@lists.buffer= bloat.net" , "end2end-interest@postel.org" , "mallman@icir.org" =0ASubject= : Re: [e2e] [Bloat] bufferbloat paper=0A=0A=0A=0AHello Michael,=0A=0AOn Wed= , Jan 9, 2013 at 9:07 AM, Michael Richardson wrote:=0A> = Have you considered repeating your test with two phones?=0A=0AYes, we have = tried up to four phones at the same time.=0A=0A> Can the download on phone1= affect the latency seen by a second phone?=0A=0AIn our experience, a downl= oad on phone1 will not affect the unloaded=0Alatency seen by phone2. The ce= ll towers appear to use a per-UE=0A(per-phone) queue on uplink and downlink= . (This is similar to what a=0Acommodity cable modem user sees -- I don't g= et long delays just=0Abecause my neighbor is saturating his uplink or downl= ink and causing a=0Astanding queue for himself.)=0A=0AHowever, a download o= n phone1 can affect the average throughput seen=0Aby phone2 when it is satu= rating its link, suggesting that the two=0Aphones are contending for the sa= me limited resource (timeslices and=0AOFDM resource blocks, or possibly jus= t backhaul throughput).=0A=0A> Obviously the phones should be located right= next to each other, with=0A> some verification that they are actually asso= ciated to the same tower.=0A=0AThis is harder than we thought it would be -= - the phones have a=0Atendency to wander around rapidly among cell IDs (som= etimes switching=0Aseveral times in a minute). We're not sure if the differ= ent cell IDs=0Areally represent different towers (we doubt it) or maybe jus= t=0Adifferent LTE channels or logical channels. I understand in LTE it is= =0Apossible for multiple towers to cooperate to receive one packet, so=0Ath= e story may be more complicated.=0A=0AIn practice it is possible to get fou= r phones to "hold still" on the=0Asame cell ID for five minutes to do a tes= t, but it is a bit like=0Aherding cats and requires some careful placement = and luck.=0A=0ABest regards,=0AKeith ------=_20130110084818000000_42824 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= =0A

These observations are easil= y explained by a) excessive refusal to signal congestion on each separate l= ink (multiple seconds of buffering without drops or ECN), plus b) a contend= ed upstream bottleneck.

=0A

 

=0A

In other words, exactly the same phenomenon encountered in Comcast's "DO= CSIS plant".

=0A

&= nbsp;

=0A

I apprec= iate the actual willingness to look at data, despite the lack of cooperatio= n of Verizon Wireless in providing access to the actual design and its para= meters.

=0A

 =

=0A

True expermen= tal work, rather than presuming this has to do with "interference" in the r= adio space, and not bothering to verify that.  Yay!

=0A

 

=0A

However, I worry aboutect those with a = huge personal investment in seeing "wireless" as different, and in promotin= g research based on false assumptions will continue to try to explain the o= bservations with bizarre and complex explanations.  If there is a diff= erent explanation, develop an experiment that will discriminate between tha= t hypothesis and the one above (the bufferbloat is important on LTE systems= hypothesis), and *do the experimental measurement*.

=0A

 

=0A

-----Original Message-----
From: "Keit= h Winstein" <keithw@mit.edu>
Sent: Thursday, January 10, 2013 2:= 37am
To: "Michael Richardson" <mcr@sandelman.ca>
Cc: "bloat= @lists.bufferbloat.net" <bloat@lists.bufferbloat.net>, "end2end-inter= est@postel.org" <end2end-interest@postel.org>, "mallman@icir.org" <= ;mallman@icir.org>
Subject: Re: [e2e] [Bloat] bufferbloat paper

=0A
=0A

Hello Michael,

On Wed, Jan 9, 201= 3 at 9:07 AM, Michael Richardson <mcr@sandelman.ca> wrote:
> = Have you considered repeating your test with two phones?

Yes, we= have tried up to four phones at the same time.

> Can the dow= nload on phone1 affect the latency seen by a second phone?

In ou= r experience, a download on phone1 will not affect the unloaded
latenc= y seen by phone2. The cell towers appear to use a per-UE
(per-phone) q= ueue on uplink and downlink. (This is similar to what a
commodity cabl= e modem user sees -- I don't get long delays just
because my neighbor = is saturating his uplink or downlink and causing a
standing queue for = himself.)

However, a download on phone1 can affect the average t= hroughput seen
by phone2 when it is saturating its link, suggesting th= at the two
phones are contending for the same limited resource (timesl= ices and
OFDM resource blocks, or possibly just backhaul throughput).<= br />
> Obviously the phones should be located right next to each o= ther, with
> some verification that they are actually associated to= the same tower.

This is harder than we thought it would be -- t= he phones have a
tendency to wander around rapidly among cell IDs (som= etimes switching
several times in a minute). We're not sure if the dif= ferent cell IDs
really represent different towers (we doubt it) or may= be just
different LTE channels or logical channels. I understand in LT= E it is
possible for multiple towers to cooperate to receive one packe= t, so
the story may be more complicated.

In practice it is = possible to get four phones to "hold still" on the
same cell ID for fi= ve minutes to do a test, but it is a bit like
herding cats and require= s some careful placement and luck.

Best regards,
Keith

= =0A
=0A

 ------=_20130110084818000000_42824--