Subject: Re: [tcpm] comments for draft-ietf-tcpm-rack-00.txt

From: Yuchung Cheng <[email-masked]>
Date: Sun, 2 Oct 2016 09:20:56 -0700

On Sat, Oct 1, 2016 at 3:53 PM, Yuchung Cheng <[email-masked]> wrote:
> On Fri, Sep 30, 2016 at 12:20 AM, Yoshifumi Nishida
> <[email-masked]> wrote:
>> Hello,
>>
>> Thanks for an interesting proposal.
>> I've read the draft-ietf-tcpm-rack-00.txt and have the following comments on
>> the draft.
>> Please point out if I miss something.
>>
>> 1: I think the draft should mention how to control pipe size during loss
>> recovery.
>>     When RACK identifies lost packets, how it reduces cwnd?
> If RACK marks a packet lost, the pipe is reduced by 1.
>
> RACK does not change cwnd at all. It's congestion control's job. We
> intentionally want to decouple loss detection (what to send) from
> congestion control (how fast to send). But this is certainly worth
> clarifying more.
>
>>
>> 2: Similar to 1:, doesn't RACK have a certain back-off mechanism? I couldn't
>> find it in the draft.
>>     It is nice that it can find the lost of retransmitted packets, but does
>> it retransmits them again with the same settings?
>>     It seems to me that RACK might become aggressive under heavy congestions
>> as it keeps retransmitting packets with short intervals while other TCPs
>> wait for RTO.
> The concern of RACK interaction with current CC is valid. But again
> RACK only detects losses. The congestion control decides how fast to
> retransmit these packets under heavy or other congestion conditions.
> If the retransmission is too aggressive, C.C. is to blame.
>
> In reality, this has been true with Cubic-PRR under policers. Without
> RACK, Cubic used to timeout a lot under policer by failing to detect
> loss retransmission. With RACK, it detects them quickly and that
> exposes PRR is too aggressive. I've briefly mentioned this in RACK
> presentation in tcpm of 94 meeting. I have signed up another talk in
> next maprg to detail this issue.
>
>>
>> 3: I am not very sure if using the minimum value in all RTT measurements for
>> RACK.min_RTT is a really good option.
>>     If RTT is significantly increased all of sudden, it might cause lots of
>> spurious retransmits unless reordering window is dynamically adjusted.
> Many people have expressed the same concern. I am re-evaluating this part.
>
> But we chose of min RTT for a reason (which was not clear in the
> draft): with default loss-based CC + buffer-bloat, the current RTT
> when loss occurs can be 10x-100x (no kidding) of the min-RTT. For
> example, if the min-RTT is only 10ms (e.g., for many CDN caches placed
> inside ISPs), arming a reordering timer of 1000/4 = 250ms makes little
> sense, because the reordering is not tied to the present bottleneck
> queue status, but often the underlying link (wireless).
>
> That's said, min_RTT has issues too.
>
>>
>> 4: It is a bit confusing to me that the abstract says "modern TCP
>> implementations that can support per-packet timestamps.." because I thought
>> it was referring timestamp option. But, RACK actually doesn't rely on it. I
>> might prefer to say something like keep tracking transmit time per packet.
> Sure, we can reword to per packet transmit time and explicitly clarify
> this is NOT TCP timestamp options.
>
>>
>> 5: I guess you might want to add explanations of "RACK packet" and
>> "RACK.ack_ts" in Section 4. I think their definitions are not very clear.
> Sorry about that. How about:
>
>
>    "Packet.xmit_ts" refers to the transmission time of some data
> sequences sent by a TCP data segment. If the sequences have been
> retransmitted multiple times, it is the latest transmission. The
> sender needs to keep track of Packet.xmit_ts of all unacknowledged
> data sequences. The time granularity must be at least millisecond.
>
>    "RACK.xmit_ts" refers to the highest (i.e., most recent)
> Packet.xmit_ts being tracked currently.
>
>
>
>
>>
>> Thanks,
>> --
>> Yoshi
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 3 Oct 2016 09:56:10 -0700

Hi Yuchung,

Thanks for the comments.

> > congestion control (how fast to send). But this is certainly worth

Yes, while decoupling CC is fine, I think it would be good to see some
clarifications.
I guess you already have some recommended CC for RACK (and it's probably
not RFC5681)

> > If the retransmission is too aggressive, C.C. is to blame.

OK. I see the point.
But, this seems to say that we'll need to find a proper CC for RACK.

> > this is NOT TCP timestamp options.

Thanks!

> > Packet.xmit_ts being tracked currently.

Yes, I think this is clear. What I meant was the draft doesn't have
concrete definitions of RACK packet and RACK.ack_ts, while they are used in
the logics in Section 5.2. I can infer them, though.

--
Yoshi