Re: [tcpm] A review of draft-ietf-tcpm-rack-10

On Sun, Sep 20, 2020 at 6:16 PM Yi Huang
<huanyi=40microsoft.com@dmarc.ietf.org> wrote:
>
> Hi,
>
> I reviewed the latest version of RACK-TLP draft and have a few comments/questions.
>
> 1. In section 5.1, "Segment.retransmitted is true if it was retransmitted in the most recent transmission."
> There are also pseudo-code explaining how retransmitted flag is set. AFAICT, retransmitted is set if the segment is ever retransmitted since the flag is never reset. Is this variable supposed to mean ever retransmitted?
Thanks for catching that. Segment.retransmitted MUST be reset upon a
(re)transmission so it does not ever-retransmitted (i.e. it's only
meant for the very last transmission)

   RACK_transmit_data(Segment):
           Segment.xmit_ts = Now()
           Segment.lost = FALSE
           Segment.retransmitted = FALSE

   RACK_retransmit_data(Segment):
           RACK_transmit_data(Segment)
           Segment.retransmitted = TRUE

>
> 2. In section 6.2, p14,
> "   If the sender has not yet observed any reordering based on the
>    previous step, then RACK prioritizes quick loss recovery by using
>    setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds
>    DupThresh, or during loss recovery.
>
>    Aside from those special conditions, RACK starts with a conservative
>    reordering window of RACK.min_RTT/4.  This value was chosen because
>    Linux TCP used the same factor in its implementation to delay Early
>    Retransmit [RFC5827] to reduce spurious loss detections in the
>    presence of reordering, and experience showed this worked reasonably
>    well [DMCG11]."
>
> If I understand this correctly, if no reordering observed, TCP should still enter loss recovery when DupACK >= DupThresh (RFC6675). If reordering has been seen, this RFC6675 rule is not honored and TCP only enters loss recovery when RACK detects loss? I think it would be great to clarify this in the spec.

Your understanding is correct. will this text revision improves clarity"
""
If no reordering has been observed based on the previous step, the
sender enters Fast Recovery when the number of SACKed segments exceeds
DupThresh (similar to RFC6675). The RACK.reo_wnd is set to 0 both upon
entering and during the loss recovery.

Otherwise if some reordering has been observed, RACK does not honor
RFC6675 rule and starts with a conservative RACK.reo_wnd of
RACK.min_RTT/4. This .... reasonably well [DMCG11].
""

> "   If the sender has not yet observed any reordering based on the
>    previous step, then RACK prioritizes quick loss recovery by using
>    setting RACK.reo_wnd to 0 when the number of SACKed segments exceeds
>    DupThresh, or during loss recovery.
>
>    Aside from those special conditions, RACK starts with a conservative
>    reordering window of RACK.min_RTT/4.  This value was chosen because
>    Linux TCP used the same factor in its implementation to delay Early
>    Retransmit [RFC5827] to reduce spurious loss detections in the
>    presence of reordering, and experience showed this worked reasonably
>    well [DMCG11]."
>
> 3. [NIT] In section 8, " Zero window probe (ZWP) timer" -> "Zero Window Probe (ZWP) timer".
will fix thanks
>
> Thanks,
>
> Yi
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm