questions on draft-ietf-quic-recovery

[Yoshifumi Nishida <[e-mail]>]

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?