From touch at isi.edu Wed Aug 11 15:58:08 2010 From: touch at isi.edu (Joe Touch) Date: Wed, 11 Aug 2010 15:58:08 -0700 Subject: [e2e] CFP - IEEE Comm. Magazine feature topic on "Recent Advances in IETF Standards" Message-ID: <4C632B00.60003@isi.edu> ================================================================== Call For Papers - IEEE Communications Magazine Feature Topic on "Recent Advances in IETF Standards" ================================================================== The mission of the Internet engineering Task Force (IETF) is to "make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet". This is a continuous process driving and driven by the rapid evolution of the Internet. Protocols and other technical standards developed by the IETF are fundamental building blocks of the networked society. This feature topic will give an overview of recent achievements in creating standards that soon will have an impact on design, use and management of the Internet. We welcome tutorial style papers that describe new IETF standards as well as research papers presenting results that had an impact on the standardization process or that investigate the expected impact of recent standards. All submissions should be written to be understandable and appealing to a general audience. Areas of Interest ================= Areas of interest include standards track work that has been completed recently or will be completed soon from all areas of the IETF including but not limited to - Emergency service - Location based services - Internationalization - Peer-to-peer communication - Network address translation - Congestion control - IP6 transition - Mobility and mobility management - Secure DNS - Routing security - Locator/Identifier Separation - MPLS Transport Profile - Better-than-nothing security - Network configuration with XML - Internet metrics and measurement Schedule ======== Full paper submission: October 1, 2010 Author notifications: December 17, 2010 Manuscripts in final form: January 27, 2011 Publication date: April 2011 Submission Instructions ======================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the field. Authors must follow the IEEE Communications Magazine's guidelines for preparation of the manuscript. Complete guidelines for prospective authors can be found at http://www.comsoc.org/livepubs/ci1/info/sub_guidelines.html. All articles to be considered for publication must be submitted through the IEEE Manuscript Central (http://commag-ieee.manuscriptcentral.com). Guest Editors ============= Juergen Quittek, NEC Europe Ltd., quittek at neclab.eu Henning Schulzrinne, Columbia University, hgs at cs.columbia.edu Joe Touch, Postel Center, USC/ISI, touch at isi.edu From lastewart at swin.edu.au Mon Aug 16 19:49:34 2010 From: lastewart at swin.edu.au (Lawrence Stewart) Date: Tue, 17 Aug 2010 12:49:34 +1000 Subject: [e2e] Software for FreeBSD TCP R&D (resend of mail dated 2010-08-03) Message-ID: <4C69F8BE.3040602@swin.edu.au> Hi all, (apologies for any duplicates you have received) We're pleased to announce the release of a substantial set of new and updated BSD licenced software for TCP experimentation and research using FreeBSD: - "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 (new) - "Hamilton Delay" Congestion Control Algorithm v0.2 (update) - Vegas Congestion Control Algorithm v0.2 (update) - H-TCP Congestion Control Algorithm v0.12 (update) - CUBIC Congestion Control Algorithm v0.10 (update) - Statistical Information For TCP Research (SIFTR) v1.2.3 (update) - Enhanced Round Trip Time (ERTT) Khelp Module v0.2 (update) - Khelp Framework for FreeBSD v0.1.1 (update) - Modular TCP Congestion Control for FreeBSD v0.10.0 (update) A more detailed summary of the various tools/patches is included at the end of this email. Everything mentioned above along with other papers, patches and software relevant/useful for protocol analysis, debugging and experimental research is available from: http://caia.swin.edu.au/urp/newtcp/tools.html The software was developed as part of the NewTCP research project at Swinburne University's Centre for Advanced Internet Architectures, made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. Testing and development was further assisted by a grant from the FreeBSD Foundation. We welcome any feedback and hope you enjoy playing with the code and tools. Cheers, Lawrence Stewart, David Hayes and Grenville Armitage http://caia.swin.edu.au NB: "CAIA-Hamilton Delay" and "Hamilton Delay" are our working names for algorithms which do not have established names in the literature. "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 [1,2] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3] but with modifications made by CAIA [4]. It builds on Hamilton's initial proposal by adding tolerance to non-congestion related losses and still aims to allow delay- and loss-based algorithms to fairly coexist. "Hamilton Delay" Congestion Control Algorithm v0.2 [5,6] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3]. It provides a first step toward the ability of delay based algorithms to fairly coexist with loss based algorithms. Vegas Congestion Control Algorithm v0.2 [7,8] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the Vegas delay-based congestion control algorithm [9]. H-TCP Congestion Control Algorithm v0.12 [10,11] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the H-TCP loss based TCP congestion control algorithm [12]. CUBIC Congestion Control Algorithm v0.10 [13,14] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the CUBIC loss based TCP congestion control algorithm [15]. CUBIC is the current default algorithm used by Linux. Statistical Information For TCP Research (SIFTR) v1.2.3 [16,17] ---------------------------------------------------------------------- A FreeBSD 6/7/8/9 kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. NB: SIFTR has been imported into FreeBSD's "head" svn branch (a.k.a. 9-CURRENT) as revision 209662 and will be backported to 8-STABLE in time for 8.2-RELEASE. Enhanced Round Trip Time (ERTT) Khelp Module v0.2 [18,19] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that provides enhanced RTT measurements for use by delay and rate based TCP congestion control algorithms. Robust estimates of RTT are provided even when the receiver uses delayed acknowledgements, TCP segmentation offload (TSO) or Selective Acknowledgements (SACK). This module is required by the delay based congestion control algorithms. Khelp Framework for FreeBSD v0.1.1 [20,21] ---------------------------------------------------------------------- A FreeBSD kernel patch that provides support for generic kernel modules known as "helpers" to hook into arbitrary points within the kernel and provide service(s) to the running system. This forms the foundation for the ERTT Khelp module. Modular TCP Congestion Control for FreeBSD v0.10.0 [22,23] ------------------------------------------------- This revision of the modular TCP congestion control framework patch provides a current snapshot of the project's development branch. Some fairly major changes and refactoring have gone into this release, along with numerous tweaks, bug fixes and enhancements to support the new delay based congestion control algorithms we have been working on. In theory, the framework now also supports sharing of congestion control algorithms between congestion aware transport protocols like TCP and SCTP, though this integration work is yet to be done. [1] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-0.1.tar.gz [2] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-readme-0.1.txt [3] L. Budzisz, R. Stanojevic, R. Shorten, and F. Baker, "A strategy for fair coexistence of loss and delay-based congestion control algorithms", IEEE Commun. Lett., vol. 13, no. 7, pp. 555-557, Jul. 2009. [4] D. A. Hayes and G. Armitage, "Improved coexistence and loss tolerance for delay based TCP congestion control", in Proceedings of 35th Annual IEEE Conference on Local Computer Networks (LCN 2010), Denver, Colorado, USA, 11-14 October 2010. [5] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-0.2.tar.gz [6] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-readme-0.2.txt [7] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-0.2.tar.gz [8] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-readme-0.2.txt [9] L. S. Brakmo and L. L. Peterson, "TCP Vegas: end to end congestion avoidance on a global internet", IEEE J. Sel. Areas Commun., vol. 13, no. 8, pp. 1465-1480, Oct. 1995. [10] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-0.12.tar.gz [11] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-readme-0.12.txt [12] D. Leith, R. Shorten, "H-TCP: TCP for high-speed and long-distance networks", in Second International Workshop on Protocols for Fast Long-Distance Networks, Argonne, Illinois USA, February 2004. [13] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-0.10.tar.gz [14] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-readme-0.10.txt [15] I. Rhee, L. Xu, S. Ha, "CUBIC for Fast Long-Distance Networks", Internet Draft, draft-rhee-tcpm-cubic-02.txt, August 2008. [16] http://caia.swin.edu.au/urp/newtcp/tools/siftr-1.2.3.tar.gz [17] http://caia.swin.edu.au/urp/newtcp/tools/siftr-readme-1.2.3.txt [18] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-0.2.tar.gz [19] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-readme-0.2.txt [20] http://caia.swin.edu.au/urp/newtcp/tools/caia_khelp_framework_v0.1.1_9.x.r209905.patch [21] http://caia.swin.edu.au/urp/newtcp/tools/khelp-readme-0.1.1.txt [22] http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.10.0_9.x.r209905.patch [23] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.10.0.txt From anoop at brocade.com Tue Aug 17 16:08:24 2010 From: anoop at brocade.com (Anoop Ghanwani) Date: Tue, 17 Aug 2010 16:08:24 -0700 Subject: [e2e] ECN deployment Message-ID: <5EB1A55E180C914BBC1A49310B76293863830E1E46@HQ1-EXCH02.corp.brocade.com> Are folks here aware of any actual ECN deployments? It seems like the TCP implementations in most OSes support it, but it's disabled. Also most switch and router vendors support it, but again, disabled by default. So do any real deployments actually turn on these features and use them? If not, why not? I figure most ISPs would have it disabled (because of the unfairness issues between ECN and non-ECN sessions), but I'm wondering if people are aware of specialized networks that might have this option enabled in all their servers. Any pointers would be helpful. Thanks, Anoop From gdt at gdt.id.au Thu Aug 19 20:43:59 2010 From: gdt at gdt.id.au (Glen Turner) Date: Fri, 20 Aug 2010 13:13:59 +0930 Subject: [e2e] ECN deployment In-Reply-To: <5EB1A55E180C914BBC1A49310B76293863830E1E46@HQ1-EXCH02.corp.brocade.com> References: <5EB1A55E180C914BBC1A49310B76293863830E1E46@HQ1-EXCH02.corp.brocade.com> Message-ID: <1282275839.4788.38.camel@thrace.adelaide.aarnet.edu.au> 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. From anoop at brocade.com Fri Aug 20 13:35:10 2010 From: anoop at brocade.com (Anoop Ghanwani) Date: Fri, 20 Aug 2010 13:35:10 -0700 Subject: [e2e] ECN deployment In-Reply-To: <1282275839.4788.38.camel@thrace.adelaide.aarnet.edu.au> References: <5EB1A55E180C914BBC1A49310B76293863830E1E46@HQ1-EXCH02.corp.brocade.com> <1282275839.4788.38.camel@thrace.adelaide.aarnet.edu.au> Message-ID: <5EB1A55E180C914BBC1A49310B762938638319B7F7@HQ1-EXCH02.corp.brocade.com> >>>> > 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 computing environments. 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. Thanks, Anoop > -----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 > 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. From j.vimal at gmail.com Fri Aug 20 14:19:24 2010 From: j.vimal at gmail.com (Vimal) Date: Fri, 20 Aug 2010 14:19:24 -0700 Subject: [e2e] ECN deployment In-Reply-To: <5EB1A55E180C914BBC1A49310B762938638319B7F7@HQ1-EXCH02.corp.brocade.com> References: <5EB1A55E180C914BBC1A49310B76293863830E1E46@HQ1-EXCH02.corp.brocade.com> <1282275839.4788.38.camel@thrace.adelaide.aarnet.edu.au> <5EB1A55E180C914BBC1A49310B762938638319B7F7@HQ1-EXCH02.corp.brocade.com> Message-ID: Hi Anoop, On 20 August 2010 13:35, Anoop Ghanwani wrote: > I was hoping to also get responses from people with > experience running data centers or high-performance > computing environments. > > 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. > While over provisioning networks or having deep buffered switches might help reduce packet losses, it does not help deal with queuing delays. In fact, in this year's SIGCOMM, there's a paper that talks about how a particular ECN marking scheme can be used to maintain small queue occupancies in switch buffers. Here's a link to the paper if you're interested: http://research.microsoft.com/apps/pubs/?id=121386 Regards, -- Vimal From fernando at gont.com.ar Sun Aug 22 14:54:22 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 22 Aug 2010 18:54:22 -0300 Subject: [e2e] Nimrod for IPv6? Message-ID: <4C719C8E.10309@gont.com.ar> Hi, folks, IPv6 Routing Header Type 1, and IPv6 option 0x8a (Endpoint Identification), are related to the Nimrod routing system. Has Nimrod for IPv6 ever been specified? If so, has there ever been any deployments? Put another way: should one expect to find occurrences of RHT1 and/or option 0x8a? Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jnc at mercury.lcs.mit.edu Sun Aug 22 16:35:03 2010 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 22 Aug 2010 19:35:03 -0400 (EDT) Subject: [e2e] Nimrod for IPv6? Message-ID: <20100822233503.916CF6BE582@mercury.lcs.mit.edu> > From: Fernando Gont > Has Nimrod for IPv6 ever been specified? No. > Put another way: should one expect to find occurrences of RHT1 > and/or option 0x8a? Not that I can see. Noel From fu at cs.uni-goettingen.de Tue Aug 31 21:43:01 2010 From: fu at cs.uni-goettingen.de (Xiaoming Fu) Date: Wed, 01 Sep 2010 06:43:01 +0200 Subject: [e2e] Folklore of protocol design Message-ID: <4C7DD9D5.5080407@cs.uni-goettingen.de> Hi, I enjoyed Radia Perlman's keynote at SIGCOMM yesterday who introduces several key aspects of protocol design - thanks! Besides the two graceful "algorithms" she proposed in the talk, I think there is an additional reading for anyone of interest that she wrote more than a dozen years ago: http://tools.ietf.org/id/draft-iab-perlman-folklore Xiaoming