From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (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 86D56201B71 for ; Thu, 10 Jan 2013 05:01:57 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r0AD1ods019055; Thu, 10 Jan 2013 05:01:51 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E63A25D3647; Thu, 10 Jan 2013 08:01:50 -0500 (EST) To: David Lang From: Mark Allman In-Reply-To: <3d007482e186836ea9d3a783431c765a@lang.hm> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Finishing Touches X-URL-0: http://www.icir.org/mallman-files/Document35376.docx X-URL-1: http://www.icir.org/mallman-files/Document16339.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma48060-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 10 Jan 2013 08:01:50 -0500 Sender: mallman@icir.org Message-Id: <20130110130150.E63A25D3647@lawyers.icir.org> Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Bufferbloat Paper X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: mallman@icir.org 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:01:57 -0000 ----------ma48060-1 Content-Type: text/plain Content-Disposition: inline > > (2) The network I am monitoring looks like this ... > > > > LEH -> IHR -> SW -> Internet -> REH > > > > where, "LEH" is the local end host and "IHR" is the in-home > > router provided by the FTTH project. The connection between the > > LEH and the IHR can either be wired (at up to 1Gbps) or wireless > > (at much less than 1Gbps, but I forget the actual wireless > > technology used on the IHR). The IHRs are all run into a switch > > (SW) at 1Gbps. The switch connects to the Internet via a 1Gbps > > link (so, this is a theoretical bottleneck right here ...). The > > "REH" is the remote end host. We monitor via mirroring on SW. > > > > The delay we measure is from SW to REH and back. > > The issue is that if the home user has a 1G uplink to you, and then > you hae a 1G uplink to the Internet, there is not going to be very > much if any congestion in place. The only place where you are going > to have any buffering is in your 1G uplink to the Internet (and only > if there is enough traffic to cause congestion here) > > In the 'normal' residential situation, the LEH -> THR connection is > probably 1G if wired, but the THR -> SW connection is likely to be > <1M. Therefor the THR ends up buffering the outbound traffic. (I assume 'THR' is what I called 'IHR'.) You are too focused on the local side of the network that produced the traffic and you are not understanding what was actually measured. As I say above, the delays are measured from SW to REH and back. That *does not* involve the LEH or the IHR in any way. Look at the picture and think about it for a minute. Read my email. Read email from others' that has also tried to clarify the issue. Let me try one more time to be as absolutely explicit as I can be. Say, ... - LEH sends a data packet D that is destined for REH at time t0. - D is forwarded by IHR at time t1. - D is both forwarded by SW and recorded in my packet trace at time t2. - D traverses the wide area Internet and arrives at REH (which is whatever LEH happens to be talking to; not something I control or can monitor) at time t3. - At time t4 the REH will transmit an ACK A for data packet D. - A will go back across the wide-area Internet and eventually hit SW at time t5. A will be both forwarded to IHR and recorded in my packet trace at this time. - A will be forwarded by IHR at time t6. - A will arrive at LEH at time t7. The RTT sample I will take from this exchange is t5-t2. Your discussion of focuses on t7-t5 (the downlink) and t2-t0 (the uplink). In other words, you are talking about something different from what is presented in the paper. If you want to comment on the paper, that is fine. But, you should comment on what the paper says or what the paper is lacking and not try to distort what the paper presents. I fully understand that these FTTH links to the Internet are abnormal. And, as such, if I were looking for buffers on the FTTH side of things that'd be bogus. But, I am not doing that. Regardless of how many times you say it. The measurements are not of 90 homes, but of 118K remote peers that the 90 homes happened to communicate with (and the networks used to reach those 118K peers). If it helps, you can think of the 90 homes as just 90 homes connected to the Internet by whatever technology (DSL, cable, fiber, wireless ...). The measurements are not concerned with the networks inside of connecting these 90 homes. Look, I could complain about my own paper all day long and twice as much on Sunday. There are plenty of ways it is lacking. Others could no doubt do the same. I have tried hard to use the right perspective and to say what this data does and does not show. I have done that on this list and in the paper itself. E.g., these are the first two bullets in the Future Work section: \item Bringing datasets from additional vantage points to bear on the questions surrounding bufferbloat is unquestionably useful. While we study bufferbloat related to 118K peers for some modest period of time (up to one week), following more peers and over the course of a longer period would be useful. \item While we are able to assess 118K peers, we are only able to do so opportunistically when a host on the network we monitor communicates with those peers. A vantage point that provides a more comprehensive view of residential peers' behavior would be useful. So, complain away if you'd like. I don't mind at all. But, at least complain about what is in the paper and what is actually measured. Please. allman ----------ma48060-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlDuu74ACgkQWyrrWs4yIs7nQQCggCRKt3kcXMxlfaN5kaZ7iMXx GxsAnA0ayb4MBBSdtKq5y7mO1Uyf9H8j =7bpi -----END PGP SIGNATURE----- ----------ma48060-1--