[e2e] Why do we need congestion control?

[Detlef Bosau]

O.k., I just asked fro additional space for my mailbox because of the 
expected responses.

Isn't AQM nothing else than some kind of "sophistically discard" packets?

Any discarded packet is a potential retransmission.

So, don't we run into the risk of suffering from a retransmission collapse?

The more I think about it, the more I think that all this AQM stuff does 
not really /solve /a problem but /causes/ a problem.

In some private message, the sender remarked: "A congestion control 
scheme that causes congestion - funny."

Wouldn't it be the better alternative to avoid congestion than to fix it?

Detlef

Am 17.03.2013 04:25, schrieb Daniel Havey:
> Hi Fred,
>
>   
>> We now have at least two AQM algorithms on the table that
>> auto-tune.
>>
>> As such, while the general statement of 2309 is a good one -
>> that we need to implement AQM procedures - the specific one
>> it recommends turned out to not be operationally useful.
>>
>> As to the specific statement that Lloyd seeks, and notes
>> that the TCP community argues for one specific answer, I'll
>> note that operationally-deployed TCP has more than one
>> answer.
> Well, perhaps all of the TCP community does not argue for one specific answer.
>
> Let's think about Joe's thesis.
>
> They are complementary:
>
>      FEC (including erasure codes) always completes in finite time,
>      but has a nonzero probability it will fail (i.e., that the
>      data won't get through at all)
>
>      ARQ always gets data through with 100% probability when
>      it completes, but has a nonzero chance of taking an
>      arbitrary long time to do so
>
> This tells us that if we have horrible RTT then TCP retransmission will be a drag.  However, if we have a nice RTT then TCP retransmission is what we want.
>
> One solution does not fit all.
>
> ...Daniel
>
>> There is Microsoft's Congestion Control algorithm,
>> NewReno in FreeBSD, and CUBIC in Linux. There are other
>> algorithms such as CAIA CDG that also fill the bottleneck in
>> a path but manage to do so without challenging the cliff,
>> which at least in my opinion is a superior model.
>>
>> Similarly, it is difficult to argue that everyone has to
>> implement the same AQM algorithm. What is reasonable without
>> doubt is that whatever algorithm is implemented, the
>> requirement is that it manage queue depths to a
>> statistically shallow queue.
>>
>


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130317/a7ae2301/attachment-0001.html