In looking back at this email, I realize that all I did about [1] was criticize.
Here’s a concrete suggestion for what to do:
TRILL Priority DEI DSCP Field (Binary/decimal)
-------------- --- -----------------------------
0 0/1 000000 / 0
1 0/1 --TBD- / TBD
[... snip ...]
RFC Editor: Please change the TBD DSCP for TRILL Priority 1 in the above
table to the DSCP value that is recommended for the Lower Effort PHB
(LE PHB) by draft-ietf-tsvwg-le-phb [LEphb] draft when that draft is
published as an RFC.
Anticipating a question about why the normative reference to the le-phb draft
does not suffice –
the above text makes it clear to implementers that there is no DSCP that is
(yet) appropriate to
use for TRILL Priority 1.
Thanks, --David
From: Black, David
Sent: Friday, February 2, 2018 12:21 PM
To: Magnus Westerlund <magnus.westerl...@ericsson.com>; Donald Eastlake
<d3e...@gmail.com>
Cc: tsv-...@ietf.org; draft-ietf-trill-over-ip....@ietf.org; trill@ietf.org;
Black, David <david.bl...@emc.com>
Subject: RE: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10
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.
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.
> "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.
Thanks, --David
From: Tsv-art [mailto:tsv-art-boun...@ietf.org] On Behalf Of Magnus Westerlund
Sent: Friday, February 2, 2018 4:29 AM
To: Donald Eastlake <d3e...@gmail.com<mailto:d3e...@gmail.com>>
Cc: tsv-...@ietf.org<mailto:tsv-...@ietf.org>;
draft-ietf-trill-over-ip....@ietf.org<mailto:draft-ietf-trill-over-ip....@ietf.org>;
trill@ietf.org<mailto:trill@ietf.org>
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10
Hi Donald,
I have reviewed the changes and my comments. Please see inline for my feedback.
I will remove text not necessary to provide context. It is almost ready now.
There are two areas where I think there needs to be some further improvements,
DSCPs and TCP encapsulation. But the needed changes are relatively
straightforward.
Den 2018-01-31 kl. 06:25, skrev Donald Eastlake:
Hi Magnus,
It has been a while but the just posted version -12 is intended to
resolve your comments except those related to middle boxes. (The TRILL
WG has decided middle boxes will be out of scope for this draft.)
On Thu, Jun 29, 2017 at 10:17 PM, Donald Eastlake
<d3e...@gmail.com><mailto:d3e...@gmail.com> wrote:
On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund
<magnus.westerl...@ericsson.com><mailto:magnus.westerl...@ericsson.com> wrote:
Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
<magnus.westerl...@ericsson.com><mailto:magnus.westerl...@ericsson.com> wrote:
Diffserv usage
--------------
Section 4.3:
The new text from -12:
The default TRILL priority and DEI to DSCP mapping, which may be
configured per TRILL over IP port, is an follows. Note that the DEI
value does not affect the default mapping and, to provide a
potentially lower priority service than the default priority 0,
priority 1 is considered lower priority than 0. So the priority
sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7, as
it is in [802.1Q].
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 above all follow the recommended DSCP values from [RFC2474]
except for the placing of priority 1 below priority 0, as specified
in [802.1Q], and for the DSCP value of 000010 binary for low effort
as recommended in [LEphb].
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.
MTU and Fragmentation
---------------------
With the changes introduced and the no middlebox applicability it looks like
the issues are resolved.
Zero Checksum:
--------------
The IPv6 zero checksum section (5.4.2) looks good.
TCP Encapsulation issue
-----------------------
So the TCP encapsulation section (5.6) is significantly improved, but some
comments:
"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.
"It is RECOMMEDED that
at least two TCP connections be provided, for example one for
priority 6 and 7 traffic and one for priority 0 through 5 taffice, in
order to insure that urgent control traffic, including control
traffic related to establishing and maintaining adjacency, is not
significantly delayed by lower priority traffic."
I think this is fine, there is one potential issue here, but likely not a
significant. If the high priority traffic is very sparse, then the TCP
connection marked with a higher priority DSCP may have a very small congestion
window. So when the high priority traffic is to be sent it will in fact be
delayed more by the TCP stacks congestion control than the lower priority that
has a larger window established. However, that is only really an issue if the
high priority traffic is multiple packets that comes in burst. Also, if there
is on path contention the lower priority traffic may still not make it even if
sent earlier, so not using a high priority DSCP is not really an option either.
I think the IP/TCP/Trill and TCP header figures are simply non-relevant here. I
think they can give the impression that a receiving node can process each TCP
packet individually rather than running a full TCP implementation here. What is
relevant is the framing format that delimit each Trill packet sent by TCP.
+--------+-------- // ----+ | Length | TRILL packet |
+--------+----- // -------+
The above figure is a bit confusing, I assume the intention is to indicate
previous Trill packet with framing and the following one. I think you be more
explicit about that as an explanation.
If the
initial 2 bytes of the TRILL packet are not one of these
Ethertypes, then the receiver assumes that framing
synchronization has been lost and MUST close that TCP
connection.
Yes, this is very important text. I would recommend that it is moved into its
own paragraph rather than hidden in a figure explanation. I am also missing the
specification what to do when one have closed the connection. I assume that it
is to have either part re-initiate. But, is it the closing party (receiver)
that should do this, or the sending part? As TCP connections are
bi-directional, but I assume that these are used only unidirectionally, and
thus it matters who should establish them in relation to signalling? Congestion
Control
Flow and ECMP
-------------
Issues resolved in the more limited applicability scope.
NAT and TRILL over IP:
I think it is fine with the WG saying that NATs are out of scope for Trill.
However, I really think you need to say this upfront in the document that this
specification relies on that there are no NAT in the path between the trill
nodes using this specification. And be explicit if there would be NATs then
things will not work as intended.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Torshamnsgatan 23 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto:
magnus.westerl...@ericsson.com<mailto:magnus.westerl...@ericsson.com>
----------------------------------------------------------------------
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
