Bob, Thanks for reviewing the draft and your comments. I agree with what you said and have changed the SHOULD to MUST and also the statement about there being “several options” for DSCP and ECN to “several considerations”. I just uploaded a new version of the draft (great timing by the way as I was in the process of updating it today) that reflects this.
Jesse On 7/8/16, 9:02 AM, "Bob Briscoe" <[email protected]<mailto:[email protected]>> wrote: 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
