[e2e] ECN deployment

[Glen Turner]

Anoop Ghanwani wrote:
> Also most switch and router vendors support it

"Vendors" is not quite the right statistic. Most "routers (with their
ISP-centric software stream) deployed in ISP backbones" don't support
ECN.

Where routers do optionally support ECN is often isn't turned on
(because for each nerb knob an ISP turns, the risk of encountering a bug
in the router software increases). You'd be disappointed how many
routers out there run with the default queuing, even if that is a short
FIFO queue. Most ISP network engineers have poor knowledge of forwarding
plane tuning -- they rely on the manufacturer shipping reasonable
defaults. But the manufacturer has concerns other than end-to-end
performance (such as consistency across models and software versions).

> I figure most ISPs would have it disabled (because
> of the unfairness issues between ECN and non-ECN 
> sessions)

Can't say that's a concern. ECN versus non-ECN only matters upon
congestion and that's not how we like to run the network. Commercial
ISPs pay very little attention to fairness at all (they figure that's
the job of protocol developers to get right). Academic networks like
AARNet pay some attention, but we're much more concerned about
ameliorating RTT fairness, preventing network-wide synchronisation and
other unfairness issues in the network's normal operation rather than
when it is under stress.

I very much hope the public end-to-end measurement infrastructure being
deployed is picked by by the trade press and used when comparing ISP
performance. When the metric used is "ping" there will be little
management-initiated emphasis within commercial ISPs to improve
end-to-end performance. At the moment it is very much down to a small
number of network engineers and their interests in the topic.

> but I'm wondering if people are aware of 
> specialized networks that might have this option
> enabled in all their servers

Most operating systems (at least Win7, Ubuntu, Fedora) ship with ECN
disabled. This is because of this bug in the popular Cisco PIX firewall:

  Bug CSCds23698
  PIX sends RSET in response to tcp connections with ECN bits set

   PIX sends a TCP RST in response to any connection
   attempts that have the ECN bits set.

   The PIX no longer checks all the bits in the TCP
   flags but only the urgent, acknowledge, reset,
   synchronize, and finish bits for session establishment 

   Fix in 5.1(2.206), 5.2(1.200), 6.0(0.100) and later

Unfortunately some high profile sites used this firewall software and
took many years to upgrade that software (interesting how many "high
profile" websites had no in-service upgrade plans for their networking
devices). In retrospect, those promoting ECN would have seen more
penetration if they had lobbied/shamed the worst offenders, perhaps via
their equipment vendor.

There's a lot of this "tuning for bugs" going on in operating system
networking. Witness the default window scale advert of Linux. The
vendors will trade off performance for having to deal with <0.0001% of
hosts becoming unreachable.

For the record, Australia's Academic and Research Network supports a RED
queue with ECN marking where it is supported by the equipment we use.
Which turns out to be at the edge but not in the core (which does RED
with drop).

Hope this is of some help,
Glen
Network engineer, AARNet.