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

[Magnus Westerlund <[e-mail]>]

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]>  wrote:
>> On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund
>> <[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]>  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]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto:[e-mail]
----------------------------------------------------------------------