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

[Joe Touch <[e-mail]>]

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