Superhub : Bufferbloat - is it bad?

[MUD_Wizard]

https://www.youtube.com/watch?v=F1a-eMF9xdY

http://www.cablelabs.com/how-docsis-...ue-management/

http://www.cablelabs.com/wp-content/...QM_May2014.pdf

[Sephiroth]

I've never understood the concept of downstream buffer bloat. The data arriving is passed straight to the destination device.

Maybe something to do with e.g. A 200 meg circuit but a 100 meg link to the device - there would be some buffering if the arrival rate is 200 meg but then in TCP, semaphores between destination & source would start/stop data flow. Something like that.

[SnoopZ]

Just done another test, the connection gave me full speed at 156mbit, download bufferbloat rose to +1100ms, upload bufferbloat stays between +3ms to +23ms although right at the very end for a split second it did rise to +239ms but this doesn't always happen.

But as already said, i think my connection works perfectly since i was moved to 16 downstream channels on a new Arris CMTS, i am not sure if i was getting bufferbloat on my old CMTS.

It would be nice to know why some people see bufferbloat on VM and others don't though. I was originally Cambridge Cable before NTL/VM took it over if that makes any difference.

[Sephiroth]

Snoopz, I think that DSLReports are confusing the hell out of customeers.

Your downstream is VM's upstream. It seems to me that any bufferbloat they claim to detect when testing downstream speed (how do they detect it?) is in VM's transmission path.

[Ignitionnet]

The bloat's tested by monitoring latency during the upload and download sections of the tests and comparing to baseline, Seph.

[SnoopZ]

Are we saying the DSLreorts are miss reporting my connection bloat? Are there any alternatives to a bloat test i can do?

[Sephiroth]

Originally Posted by Ignitionnet

The bloat's tested by monitoring latency during the upload and download sections of the tests and comparing to baseline, Seph.

So it's simply latency re-branded as bufferbloat to scare the hell out of peops.

[Ignitionnet]

Originally Posted by Sephiroth

So it's simply latency re-branded as bufferbloat to scare the hell out of peops.

It's measuring how latency changes under load. That is the definition of buffer bloat. How long a ping can spend stuck behind the other traffic, in a buffer, before it gets dropped.

[Sephiroth]

Originally Posted by SnoopZ

Are we saying the DSLreorts are miss reporting my connection bloat? Are there any alternatives to a bloat test i can do?

To what end? Is there any VOIP problem in your circuit? Any gaming difficulty? If not, I think you're chasing shadows. I'm open to stand corrected, of course.

[SnoopZ]

Originally Posted by Sephiroth

To what end? Is there any VOIP problem in your circuit? Any gaming difficulty? If not, I think you're chasing shadows. I'm open to stand corrected, of course.

As far as i know i have no problem.

[Sephiroth]

Originally Posted by Ignitionnet

It's measuring how latency changes under load. That is the definition of buffer bloat. How long a ping can spend stuck behind the other traffic, in a buffer, before it gets dropped.

Since it is non-ping traffic that matters, the low priority ping has to wait. What's the big deal here? Of course latency changes under load. Realms of ...

[MUD_Wizard]

Originally Posted by Sephiroth

Your downstream is VM's upstream. It seems to me that any bufferbloat they claim to detect when testing downstream speed (how do they detect it?) is in VM's transmission path.

Yes, the upstream service flows corresponds to queues in the cable modem for out-going traffic and the downstream service flows corresponds to queues at the CMTS for sending traffic to the cable modem(s).

The bufferbloat test is measuring these queues.

Though I notice that DSLReports test on the CM upstream does not match my increase in latency to google, so is not an accurate representation of the bloat. The downstream bloat test seems to work fine though.


---------- Post added at 18:00 ---------- Previous post was at 17:51 ----------

Originally Posted by SnoopZ

It would be nice to know why some people see bufferbloat on VM and others don't though. I was originally Cambridge Cable before NTL/VM took it over if that makes any difference.

For downstream bloat it depends on the situation and configuration at the CMTS, so it would be area specific and possibly CMTS type specific (because different CMTS's are configured differently and have different options).

[Sephiroth]

The downstream bloat test is totally meaningless, the way I see it. As load grows (towards all destinations from the CMTS), so does latency and pings get relegated. What's the big deal?

[Ignitionnet]

Originally Posted by Sephiroth

Since it is non-ping traffic that matters, the low priority ping has to wait. What's the big deal here? Of course latency changes under load. Realms of ...

On things like Superhubs and the CMTS that feed them the ping doesn't have any priority, low or otherwise. Everything is treated equally.

CMTS sending pings to end users treats it with the same priority as other traffic. The big routers only prioritise traffic that has them as the destination unless told otherwise.

Control plane versus forwarding plane. Traffic for router takes control plane, traffic passing through router forwarding plane.

[Eeeps]

How would these result be impacted by Weighted Fair Queuing though?

In that case I'd guess the bloat measurement would start high and then reduce as the data payload packets get deprioritised.