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

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:trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/