[e2e] ECN deployment
gdt at gdt.id.au
Thu Aug 19 20:43:59 PDT 2010
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
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
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:
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
Hope this is of some help,
Network engineer, AARNet.
More information about the end2end-interest