Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13)

[Ing-Jyh Tsang <[e-mail]>]

Bob, all.

I definitely support the work done here. ECN and L4S support in TRILL 
addresses cross layer "control intelligence" benefiting network 
optimization.


On 11/06/2017 22:43, Bob Briscoe wrote:
> Koen,
>
> On 09/06/17 17:33, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
>> Hi all,
>>
>> I reviewed this draft (for the first time) mainly from the point of view of L4S support. I greatly appreciate the forward vision of supporting upcoming ECN functionality, and the flexibility/extensibility of the thrill headers.
>>
>> Answering question 1: Definitely, L4S ECN marking can drastically improve latency and flow control.
>>
>> Following comments related to question 2:
>>
>> I think there is one opportunity not exploited in how L4S ECN is handled: If an ingress node is not supporting ECN, a transit node is allowed to add the Flags word and mark packets with CCE. In case of L4S this case is not covered, and cannot be applied, as NCCE code points are translated by egress nodes as CE or drop if the inner packet is Not-ECT.
> There is a problem in this case, but I don't think you have described 
> it well (I think you have described why your solution would not work 
> with the spec as it stands, rather than describing what is wrong with 
> the spec as it stands).
>
> Here's how I would have described the problem:
> The technique in Appendix A for a transit RBridge to support L4S-ECN 
> takes different actions depending on the last bit of the trill-ECN 
> field, which in turn depends on the trill ingress RBridge having 
> copied the IP-ECN field into the trill-ECN field. However, in a case 
> where the ingress hasn't, the spec says "a transit RBridge "MAY" add a 
> Flags Word itself. But, it would be a layering violation to expect the 
> transit RBridge to look for the IP-ECN field and copy it into the 
> trill-ECN field.
>
> The approach in the spec works for standard ECN [RFC3168], i.e. if a 
> transit RBridge creates a flags Word it just initializes the trill-ECN 
> field to not-ECT. But you're right, this doesn't work for L4S.
>
> I'm not sure how important this is, because no vendor is likely to 
> implement creation of a Flags word by a transit RBridge anyway (which 
> is why the spec says "MAY").
>
>> I think the solution could be to extent the "Arriving TRILL 3-bit codepoint name" table with an extra NCCE name mapping from TRILL-ECN=11 and CCE=0. Table 2 needs to have an extra column with rows (not-ECT, ECT(0), CE, CE). This way an L4S transit node can also insert a Flags word and set NCCE with probability p on top of CCE with p^2. I saw no other combinations that could lead to this arriving situation, and could lead to problems, as current ECN capable transit nodes never mark NCCE.
> I have checked and this works in all cases.
>
> Even if there is a Flags word, this is better for L4S, because L4S 
> transit RBridges would not need to read the trill-ECN field before 
> marking. So the pseudocode in Appendix A would be simpler, i.e. just:
>
>        % On TRILL transit
>        if (p > random() ) {
>           mark(NCCE)                     % likelihood: p
>           if (p > random() )
>              mark(CCE)                   % likelihood: p^2
>        }
>
> There is a downside tho: your proposal adds an extra case for the 
> behaviour of all trill egress RBridges.
>
> In summary, the tradeoffs with your proposal are:
> * More complex standards track behaviour for all egress RBridges.
> * Simpler for transit RBridges to support L4S (which is experimental 
> track)
> * Makes it possible for transit RBridges that support L4S to add a 
> Flags Word (but unlikely that vendors will do this anyway)
>
> Another way to solve this problem would be to just say that an L4S 
> transit RBridge:
> * MAY create a Flags word, but only if it is willing and able to 
> inspect the inner IP header and copy the IP-ECN field to the trill-ECN 
> field.
> * Otherwise it has to use Classic drop for packets without a Flags Word.
>
> One thing your email made me notice: as it stands, the pseudocode in 
> Appendix A ought to include an outer 'if' block that checks for the 
> Flags Word. But let's see what comments there are on the list before 
> deciding between the alternatives, then we can write the appropriate 
> pseudocode.
>
>> A typo in section 2: Extesnion should be Extension.
> Thanks for this. While re-reading the draft, I also noticed a few 
> editorial improvements, which I will raise with my co-author.
>
> And thanks particularly for pointing out the alternative way of 
> defining the egress behaviour.
>
> Cheers
>
>
>
> Bob
>> Regards,
>> Koen.
>>
>>
>>> On 31/05/17 19:48, Susan Hares wrote:
>>> This begins a  2 week WG LC for draft-ietf-trill-ecn-support which can be
>>> found at:
>>> https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/.
>>>
>>>
>>> The authors (Donald Eastlake and Bob Biscoe) should indicate whether they
>>> know of any IPR relating to this draft.
>>>
>>> The TRILL WG should consider the following questions:
>>>
>>> 1) Does this extension of the ECN to TRILL Switches provide for better
>>> Flow control of IP packets without packet drops?  And is this useful in TRILL
>>> deployments?
>>>
>>> 2) Do you believe this document is ready for RFC publication?
>>>
>>> Please include the answers to these questions among your comments about
>>> this draft.
>>>
>>> Sue Hares
>>>
>>>
>>>
>>> _______________________________________________
>>> trill mailing list
>>> mailto:[e-mail]
>>> https://www.ietf.org/mailman/listinfo/trill
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill