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

Hi Magnus,

thanks for the feedback! I wasn’t aware of issue 1 and missed the issues in 2. Can we assign you as the official tsv-art reviewer and you send the review directly to the respective mailing list(s)?

Regarding issue 1, I think that good to raise now but might rather be a discuss point on the other doc later evtl.

On issue 2, Spencer, can you maybe file a discuss on this given I have put in my ballot already; otherwise I can also change my ballot...

Mirja

> Am 03.07.2017 um 16:08 schrieb Magnus Westerlund <magnus.westerlund@ericsson.com>:
> 
> 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  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art