On May 3, 2010, at 9:19 PM, Patrick Giagnocavo wrote:

...

- do ISPs typically use token bucket filters with large bursts to shape traffic? - what kind of burst sizes and latencies/limits are typically used for the filter?

You will definitely have to account for latency.

For emulating cable traffic, latencies (in the USA) will be about 60-80ms to typical sites. Burst mode in my experience occurs only for about the first 15 seconds, then is throttled back (though not always; seems to depend on time of day).

And queues of 1 second at line rate are not uncommon, so if you load the link, things lag.

For DSL, I seem to recall latency being about 90-110ms (note, I haven't used DSL in many years). Burst mode was generally not noticeable or available, that is, you got the same speed regardless of downloading a 1MB jpeg or a 640MB .iso file.

Now more typically 40ms. And yeah, no bursts over normal line rate. Most turn down line rate for other plans, not shape.

On Tue, May 4, 2010 at 08:54 UTC, Raymond Dijkxhoorn wrote, quoting Patrick:

...

For emulating cable traffic, latencies (in the USA) will be about 60-80ms to typical sites. [...] For DSL, I seem to recall latency being about 90-110ms (note, I haven't used DSL in many years). [...] The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor 4...

Either you're looking only at the loop contribution, or you're in the SF bay area and nearly every "typical site" is available locally. Here in the relatively backwater Seattle suburbs, unless it's served by Microsoft or a content distribution network, there are substantial latencies to typical sites. To make it concrete I used Windows ICMP tracert against a few sites from both cable and DSL in the Seattle suburbs. First from a consumer-grade cable offering: http://pastebin.com/TGc6xsHk Then from a business-class telco DSL (complete with more than 1 static IP, someone tie me down lest my soul escape my body from sheer joy!): http://pastebin.com/DMrsiUQf Note I made no attempt to ensure I was tracing to the same numeric IP address from both, and the tests were simultaneous. Cheers, Dave Hart P.S. A special flip of the bird to those IWFs who filter all ICMP at the edge and break path MTU detection.

On May 4, 2010, at 8:02 AM, Dave Hart wrote:

On Tue, May 4, 2010 at 08:54 UTC, Raymond Dijkxhoorn wrote, quoting Patrick:

...

...

For emulating cable traffic, latencies (in the USA) will be about 60-80ms to typical sites. [...] For DSL, I seem to recall latency being about 90-110ms (note, I haven't used DSL in many years). [...] The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor 4...

Either you're looking only at the loop contribution, or you're in the SF bay area and nearly every "typical site" is available locally. Here in the relatively backwater Seattle suburbs, unless it's served by Microsoft or a content distribution network, there are substantial latencies to typical sites.

I am not sure what the point is in mixing in speed of light latency. If your "typical sites" are, say, Indian cricket blogs, you will typically have a high latency from the US. What does that tell you about your DSL or Cable system, except that it is somewhat removed from India ? Regards Marshall

To make it concrete I used Windows ICMP tracert against a few sites from both cable and DSL in the Seattle suburbs. First from a consumer-grade cable offering:

http://pastebin.com/TGc6xsHk

Then from a business-class telco DSL (complete with more than 1 static IP, someone tie me down lest my soul escape my body from sheer joy!):

http://pastebin.com/DMrsiUQf

Note I made no attempt to ensure I was tracing to the same numeric IP address from both, and the tests were simultaneous.

Cheers, Dave Hart

P.S. A special flip of the bird to those IWFs who filter all ICMP at the edge and break path MTU detection.

same as in the HFC and QAM modulation values and so on and so forth ..... services that are requiring a connection-oriented service such as a gaming clan/cloud are highly affected when working in latency and jitter network based environments such as the ethernet based ones and SMDS ....... ----- Original Message ---- From: Chris Boyd <cboyd@gizmopartners.com> To: NANOG <nanog@nanog.org> Sent: Tue, May 4, 2010 2:19:39 PM Subject: Re: Emulating ADSL bandwidth shaping On May 4, 2010, at 7:27 AM, Marshall Eubanks wrote:

I am not sure what the point is in mixing in speed of light latency. If your "typical sites" are, say, Indian cricket blogs, you will typically have a high latency from the US. What does that tell you about your DSL or Cable system, except that it is somewhat removed from India ?

Most of the ADSL installations I've seen in SBC 13 state area had interleaving turned on, which significantly increases latency.  I suspect that's why many cable MSOs in the same territory have "cable is better for gaming" marketing campaigns running all the time. So the latency you see on an ADSL line is dependent on how the carrier set up the DSLAM. --Chris

On Tue, 4 May 2010 16:44:06 +0200 (CEST) Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Tue, 4 May 2010, Chris Boyd wrote:

...

Most of the ADSL installations I've seen in SBC 13 state area had interleaving turned on, which significantly increases latency. I suspect that's why many cable MSOs in the same territory have "cable is better for gaming" marketing campaigns running all the time.

So the latency you see on an ADSL line is dependent on how the carrier set up the DSLAM.

Interleaving is good because it reduces bit error rate on the line. Would be good though if the carrier let the customer change the properties of the line to optimize for different things, high snr target/no interleaving for low bw/low BER/low latency applications, low snr target/interleaving for file transfers.

It's common for ISPs in Australia who own their own DSLAMs to do this via 'line profiles'. I'm on the most aggressive one, and have line latency of around 9.5 to 10ms. Also what is interesting is that ADSL firmware in the modem can contribute significantly. I used to need to be on ADSL1 with interleaving to get any sort of reliable line sync. After a modem firmware upgrade, which I knew also involved an ADSL chipset firmware upgrade, I didn't get any more bandwidth, but was able to get stability (i.e. no loss of sync for weeks on end) without interleaving. Regards, Mark.