Subject: [ledbat] flightSize & cwnd

From: serveh sadeghi <[email-masked]>
Date: Tue, 22 Mar 2011 04:19:45 -0700 (PDT)

Hi guys,
I’m implementing the congestion control mechanism used in µTP (LEDBAT ) and I 
encountered some problems .
Here is what LEDBAT specification says about how to calculate cwnd:
off_target = TARGET - queuing_delay + random_input()
cwnd += GAIN * off_target / cwnd
# flight_size() is the amount of currently not acked data.
max_allowed_cwnd = ALLOWED_INCREASE + TETHER*flight_size()
cwnd = min(cwnd, max_allowed_cwnd)
And here is the values spec suggests for the parameters:
TARGET = 100;
GAIN = 1.0;
ALLOWED_INCREASE = 1.0;
TETHER = 1.5;
Considering these , if flight_size becomes 0 at some point, max_allowed_cwnd 
becomes 1.0, so whatever calculatedcwnd is, finalcwnd would be 1.0(The minimum 
amount of cwnd while a TCP flow exists!). Even worse , ifcwnd becomes 1.0, it 
remains 1.0 forever. Becausecwnd = 1.0 means just send 1 packet. So on receiving 
ack, flight_size would be 0 and againmax_allowed_cwnd would be 1.0 ! 

could you please guide me where I'm making mistake .

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 22 Mar 2011 12:31:27 +0100

Hi Serveh,

you are right, but we changed a couple of things in the just newly updated 
version of the draft (draft-ietf-ledbat-congestion-04). Please have a look at 
this version; there shouldn't any problem anymore.

Mirja

--
---------------------
Here the code from the current draft:

   on acknowledgement:
       # flightsize is the amount of data oustanding before this ack
       #    was received and is updated later by update_flightsize();
       # bytes_newly_acked is the number of bytes that this ack
       #    newly acknowledges, and it MAY be set to MSS; and
       # cwnd is in bytes.

       delay = acknowledgement.delay
       update_base_delay(delay)
       update_current_delay(delay)
       queuing_delay = MIN(current_delays) - MIN(base_delays)
       off_target = (TARGET - queuing_delay) / TARGET
       cwnd += GAIN * off_target * bytes_newly_acked / cwnd
       max_allowed_cwnd = flightsize + ALLOWED_INCREASE * MSS
       cwnd = min(cwnd, max_allowed_cwnd)
       cwnd = max(cwnd, MIN_CWND * MSS)
       update_flightsize()  #subtracts bytes_newly_acked from flightsize

On Tuesday 22 March 2011 12:19:45 serveh sadeghi wrote:
> Hi guys,
> I’m implementing the congestion control mechanism used in µTP (LEDBAT ) and
> I encountered some problems .
> Considering these , if flight_size becomes 0 at some point,
> max_allowed_cwnd becomes 1.0, so whatever calculatedcwnd is, finalcwnd
> would be 1.0(The minimum amount of cwnd while a TCP flow exists!). Even
> worse , ifcwnd becomes 1.0, it remains 1.0 forever. Becausecwnd = 1.0 means
> just send 1 packet. So on receiving ack, flight_size would be 0 and
> againmax_allowed_cwnd would be 1.0 !
>
>

---

From: Rolf Winter <[email-masked]>
Date: Tue, 22 Mar 2011 11:32:08 +0000

Hi,

the old congestion control formula had a bug. Could you re-evaluate with the newest version found at 

http://tools.ietf.org/html/draft-ietf-ledbat-congestion-04.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of serveh sadeghi
> Sent: Dienstag, 22. März 2011 12:20
> To: [email-masked]
> Subject: [ledbat] flightSize & cwnd
> 
> Hi guys,
> 
> I’m implementing the congestion control mechanism used in µTP (LEDBAT )
> and I encountered some problems .
> 
> max_allowed_cwnd becomes 1.0, so whatever calculated cwnd is, final
> cwnd would be 1.0(The minimum amount of cwnd while a TCP flow exists!).
> Even worse , if cwnd becomes 1.0, it remains 1.0 forever. Because cwnd
> = 1.0 means just send 1 packet. So on receiving ack, flight_size would
> be 0 and again max_allowed_cwnd would be 1.0 !
> 
> 
> 
>

---

From: serveh sadeghi <[email-masked]>
Date: Mon, 28 Mar 2011 01:50:48 -0700 (PDT)

Hi guys,
If you start with init_cwnd=2 packets and your mss is 1500 ,initial cwnd is 3000 
bytes. on  receiving  the ack for both sent packets,  having queuing_delay 0, 
off_target would be 1.0.
off_target = (TARGET - queuing_delay) / TARGET
cwnd += GAIN * off_target * bytes_newly_acked / cwnd
 
and new cwnd would be 3000 + 1.0 * 1.0 * 3000 / 3000 = 3001
So if you just send 2 packets and receive both, and there is no congestion at 
all(queuing_delay = 0), you expect that new cwnd would increase very much, not 
only one byte. I run this in a long time and the chart produced for cwnd size is 
not increasing that much.The chart is not what I expected.

________________________________
From: Rolf Winter <[email-masked]>
To: serveh sadeghi <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tue, March 22, 2011 12:32:08 PM
Subject: RE: [ledbat] flightSize & cwnd

Hi,

the old congestion control formula had a bug. Could you re-evaluate with the 
newest version found at 

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 
6BL | Registered in England 2832014

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 28 Mar 2011 11:05:25 +0200

Hi Serveh,

sorry, we've been missing an *MSS here:

cwnd += GAIN * off_target * bytes_newly_acked / cwnd * MSS

That's because we've just changed from a cwnd in packets to a cwnd in bytes...

Thanks for the pointer!!
Mirja

On Monday 28 March 2011 10:50:48 serveh sadeghi wrote:
> Hi guys,
> If you start with init_cwnd=2 packets and your mss is 1500 ,initial cwnd is
> 3000 bytes. on  receiving  the ack for both sent packets,  having
> queuing_delay 0, off_target would be 1.0.
> So if you just send 2 packets and receive both, and there is no congestion
> at all(queuing_delay = 0), you expect that new cwnd would increase very
> much, not only one byte. I run this in a long time and the chart produced
> for cwnd size is not increasing that much.The chart is not what I expected.
>
>
>
> To: serveh sadeghi <[email-masked]>; "[email-masked]"
> <[email-masked]> Sent: Tue, March 22, 2011 12:32:08 PM

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: serveh sadeghi <[email-masked]>
Date: Mon, 28 Mar 2011 05:23:10 -0700 (PDT)

Are you sure? because I already put cwnd as number of bytes (3000 means 2 * mss)

________________________________
From: Mirja Kuehlewind <[email-masked]>
To: [email-masked]; Janardhan Iyengar <[email-masked]>
Cc: serveh sadeghi <[email-masked]>
Sent: Mon, March 28, 2011 11:05:25 AM
Subject: Re: [ledbat] flightSize & cwnd

Hi Serveh,

Thanks for the pointer!!
Mirja

tel: +49(0)711/685-67973

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 28 Mar 2011 14:28:44 +0200

yes, I'm sure, because you add this value again to the cwnd which is in 
bytes...

in_bytes += no_unit * no_unit * in_bytes / in_bytes * in_bytes = in_bytes

Mirja

On Monday 28 March 2011 14:23:10 serveh sadeghi wrote:
> > If you start with init_cwnd=2 packets and your mss is 1500 ,initial cwnd
> > is 3000 bytes. on  receiving  the ack for both sent packets,  having
> > So if you just send 2 packets and receive both, and there is no
> > congestion at all(queuing_delay = 0), you expect that new cwnd would
> > increase very much, not only one byte. I run this in a  long time and the
> > chart produced for cwnd size is not increasing that much.The chart is not
> > what I expected.
> >
> >
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL | Registered in England 2832014
> >
> > > I’m implementing the congestion  control mechanism used in µTP (LEDBAT
> > > ) and I encountered some problems .
> > >

tel: +49(0)711/685-67973