[tcpm] AccECN semantics

["Scheffenegger, Richard" <[e-mail]>]

Hi Mirja, Brian, group,


I'm currently testing, trying to follow what Mirja and you have described here:

http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback-01

but extending it a bit into the ambiguous region against a ECN receiver.

RFC3168 stipulates that pure control packets MUST NOT have ECT (thus no CE) (section 6.1.4), but doesn't explicitly specify the receiver reaction, if a control packet is nevertheless received with CE...

With one ECN TCP stack I happened to have under test, the receiver actually suppresses and conceals the CE information. 

IMHO, the receiver should not make assumptions or remove information (a path still using TOS rather than DiffServ might be the cause - but it's up to the sender to detect that misbehavior).

I think the requirement given in 3168 about control packets MUST NOT carry ECT is sound, it probably would have been better a SHOULD NOT; but IMHO, the receiver MUST reflect the ECT/CE once the session has negotiated ECN support - to allow future extensions without having to modify the receiver again.

However, this might make the accounting more complex, as CE marks on pure ACKs, while no data is being sent, don't necessarily have to invoke a CC reaction (other than ACK-CC) immediately.

Perhaps that should go into either AccEcn requirements, or one of the AccECN mechanism drafts?


Any thoughts?

Richard Scheffenegger