Subject: Re: [aqm] [iccrg] [tcpm] ECN support and usage on the Internet

From: Naeem Khademi <[email-masked]>
Date: Fri, 5 Apr 2013 16:01:01 +0200

I don't think the "global average speed" is a good indicative metric here
and it could be better to know the median/CDF for instance; In the same
graph "the average peak connection speed" is well beyond 4 Mbps making it a
fuzzy issue e.g. ECN could be useful sometimes and not useful in other
times again assuming Dave's analysis being correct.

Naeem

On Wed, Mar 20, 2013 at 12:14 PM, Matthew Ford <[email-masked]> wrote:

> (trimmed the cc list)
>
> On 19 Mar 2013, at 22:36, Jim Gettys <[email-masked]> wrote:
>
> > There is one other issue with ECN: when operating at low bandwidth at
> the very edge of the net, it can still be advantageous to drop a packet
> rather than ECN mark it, to get back the transmission time of the packet.
>  Dave Taht's experiments (IIRC) were below 4Mbps for this advantage (when
> doing VOIP over that bottleneck competing against other traffic in a best
> effort class).
>
> Hmmm. According to Akamai, global average connection speeds remain
> stubbornly below 4Mbps [1], so if Dave's analysis is correct, an
> unsophisticated ECN-deployment campaign may be counterproductive.
>
> Mat
>
> [1]
> http://www.internetsociety.org/blog/2013/02/internet-connection-speeds-and-right-some
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: Dave Taht <[email-masked]>
Date: Fri, 5 Apr 2013 12:05:36 -0700

> times again assuming Dave's analysis being correct.

Which part? This is what I wrote:

http://www.ietf.org/mail-archive/web/aqm/current/msg00051.html

Please read, where I tried to describe use cases for ECN.

I was rather ambiguous with what I wrote above, but I think the most
critical point I made, was that over the wild and woolly internet

"ECN however can be seriously gamed and there needs to be an operating
point in an AQM where packets are dropped not marked. "

And that I never found one, despite fiddling with various options for a
while.

What do you base a "drop instead of mark an ECN enabled" packet algorithm
on? The drop rate of a stream? The RTT of the stream? The overall load on a
device? Failure to respond to previous ECN markings?

They all involve keeping a lot of state around for not a lot of benefit.

Certainly at the moment, ECN can be used effectively particularly on
ingress rate shaping to a router, with current code already "out there" in
linux's fq_codel, codel and RED implementations, and that it works - but I
feel as soon as AQM (and ECN) reaches wider deployment that it will be
abused by the bad guys.

In data centers, and more generally, inside a well protected network, ECN
seems to have uses. I'm sorry the "nonce" idea for it didn't work out. In
the case of IPv6, there's all these extra bits in the flow header that
could be considered...

So I'm largely down on the idea except in a few special cases like the ones
I mentioned in the link above. In the case of a link-local routing protocol
like babel, ECN seemed to be a win, but the area remains rather unexplored.

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

---

From: John Leslie <[email-masked]>
Date: Fri, 5 Apr 2013 16:06:19 -0400

Dave Taht <[email-masked]> wrote:
> 
> ... This is what I wrote:
> 

   I held off on replying to that...

> Please read, where I tried to describe use cases for ECN.

   (I indeed have read it.)

> point in an AQM where packets are dropped not marked. "

   I agree that a packet ECN-marked may need to be dropped anyway.

   But I think it would help for you to expand on "seriously gamed..."

> And that I never found one, despite fiddling with various options for a

   I assume you mean you looked for a configuration parameter. I don't
know of one either -- but I quite agree there should be one.

> on? The drop rate of a stream?

   Yes, IMHO. Once you reach, say, 1% packet loss sustained over one
second, it's no longer time for halfway measures. However... it _would_
be good to deliver at least one ECN-marked packet before dropping (but
I have no sure-fire algorithm to do so: I would mark at a lower threshhold
than I drop ECN-marked packets, were I writing the code).

> The RTT of the stream? The overall load on a device?

   Probably not. I'd tend towards time-in-queue.

> Failure to respond to previous ECN markings?

   That's a real pain to evaluate. (If ConEx ever gets deployed, it
might become practical, though.)

> They all involve keeping a lot of state around for not a lot of benefit.

   Not the drop-rate. That's very minimal state...

> feel as soon as AQM (and ECN) reaches wider deployment that it will be

   The potential for abuse is real... But I'm not convinced the "benefit"
of abuse would be sufficient, especially if the additional time-in-queue
were only a few milliseconds.

   (Again, ConEx if deployed offers some real hope of catching abuse.)

> the case of IPv6, there's all these extra bits in the flow header that

   Indeed!

   (And, of course, ConEx is being designed for IPv6.)

> like babel, ECN seemed to be a win, but the area remains rather unexplored.

   IMHO, there are even now cases where ECN is a win -- it shaves enough
off the time-to-infer-congestion to make up for more abuse than I've
seen so far. But a configuration parameter to diddle time-in-queue before
dropping ECN-marked packets would _really_ help.

--
John Leslie <[email-masked]>

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Fri, 5 Apr 2013 23:41:42 +0300 (EEST)

> were only a few milliseconds.

Me neither. Also TCP congestion control could be disabled rather easily 
today but is that really happening? ...Except in those "new 100x faster 
TCP" research circles (and with IW10, obviously) ;-).

If you just want to transfer lots of data, TCP pretty much fills the 
buffers at the bottleneck as is, and you can hardly get _real work_ done 
significantly faster over the bottleneck, even if gaming. And if you're 
worried about other users getting some share of the BW, just open unfair 
number of connections and there's little need for more technical 
circumvention.

On the other hand, if there's simply intention to cause harm rather than 
doing "real work", why would one need to do something as complex as 
disabling TCP cc feedback loop? It's simply not happening, at least in 
large scale AFAIK. Why would ECN suddenly make that more attractive or 
more effective?

-- 
 i.