Re: [tcpm] draft-kuehlewind-tcpm-ecn-fallback-01.txt

[Brian Trammell <[e-mail]>]

hi John,

Many thanks for the comments, a good bit to think about here. Inline:

On 1 Oct 2013, at 17:05 , John Leslie <[e-mail]> wrote:

>   I very much support this sort of work; but I think any RFC will have
> to rely more on stated principles than an algorithm.

Hm. Interesting approach, you may well be right. In this case it probably makes sense to elucidate the general approach more clearly, discuss the parameter space alluded to in the discussion notes, and present the algorithm as an example.

>   This algorithm will fail badly if the actual path changes often
> enough between ECN-friendly and ECN-unfriendly.

This is a very good point, which we're admittedly kind of ignoring at the moment, as we think that it will fail at worst as badly as if one enables ECN in such an environment without fallback.

The higher the proportion of unfriendly paths, the higher the probability this becomes an issue; the other question is where on the path does the unfriendliness occur, and how often are those path components variable. IIRC there are some numbers in the Bauer paper we cite in our PAM work that may shed some light on this last question, but I'll need to read it again.

>   Also note that we already know of several flavors of ECN-unfriendly.

We've tried to tune the algorithm such that we react only to ECN-unfriendliness that causes connectivity problems; this would be a point to make in the description general approach.

On thinking about it, there's one whole class of ECN unfriendliness that we don't talk about, and should: connectivity failure on attempts to negotiate.

>   IMHO, we need to start using ECN early in the absence of indications
> of an ECN-unfriendly path; and back off quickly in the presence of
> such indications.
> 
>   There may (or may not) be other indications of path changes, which
> we could use to be more fearful...

Here there's a balance to be struck between reactivity and runtime complexity, but I get your point...

>   But fundamentally, clearing ECN bits just puts us into packet-drop
> as the only signal, while dropping ECN-aware packets may or may not
> indicate any congestion. When a significant fraction of ECN-aware
> packets get dropped, it's clearly time to stop ECN-marking.

Yep.

Thanks, cheers,

Brian

>   Et cetera...
> 
> --
> John Leslie <[e-mail]>