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:[email protected]
https://www.ietf.org/mailman/listinfo/trill
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
_______________________________________________
trill mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trill
