Re: [ledbat] open issues, ACK rate

As I'm going over the open issues last time before submitting the draft, I
wanted to note that if you don't get any ACKs, you'll timeout and conclude
losses are occurring, thus quickly and radically reducing the window by a
factor of two per RTT.

This is one of the stated reasons for multiplicative decrease:

"Further, *to deal with severe congestion when most packets are lost* and to
provide a safety net against incorrect queuing delay estimates, we'll halve
the window when a loss event is detected." (emphasis added)

On Thu, Jul 8, 2010 at 9:02 AM, Mirja Kuehlewind <
mirja.kuehlewind@ikr.uni-stuttgart.de> wrote:

> Hi,
>
> > 4. ACK rate
> > In the framing and wire format section, Stas promised to add a statement
> > that LEDBAT needs to send (and receive) ACKs frequently in order to work
> > properly. This is an open issue that needs to be solved. As this has not
> > happened yet, text to include from the WG is more than welcome. Details
> on
> > what frequently should mean in practice is open for discussion.
> Actually section 5 says
>
> "Consider a protocol that uses packets of equal size and acknowledges each
> of
> them separately."
>
> Okay, it does say anything about loss of acks. Maybe there should something
> in
> the algorithm that says: if I don't see acks for 'some' time I will reduce
> my
> cwnd...? Does anyone did some experiments with lost acks?
>
> One more point for the pseudo code: the part of halving the congestion
> window
> in case of (data packet) loss is missing here.
>
> Mirja
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
>

-- 
Stanislav Shalunov
BitTorrent Inc
shalunov@bittorrent.com

personal: http://shlang.com