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

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 19 Nov 2019 10:51:57 +0000

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 <[email-masked]>
> To: "Rodney W. Grimes" <[email-masked]>
> Cc: Neal Cardwell <ncardwell=[email-masked]>,  Praveen
> 	Balasubramanian <pravb=[email-masked]>,
> Michael
> 	Tuexen <[email-masked]>,  "[email-masked]
> Extensions"
> 	<[email-masked]>
> Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-rack
> Message-ID:
> 	<CAK6E8=enBNBrTwkbDXKF5Snu-
> [email-masked]>
> 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
> <[email-masked]>
> 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=[email-masked]> 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> >
> > --
> > Rod Grimes
> > [email-masked]
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> ------------------------------
> 
> End of tcpm Digest, Vol 187, Issue 64
> *************************************

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 19 Nov 2019 19:06:10 +0800

> On 19 Nov, 2019, at 6:51 pm, Ingemar Johansson S <ingemar.s.johansson=[email-masked]> wrote:
> 

Android is Linux, to a first approximation, and thus inherits its networking capabilities.

FreeBSD I understand has a RACK-capable TCP stack, but which is not the default.  I think Rod Grimes should be able to clarify this, and he's also on this list.

Apple devices I do not know for sure about.

 - Jonathan Morton

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 19 Nov 2019 20:07:36 +0800

For FreeBSD, that alternate stack is in production (public internet) use
by at least one operator, and other operators are looking into making
RACK their default.

Also, on FBSD any improvements on the base (NewReno) stack need to be
reflected in RACK, e.g. when new functionality is implemented.

RACK is certainly a serious affair :)

Richard

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 19 Nov 2019 13:52:43 +0000

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 <[email-masked]> 
Sent: Tuesday, November 19, 2019 6:52 PM
To: [email-masked]
Cc: Neal Cardwell <[email-masked]>; [email-masked]; Praveen Balasubramanian <[email-masked]>; Ingemar Johansson S <[email-masked]>
Subject: Re: Intended status of draft-ietf-tcpm-rack 

Hi

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 20 Nov 2019 11:26:07 +0800

> On Nov 19, 2019, at 7:06 PM, Jonathan Morton <[email-masked]> wrote:
> 

We do not have an implementation of RACK in our TCP stack.

Regardless of that, I support PS as the intended status for RACK.

Christoph

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 20 Nov 2019 07:24:26 +0000

Thanks all for the response, it is indeed useful information

/Ingemar

> From: [email-masked] <[email-masked]> On Behalf Of Christoph
> Paasch
> Sent: den 20 november 2019 04:26
> To: Jonathan Morton <[email-masked]>
> Cc: Ingemar Johansson S <[email-masked]>; Ingemar
> Johansson S <[email-masked]>; [email-masked]
> >> On 19 Nov, 2019, at 6:51 pm, Ingemar Johansson S
> <ingemar.s.johansson=[email-masked]> wrote:
> >>
> >> 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.
> >>
> >> 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 ??
> >
> > Android is Linux, to a first approximation, and thus inherits its
networking
> capabilities.
> >
> > FreeBSD I understand has a RACK-capable TCP stack, but which is not the
> default.  I think Rod Grimes should be able to clarify this, and he's also
on this
> list.