From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com [207.126.144.131]) (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 190E921F0A2 for ; Mon, 9 Dec 2013 23:54:53 -0800 (PST) Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP ID DSNKUqbIx3MuKNGgqdzSpcLBG2vCmcod+/a+@postini.com; Tue, 10 Dec 2013 07:54:54 UTC Received: from ba6-office.pnsol.com ([172.20.5.199]) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1VqI9W-0008BO-SV; Tue, 10 Dec 2013 07:54:46 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Neil Davies In-Reply-To: Date: Tue, 10 Dec 2013 07:54:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1B54D30E-AB4D-4410-B1FB-CC93022B7C8F@pnsol.com> References: <26FB3C56-AF24-497C-943A-3FDAE7B88D08@isoc.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) Cc: bloat Subject: Re: [Bloat] CFP: Workshop on Reducing Internet Latency 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, 10 Dec 2013 07:54:54 -0000 Mikael Your statements about ADSL2+ are interesting; I've been looking at = deployments where the SNR is "ok" but (by measurement) 20% packet loss = is occurring. This state can last for several minutes, resolved by a = re-train (but that has to be initiated manually from the customer end). Our current "hypothesis" is that specific frequencies are suffering due = to very specific (narrow) changes in the transmission characteristics - = "slot filters" that come into existence (due to changes in environmental = conditions) then disappear. We've seen this even when we've played with the settings through the = customer portal (I'm' in the UK - the provisioning portal allows many = such changes). Are you capturing any evidence of DSL modem state when this occurs?=20 Neil On 10 Dec 2013, at 06:48, Mikael Abrahamsson wrote: > On Mon, 9 Dec 2013, Matthew Ford wrote: >=20 >> The report of the Reducing Internet Latency workshop is now = available: >>=20 >> = http://www.internetsociety.org/blog/2013/12/speeding-internet-reducing-lat= ency >=20 > Reading through this I generally like it. It's a good summary and = introduction. >=20 > However, this part: > "Hiding packet losses in broadband lines using interleaving can add = about 20ms of delay, even though modern transports and applications are = robust to such low packet loss levels;" >=20 > Having been part of a decently sized ADSL2+ deployment ISP, I have = some experience with this and the above doesn't match them. We actually = did get customer complaints when we were running ADSL2+ in fast-mode (no = interleaving), that the customers were getting packet losses that = affected their applications. >=20 > So I would have liked the above to not say "broadband lines" but = instead said ADSL(2+) broadband lines (because the above statement only = relates to ADSL(2+) afaik), and also that the packet losses can be = non-trivial for some and that ISPs don't turn on interleaving out of = ignorance. It's hard to measure customer impact of "errored seconds" = which is the only way the ISP can see packet losses. Also, these errored = seconds can be quite severer when it comes to number of packets dropped. >=20 > We actually did talk about having a self-service portal where the = customer could choose their preferred profile, either fast (no = interleaving), 4ms or 16 ms interleaving, and also their safety margin = to 6, 9 or 12 dB. Fast or 4ms interleaving worked well with 12 dB SNR = margin (which means lower latency but also lower access speeds), whereas = 6dB margin often required 16ms interleaving to work well. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat