Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06

[Magnus Westerlund <[e-mail]>]

Den 2017-06-30 kl. 12:47, skrev Martin Stiemerling:
> Hi,
>
> I wonder who could and would volunteer to do the tsv-art review for
> draft-ietf-trill-mtu-negotiation-06 ?
>

Hi,

I am not doing a full review, but something for the ADs and the reviewer 
to consider is the issues that I have found with the relation between 
draft-ietf-trill-over-ip-10 and this document.

1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for 
determining if the UDP encapsulation will work or not. It references  in 
Section 8.4 the old RFC, i.e. RFC 6325, which is updated by 
draft-ietf-trill-mtu-negotiation.

    TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in
    [RFC7177], can be used to obtain added assurance of the MTU of a
    link.

However, this is not quite true, as if the IP path MTU is below 1470 
bytes, which is not unheard of, the algorithm in the MTU negotiation 
draft can't determine it. It will only report the IP path as having an 
MTU to small when the 1470 bytes probe fail.

So, if the Trill authors want to use this as a mechanism, then the MTU 
negotiation draft needs to be expanded to have more flexible lower 
boundaries. However, that appear to affect MTU negotiation quite 
significant as it needs to seperate algorithm for finding MTU, from the 
different usage of the algorithm with different starting points. Where 
the normal will have a lower bound of 1470, and be more tightly coupled 
to Sz when finding Lz. While the Trill-over-IP has a different usage.

This can also result in the need to discuss if binary searching is good 
enough?


2. Another issue, is that I think the algorithm is a bit short on 
transmission scheduling recommendations:

    1) If RB1 successfully receives the MTU-ack from RB2 to the probe of
       the value of link-wide Lz within k tries (where k is a
       configurable parameter whose default is 3), link MTU size is set
       to the size of link-wide Lz and stop.

If I do this test with all three packets back to back at line rate, I could
potentially get all probes lost in the same burst loss in router queue or switch fabric.

3. This is also unclear on what the criteria is for determining that something is lost:

      a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1
          sets the "failed minimum MTU test" flag for RB2 in RB1's Hello
          and stop.

No discussion of X*RTT, or timeout values that one uses to determine 
when a probe is lost.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------