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

From: John Leslie <[email-masked]>
Date: Tue, 1 Oct 2013 11:05:10 -0400

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

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

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

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

   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.

   Et cetera...

--
John Leslie <[email-masked]>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 10 Oct 2013 11:46:01 +0200

hi John,

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

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

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

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

> packets get dropped, it's clearly time to stop ECN-marking.

Yep.

Thanks, cheers,

Brian