Re: [quicwg/base-drafts] Ack delays are adjusted by ack_delay_exponent (#3362)

[ianswett <[e-mail]>]

ianswett commented on this pull request.



> @@ -315,14 +315,16 @@ samples, and rttvar is the variation in the RTT samples, estimated using a
 mean variation.
 
 The calculation of smoothed_rtt uses path latency after adjusting RTT samples
-for ACK delays.  For packets sent in the ApplicationData packet number space,
-a peer limits any delay in sending an acknowledgement for an ack-eliciting
-packet to no greater than the value it advertised in the max_ack_delay transport
-parameter.  Consequently, when a peer reports an Ack Delay that is greater than
-its max_ack_delay, the delay is attributed to reasons out of the peer's control,
-such as scheduler latency at the peer or loss of previous ACK frames.  Any
-delays beyond the peer's max_ack_delay are therefore considered effectively
-part of path delay and incorporated into the smoothed_rtt estimate.
+for ACK delays. ACK delays are communicated in the ACK frame as an ack_delay
+field right shiften by the ack_delay_exponent transport parameter.  For packets

I think I'd rather not talk about shifting, since we describe it differently in transport, how about 'adjusted'?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3362#discussion_r368692253