Subject: [tcpm] questions on draft-ietf-quic-recovery

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 29 Oct 2018 10:02:15 -0700

Hello,

At Bangkok, TCPM WG will have a session to discuss loss recovery and
congestion control mechanism in QUIC and TCP. (11/6 Tuesday
11:20-12:20)
I really appreciate Ian and Jana for the efforts.

I might overlook something as I couldn't follow up all discussion in
QUIC, but I am thinking that it might be good if we could get some
comments on the following questions.
I have listed several questions on the value of some parameters, but
it doesn't mean I disagree with these values. I just would like to
check where these values came from.
Hope this will be useful in some ways.

Section 4:
   QUIC supports both ack and timer for loss detection.
   But, it's not very clear whether an implementation can choose one
of them or it should implement both and can use both at the same time.
Can it be clarified?

Section 4.1.1:
   For RTT sampling, implementations will need to maintain the
transmission time for each sending packets even if they support only
ack-based method.
   But, this requirement might be hard for tiny devices. Wouldn't it
limit the applicability of QUIC?

   "the largest newly acked packet" might be confusing. packet that
acks the largest packet number?

Section 4.2.1:
   TCP RACK's reo_wnd is aiming to be 1/4 RTT. Why QUIC uses 1/8 RTT?

Section 4.2.2:
   The early retransmit logic in QUIC seems to be different from TCP's one.
   It doesn't look ack-based as it relies on timer. (I don't say this
is bad, but it's a bit strange to categorize it as an ack-based
method)
   TCP's early retransmit will be triggered only when the amount of
outstanding data is less than 4*SMSS, but this draft doesn't mention
about the condition. Is there any reason for it?
   when timer-based loss detection is used, it this logic still
available? or it won't be used with timer-based loss detection? We
might need clarifications here.

Section 4.3.2:
   TCP RACK's PTO is aiming to be 2 * SRTT. Why QUIC uses 1.5 * SRTT?

Section 4.3.3:
   RFC5681 uses 1 SMSS as the size of loss window, while QUIC uses 2.
I understand the motivation to reduce the possibility of consecutive
RTO events. But, this may means when TCP and QUIC connections are
under heavy congestion, QUIC connections will recover more quickly
than TCP connections. We might want to think how much QUIC and TCP
should be fair.

   BTW, it might not be necessarily, but QUIC does not need the upper
bound for RTO?

Section 4.4:
   why the default value of max_ack_delay is 25ms?

Section 4.5.7.3:
   Sorry.. what is 1/4 RTT timer for early retransmit?

Section 5.8.1:
   Why the recommended value is 1200 bytes?

---

From: Ian Swett <[email-masked]>
Date: Tue, 30 Oct 2018 21:34:39 -0400

Thanks for your careful reading, answers inline.
On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida <[email-masked]>

> congestion control mechanism in QUIC and TCP. (11/6 Tuesday

Yes, there's an open Issue to clarify this.
https://github.com/quicwg/base-drafts/issues/1212

The outstanding PR is quite old, but has some helpful clarifications in it,
so I'm intending to migrate the best parts to a new PR.  Suggestions(or
PRs) welcome.

> limit the applicability of QUIC?

Good question.  Assuming a ~1200 byte packet and a 4 byte timestamp, that's
<0.5% of the total storage overhead, assuming the data being sent is
reliable.  That doesn't seem like too much overhead to me, but one could
certainly store less granular information if they were really constrained.
ie: packet numbers X to X+N all contain a certain sequence of bytes and
were sent at approximately a single time.  I believe such a storage
approach would make it more similar to TCP metadata, but you likely know
better than I do.

> acks the largest packet number?

 That's the largest packet that was acknowledged in the current ack frame
being processed.  I re-read the text and I'm not sure how to improve it, so
feel free to send a PR.

>    TCP RACK's reo_wnd is aiming to be 1/4 RTT. Why QUIC uses 1/8 RTT?

I ran some experiments that indicated 1/4 RTT was a slight latency
regression for web applications and 1/8 RTT still had fewer spurious
retransmits than the dupack threshold loss detection.  I also presented
some reordering data at maprg in Montreal that indicated 1/8 RTT was
typically enough.  Obviously different networks and workloads are
different, and I think the best approach is likely an adaptive one, but I
don't have an adaptive algorithm I'm confident enough in to write it up.
Suggestions definitely welcome.

> might need clarifications here.

The timer is taken from Linux, as mentioned at the end of 4.2.2.  It's
categorized as ACK based because it is only armed when a packet with a
larger packet number than the one being lost has been acknowledged.  One
could argue the same issue for time based loss detection, which also needs
a timer.

Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed like
the core issue being fixed was that there was no other mechanism for
quickly declaring these packets lost, and if one did implement adaptive
reordering tolerance, one threshold wouldn't be out of sync with the other.

The intent is that like RACK, timer based loss detection subsumes early
retransmit.  But yes, this text could use some further clarification,
including and not limited to items pointed out in #1212.

>    TCP RACK's PTO is aiming to be 2 * SRTT. Why QUIC uses 1.5 * SRTT?

This arose because TCP uses 1.5 * SRTT + MaxAckDelay if there is only one
MSS outstanding.  QUIC is still arriving at the optimal algorithm for
sending ACKs and how to indicate that to the peer, so QUIC explicitly
specifies MaxAckDelay in the handshake and always includes the MaxAckDelay
in PTO.  We could go back to the approach of trying to determine whether a
fast ACK is expected and use 2 * SRTT in that case, if we thought it was
better, but this is a bit simpler.

> than TCP connections. We might want to think how much QUIC and TCP

I have some experimental code to see if 2 packets makes a difference vs 1
packet.  If not, we can change QUIC to 1.  If it does make a difference,
then we should discuss what to recommend for both TCP and QUIC.

>    BTW, it might not be necessarily, but QUIC does not need the upper

In practice, I'd expect a QUIC connection to idle timeout before it hit the
upper bound.  We could add one if you think it's useful, but it seemed
safer to continue with exponential backoff.

>    why the default value of max_ack_delay is 25ms?

It was a chosen as a good general purpose value for modern networks.  25ms
means sending an ACK for every packet only if packets are evenly spaced and
the bandwidth is about 300kbits or lower if my math is correct.  That's
definitely on the lower end of internet speeds.  Additionally, if a client
knows they're on such a slow link(2g) they can use the MaxAckDelay
transport param to specify a larger ack delay.

Or, from 4.6:
"A shorter delayed ack time of 25ms was chosen because longer delayed

   acks can delay loss recovery and for the small number of connections
   where less than packet per 25ms is delivered, acking every packet is
   beneficial to congestion control and loss recovery."

>    Sorry.. what is 1/4 RTT timer for early retransmit?

 Sorry, I can't seem to find the reference to a 1/4 RTT timer for early
retransmit.

>    Why the recommended value is 1200 bytes?
That's from QUIC transport, but the intent is to make the minimum MTU
fairly large to avoid amplification attacks as well as provide enough room
for the TLS ClientHello.