[e2e] ECN deployment
anoop at brocade.com
Fri Aug 20 13:35:10 PDT 2010
> Hope this is of some help,
Very much so!
I was hoping to also get responses from people with
experience running data centers or high-performance
I guess most people in such environments, just
like service providers, overdesign the network so
that loss seldom happens. Thus there is no tangible
benefit of going through the hassle with enabling
ECN in all of the devices.
> -----Original Message-----
> From: Glen Turner [mailto:gdt at gdt.id.au]
> Sent: Thursday, August 19, 2010 8:44 PM
> To: Anoop Ghanwani
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] ECN deployment
> 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
> 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
> 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
> 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
> 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,
> Network engineer, AARNet.
More information about the end2end-interest