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

[Wesley Eddy <[e-mail]>]

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.


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