Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
From: [email-masked] (Mirja Kuehlewind)
Date: Sat Jun 18 09:27:25 2011

Hi Lisong,

> A scientific paper is meant for a researcher, but an RFC is for a
> programmer who wants to implement the protocol. This is why I want to
> specify the data type of acknowledgement.delay (possible others too).
Other than many RFCs this document is NOT specifying a protocol. It 'only' 
documents the algorithm. There is anyway some work for the implementor  to 
transfer the algorithm based on the used framing protocol and programming 
language. E.g. if you want to implement LEDBAT on a small low-energy device 
with limited memory and you only have unsigned short, you have to scope with 
it...
And even protocol specifications, which are even more implementor guides, try 
to specify a protocol deliberately without any implementation specify 
assumptions such that a protocol can be implemented in many different 
devices.
We are actually still thinking about a document to define LEDBAT for TCP 
(which would be more like a implementation guide then).

>
> OK, here is an example to illustrate the problem of unsigned variables.
>
> assume all variables are unsigned short.
>
> at some time (low queueing delay):
>    local_timestamp = 3, and remote_timestamp = 5
>    then acknowledgement.delay = 65534
>    then base_delay = 65534
>
> at some time later (high queueing delay):
>    local_timestamp = 7, and remote_timestamp = 6
>    then acknowledgement.delay = 1
>    then base_delay = 1
>    then queueing_delay = 0
In this example there is a very strong clock skew. You would need some clock 
correction, otherwise the result are incorrect anyway.

Mirja

>
> Thanks
> Lisong
>
> On 6/17/2011 2:33 AM, Mirja Kuehlewind wrote:
> > Hi Lisong,
> >
> > you are right, if it is an unsigned this might cause errors but its
> > actually not a problem. If local_timestamp-remote_timestamp is negative
> > but acknowledgement.delay is signed you will get a wrong result (but this
> > doesn't matter as this delay does not show a real delay value anyway) but
> > you will get a result because there simply will be an overflow.
> > If you now calculate queuing_delay = current_delay - base_delay. Also
> > this error will cancel out and you get an valid result.
> >
> > Anyway, its in the responsibility of the implementor to get the type and
> > range right; its not part of the algorithm itself, from my point of view.
> > Do you have a different opinion here?
> >
> > Mirja
> >
> > On Thursday 16 June 2011 18:36:24 Lisong Xu wrote:
> >> Mirja,
> >>
> >> Thanks for your reply. I have only one question now.
> >>
> >> "it doesn't matter if the delay is positive or negative because its
> >> canceled out in the calculation of the queuing delay and even an
> >> overflow would work here."
> >>
> >> You are right that it does not matter whether acknowledgement.delay is
> >> positive or negative. But variable acknowledgement.delay MUST be a
> >> signed int. If it is implemented as an unsigned int, then sometimes
> >> there will be a problem.
> >>
> >> Thanks
> >> Lisong
> >>
> >> On 6/15/2011 6:07 AM, Mirja K?hlewind wrote:
> >>> Hi Lisong
> >>>
> >>> thank you very much for your review! Please see comments inline.
> >>>
> >>> Mirja
> >>>
> >>> On Sunday 12 June 2011 08:53:10 Lisong Xu wrote:
> >>>> Hi Michael,
> >>>>
> >>>> Below are my comments after reading the draft.
> >>>> Thanks
> >>>> Lisong
> >>>>
> >>>>
> >>>> **** Section 3.1 ****
> >>>> First sentence: "a loss occurs [RFC5681], which, in the absence of any
> >>>> Active Queue Management (AQM) in the network, occurs only when the
> >>>> queue at the bottleneck link on the end-to-end path overflows "
> >>>>
> >>>> Since a loss may occur due to link errors, such as fiber errors and
> >>>> wireless errors, we may change the first sentence to
> >>>> "... (AQM) and link errors in the network,...."
> >>>
> >>> Done.
> >>>
> >>>> **** Section 3.3 ****
> >>>> The data type of each variable is not specified. Since some variables
> >>>> must be signed variables, it is important to specify the type of each
> >>>> variable in order to correctly implement the algorithm.
> >>>>
> >>>> For example, tcp_time_stamp is an unsigned int, so local_timestamp and
> >>>> remote_timestamp are also unsigned int.  But variable
> >>>> acknowledgement.delay should be a signed int, since
> >>>> local_timestamp-remote_timestamp may be negative.
> >>>
> >>> I don't want to specify any data type here because that's only pseudo
> >>> code of the algorithm and the range and resolution of a variable are
> >>> implementation specific and might depend on the framing protocol used
> >>> and of course as well on the programming language.
> >>>
> >>> Your example is a quite special case as one would assume that delay is
> >>> always positive but you might get negative values because of the clock
> >>> offset. Issues like clock offset and skew, which can come up in a real
> >>> system, are not regarded as part of the algorithm. Anyway there is some
> >>> discussion in the appendix. Moreover, in fact in this special example
> >>> it doesn't matter if the delay is positive or negative because its
> >>> canceled out in the calculation of the queuing delay and even an
> >>> overflow would work here.
> >>>
> >>> The only case where it is important that a value can/must get negative
> >>> is the off_target and this is mentioned explicit in 3.4.1.
> >>>
> >>>> **** Section 3.4.2 ****
> >>>> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for
> >>>> the last BASE_HISTORY minutes, and one for the running current
> >>>> minute."
> >>>>
> >>>> But the update_current_delay(delay) code maintains only BASE_HISTORY
> >>>> minima. So the above sentence should be changed to
> >>>> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for the
> >>>> last BASE_HISTORY-1 minutes, and one for the running current minute."
> >>>
> >>> Thanks. You are right! Done.
> >>>
> >>>> **** Section 3.5 ****
> >>>> "we recommend that the sender SHOULD use at least 4 samples in each
> >>>> RTT. Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that
> >>>> no samples in list are older than an RTT in the
> >>>> past."
> >>>>
> >>>> But what if cwnd is less than 4? In this case, there are less than 4
> >>>> samples in each RTT.
> >>>
> >>> That's why there is a SHOULD and not a MUST. If you have less samples,
> >>> you can, of course, only use whatever you get. But the results might be
> >>> very noisy and if you permanently have less then 4 samples, LEDBAT
> >>> might not work correctly (because of noise in real systems).
> >>>
> >>> Should we make this more explicit?
> >>>
> >>>> **** General *****
> >>>>
> >>>> It is not clear what the relation between cwnd and flightsize is. Is
> >>>> flightsize always the same as cwnd, or could be less than cwnd? When
> >>>> is flightsize less than cwnd?
> >>>
> >>> flightsize can be less if your transfer is application-limited (and
> >>> ALLOWED_INCREASE is large enough). Thus you don't have enough data to
> >>> fill the cwnd.
> >>>
> >>> In the code you find
> >>> " on acknowledgment:
> >>>       # flightsize is the amount of data outstanding 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."
> >>>
> >>> I've added the following to 'on initialization:' (eventhough you find
> >>> the same explanation in 3.2.)
> >>> "   # cwnd is the amount of data that is allowed to send in one RTT and
> >>>       # is defined in bytes."
> >>>
> >>> Does this help?
> >>>
> >>>> On 6/5/2011 12:38 AM, Michael Welzl wrote:
> >>>>> Hi,
> >>>>>
> >>>>> We're urgently looking for a volunteer to review
> >>>>> draft-ietf-ledbat-congestion-06:
> >>>>> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
> >>>>> which is currently in Last Call, ending in less than two weeks (15
> >>>>> June).
> >>>>>
> >>>>> If anyone here is willing to do a review, please drop Murari and me a
> >>>>> note ASAP!
> >>>>>
> >>>>> Thanks,
> >>>>> Michael
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Iccrg mailing list
> >>>>> [email-masked]
> >>>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
-------------------------------------------------------------------
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: [email-masked] (Lisong Xu)
Date: Sat Jun 18 01:44:44 2011
Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Mirja,

A scientific paper is meant for a researcher, but an RFC is for a 
programmer who wants to implement the protocol. This is why I want to 
specify the data type of acknowledgement.delay (possible others too).

OK, here is an example to illustrate the problem of unsigned variables.

assume all variables are unsigned short.

at some time (low queueing delay):
   local_timestamp = 3, and remote_timestamp = 5
   then acknowledgement.delay = 65534
   then base_delay = 65534

at some time later (high queueing delay):
   local_timestamp = 7, and remote_timestamp = 6
   then acknowledgement.delay = 1
   then base_delay = 1
   then queueing_delay = 0

Thanks
Lisong

On 6/17/2011 2:33 AM, Mirja Kuehlewind wrote:
> Hi Lisong,
>
> you are right, if it is an unsigned this might cause errors but its actually
> not a problem. If local_timestamp-remote_timestamp is negative but
> acknowledgement.delay is signed you will get a wrong result (but this doesn't
> matter as this delay does not show a real delay value anyway) but you will
> get a result because there simply will be an overflow.
> If you now calculate queuing_delay = current_delay - base_delay. Also this
> error will cancel out and you get an valid result.
>
> Anyway, its in the responsibility of the implementor to get the type and range
> right; its not part of the algorithm itself, from my point of view. Do you
> have a different opinion here?
>
> Mirja
>
>
> On Thursday 16 June 2011 18:36:24 Lisong Xu wrote:
>> Mirja,
>>
>> Thanks for your reply. I have only one question now.
>>
>> "it doesn't matter if the delay is positive or negative because its
>> canceled out in the calculation of the queuing delay and even an
>> overflow would work here."
>>
>> You are right that it does not matter whether acknowledgement.delay is
>> positive or negative. But variable acknowledgement.delay MUST be a
>> signed int. If it is implemented as an unsigned int, then sometimes
>> there will be a problem.
>>
>> Thanks
>> Lisong
>>
>> On 6/15/2011 6:07 AM, Mirja K?hlewind wrote:
>>> Hi Lisong
>>>
>>> thank you very much for your review! Please see comments inline.
>>>
>>> Mirja
>>>
>>> On Sunday 12 June 2011 08:53:10 Lisong Xu wrote:
>>>> Hi Michael,
>>>>
>>>> Below are my comments after reading the draft.
>>>> Thanks
>>>> Lisong
>>>>
>>>>
>>>> **** Section 3.1 ****
>>>> First sentence: "a loss occurs [RFC5681], which, in the absence of any
>>>> Active Queue Management (AQM) in the network, occurs only when the queue
>>>> at the bottleneck link on the end-to-end path overflows "
>>>>
>>>> Since a loss may occur due to link errors, such as fiber errors and
>>>> wireless errors, we may change the first sentence to
>>>> "... (AQM) and link errors in the network,...."
>>>
>>> Done.
>>>
>>>> **** Section 3.3 ****
>>>> The data type of each variable is not specified. Since some variables
>>>> must be signed variables, it is important to specify the type of each
>>>> variable in order to correctly implement the algorithm.
>>>>
>>>> For example, tcp_time_stamp is an unsigned int, so local_timestamp and
>>>> remote_timestamp are also unsigned int.  But variable
>>>> acknowledgement.delay should be a signed int, since
>>>> local_timestamp-remote_timestamp may be negative.
>>>
>>> I don't want to specify any data type here because that's only pseudo
>>> code of the algorithm and the range and resolution of a variable are
>>> implementation specific and might depend on the framing protocol used and
>>> of course as well on the programming language.
>>>
>>> Your example is a quite special case as one would assume that delay is
>>> always positive but you might get negative values because of the clock
>>> offset. Issues like clock offset and skew, which can come up in a real
>>> system, are not regarded as part of the algorithm. Anyway there is some
>>> discussion in the appendix. Moreover, in fact in this special example it
>>> doesn't matter if the delay is positive or negative because its canceled
>>> out in the calculation of the queuing delay and even an overflow would
>>> work here.
>>>
>>> The only case where it is important that a value can/must get negative is
>>> the off_target and this is mentioned explicit in 3.4.1.
>>>
>>>> **** Section 3.4.2 ****
>>>> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for the
>>>> last BASE_HISTORY minutes, and one for the running current minute."
>>>>
>>>> But the update_current_delay(delay) code maintains only BASE_HISTORY
>>>> minima. So the above sentence should be changed to
>>>> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for the
>>>> last BASE_HISTORY-1 minutes, and one for the running current minute."
>>>
>>> Thanks. You are right! Done.
>>>
>>>> **** Section 3.5 ****
>>>> "we recommend that the sender SHOULD use at least 4 samples in each RTT.
>>>> Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that no
>>>> samples in list are older than an RTT in the
>>>> past."
>>>>
>>>> But what if cwnd is less than 4? In this case, there are less than 4
>>>> samples in each RTT.
>>>
>>> That's why there is a SHOULD and not a MUST. If you have less samples,
>>> you can, of course, only use whatever you get. But the results might be
>>> very noisy and if you permanently have less then 4 samples, LEDBAT might
>>> not work correctly (because of noise in real systems).
>>>
>>> Should we make this more explicit?
>>>
>>>> **** General *****
>>>>
>>>> It is not clear what the relation between cwnd and flightsize is. Is
>>>> flightsize always the same as cwnd, or could be less than cwnd? When is
>>>> flightsize less than cwnd?
>>>
>>> flightsize can be less if your transfer is application-limited (and
>>> ALLOWED_INCREASE is large enough). Thus you don't have enough data to
>>> fill the cwnd.
>>>
>>> In the code you find
>>> " on acknowledgment:
>>>       # flightsize is the amount of data outstanding 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."
>>>
>>> I've added the following to 'on initialization:' (eventhough you find the
>>> same explanation in 3.2.)
>>> "   # cwnd is the amount of data that is allowed to send in one RTT and
>>>       # is defined in bytes."
>>>
>>> Does this help?
>>>
>>>> On 6/5/2011 12:38 AM, Michael Welzl wrote:
>>>>> Hi,
>>>>>
>>>>> We're urgently looking for a volunteer to review
>>>>> draft-ietf-ledbat-congestion-06:
>>>>> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
>>>>> which is currently in Last Call, ending in less than two weeks (15
>>>>> June).
>>>>>
>>>>> If anyone here is willing to do a review, please drop Murari and me a
>>>>> note ASAP!
>>>>>
>>>>> Thanks,
>>>>> Michael
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Iccrg mailing list
>>>>> [email-masked]
>>>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>

-- 
Lisong Xu, Associate Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu

From: [email-masked] (Mirja Kuehlewind)
Date: Fri Jun 17 10:32:03 2011
Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Lisong,

you are right, if it is an unsigned this might cause errors but its actually 
not a problem. If local_timestamp-remote_timestamp is negative but 
acknowledgement.delay is signed you will get a wrong result (but this doesn't 
matter as this delay does not show a real delay value anyway) but you will 
get a result because there simply will be an overflow.
If you now calculate queuing_delay = current_delay - base_delay. Also this 
error will cancel out and you get an valid result.

Anyway, its in the responsibility of the implementor to get the type and range 
right; its not part of the algorithm itself, from my point of view. Do you 
have a different opinion here? 

Mirja

On Thursday 16 June 2011 18:36:24 Lisong Xu wrote:
> Mirja,
>
> Thanks for your reply. I have only one question now.
>
> "it doesn't matter if the delay is positive or negative because its
> canceled out in the calculation of the queuing delay and even an
> overflow would work here."
>
> You are right that it does not matter whether acknowledgement.delay is
> positive or negative. But variable acknowledgement.delay MUST be a
> signed int. If it is implemented as an unsigned int, then sometimes
> there will be a problem.
>
> Thanks
> Lisong
>
> On 6/15/2011 6:07 AM, Mirja K?hlewind wrote:
> > Hi Lisong
> >
> > thank you very much for your review! Please see comments inline.
> >
> > Mirja
> >
> > On Sunday 12 June 2011 08:53:10 Lisong Xu wrote:
> >> Hi Michael,
> >>
> >> Below are my comments after reading the draft.
> >> Thanks
> >> Lisong
> >>
> >>
> >> **** Section 3.1 ****
> >> First sentence: "a loss occurs [RFC5681], which, in the absence of any
> >> Active Queue Management (AQM) in the network, occurs only when the queue
> >> at the bottleneck link on the end-to-end path overflows "
> >>
> >> Since a loss may occur due to link errors, such as fiber errors and
> >> wireless errors, we may change the first sentence to
> >> "... (AQM) and link errors in the network,...."
> >
> > Done.
> >
> >> **** Section 3.3 ****
> >> The data type of each variable is not specified. Since some variables
> >> must be signed variables, it is important to specify the type of each
> >> variable in order to correctly implement the algorithm.
> >>
> >> For example, tcp_time_stamp is an unsigned int, so local_timestamp and
> >> remote_timestamp are also unsigned int.  But variable
> >> acknowledgement.delay should be a signed int, since
> >> local_timestamp-remote_timestamp may be negative.
> >
> > I don't want to specify any data type here because that's only pseudo
> > code of the algorithm and the range and resolution of a variable are
> > implementation specific and might depend on the framing protocol used and
> > of course as well on the programming language.
> >
> > Your example is a quite special case as one would assume that delay is
> > always positive but you might get negative values because of the clock
> > offset. Issues like clock offset and skew, which can come up in a real
> > system, are not regarded as part of the algorithm. Anyway there is some
> > discussion in the appendix. Moreover, in fact in this special example it
> > doesn't matter if the delay is positive or negative because its canceled
> > out in the calculation of the queuing delay and even an overflow would
> > work here.
> >
> > The only case where it is important that a value can/must get negative is
> > the off_target and this is mentioned explicit in 3.4.1.
> >
> >> **** Section 3.4.2 ****
> >> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for the
> >> last BASE_HISTORY minutes, and one for the running current minute."
> >>
> >> But the update_current_delay(delay) code maintains only BASE_HISTORY
> >> minima. So the above sentence should be changed to
> >> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for the
> >> last BASE_HISTORY-1 minutes, and one for the running current minute."
> >
> > Thanks. You are right! Done.
> >
> >> **** Section 3.5 ****
> >> "we recommend that the sender SHOULD use at least 4 samples in each RTT.
> >> Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that no
> >> samples in list are older than an RTT in the
> >> past."
> >>
> >> But what if cwnd is less than 4? In this case, there are less than 4
> >> samples in each RTT.
> >
> > That's why there is a SHOULD and not a MUST. If you have less samples,
> > you can, of course, only use whatever you get. But the results might be
> > very noisy and if you permanently have less then 4 samples, LEDBAT might
> > not work correctly (because of noise in real systems).
> >
> > Should we make this more explicit?
> >
> >> **** General *****
> >>
> >> It is not clear what the relation between cwnd and flightsize is. Is
> >> flightsize always the same as cwnd, or could be less than cwnd? When is
> >> flightsize less than cwnd?
> >
> > flightsize can be less if your transfer is application-limited (and
> > ALLOWED_INCREASE is large enough). Thus you don't have enough data to
> > fill the cwnd.
> >
> > In the code you find
> > " on acknowledgment:
> >      # flightsize is the amount of data outstanding 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."
> >
> > I've added the following to 'on initialization:' (eventhough you find the
> > same explanation in 3.2.)
> > "   # cwnd is the amount of data that is allowed to send in one RTT and
> >      # is defined in bytes."
> >
> > Does this help?
> >
> >> On 6/5/2011 12:38 AM, Michael Welzl wrote:
> >>> Hi,
> >>>
> >>> We're urgently looking for a volunteer to review
> >>> draft-ietf-ledbat-congestion-06:
> >>> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
> >>> which is currently in Last Call, ending in less than two weeks (15
> >>> June).
> >>>
> >>> If anyone here is willing to do a review, please drop Murari and me a
> >>> note ASAP!
> >>>
> >>> Thanks,
> >>> Michael
> >>>
> >>>
> >>> _______________________________________________
> >>> Iccrg mailing list
> >>> [email-masked]
> >>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
-------------------------------------------------------------------
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: [email-masked] (Lisong Xu)
Date: Thu Jun 16 17:44:55 2011
Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Mirja,

Thanks for your reply. I have only one question now.

"it doesn't matter if the delay is positive or negative because its 
canceled out in the calculation of the queuing delay and even an 
overflow would work here."

You are right that it does not matter whether acknowledgement.delay is 
positive or negative. But variable acknowledgement.delay MUST be a 
signed int. If it is implemented as an unsigned int, then sometimes 
there will be a problem.

Thanks
Lisong

On 6/15/2011 6:07 AM, Mirja K?hlewind wrote:
> Hi Lisong
>
> thank you very much for your review! Please see comments inline.
>
> Mirja
>
>
> On Sunday 12 June 2011 08:53:10 Lisong Xu wrote:
>> Hi Michael,
>>
>> Below are my comments after reading the draft.
>> Thanks
>> Lisong
>>
>>
>> **** Section 3.1 ****
>> First sentence: "a loss occurs [RFC5681], which, in the absence of any
>> Active Queue Management (AQM) in the network, occurs only when the queue
>> at the bottleneck link on the end-to-end path overflows "
>>
>> Since a loss may occur due to link errors, such as fiber errors and
>> wireless errors, we may change the first sentence to
>> "... (AQM) and link errors in the network,...."
> Done.
>
>> **** Section 3.3 ****
>> The data type of each variable is not specified. Since some variables
>> must be signed variables, it is important to specify the type of each
>> variable in order to correctly implement the algorithm.
>>
>> For example, tcp_time_stamp is an unsigned int, so local_timestamp and
>> remote_timestamp are also unsigned int.  But variable
>> acknowledgement.delay should be a signed int, since
>> local_timestamp-remote_timestamp may be negative.
> I don't want to specify any data type here because that's only pseudo code of
> the algorithm and the range and resolution of a variable are implementation
> specific and might depend on the framing protocol used and of course as well
> on the programming language.
>
> Your example is a quite special case as one would assume that delay is always
> positive but you might get negative values because of the clock offset.
> Issues like clock offset and skew, which can come up in a real system, are
> not regarded as part of the algorithm. Anyway there is some discussion in the
> appendix. Moreover, in fact in this special example it doesn't matter if the
> delay is positive or negative because its canceled out in the calculation of
> the queuing delay and even an overflow would work here.
>
> The only case where it is important that a value can/must get negative is the
> off_target and this is mentioned explicit in 3.4.1.
>
>>
>> **** Section 3.4.2 ****
>> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for the
>> last BASE_HISTORY minutes, and one for the running current minute."
>>
>> But the update_current_delay(delay) code maintains only BASE_HISTORY
>> minima. So the above sentence should be changed to
>> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for the
>> last BASE_HISTORY-1 minutes, and one for the running current minute."
> Thanks. You are right! Done.
>
>> **** Section 3.5 ****
>> "we recommend that the sender SHOULD use at least 4 samples in each RTT.
>> Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that no
>> samples in list are older than an RTT in the
>> past."
>>
>> But what if cwnd is less than 4? In this case, there are less than 4
>> samples in each RTT.
> That's why there is a SHOULD and not a MUST. If you have less samples, you
> can, of course, only use whatever you get. But the results might be very
> noisy and if you permanently have less then 4 samples, LEDBAT might not work
> correctly (because of noise in real systems).
>
> Should we make this more explicit?
>
>>
>>
>> **** General *****
>>
>> It is not clear what the relation between cwnd and flightsize is. Is
>> flightsize always the same as cwnd, or could be less than cwnd? When is
>> flightsize less than cwnd?
> flightsize can be less if your transfer is application-limited (and
> ALLOWED_INCREASE is large enough). Thus you don't have enough data to fill
> the cwnd.
>
> In the code you find
> " on acknowledgment:
>      # flightsize is the amount of data outstanding 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."
>
> I've added the following to 'on initialization:' (eventhough you find the same
> explanation in 3.2.)
> "   # cwnd is the amount of data that is allowed to send in one RTT and
>      # is defined in bytes."
>
> Does this help?
>
>>
>> On 6/5/2011 12:38 AM, Michael Welzl wrote:
>>> Hi,
>>>
>>> We're urgently looking for a volunteer to review
>>> draft-ietf-ledbat-congestion-06:
>>> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
>>> which is currently in Last Call, ending in less than two weeks (15 June).
>>>
>>> If anyone here is willing to do a review, please drop Murari and me a
>>> note ASAP!
>>>
>>> Thanks,
>>> Michael
>>>
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
Lisong Xu, Associate Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu

From: [email-masked] (Mirja =?iso-8859-1?q?K=FChlewind?=)
Date: Wed Jun 15 14:12:10 2011
Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Lisong

thank you very much for your review! Please see comments inline.

Mirja

On Sunday 12 June 2011 08:53:10 Lisong Xu wrote:
> Hi Michael,
>
> Below are my comments after reading the draft.
> Thanks
> Lisong
>
>
> **** Section 3.1 ****
> First sentence: "a loss occurs [RFC5681], which, in the absence of any
> Active Queue Management (AQM) in the network, occurs only when the queue
> at the bottleneck link on the end-to-end path overflows "
>
> Since a loss may occur due to link errors, such as fiber errors and
> wireless errors, we may change the first sentence to
> "... (AQM) and link errors in the network,...."
Done.

> **** Section 3.3 ****
> The data type of each variable is not specified. Since some variables
> must be signed variables, it is important to specify the type of each
> variable in order to correctly implement the algorithm.
>
> For example, tcp_time_stamp is an unsigned int, so local_timestamp and
> remote_timestamp are also unsigned int.  But variable
> acknowledgement.delay should be a signed int, since
> local_timestamp-remote_timestamp may be negative.
I don't want to specify any data type here because that's only pseudo code of 
the algorithm and the range and resolution of a variable are implementation 
specific and might depend on the framing protocol used and of course as well 
on the programming language. 

Your example is a quite special case as one would assume that delay is always 
positive but you might get negative values because of the clock offset. 
Issues like clock offset and skew, which can come up in a real system, are 
not regarded as part of the algorithm. Anyway there is some discussion in the 
appendix. Moreover, in fact in this special example it doesn't matter if the 
delay is positive or negative because its canceled out in the calculation of 
the queuing delay and even an overflow would work here.

The only case where it is important that a value can/must get negative is the 
off_target and this is mentioned explicit in 3.4.1.

>
> **** Section 3.4.2 ****
> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for the
> last BASE_HISTORY minutes, and one for the running current minute."
>
> But the update_current_delay(delay) code maintains only BASE_HISTORY
> minima. So the above sentence should be changed to
> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for the
> last BASE_HISTORY-1 minutes, and one for the running current minute."
Thanks. You are right! Done.

> **** Section 3.5 ****
> "we recommend that the sender SHOULD use at least 4 samples in each RTT.
> Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that no
> samples in list are older than an RTT in the
> past."
>
> But what if cwnd is less than 4? In this case, there are less than 4
> samples in each RTT.
That's why there is a SHOULD and not a MUST. If you have less samples, you 
can, of course, only use whatever you get. But the results might be very 
noisy and if you permanently have less then 4 samples, LEDBAT might not work 
correctly (because of noise in real systems). 

Should we make this more explicit?

>
>
> **** General *****
>
> It is not clear what the relation between cwnd and flightsize is. Is
> flightsize always the same as cwnd, or could be less than cwnd? When is
> flightsize less than cwnd?
flightsize can be less if your transfer is application-limited (and 
ALLOWED_INCREASE is large enough). Thus you don't have enough data to fill 
the cwnd.

In the code you find
" on acknowledgment:
    # flightsize is the amount of data outstanding 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."

I've added the following to 'on initialization:' (eventhough you find the same 
explanation in 3.2.)
"   # cwnd is the amount of data that is allowed to send in one RTT and 
    # is defined in bytes."

Does this help?

>
> On 6/5/2011 12:38 AM, Michael Welzl wrote:
> > Hi,
> >
> > We're urgently looking for a volunteer to review
> > draft-ietf-ledbat-congestion-06:
> > http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
> > which is currently in Last Call, ending in less than two weeks (15 June).
> >
> > If anyone here is willing to do a review, please drop Murari and me a
> > note ASAP!
> >
> > Thanks,
> > Michael
> >
> >
> > _______________________________________________
> > Iccrg mailing list
> > [email-masked]
> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Sun Jun 12 08:40:56 2011
Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

thank you!

I'm cc'ing ledbat in my answer.

Cheers,
Michael

On Jun 12, 2011, at 8:53 AM, Lisong Xu wrote:

> Hi Michael,
>
> Below are my comments after reading the draft.
> Thanks
> Lisong
>
>
> **** Section 3.1 ****
> First sentence: "a loss occurs [RFC5681], which, in the absence of  
> any Active Queue Management (AQM) in the network, occurs only when  
> the queue at the bottleneck link on the end-to-end path overflows "
>
> Since a loss may occur due to link errors, such as fiber errors and  
> wireless errors, we may change the first sentence to
> "... (AQM) and link errors in the network,...."
>
> **** Section 3.3 ****
> The data type of each variable is not specified. Since some  
> variables must be signed variables, it is important to specify the  
> type of each variable in order to correctly implement the algorithm.
>
> For example, tcp_time_stamp is an unsigned int, so local_timestamp  
> and remote_timestamp are also unsigned int.  But variable  
> acknowledgement.delay should be a signed int, since local_timestamp- 
> remote_timestamp may be negative.
>
> **** Section 3.4.2 ****
> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for  
> the last BASE_HISTORY minutes, and one for the running current  
> minute."
>
> But the update_current_delay(delay) code maintains only BASE_HISTORY  
> minima. So the above sentence should be changed to
> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for  
> the last BASE_HISTORY-1 minutes, and one for the running current  
> minute."
>
> **** Section 3.5 ****
> "we recommend that the sender SHOULD use at least 4 samples in each  
> RTT. Thus, CURRENT_FILTER SHOULD be at least 4, and limited such  
> that no samples in list are older than an RTT in the
> past."
>
> But what if cwnd is less than 4? In this case, there are less than 4  
> samples in each RTT.
>
>
> **** General *****
>
> It is not clear what the relation between cwnd and flightsize is. Is  
> flightsize always the same as cwnd, or could be less than cwnd? When  
> is flightsize less than cwnd?
>
>
> On 6/5/2011 12:38 AM, Michael Welzl wrote:
>> Hi,
>>
>> We're urgently looking for a volunteer to review
>> draft-ietf-ledbat-congestion-06:
>> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
>> which is currently in Last Call, ending in less than two weeks (15  
>> June).
>>
>> If anyone here is willing to do a review, please drop Murari and me a
>> note ASAP!
>>
>> Thanks,
>> Michael
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>
> -- 
> Lisong Xu, Associate Professor
> Computer Science & Engineering
> University of Nebraska-Lincoln
> http://cse.unl.edu/~xu

From: [email-masked] (Lisong Xu)
Date: Sun Jun 12 07:52:40 2011
Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Michael,

Below are my comments after reading the draft.
Thanks
Lisong

**** Section 3.1 ****
First sentence: "a loss occurs [RFC5681], which, in the absence of any 
Active Queue Management (AQM) in the network, occurs only when the queue 
at the bottleneck link on the end-to-end path overflows "

Since a loss may occur due to link errors, such as fiber errors and 
wireless errors, we may change the first sentence to
"... (AQM) and link errors in the network,...."

**** Section 3.3 ****
The data type of each variable is not specified. Since some variables 
must be signed variables, it is important to specify the type of each 
variable in order to correctly implement the algorithm.

For example, tcp_time_stamp is an unsigned int, so local_timestamp and 
remote_timestamp are also unsigned int.  But variable 
acknowledgement.delay should be a signed int, since 
local_timestamp-remote_timestamp may be negative.

**** Section 3.4.2 ****
"a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for the 
last BASE_HISTORY minutes, and one for the running current minute."

But the update_current_delay(delay) code maintains only BASE_HISTORY 
minima. So the above sentence should be changed to
"a LEDBAT sender stores BASE_HISTORY separate minima- one each for the 
last BASE_HISTORY-1 minutes, and one for the running current minute."

**** Section 3.5 ****
"we recommend that the sender SHOULD use at least 4 samples in each RTT. 
Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that no 
samples in list are older than an RTT in the
past."

But what if cwnd is less than 4? In this case, there are less than 4 
samples in each RTT.

**** General *****

It is not clear what the relation between cwnd and flightsize is. Is 
flightsize always the same as cwnd, or could be less than cwnd? When is 
flightsize less than cwnd?

On 6/5/2011 12:38 AM, Michael Welzl wrote:
> Hi,
>
> We're urgently looking for a volunteer to review
> draft-ietf-ledbat-congestion-06:
> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
> which is currently in Last Call, ending in less than two weeks (15 June).
>
> If anyone here is willing to do a review, please drop Murari and me a
> note ASAP!
>
> Thanks,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
Lisong Xu, Associate Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu

From: [email-masked] (Michael Welzl)
Date: Mon Jun  6 09:31:32 2011
Subject: [Iccrg] Charter update
Message-ID: <[email-masked]>

Dear all,

The charter of ICCRG has been broadened, by adding the following  
paragraph at the end:

"Because congestion control is typically a key function of transport
protocols, it is hard to separate other transport layer issues from
congestion control. Considerations for deployment of transport
protocols are therefore also considered within scope. The ICCRG may
also consider congestion and protocol performance problems in general
IP networks, i.e., not only on the global Internet. One example of
such IP networks are multi-tenant, heterogeneous datacenters, which
in some sense represent a microcosm of the larger Internet; changes
to the transport protocols being considered in that space are
fundamental and can have broader implications."

We have by now established quite a history of
1) lots of interesting and interactive meetings, but
2) almost zero discussion on the list

This charter change, but most of all *you* could help us to change  
item #2 - send us your ideas, let's get some discussion rolling!

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Sun Jun  5 08:38:44 2011
Subject: [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
Message-ID: <[email-masked]>

Hi,

We're urgently looking for a volunteer to review draft-ietf-ledbat- 
congestion-06:
http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
which is currently in Last Call, ending in less than two weeks (15  
June).

If anyone here is willing to do a review, please drop Murari and me a  
note ASAP!

Thanks,
Michael