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

[Michael Richardson <mcr@sandelman.ca>]

>>>>> "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    [