Subject: [ledbat] other open issues

From: Padma Bhooma <[email-masked]>
Date: Fri, 11 Jun 2010 11:25:13 -0700

Hi WG,

We have been looking into LEDBAT as an alternate TCP congestion control mechanism for background traffic. A couple of things that are not very clear in the draft draft-ietf-ledbat-congestion are:

1. How will base history expire after some idle time? May there should be a recommendation to throw away the history and re-learn delay on the link.

2. The linear controller that LEDBAT uses suggests that the congestion window should be increased proportional to the change in one-way delay. This is very good for responding quickly to changes in delay. But this can cause the window to increase at a faster rate than TCP would do with its probing mechanism using additive-increase. Although the maximum increase in window is capped to be less than Best-effort TCP, the rate of increase can be more. Does this concern anyone? 

Some of these decisions can be made implementation-specific. I think, it will be good if there is some discussion about it.

Thanks,
Padma

On Jun 8, 2010, at 12:00 PM, [email-masked] wrote:
> 
> Date: Tue, 8 Jun 2010 16:03:37 +0200
> From: "Rolf Winter" <[email-masked]>
> Subject: [ledbat] Open issues, part 1
> To: <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi,
> 
> Here is the first Email in a series of Emails (to keep Email threats separate) which deal with open points in the congestion control draft. I pulled those together from various sources such as meeting minutes. I would like have a documented agreement on them. If there are other open question please speak up.
> 
> 1. Parameters
> There were comments on the parameterization of the congestion control draft. The main concern was that they seem to come out of thin air. To close this issue I'd like to ask the group whether they think the parameters are sensible or not (e.g. 25ms delay target). It would be good to hear from people such as, say, game developers what they have to say about this target. A better description of why these were chosen is surely something that should go into the text.
> 
> Best,
> 
> 	Rolf
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Rolf Winter" <[email-masked]>
Date: Sat, 12 Jun 2010 10:55:12 +0200

Padma,

thanks for the feedback. Regarding point 1. I guess changes in the base delay are expected only when the route changes. As we talk about the last n minutes of measurement, I assume the "old" measurement will just disappear over time even in idle periods(after n minutes). What the draft should describe therefore I think is how periods of idle time are interpreted. So if the last entry in the base history is still removed even in periods where no data is sent or received and idle periods are simply not taken into account when calculating the base delay, we might be fine. But as you said this should be explicitly stated.

Best,

	Rolf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Padma Bhooma
Sent: Freitag, 11. Juni 2010 20:25
To: [email-masked]
Subject: [ledbat] other open issues

Hi WG,

Thanks,
Padma

	
	Hi,

	1. Parameters
	
	Best,
	
	Rolf

---

From: Padma Bhooma <[email-masked]>
Date: Mon, 14 Jun 2010 16:38:49 -0700

Thanks Rolf for the reply. Changes in base delay can happen more frequently in wireless environment. For instance, it can happen when a host moves from 3G to edge. It can also happen if the host moves away from its Wifi access point or if the quality of the channel deteriorates for some reason. I guess, these can also be considered as changes in the route.

Padma

---

From: Padma Bhooma <[email-masked]>
Date: Mon, 14 Jun 2010 16:40:16 -0700

Padma

---

From: Murari Sridharan <[email-masked]>
Date: Tue, 15 Jun 2010 02:21:35 +0000

Yes as those changes happen base delay will have to be re-measured and history purged. Purging the history is necessary as the buffering on these wireless networks is quite different and so samples will be invalid across these changes. I guess along with route flaps we should talk about interface or nexthop changes which are seamless (without breaking connectivity) like on mobile devices. 

Thanks
Murari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Padma Bhooma
Sent: Monday, June 14, 2010 4:39 PM
To: Rolf Winter
Cc: [email-masked]
Subject: Re: [ledbat] other open issues

Padma

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

_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: "Rolf Winter" <[email-masked]>
Date: Tue, 15 Jun 2010 10:31:05 +0200

Padma,

This is a very good point. However, I think we are mixing two issues now. One is that you have periods of idle time, the other one is that routes/access can change over time. Both can happen at the same time but let's first look at them individually. Assuming for now that there is not route change but only idle time, I think the algorithm as described now works OK. We could add some text to make things clearer, but initializing a minute of measurements with 'infinity' might just do the trick. Do you think this is a valid assumption?

The other issue that you bring up is how fast a new base delay can be correctly measured on route/access change. For the following I assume that you will be able to get one packet through that will give you a good estimate for the base delay fairly quickly. The only problem I see then is when the base delay increases. If it decreases, the new lower base delay estimate will result in a correct overall base delay value that you use for congestion control. However if it increases, there are 'old' lower values that you will use until they disappear from the history. If you consider the last 10 minutes, then it might take 9.x Minutes till you have the correct base delay. I agree that it would be nice if we could avoid that. However, while idle time is easy to recognize, a potentially seamless change in access technology is not that easy. If possible, I would like to not mandate the protocol to make use of lower layer triggers but an implementation is free to do so. We could in any case add text to the document.

An earlier Email from Arvid concerned me where he said that it might take 10 minutes till a packet gets through without experiencing queuing delay. This is another issue that has a similar effect and I would like to hear more about the settings when this happens.

Thanks for the valuable feedback Padma.

Best,

	Rolf

-----Original Message-----
From: Murari Sridharan [mailto:[email-masked]] 
Sent: Dienstag, 15. Juni 2010 04:22
To: Padma Bhooma; Rolf Winter
Cc: [email-masked]
Subject: RE: [ledbat] other open issues

Thanks
Murari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Padma Bhooma
Sent: Monday, June 14, 2010 4:39 PM
To: Rolf Winter
Cc: [email-masked]
Subject: Re: [ledbat] other open issues

Padma

---

From: Murari Sridharan <[email-masked]>
Date: Tue, 15 Jun 2010 14:28:47 +0000

Rolf, good points; I think some discussion around this is definitely useful although the exact way in which somebody would discover such a (seamless) change is clearly out-of-scope of our charter. 

Thanks

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Tuesday, June 15, 2010 1:31 AM
To: Murari Sridharan; Padma Bhooma
Cc: [email-masked]
Subject: RE: [ledbat] other open issues

Padma,

Best,

	Rolf

-----Original Message-----
From: Murari Sridharan [mailto:[email-masked]] 
Sent: Dienstag, 15. Juni 2010 04:22
To: Padma Bhooma; Rolf Winter
Cc: [email-masked]
Subject: RE: [ledbat] other open issues

Thanks
Murari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Padma Bhooma
Sent: Monday, June 14, 2010 4:39 PM
To: Rolf Winter
Cc: [email-masked]
Subject: Re: [ledbat] other open issues

Padma

---

From: Padma Bhooma <[email-masked]>
Date: Wed, 16 Jun 2010 09:03:18 -0700

I am not suggesting that LEDBAT should use any hints about link layer changes. I agree that it is out-of-scope for LEDBAT. The only reason given for expiring base delay history was route changes. I was suggesting that base delay can change more frequently in wireless environments.

The way LEDBAT expires the base delay every minute is a good way to adjust to these changes. It is true that the current text says that base delay should be stored for last n minutes. According to the current algorithm, base delay should be updated during packet processing or acknowledgement processing. So if there are no packets during some idle period, base delay can become stale. I am asking if there needs to be some text about expiring base delay during idle period. It looks like there is some agreement on that.

Thanks,
Padma

---

From: Murari Sridharan <[email-masked]>
Date: Wed, 16 Jun 2010 16:07:37 +0000

Yes and additional text to capture this discussion will be added to the document. 

Thanks for reviewing and providing comments.
Murari 

-----Original Message-----
From: Padma Bhooma [mailto:[email-masked]] 
Sent: Wednesday, June 16, 2010 9:03 AM
To: Murari Sridharan
Cc: Rolf Winter; [email-masked]
Subject: Re: [ledbat] other open issues

Thanks,
Padma