Hi David, On Fri, Feb 2, 2018 at 12:20 PM, Black, David <david.bl...@dell.com> wrote: > > A couple of Diffserv-related follow-ups to Magnus’s comments: > >  > > > 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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ trill mailing list firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/trill