Re: questions on draft-ietf-quic-recovery

[Yoshifumi Nishida <[e-mail]>]

Hi Ian,

Thank you so much for the detailed response. Things are getting clearer to
me now.
I will need to have some time to think about some of them, but I would like
to comments on the following points.
Also, I am very sorry that I have mostly read -15 version and didn't have
enough time to check -16 carefully (so, my question on 4.5.7.3 was wrong) .
I will try to re-read -16 before the meeting.

On Tue, Oct 30, 2018 at 6:34 PM Ian Swett <ianswett=
[e-mail]> wrote:
>
> Thanks for your careful reading, answers inline.
> On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida <[e-mail]>
wrote:
>> 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?
>
> 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.

I don't have explicit suggestions for now, but I guess we will need to
think about the following 2 questions.

Q1: Should implementations should support both modes or are they allow to
support only one of them?
Q2: An implementation that supports both modes can activate both logics at
the same time or the mode should be used exclusively?
I think these questions will lead to another question: How much freedom
implementations should have. For example, how much implementations should
follow the pseudo codes.

>> 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.
>
>
> 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.

Hmm... but, as you implement the logic in such a way, I think the current
early transmit logic in the draft is similar to the TLP logic in the draft.
If time_reordering_fraction is 1/8, it seems to me they are mostly
identical.
(Well, one may say this is a natural thing because early transmit and TLP
is aiming similar goal)

I might still overlook something, but it seems to me that the ack-based
scheme in QUIC just looks the time-based scheme in QUIC + retransmission
scheme with dupack threshold.
But, in this case, I am wondering that it may be enough just to have
ack-based scheme.

BTW, the original early retransmit in RFC5827 is to reduce dupack threshold
(kReorderingThreshold in QUIC) when outstanding data is less than 4 *SMSS.
Another condition is to activate only when there's no data to be sent in
the queue.
I  am thinking there would be a way to do this type of early retransmit in
QUIC by tweaking reordering_threshold although I probably don't recommend
it.

Thanks,
--
Yoshi