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

[Donald Eastlake <[e-mail]>]

Hi David,

On Fri, Feb 2, 2018 at 12:20 PM, Black, David <[e-mail]> wrote:
>
> A couple of Diffserv-related follow-ups to Magnus’s comments:
>
> [1]
>
> > I don't really understand this change. Now you have priority 1
> > which points to the proposed new mapping for Lower than Best
> > Effort, being the least prioritized. Then priority 0 intended to
> > be more prioritized is CS1 which may still be lower than best
> > effort (thus basically same as prio 1), or end up being receiving
> > a more prioritized PHB than best effort.  Why isn't 0 mapped to
> > best effort (000000)? That appears that it would provide a more
> > consistent behaviour.
>
> +1 – zero should be best effort in all contexts.   Moreover, the
>      table has additional problems:
>
>
>       TRILL Priority  DEI  DSCP Field (Binary/decimal)
>       --------------  ---  -----------------------------
>                   0   0/1  001000 / 8
>                   1   0/1  000010 / 0
>                   2   0/1  010000 / 16
>                   3   0/1  011000 / 24
>                   4   0/1  100000 / 32
>                   5   0/1  101000 / 40
>                   6   0/1  110000 / 48
>                   7   0/1  111000 / 56
>
>
> The entry for priority 1 is inconsistent – 000010 Binary is *not* 0 decimal.

Yes, the decimal version was not updated when it should have been.

> If 000010 was an attempt to anticipate a possible TSVWG assignment
> of DSCP 000010 / 2 as the default DSCP for less than best effort
> traffic, this serves as a practical lesson in why that sort of
> attempt to predict the future is not appropriate for a standard.
> While that DSCP was suggested in some earlier TSVWG drafts, better
> understanding of some unfortunate “running code” in the Internet
> that zeros only the most significant 3 bits in the DSCP has led to
> TSVWG’s current direction (as of the Singapore meeting week) to open
> up the pool of DSCPs that end in 01 (xxxx01) for standards usage in
> order to assign either DSCP 1 (000001) or DSCP 5 (000101) as the
> default DSCP for less than best effort service.

Thanks very much for your subsequent message suggesting specific
wording a copy of which is here:
https://www.ietf.org/mail-archive/web/trill/current/msg08112.html

Your suggested wording looks reasonable to me.

> > "All packets in a particular TCP stream SHOULD use the same DSCP
> > codepoint or packet re-ordering may occur."  > I think that SHOULD
> > > is a MUST. You get no benefit from trying to send different
> > packets > in a TCP connection with different DSCPs.  > It will
> > really only > result in reordering, and additional
> > retransmissions. Also the TCP > stacks Head of line blocking will
> > also not really > allow any > received payload to be released
> > early. Thus, only downsides and now > gain to use different DSCPs
> > for a single connection.
>
> +1, and see RFC 7657 for further discussion, including this text on
> why having a single TCP connection use DSCPs that vary only in drop
> precedence (i.e., aren’t supposed to cause reordering) is pointless:
>
>
>    There are situations in which drop precedences should not be
>    mixed.  A simple example is that there is little value in mixing
>    drop precedences within a TCP connection, because TCP's ordered
>    delivery behavior results in any drop requiring the receiver to
>    wait for the dropped packet to be retransmitted.
>
>
> There are no “MUST” keywords in RFC 7657 because that RFC is
> informational design guidance, but its guidance justifies the “MUST”
> that Magnus suggests.  I would also suggest citing RFC 7657 as an
> informative reference.

Seems reasonable.

> Thanks, --David

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]