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

["Rodney W. Grimes" <[e-mail]>]

> On 03/11/2019, 13:08, Jonathan Morton wrote:
> >> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<[e-mail]>  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.

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                                                 [e-mail]