Subject: Re: questions on draft-ietf-quic-recovery

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 1 Nov 2018 16:12:09 -0700

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

---

From: Ian Swett <[email-masked]>
Date: Sat, 3 Nov 2018 18:28:03 -0400

On Thu, Nov 1, 2018 at 7:12 PM Yoshifumi Nishida <[email-masked]>
wrote:

> I will need to have some time to think about some of them, but I would
> like to comments on the following points.

Not a problem, the drafts are still changing quite rapidly.

> > On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida <
> [email-masked]> wrote:
> >> Section 4:

The existing text says one may use one or the other or both.  I tend to
think we'll end up with always using both and removing the early retransmit
special case.  I believe the recent RACK draft removes early retransmit
entirely, correct?(BTW, it mentions early retransmit, but doesn't
explicitly say it replaces it from my reading).  If you think that would be
an improvement, I can file an issue for that and it might be worth
discussing in tcpm.

> (Well, one may say this is a natural thing because early transmit and TLP

I tried to clarify the timers used in Early Retransmit and Time-Based loss
detection in PR#1957 <https://github.com/quicwg/base-drafts/pull/1957>.
Please take a look if you have time.  The text about time-based loss
detection needs further work, but this is a start along that direction.

> But, in this case, I am wondering that it may be enough just to have

I'm not sure I understand fully, but I expect that's because the current
text is unclear.

>
> BTW, the original early retransmit in RFC5827 is to reduce dupack
> threshold (kReorderingThreshold in QUIC) when outstanding data is less
> than 4 *SMSS.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 4 Nov 2018 01:21:57 -0700

Hi Ian,

On Sat, Nov 3, 2018 at 3:28 PM Ian Swett <[email-masked]> wrote:

>> Thank you so much for the detailed response. Things are getting clearer
>> to me now.
>> Q2: An implementation that supports both modes can activate both logics
>> at the same time or the mode should be used exclusively?

The current RACK uses adopted reordering window and it will be ACK-based
when no reordering is observed. I am thinking it might be an interesting
topic to be discussed.

>> > Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed
>> like the core issue being fixed was that there was no other mechanism for
>> (Well, one may say this is a natural thing because early transmit and
>> TLP is aiming similar goal)
>>
>

OK. I will think about this a bit more.

> I'm not sure I understand fully, but I expect that's because the current

Or, I overlook something. In any case, I think it is great to have a chance
to discuss specifically loss discovery and CC. Thank you so much!
--
Yoshi