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

[Vidhi Goel <[e-mail]>]

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)

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.

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),

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…

1.d
"In this note, we describe rLEDBAT”

Should it be, “in this draft” instead?/

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….”


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 think comma is not required in this part, “.. the file transfers, originated from CDN..."


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”

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”

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.

3.d
"rLEDBAT does not defines a new congestion control algorithm.”

Suggestion: defines->define

3.e
"Irrespectively of which congestion control algorithm is executed in the receiver"

Suggestion: Irrespectively-> Irrespective

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?

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

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

3.1.2.b
will have to accumulate the increases resulting from the different received packets

Suggestion: resulting from different received packets

Section - Measuring delays
3.2.a
In the next sections we describe how rLEDBAt 

Suggestion: rLEDBAt-> rLEDBAT

Section - Measuring the RTT to estimate the queuing delay
3.2.1.a
Suggestion: remove “the” before RTT in the title

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.


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..

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?

3.2.1.2.b
packet combinations.Also, applying a filter

Suggestion: Need a space before Also.

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.

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.

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.

Section - Detecting packet losses and retransmission 
3.3.a
We call RCV.HGH the highest sequence number correspondent to

Typo, correspondent-> corresponding

Section - Security Considerations 
5.a
as it relies in existing TCP knobs

Typo, relies in->on.

5.b
irrespectively whether rLEDBAT

irrespectively-> irrespective of

5.c
receiver that a loss has occur

Typo, occur->occurred


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?

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).

A.2
the WindowIncrease() function is an additive decrease

Typo, decrease->increase


————

Let me know if you have any questions.

Vidhi