From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 853B73B2A0 for ; Sat, 18 Jun 2016 06:10:15 -0400 (EDT) Received: by mail-lf0-x235.google.com with SMTP id f6so11811716lfg.0 for ; Sat, 18 Jun 2016 03:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=904udUeaRx17dDcIQW9ieM43WVlv0dL+1OzGmPZulRE=; b=mGDFV4DdewAsdu6ykS9W0JI7LXDTtDmvc6h3OW1QLSMR+TzTEjb4vGNSNcfCPTCGDA 2RsFhAcU2V8yJ1ELiiveJwljQpOwuPYFd//Bt17cLptfN0y9LpVEobxCxjo3EsdvpNa6 xyZF9pCk5cj50mSeR//SI/zfR2f3ZE1jejrxtVIkObqllNZo4eDNZvmSY1b2lg2y1LZn IseZR7iGraaoBNP6zCMdhrv3+cjKQDz8bTnw3VTm80VxattruQBWKwh5+geiFdcz0mYu ud+iMD+g2jOnWlyZshHNES+QEvzhhxxkLT+JGB/r1OeqrmpMBhQIL6J4IkaF0tWGz8q/ XFCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=904udUeaRx17dDcIQW9ieM43WVlv0dL+1OzGmPZulRE=; b=gU9hAqvjyejgZoGHmIfIp99ldYDdyXrvP8NwU2EpdLv5JkSMXY+A1GwiCqZ0lTMqZ3 38YNo31TPksdtUElRqYIthZZH8LSLd9qnLc/B2gZSlegK2j1ZQesO0hdyyahTHcEz02M KuSIZGJ0aNWWNBrL2H54SooZgLR/anQO963fcs2oraMVMU74CzTs6yPzlUOSYN1E5Ux/ uPSpXQCYKefIV1+mQFZRFEdvXKBkQrEz6AbLxMxM2/QQtKZNvdJwiSydlVS77RBnsRv+ Y19uRQkZD1l1NBiCookU/4ASw5J0+ezDBmM151BU6Ua0PM/NnqZHDuvMQc99G8FjW7Ws IYig== X-Gm-Message-State: ALyK8tJx/DRycOZNoV9SB582lWihFmXMVyaJeqY7p5FMexKNMOvLm3CmvAX1EGAosIzPDg== X-Received: by 10.25.23.72 with SMTP id n69mr1943328lfi.64.1466244613743; Sat, 18 Jun 2016 03:10:13 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-112-183.bb.dnainternet.fi. [37.33.112.183]) by smtp.gmail.com with ESMTPSA id 89sm2497145lja.35.2016.06.18.03.10.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Jun 2016 03:10:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <57650074.90106@gmail.com> Date: Sat, 18 Jun 2016 13:09:57 +0300 Cc: bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <57650074.90106@gmail.com> To: Jan Ceuleers X-Mailer: Apple Mail (2.3124) Subject: Re: [Bloat] ultrafast broadband conference june 27-30 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 10:10:15 -0000 > On 18 Jun, 2016, at 11:04, Jan Ceuleers = wrote: >=20 > As I'm sure everyone here knows DSL uses interleaving in order to > achieve coding gain in the face of impulse noise. DSL has to operate = in > environments that are rich in such noise so although it is possible to > turn interleaving off pretty much every operator has it on, if for no > other reason than to avoid IPTV artefacts. >=20 > This does not meet at least my understanding of the definition of > bufferbloat, in that interleaving introduces a static amount of = latency > (i.e. latency that does not vary with load). >=20 > But it's perhaps also not what you were talking about because you > mentioned the uplink. Not sure what you meant. Still, other than the = use > of ATM and coding I'm not aware of buffering in DSL. Certainly no > dynamic buffers that absorb traffic under load. >=20 > Could you enlighten me? I know that you're a busy man; a few keywords > for me to stick into google would be great. These buffers are not inherent to the link technology. If they were, = we=E2=80=99d be calling for different link technology. Rather, they are = contained in the devices at each end of the link. It is the device at = the *entry* to the link which matters; a device at the ISP end for the = downlink, and at the customer end for the uplink. Consider a railway with frequent, direct services between two popular = cities - take Osaka and Tokyo, connected by the Tokaido Shinkansen, for = a realistic example. Each train can carry several hundred passengers; = if there aren=E2=80=99t enough seats for everyone waiting, some = passengers will be left on the platform (the days of stuffing commuters = onto trains are over, even in Tokyo). Only so many trains per hour will fit on the track, however fast they = travel along it; indeed, the faster they go, the fewer can be scheduled, = because braking distance scales with the square of speed, and trains are = kept a full braking distance apart. And it is hard to make trains = longer than they are already; the 16-car Series 700 trains are already = nearly a quarter-mile long, and passengers just don=E2=80=99t want to = walk that far. These factors limit the passenger-carrying capacity of the entire = railway, to the point where a second high-speed railway (the Chu=CC=84o=CC= =84 Shinkansen) is being built between the same two cities, along a = different route. However, it is not yet complete and won=E2=80=99t be = for some years. Now consider the choices made by each station=E2=80=99s architect. He = can only provide a certain number of platforms to hold trains for = efficient cleaning and loading - both are very crowded cities. Leaving = customers on the platform is also bad for business, both in terms of = revenue and reputation. So on the fastest trains which run non-stop = between the major cities, all the seats are to be reserved for = individual passengers. A reservation can be booked the same day, at the = station, but before reaching the platform. So passengers are directed to a platform where they can always find a = seat on the train waiting there - but *until* the train is waiting = there, they must wait in the concourse. So the architect builds a large = and pleasant concourse with lots of cafes and bookshops and waiting = benches and so on. There is plenty of space to do so *above* the = Shinkansen platforms, not to mention above the platforms of the huge = commuter station next door. This suits tourists and holidaymakers just fine. They don=E2=80=99t = mind waiting as much as an hour in a pleasant concourse at busy times of = the day. It=E2=80=99s all part of the journey. But to a business traveller, time is money, and he has a meeting = appointment in the other city which he Must Not be late for. (You know = these modern Japanese business practices=E2=80=A6) If he regularly has to wait an hour to get a seat on a train, he=E2=80=99s= just as likely to turn around and book a flight next time. It=E2=80=99s = almost as fast, door to door, and the extra cost is just a business = expense. If tourists and holidaymakers take up seats that he might have = been able to use, the railway is no longer useful to him. The concourse is the buffer, and the simplistic reservation system = represents a basic FIFO queue. How the railway actually copes with this problem is by charging extra = for reserved seats, premier-class seats and for the fastest trains. = This encourages tourists and holidaymakers to take the slightly slower = all-stops trains which have a generous allocation of unreserved seats, = leaving the fastest trains entirely for people in a genuine hurry. = People also generally make reservations in advance when possible, to = ensure they get on a train at their preferred time. There are still = people waiting in the concourse, but they=E2=80=99re not the people who = particularly mind waiting. This solution is roughly equivalent to =E2=80=9Cfair queuing=E2=80=9D or = =E2=80=9Cflow isolation=E2=80=9D, though the analogy is imperfect since = no money or resource exchange is involved in Internet queuing systems. Taking the analogy further, let=E2=80=99s look at what happens if too = many people are waiting for trains, so the concourse fills up despite = its size. This will always happen if people continuously arrive at a = greater rate than the railway=E2=80=99s capacity. The waiting time = grows to five hours, which is intolerable for even the most patient = tourists. The cafes sell out of sandwiches and coffee, and shut their = doors. Passengers who read the writing on the wall and booked a week in = advance have to fight through the crowd to reach the platforms. It=E2=80=99s dangerous to have too many people in an enclosed space; you = tend to get stampedes, especially if something alarming happens. So the = police are called in to keep order; they stop people going in (including = people with prior reservations, who then miss their train and are angry = about it, while that much capacity on departing trains goes unused), and = arrest people who have started fighting over who was first in the queue = for the ticket office. Or the toilets - it=E2=80=99s hard to tell which = queue is which any more, as it=E2=80=99s just a solid mass of humanity. = Keeping order in such a big concourse is *hard* - the police have = difficulty moving in the crowd too. If the concourse hadn=E2=80=99t been built so large, keeping order would = be easier. The problem would have been spotted earlier, before the = waiting time grew so long and people started shoving each other in the = queues. The booking office could sensibly have been placed by the front = doors, so people would know how long they had to wait before they even = got inside. People with prior reservations wouldn=E2=80=99t have had so = much of a crowd to fight through. The cafes and bookshops simply set up = in the plaza outside, instead of in the concourse itself, and people = waiting can circulate more freely. Similarly, there is an optimum size for a FIFO queue: it is related to = the link capacity, the expected RTT of paths using the link, and the = number of simultaneous flows. Specifically (and IIRC), it is = Bandwidth*RTT/sqrt(flows). This is in itself a dynamic quantity, but it = is reasonably sensible to assume 1 flow and 100ms RTT for a consumer = Internet-edge link. Increasing the buffer size beyond that gives little = or no improvement in link utilisation efficiency, and increases delay = which is harmful. - Jonathan Morton