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

On Mon, Nov 4, 2019 at 8:59 PM Rodney W. Grimes <4bone@gndrsh.dnsmgr.net> wrote:
>
> > On 03/11/2019, 13:08, Jonathan Morton wrote:
> > >> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<gorry@erg.abdn.ac.uk>  wrote:
> > >>
> > >>> 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 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
> > 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.
>
> 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.

I agree with Rod here.
>
> 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.
>
> > Gorry
> --
> Rod Grimes                                                 rgrimes@freebsd.org
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm