Re: [httpstreaming] [conex] [dispatch] Q-HTTP

[Roland Bless <[e-mail]>]

Hi David,

On 09.11.2010 11:31, David Singer wrote:

> It is that there are two ways to solve a real-time bandwidth need.
> One is to reserve bandwidth, manage QoS and so on;  one gets
> protocols and systems like diffserv, ATM, and so on.  The other is
> simply to have 'too much' of the resource.  Though it feels wrong,

QoS mechanisms are usually only necessary if you've got some kind of
resource shortage. They try to manage the resource scarcity in some
way then. So having "too much of a resource" seems to imply that we
actually don't need any QoS support.

The basic problem is that even if you over-provision you'll depend
on the traffic distribution (i.e. the traffic matrix). For instance,
if you've got 10x100Mbit/s links aggregated to a 1 Gbit/s "upstream"
link, you usually have no problem of transmitting traffic towards the
larger link. In the other direction though, it depends heavily on the
incoming
traffic distribution. So if the 1 Gbit/s link transmits 200 Mbit/s
towards a single 100Mbit/s link over a longer period, you'll get dropped
packets. Denial-of-Service attacks can achieve this effect
intentionally. It's no problem using my PC and trying to flood several
DSL subscriber lines, or using 10 PCs at our campus site and trying to
flood some link with the aggregated bandwidth of ~ 10 Gbit/s. Your
real-time traffic will definitely suffer then...

I fear that the bandwidth demand will increase a lot due to HD streaming
etc. and that we need some kind of active QoS management at the edge
or access networks at least.

> the latter often ends up being the cheaper and easier solution.  So,

Yes, but not a really reliable solution and it works only as long as
the fair/whatever resource share is enough to provide the minimum
acceptable quality.

> The same is true for multimedia delivery;  the complexity of RTP +
> TCP friendliness + QoS management is not worth it compared to having
> adaptable end-systems and overall more bandwidth than needed.

I agree that having adaptable applications is a good idea anyway
and that QoS management adds a lot of complexity (and also complexity
at SLA level).

> (I worked on real-time scheduling systems as well, and the same
> applies;  it's cheaper to have a processor which is much faster than
> needed, with a normal scheduler, than to have a just-enough processor
> with a real-time scheduler).

> I know, it 'feels' wrong.

I think it's fine as long as everything behaves somehow friendly,
i.e., in the absence of DoS flooding attacks...

Regards,
 Roland