Return-Path: X-Original-To: iccrg@ietfa.amsl.com Delivered-To: iccrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EE2C1CAE68 for ; Fri, 21 Jun 2024 14:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.005 X-Spam-Level: X-Spam-Status: No, score=-7.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBZiGrdaXQKK for ; Fri, 21 Jun 2024 14:11:24 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81183C15155B for ; Fri, 21 Jun 2024 14:11:24 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-42165f6645fso21446095e9.2 for ; Fri, 21 Jun 2024 14:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; t=1719004282; x=1719609082; darn=irtf.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=TFaXJPcF9Zu8UeDCyircwqKVqpD+wKl0g79PdCJPSZk=; b=f6WnMRGK2hfV4zepoOK6rIDQqeNdvMOGHNX373gPgd5Pm9x8mlE1nnnk2dZOA7yBu5 0VqlEvevjMVTXV0Az40fGGCWzQf+iL0A6zKPNhZTON0KLmLWwxpQVuROo52hHs6RUf56 TPFYb0gqvKb25Jamk8G01Z8DGf82JKk3lb/aPSnads31h41aP3ZkRobWZTSQNOqAKzoJ CMY8K4z2aXvxaDwTAeNHNXcheIduKQxsizb3AVDeAl18+8B+3mzt0AMFbcfrTimhZRwn 6V2nMOd9ULZZc7NsPC10onVsxaEtFYLdX4tCOBXAi+rd8JKB8oSDpbz0qY7bVTJ+vdo8 jNIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719004282; x=1719609082; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=TFaXJPcF9Zu8UeDCyircwqKVqpD+wKl0g79PdCJPSZk=; b=GP3se29G2M8nGvfTUzi2+TeVhhQy/sfb1jvGqkOEVfnN4S/L9oZ8G0NtXZC1w65NIy afnAGpJFkFrW4KpZtLAb/+Dm+PagakiWQFSObiY8FhAersh0jKY7r1VXDLdCExRXCNRx MoaDgxLTI1QOwmLjxhFNV4sLmHqp2RuXC77J2JJXi4RfW3bKa8JoercNFz23hJnuziLQ zuUKXoJzdjjJwMT4dRr3nv/ux0lQmwp6uPbfUS37hMqvxnOE8f/nvjoSGNOsbIsp14cG plpE+vyNb54hPMQEJydDwqPANhRxuOQ8xrYlKKJxEZrnA+XTT3x7hKv9u1e3HA1upLzQ TXhg== X-Forwarded-Encrypted: i=1; AJvYcCVmU8ZMxT5W3hZDd6wy1xzi1DStgrPE8CmPZ6Dy8F8hX4Y7mrFNHMXBXRvP0FIL3WiKCt6/sAxxARdsmD76ZQ== X-Gm-Message-State: AOJu0Yw3Wq3VOB4xYGdYLai5ZtHzkp4mD2jLI6HtNBfejFJ0Y03UpLw1 P9iSH454Aa8LaIQEMDTFxYCGkS2F2dF1Bsjb+2sAz4COBJYXC73v1GNSfnAOLwM= X-Google-Smtp-Source: AGHT+IEFoRGHkOxhzTKGRrXXNVchz9uNWfvpNAdltgqVZ2AlnQfAEht5o+Zxr5N+DleC5sapxXLSYA== X-Received: by 2002:a05:600c:41d5:b0:422:7eca:db62 with SMTP id 5b1f17b1804b1-424750786f1mr74716565e9.4.1719004281783; Fri, 21 Jun 2024 14:11:21 -0700 (PDT) Received: from [192.168.1.48] (135.41.94.90.dynamic.jazztel.es. [90.94.41.135]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4247d208b0esm78124315e9.38.2024.06.21.14.11.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Jun 2024 14:11:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------zAAbNKsSpr2hNW0VRpsrTxsn" Message-ID: <17593e43-2c8e-4721-9f93-9553480fc57e@it.uc3m.es> Date: Fri, 21 Jun 2024 23:11:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB To: Vidhi Goel References: <25590210-26d8-4096-86ef-2a87fb064ca5@it.uc3m.es> <87F6A013-2F8B-4304-AAA8-A53F0107112E@apple.com> From: marcelo bagnulo braun In-Reply-To: <87F6A013-2F8B-4304-AAA8-A53F0107112E@apple.com> Message-ID-Hash: MLWIXTLXOUEU6SZOEH6KBUDHVO4UVANH X-Message-ID-Hash: MLWIXTLXOUEU6SZOEH6KBUDHVO4UVANH X-MailFrom: marcelo@it.uc3m.es X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-iccrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-irtf-iccrg-rledbat@ietf.org, iccrg IRTF list X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Biccrg=5D_Re=3A_Review_of_draft-irtf-iccrg-rledbat-07?= List-Id: "Discussions of Internet Congestion Control Research Group (ICCRG)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------zAAbNKsSpr2hNW0VRpsrTxsn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> 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 >>> ] 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 ] (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 >>> ]”/ >>> >>> 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 >>> ] 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 >>> / >>> / >>> >>> >> >> > --------------zAAbNKsSpr2hNW0VRpsrTxsn Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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 <marcelo@it.uc3m.es> 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] 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] (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]”

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


--------------zAAbNKsSpr2hNW0VRpsrTxsn--