[iccrg] Re: Review of draft-irtf-iccrg-rledbat-07

[marcelo bagnulo braun <[e-mail]>]

below...

El 21/6/24 a las 21:56, Vidhi Goel escribió:
> *Section - Motivations for rLEDBAT*
>>> 2.a
>>> /"However, because the file is being distributed through a CDN which 
>>> surrogates do not support LBE congestion control, the result is that 
>>> the file transfers, originated from CDN surrogates will not be using 
>>> LBE.//”/
>>> /
>>> /
>>> Typo in the above sentence. Here, “.../distributed through a CDN 
>>> which surrogates do not support.. “ ./
>>
>> I am not sure what the typo is, sorry, i must be asleep still...
>>
> I am not quite sure but the sentence reads wrong grammatically, esp 
> this part, “which surrogates do not support”. Probably missing some 
> word or there is an extra word. If you remove “surrogates”, then it 
> reads fine. But I am not sure what was the intention of using this 
> word here.
>
>

Ok, I rephrased it as:


  However, because the file is being distributed through a CDN that does 
not implements LBE congestion control, the result is that the file 
transfers originated from CDN surrogates will not be using LBE.


>>> *Section - Measuring the RTT sending data packets*
>>> 3.2.1.2.a
>>> /The additional increase in the measured RTT will range between the 
>>> transmission delay of on packet and 500 ms./
>>> /
>>> /
>>> There is one typo and I have one question.
>>>
>>> Suggestion for typo: … delay of a packet…
>>> My question is, how is the increase in measured RTT range related to 
>>> transmission delay?
>>>
>> Not sure I understand the question, but since the increase may be up 
>> to 500 ms, I guess that the increase can be much larger than the RTT 
>> measured (which is why the draft allows the possibility for filtering 
>> those out).
>>
> The upper limit on delay is clear. But there is no lower limit as the 
> delay can be as low as 0. Maybe better to remove the lower limit and 
> only mention the upper limit?
>
>

Right, i phrased it as:


The additional increase in the measured RTT will be up to 500 ms.

Regards, marcelo



> Vidhi
>
>> On Jun 20, 2024, at 11:54 PM, marcelo bagnulo braun 
>> <[e-mail]> wrote:
>>
>> Hi Vidhi,
>>
>> Thank you very much for your comments.
>> I think I have addressed all of them.
>> Find attached the updated version of the draft.
>> I will submit it in a couple of days, if no other comment arises.
>>
>>
>>
>> I reply online below...
>>
>> El 19/6/24 a las 21:50, Vidhi Goel escribió:
>>> Hello Authors,
>>>
>>> Although this is coming after the last call, I had some comments as 
>>> I was going through the document one more time.
>>>
>>>
>>> General comment - Please update all references to TCP RFC [now RFC 
>>> 9293] and Cubic RFC (RFC 9438)
>>>
>> Done
>>
>>
>>> Most of the comments below are editorial for minor things. Sorry, 
>>> the list got a bit long.
>>>
>>> *Section - Introduction*
>>> 1.a
>>> /"LEDBAT (Low Extra Delay Background Transport) [RFC6817 
>>> <https://www.rfc-editor.org/info/rfc6817>] is a congestion-control 
>>> algorithm that implements a less-than-best-effort (LBE) traffic 
>>> class//”/
>>>
>>> Above line doesn’t read right as LEDBAT doesn’t implement any 
>>> traffic class.
>>> Suggestion: …congestion-control algorithm used for 
>>> less-than-best-effort (LBE) traffic.
>>>
>> done
>>
>>
>>> 1.b
>>> /"When LEDBAT traffic shares a bottleneck with one or more TCP 
>>> connections using standard congestion control algorithms such as 
>>> Cubic [RFC8312 <https://www.rfc-editor.org/info/rfc8312>] (hereafter 
>>> standard-TCP for short),"/
>>> /
>>> /
>>> LEDBAT can share traffic with any connection, doesn’t matter whether 
>>> it is TCP or not.
>>> Suggestion: / … /shares a bottleneck with other traffic using 
>>> standard congestion control algorithms (for example, TCP traffic 
>>> using Cubic[RFC 9438], hereafter referred as standard-TCP for short),
>>>
>> done
>>
>>
>>> 1.c
>>> /"it reduces its sending rate earlier and more aggressively than 
>>> standard-TCP congestion control, allowing standard-TCP traffic to 
>>> use more of the available capacity. In the absence of competing 
>>> standard-TCP traffic, LEDBAT aims to make an efficient use of the 
>>> available capacity, while keeping the queuing delay within 
>>> predefined bounds.//”/
>>>
>>> Again, the use of standard-TCP to refer to all competing traffic is 
>>> incorrect.
>>> Suggestion: .. than standard-TCP congestion control, allowing other 
>>> non-background traffic to use more of….In the absence of any 
>>> competing traffic, LEDBAT aims to make…
>>>
>> done
>>
>>
>>> 1.d
>>> /"In this note, we describe rLEDBAT//”/
>>> /
>>> /
>>> Should it be, “in this draft” instead?/
>>
>> well, it wouldnt be a draft when it is published as an RFC, no?
>>
>> I suggest in this specification?
>>
>>
>>>
>>> 1.e
>>> /"In section 4 about Experiment Considerations we describe the 
>>> purpose of the experiment and its current status”/
>>>
>>> Minor suggestion, “In section 4 titled Experiment Considerations, we 
>>> describe….”
>>>
>> done
>>
>>
>>>
>>> *Section - Motivations for rLEDBAT*
>>> 2.a
>>> /"However, because the file is being distributed through a CDN which 
>>> surrogates do not support LBE congestion control, the result is that 
>>> the file transfers, originated from CDN surrogates will not be using 
>>> LBE.//”/
>>> /
>>> /
>>> Typo in the above sentence. Here, “.../distributed through a CDN 
>>> which surrogates do not support.. “ ./
>>
>> I am not sure what the typo is, sorry, i must be asleep still...
>>
>>
>>> I think comma is not required in this part, “../ the file transfers, 
>>> originated from CDN..."/
>>> /
>>> /
>>>
>> removed the comma
>>
>>
>>> *Section - rLEDBAT mechanisms*
>>> 3.a
>>> /"The rLEDBAT receiver controls the sender's rate through the 
>>> Receive Window announced to the receiver in the TCP header”/
>>>
>>> Typo in the last part, should be “.. /announced to the sender in the 
>>> TCP header//”/
>>> /
>>> /
>>
>> Actually, what i think I meant was announced by the receiver
>>
>>
>>> 3.b
>>> /"The envisioned deployment model for rLEDBAT is that the clients 
>>> implement rLEDBAT and this enable rLEDBAT"/
>>>
>>> Small typo in the end, "enable->enables”
>>>
>> done
>>
>>
>>> 3.c
>>> /"Also, the sender SHOULD implement some of the standard congestion 
>>> control mechanisms, such as Cubic [RFC8312 
>>> <https://www.rfc-editor.org/info/rfc8312>]”/
>>>
>>> Please update to the new Cubic RFC 9438.
>>
>>
>> done
>>
>>>
>>> 3.d
>>> /"rLEDBAT does not defines a new congestion control algorithm.”/
>>>
>>> Suggestion: defines->define
>>>
>> done
>>
>>
>>> 3.e
>>> /"Irrespectively of which congestion control algorithm is executed 
>>> in the receiver"/
>>>
>>> Suggestion: Irrespectively-> Irrespective
>>
>>
>> done
>>
>>>
>>> *Section - Controlling the receive window*
>>> 3.1.a
>>> /"This guarantees that the rLEDBAT flow will never transmit more 
>>> aggressively than a TCP flow,//“/
>>> /
>>> /
>>> Should it be, “more aggressively than a standard-TCP flow?
>>
>> done
>>
>>
>>>
>>> *Section - Avoiding Window Shrinking*
>>> 3.1.1.a
>>> /"window output from the LEDBAT/LEDBAT++ algorithms since they only 
>>> allows to perform at most one multiplicative decrease per RTT"/
>>>
>>> Suggestion: allows->allow
>>>
>> done
>>
>>
>>> *Section - Window Scale option*
>>> 3.1.2.a
>>> /The Window Scale (WS) option [RFC7323 
>>> <https://www.rfc-editor.org/info/rfc7323>] is a mean to increase/
>>> /
>>> /
>>> Suggestion: mean->means
>>>
>> done
>>
>>
>>> 3.1.2.b
>>> /will have to accumulate the increases resulting from the different 
>>> received packets/
>>>
>>> Suggestion: resulting from different received packets
>>>
>> done
>>
>>
>>> *Section - Measuring delays*
>>> 3.2.a
>>> In the next sections we describe how rLEDBAt
>>>
>>> Suggestion: rLEDBAt-> rLEDBAT
>>
>> done
>>
>>
>>>
>>> *Section - Measuring the RTT to estimate the queuing delay*
>>> 3.2.1.a
>>> Suggestion: remove “the” before RTT in the title
>>
>> done
>>
>>
>>>
>>> 3.2.1.b
>>> /In order to estimate the queueing delay using the RTT, the rLEDBAT 
>>> receiver/
>>>
>>> Suggestion: Remove “the" before RTT and before rLEDBAT receiver. In 
>>> this section, at multiple places, “the” is used before RTT which is 
>>> not needed. It would be good to fix them all.
>>>
>> done
>>
>>
>>>
>>> *Section - Measuring RTT sending pure ACKs*
>>> 3.2.1.1.a
>>> /since the rLEDBAT is not actively controlling the sender's rate./
>>> /
>>> /
>>> Suggestion: since the rLEDBAT node..
>>>
>> done
>>
>>
>>> *Section - Measuring the RTT sending data packets*
>>> 3.2.1.2.a
>>> /The additional increase in the measured RTT will range between the 
>>> transmission delay of on packet and 500 ms./
>>> /
>>> /
>>> There is one typo and I have one question.
>>>
>>> Suggestion for typo: … delay of a packet…
>>> My question is, how is the increase in measured RTT range related to 
>>> transmission delay?
>>>
>> Not sure I understand the question, but since the increase may be up 
>> to 500 ms, I guess that the increase can be much larger than the RTT 
>> measured (which is why the draft allows the possibility for filtering 
>> those out).
>>
>>
>>> 3.2.1.2.b
>>> /packet combinations.Also, applying a filter/
>>>
>>> Suggestion: Need a space before Also.
>>>
>> done
>>
>>
>>> *Section - Measuring one way delay to estimate queuing delay*
>>> 3.2.2.a
>>> /by subtracting the time stamp contained in the incoming packet/
>>>
>>> Suggestion: timestamp is one word.
>>>
>> done
>>
>>
>>> 3.2.2.b
>>> /receiver compares how much local time has elapsed between the 
>>> sender has issued two packets with different TS values./
>>>
>>> There is a small grammar problem at "between the sender has issued”. 
>>> I get what it’s saying but if you have ideas to fix it, that would 
>>> be great.
>>>
>> I think the problem with that sentence was that it was using compared 
>> as the verb, but there was no mention regarding what we were 
>> comparing against. I changed the verb to measure, hoping that this 
>> will improve it.
>>
>> The result is:
>>
>> In order to learn both the TS units and the clock skew, the rLEDBAT 
>> receiver measures how much local time has elapsed between the sender 
>> has issued two packets with different TS values. By comparing the 
>> local time difference and the TS value difference, the receiver can 
>> assess the TS units and relative clock skews.
>>
>>
>>
>>> 3.2.2.c
>>> /the problem is that the receiver is unaware if the sender is 
>>> injecting traffic at any point in time, and opportunistically seize 
>>> quiet intervals to preform measurements./
>>>
>>> Minor typos, seize->seizes, preform->perform.
>>>
>> done
>>
>>
>>> *Section - Detecting packet losses and retransmission *
>>> 3.3.a
>>> /We call RCV.HGH the highest sequence number correspondent to/
>>> /
>>> /
>>> Typo, correspondent-> corresponding
>>>
>> done
>>
>>
>>> *Section - Security Considerations*
>>> 5.a
>>> /as it relies in existing TCP knobs/
>>>
>>> Typo, relies in->on.
>>>
>> done
>>
>>
>>> 5.b
>>> /irrespectively whether rLEDBAT/
>>>
>>> irrespectively-> irrespective of
>>>
>> done
>>
>>
>>> 5.c
>>> /receiver that a loss has occur/
>>>
>>> Typo, occur->occurred
>>>
>> done
>>
>>
>>>
>>> 5.d
>>> /This means that the attacker can achieve a reduction of incoming 
>>> flows to the rLEDBAT receiver/
>>>
>>> Did you mean reduction of incoming traffic/packets?
>>>
>> yes, changed that
>>
>>
>>> *Section - Appendix A*
>>> A.1
>>> /one that is executed when a packet is received by a rLEDBAT-enabled 
>>> endpoint, Figure 2 and another, Figure 3, that is executed when the 
>>> rLEDBAT-enabled endpoint sends a packet./
>>>
>>> Typo in the first line, a rLEDBAT -> an rLEDBAT.
>>> Another suggestion regarding placement of Figure 3, would it be 
>>> better to place Figure 3 text at the end of the sentence? Something 
>>> like,
>>>
>>> /one that is executed when a packet is received by a rLEDBAT-enabled 
>>> endpoint (Figure 2) and another that is executed when the 
>>> rLEDBAT-enabled endpoint sends a packet (Figure 3)./
>>> /
>>> /
>>
>> done
>>
>>
>>> /A.2/
>>> /the WindowIncrease() function is an additive decrease/
>>>
>>> Typo, decrease->increase
>>>
>>>
>> done
>>
>>
>>> ————
>>>
>>> Let me know if you have any questions.
>>>
>>> Vidhi
>>> /
>>> /
>>>
>>>
>>
>> <draft-irtf-iccrg-rledbat-09a.txt>
>