Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.txt

[Brian Trammell <[e-mail]>]

hi Michael,

inline below...

On 29 Jul 2013, at 14:14, Michael Welzl <[e-mail]> wrote:

<snip>

>>> - step 6: "In this case, the sender may continue using ECN, because while it may not work for detecting congestion, the use of ECN does not negatively affect connectivity." => I'd rather not have it used if it's not working - if a router marks ECN to CE but the next downstream router clears the codepoint, we ignore congestion, and we'd like to avoid that, no?
>> 
>> The problem in this case is that we don't know if we have an ECN-aware middlebox that is clearing a CE from the end system, on the assumption that it is closer to the end-system than one would expect -- we did see some of this activity in the study detailed in the PAM paper. In this case the CE-clearing is arguably correct (or at least acceptable). 
> 
> I'm beginning to understand your point. It's about this sentence in the draft:
> "If the ECE flag is not set on the ACK segment(s) sent by the
>       receiver acknowledging the CE probe segments, the path may or may
>       not be usable, as that there might be middleboxes/gateways that
>       (arguably correctly) clear CE on segments from end hosts, because
>       they assume that congestion can not have occurred up to this
>       point on the path."
> 
> But here you're assuming that this is the only possible reason for a CE to be cleared, i.e. CE cannot be cleared by a middlebox for any other reason. It might well be that a middlebox makes a mistake when it clears CE…  well, but if that wasn't seen in any of the measurement studies (the IMC one and yours), I'm inclined to accept that it's okay to leave ECN on then.

The question is one of requirements (and therefore one of philosophy): are we trying to guarantee (1) that ECN works, or (2) that attempts to activate ECN do not lead to connectivity problems. Given where we are now (increasing capability in endpoints, but not much activation in routers and clients) we think (2) is the more useful goal: we want to build confidence that TCP stacks could activate ECN negotiation on active open by default without causing connectivity issues that are hard for end-users and admins to debug.

We're not assuming that CE clearing is benign (though it does read that way; we'll need to be more explicit about a few things that aren't as clear as they should be in the -01 rev) -- rather, we're assuming that CE clearing that doesn't result in a dropped packet indicates that ECN can be activated on a path, even if you'll in effect never receive an ECE.

Cheers,

Brian