Re: Why do we need congestion control?

Detlef Bosau <[email protected]>
Newsgroups gmane.network.end2end
Message-ID <[email protected]>
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
[email protected]                     http://www.detlef-bosau.de
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.