[Bloat] The bigger picture: whats components are used together to fight bloat

[Bloat] The bigger picture: whats components are used together to fight bloat

[Jeroen Balduyck]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

I hope I can get a bit more information on what comprises the total
solution. But knitting it together proves a bit hard (for me at least).
Without this, it is hard to follow the discussions on the list. Has anyone
made a summary of how all of this works together?

So:

1. In order to move the bottleneck to a device under our administrative
control, we need to shape traffic (we need to become the bottleneck).
2. Next, we have the AQM-algorithms that manage the (or a) queue.
3. And then there are still issues with multiple flows and with UDP?

From what I understand, we need to shape traffic, and then drop packets
taking into account that the most aggressive flow (the flow that
contributes the most to filling a buffer), is the flow that will get the
most packets dropped. This to prevent the aggressive flow from impacting
flows that behave better.

Now for UDP, is the problem here that we cannot identify flows, and hence,
only have one queue for UDP whereas for TCP we can have multiple?

Any good resources are more than welcome:-)!

Thanks,
Jeroen

[-- Attachment #2: Type: text/html, Size: 1219 bytes --]

Re: [Bloat] The bigger picture: whats components are used together to fight bloat

[Michael Richardson]

>>>>> "Jeroen" == Jeroen Balduyck <jeroen.balduyck@gmail.com> writes:
    Jeroen> 1. In order to move the bottleneck to a device under our
    Jeroen> administrative 
    Jeroen> control, we need to shape traffic (we need to become the
    Jeroen> bottleneck). 

It turns out that this is often easy to do suboptimally, but in some
cases, it might not be very bad.  The two situations which I'm trying to
address are white label ("TPIA") ADSL and 3G termination, but my
understanding is that the various "PowerBoost" cable modem situations
are similar.

The issue with ADSL is twofold:  
  1) we don't know what speed the modem really sync'ed up at.
     We aren't the layer-2 ISP, and it isn't clear that in the case of
     third party access, that they even know how to manage the modem	
     to find out what really happened.
  
  2) the capacity of the back haul from the customer to the NNI is
     uncertain in many ways, and I think customers are not well enough
     protected from each other.    We know that in Canada the ATM
     network which back hauls the customers to the ISPs is very much
     under-provisioned:  the phone company has said so to the regulator.

I anticipate similar problems trying to provide VoIP over (initially:
stationary) 3G.   Two providers have promised me that I'll be able to do PPP
directly to the devices, but when they show me a price list, it's
clearly for whole(re)sale.   I think the sales people don't understand
that they are lying, so I have less details on this.

So the problem is that we can't always know what amount to shape things
with.   As I am working with a vendor of CPE and access devices which
says that they have an SDK, I attempting to put together a project to do
measurements.  I will control the layer-3 devices at each end of the PPP(oE)
link...   

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	



	
     

Re: [Bloat] The bigger picture: whats components are used together to fight bloat

[Mikael Abrahamsson]

On Thu, 2 May 2013, Michael Richardson wrote:

> I anticipate similar problems trying to provide VoIP over (initially: 
> stationary) 3G.  Two providers have promised me that I'll be able to do 
> PPP directly to the devices, but when they show me a price list, it's 
> clearly for whole(re)sale.  I think the sales people don't understand 
> that they are lying, so I have less details on this.

Even if you do ppp to the device, you're still not the bottleneck. Every 
3G pluggable device I'm aware of does its own scheduling and just 
emulates/spoofs the ethernet/ppp layer so it's easier to integrate into 
the operating system. I wouldn't be surprised if most phones were done the 
same way, the OS of the system talks to the baseband part, but the 
baseband part does its own queueing.

> So the problem is that we can't always know what amount to shape things
> with.   As I am working with a vendor of CPE and access devices which
> says that they have an SDK, I attempting to put together a project to do
> measurements.  I will control the layer-3 devices at each end of the PPP(oE)
> link...

If you want to be able to do sane scheduling on 3GPP devices then you need 
to interact with the APIs provided to do traffic prioritization the 3GPP 
way. These are called "Traffic Flow Templates", but they basically just 
sorts packets according to criteria into different parallell queues 
(bearers) with different priority in the radio network. So you get a few 
FIFOs instead of just one.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] The bigger picture: whats components are used together to fight bloat

[Michael Richardson]

Thanks for the reply.

>>>>> "Mikael" == Mikael Abrahamsson <swmike@swm.pp.se> writes:
    >> I anticipate similar problems trying to provide VoIP over (initially:
    >> stationary) 3G.  Two providers have promised me that I'll be able to do PPP
    >> directly to the devices, but when they show me a price list, it's clearly
    >> for whole(re)sale.  I think the sales people don't understand that they are
    >> lying, so I have less details on this.

    Mikael> Even if you do ppp to the device, you're still not the bottleneck. Every 3G
    Mikael> pluggable device I'm aware of does its own scheduling and just
    Mikael> emulates/spoofs the ethernet/ppp layer so it's easier to integrate into the
    Mikael> operating system. I wouldn't be surprised if most phones were done the same
    Mikael> way, the OS of the system talks to the baseband part, but the baseband part
    Mikael> does its own queueing.

Most phones talk USB serial to the radio.  Many even use "AT" command
set...  Most "rocket sticks" contain the same radio, but it speaks
USB-ethernet instead of USB-serial, or sometimes it's a completely
proprietary (Windows only) interface.

    >> So the problem is that we can't always know what amount to shape things
    >> with.   As I am working with a vendor of CPE and access devices which
    >> says that they have an SDK, I attempting to put together a project to do
    >> measurements.  I will control the layer-3 devices at each end of the PPP(oE)
    >> link...

    Mikael> If you want to be able to do sane scheduling on 3GPP devices
    Mikael> then you need to 
    Mikael> interact with the APIs provided to do traffic prioritization the 3GPP
    Mikael> way. These are called "Traffic Flow Templates", but they
    Mikael> basically just sorts 
    Mikael> packets according to criteria into different parallell
    Mikael> queues (bearers) with 
    Mikael> different priority in the radio network. So you get a few FIFOs instead of
    Mikael> just one.

yes, I'm aware that there are multiple queues.  I have no idea at this
point if we will get to speak at that layer, I suspect that we will get
access to a single queue.

The 3G situation is a sometime in 3-quarters thing.
The PPPoE situation is next month :-)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	

Re: [Bloat] The bigger picture: whats components are used together to fight bloat

[Mikael Abrahamsson]

On Thu, 16 May 2013, Michael Richardson wrote:

> Most phones talk USB serial to the radio.  Many even use "AT" command 
> set...  Most "rocket sticks" contain the same radio, but it speaks 
> USB-ethernet instead of USB-serial, or sometimes it's a completely 
> proprietary (Windows only) interface.

Yes. But you're still not talking directly to the radio interface, it's 
not a TDM connection. You're sending packet over serial to the baseband 
which then uses its own scheduler to send packets out on the radio.

> yes, I'm aware that there are multiple queues.  I have no idea at this
> point if we will get to speak at that layer, I suspect that we will get
> access to a single queue.

Correct, those 3GPP QoS features are controlled by the network operator, 
not the user. So you're firmly in FIFO-land.

Only way to improve the situation is to start talking to the USB dongle 
vendors and try to get them to implement some kind of knob where one can 
tune the depth of the queue.

Currently in 3G I know at least one vendor who in the downstream direction 
uses a 400 packet deep buffer, regardless of speed of the access or size 
of packets. I could imagine that most USB sticks use a similar approach.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se