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

[Michael Welzl <[e-mail]>]

Cutting, cutting… inline:


>> In case the probe packets are lost, it could be useful to have sent enough extra packets to be avoid an RTO (or at least reduce the risk for an RTO).
> 
> ...and requiring segments in the buffer would be a good way of doing this. We didn't want to get into buffer details, in on account of corner cases (in the timing of writes to the buffer) about which we didn't want to think about yet. But if we can ignore those, 

I think you can't avoid that anyway because of this:


>> I don't understand why the necessary information about the number of data that are available to send "is only available at the higher layer", can't TCP look into its send buffer to know how much it has available? Surely that must be possible?
> 
> Again, we didn't want to make assumptions about how applications write into the buffer, but yeah, requiring app changes at the API level is much, much worse. So good point, I think I'm convinced, at least, that an approach based on buffer occupancy is worth pursuing.

… seems like we agree now (wow, that was fast  :-)  ).


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

Cheers,
Michael