Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations

["Black, David" <[e-mail]>]

> -----Original Message-----
> From: Tsv-art [mailto:[e-mail]] On Behalf Of Wesley Eddy
> Sent: Thursday, July 13, 2017 9:41 AM
> To: Joe Touch <[e-mail]>; [e-mail]
> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN &
> DSCP considerations
> 
> I agree on all points, and with the absurdity of trying to change DSCP
> on a TCP connection per encapsulated packet.  If the DSCP values used
> for a TCP connection change over time, it should be "coarse grained"
> (e.g. with say hundreds or thousands of segments in between changes) and
> not anywhere near per-segment.
> 
> But while obvious to us, I don't think this is in any RFC to be quoted.

[David>] RFC 7657 - this is discussed in sections 5.1 & 5.3 and summarized as a bullet point in section 6.

> 
> 
> On 7/13/2017 8:59 AM, Joe Touch wrote:
> > Two additional points that are very important for this doc:
> >
> > 1) RFC1122 admits there might not even be an API to make such a change
> > after a connection has been established, so trill-over-IP cannot rely on
> > it and must explain what to do if that API is not supported.
> >
> > 2) RFC1122 mentions this as an API issue - there is NO way that TCP can
> > know which trill packets will end up in a given TCP segment from the
> > existing TCP API, thus it would never be clear how or when to make such
> > a TOS/DSCP change unless it was persistent and relatively stable (again,
> > that's the intent AFAICT from the RFC1122 text).
> >
> > Using TCP is *never* merely a matter of "throw on a TCP header".
> >
> > Joe
> >
> >
> > On 7/13/2017 5:41 AM, Joe Touch wrote:
> >> Hi, Wes (et al.),
> >>
> >>
> >> On 7/12/2017 12:31 PM, Wesley Eddy wrote:
> >>> On 7/1/2017 2:03 PM, Donald Eastlake wrote:
> >>>> On Sat, Jul 1, 2017 at 10:53 AM, Black, David <[e-mail]>
> >>>> wrote:
> >>>>> Also, as noted earlier in this discussion, RFC 7657 explicitly
> >>>>> discourages use of multiple DSCPs in a single TCP connection.  That
> >>>>> needs to be reflected in the TCP encapsulation text in the
> >>>>> trill-over-ip draft - in particular, the current text in Section 4.3
> >>>>> on mapping to DSCPs from TRILL priority and DEI does not appear to
> >>>>> be consistent with RFC 7657 for TCP-based encapsulation.
> >>>> I'm surprised it only "discourages" rather than "prohibits"...
> >>>>
> >>>>
> >>> RFC 1122 section 4.2.4.2 might be of interest.
> >>>
> >>> It says that TOS "SHOULD" be able to change during TCP connection
> >>> lifetime.  The example given there is an SMTP connection whose nature
> >>> might change during its lifetime.
> >>>
> >>> I'm not saying whether or not this is really still a sensible concern,
> >>> just pointing it out.
> >>>
> >>> The change from TOS to DSCP terminology and semantics didn't make any
> >>> change here as far as I can tell.
> >> Agreed, but only on that point.
> >>
> >> My interpretation of the relevant RFC1122 text is that it's OK for a TCP
> >> session to "shift" from one TOS (or DSCP) to another when the nature of
> >> its transfer changes. I would expect those changes to be infrequent and
> >> atypical.
> >>
> >> I would not expect a single TCP connection to issue individual segments
> >> with TOS (or DSCP) values that change nearly every segment, which would
> >> be the consequence of copying those values from the payload of
> >> encapsulated traffic. Furthermore, it would be impossible to determine
> >> the appropriate DSCP values when a segment contains all or part of more
> >> than one encapsulated packet with different values.
> >>
> >> Joe
> >>
> >> _______________________________________________
> >> Tsv-art mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tsv-art
> 
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art