Subject: [ledbat] Seperating spec from implementation guidelines

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 23 Mar 2010 17:54:37 +0100

Hi,

I think I could not make my point clear in the wg meeting yesterday. So I try 
to phase my proposal again.
I suggest to make two documents out of the ledbat spec:

- one that really just describes the algorithm without making any assumption 
about the underlaying network (e.g. if acks could get lost) or the transport 
protocol (which is out of scope of the doc already) or any actual value for 
certain parameters (as these also might depend on an assumption about a 
specific scenario). If there is a logical reason for a upper or lower bound 
of a parameter (which maybe even calculable somehow), that should be in the 
document. But it needs to be explained.

- the other document will than have implementation recommendations/guidelines. 
That could be the place to put the pseudocode. But more important 
recommendations for all the parameters should be addressed here plus a 
description of the scenario (or various scenarios) those values have been 
approved in. 

I'm not sure if that is the proper way to handle it but it could help to set 
up a spec a soon as possible and than leave more space for the further 
evaluations.

Mirja

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 23 Mar 2010 18:42:03 -0700

The pseudocode is the meat of the spec. The rest of the document  
explains why it is the way it is. If it is removed, it'd need to be  
replaced with much more verbose text describing the same algorithmic  
behavior in prose. It seems that pseudocode is not a bad way to  
describe an algorithm because it is concise and unambiguous.

Are there any other parts of the spec you like to move out?

Stanislav Shalunov

On Mar 23, 2010, at 9:54 AM, Mirja Kühlewind <[email-masked] 
e> wrote:

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 24 Mar 2010 17:33:48 +0100

I'm not saying to remove anything. I not even saying that there is anything 
wrong about the way it is now. I'm just suggesting another way of documenting 
it. Don't know if this might be the better way...

The only thing I'm concerned about are those parameter values in the spec, 
which are there without any explanation where there are coming from. I would 
like to see some evaluation results and maybe even more important I would 
like to know in which scenarios you actually evaluated the algorithm. 
But to get the spec finished as soon as possible, maybe move this part to a 
different doc...?

If one of your goals is to write a short and handy spec which makes it easy to 
implement the algorithm, it might just be more appropriate to have a separate 
doc. In such a doc, which gives implementation guidelines, the pseudocode 
would be probably really helpful.

The pseudocode is a good way to describe the algorithm but anyway I would like 
to have some more text there as well. If you don't get all of the pseudocode 
at the first look I guess some text is really helpful. If you get everything 
from the pseudocode just don't read the text.
Moreover, I was wondering if the pseudocode is maybe implying some 
implementation assumptions - like e.g. define a certain order to do things - 
I don't know; you have to tell...

Another point is I think it would be helpful to have an implementation 
guideline doc to describe scenarios in which LEDBAT should be use. I guess 
your motivation to use LEDBAT with Bittorrent is right now that the 
bottleneck link is in the access network and so Bittorrent traffic might 
block other transmission of the same user.
There might be different scenarios e.g. within a private network where you 
just have a different use case and therefore different parameter value should 
be selected.
The parameter values might also depend on the application you use LEDBAT with.  
E.g. I was thinking about having also something like a lower bound of the 
congestion windows which could be helpful for video streaming application 
(which do some buffering). Just a thought...

Mirja

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

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