Jesse, Ilango,
Just checked
https://tools.ietf.org/html/draft-ietf-nvo3-geneve-01#section-4.1.2
It currently says:
[RFC6040] describes the mechanism for exposing ECN capabilities on IP
tunnels and propagating congestion markers to the inner packets.
This behavior SHOULD be followed for IP packets encapsulated in
Geneve.
I'm afraid this has to be a MUST. Otherwise, if you don't follow
RFC6040, what do you implement instead?
The whole point of RFC6040 was to specify one single consistent
behaviour for all types of tunnel endpoints, with zero options, zero
config, zero management (unlike Diffserv).
So this statement a little earlier is also a bit wrong:
there are several options for propagating DSCP and ECN bits
ECN is now becoming popular in private DCs to keep buffer occupancy v
shallow (e.g. with DCTCP).
If a decapsulator doesn't propagate congestion notification at all, it
black-holes it. Admittedly you have loss to fall back on... eventually.
However, while ECN is black-holed sources carry on increasing their
rate, until they overflow the buffer. Particularly with pooled memory
for buffering that can introduce a huge amount of delay before
black-holed ECN turns into loss. Even if ECN isn't being used at the
moment, it must be implemented in case it starts to be used.
Cheers
Bob
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
