[e2e] [aqm] What is a good burst? -- AQM evaluation guidelines

[Detlef Bosau]

Am 16.12.2013 08:34, schrieb Fred Baker (fred):
> On Dec 15, 2013, at 2:57 PM, Bob Briscoe <bob.briscoe at bt.com>
>  wrote:
>
>> Fred,
>>
>> Jonathan Morton, Michael Scharf & I took Naeem's question to mean "What should an AQM assume the size of a good burst is?" whereas I think you and David C-B took the question to mean "What should an end-system take the size of a good burst to be?".
> I can't comment on what he means. I took the question as "what should a system that is in receipt of what it might consider a 'burst', and more especially a 'good burst', to be?"
>
> I don't know that a sending transport (which is to be distinguished from the queueing arrangement in that same system) or a receiving system *has* a definition of a "good" or "bad" burst. The one is sending data, which in the context of y two examples might be a good or bad idea, and the other is receiving it. From the receiver's perspective, the data either arrived or it didn't; if it arrived, there is no real argument for not delivering it to its application...
As I stated ago, the whole AQM discussion of "good" and "bad" queues
emphases, that congestion control is a local thing because congestion is
a local thing.

Some days ago, Dave Reed wrote that congestion control works fine when
the data rates do not vary that much. Dear colleagues,
the data rates of network links being actually in use varies on a range
of 10 orders of magnitude. And this range may become larger.

Some people try to manage this with sophisticated mechanisms on the end
points, some others think the end points should be facilitated by AQM
boxes who do sophisticated dropping.

Dropping a packet is always wrong. Period. It's the networks job to
deliver the packet, not to drop it. So dropping packets as a means of
congestion control does not solve a problem but introduces a second one.
There is not only a problem of network overload but a problem with a
lossy network.

In addition: The congestion collapses in the late 80s were,
synonymously, retransmission collapses. The real problem was not that
packets were dropped. The problem was that the network's capacity was
insufficient to handle the retransmissions. Any packet drop is a
potential retransmission.

Our problem is that we abuse drop as a means of signalling. When an
application/node/whatever offers to much load to the network, we should
have this application/node/whatever offer less node to the network. And
not drop the packets and hope the application will behave accordingly.
It's like bringing up a child. Either you teach your child to make up
his room. Or you will make up your child's room for the rest of your life.

Detlef

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de