Subject: Re: [tcpm] New Version Notification for draft-cheng-tcpm-rack-00.txt

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 3 Nov 2015 13:03:56 +0000

Hi

Comments inline
Ingemar

> -----Original Message-----
> From: Neal Cardwell [mailto:[email-masked]]
> Sent: den 28 oktober 2015 17:48
> To: Ingemar Johansson S
> Cc: Yuchung Cheng; [email-masked]
> Subject: Re: New Version Notification for draft-cheng-tcpm-rack-00.txt
> 
> On Wed, Oct 28, 2015 at 12:01 PM, Ingemar Johansson S
> <[email-masked]> wrote:
> >
> > Thanks, really interesting.
> >
> > One question .
> > Quote "When the sender detects packet  reordering RACK.reo_wnd MAY
> be changed to RACK.min_RTT/4."
> > Why the value MinRTT/4 ? Is this related to TLP ?.
> 
> Good question. The rationale is discussed in section 5.3, "Adjusting the
> reordering window":
> 
>    RACK uses a quarter of minimum RTT because Linux TCP uses the same
>    factor in its implementation to delay Early Retransmit [RFC5827] to
>    reduce spurious loss detections in the presence of reordering, and
>    experience shows that this seems to work reasonably well.
> 
> > One option may be to set RACK.reo_wnd according to the experienced
> > amount of reordering but that can of course delay retransmission of
> > lost packet.
> 
> Yes, we agree that investigating this kind of approach is appealing, and this is
> also discussed in section 5.3, "Adjusting the reordering
> window":
> 
>    One potential improvement is to further adapt the reordering window
>    by measuring the degree of reordering in time, instead of packet
>    distances.  But that requires storing the delivery timestamp of each
>    packet.  Some scoreboard implementations currently merge SACKed
>    packets together to support TSO (TCP Segmentation Offload) for faster
>    scoreboard indexing.  Supporting per-packet delivery timestamps is
>    difficult in such implementations.  However, we acknowledge that the
>    current metric can be improved by further research.
OK, understand, It may well be that an adaptive reordering window may become too complex to maintain. 
I guess QUIC delivers the store timestamps for free as it operates on per packet basis ?

> Thanks for the feedback!
> neal