Re: [tcpm] AccECN semantics

[Brian Trammell <[e-mail]>]

Hi Richard, all,

On 16 Mar 2014, at 12:17, Scheffenegger, Richard <[e-mail]> wrote:

> 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.

Very cool. Backing all this up with information about reality in the network is essential. :)

FWIW, though the draft expired last week, we do intend to develop it further. I have a student project that started last week to revisit the proportion of usable and unusable endpoints among popular servers (the 2013 PAM paper), as well as to catalog ECN failure modes, and to determine the likelihood of mid-flow transition from ECN-usable to ECN-unusable as discussed in Vancouver. We intend to update the draft backed up by data produced by this work.

> 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...

It does point (non-normatively) in the direction of "future research":

                                      ... [m]echanisms for responding to
   congestion on the ACK-path are areas for current and future research.
   (One simple possibility would be for the sender to reduce its
   congestion window when it receives a pure ACK packet with the CE
   codepoint set).

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

Interesting to see the stack didn't take the hint there. :) "suppresses and conceals" means no ECE, no reduction, and no information to the application layer?

> 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).

Given how many flows we observed on the open Internet that were clearly misusing the ECT bits, the receiver should probably always assume that the sender is broken.

> 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?

Well, "mechanisms for responding to congestion on the ACK-path are areas for ... future research" so maybe splitting that work out into another draft might scope the work a bit better. AccECN seems more complete than any of this at the moment...

Cheers,

Brian