[Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
Mirja Kühlewind
mirja.kuehlewind at ikr.uni-stuttgart.de
Wed Jun 15 14:07:46 BST 2011
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
> > Iccrg at cs.ucl.ac.uk
> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
More information about the Iccrg
mailing list