Subject: [ledbat] Reaction to packet drops

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 21 Mar 2011 14:22:07 +0100

Hi

I have a question on the latest version of 
http://tools.ietf.org/wg/ledbat/draft-ietf-ledbat-congestion/
If I get things right LEDBAT should react to packet drops in the same was as TCP Reno. 

For some reason I get the feeling that it is more reasonable to react more than TCP reno even to packet drops and that this can also be controlled by the GAIN parameter. The reason I can bring up is that in the strive to reduce buffer bloat it is more likely that packet dops are used to signal congestion which means that the delay increase may be very small. 
So if the GAIN parameter is also included in the cwnd calculation when packet drops occur then the delay and packet drop sensing algos would complement one another.
I guess this has probably been discussed earlier ?

/Ingemar
=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Researcher

Ericsson AB
Wireless Area Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com
Visit http://labs.ericsson.com !
=================================

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 21 Mar 2011 16:11:17 +0100

Hi Ingemar,

if LEDBAT works correctly, it will not see any packet losses at all. LEDBAT is 
already decreasing the CWND if the current queuing delay is larger than 
TARGET. This is usually the case when a competing flow is increasing the 
rate. Standard TCP increases until the queue is filled up. By that time 
LEDBAT should already have decreased its own rate to MIN_CWND (=2). If the 
competing flow(s) is/are increasing more aggressive LEDBAT will back off 
quicker as the delay-based back off already depends on off_target. 

If LEDBAT see losses because of the very aggressive increase of a completing 
flow in Slow-Start, the halving of the cwnd will help to speed-up the 
decrease process but LEDBAT is anyway decreasing further as soon as the 
completing TCP fills the queue again in Congestion Avoidance.

Halving on loss is  basically only a fall-back for the error case. If the 
total possible queuing delay (because of really, really small buffers) is 
smaller than TARGET, LEDBAT will not work. This is an error case and LEDBAT 
will behave like standard TCP. Not sure if we want to decrease more than 
standard TCP in this case. To change the loss-based decrease will probably 
also provide a possibility to have a less-than-best-effort traffic but this 
is a completely different algorithm from my point of view.

Actually, we still have to discuss the delay-based decrease more detailed in 
the draft, as we have to make sure to decrease quicker than an completing 
standard TCP would increase... 

Anyway, how would you actually include GAIN (or do you mean off_target) into 
the decrease on loss behavior?

Mirja

On Monday 21 March 2011 14:22:07 Ingemar Johansson S wrote:
> For some reason I get the feeling that it is more reasonable to react more
> than TCP reno even to packet drops and that this can also be controlled by
> the GAIN parameter. The reason I can bring up is that in the strive to
> reduce buffer bloat it is more likely that packet dops are used to signal
> congestion which means that the delay increase may be very small. So if the
> GAIN parameter is also included in the cwnd calculation when packet drops
> occur then the delay and packet drop sensing algos would complement one
> another. I guess this has probably been discussed earlier ?
>
> /Ingemar
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

-- 
-------------------------------------------------------------------
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: Nicholas Weaver <[email-masked]>
Date: Mon, 21 Mar 2011 08:38:32 -0700

> is a completely different algorithm from my point of view.

I'd vote no or yes depending on a mode selector:

mode 1 is "No bufferbloat": you want the transfer to go through but not cause problems with all the overbuffered equipment out there.  In that case, if your buffer is less than TARGET, you aren't in a problematic buffering situation and you should behave like ordinary TCP.  

This would, eg, be very good for Flash to adopt for streaming video.

Mode 2 is "True scavenger service": You want to yield to normal TCP in all cases, not just when there are buffer problems in the network.  In that case, drops should cause LEDBAT to back off further than normal TCP would in the same conditions.

---

From: michawe <[email-masked]>
Date: Mon, 21 Mar 2011 16:43:30 +0100

+1

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Mar 2011 08:46:11 -0700

Hi, all,

On 3/21/2011 6:22 AM, Ingemar Johansson S wrote:
> For some reason I get the feeling that it is more reasonable to
> react  more than TCP reno even to packet drops and that this can also be
> controlled by the GAIN parameter. The reason I can bring up is that in
> the strive to reduce buffer bloat it is more likely that packet dops are
> used to signal congestion which means that the delay increase may be
> very small.

Buffer bloat shouldn't drive this discussion. You're talking about 
reacting to drops; buffer bloat can still occur with zero drops.

AFAICT, BB is an artifact of poor buffering and queue management 
implementation and configuration. We should not strive to tune TCP to 
correct for flaws in, e.g., Linux.

Joe

---

From: Rolf Winter <[email-masked]>
Date: Mon, 21 Mar 2011 15:55:04 +0000

Speaking as non-chair,

> is a completely different algorithm from my point of view.

I think it is wrong to assume this is in fact an error case. The observation we have made with a range of DSL home gateways is that buffers indeed become smaller over time (we observed 256 packets worth of buffer in old ones to around 32 nowadays). Of course there are other delay contributors, but home gateways initially triggered the development of LEDBAT. Paired with an increase in access speed queuing delay will reduce over time and 100 ms will be too much. That is why we now allow a smaller target in the new spec. The hope therefore will be that LEDBAT will over time lower its de facto target. But given that this situation of running into loss will likely happen in the future, we need to find an adequate answer. I believe the current answer is fine - behave like TCP. In case you have this situation persistently, i.e. small buffers, you can lower your target. That's even better than a binary on/off switch. 

Best,

Rolf

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 22 Mar 2011 08:36:42 +0100

Mirja, Rolf, all

One of the reasons I see to introduce a more agressive backoff in the presence of packet loss is that I have problems to determine a good TARGET value for wireless access. It all depends on the type of radio access (HSDPA, EUL, LTE..) and also on the type of scheduling algorithm one use. As the user can be mobile he may as well do handover between access types and this complicates things even more.

I see a particulal issue if the threshold of an AQM algorithm along the transmission path is tuned such that the packets are dropped when the delay is below TARGET. This will as I understand things cause LEDBAT and TCP to backoff in the same way. I would say that the statement in the draft "LEDBAT does not induce losses and so a LEDBAT sender is not expected to normally rely on losses to determine the sending rate." is not true in this case.

It would make more sense to me if LEDBAT backs off more than TCP in the presence of packet losses.

One way to implement this is to modify section 3.4.2 slighly and include GAIN in the "on data loss:" code
       # atmost once per RTT
       cwnd = GAIN*cwnd/2
       cwnd = max(cwnd, MIN_CWND * MSS)

I am not sure if that creates a too strong backoff behavior if GAIN is very low so perhaps something like
       # atmost once per RTT
       cwnd = max(GAIN,MIN_GAIN)*cwnd/2
       cwnd = max(cwnd, MIN_CWND * MSS)

Where MIN_GAIN can be set to for instance 0.25

There is also a political angle to all this. File sharing is often looked at with not too kind eyes from certain players. It is sometimes voiced that the whole thing should be blocked as it kills the performance for all users (you all know the story that goes like "10% of the users consume 90% of the bandwidth"). If one can say that LEDBAT is indeed more than TCP friendly in all possible cases, then the above concerns wont hold (at least not for the technically oriented person :-). The delay based part of LEDBAT fulfills this requirement but I believe that the loss based (or ECN based for that matter) needs to be modified.

Regards
Ingemar

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: den 21 mars 2011 16:55
To: Mirja Kuehlewind; [email-masked]
Cc: Ingemar Johansson S
Subject: RE: [ledbat] Reaction to packet drops

Speaking as non-chair,

> Halving on loss is  basically only a fall-back for the error case. If 
> the total possible queuing delay (because of really, really small 
> buffers) is smaller than TARGET, LEDBAT will not work. This is an 
> error case and LEDBAT will behave like standard TCP. Not sure if we 
> want to decrease more than standard TCP in this case. To change the 
> loss-based decrease will probably also provide a possibility to have a 
> less-than-best-effort traffic but this is a completely different 
> algorithm from my point of view.
> 

Best,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Tue, 22 Mar 2011 07:59:28 +0000

Hi Ingemar,

(as individual) 

there are at least two more things to consider. For one the design goals of which two are:

4. utilize end-to-end available bandwidth, and
5. operate well in networks with FIFO queues and tail-drop queue management

Actually, an earlier version of the document had this as well:

where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ)...

Now the second thing to consider is that even if LEDBAT backs off in the same way as TCP does in case of loss, it will ramp up more slowly (max as TCP when in congestion avoidance which is when there is no competing traffic which is not what we are talking about in this case).

Best,

Rolf

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

> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: Dienstag, 22. März 2011 08:37
> To: Rolf Winter; Mirja Kuehlewind; [email-masked]
> Cc: Nicholas Weaver; michawe; Ingemar Johansson S
> One of the reasons I see to introduce a more agressive backoff in the
> presence of packet loss is that I have problems to determine a good
> TARGET value for wireless access. It all depends on the type of radio
> access (HSDPA, EUL, LTE..) and also on the type of scheduling algorithm
> one use. As the user can be mobile he may as well do handover between
> access types and this complicates things even more.
> 
> I see a particulal issue if the threshold of an AQM algorithm along the
> transmission path is tuned such that the packets are dropped when the
> delay is below TARGET. This will as I understand things cause LEDBAT
> and TCP to backoff in the same way. I would say that the statement in
> the draft "LEDBAT does not induce losses and so a LEDBAT sender is not
> expected to normally rely on losses to determine the sending rate." is
> not true in this case.
> 
> 
> There is also a political angle to all this. File sharing is often
> looked at with not too kind eyes from certain players. It is sometimes
> voiced that the whole thing should be blocked as it kills the
> performance for all users (you all know the story that goes like "10%
> of the users consume 90% of the bandwidth"). If one can say that LEDBAT
> is indeed more than TCP friendly in all possible cases, then the above
> concerns wont hold (at least not for the technically oriented person :-
> ). The delay based part of LEDBAT fulfills this requirement but I
> believe that the loss based (or ECN based for that matter) needs to be
> modified.
> 
> Regards
> Ingemar
> 
> 
> I think it is wrong to assume this is in fact an error case. The
> observation we have made with a range of DSL home gateways is that
> buffers indeed become smaller over time (we observed 256 packets worth
> of buffer in old ones to around 32 nowadays). Of course there are other
> delay contributors, but home gateways initially triggered the
> development of LEDBAT. Paired with an increase in access speed queuing
> delay will reduce over time and 100 ms will be too much. That is why we
> now allow a smaller target in the new spec. The hope therefore will be
> that LEDBAT will over time lower its de facto target. But given that
> this situation of running into loss will likely happen in the future,
> we need to find an adequate answer. I believe the current answer is
> fine - behave like TCP. In case you have this situation persistently,
> i.e. small buffers, you can lower your target. That's even better than
> a binary on/off switch.
> 
> Best,
> 
> Rolf

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 22 Mar 2011 11:14:24 +0100

Hmm. Good point, the slower ramp up will definitely make LEDBAT more than TCP friendly if GAIN < 1.0. This means that there should be no concern.

Thanks 

/Ingemar

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: den 22 mars 2011 08:59
To: Ingemar Johansson S; Mirja Kuehlewind; [email-masked]
Cc: Nicholas Weaver; michawe
Subject: RE: [ledbat] Reaction to packet drops

Hi Ingemar,

(as individual) 

4. utilize end-to-end available bandwidth, and 5. operate well in networks with FIFO queues and tail-drop queue management

Best,

Rolf

> access (HSDPA, EUL, LTE..) and also on the type of scheduling 
> algorithm one use. As the user can be mobile he may as well do 
> handover between access types and this complicates things even more.
> 
> I see a particulal issue if the threshold of an AQM algorithm along 
> the transmission path is tuned such that the packets are dropped when 
> the delay is below TARGET. This will as I understand things cause 
> LEDBAT and TCP to backoff in the same way. I would say that the 
> statement in the draft "LEDBAT does not induce losses and so a LEDBAT 
> sender is not expected to normally rely on losses to determine the 
> sending rate." is not true in this case.
> 
> 
> of the users consume 90% of the bandwidth"). If one can say that 
> LEDBAT is indeed more than TCP friendly in all possible cases, then 
> the above concerns wont hold (at least not for the technically 
> oriented person :- ). The delay based part of LEDBAT fulfills this 
> requirement but I believe that the loss based (or ECN based for that 
> matter) needs to be modified.
> 
> Regards
> Ingemar
> 
> 
> > Halving on loss is  basically only a fall-back for the error case. 
> > If the total possible queuing delay (because of really, really small
> of buffer in old ones to around 32 nowadays). Of course there are 
> other delay contributors, but home gateways initially triggered the 
> delay will reduce over time and 100 ms will be too much. That is why 
> we now allow a smaller target in the new spec. The hope therefore will 
> be that LEDBAT will over time lower its de facto target. But given 
> that this situation of running into loss will likely happen in the 
> future, we need to find an adequate answer. I believe the current 
> answer is fine - behave like TCP. In case you have this situation 
> persistently, i.e. small buffers, you can lower your target. That's 
> even better than a binary on/off switch.
> 
> Best,
> 
> Rolf