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

[Donald Eastlake <[e-mail]>]

Hi Magnus,

Could you look at the -13 version which is intended to resolve your
remaining unresolved comments?

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

On Fri, Feb 2, 2018 at 4:29 AM, Magnus Westerlund <
[e-mail]> wrote:

> 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 <[e-mail]> <[e-mail]> wrote:
>
> On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund<[e-mail]> <[e-mail]> wrote:
>
> Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
>
> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund<[e-mail]> <[e-mail]> 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  [phone] <+46%2010%20714%2082%2087>Torshamnsgatan 23 <https://maps.google.com/?q=Torshamnsgatan+23&entry=gmail&source=g>           | Mobile [phone] <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>