Re: questions on draft-ietf-quic-recovery

[Ian Swett <[e-mail]>]

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

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

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

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

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.


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

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

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