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 9A77CC1CAF58 for ; Wed, 19 Jun 2024 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.251 X-Spam-Level: X-Spam-Status: No, score=-7.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=apple.com 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 DHuqGDTY9TE1 for ; Wed, 19 Jun 2024 12:50:51 -0700 (PDT) Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) (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 8F629C1930B0 for ; Wed, 19 Jun 2024 12:50:51 -0700 (PDT) Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0SFC00PWIF4P8K20@ma-mailsvcp-mx-lapp02.apple.com> for iccrg@irtf.org; Wed, 19 Jun 2024 12:50:50 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-19_02,2024-06-19_01,2024-05-17_01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=cc : content-type : date : from : message-id : mime-version : subject : to; s=20180706; bh=7VuaMRPYUhIMN23+OEF27kIHlscRXlTrK5wVvIeKfsE=; b=VYPzQ4JvP2fv0B0w3UzrfpkpGE/d5vPpgVHlcmumy+sjJbBNGISvi7IazP0yRNCEFHPY AwEx8hNxez1/DCu3LDY4TQp9F2DnrTiF0vbiP8n+SYPDkpILI0MdD9RfIirYentfnyQc td2DJsyp9en7MjRP/8K79VaxrssAV/sZ51He5/ui7qBsm7J4soPxiMIvTPuHtyAxXRqu F9BViYrj/lR5AUOKA0nqDhs1qhvDRLAmUiqlWiogGE0SHp1yjltWXtd8cDkc8qYB/Wr8 iDTW2PgFfT8UC1t9RC9THp9zrYPAEVNLD+EOYlm6i3tKhUUcCj0M38+lbiq6PPGgBKoX Xw== Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0SFC00MF9F4PXC50@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 19 Jun 2024 12:50:49 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0SFC00100F31CC00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 19 Jun 2024 12:50:49 -0700 (PDT) X-Va-A: X-Va-T-CD: fe008101405254967261e62ee13a93b9 X-Va-E-CD: 5e69f4fe012301829936f3a08071a6ca X-Va-R-CD: 00ab78e132861cf57637c2ee40267c9a X-Va-ID: 9e88d41f-575e-4e86-847c-dc57eecefaff X-Va-CD: 0 X-V-A: X-V-T-CD: fe008101405254967261e62ee13a93b9 X-V-E-CD: 5e69f4fe012301829936f3a08071a6ca X-V-R-CD: 00ab78e132861cf57637c2ee40267c9a X-V-ID: 3c3cb1bf-dde1-42ab-8111-04aab3e251e4 X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-19_02,2024-06-19_01,2024-05-17_01 Received: from smtpclient.apple (unknown [17.11.86.192]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0SFC00FBRF4PWT00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 19 Jun 2024 12:50:49 -0700 (PDT) From: Vidhi Goel Content-type: multipart/alternative; boundary="Apple-Mail=_B9C03B2E-8AC8-49E5-896C-34ACE007303A" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3771.100.2\)) Message-id: Date: Wed, 19 Jun 2024 12:50:38 -0700 To: draft-irtf-iccrg-rledbat@ietf.org X-Mailer: Apple Mail (2.3771.100.2) Message-ID-Hash: CRYMO6BQAQBHG2WIUUXZ7ZMTHK5YIIUW X-Message-ID-Hash: CRYMO6BQAQBHG2WIUUXZ7ZMTHK5YIIUW X-MailFrom: vidhi_goel@apple.com 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: iccrg IRTF list X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Biccrg=5D_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: --Apple-Mail=_B9C03B2E-8AC8-49E5-896C-34ACE007303A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = ] is a congestion-control = algorithm that implements a less-than-best-effort (LBE) traffic class=E2=80= =9D Above line doesn=E2=80=99t read right as LEDBAT doesn=E2=80=99t = implement any traffic class. Suggestion: =E2=80=A6congestion-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 ] (hereafter = standard-TCP for short)," LEDBAT can share traffic with any connection, doesn=E2=80=99t matter = whether it is TCP or not. Suggestion: =E2=80=A6 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.=E2=80=9D 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=E2=80=A6.In the absence of any = competing traffic, LEDBAT aims to make=E2=80=A6 1.d "In this note, we describe rLEDBAT=E2=80=9D Should it be, =E2=80=9Cin this draft=E2=80=9D instead?/ 1.e "In section 4 about Experiment Considerations we describe the purpose of = the experiment and its current status=E2=80=9D Minor suggestion, =E2=80=9CIn section 4 titled Experiment = Considerations, we describe=E2=80=A6.=E2=80=9D 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.=E2=80= =9D Typo in the above sentence. Here, =E2=80=9C...distributed through a CDN = which surrogates do not support.. =E2=80=9C . I think comma is not required in this part, =E2=80=9C.. 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=E2=80=9D Typo in the last part, should be =E2=80=9C.. announced to the sender in = the TCP header=E2=80=9D 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=E2=80=9D 3.c "Also, the sender SHOULD implement some of the standard congestion = control mechanisms, such as Cubic [RFC8312 = ]=E2=80=9D Please update to the new Cubic RFC 9438. 3.d "rLEDBAT does not defines a new congestion control algorithm.=E2=80=9D 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, =E2=80=9C Should it be, =E2=80=9Cmore 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 = ] 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=20 Suggestion: rLEDBAt-> rLEDBAT Section - Measuring the RTT to estimate the queuing delay 3.2.1.a Suggestion: remove =E2=80=9Cthe=E2=80=9D before RTT in the title 3.2.1.b In order to estimate the queueing delay using the RTT, the rLEDBAT = receiver Suggestion: Remove =E2=80=9Cthe" before RTT and before rLEDBAT receiver. = In this section, at multiple places, =E2=80=9Cthe=E2=80=9D 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: =E2=80=A6 delay of a packet=E2=80=A6 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=E2=80=9D= . I get what it=E2=80=99s 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=20 3.3.a We call RCV.HGH the highest sequence number correspondent to Typo, correspondent-> corresponding Section - Security Considerations=20 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.=20 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 =E2=80=94=E2=80=94=E2=80=94=E2=80=94 Let me know if you have any questions. Vidhi --Apple-Mail=_B9C03B2E-8AC8-49E5-896C-34ACE007303A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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] is a congestion-control = algorithm that implements a less-than-best-effort (LBE) traffic = class=E2=80=9D

Above line doesn=E2=80=99t read right as LEDBAT = doesn=E2=80=99t implement any traffic class.
Suggestion: =E2=80=A6congestion-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] (hereafter standard-TCP for = short),"

LEDBAT can share traffic with any connection, doesn=E2=80=99t = matter whether it is TCP or not.
Suggestion:  =E2=80=A6 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.=E2=80=9D

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=E2=80=A6.In the absence of any competing traffic, LEDBAT = aims to make=E2=80=A6

1.d
"In this note, we describe = rLEDBAT=E2=80=9D

Should it be, =E2=80=9Cin this draft=E2=80=9D = instead?/

1.e
"In section 4 about Experiment = Considerations we describe the purpose of the experiment and its current = status=E2=80=9D

Minor suggestion, =E2=80=9C= In section 4 titled Experiment Considerations, we = describe=E2=80=A6.=E2=80=9D


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.=E2=80=9D

Typo in the above sentence. Here, =E2=80=9C...distributed through a CDN which surrogates do not support.. =E2=80=9C= .
I think comma is not = required in this part, =E2=80=9C.. 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=E2=80=9D

Typo in the last part, should be = =E2=80=9C.. announced to the sender in the TCP header=E2=80=9D

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=E2=80=9D

3.c
"Also, the = sender SHOULD implement some of the standard congestion control = mechanisms, such as Cubic [RFC8312]=E2=80=9D

Please update to the new Cubic = RFC 9438.

3.d
"rLEDBAT does not defines a new = congestion control algorithm.=E2=80=9D

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, =E2=80=9C

Should = it be, =E2=80=9Cmore 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] 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 =E2=80=9Cthe=E2= =80=9D before RTT in the title

3.2.1.b
In order to estimate the queueing delay using the RTT, the = rLEDBAT receiver

Suggestion: Remove =E2=80=9Cthe" before RTT and before rLEDBAT = receiver. In this section, at multiple places, =E2=80=9Cthe=E2=80=9D 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: =E2=80= =A6 delay of a packet=E2=80=A6
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=E2=80=9D. I get what = it=E2=80=99s 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


=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Let me know if you have = any questions.

Vidhi



= --Apple-Mail=_B9C03B2E-8AC8-49E5-896C-34ACE007303A--