[Bloat] CFP: Workshop on Reducing Internet Latency
neil.davies at pnsol.com
Tue Dec 10 02:54:46 EST 2013
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?
On 10 Dec 2013, at 06:48, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> On Mon, 9 Dec 2013, Matthew Ford wrote:
>> The report of the Reducing Internet Latency workshop is now available:
> Reading through this I generally like it. It's a good summary and introduction.
> 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;"
> 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.
> 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.
> 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.
> Mikael Abrahamsson email: swmike at swm.pp.se
> Bloat mailing list
> Bloat at lists.bufferbloat.net
More information about the Bloat