From nobody Wed Mar 17 23:11:09 2021 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572DE3A209E for ; Wed, 17 Mar 2021 23:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L646VxQZS1fT for ; Wed, 17 Mar 2021 23:11:05 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0576E3A209C for ; Wed, 17 Mar 2021 23:11:04 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.0.43/8.16.0.43) with SMTP id 12I67FRY006161; Wed, 17 Mar 2021 23:11:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=RalAV/G2oaQFDG8X63PUTg2hZRpzo2RbCgI/sXge/mM=; b=inunrpwjyqWGXSKhYvyHhS1R3hHkUXUyp3XTUzlv3j0fZ76JGn500Ui5BtkE+BMlZKrS +DeXP0FQhj2e5e04B+fWBUBUDpmpVhkexcT9/4Ta/RFng1aJIrL+UB64vfgt0QOnvivs 2t0LLrl6aTbmCQdyKoYdBrd6qbaAJWvScnnCUz+ahmbpQjl5rcj9Kf7e2IvTxT76hFjC VeFikPQ69wJ2SOfk2dqvASce7x2L61kmGlhdasYYQWdlI1gSHUZq1fz7CbU/joR2DJut CTqI7MK+r54QUA5+pKYaiYOgk8o/UTf1eriz5hSw1hkXaLHYi1JnoEIBWAFaMb6QEQIb +Q== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 378t456hck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Mar 2021 23:11:03 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QQ500F0WIIFARD0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 17 Mar 2021 23:11:03 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QQ500I00I86CG00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 17 Mar 2021 23:11:03 -0700 (PDT) X-V-A: X-V-T-CD: 058bbac8ca772bcfc9e38720b87faa94 X-V-E-CD: a73bc9fdfae71d4bbd14013b04a8c9d1 X-V-R-CD: a1424e4cd2d59af676e64a21e913831b X-V-CD: 0 X-V-ID: 9bb18221-4295-43c1-a6b2-4bcc8dd3ba97 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-18_01:2021-03-17, 2021-03-18 signatures=0 Received: from [17.11.64.42] (unknown [17.11.64.42]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QQ5010MZIIEZ800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 17 Mar 2021 23:11:03 -0700 (PDT) From: Vidhi Goel Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_5F8CDF55-86A8-4A55-B5C0-3AD1F3D23D12" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: New Version Notification for draft-huitema-quic-ts-05.txt Date: Wed, 17 Mar 2021 23:11:02 -0700 In-reply-to: <25E11134-A5D7-43C2-9DA8-A055BA89B413@apple.com> Cc: IETF QUIC WG To: Christian Huitema References: <161602961576.29713.5556006395853657310@ietfa.amsl.com> <2F127CC0-5D13-4DEB-9B4D-4EF89C8D9E0F@apple.com> <71a72a2c-b6eb-7640-391c-663d21afa8da@huitema.net> <25E11134-A5D7-43C2-9DA8-A055BA89B413@apple.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-18_01:2021-03-17, 2021-03-18 signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 06:11:08 -0000 --Apple-Mail=_5F8CDF55-86A8-4A55-B5C0-3AD1F3D23D12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>> 3. Introduction: >>> Using 1WD solves these >>> issues. Similar argument can be made for most delay-based >>> algorithms. >>>=20 >>> I disagree that it can be said for most delay based CCAs. LEDBAT++ = and Receive LEDBAT don=E2=80=99t use OWD. >>> For delay based algorithms, I am of the opinion that we should = consider RTT (instead of 1WD) as we should also be mindful of the ACK = traffic on the return path, if it is congested and we can do that by = slowing down the sender. >>=20 >> Well, I am on the opinion that LEDBAT++ should use one-way-delay when = timestamps are available. It does fallback to RTT when timestamps are = not available, but that's a fallback mechanism, not a design goal. In = fact, section 4.5 of the LEDBAT++ draft = (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-= 4.5 = ) acknowledges that using RTT instead of one-way-delays "can lead to = unnecessary slowdowns=E2=80=9D >=20 > Yes, and LEDBAT++ continues to say the below. For a delay based CC, = how do you suggest the increased delay on reverse path (receiver to = sender) be handled, if we don=E2=80=99t use RTT? > "but in practice this > seems to benefit the workloads because bottleneck link can carry = ACK > traffic in the other direction for the competing flows." AccECN / L4S can definitely help on the reverse path but only if an = implementation supports it. For the near future, we still need to = address it and I think RTT helps with that. - Vidhi > On Mar 17, 2021, at 11:03 PM, Vidhi Goel = wrote: >=20 >>> 1. Abstract - QUIC is not used as an acronym. >> Yes. I don't use it as an acronym either. But I realize I wrote = "Quic" instead of "QUIC". I wonder whether WG members have strong = feelings about that. >=20 > It would be good to be consistent. I=E2=80=99d prefer it to be acronym = (QUIC). >=20 >>> 2. Introduction: >>> An example would be the Low Extra Delay Background Transport = (LEDBAT) >>> [RFC6817 >] which uses variations in = transmission delay =E2=80=A6. >>>=20 >>> I think you meant to say queuing delay here. >> No. I do mean transmission delay, because that's what the LEDBAT = implementations use. There is an assumption that the variations of = transmission delays correspond to variations of queuing delays, but = that's just an hypothesis. >=20 >=20 > I am confused. RFC 6817 says the below which points to queuing delay = varying while other delays remaining constant-ish. >=20 > =E2=80=9CEnd-to-end delay can be decomposed into transmission (or > serialization) delay, propagation (or speed-of-light) delay, = queueing > delay, and processing delay. On any given path, barring some = noise, > all delay components except for queueing delay are constant. To > observe an increase in the queueing delay in the network, a LEDBAT > sender separates the queueing delay component from the rest of the > end-to-end delay, as described below.=E2=80=9D >=20 >=20 >>> 3. Introduction: >>> Using 1WD solves these >>> issues. Similar argument can be made for most delay-based >>> algorithms. >>>=20 >>> I disagree that it can be said for most delay based CCAs. LEDBAT++ = and Receive LEDBAT don=E2=80=99t use OWD. >>> For delay based algorithms, I am of the opinion that we should = consider RTT (instead of 1WD) as we should also be mindful of the ACK = traffic on the return path, if it is congested and we can do that by = slowing down the sender. >>=20 >> Well, I am on the opinion that LEDBAT++ should use one-way-delay when = timestamps are available. It does fallback to RTT when timestamps are = not available, but that's a fallback mechanism, not a design goal. In = fact, section 4.5 of the LEDBAT++ draft = (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-= 4.5 = ) acknowledges that using RTT instead of one-way-delays "can lead to = unnecessary slowdowns=E2=80=9D >=20 > Yes, and LEDBAT++ continues to say the below. For a delay based CC, = how do you suggest the increased delay on reverse path (receiver to = sender) be handled, if we don=E2=80=99t use RTT? > "but in practice this > seems to benefit the workloads because bottleneck link can carry = ACK > traffic in the other direction for the competing flows." >=20 >>> 7. Section 2.3 >>> For congestion control, TIMESTAMP frames are treated like ACK = frames. >>>=20 >>> I don=E2=80=99t understand why this should be the case. I think = TIMESTAMP frame should be guarded by CC limits. >>=20 >> This text is based on a suggestion by Ian Swett, `The draft says = "TIME_STAMP frames are not ack-eliciting. Their loss does not require = retransmission." I (Ian) believe the draft should clarify whether = adding a TIME_STAMP frame to a packet causes it to count as in-flight as = PADDING would, or not in-flight as an ACK frame would. I (Ian) believe = treating it like an ACK frame is the ideal option, personally.` >>=20 >> The whole point of adoption by the WG is that we can discuss this = issue in the WG. >=20 > Sorry, I am not too familiar with IETF procedures. Does this mean we = can discuss in the next IETF meeting or something else? >=20 >=20 > Thanks, > Vidhi >=20 >> On Mar 17, 2021, at 9:39 PM, Christian Huitema > wrote: >>=20 >> Thanks for the review, Vidhi. >>=20 >> A few comments in line. >>=20 >> On 3/17/2021 8:44 PM, Vidhi Goel wrote: >>> Thanks Christian. >>>=20 >>> I have some comments. >>>=20 >>> 1. Abstract - QUIC is not used as an acronym. >> Yes. I don't use it as an acronym either. But I realize I wrote = "Quic" instead of "QUIC". I wonder whether WG members have strong = feelings about that. >>>=20 >>> 2. Introduction: >>> An example would be the Low Extra Delay Background Transport = (LEDBAT) >>> [RFC6817 >] which uses variations in = transmission delay =E2=80=A6. >>>=20 >>> I think you meant to say queuing delay here. >> No. I do mean transmission delay, because that's what the LEDBAT = implementations use. There is an assumption that the variations of = transmission delays correspond to variations of queuing delays, but = that's just an hypothesis. >>>=20 >>> 3. Introduction: >>> Using 1WD solves these >>> issues. Similar argument can be made for most delay-based >>> algorithms. >>>=20 >>> I disagree that it can be said for most delay based CCAs. LEDBAT++ = and Receive LEDBAT don=E2=80=99t use OWD. >>> For delay based algorithms, I am of the opinion that we should = consider RTT (instead of 1WD) as we should also be mindful of the ACK = traffic on the return path, if it is congested and we can do that by = slowing down the sender. >>=20 >> Well, I am on the opinion that LEDBAT++ should use one-way-delay when = timestamps are available. It does fallback to RTT when timestamps are = not available, but that's a fallback mechanism, not a design goal. In = fact, section 4.5 of the LEDBAT++ draft = (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-= 4.5 = ) acknowledges that using RTT instead of one-way-delays "can lead to = unnecessary slowdowns". The text in that section goes on explaining how = they mitigate that, but using one-way-delays would definitely be cleaner = than relying on mitigations. >>=20 >> And yes, it is worth monitoring congestion on the return path, but = the proper response there is not to "do as if the direct path was = congested." Other mechanisms are available, such as sending fewer ACKs = or fewer data on that path. >>=20 >>=20 >>>=20 >>> 4. Section 2.1 >>> 2 or 3 MUST NOT send these frames if the other >>> peer does not announce advertise >>>=20 >>> Typo - either announce or advertise >> Yes. Will fix that in the next iteration. >>>=20 >>> 5. Section 2.2 >>>=20 >>> Following successful sending negotiation=E2=80=A6 >>>=20 >>> =E2=80=9CSending=E2=80=9D is probably extraneous here. >> Yes. Will fix that too. >>>=20 >>> 6. Section 2.2 >>> They MAY be sent either before or after the ACK frame. >>>=20 >>> I think replacing =E2=80=9Csent=E2=80=9D with =E2=80=9Cadded=E2=80=9D = would be better here. >> Yes. >>>=20 >>> 7. Section 2.3 >>> For congestion control, TIMESTAMP frames are treated like ACK = frames. >>>=20 >>> I don=E2=80=99t understand why this should be the case. I think = TIMESTAMP frame should be guarded by CC limits. >>=20 >> This text is based on a suggestion by Ian Swett, `The draft says = "TIME_STAMP frames are not ack-eliciting. Their loss does not require = retransmission." I (Ian) believe the draft should clarify whether = adding a TIME_STAMP frame to a packet causes it to count as in-flight as = PADDING would, or not in-flight as an ACK frame would. I (Ian) believe = treating it like an ACK frame is the ideal option, personally.` >>=20 >> The whole point of adoption by the WG is that we can discuss this = issue in the WG. >>=20 >>> 8. Section 2.3 >>> The same applies to packets >>> containing only TIMESTAMP frames >>>=20 >>> For my curiosity, when do you think packets containing only TS frame = would be useful? Also, based on Section 2.6, such a packet wouldn=E2=80=99= t be used for 1wd computation. >>> Is it better to prohibit such a packet? >>=20 >> I would rather not introduce another failure condition. I have at = least one use case, measuring one way delays on seldom used paths in a = multi-path configuration. It is not exactly compelling, but at the same = time there is no strong reason to prohibit it. >>=20 >>>=20 >>> 9. Section 2.6 >>> latest_1wd =3D timestamp - send_time_of_largest_acked - phase_shift >>>=20 >>> I think ack_delay should also be subtracted to remove the processing = delay from the 1wd. >>>=20 >>> Alternatively, one could change how timestamp is encoded. The = current text in Section 2.3 says >>>=20 >>> "The timestamp encodes the number of microseconds since the = beginning >>> of the epoch, as measured by the peer at the time at which the = packet >>> is sent.=E2=80=9D >>>=20 >>> This could be changed to =E2=80=9Ctime at which the packet was = received by the peer=E2=80=9D. That would eliminate the processing = delay. >>=20 >> Good point. I think the computation should mention the ACK delay. >>=20 >> I like the timestamp being exactly the time at which the packet is = sent, because that keeps the specification very clean. It also helps = scenarios in which the timestamp is used with something else than an ACK = -- challenge response comes to mind, but there are probably other = possibilities when composing timestamps with other frames. Maybe = composing timestamps and datagrams in real time applications. >>=20 >>> Thats all for now. Will let you know if something else comes to = mind. >>>=20 >> Thanks for the feedback! >>=20 >> -- Christian Huitema >>=20 >>=20 >=20 --Apple-Mail=_5F8CDF55-86A8-4A55-B5C0-3AD1F3D23D12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
3. =
Introduction:
Using 1WD solves these
   issues.  Similar argument can be made =
for most delay-based
   algorithms.

I disagree that it can be said for most delay =
based CCAs. LEDBAT++ and Receive LEDBAT don=E2=80=99t use OWD.
For delay based algorithms, I am of the opinion that we =
should consider RTT (instead of 1WD) as we should also be mindful of the =
ACK traffic on the return path, if it is congested and we can do that by =
slowing down the sender.

Well, =
I am on the opinion that LEDBAT++ should use one-way-delay when =
timestamps are available. It does fallback to RTT when timestamps are =
not available, but that's a fallback mechanism, not a design goal. In =
fact, section 4.5 of the LEDBAT++ draft (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-0=
1#section-4.5) acknowledges that using RTT instead of one-way-delays =
"can lead to unnecessary slowdowns=E2=80=9D

Yes, and LEDBAT++ continues to say the below. For a delay =
based CC, how do you suggest the increased delay on reverse path =
(receiver to sender) be handled, if we don=E2=80=99t use =
RTT?
"but in practice =
this
   seems to benefit the workloads because bottleneck link can =
carry ACK
   traffic in the other direction for the competing =
flows."


AccECN / L4S can = definitely help on the reverse path but only if an implementation = supports it. For the near future, we still need to address it and I = think RTT helps with that.

-
Vidhi

On Mar = 17, 2021, at 11:03 PM, Vidhi Goel <vidhi_goel=3D40apple.com@dmarc.ietf.org> = wrote:

1. = Abstract - QUIC is not used as an acronym.
Yes.= I don't use it as an acronym either. But I realize I wrote "Quic" = instead of "QUIC". I wonder whether WG members have strong feelings = about that.

It would be = good to be consistent. I=E2=80=99d prefer it to be acronym (QUIC).

2. Introduction:
 An example would be the Low Extra Delay Background = Transport (LEDBAT)
   [RFC6817 <https://tools.ietf.org/html/rfc6817>] which uses = variations in transmission delay =E2=80=A6.

I= think you meant to say queuing delay here.
No.= I do mean transmission delay, because that's what the LEDBAT = implementations use. There is an assumption that the variations of = transmission delays correspond to variations of queuing delays, but = that's just an hypothesis.

I am confused. RFC 6817 = says the below which points to queuing delay varying while other delays = remaining constant-ish.

=E2=80=9CEnd-to-end delay can be = decomposed into transmission (or
   serialization) delay, propagation (or speed-of-light) =
delay, queueing
   delay, and processing delay.  On any given path, barring some noise,
   all delay components except for queueing delay are constant.  To
   observe an increase in the queueing delay in the network, a LEDBAT
   sender separates the queueing delay component from the rest of the
   end-to-end delay, as described below.=E2=80=9D


3. Introduction:
Using 1WD solves these
   issues. =
 Similar argument can be made for most delay-based
   algorithms.

I =
disagree that it can be said for most delay based CCAs. LEDBAT++ and =
Receive LEDBAT don=E2=80=99t use OWD.
For delay based =
algorithms, I am of the opinion that we should consider RTT (instead of =
1WD) as we should also be mindful of the ACK traffic on the return path, =
if it is congested and we can do that by slowing down the sender.

Well, I am on the opinion that =
LEDBAT++ should use one-way-delay when timestamps are available. It does =
fallback to RTT when timestamps are not available, but that's a fallback =
mechanism, not a design goal. In fact, section 4.5 of the LEDBAT++ draft =
(https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-0=
1#section-4.5) acknowledges that using RTT instead of one-way-delays =
"can lead to unnecessary slowdowns=E2=80=9D

Yes, and LEDBAT++ continues to say the =
below. For a delay based CC, how do you suggest the increased delay on =
reverse path (receiver to sender) be handled, if we don=E2=80=99t use =
RTT?
"but in practice =
this
   seems to benefit the workloads =
because bottleneck link can carry ACK
   traffic in the other direction for the competing flows."

7. Section 2.3
For congestion control, TIMESTAMP frames are treated like ACK =
frames.

I don=E2=80=99t understand why this =
should be the case. I think TIMESTAMP frame should be guarded by CC =
limits.

This text is based on =
a suggestion by Ian Swett, `The draft says "TIME_STAMP frames are not =
ack-eliciting. Their loss does not require retransmission." I =
(Ian)  believe the draft should clarify whether adding a TIME_STAMP =
frame to a packet causes it to count as in-flight as PADDING would, or =
not in-flight as an ACK frame would. I (Ian) believe treating it like an =
ACK frame is the ideal option, personally.`

The whole point of adoption by the WG is that we can discuss =
this issue in the WG.

Sorry, I am not too familiar with IETF procedures. Does this =
mean we can discuss in the next IETF meeting or something =
else?

Thanks,
Vidhi

On Mar 17, 2021, at 9:39 PM, Christian = Huitema <huitema@huitema.net> wrote:

Thanks= for the review, Vidhi.

A few comments in = line.

On 3/17/2021 8:44 PM, Vidhi Goel = wrote:
Thanks = Christian.

I have some comments.

1. Abstract - QUIC is not used as an = acronym.
Yes. I don't use it as an acronym = either. But I realize I wrote "Quic" instead of "QUIC". I wonder whether = WG members have strong feelings about that.

2. Introduction:
=  An example would be the Low Extra Delay Background Transport = (LEDBAT)
   [RFC6817 <https://tools.ietf.org/html/rfc6817>] which uses = variations in transmission delay =E2=80=A6.

I= think you meant to say queuing delay here.
No.= I do mean transmission delay, because that's what the LEDBAT = implementations use. There is an assumption that the variations of = transmission delays correspond to variations of queuing delays, but = that's just an hypothesis.

3. Introduction:
Using 1WD = solves these
   issues.  Similar = argument can be made for most delay-based
=    algorithms.

I disagree = that it can be said for most delay based CCAs. LEDBAT++ and Receive = LEDBAT don=E2=80=99t use OWD.
For delay based algorithms, = I am of the opinion that we should consider RTT (instead of 1WD) as we = should also be mindful of the ACK traffic on the return path, if it is = congested and we can do that by slowing down the sender.

Well, I am on the opinion that = LEDBAT++ should use one-way-delay when timestamps are available. It does = fallback to RTT when timestamps are not available, but that's a fallback = mechanism, not a design goal. In fact, section 4.5 of the LEDBAT++ draft = (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-0= 1#section-4.5) acknowledges that using RTT instead of one-way-delays = "can lead to unnecessary slowdowns". The text in that section goes on = explaining how they mitigate that, but using one-way-delays would = definitely be cleaner than relying on mitigations.

And yes, it is worth monitoring congestion on the return = path, but the proper response there is not to "do as if the direct path = was congested." Other mechanisms are available, such as sending fewer = ACKs or fewer data on that path.



4. = Section 2.1
2 or 3 MUST NOT send these frames if the = other
   peer does not announce = advertise

Typo  - either announce or = advertise
Yes. Will fix that in the next = iteration.

5. Section 2.2

Following = successful sending negotiation=E2=80=A6

=E2=80=9CSending=E2=80=9D is probably extraneous here.
Yes. Will fix that too.

6. Section 2.2
=  They MAY be sent either before or after the ACK frame.

I think replacing =E2=80=9Csent=E2=80=9D with = =E2=80=9Cadded=E2=80=9D would be better here.
Yes.

7. Section 2.3
For congestion = control, TIMESTAMP frames are treated like ACK frames.

I don=E2=80=99t understand why this should be the case. I = think TIMESTAMP frame should be guarded by CC limits.

This text is based on a = suggestion by Ian Swett, `The draft says "TIME_STAMP frames are not = ack-eliciting. Their loss does not require retransmission." I = (Ian)  believe the draft should clarify whether adding a TIME_STAMP = frame to a packet causes it to count as in-flight as PADDING would, or = not in-flight as an ACK frame would. I (Ian) believe treating it like an = ACK frame is the ideal option, personally.`

The whole point of adoption by the WG is that we can discuss = this issue in the WG.

8. Section 2.3
The same applies = to packets
   containing only TIMESTAMP = frames

For my curiosity, when do you think = packets containing only TS frame would be useful? Also, based on Section = 2.6, such a packet wouldn=E2=80=99t be used for 1wd computation.
Is it better to prohibit such a packet?

I would rather not introduce = another failure condition. I have at least one use case, measuring one = way delays on seldom used paths in a multi-path configuration. It is not = exactly compelling, but at the same time there is no strong reason to = prohibit it.


9. Section 2.6
 latest_1wd = =3D timestamp - send_time_of_largest_acked - phase_shift
I think ack_delay should also be subtracted to remove the = processing delay from the 1wd.

Alternatively,= one could change how timestamp is encoded. The current text in Section = 2.3 says

"The timestamp encodes the number = of microseconds since the beginning
   of = the epoch, as measured by the peer at the time at which the packet
   is sent.=E2=80=9D

This could be changed to =E2=80=9Ctime at which the packet = was received by the peer=E2=80=9D. That would eliminate the processing = delay.

Good point.  I = think the computation should mention the ACK delay.

I like the timestamp being exactly the time at which the = packet is sent, because that keeps the specification very clean. It also = helps scenarios in which the timestamp is used with something else than = an ACK -- challenge response comes to mind, but there are probably other = possibilities when composing timestamps with other frames. Maybe = composing timestamps and datagrams in real time applications.

Thats all = for now. Will let you know if something else comes to mind.

Thanks for the feedback!

-- Christian Huitema




= --Apple-Mail=_5F8CDF55-86A8-4A55-B5C0-3AD1F3D23D12--