Re: [tcpm] Intended status of draft-ietf-tcpm-rack

[Praveen Balasubramanian <[e-mail]>]

Windows 10 and Server 2016/2019 have RACK enabled by default for connections with 10 msec or higher handshake RTT. But do not assume that RACK implies higher reordering resilience. The dynamic adjustment to reo_wnd is optional in the draft and requires DSACK support. Plus there is still large number of devices on older OS versions which don't have RACK. So for the time being strict ordering requirements are here to stay.

-----Original Message-----
From: Ingemar Johansson S <[e-mail]> 
Sent: Tuesday, November 19, 2019 6:52 PM
To: [e-mail]
Cc: Neal Cardwell <[e-mail]>; [e-mail]; Praveen Balasubramanian <[e-mail]>; Ingemar Johansson S <[e-mail]>
Subject: Re: Intended status of draft-ietf-tcpm-rack 

Hi

I am also in support of proposed standard for draft-ietf-tcpm-rack as this
can potentially relax the strict ordering requirements in 5G deployments. I
am not 100% certain of the actual value of proposed standard vs experimental
ditto outside IETF but it is definitely not of negative impact. 

A question (perhaps already discussed on the mailing list): 
How widely do you think that RACK will be deployed in TCP stacks in the near
and more far perspective?. 
I know that it is already in Linux. What about MS Windows, FreeBSD, IOS,
Android ??
/Ingemar

> Date: Mon, 18 Nov 2019 09:17:47 -0800
> From: Yuchung Cheng <[e-mail]>
> To: "Rodney W. Grimes" <[e-mail]>
> Cc: Neal Cardwell <ncardwell=[e-mail]>,  Praveen
> 	Balasubramanian <pravb=[e-mail]>,
> Michael
> 	Tuexen <[e-mail]>,  "[e-mail]
> Extensions"
> 	<[e-mail]>
> Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
> Message-ID:
> 	<CAK6E8=enBNBrTwkbDXKF5Snu-
> [e-mail]>
> Content-Type: text/plain; charset="utf-8"
> 
> PS +1 for same reasons people have mentioned
> 
> On Sun, Nov 17, 2019, 11:28 AM Rodney W. Grimes
> <[e-mail]>
> wrote:
> 
> > I am finding myself in agreement with others, PS is the correct status.
> >
> > Thank you Neal for the good siting of RFC7127 with respect to PS,
> >
> > Regards,
> > Rod
> >
> > > On Sun, Nov 17, 2019 at 3:49 AM Praveen Balasubramanian
> > > <pravb=[e-mail]> wrote:
> > > >
> > > > RACK is fundamental enough, subsumes TLP, and has enough
> > implementation and deployment. My vote is for PS status.
> > >
> > > Personally, I agree with Praveen, that "Proposed Standard" is
> > > appropriate, given my understanding of the definition from
> > > https://tools.ietf.org/html/rfc7127#section-3.1 :
> > >
> > >    3.1.  Characterization of IETF Proposed Standard Specifications
> > >    ...
> > >    A Proposed Standard specification is stable, has resolved known
> > >    design choices, has received significant community review, and
> > >    appears to enjoy enough community interest to be considered
> valuable.
> > >
> > >    Usually, neither implementation nor operational experience is
> > >    required for the designation of a specification as a Proposed
> > >    Standard.  However, such experience is highly desirable and will
> > >    usually represent a strong argument in favor of a Proposed Standard
> > >    designation.
> > >
> > > There are several independent and very widely deployed
> > > implementations of RACK at this point.
> > >
> > > best regards,
> > > neal
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> >
> > --
> > Rod Grimes
> > [e-mail]
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20191118/c25
> 5c28b/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> ------------------------------
> 
> End of tcpm Digest, Vol 187, Issue 64
> *************************************