Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

From: "Rodney W. Grimes" <[email-masked]>
Date: Sat, 2 Nov 2019 16:26:18 -0700 (PDT)

Rod Grimes                                                 [email-masked]
Alex,
With respect to draft-ietf-tcpm-accurate-ecn and
draft-grimes-tcpm-tcpsce compatibility:
  When accurate ecn (AccECN) fails to negotiate an AccECN capable session
  it falls back to RFC3168 conformance, leaving a state that is fully
  compatible with SCE, hence they are compatible.

  I am currently working on a revision to draft-grimes-tcpm-tcpsce and
  hopefully can cover this "compatible" situation in the draft itself.

With respect to "There are no IANA considerations":
  You are correct, reworking that in several respects, hope to remove
  references to the NS bit for most parts and simply state that this
  draft for "IANA considerations" is requesting a bit, with the former
  NS bit prefered.

Regards,
Rod

>  Rod, Jonathan,
> ?I could be wrong, but it appears to me that this draft does not merely not make use of draft-ietf-tcpm-accurate-ecn,it's incompatible with it. Is this the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft also asserts that there are other uses for accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could state your position on those other uses, for the record. 
> 
> Also, presumably it is incorrect that "There are no IANA considerations", since IANA would need to change the NS bit.
> 
> Regards,
> Alex
> 
> Rodney W. Grimes" <[email-masked]> wrote:
> > > Rod,
> > > 
> > > This draft appears to be focused on obtaining a TCP header bit for SCE.
> > 
> > Yes, that is correct.
> > 
> > > As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. 
> > 
> > I specifically did not do what Accurate Ecn attempts as that requires
> > a TCP option negotiation at connection establishment to negotiate the
> > overloading of other TCP header bits.? SCE only needs 1 new bit, and
> > does not alter the behavior of any current bits.
> > 
> > This proposal (TCPSCE) does not in any way effect the current use of
> > any of the other bits, and use of the NS bit should be fully backwards
> > compatible and ignored by pre SCE implementations and does not require
> > a TCP option negotiation.
> > 
> > I have to get additional data but have been lead to understand that
> > adding a tcp option and doing that negotiation is going to cause a
> > great deal of pain in the ability to deploy accurate ecn as it is
> > currently designed due to middle box inspection and handling.
> > 
> > Regards,
> > Rod
> > 
> > > Thanks, --David
> > > 
> 
> 
> 
> 

-- 
Rod Grimes                                                 [email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 03 Nov 2019 09:46:11 +0000

See in-line.

>    compatible with SCE, hence they are compatible.
I was expecting this to fall-back to RFC8511, treatment at the 
endpointrs, since that is the most recent spec. Does that make any 
difference to your thoughts abiout what you expect an endpoint to do 
when it receives ECN-marking without Accurate ECN?

Gorry
>> Rodney W. Grimes"<[email-masked]>  wrote:
>>>> Rod,
>>>>

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 3 Nov 2019 15:08:54 +0200

> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst <[email-masked]> wrote:
> 

> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN?

RFC-8511 doesn't change the signalling on the wire relative to RFC-3168.  That was the sense intended here.

 - Jonathan Morton

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Nov 2019 08:19:50 +0000

On 03/11/2019, 13:08, Jonathan Morton wrote:
>> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<[email-masked]>  wrote:
>>
RFC3168 describes both endpoint behaviour and network functions. To me, 
this sentence is about
how you receive indications of incipent congestion, the sender can 
change from using only CE to using CE plus
the accurate information -or fall back to using just CE - ultimately it 
falls back to just detecting congestion (loss,delay).
So yes, the CE signal could be regarded as input to SCE.

The endpoint behaviour, I think, should fall back to RFC8511.

Gorry

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 4 Nov 2019 10:11:48 +0100

> On Nov 4, 2019, at 09:19, Gorry Fairhurst <[email-masked]> wrote:
> 
> RFC3168 describes both endpoint behaviour and network functions. To me, this sentence is about
> how you receive indications of incipent congestion, the sender can change from using only CE to using CE plus
> the accurate information -or fall back to using just CE - ultimately it falls back to just detecting congestion (loss,delay).

Question: Since the ABE RFC is marked experimental while RFC3168 is a proposed standard, why should tcpsce fall-back to RFC8511 instead of RFC3168? 
I ask as in the discussion of L4S it was (IMHO rightfully) argued that including a requirement on another experimental RFC (RACK in that case) was problematic as it would link basically independent experiments (and introduce undesired fate-sharing).

Sebastian

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Nov 2019 09:41:25 +0000

On 04/11/2019, 09:11, Sebastian Moeller wrote:
>
>> On Nov 4, 2019, at 09:19, Gorry Fairhurst<[email-masked]>  wrote:
>>
Because, that is why the WG publishes EXP RFCs.

My own understanding, is that to publish a PS update to TCP, it is good 
to have deployment experience.
To get there, you need to alreday have completed detailed experiments in 
labs, etc, and show safety
there and then have a proposal that has been accepted by the WG and 
developed into an RFC
- The EXP RFC. Next comes the deployment, and decision about what to do 
next - many TCP RFC's remain EXP.

In this case, the purpose of the RFC8511 experiment is to "collect experience with the deployment of ABE
and confirm acceptable safety in deployed networks that use this update to TCP congestion control"
and then to "propose it as a Standards-Track document in the future".  (Section 6).

> I ask as in the discussion of L4S it was (IMHO rightfully) argued that including a requirement on another experimental RFC (RACK in that case) was problematic as it would link basically independent…
That can indeed be an issue, if a new proposal comes along that depends 
on one of the existing experiments. That needs careful thought.
Gorry

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Nov 2019 10:11:25 +0000

> to have deployment experience.

In this context, it makes sense to read the exact wording of RFC 7127:

   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.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.

In general, there is no strict formal requirement for implementation or operational experience for a PS. But TCP is a core Internet protocol, i.e., the third quoted paragraph may apply. The TCPM working group has in several cases concluded that running an experiment first would be reasonable.

In some of these cases, there is now implementation and operational experience. In those cases, doing the PS is mostly a matter of WG energy...

Michael

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Mon, 4 Nov 2019 08:58:38 -0800 (PST)

> The endpoint behaviour, I think, should fall back to RFC8511.

The response to CE of an SCE capable end-point is unaltered by
the fact that SCE is in use.  If RFC8511 is enabled on the
end node the response shall be that of the ABE parameters, if
RC8511 is not enabled then the response should be that of RFC3168.

IE, the 2 experiments co-exist without any special considerations,
and SCE plays nicely with either response to CE.

Explicitly stating in this draft that behavior should fall-back
to RFC8511 would complicate implementation details as then an
implementor may be required to implement RFC8511 if it did not
exist, and also to some how "know" that a connection was SCE
capable, somethng a sender is unaware of until the first ESCE
mark is recieved, and something that can change as paths over
the internet change during the life of the connection.

Further more stating RFC8511 as a fallback position would more
or less mandate that RFC8511 be used if SCE is used, something
that may not be desireable.

In summary.  tcpsce does not alter CE generation, feedback or
response, leaving all existing RFC's intact as they are written
with respect to the CE and ECE bits.  Tcpsce does not alter the
response to loss either.  This is by design.

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 5 Nov 2019 08:41:15 +0400

> that may not be desireable.

I agree with Rod here.
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Black, David" <[email-masked]>
Date: Tue, 5 Nov 2019 05:29:28 +0000

This appears to be a tempest in a teapot, as I see the following text in Section 5 (TCP Sender) of the -01 version of this draft:

   There are no changes to the response functions with respect to CE or
   packet loss specificed by this draft, hence [RFC3168] and [RFC8511]
   are still applicable

The neutral "still applicable" language nicely sidesteps the Experimental status of RFC 8511 - in particular, if RFC 8511 is replaced by a standards-track RFC in the future, the above language has the desired effect, whereas language that explicitly referred to the Experimental status of RFC 8511 could be problematic in that scenario.

Thanks, --David (as an individual, not as a TSVWG chair)

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Loganaden Velvindron
> Sent: Monday, November 4, 2019 11:41 PM
> To: Rodney W. Grimes
> Cc: [email-masked]; Rodney W. Grimes; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-
> tcpsce-00.txt
> 
> 
> [EXTERNAL EMAIL]
> 
> > > >> I was expecting this to fall-back to RFC8511, treatment at the endpointrs,
> since that is the most recent spec. Does that make any difference to your
> thoughts abiout what you expect an endpoint to do when it receives ECN-
> marking without Accurate ECN?