From sharad2833 at yahoo.com Thu Sep 7 23:44:43 2006 From: sharad2833 at yahoo.com (sharad misra) Date: Thu, 7 Sep 2006 23:44:43 -0700 (PDT) Subject: [e2e] How to get TCPanaly Message-ID: <20060908064443.94811.qmail@web35311.mail.mud.yahoo.com> Hi, Can you tell me how to get TCPanaly and its source as well. If someone has it can anyone send it to me. Regards Sharad Misra --------------------------------- Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060907/f5ae09dd/attachment.html From pganti at gmail.com Fri Sep 8 09:51:54 2006 From: pganti at gmail.com (Paddy Ganti) Date: Fri, 8 Sep 2006 09:51:54 -0700 Subject: [e2e] How to get TCPanaly In-Reply-To: <20060908064443.94811.qmail@web35311.mail.mud.yahoo.com> References: <20060908064443.94811.qmail@web35311.mail.mud.yahoo.com> Message-ID: <2ff1f08a0609080951j32641b92ua1a631c088eb8a7a@mail.gmail.com> Sharad, RFC 2398 says you need to contact Vern Paxson (vern at ee.lbl.gov) for the source. In his paper introducing this tool "Automated Packet Trace Analysis of TCP Implementations" he concluded with the following note which may explain lack of source distribution "We regard tcpanaly's development as not fully satisfying because of our inability to write the tool in terms of one-pass analysis of generic TCP actions, but the triple impediments of packet filter errors,vantage point ambiguities, and wide behavioral variation across different TCP implementations makes this difficult to achieve." -Paddy On 9/7/06, sharad misra wrote: > > Hi, > Can you tell me how to get TCPanaly and its source as well. If someone > has it can anyone send it to me. > > Regards > > Sharad Misra > > ------------------------------ > Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small > Business. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060908/0903c8e8/attachment.html From vern at icir.org Sun Sep 10 10:19:59 2006 From: vern at icir.org (Vern Paxson) Date: Sun, 10 Sep 2006 10:19:59 -0700 Subject: [e2e] How to get TCPanaly In-Reply-To: <2ff1f08a0609080951j32641b92ua1a631c088eb8a7a@mail.gmail.com> (Fri, 08 Sep 2006 09:51:54 PDT). Message-ID: <200609101719.k8AHJxfA063982@jaguar.icir.org> FYI, I do still give out copies, but the code is undocumented and now very out-of-date, which is why I've only distributed it on request. Vern From weiye at ISI.EDU Sun Sep 10 16:47:21 2006 From: weiye at ISI.EDU (Wei Ye) Date: Sun, 10 Sep 2006 16:47:21 -0700 Subject: [e2e] ACM SenSys'06 call for participation Message-ID: <1157932042.2508.34.camel@tulip.weihome> Our apologies if you have received multiple copies. --------- ACM SenSys 2006 - Call for Participation The 4th ACM Conference on Embedded Networked Sensor Systems http://sensys.acm.org/2006/ Boulder, Colorado, USA October 31 - November 3, 2006 In the short period since its inception in Los Angeles in 2003, SenSys has risen to become the leading forum for reporting on new, exciting, and technically important research in the field of sensor networks. Please note that the cut off dates for the conference hotels and early registration are September 29 and October 30, respectively. This year we have a stellar conference for you that includes: * A keynote by David Carlson Director, International Polar Year Program Office, and formally, Director of the Atmospheric Technology Division of the US National Centre for Atmospheric Research (NCAR). * 24 technical papers * 29 Sensor network demos * 19 Posters - representing early results and work-in-progress * 2 one day workshops on emerging and important new topics in sensor networks. The workshops will be held the day prior to the main technical program + First Workshop on World-Sensor-Web: Mobile Device Centric Sensory Networks and Applications http://www.sensorplanet.org/wsw2006/ + First Workshop on Distributed Smart Cameras http://www.iti.tugraz.at/dsc06/ Registration is now open: http://www.regonline.com/Checkin.asp?EventId=97157 Important Dates: Cut off date for reduced hotel rates is *September 29, 2006* Cut off date for early registration is *October 30, 2006* Please book and register today to guarantee the best rates. One behalf of the whole organizing team we very much look forward to seeing you at SenSys in Boulder! Best regards, Andrew T. Campbell SenSys 2006 General Chair Thanks to our sponsors: ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS, SIGBED NSF, NCAR, ISTS, Crossbow, Intel, Microsoft Research, Moteiv, Nokia Below you'll find the technical program. Please go to http://sensys.acm.org/2006/ for more information. ========================================= **Technical Program, Demos, and Posters** ========================================= Wednesday, November 1 08:15-08:30 Opening announcements 08:30-10:00 Keynote David Carlson Director, International Polar Year Program Office 10:00-10:30 Break 10:30-12:00 Operating Systems t-kernel: Providing Reliable OS Support to Wireless Sensor Networks Lin Gu, John A. Stankovic (University of Virginia) Run-time Dynamic Linking for Reprogramming Wireless Sensor Networks Adam Dunkels, Niclas Finne, Joakim Eriksson, Thiemo Voigt (Swedish Institute of Computer Science) Protothreads: Simplifying Event-Driven Programming of Memory- Constrained Embedded Systems Adam Dunkels, Oliver Schmidt, Thiemo Voigt (Swedish Institute of Computer Science), Muneeb Ali (TU Delft) 12:00-13:30 Lunch 13:30-14:30 Sensing Capturing High-Frequency Phenomena Using a Bandwidth-Limited Sensor Network Ben Greenstein, Christopher Mar, Alex Pesterev, Shahin Farshchi, Eddie Kohler, Jack Judy, Deborah Estrin (UCLA) Virtual High-resolution for Sensor Networks Aman Kansal, William J. Kaiser, Gregory J. Pottie, Mani B. Srivastava (UCLA) and Gaurav Sukhatme (USC) 14:30-15:00 Break 15:00 -16:30 Routing and Dissemination RBP: Robust Broadcast Propagation in Wireless Networks Fred Stann (Amgen), John Heidemann, Rajesh Shroff, Muhammad Zaki Murtaza (USC/ISI) Interest Dissemination with Directional Antenna for Wireless Sensor Networks with Mobile Sinks Yihong Wu, Xiaobo Chen, Lin Zhang, Zhisheng Niu (Tsinghua University) Lazy Cross-Link Removal for Geographic Routing Young-Jin Kim, Ramesh Govindan (USC), Brad Karp (University Colledge London), Scott Shenker (UCB) **19.00 Banquet at the Walnut Brewery Boulder's Original Brew Pub 1123 Walnut Street** Thursday, November 2 09:00-10:00 Configuration StarDust: A Flexible Architecture for Passive Localization in Wireless Sensor Networks Radu Stoleru, Pascal Vicaire, Tian He, John A. Stankovic (University of Virginia) The Design and Implementation of a Self-Calibrating Distributed Acoustic Sensing Platform Lewis Girod (MIT/CSAIL), Martin Lukac, Vlad Trifa, Deborah Estrin (UCLA) 10:00-10:30 Break 10:30-11:30 In-network Processing Target Tracking with Binary Proximity Sensors: Fundamental Limits, Minimal Descriptions, and Algorithms Nisheeth Shrivastava, Raghuraman Mudumbai, Upamanyu Madhow, Subhash Suri (UCSB) Data Compression Algorithms for Energy-Constrained Devices in Delay Tolerant Networks Christopher M. Sadler, Margaret Martonosi (Princeton University) 11:30-13:00 Lunch 13:00-14:30 Radio Propagation and Transport Datalink Streaming in Wireless Sensor Networks Raghu K. Ganti, Praveen Jayachandran, Tarek F. Abdelzaher, and Haiyun Luo (UIUC) ATPC: Adaptive Transmission Power Control for Wireless Sensor Shan Lin (University of Virginia), Tian He (University of Minnesota), Jingbin Zhang, Gang Zhou, Lin Gu, John A. Stankovic (University of Virginia) Experimental Study of Concurrent Transmission in Wireless Sensor Networks Dongjin Son, Bhaskar Krishnamachari (USC), John Heidemann (USC/ISI) 14:30-15:00 Break 15:00-16:30 Storage and Abstractions Abstractions for Safe Concurrent Programming in Networked Embedded Systems William P. McCartney, Nigamanth Sridhar (Cleveland State University) Scalable Data Aggregation for Dynamic Events in Sensor Networks Kai-Wei Fan, Sha Liu, Prasun Sinha (The Ohio State University) An Energy-Optimized Object Storage System for Memory-Constrained Sensor Devices Gaurav Mathur, Peter Desnoyers, Deepak Ganesan, Prashant Shenoy (University of Massachusetts, Amherst) 16:30-20:00 Demonstration and poster session List of accepted demonstrations and posters http://sensys.acm.org/2006/demo_poster.html Friday, November 3 08:30-10:00 Architecture CarTel: A Distributed Mobile Sensor Computing System Bret Hull, Vladimir Bychkovsky, Yang Zhang, Kevin Chen, Michel Goraczko, Allen Miu, Eugene Shih, Hari Balakrishnan, Samuel Madden (MIT/CSAIL) MELETE: Supporting Concurrent Applications in Wireless Sensor Networks Yang Yu, Loren Rittle (Motorola Labs), Jason LeBrun (UCD), Vartika Bhandari (UIUC) The Tenet Architecture for Tiered Sensor Networks Omprakash Gnawali (USC), Ben Greenstein (UCLA), Ki-Young Jang (USC), August Joki (UCLA), Jeongyeup Paek, Marcos Vieira (USC), Deborah Estrin (UCLA), Ramesh Govindan (USC), Eddie Kohler (UCLA) 10:00-10:30 Break 10:30-12:00 Media Access Control Funneling-MAC: A Localized, Sink-Oriented MAC for Boosting Fidelity in Sensor Networks Gahng-Seop Ahn (Columbia University), Emiliano Miluzzo, Andrew T. Campbell (Dartmouth College), Se Gi Hong (Columbia University), Francesca Cuomo (University of Rome "La Sapienza") X-MAC: A Short Preamble MAC Protocol for Duty-Cycled Wireless Sensor Networks Michael Buettner, Gary V. Yee, Eric Anderson, Richard Han (University of Colorado, Boulder) Ultra-Low Duty Cycle MAC with Scheduled Channel Polling Wei Ye, Fabio Silva, John Heidemann (USC/ISI) 12:00-12:15 Best Talk Award and Closing ========================================= ***************DEMOS********************* ========================================= SignetLab: Deployable Sensor Network Testbed and Management Tool Riccardo Crepaldi, Albert F Harris III, Alberto Scarpa, Andrea Zanella, Michele Zorzi (University of Padova) An Eventual Consistent Wireless Light Control System Jeonghoon Kang (Korea Electronics Technology Institute), Alec Woo (Arch Rock), Junejae Yoo, Myunghyun Yoon (Korea Electronics Technology Institute) Data Analysis Tools for Sensor-Based Science Stuart Ozer (Microsoft Research), Alex Szalay (Johns Hopkins University), Jim Gray (Microsoft Research), Andreas Terzis, Razvan Musaloiu-E., Katalin Szlavecz, Josh Cogan, Randal Burns (Johns Hopkins University) Data Collection in Delay Tolerant Mobile Sensor Networks using SCAR Cecilia Mascolo, Mirco Musolesi, Bence Pasztor (University College London) cCAM: Ultra Compact, High Data-Rate Wireless Sensor Node with a Miniature Camera Chulsung Park, Pai H. Chou (UCI) Using Grid Technologies to Optimise a Wireless Sensor Network for Flood Management Danny Hughes, Phil Greenwood, Geoff Coulson, Gordon Blair, Barry Porter, Paul Grace, Florian Pappenberger, Paul Smith, Keith Beven (Lancaster University) A Funneling-MAC for High Performance Data Collection in Sensor Networks Gahng-Seop Ahn (Columbia University) Emiliano Miluzzo, Andrew T. Campbell (Dartmouth College) A Storage-centric Camera Sensor Network Gaurav Mathur, Paul Chukiu, Peter Desnoyers, Deepak Ganesan, Prashant Shenoy (University of Massachusetts) Real-Time Volcanic Earthquake Localization Geoffrey Werner-Allen, Patrick Swieskowski, Matt Welsh (Harvard University) Low Power, Low Cost, Wireless Camera Sensor Nodes For Human Detection Jason Schlessman, Jaechang Shim, Ikdong Kim, Yun Cheol Baek, Wayne Wolf (Princeton University) A Unified Architecture for Flexible Radio Power Management in Wireless Sensor Networks Kevin Klues, Guoliang Xing, Chenyang Lu (Washington University) A Self-Calibrating Distributed Acoustic Sensing Platform Lewis D Girod (MIT/CSAIL), Martin Lukac (UCLA), Vladimir Trifa (EPFL), Deborah Estrin (UCLA) A Virtualizing OS Kernel for Wireless Sensor Networks Lin Gu, John A Stankovic (University of Virginia) Flexible Hardware/Software Platform for Tracking Applications Junaid Ansari, Jos?? S??nchez, Marina Petrova, Janne Riihij??rvi, Ossi Raivio, Krisakorn Rerkrai, Chirstine Jardak, Frank Oldewurtel, Mathias Wellens, Lili Wu, Petri M??h??nen (RWTH Aachen University) Simple Sensor Syndiciation Michael Colagrosso, Wade Simmons, Marianne Graham (Colorado School of Mines) Responsive and Energy-Efficient Sensor Networking for Real Time Location Tracking Henoc Agbota, Mike Hazas (Lancaster University) Demonstrating Distributed Signal Strength Location Estimation Neal Patwari (University of Utah), Alfred O. Hero (University of Michigan) Sensing and Reproducing the Shapes of 3D Objects Using Claytronics Padmanabhan Pillai, Jason Campbell (Intel Research Pittsburgh) Cascades: An Extensible Heterogeneous Sensor Networking Framework Phillip Sitbon, Nirupama Bulusu, Wu-Chi Feng (Portland State University) LiteOS - A Lightweight Operating System for C++ Software Development in Sensor Networks Qing Cao, Tarek Abdelzaher (UIUC) GRAIL: General Real-Time Adaptable Indoor Localization Yingying Chen (Rutgers University), Eiman Elnahrawy (Kordinate LLC), John-Austen Francisco, Konstantinos Kleisouris (Rutgers University), Xiaoyan Li (Lafayette College), Hongyi Xue (Rutgers University), Richard P. Martin (Rutgers University and Kordinate LLC) A Hierarchical Location Directory Service Across Sensor and IP Networks Sangeeta Bhattacharya, Chien-Liang Fok, Chenyang Lu, Gruia-Catalin Roman (Washington University) Software Radio Implementation of Short-range Wireless Standards for Sensor Networking Thomas Schmid, Tad Dreier, Mani B. Srivastava (UCLA) The CarTel Mobile Sensor Computing System Vladimir L Bychkovsky, Kevin Chen, Michel Goraczko, Hongyi Hu, Bret W Hull, Allen K Miu, Eugene I Shih, Yang Zhang (MIT) TOSDev: A Rapid Development Environment for TinyOS William P McCartney, Nigamanth Sridhar (Cleveland State University) Step-wise Context Extraction in AoK Mule System Yuichi Uehara, Masato Mori, Nayuta Ishii (Tokyo Denki University), Yoh Shiraishi (The University of Tokyo) Yoshito Tobe (Tokyo Denki University) SensorMap: A Web Site for Sensors World-Wide Suman Nath, Jie Liu, Jessica Miller, Feng Zhao (Microsoft Research), Andre Santanche (UNICAMP) Mobility Centric Campus Area Sensor Network for Locality Specific Applications Mukundan Sridharan, Anish Arora, Rajiv Ramnath, Emre Ertin (The Ohio State University) ========================================= ***************Posters******************* ========================================= Routing and Processing Multiple Aggregate Queries in Sensor Networks Niki Trigoni, Alexandre Guitton, Antonios Skordylis (University of London) Rateless Codes for Data Dissemination in Sensor Networks Andrew Hagedorn, David Starobinski, Ari Trachtenberg (Boston University) AMSecure: Secure Link-Layer Communication in TinyOS for IEEE 802.15.4- based Wireless Sensor Networks Anthony D Wood, John A Stankovic (University of Virginia) Virtual Sensing Range Emiliano Miluzzo, Nicholas D Lane, Andrew T Campbell (Dartmouth College) uScan: A Lightweight Two-Tier Global Sensing CoverageDesign Yu Gu, Tian He (University of Minnesota) SkiScape Sensing Shane B. Eisenman (Columbia University), Andrew T. Campbell (Dartmouth College) Channel Surfing: Defending WirelessSensor Networks from Jamming and Interference Wenyuan Xu, Wade Trappe, Yanyong Zhang (Rutgers University) Energy Adaptation Techniques to Optimize Data Delivery in Store-and- Forward Sensor Networks Pei Zhang, Margaret Martonosi (Princeton Unviersity) A Distributed Reliable Data Transport Strategy for Event Based Wireless Sensor Networks Yuyan Xue, Byrav Ramamurthy, Ying Lu (University of Nebraska - Lincoln) Lowering Radio Duty Cycle Through Temperature Compensated Timing Joakim Arfvidsson, Eric Park, Philip Levis (Stanford University) Collaborative Scheduling of Event Types and Allocation of Rates for Wireless Sensor Nodes with Multiple Sensing Units Hidayet Ozgur Sanli, Hasan Cam (Arizona State University) Kaizen: Improving Sensor Network Operating Systems James Horey, Jean-Charles Tournier, Arthur B Maccabe (University of New Mexico) Achieving Realistic Sensing Area Modeling Joengmin Hwang, Tian He, Yongdae Kim (University of Minnesota) Is Data-Centric Storage and Querying Scalable? Joon Ahn, Bhaskar Krishnamachari (USC) Understanding the Causes of Packet Delivery Success and Failure in Dense Wireless Sensor Networks Kannan Srinivasan (Stanford University), Prabal Dutta, Arsalan Tavakoli (UCB), Philip Levis (Stanford University) WaveScope: A Signal-Oriented Data Stream Management System Lewis Girod, Kyle Jamieson, Yuan Mei, Ryan Newton, Stanislav Rost, Arvind Thiagarajan, Hari Balakrishnan, Samuel Madden (MIT/CSAIL) Comprehensive Monitoring of CO2 Sequestration in Subalpine Forest Ecosystems and its Relation to Global Warming Lynette L. Laffea, Russ K. Monson, Ryan Manning, Ashly Glasser, Richard Han (University of Colorado, Boulder), Steve Oncley, Jielun Sun, Sean Burns, Steve Semmer, John Militzer (NCAR) TINX A Tiny Index Design for Flash Memory on Wireless Sensor Devices Ajay Mani, Manjunath B Rajashekhar, Philip Levis (Stanford University) Wireless Sensor Networks for Structural Health Monitoring Sukun Kim, Shamim Pakzad, David Culler, James Demmel, Gregory Fenves, Steve Glaser (UCB), Martin Turon (Crossbow) From ctchou at cse.unsw.edu.au Wed Sep 13 09:49:49 2006 From: ctchou at cse.unsw.edu.au (Chun Tung Chou) Date: Thu, 14 Sep 2006 02:49:49 +1000 Subject: [e2e] LCN 2006 - Call for Participation Message-ID: Call for Participation (LCN 2006) The 31st IEEE Conference on Local Computer Networks (LCN) Tampa, Florida, U.S.A. 14-16 November 2006 http://www.ieeelcn.org/ The IEEE Conference on Local Computer Networks (LCN), sponsored by the IEEE Computer Society, is one of the networking industry's oldest, continuously running conferences. This year's LCN features: * Keynote Addresses by -- Dr. Bob Iannucci, Senior Vice President and Head of Nokia Research Center -- Prof. Edward Knightly, Rice University * 61 regular papers in 15 parallel sessions * 31 posters * 5 Workshops on the first day of the conference ================= Technical Program ================= ================= Tuesday 14 November ================= The following 5 workshops will take place: * Sixth International IEEE Workshop on Wireless Local Networks (WLN) http://www.cse.unsw.edu.au/~wln2006/ -- Keynote: Prof Vassilis Tsaoussidis (Democritus University of Thrace, Greece) -- 11 regular papers and 5 posters * First IEEE International Workshop on Practical Issues in Building Sensor Network Applications http://www.cse.unsw.edu.au/~senseapp/ -- Keynote: Prof. A. Savvides, Yale University, USA -- 11 regular papers * The 2nd IEEE LCN Network Security workshop http://www.cs.ucf.edu/~czou/IEEE-WoNS.htm -- 8 regular papers * Second IEEE International Workshop on Performance and Management of Wireless and Mobile Networks http://137.122.93.16/perf/about.html -- 16 Regular papers * First IEEE LCN Workshop on Network Measurements http://www.cnrl.colostate.edu/IEEELCN-WNM2006/cfp.html Featuring a Panel Discussion and 5 regular papers =================== Wednesday 15 November =================== Keynote: Dr. Bob Iannucci, Senior Vice President and Head of Nokia Research Center ***** 10:30 - 12:10 Session #1 (Tracks A, B, and C) Track A ? Energy efficiency LEMA: Localized Energy-Efficient Multicast Algorithm based on Geographic Routing by Juan Sanchez and Pedro Ruiz Energy-efficient Interleaving for Error Recovery in Broadcast Networks by Kyungtae Kang and Yongwoo Cho Performance Study of Power Saving Classes of Type I and II in IEEE 802.16e by Lei Kong and Danny H. K. Tsang Ethernet Adaptive Link Rate: System Design and Performance Evaluation by Ken Christensen and Chamara Gunaratne Track B ? Performance evaluation Performance Aware Design of Communication Systems by Lukas Pustina, Michael Gerharz, Peter Martini, Volker Deichmann, and Simon Schwarzer Minimizing Cache Misses in an Event-Driven Network Server: A Case Study of TUX by Sapan Bhatia, Charles Consel, and Julia Lawall An Efficient Buffer Management Technique for Remote 3D Image-based Rendering by Azzedine Boukerche and Jing Feng Efficient Packet Processing in User-Level OSes: A Study of UML by Younggyun Koh, Calton Pu, Sapan Bhatia, and Charles Consel Track C ? Scheduling and MAC layer Fair Scheduling over Multiple Servers with Flow-Dependent Server Rates by Satya Mohanty and Laxmi Bhuyan An Adaptive Non-preemptive Scheduling Framework for Delay Bounded Traffic by Yaser Khamayseh and Ehab Elmallah Bandwidth Aware Slot Allocation in Hybrid MAC by Yuvraj Rana, Bao Hua Liu, Alfandika Nyandoro, and Sanjay Jha A Congestion-aware Medium Access Control Protocol for Multi-rate Ad-hoc Networks by Timo Zauner, Luke Haslett, Wen Hu, Sanjay Jha, and Cormac Sreenan ***** 1:30 - 3:10 Session #2 (Tracks A, B, and C) Track A ? P2P and overlay networks Computing Real Time Jobs in P2P Networks by Jingnan Yao, Jian Zhou, and Laxmi Bhuyan Achieving Resilient and Efficient Load Balancing in DHT-based P2P Systems by Di Wu, Ye Tian and Kamwing Ng Content-based Packet Marking for Application-Aware Processing in Overlay Networks by Panho Lee, Tarun Banka, Anura Jayasumana, and Chandra V Chandrasekar Track B ? Transport layer Considerations of SCTP Retransmission Delays for Thin Streams by Jon Pedersen, Carsten Griwodz, and P?l Halvorsen A New Stable AQM exploiting RTT Estimation by Hayato Hoshihara Adapting TCP for Vertical Handoffs in Wireless Networks by Laila Daniel and Markku Kojo Emulating TCP Using the Fixed Point Algorithm by Debessay Kassa Track C ? Routing and caching An Interior Path Vector Protocol by Conor Creagh and Cormac Sreenan Maximum Data Collection Least-Cost Routing in Energy Constrained Wireless Sensor Networks by Ka Lok Hung, Brahim Bensaou, Junhua Zhu, and Farid Nait-Abdesselam On Cache Prefetching Strategy for Integrated Infostation-Cellular Network by Jerry Chun-Ping Wang, Hossam Elgindy, and Justin Lipman ***** 3:30 - 5:00 Poster Session Cerco: Supporting Range Queries with a Hierarchically Structured Peer-to-Peer System by Simon Rieche, Klaus Wehrle, Leo Petrak, and Clemens Wrzodek Performance of Constant Quality Video Applications using the DCCP Transport Protocol by Jeroen Van Velthoven, Kathleen Spaey, and Chris Blondia BEAM: An Efficient Peer to Peer Media Streaming Framework by Darshan Purandare MPLS Based Approach for Heterogeneous and Scalable Multicast in DiffServ by Mohamed El Hachimi and Abdelhafid Abouaissa Power-Proxying on the NIC: A Case Study with the Gnutella File-Sharing Protocol by Pradeep Purushothaman, Mukund Navada Kanyana, Rajagopal Subramaniyan, Casey Reardon, and Alan George Energy-Efficient Rate Adaptation and Congestion Control Protocol for Wireless Ad Hoc Networks by Maciej Zawodniok and Sarangapani Jagannathan A Multicast Tree Reconstuction Method for Many-to-Many Mobile Communications with Delay Constraint by Tsuyoshi Yamada, Shoji Yoshimura, Keita Kawano, Kazuhiko Kinoshita, and Koso Murakami Achieving Fairness in IEEE 802.11 Ad Hoc Networks by Fanilo Harivelo A Traffic Shaping Heuristic for Congestion Control in Optical Burst-Switched Networks by Mushi Jin and Oliver Yang The Design of Efficient Hashing Techniques for IP Address Lookup by Devang Pandya, Christopher Martinez, Wei-Ming Lin, and Parimal Patel Adaptive Link Rate (ALR) for Ethernet: Analysis of a MAC Handshake Protocol by Himanshu Anand, Casey Reardon, Rajagopal Subramaniyan, and Alan George Hydra: A Novel Framework for Making High-Performance Computing Offload Capable by Danny Dolev, Pete Wyckoff, Tal Anker, and Yaron Weinsberg Characterization of Layer-2 Unique Topologies in Multisubnet Local Area Networks by Hassan Gobjuka and Yuri Breitbart Data Aggregation System for Distributing Inter-Vehicle Warning Messages by Stephan Eichler, Markus Strassberger, and Christian Merkle TA2I: Time Slot Access with Acknowledge Insertion by Marcel Wille and Harald Richter Towards Minimizing Service Degradation during MIPv6 Handoffs by Yan Cheng and J. William Atwood VoIP Capacity over Wireless Mesh Networks by Alex Lee, Guanyan Cai, Yu Ge, and Winston Seah Traffic shaping and dimensioning of an external overload controller in service architectures by Jens Andersson, Christian Nyberg, and Maria Kihl Mitigating Worm Propagation on Virtual LANs by Saeed Rajput, Xiaoguang Sun, and Sam Hsu QoS Differentiation Provisioning & Management System Exploiting Mobile Agent Technology by Angelos Michalas A New Bandwidth Access Framework in Slotted-OPS Networks by Akbar Ghaffar Pour Rahbar and Oliver Yang Improved Collaborative Environment Control Using Mote-based Sensor/Actuator Networks by Masayuki Nakamura, Atsushi Sakurai, Toshio Watanabe, Jiro Nakamura, and Hiroshi Ban Communication-assisted Topology Control of Semi-autonomous Robots by Venkatesh Ramarathinam and Miguel Labrador Scalability of Location Sensor Data Fusion by Tom Pfeifer and Kieran Sullivan Port-based Multihomed Mobile IPv6 for Heterogeneous Networks by Christer Ahlund, Robert Brannstrom, Karl Andersson, and Orjan Tjernstrom Performance of TCP with Load-sensitive Routing by Sivaram Cheekiralla and Daniel Engels Needles in Haystacks: Practical Intrusion Detection from Theoretical Results by Gerald Marin and William Allen Viral IP Address Assignment by Sivaram Cheekiralla and Daniel Engels =================== Thursday 16 November =================== Keynote: Dr. Edward Knightly, Rice University, USA (Title of talk: ?Large-Scale Urban Mesh Networks: from Deployment to Applications?) ***** 10:30 - 12:10 Session #3 (Tracks A, B, and C) Track A ? Security and disaster management Detecting Botnets with Tight Command and Control by Tim Strayer Can CRLs Provide Bandwidth-Efficient Online Certificate Status? by Anantharaman Lakshminarayanan, Aditya Liviandi, Tong Lee Lim, and William Chui Modelling Voice Communication in Disaster Area Scenarios by Nils Aschenbruck, Michael Gerharz, Matthias Frank, and Peter Martini Security for FTTx Optical Access Networks by Walid Shawbaki and Ahmed Kamal Track B ? Clustering and localization Clustered Mobility Model for Scale-Free Wireless Networks by Sunho Lim, Chansu Yu, and Chita Das Landscape-3D: A Robust Localization Scheme for Sensor Networks over Complex 3D Terrains Liqiang Zhang, Xiaobo Zhou, and Qiang Cheng Adaptive Location Update Area Design for PCS Networks under 2D Markov Walk Model by Jun Zheng, Yan Zhang, and Ling Wang Track C ? High-speed interconnects and hardware Design of a Giga-bit Hardware Accelerator for the iSCSI Initiator by Chung-Ho Chen, Yi-Cheng Chung, Chen-Hua Wang, and Han-Chiang Chen Efficient Java Communication Protocols on High-speed Cluster Interconnects by Guillermo Taboada, Juan Touri?o, and Ram?n Doallo An integrated Hardware Solution for MAT, MPLS-UNI, and TM in Access Networks by Harald Widiger, Stephan Kubisch, Thomas Bahls, and Dirk Timmermann Effect of Hash Collisions on the Performance of LAN Switching Devices and Networks by Chris Huntley, Galina Antonova, and Paul Guinand ***** 1:30 - 3:10 Session #4 (Tracks A, B, and C) Track A ? Wireless and ad hoc Exploiting Rate Diversity for Broadcasting in Wireless Mesh Networks by Junaid Qadir, Chun Tung Chou, and Archan Misra Analysis of Link Availability and the Capacity of Mobile Ad Hoc Networks by Ruchi Sharma and Ravi Pendse Toward a Seamless Communication Architecture for In-building Networks at the 60 GHz band by Bao Linh Dang, Venkatesha Prasad, and Ignas Niemegeers A Hybrid Distributed Coordination Function for Scalability and Inter-operability in Large-Scale WLANs by Nakjung Choi, Seongil Han, Yongho Seok, Yanghee Choi, and Taekyoung Kwon Track B ? Optical networks 1 A Transceiver Saving Auxiliary Graph Model for Dynamic Traffic Grooming in WDM Mesh Networks by Huaxiong Yao Traffic Grooming in Statistically Shared Optical Networks by Srivatsan Balasubramanian and Arun Somani Optical CDMA Code Collision and Translation Performance Analysis by Anh Nguyen and Deniz Gurkan Track C ? Modeling and advanced techniques Ontology Modeling of a Dynamic Protocol Stack by Lifeng Zhou Towards Semantic Modeling for QoS Specification by Lifeng Zhou Training on Multiple Sub-Flows to Optimise the use of Machine Learning Classifiers in Real-World IP Networks by Thuy Nguyen and Grenville Armitage Biologically-Inspired Data Aggregation for Multi-Modal Wireless Sensor Networks by Pruet Boonma and Junichi Suzuki ***** 3:30 - 5:35 Session #5 (Tracks A, B, and C) Track A ? IEEE 802.11 Delay Distribution Analysis of the RTS/CTS mechanism of IEEE 802.11 by Paschalis Raptis, Albert Banchs, Vassileios Vitsas, Konstantinos Paparrizos, and Periklis Chatzimisios Maximizing differentiated throughput in IEEE 802.11e wireless LANs by Jongwon Yoon, Sangki Yun, and Hyogon Kim Performance Limits and Analysis of Contention-based IEEE 802.11 MAC by Shao-Cheng Wang and Ahmed Helmy Track B ? Optical networks 2 Residual Admission Capacity in Optical Burst Switching Networks and its Application in Routing Loss-Guaranteed Flows by Qian Chen, Mohan Gurusamy, and Kee Chaing Chua Embedding Hypercube Communications on Optical Chordal Ring Networks of Degree 4 by Yawen Chen Delay Constrained Traffic Grooming in WDM Ring Networks by Arun Vishwanath and Weifa Liang Rerouting Schemes with Inter-layer Backup Resource Sharing for Differentiated Survivability in IP-over-WDM Optical Networks by Krishanthmohan Ratnam, Mohan Gurusamy, and Luying Zhou An Efficient MAC Protocol for Optical WDM Networks with Simulation Evaluation by Ge Nong, S. Zhang, and XiaoLa Lin Track C ? Multicast Protecting Multicast Sessions in Wireless Mesh Networks by Xin Zhao, Chun Tung Chou, Jun Guo, and Sanjay Jha The Internet Group Management Protocol with Access Control (IGMP-AC) by Salekul Islam and J. William Atwood Making Application Layer Multicast Reliable is Feasible by Bin Rong Detecting Malicious Peers in Overlay Multicast Streaming by Samarth Shetty, Patricio Galdames, Wallapak Tavanapong, and Ying Cai -- Chun Tung Chou Senior Lecturer / Head of Networks Group School of Computer Science and Engineering The University of New South Wales Sydney, NSW 2052, Australia Phone: +61-2-9385 7203 Fax:+61-2-9385 5995 Email: ctchou at cse.unsw.edu.au WWW: http://www.cse.unsw.edu.au/~ctchou/ Legal disclaimer: http://www.eng.unsw.edu.au/emaildis.htm The CRICOS Provider Code for UNSW is 00098G. From am.amir at gmail.com Fri Sep 15 13:11:16 2006 From: am.amir at gmail.com (Aamir Mehmood) Date: Sat, 16 Sep 2006 01:11:16 +0500 Subject: [e2e] PhD. in Germany Message-ID: <12a3f4080609151311k7ffd6776h3fe975247d59ed6d@mail.gmail.com> Dear All Hi I have done my masters and now seeking admission in PhD in Germany. Luckly i have got PhD funding from DaaD Germany. My research interests are as follows. 1) Active and Passive measurements on Tier-1/Tier-2 ISP's 2) Internet- 2 3) End-to-End QoS Architectures 4) Simulation and Modelling of next generation Internet. 5) Voice Quality Assessment I shall be thankful if some one could give me an idea where similar kind of research in Germany is being done and is there any requirement of any PhD student for such projects. My CV is attached. Regards Amir Mehmood -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060916/d60438c9/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: CV ver 1.4.pdf Type: application/pdf Size: 46945 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060916/d60438c9/CVver1.4-0001.pdf From feamster at cc.gatech.edu Wed Sep 20 00:13:00 2006 From: feamster at cc.gatech.edu (Nick Feamster) Date: Wed, 20 Sep 2006 03:13:00 -0400 Subject: [e2e] CoNext Student Workshop Message-ID: <20060920071259.GO9458@cc.gatech.edu> CoNext Student Workshop Lisbon, Portugal December 4, 2006 Call for Abstracts The CoNext Student Workshop is a forum for graduate students around the world to interact with their peers, publicize and exchange feedback, share experiences, make contacts, and learn about networking problems that other students from around the world are working on. Students will not only learn about other students' work, but also meet and interact with established networking researchers, who will participate in the workshop as panelists and organizers. Students will have the opportunity to establish connections in the networking community and help shape its future. The workshop will be a day-long program organized in a way that promotes interaction and lively discussion. The CoNext 2006 Student Workshop organizing committee is encouraging the submission of abstracts describing ongoing thesis research in all areas of computer networking and data communications (for a list of topics, please refer to the CoNext 2006 call for papers). Student authors are asked to submit 1-2 page abstracts before the deadline below, using the CoNext 2006 format. Please visit http://www.co-next.net and follow the link to the Student Workshop to submit your abstract. Submissions will be reviewed by the program committee, from which a number of abstracts will be selected for inclusion in the workshop program. The workshop abstracts will appear in the CoNext 2006 proceedings. CoNext 2006 offer students the opportunity to apply for travel grants. Information on travel grants are available from http://www.co-next.net. Important dates: ---------------- Submission: September 29th, 2006 Notification: October 13th, 2006 Final version: October 20th, 2006 Student Workshop chairs: Nick Feamster, Georgia Tech, USA Renata Teixeira, LIP6-CNRS, France Program Committee: Aditya Akella, University of Wisconsin, USA Ernst Biersack, Institut Eurecom, France Olivier Bonaventure, Universite Catholique de Louvain, Belgium Luis Costa, Universidade Federal do Rio de Janeiro, Brazil Jon Crowcroft, University of Cambridge, UK Xenofontas Dimitropoulos, IBM Zurich Serge Fdida, LIP6-CNRS, France Jim Kurose, University of Massachusetts, Amherst, USA Olaf Maennel, University of Adelaide, Australia Morley Mao, University of Michigan, USA Aman Shaikh, AT&T Research, USA Geoff Voelker, University of California San Diego -- From doug.leith at nuim.ie Fri Sep 22 07:22:25 2006 From: doug.leith at nuim.ie (Douglas Leith) Date: Fri, 22 Sep 2006 15:22:25 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc Message-ID: <4513F1A1.3000506@nuim.ie> For those interested in TCP for high-speed environments, and perhaps also people interested in TCP evaluation generally, I'd like to point you towards the results of a detailed experimental study which are now available at: http://www.hamilton.ie/net/eval/ToNfinal.pdf This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP performance under a wide range of conditions including with mixes of long and short-lived flows. This study has now been subject to peer review (to hopefully give it some legitimacy) and is due to appear in the Transactions on Networking. The conclusions (see summary below) seem especially topical as BIC-TCP is currently widely deployed as the default algorithm in Linux. Comments appreciated. Our measurements are publicly available - on the web or drop me a line if you'd like a copy. Summary: In this paper we present experimental results evaluating the performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP proposals in a series of benchmark tests. We find that many recent proposals perform surprisingly poorly in even the most simple test, namely achieving fairness between two competing flows in a dumbbell topology with the same round-trip times and shared bottleneck link. Specifically, both Scalable-TCP and FAST TCP exhibit very substantial unfairness in this test. We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly greater RTT unfairness between competing flows with different round-trip times. The unfairness can be an order of magnitude greater than that with standard TCP and is such that flows with longer round-trip times can be completely starved of bandwidth. While the TCP proposals studied are all successful at improving the link utilisation in a relatively static environment with long-lived flows, in our tests many of the proposals exhibit poor responsiveness to changing network conditions. We observe that Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely slow (>100s) convergence times following the startup of a new flow. We also observe that while FAST-TCP flows typically converge quickly initially, flows may later diverge again to create significant and sustained unfairness. --Doug Hamilton Institute www.hamilton.ie From ian.mcdonald at jandi.co.nz Fri Sep 22 10:42:59 2006 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Sat, 23 Sep 2006 05:42:59 +1200 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <4513F1A1.3000506@nuim.ie> References: <4513F1A1.3000506@nuim.ie> Message-ID: <5640c7e00609221042w5122c37cm7db3013e21e3b5dc@mail.gmail.com> On 9/23/06, Douglas Leith wrote: > For those interested in TCP for high-speed environments, and perhaps > also people interested in TCP evaluation generally, I'd like to point > you towards the results of a detailed experimental study which are now > available at: > > http://www.hamilton.ie/net/eval/ToNfinal.pdf > > This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP > and H-TCP performance under a wide range of conditions including with > mixes of long and short-lived flows. This study has now been subject to > peer review (to hopefully give it some legitimacy) and is due to appear > in the Transactions on Networking. > > The conclusions (see summary below) seem especially topical as BIC-TCP > is currently widely deployed as the default algorithm in Linux. > > Comments appreciated. Our measurements are publicly available - on the > web or drop me a line if you'd like a copy. > > Summary: > In this paper we present experimental results evaluating the > performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and > H-TCP proposals in a series of benchmark tests. > > We find that many recent proposals perform surprisingly poorly in > even the most simple test, namely achieving fairness between two > competing flows in a dumbbell topology with the same round-trip > times and shared bottleneck link. Specifically, both Scalable-TCP > and FAST TCP exhibit very substantial unfairness in this test. > > We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly > greater RTT unfairness between competing flows with different round-trip > times. The unfairness can be an order of magnitude greater than that > with standard TCP and is such that flows with longer round-trip times > can be completely starved of bandwidth. > > While the TCP proposals studied are all successful at improving > the link utilisation in a relatively static environment with > long-lived flows, in our tests many of the proposals exhibit poor > responsiveness to changing network conditions. We observe that > Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely > slow (>100s) convergence times following the startup of a new > flow. We also observe that while FAST-TCP flows typically converge > quickly initially, flows may later diverge again to create > significant and sustained unfairness. > > --Doug > > Hamilton Institute > www.hamilton.ie > > > Interesting reading and I am replying to netdev at vger.kernel.org as well. I will read in more detail later but my first questions/comments are: - have you tested CUBIC subsequently as this is meant to fix many of the rtt issues? This is becoming the default in 2.6.19 probably. - have you tested subsequently on more recent kernels than 2.6.6? Looks like some very useful information. Regards, Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand From doug.leith at nuim.ie Fri Sep 22 12:38:07 2006 From: doug.leith at nuim.ie (Douglas Leith) Date: Fri, 22 Sep 2006 20:38:07 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <5640c7e00609221042w5122c37cm7db3013e21e3b5dc@mail.gmail.com> References: <4513F1A1.3000506@nuim.ie> <5640c7e00609221042w5122c37cm7db3013e21e3b5dc@mail.gmail.com> Message-ID: <45143B9F.9080000@nuim.ie> Ian McDonald wrote: > On 9/23/06, Douglas Leith wrote: >> For those interested in TCP for high-speed environments, and perhaps >> also people interested in TCP evaluation generally, I'd like to point >> you towards the results of a detailed experimental study which are now >> available at: >> >> http://www.hamilton.ie/net/eval/ToNfinal.pdf >> >> This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP >> and H-TCP performance under a wide range of conditions including with >> mixes of long and short-lived flows. This study has now been subject to >> peer review (to hopefully give it some legitimacy) and is due to appear >> in the Transactions on Networking. >> >> The conclusions (see summary below) seem especially topical as BIC-TCP >> is currently widely deployed as the default algorithm in Linux. >> >> Comments appreciated. Our measurements are publicly available - on the >> web or drop me a line if you'd like a copy. >> >> Summary: >> In this paper we present experimental results evaluating the >> performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and >> H-TCP proposals in a series of benchmark tests. >> >> We find that many recent proposals perform surprisingly poorly in >> even the most simple test, namely achieving fairness between two >> competing flows in a dumbbell topology with the same round-trip >> times and shared bottleneck link. Specifically, both Scalable-TCP >> and FAST TCP exhibit very substantial unfairness in this test. >> >> We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly >> greater RTT unfairness between competing flows with different round-trip >> times. The unfairness can be an order of magnitude greater than that >> with standard TCP and is such that flows with longer round-trip times >> can be completely starved of bandwidth. >> >> While the TCP proposals studied are all successful at improving >> the link utilisation in a relatively static environment with >> long-lived flows, in our tests many of the proposals exhibit poor >> responsiveness to changing network conditions. We observe that >> Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely >> slow (>100s) convergence times following the startup of a new >> flow. We also observe that while FAST-TCP flows typically converge >> quickly initially, flows may later diverge again to create >> significant and sustained unfairness. >> >> --Doug >> >> Hamilton Institute >> www.hamilton.ie >> >> >> > Interesting reading and I am replying to netdev at vger.kernel.org as > well. I will read in more detail later but my first questions/comments > are: > - have you tested CUBIC subsequently as this is meant to fix many of > the rtt issues? This is becoming the default in 2.6.19 probably. > - have you tested subsequently on more recent kernels than 2.6.6? > > Looks like some very useful information. > > Regards, > > Ian Ian, We haven't tested cubic yet. Inevitably there's a delay in running tests, getting them properly reviewed (essential for credibility I think when results can be controversial) etc and so there are quite a few proposed algorithms that are post out tests and so not covered, including cubic. I think this certainly motivates further rounds of testing. We have tested later kernels, but we found the results are much the same as with the 2.6.6 kernel used (which included sack processing patches etc that have now largely been incorporated into later kernels). I wasn't aware of the planned move to cubic in Linux. Can I ask the rationale for this ? Cubic is, of course, closely related to HTCP (borrowing the HTCP idea of using elapsed time since last backoff as the quantity used to adjust the cwnd increase rate) which *is* tested in the reported study. I'd be more than happy to run tests on cubic and I reckon we should do this sooner rather than later now that you have flagged up plans to rollout cubic. Doug Hamilton Institute www.hamilton.ie From ian.mcdonald at jandi.co.nz Fri Sep 22 13:04:48 2006 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Sat, 23 Sep 2006 08:04:48 +1200 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <45143B9F.9080000@nuim.ie> References: <4513F1A1.3000506@nuim.ie> <5640c7e00609221042w5122c37cm7db3013e21e3b5dc@mail.gmail.com> <45143B9F.9080000@nuim.ie> Message-ID: <5640c7e00609221304h78689765kd63d2bc2e985d42e@mail.gmail.com> > I wasn't aware of the planned move to cubic in Linux. Can I ask the > rationale for this ? Cubic is, of course, closely related to HTCP > (borrowing the HTCP idea of using elapsed time since last backoff as the > quantity used to adjust the cwnd increase rate) which *is* tested in the > reported study. I'd be more than happy to run tests on cubic and I > reckon we should do this sooner rather than later now that you have > flagged up plans to rollout cubic. > As I understand it, it is because Cubic is better than bic for differing rtts and bic is the current default. Stephen might like to add to it. More tests are always good! Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand From francis at cs.cornell.edu Fri Sep 22 13:09:42 2006 From: francis at cs.cornell.edu (Paul Francis) Date: Fri, 22 Sep 2006 16:09:42 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <4513F1A1.3000506@nuim.ie> Message-ID: Any reason XCP not included in this? PF -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Douglas Leith Sent: Friday, September 22, 2006 10:22 AM To: end2end-interest at postel.org Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc For those interested in TCP for high-speed environments, and perhaps also people interested in TCP evaluation generally, I'd like to point you towards the results of a detailed experimental study which are now available at: http://www.hamilton.ie/net/eval/ToNfinal.pdf This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP performance under a wide range of conditions including with mixes of long and short-lived flows. This study has now been subject to peer review (to hopefully give it some legitimacy) and is due to appear in the Transactions on Networking. The conclusions (see summary below) seem especially topical as BIC-TCP is currently widely deployed as the default algorithm in Linux. Comments appreciated. Our measurements are publicly available - on the web or drop me a line if you'd like a copy. Summary: In this paper we present experimental results evaluating the performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP proposals in a series of benchmark tests. We find that many recent proposals perform surprisingly poorly in even the most simple test, namely achieving fairness between two competing flows in a dumbbell topology with the same round-trip times and shared bottleneck link. Specifically, both Scalable-TCP and FAST TCP exhibit very substantial unfairness in this test. We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly greater RTT unfairness between competing flows with different round-trip times. The unfairness can be an order of magnitude greater than that with standard TCP and is such that flows with longer round-trip times can be completely starved of bandwidth. While the TCP proposals studied are all successful at improving the link utilisation in a relatively static environment with long-lived flows, in our tests many of the proposals exhibit poor responsiveness to changing network conditions. We observe that Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely slow (>100s) convergence times following the startup of a new flow. We also observe that while FAST-TCP flows typically converge quickly initially, flows may later diverge again to create significant and sustained unfairness. --Doug Hamilton Institute www.hamilton.ie From doug.leith at nuim.ie Fri Sep 22 13:29:27 2006 From: doug.leith at nuim.ie (Douglas Leith) Date: Fri, 22 Sep 2006 21:29:27 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: References: Message-ID: <451447A7.1000601@nuim.ie> Paul, Inevitably, these tests are a snapshot of sorts and things can move on while things get written up and the review process takes place. Its not great, but seems hard to avoid. The BIC folks for example have also developed Cubic that may address some of the issues flagged up, but this was post our tests and so isn't included. I think the lesson here is that tests really need to be ongoing as protocols develop. That said, XCP is perhaps at a different stage of development from other algorithms we've studied (all of which are possible candidates for rollout in the immediate future) as it seems to require router changes as well as end-host changes, and to my knowledge XCP support in production routers is not available yet. I'm all for including it in future tests however. Doug Paul Francis wrote: > Any reason XCP not included in this? > > PF > > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of Douglas Leith > Sent: Friday, September 22, 2006 10:22 AM > To: end2end-interest at postel.org > Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc > > For those interested in TCP for high-speed environments, and perhaps also > people interested in TCP evaluation generally, I'd like to point you towards > the results of a detailed experimental study which are now available at: > > http://www.hamilton.ie/net/eval/ToNfinal.pdf > > This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and > H-TCP performance under a wide range of conditions including with mixes of > long and short-lived flows. This study has now been subject to peer review > (to hopefully give it some legitimacy) and is due to appear in the > Transactions on Networking. > > The conclusions (see summary below) seem especially topical as BIC-TCP is > currently widely deployed as the default algorithm in Linux. > > Comments appreciated. Our measurements are publicly available - on the web > or drop me a line if you'd like a copy. > > Summary: > In this paper we present experimental results evaluating the performance of > the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP proposals in a series > of benchmark tests. > > We find that many recent proposals perform surprisingly poorly in even the > most simple test, namely achieving fairness between two competing flows in a > dumbbell topology with the same round-trip times and shared bottleneck link. > Specifically, both Scalable-TCP and FAST TCP exhibit very substantial > unfairness in this test. > > We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly > greater RTT unfairness between competing flows with different round-trip > times. The unfairness can be an order of magnitude greater than that with > standard TCP and is such that flows with longer round-trip times can be > completely starved of bandwidth. > > While the TCP proposals studied are all successful at improving the link > utilisation in a relatively static environment with long-lived flows, in our > tests many of the proposals exhibit poor responsiveness to changing network > conditions. We observe that Scalable-TCP, HS-TCP and BIC-TCP can all suffer > from extremely slow (>100s) convergence times following the startup of a new > flow. We also observe that while FAST-TCP flows typically converge quickly > initially, flows may later diverge again to create significant and sustained > unfairness. > > --Doug > > Hamilton Institute > www.hamilton.ie > > From francis at cs.cornell.edu Fri Sep 22 15:23:13 2006 From: francis at cs.cornell.edu (Paul Francis) Date: Fri, 22 Sep 2006 18:23:13 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: Message-ID: Sure, but nevertheless it is interesting to compare them. I mean, what if we find out that fasttcp is just or nearly just as good as XCP. This tells us not to even bother looking at XCP cause of the deployment cost. If on the other hand explicit signaling approaches are generally way better, then one can think about environments where one might deploy them (i.e. VPN scenarios...). Fred's point that one *can't* measure XCP over the internet is certainly a good one..... PF -----Original Message----- From: Lachlan Andrew [mailto:lachlan.andrew at gmail.com] Sent: Friday, September 22, 2006 5:26 PM To: Paul Francis Cc: Douglas Leith; end2end-interest at postel.org Subject: Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc Greetings Paul, I can't speak for the Hamilton team, but I think the reason is that, like MaxNet, RCP, JetMax and a host of other proposals, XCP uses explicit signalling from the routers. They can't be fairly compared with sender-side-only solutions like the others, because they uses extra information they don't have, and thay can't be generally implemented until enough routers on the internet are upgraded to give that information. Cheers, Lachlan On 22/09/06, Paul Francis wrote: > > Any reason XCP not included in this? > > PF -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From L.Wood at surrey.ac.uk Fri Sep 22 15:35:00 2006 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Fri, 22 Sep 2006 23:35:00 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316A7E@EVS-EC1-NODE1.surrey.ac.uk> Paul Francis wrote on Fri 2006-09-22 21:09 > Any reason XCP not included in this? because XCP has morphed so many times no-one knows what it is anymore. XCP is no longer a clearly-defined algorithm -- it's now a brand name. L. -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Douglas Leith Sent: Friday, September 22, 2006 10:22 AM To: end2end-interest at postel.org Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc For those interested in TCP for high-speed environments, and perhaps also people interested in TCP evaluation generally, I'd like to point you towards the results of a detailed experimental study which are now available at: http://www.hamilton.ie/net/eval/ToNfinal.pdf This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP performance under a wide range of conditions including with mixes of long and short-lived flows. This study has now been subject to peer review (to hopefully give it some legitimacy) and is due to appear in the Transactions on Networking. The conclusions (see summary below) seem especially topical as BIC-TCP is currently widely deployed as the default algorithm in Linux. Comments appreciated. Our measurements are publicly available - on the web or drop me a line if you'd like a copy. Summary: In this paper we present experimental results evaluating the performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP proposals in a series of benchmark tests. We find that many recent proposals perform surprisingly poorly in even the most simple test, namely achieving fairness between two competing flows in a dumbbell topology with the same round-trip times and shared bottleneck link. Specifically, both Scalable-TCP and FAST TCP exhibit very substantial unfairness in this test. We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly greater RTT unfairness between competing flows with different round-trip times. The unfairness can be an order of magnitude greater than that with standard TCP and is such that flows with longer round-trip times can be completely starved of bandwidth. While the TCP proposals studied are all successful at improving the link utilisation in a relatively static environment with long-lived flows, in our tests many of the proposals exhibit poor responsiveness to changing network conditions. We observe that Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely slow (>100s) convergence times following the startup of a new flow. We also observe that while FAST-TCP flows typically converge quickly initially, flows may later diverge again to create significant and sustained unfairness. --Doug Hamilton Institute www.hamilton.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060922/844a718c/attachment-0001.html From rhee at eos.ncsu.edu Fri Sep 22 18:45:26 2006 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Fri, 22 Sep 2006 21:45:26 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <4513F1A1.3000506@nuim.ie> References: <4513F1A1.3000506@nuim.ie> Message-ID: <9dbabe09ba99fc423f5f33f51f7fff02@eos.ncsu.edu> Hi Doug, Thanks for sharing your paper. Also congratulations to the acceptance of your journal paper to TONs. But I am wondering what's new in this paper. At first glance, I did not find many new things that are different from your previously publicized reports. How much is this different from the ones you put out in this mail list a year or two ago and also the one publicized in PFLDnet February this year http://www.hpcc.jp/pfldnet2006/? In that same workshop, we also presented our experimental results that shows significant discrepancy from yours but i am not sure why you forgot to reference our experimental work presented in that same PFLDnet. Here is a link to a more detailed version of that report accepted to COMNET http://netsrv.csc.ncsu.edu/highspeed/comnet-asteppaper.pdf The main point of contention [that we talked about in that PFLDnet workshop] is the presence of background traffic and the method to add them. Your report mostly ignores the effect of background traffic. Some texts in this paper state that you added some web traffic (10%), but the paper shows only the results from NO background traffic scenarios. But our results differ from yours in many aspects. Below are the links to our results (the links to them have been available in our BIC web site for a long time and also mentioned in our PFLDnet paper; this result is with the patch that corrects HTCP bugs). [Convergence and intra protocol fairness] without background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/intra_protocol/ intra_protocol.htm with background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/bk/intra_protocol/ intra_protocol.htm [RTT fairness]: w/o background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/rtt_fairness/ rtt_fairness.htm with background traffic:http://netsrv.csc.ncsu.edu/highspeed/1200/bk/rtt_fairness/ rtt_fairness.htm [TCP friendliness] without background traffic:http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/ tcp_friendliness/tcp_friendliness.htm with background traffic:http://netsrv.csc.ncsu.edu/highspeed/1200/bk/tcp_friendliness/ tcp_friendliness.htm After our discussion in that PFLDnet, I puzzled why we get different results. My guess is that the main difference between your experiment and ours is the inclusion of mid-sized flows with various RTTs -- our experience tells that the RTT variations of mid size flows play a very important role in creating significant dynamics in testing environments. The same point about the importance of mid size flows with RTT variations has been raised in several occasions by Sally Floyd as well, including in this year's E2E research group meeting. You can find some reference to the importance of RTT variations in her paper too [http://www.icir.org/models/hotnetsFinal.pdf ]. Just having web-traffic (all with the same RTTs) does not create a realistic environment as it does not do anything about RTTs and also flow sizes tend to be highly skewed with the Pareto distribution-- but I don't know exactly how you create your testing environment with web-traffic -- I can only guess from the description you have about the web traffic in your paper. Another puzzle in this difference seems that even under no background traffic, we also get different results from yours..hmm...especially with FAST because under no background traffic, FAST seems to work fairly well with good RTT fairness in our experiment. But your results show FAST has huge RTT-unfairness. That is very strange. Is that because we have different bandwidth and buffer sizes in the setup? I think we need to compare our notes more. Also in the journal paper of FAST experimental results [http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf ], FAST seems to work very well under no background traffic. We will verify our results again in the exact same environment as you have in your report, to make sure we can reproduce your results....but here are some samples of our results for FAST. http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/rtt_fairness/1200- -2.4_FAST-2.4_FAST-NONE--400-3-1333--1000-76-3-0-0-0-5-500--200000-0.6 -1000-10-1200-64000-150--1/ In this experiment, FAST flows are just perfect. Also the same result is confirmed inthe FAST journal paper [http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf -- please look at Section IV.B and C. But your results show really bad RTT fairness.] Best regards, Injong --- Injong Rhee NCSU On Sep 22, 2006, at 10:22 AM, Douglas Leith wrote: > For those interested in TCP for high-speed environments, and perhaps > also people interested in TCP evaluation generally, I'd like to point > you towards the results of a detailed experimental study which are now > available at: > > http://www.hamilton.ie/net/eval/ToNfinal.pdf > > This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, > FAST-TCP and H-TCP performance under a wide range of conditions > including with mixes of long and short-lived flows. This study has > now been subject to peer review (to hopefully give it some legitimacy) > and is due to appear in the Transactions on Networking. > > The conclusions (see summary below) seem especially topical as BIC-TCP > is currently widely deployed as the default algorithm in Linux. > > Comments appreciated. Our measurements are publicly available - on > the web or drop me a line if you'd like a copy. > > Summary: > In this paper we present experimental results evaluating the > performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and > H-TCP proposals in a series of benchmark tests. > > We find that many recent proposals perform surprisingly poorly in > even the most simple test, namely achieving fairness between two > competing flows in a dumbbell topology with the same round-trip > times and shared bottleneck link. Specifically, both Scalable-TCP > and FAST TCP exhibit very substantial unfairness in this test. > > We also find that Scalable-TCP, HS-TCP and BIC-TCP induce > significantly greater RTT unfairness between competing flows with > different round-trip times. The unfairness can be an order of > magnitude greater than that with standard TCP and is such that flows > with longer round-trip times > can be completely starved of bandwidth. > > While the TCP proposals studied are all successful at improving > the link utilisation in a relatively static environment with > long-lived flows, in our tests many of the proposals exhibit poor > responsiveness to changing network conditions. We observe that > Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely > slow (>100s) convergence times following the startup of a new > flow. We also observe that while FAST-TCP flows typically converge > quickly initially, flows may later diverge again to create > significant and sustained unfairness. > > --Doug > > Hamilton Institute > www.hamilton.ie > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 7407 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060922/c33b87a2/attachment.bin From rhee at eos.ncsu.edu Fri Sep 22 19:34:08 2006 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Fri, 22 Sep 2006 22:34:08 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc Message-ID: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> This is a resend with fixed web links. The links were broken in my previous email -- sorry about multiple transmissions. --------------------------------------------------------------------------------- Hi Doug, Thanks for sharing your paper. Also congratulations to the acceptance of your journal paper to TONs. But I am wondering what's new in this paper. At first glance, I did not find many new things that are different from your previously publicized reports. How much is this different from the ones you put out in this mail list a year or two ago and also the one publicized in PFLDnet February this year http://www.hpcc.jp/pfldnet2006/? In that same workshop, we also presented our experimental results that shows significant discrepancy from yours but i am not sure why you forgot to reference our experimental work presented in that same PFLDnet. Here is a link to a more detailed version of that report accepted to COMNET http://netsrv.csc.ncsu.edu/highspeed/comnet-asteppaper.pdf The main point of contention [that we talked about in that PFLDnet workshop] is the presence of background traffic and the method to add them. Your report mostly ignores the effect of background traffic. Some texts in this paper state that you added some web traffic (10%), but the paper shows only the results from NO background traffic scenarios. But our results differ from yours in many aspects. Below are the links to our results (the links to them have been available in our BIC web site for a long time and also mentioned in our PFLDnet paper; this result is with the patch that corrects HTCP bugs). [Convergence and intra protocol fairness] without background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/intra_protocol/intra_protocol.htm with background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/bk/intra_protocol/intra_protocol.htm [RTT fairness]: w/o background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/rtt_fairness/rtt_fairness.htm with background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/bk/rtt_fairness/rtt_fairness.htm [TCP friendliness] without background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/tcp_friendliness/tcp_friendliness.htm with background traffic: http://netsrv.csc.ncsu.edu/highspeed/1200/bk/tcp_friendliness/tcp_friendliness.htm After our discussion in that PFLDnet, I puzzled why we get different results. My guess is that the main difference between your experiment and ours is the inclusion of mid-sized flows with various RTTs -- our experience tells that the RTT variations of mid size flows play a very important role in creating significant dynamics in testing environments. The same point about the importance of mid size flows with RTT variations has been raised in several occasions by Sally Floyd as well, including in this year's E2E research group meeting. You can find some reference to the importance of RTT variations in her paper too [ http://www.icir.org/models/hotnetsFinal.pdf]. Just having web-traffic (all with the same RTTs) does not create a realistic environment as it does not do anything about RTTs and also flow sizes tend to be highly skewed with the Pareto distribution-- but I don't know exactly how you create your testing environment with web-traffic -- I can only guess from the description you have about the web traffic in your paper. Another puzzle in this difference seems that even under no background traffic, we also get different results from yours..hmm...especially with FAST because under no background traffic, FAST seems to work fairly well with good RTT fairness in our experiment. But your results show FAST has huge RTT-unfairness. That is very strange. Is that because we have different bandwidth and buffer sizes in the setup? I think we need to compare our notes more. Also in the journal paper of FAST experimental results [ http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf ], FAST seems to work very well under no background traffic. We will verify our results again in the exact same environment as you have in your report, to make sure we can reproduce your results....but here are some samples of our results for FAST. http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/rtt_fairness/1200--2.4_FAST-2.4_FAST-NONE--400-3-1333--1000-76-3-0-0-0-5-500--200000-0.6-1000-10-1200-64000-150--1/ In this experiment, FAST flows are just perfect. Also the same result is confirmed inthe FAST journal paper [ http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf-- please look at Section IV.B and C. But your results show really bad RTT fairness.] Best regards, Injong --- Injong Rhee NCSU On Sep 22, 2006, at 10:22 AM, Douglas Leith wrote: For those interested in TCP for high-speed environments, and perhaps also people interested in TCP evaluation generally, I'd like to point you towards the results of a detailed experimental study which are now available at: http://www.hamilton.ie/net/eval/ToNfinal.pdf This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP performance under a wide range of conditions including with mixes of long and short-lived flows. This study has now been subject to peer review (to hopefully give it some legitimacy) and is due to appear in the Transactions on Networking. The conclusions (see summary below) seem especially topical as BIC-TCP is currently widely deployed as the default algorithm in Linux. Comments appreciated. Our measurements are publicly available - on the web or drop me a line if you'd like a copy. Summary: In this paper we present experimental results evaluating the performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and H-TCP proposals in a series of benchmark tests. We find that many recent proposals perform surprisingly poorly in even the most simple test, namely achieving fairness between two competing flows in a dumbbell topology with the same round-trip times and shared bottleneck link. Specifically, both Scalable-TCP and FAST TCP exhibit very substantial unfairness in this test. We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly greater RTT unfairness between competing flows with different round-trip times. The unfairness can be an order of magnitude greater than that with standard TCP and is such that flows with longer round-trip times can be completely starved of bandwidth. While the TCP proposals studied are all successful at improving the link utilisation in a relatively static environment with long-lived flows, in our tests many of the proposals exhibit poor responsiveness to changing network conditions. We observe that Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely slow (>100s) convergence times following the startup of a new flow. We also observe that while FAST-TCP flows typically converge quickly initially, flows may later diverge again to create significant and sustained unfairness. --Doug Hamilton Institute www.hamilton.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060922/75c36169/attachment-0001.html From doug.leith at nuim.ie Fri Sep 22 23:34:56 2006 From: doug.leith at nuim.ie (Douglas Leith) Date: Sat, 23 Sep 2006 07:34:56 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> Message-ID: <4514D590.9010201@nuim.ie> I suggest you take a closer look Injong - there is a whole page of data from tests covering a wide range of levels of background traffic. These results are all new, and significantly strengthen the conclusions I think, as is the expanded explanatory discussion of the observed behaviour of the various algorithms (the result of a fair bit of detective work of course). Your claim that "Your report mostly ignores the effect of background traffic" is simply not true. I can't really comment on your own tests without more information, although I can say that we went to a good bit of trouble to make sure our results were consistent and reproducible - in fact all our reported results are from at least five, and usually more, runs of each test. We were also careful to control for differences in kernel implementation so that we compare congestion control algorithms rather than other aspects of the network stack implementation. All of this is documented in the paper. The kernel we used is available on the web. Our measurements are also publicly available - the best way forward might be to pick one or two tests and compare results of them in detail with a view to diagnosing the source of any differences. General comments such as "our experience tells that the RTT variations of mid size flows play a very important role in creating significant dynamics in testing environments" are not too helpful. What do you mean by a "mid-sized flow" ? What do you mean by "significant dynamics" ? What do you mean by "important role" - is this quantified ? Best to stick to science rather than grandstanding. This is especially true when dealing with a sensitive subject such as the evaluation of competing algorithms. Re FAST, we have of course discussed our results with the Caltech folks. As stated in the paper, some of the observed behaviour seems to be associated with the alpha tuning algorithm. Other behaviour seems to be associated with packet burst effects that have also been reported independently by the Caltech folks. Similar results to ours have since been observed by other groups I believe. Perhaps differences between our results point to some issue in your testbed setup. Doug Injong Rhee wrote: > > > This is a resend with fixed web links. The links were broken in my > previous email -- sorry about multiple transmissions. > > --------------------------------------------------------------------------------- > > > Hi Doug, > > Thanks for sharing your paper. Also congratulations to the acceptance of > your journal paper to TONs. But I am wondering what's new in this paper. > At first glance, I did not find many new things that are different from > your previously publicized reports. How much is this different from the > ones you put out in this mail list a year or two ago and also the one > publicized in PFLDnet February this year > http://www.hpcc.jp/pfldnet2006/? In that same workshop, we also > presented our experimental results that shows significant discrepancy > from yours but i am not sure why you forgot to reference our > experimental work presented in that same PFLDnet. Here is a link to a > more detailed version of that report accepted to COMNET > http://netsrv.csc.ncsu.edu/highspeed/comnet-asteppaper.pdf > > The main point of contention [that we talked about in that PFLDnet > workshop] is the presence of background traffic and the method to add > them. Your report mostly ignores the effect of background traffic. Some > texts in this paper state that you added some web traffic (10%), but the > paper shows only the results from NO background traffic scenarios. But > our results differ from yours in many aspects. Below are the links to > our results (the links to them have been available in our BIC web site > for a long time and also mentioned in our PFLDnet paper; this result is > with the patch that corrects HTCP bugs). > > [Convergence and intra protocol fairness] > > without background traffic: > http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/intra_protocol/intra_protocol.htm > > > with background traffic: > http://netsrv.csc.ncsu.edu/highspeed/1200/bk/intra_protocol/intra_protocol.htm > > > [RTT fairness]: > > w/o background traffic: > http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/rtt_fairness/rtt_fairness.htm > > > with background traffic: > http://netsrv.csc.ncsu.edu/highspeed/1200/bk/rtt_fairness/rtt_fairness.htm > > [TCP friendliness] > > without background traffic: > http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/tcp_friendliness/tcp_friendliness.htm > > > with background traffic: > http://netsrv.csc.ncsu.edu/highspeed/1200/bk/tcp_friendliness/tcp_friendliness.htm > > > After our discussion in that PFLDnet, I puzzled why we get different > results. My guess is that the main difference between your experiment > and ours is the inclusion of mid-sized flows with various RTTs -- our > experience tells that the RTT variations of mid size flows play a very > important role in creating significant dynamics in testing environments. > The same point about the importance of mid size flows with RTT > variations has been raised in several occasions by Sally Floyd as well, > including in this year's E2E research group meeting. You can find some > reference to the importance of RTT variations in her paper too [ > http://www.icir.org/models/hotnetsFinal.pdf]. Just having web-traffic > (all with the same RTTs) does not create a realistic environment as it > does not do anything about RTTs and also flow sizes tend to be highly > skewed with the Pareto distribution-- but I don't know exactly how you > create your testing environment with web-traffic -- I can only guess > from the description you have about the web traffic in your paper. > > Another puzzle in this difference seems that even under no background > traffic, we also get different results from yours..hmm...especially with > FAST because under no background traffic, FAST seems to work fairly well > with good RTT fairness in our experiment. But your results show FAST has > huge RTT-unfairness. That is very strange. Is that because we have > different bandwidth and buffer sizes in the setup? I think we need to > compare our notes more. Also in the journal paper of FAST experimental > results [ > http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf ], > FAST seems to work very well under no background traffic. We will verify > our results again in the exact same environment as you have in your > report, to make sure we can reproduce your results....but here are some > samples of our results for FAST. > > http://netsrv.csc.ncsu.edu/highspeed/1200/nobk/rtt_fairness/1200--2.4_FAST-2.4_FAST-NONE--400-3-1333--1000-76-3-0-0-0-5-500--200000-0.6-1000-10-1200-64000-150--1/ > > > In this experiment, FAST flows are just perfect. Also the same result is > confirmed inthe FAST journal paper [ > http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf -- > please look at Section IV.B and C. But your results show really bad RTT > fairness.] > > Best regards, > > Injong > > --- > > Injong Rhee > > NCSU > > On Sep 22, 2006, at 10:22 AM, Douglas Leith wrote: > > For those interested in TCP for high-speed environments, and perhaps > also people interested in TCP evaluation generally, I'd like to point > you towards the results of a detailed experimental study which are now > available at: > > > > http://www.hamilton.ie/net/eval/ToNfinal.pdf > > > > > This study consistently compares Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP > and H-TCP performance under a wide range of conditions including with > mixes of long and short-lived flows. This study has now been subject to > peer review (to hopefully give it some legitimacy) and is due to appear > in the Transactions on Networking. > > > > The conclusions (see summary below) seem especially topical as BIC-TCP > is currently widely deployed as the default algorithm in Linux. > > > > Comments appreciated. Our measurements are publicly available - on the > web or drop me a line if you'd like a copy. > > > > Summary: > > In this paper we present experimental results evaluating the > > performance of the Scalable-TCP, HS-TCP, BIC-TCP, FAST-TCP and > > H-TCP proposals in a series of benchmark tests. > > > > We find that many recent proposals perform surprisingly poorly in > > even the most simple test, namely achieving fairness between two > > competing flows in a dumbbell topology with the same round-trip > > times and shared bottleneck link. Specifically, both Scalable-TCP > > and FAST TCP exhibit very substantial unfairness in this test. > > > > We also find that Scalable-TCP, HS-TCP and BIC-TCP induce significantly > greater RTT unfairness between competing flows with different round-trip > times. The unfairness can be an order of magnitude greater than that > with standard TCP and is such that flows with longer round-trip times > > can be completely starved of bandwidth. > > > > While the TCP proposals studied are all successful at improving > > the link utilisation in a relatively static environment with > > long-lived flows, in our tests many of the proposals exhibit poor > > responsiveness to changing network conditions. We observe that > > Scalable-TCP, HS-TCP and BIC-TCP can all suffer from extremely > > slow (>100s) convergence times following the startup of a new > > flow. We also observe that while FAST-TCP flows typically converge > > quickly initially, flows may later diverge again to create > > significant and sustained unfairness. > > > > --Doug > > > > Hamilton Institute > > www.hamilton.ie > From rhee at ncsu.edu Sat Sep 23 00:45:17 2006 From: rhee at ncsu.edu (rhee@ncsu.edu) Date: Sat, 23 Sep 2006 03:45:17 -0400 (EDT) Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <4514D590.9010201@nuim.ie> References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> <4514D590.9010201@nuim.ie> Message-ID: <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> Doug Leith wrote----- > I suggest you take a closer look Injong - there is a whole page of data > from tests covering a wide range of levels of background traffic. These > results are all new, and significantly strengthen the conclusions I > think, as is the expanded explanatory discussion of the observed > behaviour of the various algorithms (the result of a fair bit of > detective work of course). I was not sure whether this whole new page is good enough to make another public announcement about this paper -- this paper has been publicized by you many times in these mailing lists and also in the workshop. It would have saved us some time if you had just pointed out the new stuff. > > I can't really comment on your own tests without more information, > although I can say that we went to a good bit of trouble to make sure > our results were consistent and reproducible - in fact all our reported > results are from at least five, and usually more, runs of each test. I am not doubting your effort here and I am sure your methods are correct. Just i was pondering why we got different results and try to see if we can come to some understanding on this different results we got. Who knows we together might run into some fundamental research issues regarding testing. Also the "more" information about our own experiment is already given in the paper and also in our web site. If you could tell what specific info you need more, I can provide. Let's put our heads together to solve this mystery of "different results". > > General comments such as "our experience tells that the RTT variations > of mid size flows play a very important role in creating significant > dynamics in testing environments" are not too helpful. What do you mean > by a "mid-sized flow" ? What do you mean by "significant dynamics" ? > What do you mean by "important role" - is this quantified ? Best to > stick to science rather than grandstanding. This is especially true > when dealing with a sensitive subject such as the evaluation of > competing algorithms. I hope you can perhaps enlighten us with this "science". Well..this WAS just email. There wasn't much space to delve into "science" there. So that is why I gave the link to Floyd and Kohler's paper. Sally's paper on this role of RTT variations provides more scientific explanation on this "dynamics". In case you missed it, here is the link again. http://www.icir.org/models/hotnetsFinal.pdf. Please read Section 3.3. Also about mid size flows, I am referring to the flow lifetimes. The mid sized flows cannot be represented well by the Pareto distribution -- the ones that are in the middle of the distribution that heavy tail is not capable of providing with a large number. Since the Pareto distribution (of your web traffic sz) follows the power law, the distribution of flow sizes around the origin (very short-term) is very high while very long-term flows have relatively high probability. So speaking of "science", can you please tell me whether all flows of your web traffic have the same RTTs or not? If you could please point me to the results you have with your web traffic tests instead of simply hand-wavy about the results saying they are just the same (or similar) as the results from your NO background traffic tests, I'd appreciate that very much. > > Re FAST, we have of course discussed our results with the Caltech folks. > As stated in the paper, some of the observed behaviour seems to be > associated with the alpha tuning algorithm. Other behaviour seems to be > associated with packet burst effects that have also been reported > independently by the Caltech folks. Similar results to ours have since > been observed by other groups I believe. Perhaps differences between > our results point to some issue in your testbed setup. That might be the case. Thanks for pointing that out. But it is hard to explain why we got coincidently the same results as the FAST folks. Maybe our and FAST folks' testbeds have "this issue" while yours are completely sound and scientific. But I think it is more to do with the different setups we have regarding buffer sizes and the maximum bandwidth. FAST doesn't adapt very well especially under small buffers because of this alpha tuning. From L.Wood at surrey.ac.uk Sat Sep 23 01:33:21 2006 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Sat, 23 Sep 2006 09:33:21 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316A80@EVS-EC1-NODE1.surrey.ac.uk> Paul Francis said on Fri 2006-09-22 23:23: > Sure, but nevertheless it is interesting to compare them. I mean, what if we > find out that fasttcp is just or nearly just as good as XCP. This tells us > not to even bother looking at XCP cause of the deployment cost. While the Caltech IPR on Fast TCP tells us not to look at Fast TCP because of the deployment cost. http://www.fastsoft.com/fasttcp.html Note that the correct name of the protocol is FastTCP(TM) -- and that in FastSoft's preferred deployment model, you'd have to deploy their PEPs in front of every LAN... not so different from XCP. FastTCP has been out of the running for deployment ever since it was first announced -- with the Caltech IPR shackles mentioned in the slideset. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060923/5542d8fe/attachment.html From doug.leith at nuim.ie Sat Sep 23 02:43:11 2006 From: doug.leith at nuim.ie (Douglas Leith) Date: Sat, 23 Sep 2006 10:43:11 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> <4514D590.9010201@nuim.ie> <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> Message-ID: <451501AF.2040209@nuim.ie> > I was not sure whether this whole new page is good enough to make another > public announcement about this paper At the risk of repeating myself, the page referred to contains the results of approx. 500 new test runs (and we have carried out many more than that which are summarised in the text) and directly addresses the primary concern raised by yourself and others that situations with a mix of connection lengths may lead to significantly different conclusions from tests with only long-lived flows. Our finding is that, for the metrics studied, the mix of flow sizes makes little difference to our conclusions. That, combined with the scrutiny provided by the peer review process, greatly strengthens our conclusions and certainly seems worth reporting. > I am not doubting your effort here and I am sure your methods are correct. > Just i was pondering why we got different results and try to see if we can > come to some understanding on this different results we got. Who knows we > together might run into some fundamental research issues regarding > testing. I'm certainly up for taking a closer look at this. > Sally's paper on this role of RTT variations provides more > scientific explanation on this "dynamics". > In case you missed it, here is the link again. > http://www.icir.org/models/hotnetsFinal.pdf. Please read Section 3.3. Section 3.3 of this paper seems to concern "Active Queue Management: Oscillations". The discussion relates to queue dynamics of RED. How is this relevant ? All of our tests are for drop-tail queues only. > Also about mid size flows, I am referring to the flow lifetimes. The mid > sized flows cannot be represented well by the Pareto distribution -- the > ones that are in the middle of the distribution that heavy tail is not > capable of providing with a large number. Since the Pareto distribution > (of your web traffic sz) follows the power law, the distribution of flow > sizes around the origin (very short-term) is very high while very > long-term flows have relatively high probability. I suspect your answers in the previous point and here just re-emphasise my point. Its not clear for example what actual values of flow lifetime you consider "mid-size" nor what the basis for those values is - there are a huge number of measurement studies on traffic stats and if the aim is to get closer to real link behaviour then it seems sensible to make use of this sort of data. I do agree it might be interesting to see if our test results are sensitive to the connection size distribution used, although I suspect the answer will be that they are largely insensitive - should be easy enough to check though if you'd be kind enough to send me details of the sort of distribution you have in mind. > That might be the case. Thanks for pointing that out. But it is hard to > explain why we got coincidently the same results as the FAST folks. Its hard for me to comment without more information - can you post a link to the results by the FAST folks that you mention ? Perhaps they also might like to comment here ? See also the next comment below ... > But I think it is more to do with the different > setups we have regarding buffer sizes and the maximum bandwidth. FAST > doesn't adapt very well especially under small buffers because of this > alpha tuning. I thought you were suggesting in your last post that you obtained different results for the *same* setup as us ? Some clarity here seems important as otherwise your comments are in danger of just serving to muddy the water. If the network setup is different, then its maybe no surprise if the results are a little different. Our own experience (and a key part of the rationale for our work) underlines the need to carry out tests over a broad range of conditions rather than confining testing to a small number of specific scenarios (e.g. only gigabit speed links or only links with large buffers) - otherwise its hard to get an overall feel for expected behaviour. We did carry out tests for really quite a wide range of network conditions and do already comment, for example, that FAST performance does depend on the buffer size. Doug From detlef.bosau at web.de Sat Sep 23 02:47:00 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 23 Sep 2006 11:47:00 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? Message-ID: <45150294.9000204@web.de> Hi. I wonder, whether packet trains and / or bursts are a problem in TCP. On the one hand, there is much literature that this is the case and much effort is being done on "smoothing" TCP traffic, e.g. AQM and pacing techniques. On the other hand, I frequently see papers where packed trains are created _intendedly_ for measurement purposes or throughput estimation. This seems contradictory to me. So I wonder whether burstiness in TCP, or int the Internet in general, is a problem - or a buzz word. Detlef From craig at aland.bbn.com Sat Sep 23 03:38:53 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Sat, 23 Sep 2006 06:38:53 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: Your message of "Sat, 23 Sep 2006 11:47:00 +0200." <45150294.9000204@web.de> Message-ID: <20060923103853.426C567@aland.bbn.com> Hi Detlef: Here's my simple-minded answer. Small packet trains (say 4 or 8 segments) are generally short enough they do not cause much trouble in queues, yet are long enough to do a useful (though imperfect) job of throughput estimation. As an example of a TCP implementation that uses bursts to estimate and then spreads the traffic out, see: J. Kulik, R. Coulter, D. Rockwell and C. Partridge, ``Paced TCP for High Delay-Bandwidth Networks,'' IEEE Workshop on Satellite Based Information Systems, Rio de Janeiro, December 1999. At some point, however, burst sizes (or frequency of bursts), becomes a problem. Exactly what size/frequency combinations cause grief has, to my knowledge, not been studied very much. The only paper I can think of is the one at SIGCOMM a few years ago on attacking TCP. Craig From francis at cs.cornell.edu Sat Sep 23 06:06:01 2006 From: francis at cs.cornell.edu (Paul Francis) Date: Sat, 23 Sep 2006 09:06:01 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC20701316A80@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: Hmmmmm. I'm not sure you read the fastsoft.com material very carefully. I looked, and it says in quite a large font "Easy to Deploy". PF ________________________________ From: L.Wood at surrey.ac.uk [mailto:L.Wood at surrey.ac.uk] Sent: Saturday, September 23, 2006 4:33 AM To: Paul Francis; l.andrew at ieee.org Cc: doug.leith at nuim.ie; end2end-interest at postel.org Subject: RE: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc Paul Francis said on Fri 2006-09-22 23:23: > Sure, but nevertheless it is interesting to compare them. I mean, what if we > find out that fasttcp is just or nearly just as good as XCP. This tells us > not to even bother looking at XCP cause of the deployment cost. While the Caltech IPR on Fast TCP tells us not to look at Fast TCP because of the deployment cost. http://www.fastsoft.com/fasttcp.html Note that the correct name of the protocol is FastTCP(TM) -- and that in FastSoft's preferred deployment model, you'd have to deploy their PEPs in front of every LAN... not so different from XCP. FastTCP has been out of the running for deployment ever since it was first announced -- with the Caltech IPR shackles mentioned in the slideset. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060923/0e214be8/attachment.html From francis at cs.cornell.edu Sat Sep 23 06:15:12 2006 From: francis at cs.cornell.edu (Paul Francis) Date: Sat, 23 Sep 2006 09:15:12 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC20701316A80@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: Seriously though... There is another way to view the question of whether fasttcp is out of the running or not. Which is, if FastTCP is commercialized (and by the way the Fastsoft deployment model is a simple and popular one), then it seems that FastTCP is exactly the protocol that you want to be benchmarking against alternatives. PF ________________________________ From: L.Wood at surrey.ac.uk [mailto:L.Wood at surrey.ac.uk] Sent: Saturday, September 23, 2006 4:33 AM To: Paul Francis; l.andrew at ieee.org Cc: doug.leith at nuim.ie; end2end-interest at postel.org Subject: RE: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc Paul Francis said on Fri 2006-09-22 23:23: > Sure, but nevertheless it is interesting to compare them. I mean, what if we > find out that fasttcp is just or nearly just as good as XCP. This tells us > not to even bother looking at XCP cause of the deployment cost. While the Caltech IPR on Fast TCP tells us not to look at Fast TCP because of the deployment cost. http://www.fastsoft.com/fasttcp.html Note that the correct name of the protocol is FastTCP(TM) -- and that in FastSoft's preferred deployment model, you'd have to deploy their PEPs in front of every LAN... not so different from XCP. FastTCP has been out of the running for deployment ever since it was first announced -- with the Caltech IPR shackles mentioned in the slideset. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060923/0d24aad4/attachment.html From fred at cisco.com Fri Sep 22 13:55:50 2006 From: fred at cisco.com (Fred Baker) Date: Fri, 22 Sep 2006 13:55:50 -0700 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: References: Message-ID: On Sep 22, 2006, at 1:09 PM, Paul Francis wrote: > Any reason XCP not included in this? Lack of measurements in the Internet? From ksarac at utdallas.edu Fri Sep 22 23:26:21 2006 From: ksarac at utdallas.edu (Kamil Sarac) Date: Sat, 23 Sep 2006 01:26:21 -0500 Subject: [e2e] ICNP 2006: Final Call for Participation Message-ID: <4514D38D.9050909@utdallas.edu> Dear Colleagues, (This message is sent to multiple lists. Our apologies if you receive multiple copies of it.) Below is the final Call for Participation for ICNP 2006. We have worked especially hard to make ICNP this year affordable with early registration for IEEE Members of $450. With reasonably cheap air tickets available, ICNP 2006 is a great opportunity to see a great program and network with colleagues. ===================================================================== Call For Participation 14th IEEE International Conference on Network Protocols http://www.ieee-icnp.org/2006 Santa Barbara, California, USA November 12-15, 2006 Sponsored by: IEEE (Computer Society), NSF CISE/CNS, HP, Microsoft, University of California--Santa Barbara Important Dates =============== Early Registration and Hotel Block Deadlines: October 13, 2006 Student Travel Award Application Deadline: September 29, 2006 Minority Faculty Travel Award Application Deadline: September 29, 2006 Highlights of ICNP 2006 ======================= * Keynote talk by Dr. Wei Zhao, Division Director of Computer and Network Systems (CNS) at the National Science Foundation, and Senior Associate Vice President for Research at Texas A&M University, "Challenges and Opportunities of IT Education and Research" * Presentations of technical papers in nine sessions + P2P Applications + Network Security + Routing of Wireless Networks + Protocol Design and Routing + Security Issues + Wireless and Sensor Networks + File Sharing and Overlay Networks + BGP and Traffic Engineering + Wireless Networks The details of the full technical program can be viewed at: http://www.ieee-icnp.org/2006/program.html * The Second Workshop on Secure Network Protocols (NPSec). See: http://www.ics.uci.edu/NPSec-06/ * Student work-in-progress poster session. See: http://www.ieee-icnp.org/2006/poster.html ===================================================================== Sincerely, Kamil Sarac ICNP 2006 Publicity Co-chair. From detlef.bosau at web.de Mon Sep 25 07:08:04 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 25 Sep 2006 16:08:04 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <20060923103853.426C567@aland.bbn.com> References: <20060923103853.426C567@aland.bbn.com> Message-ID: <4517E2C4.8040300@web.de> Craig Partridge wrote: > At some point, however, burst sizes (or frequency of bursts), becomes > a problem. Exactly what size/frequency combinations cause grief has, to > my knowledge, not been studied very much. > Hm. Is this really the problem? What, if we knew what size/frequency combinations cause problems? Would we then adapt our protocols? E.g. turn on / off TCP pacing mechanisms? Isn?t it a more fundamental question, wether burstiness may cause grief in a significant number of scenarios, so that it would be useful to avoid burstiness at all? However, what is the exact meaning of "burstiness" then? The more papers I read about pacing, AQM etc., the more I wonder how "Telco-like" the internet shall become. In addition: Do we have actual statistics about the length of a TCP flow? Whenever I read papers on AQM, congestion control etc., I see always the same stuff. NS2 simulations with impressively huge (up to 10) or even giant (up to 100) numbers of flows with greedy sources. In some cases, even the "dynamics" of the network are described with stationary equations which (hopefuly) hold, when all flows lasted at least one week up to the beginning of the calculation ;-) Now, I remember a paper where it was mentioned that 95 % of all TCP flows consist of less then 20 packets. (Spoken more drastically: Are unlikely to leave the initial slowstart and achieve congestion avoidance at all.) In addition, users often initiate TCP flows independently (not in a statistical sense), however there might be many TCP flows initiated at the same time. Perhaps, there are some "evening news effects", i.e. after the evening news on TV, a huge number of people turns on the light in the living room (causing the utilities to fail ;-)) and afterwords use their toilet (causing the water supply to fail ;-)). What I'm curious about is: - is such a bevhaviour annoying? - if so: do our AQM / congestion control / pacing mechanisms really tackle the reasons of burstiness? - _can_ we influence this behaviour at all? (start the evening news on at least 20 TV channels, each with a time offset of five minuts... ;-)) Perhaps its a problem of my understanding and someone could give me a clue. Detlef From craig at aland.bbn.com Mon Sep 25 07:20:37 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 25 Sep 2006 10:20:37 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: Your message of "Mon, 25 Sep 2006 16:08:04 +0200." <4517E2C4.8040300@web.de> Message-ID: <20060925142037.112C067@aland.bbn.com> Hi Detlef: Yes burstiness matters. Some background reading: * Jacobson's original TCP paper. And, if you can find them on-line some of the IETF talks before and after. The early TCP was bursty -- indeed, it retransmitted bursts. The effects were awful. Plenty of operational measurements to prove it. * Jim Kurose had a paper (I think it is Nagarajan/Kurose in INFOCOM '92) that showed that burstiness effects tend to multiply (e.g., burst meets burst in routers) and synchronize. Also, see Jacobson/Floyd on synchronization of periodic routing messages (SIGCOMM '93), where you see self organized bursts destroying a network. * Jacobson sent out notes (not sure if it was ever published) showing that small flows suffered disproportionatly when competing with a big bursty flow. The big flow would end up synchronizing its bursts with the available queueing space in routers, leaving the small flows shut out. So even if most TCP flows are short and small, one cares about burstiness in the big flows as that will affect the short flows (e.g. web download times). What my previous post was trying to point out is that the definition of harmful burstiness is not well understood in this day and age. Network capacity has gotten larger -- than means larger bursts don't cause the same destructiveness they once did. This does not mean we can ignore burstiness (ala the HOTNETs paper that argued naively that we should optimistically transmit). But it does mean there's room for someone who wants to understand whether an evil burst is 8 packets (as it was in the old days) or 8,000. Thanks! Craig From fred at cisco.com Mon Sep 25 07:54:49 2006 From: fred at cisco.com (Fred Baker) Date: Mon, 25 Sep 2006 07:54:49 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <4517E2C4.8040300@web.de> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> Message-ID: On Sep 25, 2006, at 7:08 AM, Detlef Bosau wrote: > Isn?t it a more fundamental question, wether burstiness may cause > grief in a significant number of scenarios, so that it would be > useful to avoid burstiness at all? I think there is a fair bit we can say from mathematics. For example, there is a fairly dramatic difference between the delays experienced in an M/M/1 and an M/D/1 scenario. Queuing delays result from packets sitting in queues, and variability in queue depth results in variability in delay. Increased burstiness increases average delay and average jitter. That said, I will agree with Craig that burstiness in moderation doesn't itself cause major problems in the network. Short sessions, which are as you say very common in web and mail applications, are inherently bursty, and it's hard to imagine them being otherwise when slow-start combined with the fact that they are moving small amounts of data are brought into consideration. Longer sessions also occur in web and mail transactions, and are common in p2p applications, which are now pretty prominent as a traffic source. But when TCP runs in a longer session, I think you will find that burstiness levels out, as the duration of a burst is stretched by the queues of bottlenecks in the path, resulting in a reduction of the rate of the burst as traffic crosses the network, and the Acks come back at a rate less than or equal to the bottleneck rate. I would expect to see ack clocking spread the traffic of a longer TCP session so that it is less bursty. Pacing attacks burstiness. AQM actually doesn't; it attacks average queue depth. There are places where improving TCP burstiness can be of value, such as in the cases where (usually Linux) TCPs decide to send their entire next window in a short period of time it would be nice of they could be convinced to do so at a rate that doesn't exceed cwnd/srtt. Beyond handling extreme cases like that, I'm not convinced it's worth the effort - it sounds like a lot of mechanism solving a problem that I'm not sure actually hurts us all that much. I'm much more interested in TCPs that will handle high loss rates and variable delay (WiFi/WiMax) and long delays over a wide range of speeds, consistently delivering a good approximation of the available bandwidth (there's still a lot of dial in the world, and there are many places that sport fiber end to end) to applications that attempt to use it. From braden at ISI.EDU Mon Sep 25 12:11:05 2006 From: braden at ISI.EDU (Bob Braden) Date: Mon, 25 Sep 2006 12:11:05 -0700 (PDT) Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? Message-ID: <200609251911.MAA24244@gra.isi.edu> *> *> There are places where improving TCP burstiness can be of value, such *> as in the cases where (usually Linux) TCPs decide to send their *> entire next window in a short period of time it would be nice of they *> could be convinced to do so at a rate that doesn't exceed cwnd/srtt. The ability of an OS to do that pacing has traditionally been limited by the coarse-grain software clocks that were available -- i.e., by interrupt overhead. Suppose CPU chip designers listened to the needs of networking people. Could they provide fine-grain hardware clocks that could be easily used by transport protocols for pacing out packets in large windows? Bob Braden From craig at aland.bbn.com Mon Sep 25 12:23:26 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 25 Sep 2006 15:23:26 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: Your message of "Mon, 25 Sep 2006 12:11:05 PDT." <200609251911.MAA24244@gra.isi.edu> Message-ID: <20060925192326.5028B67@aland.bbn.com> Hi Bob: A team I was on showed you could do this a few years ago. I no longer remember all the details (Dennis Rockwell did the hard work with UNIX timers) but it is probably in the paper: J. Kulik, R. Coulter, D. Rockwell and C. Partridge, "Paced TCP for High Delay-Bandwidth Networks," IEEE Workshop on Satellite Based Information Systems, December 1999. Craig In message <200609251911.MAA24244 at gra.isi.edu>, Bob Braden writes: > > > *> > *> There are places where improving TCP burstiness can be of value, such > *> as in the cases where (usually Linux) TCPs decide to send their > *> entire next window in a short period of time it would be nice of they > *> could be convinced to do so at a rate that doesn't exceed cwnd/srtt. > >The ability of an OS to do that pacing has traditionally been limited >by the coarse-grain software clocks that were available -- i.e., by >interrupt overhead. Suppose CPU chip designers listened to the needs >of networking people. Could they provide fine-grain hardware clocks >that could be easily used by transport protocols for pacing out packets >in large windows? > >Bob Braden > From jeroen at unfix.org Mon Sep 25 12:43:47 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 25 Sep 2006 21:43:47 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <200609251911.MAA24244@gra.isi.edu> References: <200609251911.MAA24244@gra.isi.edu> Message-ID: <45183173.8010208@spaghetti.zurich.ibm.com> Bob Braden wrote: > *> > *> There are places where improving TCP burstiness can be of value, such > *> as in the cases where (usually Linux) TCPs decide to send their > *> entire next window in a short period of time it would be nice of they > *> could be convinced to do so at a rate that doesn't exceed cwnd/srtt. > > The ability of an OS to do that pacing has traditionally been limited > by the coarse-grain software clocks that were available -- i.e., by > interrupt overhead. Suppose CPU chip designers listened to the needs > of networking people. Could they provide fine-grain hardware clocks > that could be easily used by transport protocols for pacing out packets > in large windows? You mean like HPET ? http://www.intel.com/hardwaredesign/hpetspec.htm Also partially discussed here: http://newkerneltrap.osuosl.org/node/6750 These should give one quite a good clock for doing things like that. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060925/533d6189/signature.bin From ritesh at cs.unc.edu Mon Sep 25 15:42:35 2006 From: ritesh at cs.unc.edu (Ritesh Kumar) Date: Mon, 25 Sep 2006 18:42:35 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> Message-ID: Hi, The following paper ( http://www.cs.washington.edu/homes/tom/pubs/pacing.html) makes a case against TCP Pacing saying that pacing packets in a given RTT can have adverse effects when TCP tries to infer congestion using its congestion avoidance algorithms. The paper presents many details but the gist is that when TCP is paced, it takes very little time for the bottleneck queue to build up from nothing to the full queue size. So even though lesser queueing is definitely an advantage of TCP pacing, probably it also calls for a redesign of the congestion control algorithms...? Ritesh On 9/25/06, Fred Baker wrote: > > > On Sep 25, 2006, at 7:08 AM, Detlef Bosau wrote: > > > Isn?t it a more fundamental question, wether burstiness may cause > > grief in a significant number of scenarios, so that it would be > > useful to avoid burstiness at all? > > I think there is a fair bit we can say from mathematics. For example, > there is a fairly dramatic difference between the delays experienced > in an M/M/1 and an M/D/1 scenario. Queuing delays result from packets > sitting in queues, and variability in queue depth results in > variability in delay. Increased burstiness increases average delay > and average jitter. > > That said, I will agree with Craig that burstiness in moderation > doesn't itself cause major problems in the network. Short sessions, > which are as you say very common in web and mail applications, are > inherently bursty, and it's hard to imagine them being otherwise when > slow-start combined with the fact that they are moving small amounts > of data are brought into consideration. Longer sessions also occur in > web and mail transactions, and are common in p2p applications, which > are now pretty prominent as a traffic source. But when TCP runs in a > longer session, I think you will find that burstiness levels out, as > the duration of a burst is stretched by the queues of bottlenecks in > the path, resulting in a reduction of the rate of the burst as > traffic crosses the network, and the Acks come back at a rate less > than or equal to the bottleneck rate. I would expect to see ack > clocking spread the traffic of a longer TCP session so that it is > less bursty. > > Pacing attacks burstiness. AQM actually doesn't; it attacks average > queue depth. > > There are places where improving TCP burstiness can be of value, such > as in the cases where (usually Linux) TCPs decide to send their > entire next window in a short period of time it would be nice of they > could be convinced to do so at a rate that doesn't exceed cwnd/srtt. > Beyond handling extreme cases like that, I'm not convinced it's worth > the effort - it sounds like a lot of mechanism solving a problem that > I'm not sure actually hurts us all that much. > > I'm much more interested in TCPs that will handle high loss rates and > variable delay (WiFi/WiMax) and long delays over a wide range of > speeds, consistently delivering a good approximation of the available > bandwidth (there's still a lot of dial in the world, and there are > many places that sport fiber end to end) to applications that attempt > to use it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060925/6fbc524d/attachment.html From ritesh at cs.unc.edu Mon Sep 25 16:35:23 2006 From: ritesh at cs.unc.edu (Ritesh Kumar) Date: Mon, 25 Sep 2006 19:35:23 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> Message-ID: On 9/25/06, Fred Baker wrote: > > > On Sep 25, 2006, at 3:42 PM, Ritesh Kumar wrote: > > > The paper presents many details but the gist is that when TCP is > > paced, it takes very little time for the bottleneck queue to build > > up from nothing to the full queue size. > > actually, I'm not sure that ack clocking that worked perfectly (all > traffic is evenly paced throughout the RTT) or pacing that worked > perfectly would behave much differently in any given RTT. The big > issue with pacing in every RTT is that it is every RTT - you never > step back to being ack clocked and as a result are not responsive to > the millisecond-to-millisecond variations inherent in the network. On the other hand, such millisecond to millisecond variations in the network might not be because of the network but because of some systems specific issues with end systems, delayed acks, queueing at multiple points in the network path etc. It is hard to say that ack clocking really reflects the *network* (and by network I mean the link and its queue) conditions at the millisecond timescale; and that's a different debate altogether :) Your point about perfect ack clocking is also very interesting. I wonder if a certain level of "tweaking" to congestion avoidance is required to work with a certain level of "perfection" achieved in ack clocking. As mentioned in the previous paper, perfectly paced TCP doesn't behave very well compared to "regularly" ack clocked TCP. Who knows how optimal is the behavior of "regularly" ack clocked TCP (given the reno congestion avoidance algorithms) is in the first place? I am sorry if the above paragraph seems a little too vague. Ritesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060925/66fe20fe/attachment.html From weixl at caltech.edu Mon Sep 25 17:02:53 2006 From: weixl at caltech.edu (Xiaoliang (David) Wei) Date: Mon, 25 Sep 2006 17:02:53 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> Message-ID: <006301c6e0ff$1dd52cb0$d22dd783@baybridge> Hi, We have a preliminary study on the effect of pacing when using with Reno or some loss-based highspeed TCPs with DropTail recently. In our study, we partially revisited the Infocom00 paper against pacing by Aggarwal et al (http://www.cs.washington.edu/homes/tom/pubs/pacing.html) pointed by Ritesh. It seems to us that the performance of pacing is quite more complicated. Not sure if our understanding is correct or helpful but here I write a summary with references to some other works, we have a technical note at www.cs.caltech.edu/~weixl/pacing/sync.pdf with more details. Our understanding is that there are at least two levels of burstiness in TCP (or in two timescales). The performance of paced TCP that we observed is the combined effect of these two levels of burstiness. The first level is micro-burst (I borrowed the term from Allman&Blanton's CCR05 paper http://www.icir.org/mallman/papers/burst-mitigate.ps). Such burstiness is in the form of packet trains which are sent back-to-back from the sender which is usually much faster than the bottleneck router. Such burst usually happens during slow-start, or in the presence of ack-compression/stretch acks. And as Fred pointed out, micro-burst leads to higher queue length and jitters but it levels out in long flows by ack-clocking and cross traffics. Micro-burst can also be mitigated by pacing and/or other mechanisms discussed in Allman's paper above. When talking about micro-burst, we are quite sure that pacing helps in reducing queueing delay and jitters with theories such as in Fred's analysis and as shown in Craig's 99paper. The second level is sub-RTT burst (I borrowed the term from Jiang&Dovrolis's SigMetric05 paper http://www-static.cc.gatech.edu/~dovrolis/Papers/f11-dovrolis.pdf). Such bursts are packets sent in a rate no greater than bottleneck capacity (already leveled by ack-clockings) but still sent within a small portion of RTT in a rate higher than its fairshare rate (cwnd/RTT). This happens with multiple flows sharing the same bottleneck. Jiang&Dovrolis's paper showed with packet traces that such bursts exist in Internet traffic (by showing the on-off patterns). Again, pacing attacks such bursts as it paces packets in a rate which equals to the flow's fairshare. On sub-RTT burstiness, we are quite sure that pacing can help in improving the short-term fairness among multiple flows as it ensures that the flows with higher rate will see higher packet loss rate. One observation we had is that: pacing can greatly improve the fairness of HS-TCP and Scalable-TCP, the two TCPs that were said to be unfair in many reports. However, it is not clear if pacing really helps in terms of the flows' aggregate throughput. If the sub-RTT burstiness exists in a flow's packet transmission processes, the flow is less likely to see a packet loss in comparison to the flow which has its packet evenly transmitted into the network (the synchronization effect of pacing). That leads to several observations that also appear in Aggarwal's Infocom00 paper: 1. paced flows might have smaller aggregate throughput as flows are likely to synchronize (but such aggregate throughput loss is bounded by 25% with Reno, and much smaller with high speed tcps). 2. paced flows usually lose to bursty flows in competition since the paced flows are more likely to detect a loss event as their packets are evenly distributed in time. So, it seems to us that there are a lot to understand in the future. The performance of paced TCP/bursty TCP seems to depend on several questions: 1. Is aggregate throughput the most important metric? 2. What is the packet loss pattern in Internet? 3. How does TCP reacts to loss? (Besides Reno, there are many new algorithms) 4. How do we implement and deploy pacing? (Are paced flows going to compete with bursty flows? We can also tune the paced flows to let them compete... Are we using AQM to generate less bursty packet loss? and etc) -David --------------------------------------------------------- Xiaoliang (David) Wei http://davidwei.org Graduate Student, Netlab, Caltech ====================================== ----- Original Message ----- From: Ritesh Kumar To: Fred Baker Cc: Craig Partridge ; end2end-interest at postel.org Sent: Monday, September 25, 2006 3:42 PM Subject: Re: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? Hi, The following paper (http://www.cs.washington.edu/homes/tom/pubs/pacing.html) makes a case against TCP Pacing saying that pacing packets in a given RTT can have adverse effects when TCP tries to infer congestion using its congestion avoidance algorithms. The paper presents many details but the gist is that when TCP is paced, it takes very little time for the bottleneck queue to build up from nothing to the full queue size. So even though lesser queueing is definitely an advantage of TCP pacing, probably it also calls for a redesign of the congestion control algorithms...? Ritesh On 9/25/06, Fred Baker wrote: On Sep 25, 2006, at 7:08 AM, Detlef Bosau wrote: > Isn?t it a more fundamental question, wether burstiness may cause > grief in a significant number of scenarios, so that it would be > useful to avoid burstiness at all? I think there is a fair bit we can say from mathematics. For example, there is a fairly dramatic difference between the delays experienced in an M/M/1 and an M/D/1 scenario. Queuing delays result from packets sitting in queues, and variability in queue depth results in variability in delay. Increased burstiness increases average delay and average jitter. That said, I will agree with Craig that burstiness in moderation doesn't itself cause major problems in the network. Short sessions, which are as you say very common in web and mail applications, are inherently bursty, and it's hard to imagine them being otherwise when slow-start combined with the fact that they are moving small amounts of data are brought into consideration. Longer sessions also occur in web and mail transactions, and are common in p2p applications, which are now pretty prominent as a traffic source. But when TCP runs in a longer session, I think you will find that burstiness levels out, as the duration of a burst is stretched by the queues of bottlenecks in the path, resulting in a reduction of the rate of the burst as traffic crosses the network, and the Acks come back at a rate less than or equal to the bottleneck rate. I would expect to see ack clocking spread the traffic of a longer TCP session so that it is less bursty. Pacing attacks burstiness. AQM actually doesn't; it attacks average queue depth. There are places where improving TCP burstiness can be of value, such as in the cases where (usually Linux) TCPs decide to send their entire next window in a short period of time it would be nice of they could be convinced to do so at a rate that doesn't exceed cwnd/srtt. Beyond handling extreme cases like that, I'm not convinced it's worth the effort - it sounds like a lot of mechanism solving a problem that I'm not sure actually hurts us all that much. I'm much more interested in TCPs that will handle high loss rates and variable delay (WiFi/WiMax) and long delays over a wide range of speeds, consistently delivering a good approximation of the available bandwidth (there's still a lot of dial in the world, and there are many places that sport fiber end to end) to applications that attempt to use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060925/3302c1cb/attachment-0001.html From perfgeek at mac.com Mon Sep 25 18:45:00 2006 From: perfgeek at mac.com (rick jones) Date: Mon, 25 Sep 2006 18:45:00 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <20060925142037.112C067@aland.bbn.com> References: <20060925142037.112C067@aland.bbn.com> Message-ID: <8f884bb031b3678c4b56874456ec25aa@mac.com> On Sep 25, 2006, at 7:20 AM, Craig Partridge wrote: > > Hi Detlef: > > Yes burstiness matters. > > Some background reading: > > * Jacobson's original TCP paper. And, if you can find them on-line > some of the IETF talks before and after. The early TCP was > bursty -- indeed, it retransmitted bursts. The effects were > awful. > Plenty of operational measurements to prove it. Maybe I'm trying to pick a nit, but was the underlying problem that it was bursty in the initial transmission, or was the underlying problem really that it continued to retransmit the bursts, without any (IIRC) exponential backoff? rick jones Wisdom teeth are impacted, people are affected by the effects of events From L.Wood at surrey.ac.uk Tue Sep 26 06:00:27 2006 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Tue, 26 Sep 2006 14:00:27 +0100 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: References: <603BF90EB2E7EB46BF8C226539DFC20701316A80@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: <200609261300.OAA04014@cisco.com> At Saturday 23/09/2006 09:15 -0400, Paul Francis wrote: >Seriously though... > >There is another way to view the question of whether fasttcp is out >of the running or not. Which is, if FastTCP is commercialized (and >by the way the Fastsoft deployment model is a simple and popular one) really? If it's so popular, which OS vendors have adopted FastTCP(TM)? (Microsoft developed its own Compound TCP. Linux is going with CUBIC variants. These avoid IPR restrictions and licenses.) L. >, then it seems that FastTCP is exactly the protocol that you want >to be benchmarking against alternatives. > >PF > > >---------- >From: L.Wood at surrey.ac.uk [mailto:L.Wood at surrey.ac.uk] >Sent: Saturday, September 23, 2006 4:33 AM >To: Paul Francis; l.andrew at ieee.org >Cc: doug.leith at nuim.ie; end2end-interest at postel.org >Subject: RE: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc > >Paul Francis said on Fri 2006-09-22 23:23: > > Sure, but nevertheless it is interesting to compare them. I > mean, what if we > > find out that fasttcp is just or nearly just as good as XCP. This tells us > > not to even bother looking at XCP cause of the deployment cost. > >While the Caltech IPR on Fast TCP tells us not to look at Fast TCP >because of the deployment cost. > >http://www.fastsoft.com/fasttcp.html > >Note that the correct name of the protocol is FastTCP(TM) -- and >that in FastSoft's preferred deployment model, you'd have to deploy >their PEPs in front of every LAN... not so different from XCP. > >FastTCP has been out of the running for deployment ever since it was >first announced -- with the Caltech IPR shackles mentioned in the slideset. > >L. From francis at cs.cornell.edu Tue Sep 26 06:50:04 2006 From: francis at cs.cornell.edu (Paul Francis) Date: Tue, 26 Sep 2006 09:50:04 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <200609261300.OAA04014@cisco.com> Message-ID: What I said was, that Fastsoft's deployment model (that of putting an appliance at the edge of the network) is simple and popular (i.e. many products deploy that way). Look, the original question on the table is simply whether it makes sense for a researcher to compare his transport protocol with FastTCP. I know how I answer that question for myself, which is, yes, it makes sense. Not only because it is a good technology (AFAIK), but also because it is a commercial product. It is very nice if a research result can beat a commercial product. Of course good to compare with other transports as well. If as a researcher you don't think it makes sense to compare your transport with FastTCP, well fine then. PF -----Original Message----- From: Lloyd Wood [mailto:L.Wood at surrey.ac.uk] Sent: Tuesday, September 26, 2006 9:00 AM To: Paul Francis Cc: l.andrew at ieee.org; doug.leith at nuim.ie; end2end-interest at postel.org Subject: Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc At Saturday 23/09/2006 09:15 -0400, Paul Francis wrote: >Seriously though... > >There is another way to view the question of whether fasttcp is out of >the running or not. Which is, if FastTCP is commercialized (and by the >way the Fastsoft deployment model is a simple and popular one) really? If it's so popular, which OS vendors have adopted FastTCP(TM)? (Microsoft developed its own Compound TCP. Linux is going with CUBIC variants. These avoid IPR restrictions and licenses.) L. >, then it seems that FastTCP is exactly the protocol that you want to >be benchmarking against alternatives. > >PF > > >---------- >From: L.Wood at surrey.ac.uk [mailto:L.Wood at surrey.ac.uk] >Sent: Saturday, September 23, 2006 4:33 AM >To: Paul Francis; l.andrew at ieee.org >Cc: doug.leith at nuim.ie; end2end-interest at postel.org >Subject: RE: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc > >Paul Francis said on Fri 2006-09-22 23:23: > > Sure, but nevertheless it is interesting to compare them. I > mean, what if we > > find out that fasttcp is just or nearly just as good as XCP. This > > tells us not to even bother looking at XCP cause of the deployment cost. > >While the Caltech IPR on Fast TCP tells us not to look at Fast TCP >because of the deployment cost. > >http://www.fastsoft.com/fasttcp.h >tml > >Note that the correct name of the protocol is FastTCP(TM) -- and that >in FastSoft's preferred deployment model, you'd have to deploy their >PEPs in front of every LAN... not so different from XCP. > >FastTCP has been out of the running for deployment ever since it was >first announced -- with the Caltech IPR shackles mentioned in the slideset. > >L. From fred at cisco.com Mon Sep 25 15:55:08 2006 From: fred at cisco.com (Fred Baker) Date: Mon, 25 Sep 2006 15:55:08 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> Message-ID: <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> On Sep 25, 2006, at 3:42 PM, Ritesh Kumar wrote: > The paper presents many details but the gist is that when TCP is > paced, it takes very little time for the bottleneck queue to build > up from nothing to the full queue size. actually, I'm not sure that ack clocking that worked perfectly (all traffic is evenly paced throughout the RTT) or pacing that worked perfectly would behave much differently in any given RTT. The big issue with pacing in every RTT is that it is every RTT - you never step back to being ack clocked and as a result are not responsive to the millisecond-to-millisecond variations inherent in the network. My thought is that there are a few cases where you would like to use a pacing algorithm to deal with momentary events, like when some implementations get their input blocked and so throw away ACKs for a while and then suddenly get an Ack that appears to permit them to send a large volume all at once. Using some appropriate trigger, such as "the current combination of effective window and available data permits me to send more than N segments in a burst", I would hope it would send whatever it chose to send at approximately cwnd/srtt. As Bob says, systems often have fairly obnoxious timing signals available to them. One might hope that this could get fixed :-( From craig at aland.bbn.com Tue Sep 26 10:29:31 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Tue, 26 Sep 2006 13:29:31 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: Your message of "Mon, 25 Sep 2006 18:45:00 PDT." <8f884bb031b3678c4b56874456ec25aa@mac.com> Message-ID: <20060926172931.96BC867@aland.bbn.com> In message <8f884bb031b3678c4b56874456ec25aa at mac.com>, rick jones writes: >Maybe I'm trying to pick a nit, but was the underlying problem that it >was bursty in the initial transmission, or was the underlying problem >really that it continued to retransmit the bursts, without any (IIRC) >exponential backoff? Hi Rick: Excellent question, on which my memory is imperfect. Here's my best recollection. Pre-1988 BSD TCP (and, indeed, I believe all TCPs) would start by sending as close to an entire window's worth of traffic as they could (e.g. as fast as the application could stuff the transmission queue, data got sent up to the window size). In case of loss, TCP retransmitted only the missing segments, but as soon as all losses were recovered from, TCP resumed hammering full bursts. So TCP was not go-back-N, but had a sort of strange burstiness of the form: initial burst -- causing loss -- followed by recovery -- followed by new burst Others who were there, please correct, update as appropriate. Thanks! Craig From johnh at ISI.EDU Tue Sep 26 10:28:34 2006 From: johnh at ISI.EDU (John Heidemann) Date: Tue, 26 Sep 2006 10:28:34 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <20060925192326.5028B67@aland.bbn.com> Message-ID: <200609261728.k8QHSYmE011416@dash.isi.edu> On Mon, 25 Sep 2006 15:23:26 EDT, Craig Partridge wrote: > >Hi Bob: > >A team I was on showed you could do this a few years ago. I no longer >remember all the details (Dennis Rockwell did the hard work with UNIX >timers) but it is probably in the paper: > > J. Kulik, R. Coulter, D. Rockwell and C. Partridge, > "Paced TCP for High Delay-Bandwidth Networks," > IEEE Workshop on Satellite Based Information Systems, > December 1999. > >Craig And also: Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections. Technical Report N. 97-661, University of Southern California, Computer Science Department, November, 1997. . (Unfortunately, never published beyond a technical report.) If one accepts moderate-size bursts (4-8 back-to-back segments), and a 100Hz clock (reasonably even by 1997 standards), one can pace at nearly 10Mb/s with ease (100Hz ticks * 1500B/pkt * 8B/b * 8 pkts/ticks), and increase by a factor of 4-8 in the next round trip. Given that today's kernels typically run at 1kHz by default, one can multiple that by 10 even before starting any serious hacking. -John > >In message <200609251911.MAA24244 at gra.isi.edu>, Bob Braden writes: > >> >> >> *> >> *> There are places where improving TCP burstiness can be of value, such >> *> as in the cases where (usually Linux) TCPs decide to send their >> *> entire next window in a short period of time it would be nice of they >> *> could be convinced to do so at a rate that doesn't exceed cwnd/srtt. >> >>The ability of an OS to do that pacing has traditionally been limited >>by the coarse-grain software clocks that were available -- i.e., by >>interrupt overhead. Suppose CPU chip designers listened to the needs >>of networking people. Could they provide fine-grain hardware clocks >>that could be easily used by transport protocols for pacing out packets >>in large windows? >> >>Bob Braden >> > From detlef.bosau at web.de Tue Sep 26 10:51:21 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 26 Sep 2006 19:51:21 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <006301c6e0ff$1dd52cb0$d22dd783@baybridge> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> Message-ID: <45196899.8030105@web.de> Xiaoliang (David) Wei wrote: > > So, it seems to us that there are a lot to understand in the > future. The performance of paced TCP/bursty TCP seems to depend on > several questions: > 1. Is aggregate throughput the most important metric? > 2. What is the packet loss pattern in Internet? > 3. How does TCP reacts to loss? (Besides Reno, there are many new > algorithms) > 4. How do we implement and deploy pacing? (Are paced flows going to > compete with bursty flows? We can also tune the paced flows to let > them compete... Are we using AQM to generate less bursty packet loss? > and etc) > > -David Perhaps the following will become clear, when I read the aformentioned papers. But what I?m curious about in all (sender) pacing approaches is: Where does the pacing rate stem from? Typically, it?s obtained from one of the numerous TCP formulae (Padhye, Mathis...), but these are first (admittedly rough) estimates and second need some measurements to have an initial value set. Moreover, widely deployed pacing would practically replace the currently used AIMD mechanism for achieving a fair share, because the currently used AIMD probing leads to "microbursts", which means that the TCP sender _exceeds_ its fair share of rate for short periods of time. This doesn?t matter as TCP is not rate controlled. And the final rate is corrected by ACK clocking. How does this work with sender pacing, i.e. putting a leaky bucket or flow shaper or something like that in the TCP sender? Detlef From detlef.bosau at web.de Tue Sep 26 10:57:27 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 26 Sep 2006 19:57:27 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <8f884bb031b3678c4b56874456ec25aa@mac.com> References: <20060925142037.112C067@aland.bbn.com> <8f884bb031b3678c4b56874456ec25aa@mac.com> Message-ID: <45196A07.8080102@web.de> rick jones wrote: > > Maybe I'm trying to pick a nit, but was the underlying problem that it > was bursty in the initial transmission, or was the underlying problem > really that it continued to retransmit the bursts, without any (IIRC) > exponential backoff? That?s a good question :-) Therefore I placed my initial posting here: I read a lot of things about "burstiness". And even more about numerous ways to describe this burstiness. For me, it would be helpful to get an idea where burstiness stems from. E.g.: - mircobursts which stem from probing during an exponential slow start. - bursts wich stem from senders which continously retrnsmit dropped packets "synchronously" . ... At least when burstiness becomes an issue, I believe its easier to avoid burstiness, or to alleviate, when we know the reasons for burstiness. Detlef > > rick jones > Wisdom teeth are impacted, people are affected by the effects of events > From sireenmalik at ieee.org Tue Sep 26 11:39:57 2006 From: sireenmalik at ieee.org (Sireen Malik) Date: Tue, 26 Sep 2006 19:39:57 +0100 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <45196A07.8080102@web.de> References: <20060925142037.112C067@aland.bbn.com> <8f884bb031b3678c4b56874456ec25aa@mac.com> <45196A07.8080102@web.de> Message-ID: <451973FD.50009@ieee.org> Detelf, > At least when burstiness becomes an issue, I believe its easier to > avoid burstiness, or to alleviate, when we know the reasons for > burstiness. > A few pointers.... Web-pages have large variance - enough to start another discussion of heavy-tailed distributions ;-) This is one source of burstiness. Hard to cure! Or, is it? TCP is bursty, too. It's like an on-off source: A bunch of packets are sent in a window in the on-phase, etc. People ahve argued about "shaping" TCP packet generation process to address this burstiness at small time scales. Look for Biplab Sikdar paper from this century. My ex-colleague at TUHH Dirk Abendroth also did a take on this. Mark Crovella, et. al showed that under heavy loss conditions, TCP causes pseduo self-similarity. ... Hope that helps, -- SM From dpreed at reed.com Tue Sep 26 11:39:34 2006 From: dpreed at reed.com (David P. Reed) Date: Tue, 26 Sep 2006 14:39:34 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> Message-ID: <451973E6.5050409@reed.com> Fred Baker wrote: > > As Bob says, systems often have fairly obnoxious timing signals > available to them. One might hope that this could get fixed :-( > Not that it should matter, but I write network code every day for XP, OSX and Linux. Perhaps the grandees who manage are still living in past decades. The days when end-system clocks had really lousy resolution are gone, gone, gone. While getting resolution below a millisecond is still not always possible, all of these platforms, when running on 500 MHz processors or better, do just fine with minimal overhead when running activities that need to be scheduled with millisecondish granularities. Of course it's a little harder to do this in user space, one needs to know how to manage user space thread priorities. But in the kernel, where networking is usually done, it's no problem. And in user space it's not actually hard, you just need to RTFM. From L.Wood at surrey.ac.uk Tue Sep 26 13:58:19 2006 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Tue, 26 Sep 2006 21:58:19 +0100 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <20060926172931.96BC867@aland.bbn.com> References: <20060926172931.96BC867@aland.bbn.com> Message-ID: <200609262058.VAA17865@cisco.com> At Tuesday 26/09/2006 13:29 -0400, Craig Partridge wrote: >In message <8f884bb031b3678c4b56874456ec25aa at mac.com>, rick jones writes: > > >Maybe I'm trying to pick a nit, but was the underlying problem that it > >was bursty in the initial transmission, or was the underlying problem > >really that it continued to retransmit the bursts, without any (IIRC) > >exponential backoff? > >Hi Rick: > >Excellent question, on which my memory is imperfect. Here's my best >recollection. > >Pre-1988 BSD TCP (and, indeed, I believe all TCPs) would start by sending >as close to an entire window's worth of traffic as they could (e.g. as fast >as the application could stuff the transmission queue, data got sent up >to the window size). > >In case of loss, TCP retransmitted only the missing segments, why did we ever bother with SACK, then? thanks, L. >but as soon as all >losses were recovered from, TCP resumed hammering full bursts. So TCP was >not go-back-N, but had a sort of strange burstiness of the form: > > initial burst -- causing loss -- followed by recovery -- followed by > new burst > >Others who were there, please correct, update as appropriate. > >Thanks! > >Craig From shemminger at osdl.org Tue Sep 26 14:08:56 2006 From: shemminger at osdl.org (Stephen Hemminger) Date: Tue, 26 Sep 2006 14:08:56 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451973E6.5050409@reed.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451973E6.5050409@reed.com> Message-ID: <20060926140856.5aa48ca3@freekitty> On Tue, 26 Sep 2006 14:39:34 -0400 "David P. Reed" wrote: > Fred Baker wrote: > > > > As Bob says, systems often have fairly obnoxious timing signals > > available to them. One might hope that this could get fixed :-( > > > Not that it should matter, but I write network code every day for XP, > OSX and Linux. Perhaps the grandees who manage are still living in past > decades. > > The days when end-system clocks had really lousy resolution are gone, > gone, gone. While getting resolution below a millisecond is still not > always possible, all of these platforms, when running on 500 MHz > processors or better, do just fine with minimal overhead when running > activities that need to be scheduled with millisecondish granularities. You must live in a world without power management and SMP. The number of systems that can't get a high resolution synchronized and stable clock seems to be increasing not decreasing! > Of course it's a little harder to do this in user space, one needs to > know how to manage user space thread priorities. But in the kernel, > where networking is usually done, it's no problem. And in user space > it's not actually hard, you just need to RTFM. > > > > -- Stephen Hemminger From mallman at icir.org Tue Sep 26 19:51:54 2006 From: mallman at icir.org (Mark Allman) Date: Tue, 26 Sep 2006 22:51:54 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <20060925142037.112C067@aland.bbn.com> Message-ID: <20060927025155.18A124926F4@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060926/9ca3dc15/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060926/9ca3dc15/attachment.bin From zec at tel.fer.hr Wed Sep 27 02:53:16 2006 From: zec at tel.fer.hr (Marko Zec) Date: Wed, 27 Sep 2006 11:53:16 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451973E6.5050409@reed.com> References: <20060923103853.426C567@aland.bbn.com> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451973E6.5050409@reed.com> Message-ID: <200609271153.16325.zec@tel.fer.hr> On Tuesday 26 September 2006 20:39, David P. Reed wrote: > Fred Baker wrote: > > As Bob says, systems often have fairly obnoxious timing signals > > available to them. One might hope that this could get fixed :-( > > Not that it should matter, but I write network code every day for XP, > OSX and Linux. Perhaps the grandees who manage are still living in past > decades. > > The days when end-system clocks had really lousy resolution are gone, > gone, gone. While getting resolution below a millisecond is still not > always possible, all of these platforms, when running on 500 MHz > processors or better, do just fine with minimal overhead when running > activities that need to be scheduled with millisecondish granularities. > > Of course it's a little harder to do this in user space, one needs to > know how to manage user space thread priorities. But in the kernel, > where networking is usually done, it's no problem. And in user space > it's not actually hard, you just need to RTFM. The question whether or not we can implement fine-grained pacing in software might be becoming less relevant now that the silicon industry is irreversibly pushing with TCP segmentation offload implementations in hardware. Given that the OS typically feeds a TSO engine with at least a 32 or 64 kbyte raw data chunk per single TCP session, this corresponds to a 22 or 44 segment wire-speed burst at minimum. Thinking what things might look like if multiple such streams would get synchronized is quite scarry... Marko From craig at aland.bbn.com Wed Sep 27 05:01:34 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Wed, 27 Sep 2006 08:01:34 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: Your message of "Tue, 26 Sep 2006 21:58:19 BST." <200609262058.VAA17865@cisco.com> Message-ID: <20060927120134.7D5F467@aland.bbn.com> In message <200609262058.VAA17865 at cisco.com>, Lloyd Wood writes: >At Tuesday 26/09/2006 13:29 -0400, Craig Partridge wrote: >>In case of loss, TCP retransmitted only the missing segments, > >why did we ever bother with SACK, then? Because, in the absence of SACK, you could only retransmit the first missing segment. (Note, this isn't what the TCP standard says -- but was widely accepted as the right practice. As I recall, there was an email from Jon Postel c. 1987 to E2E-Interest or TCP-IP on this topic but a quick search failed to find it). Craig From ikob at koganei.wide.ad.jp Wed Sep 27 05:23:21 2006 From: ikob at koganei.wide.ad.jp (Katsushi Kobayashi) Date: Wed, 27 Sep 2006 21:23:21 +0900 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <200609271153.16325.zec@tel.fer.hr> References: <20060923103853.426C567@aland.bbn.com> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451973E6.5050409@reed.com> <200609271153.16325.zec@tel.fer.hr> Message-ID: I presented a sample NIC implementation for fine grained packet pacing: http://www.hpcc.jp/pfldnet2006/paper/s3_01.pdf In my experience fine grained pacing is easy and small foot-print size compared with complete TCP offload. Also, I believe NIC vendor is already aware packet pacing effect as: http://data-reservoir.adm.s.u-tokyo.ac.jp/lsr-20041225/ I2 will not approve the result using a special hardware. So, I believe Chelsio implemented packet pacing feature in released product. -- Katsushi Kobayashi On 2006/09/27, at 18:53, Marko Zec wrote: > On Tuesday 26 September 2006 20:39, David P. Reed wrote: >> Fred Baker wrote: >>> As Bob says, systems often have fairly obnoxious timing signals >>> available to them. One might hope that this could get fixed :-( >> >> Not that it should matter, but I write network code every day for XP, >> OSX and Linux. Perhaps the grandees who manage are still living >> in past >> decades. >> >> The days when end-system clocks had really lousy resolution are gone, >> gone, gone. While getting resolution below a millisecond is >> still not >> always possible, all of these platforms, when running on 500 MHz >> processors or better, do just fine with minimal overhead when running >> activities that need to be scheduled with millisecondish >> granularities. >> >> Of course it's a little harder to do this in user space, one needs to >> know how to manage user space thread priorities. But in the kernel, >> where networking is usually done, it's no problem. And in user >> space >> it's not actually hard, you just need to RTFM. > > The question whether or not we can implement fine-grained pacing in > software > might be becoming less relevant now that the silicon industry is > irreversibly > pushing with TCP segmentation offload implementations in hardware. > Given > that the OS typically feeds a TSO engine with at least a 32 or 64 > kbyte raw > data chunk per single TCP session, this corresponds to a 22 or 44 > segment > wire-speed burst at minimum. Thinking what things might look like if > multiple such streams would get synchronized is quite scarry... > > Marko From fred at cisco.com Tue Sep 26 12:44:40 2006 From: fred at cisco.com (Fred Baker) Date: Tue, 26 Sep 2006 12:44:40 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <20060926172931.96BC867@aland.bbn.com> References: <20060926172931.96BC867@aland.bbn.com> Message-ID: <267AD444-DC0A-4414-A0E5-F620AA8ED444@cisco.com> What you describe is pretty much what happened with each of a variety of different transports and transport implementations in the 1970's and 1980's. In 1983, I wrote an implementation of XNS SPP at CDC (having just designed an instance of the BBN Class Four Transport, which was in that year withdrawn, and then ISO extracted the state machine from it and turned it into the ISO Class Four Transport). In that SPP, I included procedures pretty similar to what have become known as the Van Jacobsen Congestion Control Procedures, which he wrote up in 1988. You see, although the Internet Transport is pretty specific that one is supposed to send a packet train, in the last packet request an Ack, and send the next packet train when the Ack arrives, we read some papers from Digital that indicated that they had experienced problems with that model in early DECNET implementations and instituted AIMD procedures to deal with them... On Sep 26, 2006, at 10:29 AM, Craig Partridge wrote: > > In message <8f884bb031b3678c4b56874456ec25aa at mac.com>, rick jones > writes: > >> Maybe I'm trying to pick a nit, but was the underlying problem >> that it >> was bursty in the initial transmission, or was the underlying problem >> really that it continued to retransmit the bursts, without any (IIRC) >> exponential backoff? > > Hi Rick: > > Excellent question, on which my memory is imperfect. Here's my best > recollection. > > Pre-1988 BSD TCP (and, indeed, I believe all TCPs) would start by > sending > as close to an entire window's worth of traffic as they could (e.g. > as fast > as the application could stuff the transmission queue, data got > sent up > to the window size). > > In case of loss, TCP retransmitted only the missing segments, but > as soon as all > losses were recovered from, TCP resumed hammering full bursts. So > TCP was > not go-back-N, but had a sort of strange burstiness of the form: > > initial burst -- causing loss -- followed by recovery -- > followed by > new burst > > Others who were there, please correct, update as appropriate. > > Thanks! > > Craig From fred at cisco.com Tue Sep 26 12:46:27 2006 From: fred at cisco.com (Fred Baker) Date: Tue, 26 Sep 2006 12:46:27 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <45196899.8030105@web.de> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> Message-ID: On Sep 26, 2006, at 10:51 AM, Detlef Bosau wrote: > But what I?m curious about in all (sender) pacing approaches is: > Where does the pacing rate stem from? Typically, it?s obtained from > one of the numerous TCP formulae (Padhye, Mathis...), but these are > first (admittedly rough) estimates and second need some > measurements to have an initial value set. > > Moreover, widely deployed pacing would practically replace the > currently used AIMD mechanism for achieving a fair share, because > the currently used AIMD probing leads to "microbursts", which means > that the TCP sender _exceeds_ its fair share of rate for short > periods of time. This doesn?t matter as TCP is not rate > controlled. And the final rate is corrected by ACK clocking. > How does this work with sender pacing, i.e. putting a leaky bucket > or flow shaper or something like that in the TCP sender? The big problem in pacing is determining the rate available at the bottleneck. Let's assume a truly perfect case - the bottleneck in the network has a total capacity of N bps, and currently there are M sessions using it. The M sessions, by magic, are operating in perfect TDM fashion - as the last bit of one message departs, the first bit of the next message becomes ready to send, and no queue ever forms. Is there room for one more bit on the wire? Well, if this was a TDM network, no; something would get dropped. But it's not. So we have a new sender that decides to start a TCP session and sends a SYN. What happens is that his packet collides with some other packet, and a queue one packet deep results. The new session gets very little information about rate out of that - there is clearly capacity for at least one SYN per RTT available, but he gets no idea what he is competing with. But the other M sessions get a teensy bit of information - their Acks get delayed a few nanoseconds, and as a result they send their next data a few nanoseconds later. Their average RTT becomes some function of sizeof(SYN)/M longer, and as a result they each slow down if ever so slightly. Having no information about all this, the new session probes further, sending one or more data segments. Let's assume that it sends several (if it doesn't do so in the next RTT, it will do so in some subsequent one), and that the receiver replies with two or more Acks. The sender can infer that the capacity at the bottleneck is no smaller than Bits acknowledged only by second Ack ------------------------------------------------- Interval between arrivals of first and second Ack If its K segments were transmitted by the bottleneck back to back, this would be a measure of the rate of the bottleneck (Keshev). If packets from some other segments were interleaved, this would give the rate at the bottleneck less the capacity used by those interleaving segments. It won't EXCEED the rate at the bottleneck, but in this example it seriously overestimates the capacity unused by other sessions and therefore available to the new session at the bottleneck. Let's assume that it picked some rate and paced traffic to that rate. It could do that calculation on every Ack it received, and feed those into the moving average. There are a couple of possible scenarios, the most benign of which include "the other sessions all slow down so that this traffic all goes through at that rate" and "all other sessions cease, so that the bottleneck is ONLY carrying this session's traffic". In both of these relatively benign cases, the above calculation says that the rate available is the same number. From the sender's perspective, is that because that is the rate available at the bottleneck? Or is it because that is the rate at which it sent its probing traffic? Should it probe at a higher rate? If so, at what rate? So the new session has to decide to what extent it believes this new pice of data. Maybe it simply jumps to that new rate. I'll leave the analysis to the reader. Or may it includes that new rate estimate in some form of moving average. If it does things just right, it will ramp up its speed at the rate that the sum of the competing sessions slow down, and all will be cool. Anyone care to lay odds that it would be "just right"? Now, change the scenario. The bottleneck is completely unused. The new session comes up, and is trying to infer what capacity is available, following the procedures it followed to get things "just right". Guess what? It asymptotically approaches fully using the link, but takes one heck of a long time to get there. The big problem in pacing is determining the rate available at the bottleneck. And by the way, bottlenecks would have to have heap big magic to operate in anything resembling a TDM fashion. Operational experience in the ATM world gives us another side of this. If you give an ATM VC a certain rate and engineer that rate through the network, ATM works a lot like TDM works - it uses the rate authorized, and doesn't over-use it. If you screw up the engineering, ATM acts like it is screwed up. Hence, I think that what the research, logic, and operational experience tell us is that while pacing can be useful to break down big bursts, in the end pacing doesn't achieve a what the Internet community has been trying to achieve for a long time, which is full use of the bottleneck without overburdening it. We can achieve engineered use, like ATM, or we can from time to time over-burden a bottleneck, but we can't avoid both. So I will argue that using pacing for events, like spreading out the effect of a sequence of lost Acks, can be helpful, but in the end the procedures we use in New Reno etc are superior in the general case. What we can do to improve those procedures might be related to RCP or to some of the work that is being done on other-than-loss- triggered procedures; we'll see. But pacing is not a silver bullet. From mort at ieee.org Wed Sep 27 03:42:57 2006 From: mort at ieee.org (mort) Date: Wed, 27 Sep 2006 11:42:57 +0100 Subject: [e2e] userlevel TCP diagnostics Message-ID: <8d1cde2c0609270342x2a7b8955y5c690e8cc7dd653f@mail.gmail.com> hi, upon reading RFC 675 recently, i came across the following text: """ 5. NETWORK MEASUREMENT PLANS FOR TCP 5.1 USERLEVEL DIAGNOSTICS We have in mind a program which will exercise a given TCP, causing it to cycle through a number of states; opening, closing, and transmitting on a variety of connections. This program will collect statistics and will generally try to detect deviation from TCP functional specifications. Clearly there will have to be a copy of this program both at the local site being tested and some site which has a certified TCP. So we will have to produce a specification for this user level diagnostic program also. There needs to be a master and a slave side to all this so the master can tell the slave what's going wrong with the test. """ ...a precursor to a self-managed Internet perhaps :) anyway, I was wondering if anyone could tell me whether this program/service was ever implemented and deployed, and whether it was reported anywhere? (and if not, why not?) thanks, R. From detlef.bosau at web.de Wed Sep 27 08:33:35 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 27 Sep 2006 17:33:35 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451973E6.5050409@reed.com> <200609271153.16325.zec@tel.fer.hr> Message-ID: <451A99CF.90703@web.de> Is this really a NIC problem or end point problem? When I read Fred?s post yesterday, I got the impression that it?s more a problem that flows tend not to interleave on the path. And that?s my observation from quite a few NS2 simulations as well (although I didn?t do any simulations during the last month, the more simulations I did, the less sense I saw in doing so for quite a couple of reasons). Fred mentioned that flows do not behave "TDM like". And if this is the / one issue, I?m curious whether this could be changed. I spontaniously thought in the direction of "Rate Allocating Servers" (introduced by Keshav IIRC), but even if we totally ignore the question how a correct rate is to be set for the moment, will this scale up to thousands, perhaps millions of flows? Katsushi Kobayashi wrote: > I presented a sample NIC implementation for fine > grained packet pacing: > > http://www.hpcc.jp/pfldnet2006/paper/s3_01.pdf > > In my experience fine grained pacing is easy and small > foot-print size compared with complete TCP offload. > > Also, I believe NIC vendor is already aware packet pacing > effect as: > http://data-reservoir.adm.s.u-tokyo.ac.jp/lsr-20041225/ > > I2 will not approve the result using a special hardware. > So, I believe Chelsio implemented packet pacing feature in > released product. > > -- > Katsushi Kobayashi > > From jeffay at cs.unc.edu Tue Sep 26 19:35:14 2006 From: jeffay at cs.unc.edu (Kevin Jeffay) Date: Tue, 26 Sep 2006 22:35:14 -0400 Subject: [e2e] IMC 2006, Rio de Janeiro: Call for Participation Message-ID: <170424eca8b9aa901084a54720d3d53b@cs.unc.edu> CALL FOR PARTICIPATION Internet Measurement Conference 2006 Sponsored by ACM SIGCOMM and in cooperation with USENIX October 25-27, 2006 Rio de Janeiro, Brazil http://www.imconf.net/imc-2006/ The 2006 Internet Measurement Conference is a two and a half day event focusing on Internet measurement and analysis, following on the successes of five previous Internet Measurement Workshops and Conferences. The conference will be held in the Marina Palace Hotel located on Leblon Beach in Leblon, one of the most traditional and charming parts of Rio. The beautiful Ipanema and Copacabana beaches are also nearby. The conference reception will be at Rio Scenarium - Culture Pavillion, a 19th-century building located in the culturally rich Lapa District. The conference banquet will be at Barra Brasa Rio, which is within walking distance of the hotel. Registration and local arrangements information can be found at the conference website http://www.imconf.net/imc-2006/ TECHNICAL PROGRAM Wednesday, October 25, 2006 Sampling Shared State Sampling, Frederic Raspall, Sebastia Sallent, Josep Yufera, Technical University of Catalonia Fisher Information of Sampled Packets: an Application to Flow Size Estimation Bruno Ribeiro, Don Towsley, University of Masachusetts at Amherst; Tao Ye, Jean Bolot, Sprint Advanced Technology Laboratories On Unbiased Sampling for Unstructured Peer-to-Peer Networks Daniel Stutzbach, Reza Rejaie, University of Oregon; Nick Duffield, Subhabrata Sen, Walter Willinger, AT&T Labs-Research Security and Privacy A Longtitudinal Analysis of Botnet Dynamics: A Walk on the Wild Side Moheeb Abu Rajab, Jay Zarfoss, Fabian Monrose, Andreas Terzis, Johns Hopkins University Finding Diversity in Remote Code Injection Exploits Justin Ma, University of California, San Diego; John Dunagan, Helen Wang, Microsoft Research; Stefan Savage, Geoffrey Voelker, University of California, San Diego Generating a Privacy Footprint on the Internet Balachander Krishnamurthy, AT&T Labs - Research; Craig Wills, Worcester Polytechnic Institute Latency and Topology Towards IP Geolocation using Delay and Topology Measurements Ethan Katz-Bassett, John Zahorjan, Arvind Krishnamurthy, David Wetherall, Tom Anderson, University of Washington; Yatin Chawathe, Google Measurement-Based Analysis, Modeling, and Synthesis of the Internet Delay Space Bo Zhang, T. S. Eugene Ng, Animesh Nandi, Rudolf Riedi, Rice University; Peter Druschel, Max Planck Institute of Software Systems; Guohui Wang, Rice University An Explanatory Approach to Latency Prediction Harsha Madhyastha, Tom Anderson, Arvind Krishnamurthy, University of Washington; Neil Spring, University of Maryland; Arun Venkataramani, University of Massachusetts Amherst Touring the Internet in a TCP Sidecar Rob Sherwood, Neil Spring, University of Maryland Tools Monarch: A Tool to Emulate Transport Protocol Flows over the Internet at Large Andreas Haeberlen, Marcel Dischinger, Krishna Gummadi, MPI-SWS; Stefan Saroiu, University of Toronto Semi-Automated Discovery of Application Session Structure Jayanthkumar Kannan, University of California at Berkeley; Jaeyeon Jung, Massachusetts Institute of Technology; Vern Paxson, ICSI; Can Emre Koksal, Department of Computer an Communication Sciences, EPFL On the Impact of Research Network Based Testbeds on Wide-area Experiments Himabindu Pucha, Y. Charlie Hu, Purdue University, West Lafayette; Z. Morley Mao, University of Michigan, Ann Arbor Thursday, October 26, 2006 Anomalies and Malware Precise Anomaly Detection and Identification Using Sketch Subspaces Xin Li, Fang Bian, University of Southern California; Mark Crovella, Boston University; Christophe Diot, Thomson Technology Paris Laboratory; Ramesh Govindan, University of Southern California; Gianluca Iannaccone, Intel Research Camrbidge Avoiding Traceroute Anomalies with Paris Traceroute Brice Augustin, Xavier Cuvellier, Universite Pierre et Marie Curie, CNRS -- Laboratoire LIP6; Benjamin Orgogozo, Fabien Viger, Universite Denis Diderot, CNRS -- Laboratoire LIAFA; Timur Friedman, Universite Pierre et Marie Curie, CNRS -- Laboratoire LIP6-CNRS; Matthieu Latapy, Universite Denis Diderot, CNRS -- Laboratoire LIAFA; Clemence Magnien, Ecole Polytechnique, CNRS -- Laboratoire CREA; Renata Teixeira, Universite Pierre et Marie Curie, CNRS -- Labtoratoire LIP6 Impact of Traffic Sampling on Anomaly Detection Daniela Brauckhoff, Swiss Federal Institute of Technology; Anukool Lakhina, Boston University; Bernhard Tellenbach, Arno Wagner, Martin May, Swiss Federal Institute of Technology Is Sampled Data Sufficient for Anomaly Detection? Jianning Mai, Chen-Nee Chuah, UC Davis; Ashwin Sridharan, Tao Ye, Hui Zang, Sprint Peer to peer Comprehensive View of a Live Network Coding P2P System Pablo Rodriguez, Christos Gkantsidis, John Miller, Microsoft Research, Cambridge Understanding Churn in Peer-to-Peer Networks Daniel Stutzbach, Reza Rejaie, University of Oregon Rarest First and Choke Algorithms Are Enough Arnaud Legout, INRIA; Guillaume Urvoy-Keller, Pietro Michiardi, Institut Eurecom Traffic Delving into Internet Streaming Media Delivery: A Quality and Resource Utilization Perspective Lei Guo, Enhua Tan, The Ohio State University; Songqing Chen, George Mason University; Zhen Xiao, IBM T.J. Watson Research Center; Oliver Spatscheck, AT&T Labs-Research; Xiaodong Zhang, The Ohio State University A Measurement-based Deployment Proposal for IP Anycast Hitesh Ballani, Paul Francis, Cornell University; Sylvia Ratnasamy, Intel-Research Berkeley Measuring Query Clickstreams Nils Kammenhuber, Technische Universite Munchen; Julia Luxenburger, Max-Planck Institute of Informatics; Anja Feldmann, Technische Universite Munchen; Gerhard Weikum, Max-Planck Institute of Informatics An Independent-Connection Model for Traffic Matrices Vijay Erramilli, Mark Crovella, Boston University; Nina Taft, Intel Research Wireless The Need for Cross-layer Information in Access Point Selection Karthikeyan Sundaresan, Georgia Tech; Konstantina Papagiannaki, Intel Research Cambridge A Study of the Short Message Service of a Nationwide Cellular Carrier Petros Zerfos, Deutsche Telekom Laboratories; Xiaoqiao Meng, Vidyut Samanta, Songwu Lu, University of California Los Angeles BGP Quantifying Path Exploration in the Internet Ricardo Oliveira, UCLA; Beichuan Zhang, University of Arizona; Dan Pei, ATT Labs Research; Daniel Massey, Colorado State University; Lixia Zhang, UCLA BGP Convergence in Virtual Private Networks Dan Pei, Jacobus Van der Merwe, AT&T Labs-Research Friday, October 27, 2006 Pattern Matching and Parsing BinPAC: A yacc for Writing Application Protocol Parsers Ruoming Pang, Princeton University; Vern Paxson, ICSI; Larry Peterson, Princeton University Approximate Fingerprinting to Accelerate Pattern Matching Ramaswamy Ramaswamy, University of Massachusetts, Amherst; Lukas Kencl, Gianluca Iannaccone, Intel Research, Cambridge Efficient String Comparison Algorithms for Network Traffic Christian Kreibich, Jon Crowcroft, University of Cambridge Malware Unexpected Means of Protocol Inference Justin Ma, Kirill Levchenko, University of California San Diego; Christian Kreibich, University of Cambridge; Stefan Savage, Geoffrey Voelker, University of California San Diego A Study of Malware in Peer-to-peer Networks Andrew Kalafut, Abhinav Acharya, Minaxi Gupta, Indiana University Malware Prevalence in the KaZaA File-Sharing Network Seungwon Shin, Electronics and Telecommunications Research Institute (ETRI); Jaeyeon Jung, Hari Balakrishnan, MIT IMPORTANT NOTES If you anticipate attending, you should book your hotel room ASAP because other cultural events in Rio at the same time will make hotel accommodations scarce.. Many attendees will need a visa to enter Brazil. Visas are required for citizens of the USA, China, India, and others. Citizens of most European countries do not require a visa. Additional information as well instructions for obtaining a visa can be found on the conference website. From braden at ISI.EDU Wed Sep 27 11:30:46 2006 From: braden at ISI.EDU (Bob Braden) Date: Wed, 27 Sep 2006 11:30:46 -0700 (PDT) Subject: [e2e] userlevel TCP diagnostics Message-ID: <200609271830.LAA26303@gra.isi.edu> It was my impression that there was quite a bit of published work on this over the past 20 years. I think that Allison Mankin did some work on it, in a former life. Bob Braden *> From: mort *> To: end2end-interest at postel.org *> Content-Transfer-Encoding: 7bit *> X-Google-Sender-Auth: 7dbd93f233f447dc *> X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean *> X-Mailman-Approved-At: Wed, 27 Sep 2006 08:18:19 -0700 *> Subject: [e2e] userlevel TCP diagnostics *> List-Id: discussion of end-2-end research and design principles *> *> *> hi, *> *> upon reading RFC 675 recently, i came across the following text: *> *> """ *> 5. NETWORK MEASUREMENT PLANS FOR TCP *> *> 5.1 USERLEVEL DIAGNOSTICS *> *> We have in mind a program which will exercise a given TCP, causing it *> to cycle through a number of states; opening, closing, and *> transmitting on a variety of connections. This program will collect *> statistics and will generally try to detect deviation from TCP *> functional specifications. Clearly there will have to be a copy of *> this program both at the local site being tested and some site which *> has a certified TCP. So we will have to produce a specification for *> this user level diagnostic program also. *> *> There needs to be a master and a slave side to all this so the master *> can tell the slave what's going wrong with the test. *> """ *> *> ...a precursor to a self-managed Internet perhaps :) *> *> anyway, I was wondering if anyone could tell me whether this *> program/service was ever implemented and deployed, and whether it was *> reported anywhere? (and if not, why not?) *> *> thanks, *> *> R. *> From dpreed at reed.com Wed Sep 27 11:52:39 2006 From: dpreed at reed.com (David P. Reed) Date: Wed, 27 Sep 2006 14:52:39 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451973E6.5050409@reed.com> <200609271153.16325.zec@tel.fer.hr> Message-ID: <451AC877.5060909@reed.com> Regarding TSO offload of TCP, early binding has benefits, but also costs. One would hope that the offload engine could be upgraded to incorporate better practices. Not being able to upgrade will indeed enhance the ossification of infrastructure in the Internet, shortening the time to its obsolescence. If you design for the past, you get locked into the past. Optimal in the short term, but discounting the value of flexibility in the long term. Need I repeat my rant about designing hot rods rather than family cars? Who cares about setting I2 speed records? From dpreed at reed.com Wed Sep 27 13:09:56 2006 From: dpreed at reed.com (David P. Reed) Date: Wed, 27 Sep 2006 16:09:56 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> Message-ID: <451ADA94.2030309@reed.com> Fred - reasona ble response, but I take issue with your statement that the goal is "full use ot the bottleneck without overburdening it". Little's Lemma would suggest that idea is unreasonable. In the OS community, we used to have a rule of thumb that operating above 50% of the service rate of almost any multiplexed resource is problematic, unless you have a very precise and completely predictable and constant load. And Odlyzko has shown that enterprises are happy to run at about 10% capacity in return for lowering other, much more significant costs (such as jitter, latency, unreliability). Perhaps the real message is that obsession with the fantasy that such a goal is achievable has led to incredibly silly research efforts like the I2 hotrod compettions. Fred Baker wrote: > > On Sep 26, 2006, at 10:51 AM, Detlef Bosau wrote: > >> But what I?m curious about in all (sender) pacing approaches is: >> Where does the pacing rate stem from? Typically, it?s obtained from >> one of the numerous TCP formulae (Padhye, Mathis...), but these are >> first (admittedly rough) estimates and second need some measurements >> to have an initial value set. >> >> Moreover, widely deployed pacing would practically replace the >> currently used AIMD mechanism for achieving a fair share, because the >> currently used AIMD probing leads to "microbursts", which means that >> the TCP sender _exceeds_ its fair share of rate for short periods of >> time. This doesn?t matter as TCP is not rate controlled. And the >> final rate is corrected by ACK clocking. >> How does this work with sender pacing, i.e. putting a leaky bucket >> or flow shaper or something like that in the TCP sender? > > > The big problem in pacing is determining the rate available at the > bottleneck. > > Let's assume a truly perfect case - the bottleneck in the network has > a total capacity of N bps, and currently there are M sessions using > it. The M sessions, by magic, are operating in perfect TDM fashion - > as the last bit of one message departs, the first bit of the next > message becomes ready to send, and no queue ever forms. > > Is there room for one more bit on the wire? Well, if this was a TDM > network, no; something would get dropped. But it's not. So we have a > new sender that decides to start a TCP session and sends a SYN. What > happens is that his packet collides with some other packet, and a > queue one packet deep results. The new session gets very little > information about rate out of that - there is clearly capacity for at > least one SYN per RTT available, but he gets no idea what he is > competing with. But the other M sessions get a teensy bit of > information - their Acks get delayed a few nanoseconds, and as a > result they send their next data a few nanoseconds later. Their > average RTT becomes some function of sizeof(SYN)/M longer, and as a > result they each slow down if ever so slightly. > > Having no information about all this, the new session probes further, > sending one or more data segments. Let's assume that it sends several > (if it doesn't do so in the next RTT, it will do so in some subsequent > one), and that the receiver replies with two or more Acks. The sender > can infer that the capacity at the bottleneck is no smaller than > > Bits acknowledged only by second Ack > ------------------------------------------------- > Interval between arrivals of first and second Ack > > If its K segments were transmitted by the bottleneck back to back, > this would be a measure of the rate of the bottleneck (Keshev). If > packets from some other segments were interleaved, this would give the > rate at the bottleneck less the capacity used by those interleaving > segments. It won't EXCEED the rate at the bottleneck, but in this > example it seriously overestimates the capacity unused by other > sessions and therefore available to the new session at the bottleneck. > > Let's assume that it picked some rate and paced traffic to that rate. > It could do that calculation on every Ack it received, and feed those > into the moving average. There are a couple of possible scenarios, the > most benign of which include "the other sessions all slow down so that > this traffic all goes through at that rate" and "all other sessions > cease, so that the bottleneck is ONLY carrying this session's > traffic". In both of these relatively benign cases, the above > calculation says that the rate available is the same number. From the > sender's perspective, is that because that is the rate available at > the bottleneck? Or is it because that is the rate at which it sent its > probing traffic? Should it probe at a higher rate? If so, at what rate? > > So the new session has to decide to what extent it believes this new > pice of data. Maybe it simply jumps to that new rate. I'll leave the > analysis to the reader. Or may it includes that new rate estimate in > some form of moving average. If it does things just right, it will > ramp up its speed at the rate that the sum of the competing sessions > slow down, and all will be cool. Anyone care to lay odds that it would > be "just right"? > > Now, change the scenario. The bottleneck is completely unused. The new > session comes up, and is trying to infer what capacity is available, > following the procedures it followed to get things "just right". Guess > what? It asymptotically approaches fully using the link, but takes one > heck of a long time to get there. > > The big problem in pacing is determining the rate available at the > bottleneck. And by the way, bottlenecks would have to have heap big > magic to operate in anything resembling a TDM fashion. > > Operational experience in the ATM world gives us another side of this. > If you give an ATM VC a certain rate and engineer that rate through > the network, ATM works a lot like TDM works - it uses the rate > authorized, and doesn't over-use it. If you screw up the engineering, > ATM acts like it is screwed up. > > Hence, I think that what the research, logic, and operational > experience tell us is that while pacing can be useful to break down > big bursts, in the end pacing doesn't achieve a what the Internet > community has been trying to achieve for a long time, which is full > use of the bottleneck without overburdening it. We can achieve > engineered use, like ATM, or we can from time to time over-burden a > bottleneck, but we can't avoid both. > > So I will argue that using pacing for events, like spreading out the > effect of a sequence of lost Acks, can be helpful, but in the end the > procedures we use in New Reno etc are superior in the general case. > What we can do to improve those procedures might be related to RCP or > to some of the work that is being done on other-than-loss-triggered > procedures; we'll see. But pacing is not a silver bullet. > > From L.Wood at surrey.ac.uk Wed Sep 27 14:31:53 2006 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Wed, 27 Sep 2006 22:31:53 +0100 Subject: [e2e] userlevel TCP diagnostics In-Reply-To: <8d1cde2c0609270342x2a7b8955y5c690e8cc7dd653f@mail.gmail.co m> References: <8d1cde2c0609270342x2a7b8955y5c690e8cc7dd653f@mail.gmail.com> Message-ID: <200609272132.WAA23951@cisco.com> First, you need a TCP functional specification. See e.g. http://www.cl.cam.ac.uk/~pes20/Netsem/ and Norrish's papers. Then, perhaps, you can get to a "certified TCP". L. At Wednesday 27/09/2006 11:42 +0100, mort wrote: >hi, > >upon reading RFC 675 recently, i came across the following text: > >""" >5. NETWORK MEASUREMENT PLANS FOR TCP > >5.1 USERLEVEL DIAGNOSTICS > > We have in mind a program which will exercise a given TCP, causing it > to cycle through a number of states; opening, closing, and > transmitting on a variety of connections. This program will collect > statistics and will generally try to detect deviation from TCP > functional specifications. Clearly there will have to be a copy of > this program both at the local site being tested and some site which > has a certified TCP. So we will have to produce a specification for > this user level diagnostic program also. > > There needs to be a master and a slave side to all this so the master > can tell the slave what's going wrong with the test. >""" > >...a precursor to a self-managed Internet perhaps :) > >anyway, I was wondering if anyone could tell me whether this >program/service was ever implemented and deployed, and whether it was >reported anywhere? (and if not, why not?) > >thanks, > >R. From braden at ISI.EDU Wed Sep 27 14:39:46 2006 From: braden at ISI.EDU (Bob Braden) Date: Wed, 27 Sep 2006 14:39:46 -0700 (PDT) Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? Message-ID: <200609272139.OAA26444@gra.isi.edu> *> *> Pre-1988 BSD TCP (and, indeed, I believe all TCPs) would start by *> sending as close to an entire window's worth of traffic as they could *> (e.g. as fast as the application could stuff the transmission queue, *> data got sent up to the window size). *> Even better: pre-1979 (approx?) Tenex/TOPS20 TCP (Hi, Bill!) retransmitted the entire window every time the retransmit timer went off. Without backoff, I believe. Ouch. We learned better, fast! Bob Braden *> In case of loss, TCP retransmitted only the missing segments, but as *> soon as all losses were recovered from, TCP resumed hammering full *> bursts. So TCP was not go-back-N, but had a sort of strange burstiness *> of the form: *> *> initial burst -- causing loss -- followed by recovery -- followed by *> new burst *> *> Others who were there, please correct, update as appropriate. *> *> Thanks! *> *> Craig *> From braden at ISI.EDU Wed Sep 27 14:49:19 2006 From: braden at ISI.EDU (Bob Braden) Date: Wed, 27 Sep 2006 14:49:19 -0700 (PDT) Subject: [e2e] Perils of TSO Message-ID: <200609272149.OAA26447@gra.isi.edu> *> *> Regarding TSO offload of TCP, early binding has benefits, but also *> costs. One would hope that the offload engine could be upgraded to *> incorporate better practices. Not being able to upgrade will indeed *> enhance the ossification of infrastructure in the Internet, shortening *> the time to its obsolescence. Sometime around 1983, some chip manufacturer came out with a "TCP chip". It scared the IAB quite a lot, since we were well aware that we did not yet have enough experience with TCP design. Indeed, Van Jacobson had not come along yet. It is scary to think what what have happened if TCP of 1983 had been cast into silicon at the time, significantly retarding the introduction of the VJ congestion algorithms. Fortunately, their marketing effort failed ("'TCP'? What is that, a mouth wash?"). Bob Braden *> *> If you design for the past, you get locked into the past. Optimal in *> the short term, but discounting the value of flexibility in the long term. *> *> Need I repeat my rant about designing hot rods rather than family cars? *> Who cares about setting I2 speed records? *> From detlef.bosau at web.de Wed Sep 27 15:34:49 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 28 Sep 2006 00:34:49 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> Message-ID: <451AFC89.6010109@web.de> David P. Reed wrote: > Fred - reasona ble response, but I take issue with your statement that > the goal is "full use ot the bottleneck without overburdening it". > Little's Lemma would suggest that idea is unreasonable. > > In the OS community, we used to have a rule of thumb that operating > above 50% of the service rate of almost any multiplexed resource is > problematic, unless you have a very precise and completely predictable > and constant load. And Odlyzko has shown that enterprises are happy > to run at about 10% capacity in return for lowering other, much more > significant costs (such as jitter, latency, unreliability). > > Perhaps the real message is that obsession with the fantasy that such > a goal is achievable has led to incredibly silly research efforts like > the I2 hotrod compettions. > If I got this right, my spontaneous question is, whether we focus on the right target: Is burstiness our problem? Or is burstiness a conseuqence of flooding a network path which it cannot convey anyway, exactly _because_ we cannot achieve a "perfect TDM behviour"? Wouldn?t this suggest (and I had a short glance at Fred?s answer and perhaps he might contradict here) that we intendedly drop the goal of achieving a full load in favour of a "load dependend ECN" mechanism, i.e. when the load of a link exceeds a certain limit, say 50 % of the bandwidth, any passing packets are stamped with a forward congestion notification. Thus, we would keep the throughput on a limit we cannot exceed anyway, but limit the incomming traffic that way that queues can fullfill their purpose, i.e. interleave the flows and buffer out asynchronous traffic. Perhaps the idea is silly, perhaps its from stoneage and published dozens of times, but its just a spontaneous thought which comes to my mind. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From L.Wood at surrey.ac.uk Wed Sep 27 16:48:17 2006 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 28 Sep 2006 00:48:17 +0100 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451ADA94.2030309@reed.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> Message-ID: <200609272348.AAA04345@cisco.com> At Wednesday 27/09/2006 16:09 -0400, David P. Reed wrote: >Fred - reasona ble response, but I take issue >with your statement that the goal is "full use >ot the bottleneck without overburdening it". >Little's Lemma would suggest that idea is unreasonable. and yet, "full use of the bottleneck without overburdening it" is the ideal goal of satellite communications via geostationary orbit, and of deep space comms. It's just an expression of the desire for efficient link utilization. L. >In the OS community, we used to have a rule of >thumb that operating above 50% of the service >rate of almost any multiplexed resource is >problematic, unless you have a very precise and >completely predictable and constant load. And >Odlyzko has shown that enterprises are happy to >run at about 10% capacity in return for lowering >other, much more significant costs (such as jitter, latency, unreliability). > >Perhaps the real message is that obsession with >the fantasy that such a goal is achievable has >led to incredibly silly research efforts like the I2 hotrod compettions. > > >Fred Baker wrote: >> >>On Sep 26, 2006, at 10:51 AM, Detlef Bosau wrote: >> >>>But what I?m curious about in all (sender) >>>pacing approaches is: Where does the pacing >>>rate stem from? Typically, it?s obtained from >>>one of the numerous TCP formulae (Padhye, >>>Mathis...), but these are first (admittedly >>>rough) estimates and second need some >>>measurements to have an initial value set. >>> >>>Moreover, widely deployed pacing would >>>practically replace the currently used AIMD >>>mechanism for achieving a fair share, because >>>the currently used AIMD probing leads to >>>"microbursts", which means that the TCP sender >>>_exceeds_ its fair share of rate for short >>>periods of time. This doesn?t matter as TCP is >>>not rate controlled. And the final rate is corrected by ACK clocking. >>>How does this work with sender pacing, i.e. putting a leaky bucket >>>or flow shaper or something like that in the TCP sender? >> >> >>The big problem in pacing is determining the >>rate available at the bottleneck. >> >>Let's assume a truly perfect case - the >>bottleneck in the network has a total capacity >>of N bps, and currently there are M sessions >>using it. The M sessions, by magic, are >>operating in perfect TDM fashion - as the last >>bit of one message departs, the first bit of >>the next message becomes ready to send, and no queue ever forms. >> >>Is there room for one more bit on the wire? >>Well, if this was a TDM network, no; something >>would get dropped. But it's not. So we have a >>new sender that decides to start a TCP session >>and sends a SYN. What happens is that his >>packet collides with some other packet, and a >>queue one packet deep results. The new session >>gets very little information about rate out of >>that - there is clearly capacity for at least >>one SYN per RTT available, but he gets no idea >>what he is competing with. But the other M >>sessions get a teensy bit of information - >>their Acks get delayed a few nanoseconds, and >>as a result they send their next data a few >>nanoseconds later. Their average RTT becomes >>some function of sizeof(SYN)/M longer, and as a >>result they each slow down if ever so slightly. >> >>Having no information about all this, the new >>session probes further, sending one or more >>data segments. Let's assume that it sends >>several (if it doesn't do so in the next RTT, >>it will do so in some subsequent one), and that >>the receiver replies with two or more Acks. The >>sender can infer that the capacity at the bottleneck is no smaller than >> >> Bits acknowledged only by second Ack >> ------------------------------------------------- >> Interval between arrivals of first and second Ack >> >>If its K segments were transmitted by the >>bottleneck back to back, this would be a >>measure of the rate of the bottleneck (Keshev). >>If packets from some other segments were >>interleaved, this would give the rate at the >>bottleneck less the capacity used by those >>interleaving segments. It won't EXCEED the rate >>at the bottleneck, but in this example it >>seriously overestimates the capacity unused by >>other sessions and therefore available to the new session at the bottleneck. >> >>Let's assume that it picked some rate and paced >>traffic to that rate. It could do that >>calculation on every Ack it received, and feed >>those into the moving average. There are a >>couple of possible scenarios, the most benign >>of which include "the other sessions all slow >>down so that this traffic all goes through at >>that rate" and "all other sessions cease, so >>that the bottleneck is ONLY carrying this >>session's traffic". In both of these relatively >>benign cases, the above calculation says that >>the rate available is the same number. From the >>sender's perspective, is that because that is >>the rate available at the bottleneck? Or is it >>because that is the rate at which it sent its >>probing traffic? Should it probe at a higher rate? If so, at what rate? >> >>So the new session has to decide to what extent >>it believes this new pice of data. Maybe it >>simply jumps to that new rate. I'll leave the >>analysis to the reader. Or may it includes that >>new rate estimate in some form of moving >>average. If it does things just right, it will >>ramp up its speed at the rate that the sum of >>the competing sessions slow down, and all will >>be cool. Anyone care to lay odds that it would be "just right"? >> >>Now, change the scenario. The bottleneck is >>completely unused. The new session comes up, >>and is trying to infer what capacity is >>available, following the procedures it followed >>to get things "just right". Guess what? It >>asymptotically approaches fully using the link, >>but takes one heck of a long time to get there. >> >>The big problem in pacing is determining the >>rate available at the bottleneck. And by the >>way, bottlenecks would have to have heap big >>magic to operate in anything resembling a TDM fashion. >> >>Operational experience in the ATM world gives >>us another side of this. If you give an ATM VC >>a certain rate and engineer that rate through >>the network, ATM works a lot like TDM works - >>it uses the rate authorized, and doesn't >>over-use it. If you screw up the engineering, ATM acts like it is screwed up. >> >>Hence, I think that what the research, logic, >>and operational experience tell us is that >>while pacing can be useful to break down big >>bursts, in the end pacing doesn't achieve a >>what the Internet community has been trying to >>achieve for a long time, which is full use of >>the bottleneck without overburdening it. We can >>achieve engineered use, like ATM, or we can >>from time to time over-burden a bottleneck, but we can't avoid both. >> >>So I will argue that using pacing for events, >>like spreading out the effect of a sequence of >>lost Acks, can be helpful, but in the end the >>procedures we use in New Reno etc are superior >>in the general case. What we can do to improve >>those procedures might be related to RCP or to >>some of the work that is being done on >>other-than-loss-triggered procedures; we'll >>see. But pacing is not a silver bullet. >> > From perfgeek at mac.com Wed Sep 27 17:02:38 2006 From: perfgeek at mac.com (Rick Jones) Date: Wed, 27 Sep 2006 17:02:38 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <200609271153.16325.zec@tel.fer.hr> References: <20060923103853.426C567@aland.bbn.com> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> <451973E6.5050409@reed.com> <200609271153.16325.zec@tel.fer.hr> Message-ID: <11048837.1159401758631.JavaMail.perfgeek@mac.com> >The question whether or not we can implement fine-grained pacing in software >might be becoming less relevant now that the silicon industry is irreversibly >pushing with TCP segmentation offload implementations in hardware. We industry types have to because the researchers keep adding straws to TCP's back and increasing the path length :) And because the IEEE types won't standardize a larger MTU each time they increase the bit-rate by an order of magnitude... >Given >that the OS typically feeds a TSO engine with at least a 32 or 64 kbyte raw >data chunk per single TCP session, this corresponds to a 22 or 44 segment >wire-speed burst at minimum. Thinking what things might look like if >multiple such streams would get synchronized is quite scarry... If they trigger losses, then the cwnd's kick-in and the TSO's become smaller. rick jones From perfgeek at mac.com Wed Sep 27 17:09:32 2006 From: perfgeek at mac.com (Rick Jones) Date: Wed, 27 Sep 2006 17:09:32 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451ADA94.2030309@reed.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> Message-ID: <3329275.1159402172037.JavaMail.perfgeek@mac.com> >Perhaps the real message is that obsession with the fantasy that such a >goal is achievable has led to incredibly silly research efforts like the >I2 hotrod compettions. Since some of the following put food on my table perhaps I shouldn't ask, but are the I2 hotrod competitions really any worse than: *) SPECsfs *) SPECweb *) netperf *) ttcp *) iperf *) CNN wanting to service N% more concurrent users on existing hardware *) people wanting backups to finish sooner, using less CPU rick jones From dpreed at reed.com Wed Sep 27 17:45:08 2006 From: dpreed at reed.com (David P. Reed) Date: Wed, 27 Sep 2006 20:45:08 -0400 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <99C24D26-8A87-4B4B-AABE-50E84C558169@cisco.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> <451AFC89.6010109@web.de> <99C24D26-8A87-4B4B-AABE-50E84C558169@cisco.com> Message-ID: <451B1B14.6070109@reed.com> The point of Little's Lemma is that the tradeoff for using the full bottleneck bandwidth is asymptotically infinite delay, delay variance, and other statistics. If you value utilization but not response time, of course you can fill the pipes. But end users value response time almost always much higher than twice the throughput. And of course you can give delay-free service to a small percentage of traffic by prioritization, but all that does is make the asymptotic growth of delay and delay variance for the rest of the traffic even worse. Fred Baker wrote: > > On Sep 27, 2006, at 3:34 PM, Detlef Bosau wrote: > >> Wouldn?t this suggest (and I had a short glance at Fred?s answer and >> perhaps he might contradict here) that we intendedly drop the goal of >> achieving a full load in favour of a "load dependend ECN" mechanism, >> i.e. when the load of a link exceeds a certain limit, say 50 % of the >> bandwidth, any passing packets are stamped with a forward congestion >> notification. Thus, we would keep the throughput on a limit we cannot >> exceed anyway, but limit the incomming traffic that way that queues >> can fullfill their purpose, i.e. interleave the flows and buffer out >> asynchronous traffic. > > I certainly encouraged Sally et al to publish RFC 3168, and yes I > would agree that something other than a loss-triggered approach has > real value, especially at STM-n speeds where the difference between > "nominal delay due to queuing" and "loss" is pretty sharp. I don't > think I would pick "50%"; it would be at a higher rate. > > But that actually says about the same thing. Change the mechanism for > detecting when the application isn't going to get a whole lot more > bandwidth even if it jumps the window up by an order of magnitude, but > allow it to maximize throughput and minimize loss in a way that s > responsive to signals from the network. > From detlef.bosau at web.de Thu Sep 28 05:16:31 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 28 Sep 2006 14:16:31 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> Message-ID: <451BBD1F.4060600@web.de> Lachlan Andrew wrote: >> The big problem in pacing is determining the rate available at the >> bottleneck. > > That seems to be confusing rate control with scheduling. > To my understanding, there are quite a few TCP flavours and mechanisms which integrate some kind of rate control. Just to mention TCP Westwood, Equation Based Congestion Control (Widmer, Floyd, Padhye) and I think XCP works in the same direction. And of course TCP (sender) pacing does rate control. > A pacing scheme can measure the RTT and still maintain a "window" > (even though not used as a sliding window), following the standard > rules of (New)Reno/SACK/H-TCP/... > > If we pace packets out at a rate "window / RTT" then we transmit at > the same average rate as if we used ACK-clocking. The only difference > is that the packets are sent with roughly equal spacing in the case of > pacing, and sent irregularly with pure ACK-clocking. > That?s the gerneral idea. I found the following paper useful: > @inproceedings{ aggarwal00understanding, > author = "Amit Aggarwal and Stefan Savage and Thomas Anderson", > title = "Understanding the Performance of {TCP} Pacing", > booktitle = "{INFOCOM} (3)", > pages = "1157-1165", > year = "2000", > url = "citeseer.ist.psu.edu/aggarwal00understanding.html" } > Detlef From detlef.bosau at web.de Thu Sep 28 08:53:42 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 28 Sep 2006 17:53:42 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <3A43F08C-8A83-4E4D-90C0-2A1516E21A81@cisco.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <3A43F08C-8A83-4E4D-90C0-2A1516E21A81@cisco.com> Message-ID: <451BF006.8070201@web.de> Fred Baker wrote: > On Sep 27, 2006, at 7:46 PM, Lachlan Andrew wrote: >> If we pace packets out at a rate "window / RTT" then we transmit at >> the same average rate as if we used ACK-clocking. The only >> difference is that the packets are sent with roughly equal spacing in >> the case of pacing, and sent irregularly with pure ACK-clocking. > > yes. But in my comments, we might do so at a time that we are not > receiving acks that would clock us. > > What Detlef appears to be proposing Oh my goodness ;-) No, I don?t propose this. > is that we pace all the time. Craig's paper and my comments are to the > effect that this is Really Hard to get right, and if it's not right, > it's Really Wrong. That?s what I think as well. I only try to understand a few things. 1.: Is burstiness always a problen? And what I?ve learned so far, this is not the case. Extreme burstiness can lead to overrunning queues and unterutilization of the network. But "little" burstiness is no problem at all. 2.: Where does burstiness stem from? 3: If something should be done against bursty flows: What can be reasonably done? I don?t want to pace all the time. Quite contrary, at the moment I think the problem "burstiness" might be somewhat overestimated. Particularly when it comes to the "chaotic nature" of traffic or "self similarity" or other fine sounding words, that are mentioned simetimes in the academic world and which are always impressive. There are two things important for me. First: What do I know, when I know that traffic is bursty, chaotic, self-similar? What do I learn from that? Second (and this one is a good advice from my professor in statistics): When a behaviour appears to be stochastic, its always crucial to understand where this stochastic beheviour comes from. It says nothing, when e.g. a time series passes numerous tests on "stochastic behaviour" when the reason for this behaviour is not understood. Therefore, I?m always critical when I read papers which "prove" one more the selfsimiliarity of the Intenet by the use of yet another GIGO (garbage in garbage out) statistical program or which deal with sophisticated transformations and wavelets and so on. The more mathematics one has not understood in one's owns paper, the less worth is the result. (I don?t say anything against mathematics. But I always enjoy well done mathematics.) And it?s perhaps similar with burstiness. When there are sources of severe burstiness which lead to problems, it?s beneficial to fix this. However, it?s not worthwile to spend maximum effort for minimum results. So, e.g., what it?s good for to pace a TCP flow with a leaky bucket or something similar, when after two hops the traffic is as bursty as if nothing would have been done? When I read David?s remarks on Little?s theorem, I thought about these well known throughput/window, RTT/window, "utility"/window diagrams which can be found e.g. in Raj Jains paper on delay based congestion control from 1989 (?). I think, it?s essentialy a very similar message: Even if queues are unlimited, it is not only not useful to put arbitrary window sizes on the path, but too large a window may cause severe harm. I always thought on correct dimensioning of router queues, when I read this. O.k. I?m writing to much and thinking to little :-) Detlef From fred at cisco.com Wed Sep 27 13:49:14 2006 From: fred at cisco.com (Fred Baker) Date: Wed, 27 Sep 2006 13:49:14 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451ADA94.2030309@reed.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> Message-ID: <35E00AB3-BBD1-4C62-AC14-9F3FD82AE8EF@cisco.com> I think we're discussing different subjects. Yes, ISPs and large enterprises (and anyone that runs a LAN) routinely run their networks at a relatively low utilization, for a variety of reasons. The subject of this thread has to do with end station expectations and the behavior of TCPs, and specifically whether burst behavior is a problem and whether pacing is helpful. I'll refer you to Nandita Dukkipati and Nick McKeown's arguments (supported by a variety of factors stretching from IBM's 1970's fixation on subsecond response times to transactions to present discussions of what makes a good web site, a large part of which could be described in similar terms, and by the way, note the popularity of bittorrent, configurations of web browsers that move multiple files in in parallel, etc) that end users at the end of the day prefer shorter transaction times to longer ones. Yes, the network wants significant headroom on average. The end user has no motivation to preserve that headroom, however. Faced with the choice of moving a file in one second or ten, the user will pick 50 milliseconds, hands down and every time. So the individual TCP is interested in maximizing throughput rate while minimizing loss. On Sep 27, 2006, at 1:09 PM, David P. Reed wrote: > Fred - reasona ble response, but I take issue with your statement > that the goal is "full use ot the bottleneck without overburdening > it". Little's Lemma would suggest that idea is unreasonable. > > In the OS community, we used to have a rule of thumb that operating > above 50% of the service rate of almost any multiplexed resource is > problematic, unless you have a very precise and completely > predictable and constant load. And Odlyzko has shown that > enterprises are happy to run at about 10% capacity in return for > lowering other, much more significant costs (such as jitter, > latency, unreliability). > > Perhaps the real message is that obsession with the fantasy that > such a goal is achievable has led to incredibly silly research > efforts like the I2 hotrod compettions. > > > Fred Baker wrote: >> >> On Sep 26, 2006, at 10:51 AM, Detlef Bosau wrote: >> >>> But what I?m curious about in all (sender) pacing approaches is: >>> Where does the pacing rate stem from? Typically, it?s obtained >>> from one of the numerous TCP formulae (Padhye, Mathis...), but >>> these are first (admittedly rough) estimates and second need some >>> measurements to have an initial value set. >>> >>> Moreover, widely deployed pacing would practically replace the >>> currently used AIMD mechanism for achieving a fair share, because >>> the currently used AIMD probing leads to "microbursts", which >>> means that the TCP sender _exceeds_ its fair share of rate for >>> short periods of time. This doesn?t matter as TCP is not rate >>> controlled. And the final rate is corrected by ACK clocking. >>> How does this work with sender pacing, i.e. putting a leaky >>> bucket or flow shaper or something like that in the TCP sender? >> >> >> The big problem in pacing is determining the rate available at the >> bottleneck. >> >> Let's assume a truly perfect case - the bottleneck in the network >> has a total capacity of N bps, and currently there are M sessions >> using it. The M sessions, by magic, are operating in perfect TDM >> fashion - as the last bit of one message departs, the first bit of >> the next message becomes ready to send, and no queue ever forms. >> >> Is there room for one more bit on the wire? Well, if this was a >> TDM network, no; something would get dropped. But it's not. So we >> have a new sender that decides to start a TCP session and sends a >> SYN. What happens is that his packet collides with some other >> packet, and a queue one packet deep results. The new session gets >> very little information about rate out of that - there is clearly >> capacity for at least one SYN per RTT available, but he gets no >> idea what he is competing with. But the other M sessions get a >> teensy bit of information - their Acks get delayed a few >> nanoseconds, and as a result they send their next data a few >> nanoseconds later. Their average RTT becomes some function of >> sizeof(SYN)/M longer, and as a result they each slow down if ever >> so slightly. >> >> Having no information about all this, the new session probes >> further, sending one or more data segments. Let's assume that it >> sends several (if it doesn't do so in the next RTT, it will do so >> in some subsequent one), and that the receiver replies with two or >> more Acks. The sender can infer that the capacity at the >> bottleneck is no smaller than >> >> Bits acknowledged only by second Ack >> ------------------------------------------------- >> Interval between arrivals of first and second Ack >> >> If its K segments were transmitted by the bottleneck back to back, >> this would be a measure of the rate of the bottleneck (Keshev). If >> packets from some other segments were interleaved, this would give >> the rate at the bottleneck less the capacity used by those >> interleaving segments. It won't EXCEED the rate at the bottleneck, >> but in this example it seriously overestimates the capacity unused >> by other sessions and therefore available to the new session at >> the bottleneck. >> >> Let's assume that it picked some rate and paced traffic to that >> rate. It could do that calculation on every Ack it received, and >> feed those into the moving average. There are a couple of possible >> scenarios, the most benign of which include "the other sessions >> all slow down so that this traffic all goes through at that rate" >> and "all other sessions cease, so that the bottleneck is ONLY >> carrying this session's traffic". In both of these relatively >> benign cases, the above calculation says that the rate available >> is the same number. From the sender's perspective, is that because >> that is the rate available at the bottleneck? Or is it because >> that is the rate at which it sent its probing traffic? Should it >> probe at a higher rate? If so, at what rate? >> >> So the new session has to decide to what extent it believes this >> new pice of data. Maybe it simply jumps to that new rate. I'll >> leave the analysis to the reader. Or may it includes that new rate >> estimate in some form of moving average. If it does things just >> right, it will ramp up its speed at the rate that the sum of the >> competing sessions slow down, and all will be cool. Anyone care to >> lay odds that it would be "just right"? >> >> Now, change the scenario. The bottleneck is completely unused. The >> new session comes up, and is trying to infer what capacity is >> available, following the procedures it followed to get things >> "just right". Guess what? It asymptotically approaches fully using >> the link, but takes one heck of a long time to get there. >> >> The big problem in pacing is determining the rate available at the >> bottleneck. And by the way, bottlenecks would have to have heap >> big magic to operate in anything resembling a TDM fashion. >> >> Operational experience in the ATM world gives us another side of >> this. If you give an ATM VC a certain rate and engineer that rate >> through the network, ATM works a lot like TDM works - it uses the >> rate authorized, and doesn't over-use it. If you screw up the >> engineering, ATM acts like it is screwed up. >> >> Hence, I think that what the research, logic, and operational >> experience tell us is that while pacing can be useful to break >> down big bursts, in the end pacing doesn't achieve a what the >> Internet community has been trying to achieve for a long time, >> which is full use of the bottleneck without overburdening it. We >> can achieve engineered use, like ATM, or we can from time to time >> over-burden a bottleneck, but we can't avoid both. >> >> So I will argue that using pacing for events, like spreading out >> the effect of a sequence of lost Acks, can be helpful, but in the >> end the procedures we use in New Reno etc are superior in the >> general case. What we can do to improve those procedures might be >> related to RCP or to some of the work that is being done on other- >> than-loss-triggered procedures; we'll see. But pacing is not a >> silver bullet. >> >> From lachlan.andrew at gmail.com Wed Sep 27 16:20:49 2006 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 27 Sep 2006 16:20:49 -0700 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> <4514D590.9010201@nuim.ie> <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> Message-ID: Greetings all, On 23/09/06, rhee at ncsu.edu wrote: > Just i was pondering why we got different results and try to see if we can > come to some understanding on this different results we got. Who knows we > together might run into some fundamental research issues regarding > testing. Since many interested parties will be around LA for PFLDnet, how about getting together after that (Friday 9 Feb) to re-run some of the disputed tests on one set of hardware, with everyone present to debate the results? You're all welcome to come to Caltech to do the testing. We can provide a few servers, dummynets and Gigabit switches. Everyone is welcome to bring their scripts, and any other hardware they need. If there is interest, we could also have things like a round-table discussion of the benefits of testing with different file-length distributions (like long lived flows to understand what is happening vs a range of flows to test suitability for deployment), and the benefits of repeating other people's tests vs testing in as many scenarios as possible. Who is interested in coming? Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From fred at cisco.com Wed Sep 27 16:48:49 2006 From: fred at cisco.com (Fred Baker) Date: Wed, 27 Sep 2006 16:48:49 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451AFC89.6010109@web.de> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> <451AFC89.6010109@web.de> Message-ID: <99C24D26-8A87-4B4B-AABE-50E84C558169@cisco.com> On Sep 27, 2006, at 3:34 PM, Detlef Bosau wrote: > Wouldn?t this suggest (and I had a short glance at Fred?s answer > and perhaps he might contradict here) that we intendedly drop the > goal of achieving a full load in favour of a "load dependend ECN" > mechanism, i.e. when the load of a link exceeds a certain limit, > say 50 % of the bandwidth, any passing packets are stamped with a > forward congestion notification. Thus, we would keep the throughput > on a limit we cannot exceed anyway, but limit the incomming traffic > that way that queues can fullfill their purpose, i.e. interleave > the flows and buffer out asynchronous traffic. I certainly encouraged Sally et al to publish RFC 3168, and yes I would agree that something other than a loss-triggered approach has real value, especially at STM-n speeds where the difference between "nominal delay due to queuing" and "loss" is pretty sharp. I don't think I would pick "50%"; it would be at a higher rate. But that actually says about the same thing. Change the mechanism for detecting when the application isn't going to get a whole lot more bandwidth even if it jumps the window up by an order of magnitude, but allow it to maximize throughput and minimize loss in a way that s responsive to signals from the network. From lachlan.andrew at gmail.com Wed Sep 27 19:46:36 2006 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 27 Sep 2006 19:46:36 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> Message-ID: Greetings Fred, On 26/09/06, Fred Baker wrote: > On Sep 26, 2006, at 10:51 AM, Detlef Bosau wrote: > > The big problem in pacing is determining the rate available at the > bottleneck. That seems to be confusing rate control with scheduling. A pacing scheme can measure the RTT and still maintain a "window" (even though not used as a sliding window), following the standard rules of (New)Reno/SACK/H-TCP/... If we pace packets out at a rate "window / RTT" then we transmit at the same average rate as if we used ACK-clocking. The only difference is that the packets are sent with roughly equal spacing in the case of pacing, and sent irregularly with pure ACK-clocking. Am I missing something? Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From fred at cisco.com Thu Sep 28 08:07:29 2006 From: fred at cisco.com (Fred Baker) Date: Thu, 28 Sep 2006 08:07:29 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> Message-ID: <3A43F08C-8A83-4E4D-90C0-2A1516E21A81@cisco.com> On Sep 27, 2006, at 7:46 PM, Lachlan Andrew wrote: > If we pace packets out at a rate "window / RTT" then we transmit at > the same average rate as if we used ACK-clocking. The only > difference is that the packets are sent with roughly equal spacing > in the case of pacing, and sent irregularly with pure ACK-clocking. yes. But in my comments, we might do so at a time that we are not receiving acks that would clock us. What Detlef appears to be proposing is that we pace all the time. Craig's paper and my comments are to the effect that this is Really Hard to get right, and if it's not right, it's Really Wrong. From fred at cisco.com Thu Sep 28 08:43:43 2006 From: fred at cisco.com (Fred Baker) Date: Thu, 28 Sep 2006 08:43:43 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451B1B14.6070109@reed.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> <451AFC89.6010109@web.de> <99C24D26-8A87-4B4B-AABE-50E84C558169@cisco.com> <451B1B14.6070109@reed.com> Message-ID: That is of course mostly true. I'll quibble on Little's result: it says (in the immortal words of the wikipedia) "The average number of customers in a stable system (over some time interval) is equal to their average arrival rate, multiplied by their average time in the system." What you're referring to in this context is the set of formulae related to delay, variance, etc, in non-deterministic statistical systems, which are each inversely proportional to some variation on (one minus the utilization), which approaches a limit of zero. But your observation regarding those equations tending to infinity at full utilization is correct. The point is that while a network operator values headroom in the average case, as you aptly note, the network user values response time. Now, if he says he wants to look at a ten megabyte file (think YouTube) and values response time, his proxy (TCP) needs to maximize throughput in order to minimize elapsed time. Hence, TCP values throughput, and it does so because its user values response time. Take a good look at the various congestion management algorithms used in TCPs over the years, and what they have all tried to do is maximize throughput, detect the point where utilization at the bottleneck approaches 100% (whether by measuring loss resulting from going over the top or by measuring the increase in delay that you point us to), and then back off a little bit. TCP seeks to maximize throughput. Something else that is very important in this context is the matter of time scale. When a network operator measures capacity used, he most commonly points to an MRTG trace. MRTG samples SNMP counters every 300 seconds and plots the deltas between their values. You no doubt recall T-shirts from a decade ago or more that said something about "same day service in a nanosecond world". MRTG traces, is as useful as they are in monitoring trends, are not very useful in telling us about individual TCPs. The comparison is a little like putting a bump counter in Times Square, reading it at a random time of day once a month, and making deep remarks about the behavior of traffic at rush hour. They don't give you that data. I'd encourage, as an alternative, http://www.ieee-infocom.org/2004/ Papers/37_4.PDF. This looks at real traffic in the Sprint network a few years ago and analyzes traffic behavior. It makes three important observations: - with 90% confidence, POP-POP variation in delay within the network is less than one ms. - also with 90% confidence, POP-POP delay variation spikes to ~10 ms frequently. - on occasion (six times in the study), POP-POP delay varies by as much as 100 ms, and in so doing follows a pattern whose characteristics are consistent with the intersection of high rate data streams, not measurement error or router misbehavior as some have suggested. Note that these are POP-POP, not CPE-CPE; the study says nothing about access networks or access links. It talks about the part of the network that Sprint engineered. They don't show what the 10 ms spikes look like, but I will conjecture that they are smaller versions of the six samples they did display, and similarly suggest the momentary intersection of high rate data streams. What this tells me, coupled with my knowledge of routers and various applications, is that even within a large and well engineered ISP network (Sprint's is among the best in the world, IMHO) there are times when total throughput on a link hits 100% and delay ramps up. If they are running delay-sensitive or loss-sensitive services, it will be wise on their part to put in simple queuing mechanisms such as those suggested in draft-ietf-tsvwg-diffserv-class-aggr-00.txt to stabilize the service during such events. The overall effect will be negligible, but it will materially help in maintaining the stability of routing and of real time services. SImply adding bandwidth helps immeasurably, but measurement tells me that it is not a final solution. On Sep 27, 2006, at 5:45 PM, David P. Reed wrote: > The point of Little's Lemma is that the tradeoff for using the full > bottleneck bandwidth is asymptotically infinite delay, delay > variance, and other statistics. > > If you value utilization but not response time, of course you can > fill the pipes. > But end users value response time almost always much higher than > twice the throughput. > > And of course you can give delay-free service to a small percentage > of traffic by prioritization, but all that does is make the > asymptotic growth of delay and delay variance for the rest of the > traffic even worse. > > > Fred Baker wrote: >> >> On Sep 27, 2006, at 3:34 PM, Detlef Bosau wrote: >> >>> Wouldn?t this suggest (and I had a short glance at Fred?s answer >>> and perhaps he might contradict here) that we intendedly drop the >>> goal of achieving a full load in favour of a "load dependend ECN" >>> mechanism, i.e. when the load of a link exceeds a certain limit, >>> say 50 % of the bandwidth, any passing packets are stamped with >>> a forward congestion notification. Thus, we would keep the >>> throughput on a limit we cannot exceed anyway, but limit the >>> incomming traffic that way that queues can fullfill their >>> purpose, i.e. interleave the flows and buffer out asynchronous >>> traffic. >> >> I certainly encouraged Sally et al to publish RFC 3168, and yes I >> would agree that something other than a loss-triggered approach >> has real value, especially at STM-n speeds where the difference >> between "nominal delay due to queuing" and "loss" is pretty sharp. >> I don't think I would pick "50%"; it would be at a higher rate. >> >> But that actually says about the same thing. Change the mechanism >> for detecting when the application isn't going to get a whole lot >> more bandwidth even if it jumps the window up by an order of >> magnitude, but allow it to maximize throughput and minimize loss >> in a way that s responsive to signals from the network. >> From touch at ISI.EDU Thu Sep 28 09:04:24 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 28 Sep 2006 09:04:24 -0700 Subject: [e2e] a note from your list admin about posting delays In-Reply-To: <451BF006.8070201@web.de> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <3A43F08C-8A83-4E4D-90C0-2A1516E21A81@cisco.com> <451BF006.8070201@web.de> Message-ID: <451BF288.3020408@isi.edu> Hi, all, Some recent messages to this list have been 'held for review' because they were sent cc'd to the list rather than sent directly. To avoid unnecessary delays, please: - send posts TO the list directly - limit the number of cross-posts (other TO's and CC's) (to under 5, or omit entirely) FYI... Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060928/1d13b3c8/signature.bin From zec at tel.fer.hr Thu Sep 28 09:39:20 2006 From: zec at tel.fer.hr (Marko Zec) Date: Thu, 28 Sep 2006 18:39:20 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <11048837.1159401758631.JavaMail.perfgeek@mac.com> References: <20060923103853.426C567@aland.bbn.com> <200609271153.16325.zec@tel.fer.hr> <11048837.1159401758631.JavaMail.perfgeek@mac.com> Message-ID: <200609281839.20384.zec@tel.fer.hr> On Thursday 28 September 2006 02:02, Rick Jones wrote: > >The question whether or not we can implement fine-grained pacing in > > software might be becoming less relevant now that the silicon industry is > > irreversibly pushing with TCP segmentation offload implementations in > > hardware. > > We industry types have to because the researchers keep adding straws to > TCP's back and increasing the path length :) And because the IEEE types > won't standardize a larger MTU each time they increase the bit-rate by an > order of magnitude... > > >Given > >that the OS typically feeds a TSO engine with at least a 32 or 64 kbyte > > raw data chunk per single TCP session, this corresponds to a 22 or 44 > > segment wire-speed burst at minimum. Thinking what things might look > > like if multiple such streams would get synchronized is quite scarry... > > If they trigger losses, then the cwnd's kick-in and the TSO's become > smaller. It's obvious that doing hardware TSO for say an 8 K data chunk, i.e. 5 segments, provides great savings in terms of CPU cycles and I/O bus utilization spent on transmitting TCP streams. But what is the performance gain for going up from 8 K / 5 segment TSO to 64 K / 44 segment bursts, knowing that bursts that large clearly coudl be a double-edged sword? In other words, how large the TSO bursts could be considered tolerable and justified - roughly where should we draw the line? Marko From rhee at eos.ncsu.edu Thu Sep 28 09:58:02 2006 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Thu, 28 Sep 2006 12:58:02 -0400 Subject: [e2e] Stability of various TCP protocols [CUBIC, BIC, HTCP, HSTCP, STCP] Message-ID: <00d301c6e31f$4304fed0$4a580e98@ncsu2cc0c3fa00> Hi, I'd like to report on a measurement study regarding the stability of various TCP variant protocols. Although we can find quite a bit of work on fairness and convergence of protocols (including some theoretical studies on the topic as well), there is relatively little work on measuring the stability of protocols and its impact on protocol performance and overall health of the networks (e.g., the overall queue fluctions and link utilization). We have measured the degree of rate oscillation and fluctuation of protocols to have some understanding of protocol stability. We would like to share our results with you to get some feedback from the community. We have some theoretical results and also experimental results. Here is the link to the experimental results. You can find links to all of our experimental data that include results from several hundred experiments. http://netsrv.csc.ncsu.edu/convex-ordering/ If you need our report on theoretical results, we can e-mail you the report. Injong Rhee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060928/c42cf65c/attachment.html From rhee at eos.ncsu.edu Thu Sep 28 09:33:32 2006 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Thu, 28 Sep 2006 12:33:32 -0400 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> <4514D590.9010201@nuim.ie> <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> Message-ID: <00c401c6e31b$d75c9970$4a580e98@ncsu2cc0c3fa00> Sure. I don't mind doing this test. I am currently working with Doug Leith to get to the bottom of this difference. So when we get to the PFLDnet, we should have some more findings on this. But I am up for this challenge. ----- Original Message ----- From: "Lachlan Andrew" To: Cc: "Douglas Leith" ; ; ; ; "Injong Rhee" ; Sent: Wednesday, September 27, 2006 7:20 PM Subject: Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc > Greetings all, > > On 23/09/06, rhee at ncsu.edu wrote: >> Just i was pondering why we got different results and try to see if we >> can >> come to some understanding on this different results we got. Who knows we >> together might run into some fundamental research issues regarding >> testing. > > Since many interested parties will be around LA for PFLDnet, how about > getting together after that (Friday 9 Feb) to re-run some of the > disputed tests on one set of hardware, with everyone present to debate > the results? > > You're all welcome to come to Caltech to do the testing. We can > provide a few servers, dummynets and Gigabit switches. Everyone is > welcome to bring their scripts, and any other hardware they need. > > If there is interest, we could also have things like a round-table > discussion of the benefits of testing with different file-length > distributions (like long lived flows to understand what is happening > vs a range of flows to test suitability for deployment), and the > benefits of repeating other people's tests vs testing in as many > scenarios as possible. > > Who is interested in coming? > > Cheers, > Lachlan > > -- > Lachlan Andrew Dept of Computer Science, Caltech > 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA > Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 > From faber at ISI.EDU Thu Sep 28 16:03:00 2006 From: faber at ISI.EDU (Ted Faber) Date: Thu, 28 Sep 2006 16:03:00 -0700 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> <4514D590.9010201@nuim.ie> <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> Message-ID: <20060928230300.GA22894@hut.isi.edu> On Wed, Sep 27, 2006 at 04:20:49PM -0700, Lachlan Andrew wrote: > Greetings all, > > On 23/09/06, rhee at ncsu.edu wrote: > >Just i was pondering why we got different results and try to see if we can > >come to some understanding on this different results we got. Who knows we > >together might run into some fundamental research issues regarding > >testing. > > Since many interested parties will be around LA for PFLDnet, how about > getting together after that (Friday 9 Feb) to re-run some of the > disputed tests on one set of hardware, with everyone present to debate > the results? > > You're all welcome to come to Caltech to do the testing. We can > provide a few servers, dummynets and Gigabit switches. Everyone is > welcome to bring their scripts, and any other hardware they need. > > If there is interest, we could also have things like a round-table > discussion of the benefits of testing with different file-length > distributions (like long lived flows to understand what is happening > vs a range of flows to test suitability for deployment), and the > benefits of repeating other people's tests vs testing in as many > scenarios as possible. > > Who is interested in coming? It might be easier to do this on DETER: http://www.isi.edu/deter http://www.isi.deterlab.net/doc.php3 That's a testbed at ISI running an Emulab configured for more secure experimentation. Though security is a focus of the testbed, I believe that the admins of DETER would approve a project to recreate this study and work out the inconsistencies. With DETER you could start tomorrow and have a reproducible collaborative test environment that would outlast a week meeting at Caltech. Like all Emulab installations, DETER gives you full root access to the machines, the ability to load complete kernels on the nodes, provides GB/s connectivity between nodes as well as an ns interface that configures dummynet nodes to provide delay and throttling. I've used the testbed a fair amount, and it's tough to think of a better environment for this kind of collaboration. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060928/33e6b91b/attachment.bin From detlef.bosau at web.de Thu Sep 28 16:35:26 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 29 Sep 2006 01:35:26 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451973FD.50009@ieee.org> References: <20060925142037.112C067@aland.bbn.com> <8f884bb031b3678c4b56874456ec25aa@mac.com> <45196A07.8080102@web.de> <451973FD.50009@ieee.org> Message-ID: <451C5C3E.6080209@web.de> Sireen Malik wrote: > A few pointers.... > > Web-pages have large variance - enough to start another discussion of > heavy-tailed distributions ;-) This is one source of burstiness. Hard > to cure! Or, is it? > I wonder, if this needs a cure at all! What do we learn from the heavy tailed distributions of web pages? I don?t know the numbers, but does this mean that e.g. 95 % of webpages contain less than 20 kBytes of data? Of course, wenn these pages are visited and thousands of senders send some kbytes of data, the traffic might be "not very smooth". But I think, if this caused a problem, we did something fundamentally wrong. It?s perhaps the basic question: How telco-like shall the Internet become? > TCP is bursty, too. It's like an on-off source: A bunch of packets are > sent in a window in the on-phase, etc. Not quite. This discussion ignores ACK clocking. Ideally, TCP should not be bursty. Ideally (Freds remaks on TDM like behaviour) TCP packets and ACK packets shall form an evenly spaced packet train which wraps around downstream and upstream. At least, that?s the idea behind the congavoid paper and following ones. And that?s the idea behind a huge number of NS2 simulations with some few flows which are well behaved and work as desired. On the other hand, people look at the Internet, observe things like "self similarity" and I don?t know whether we unterstand the reasons for this claimed ( I?m not fully convinced of that. Many of theses papers present a more or less "few observations proof", so I?m somewhat reluctant on this one...) behaviour. > People ahve argued about "shaping" TCP packet generation process to > address this burstiness at small time scales. Look for Biplab Sikdar > paper from this century. My ex-colleague at TUHH Dirk Abendroth also > did a take on this. > > Mark Crovella, et. al showed that under heavy loss conditions, TCP > causes pseduo self-similarity. > Does he give a formal proof for this? And what are the lessons learned from that? Perhaps it?s a very personal problem: I once suggested a mechanism called PTE. And now, I?m looking for a problem suitable for this solution. (I?m afraid there could be none.) And during this search, I thought about burstiness of TCP again and again. Now, one question is: Does PTE, pacing, whatever significantly impact burstiness? Or is burstiness on a single flow irrelevant (it most likely is)? A second question is: Does burstiness stem from one major reason or are there a couple of reasons? (I think, it?s a couple of reasons.) Third: How can we keep burstiness in acceptable limits? Detlef From perfgeek at mac.com Fri Sep 29 08:49:34 2006 From: perfgeek at mac.com (rick jones) Date: Fri, 29 Sep 2006 08:49:34 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <200609281839.20384.zec@tel.fer.hr> References: <20060923103853.426C567@aland.bbn.com> <200609271153.16325.zec@tel.fer.hr> <11048837.1159401758631.JavaMail.perfgeek@mac.com> <200609281839.20384.zec@tel.fer.hr> Message-ID: <0b46688bfb6b82fde1d5683c842390a1@mac.com> > It's obvious that doing hardware TSO for say an 8 K data chunk, i.e. 5 > segments, provides great savings in terms of CPU cycles and I/O bus > utilization spent on transmitting TCP streams. But what is the > performance > gain for going up from 8 K / 5 segment TSO to 64 K / 44 segment bursts, > knowing that bursts that large clearly coudl be a double-edged sword? One of those wonderful "it depends" sorts of things. If you have zero-copy, the diminishing returns are father out than if there is still a non-trivial per-byte cost (eg from copying from user to kernel). CKO and zero-copy address per-byte costs, TSO the per-packet. And as the TSO offload is increased, ACK processing becomes a greater and greater percentage of the CPU overhead, which gives rise to incentives for ACK avoidance heuristics :) > In other words, how large the TSO bursts could be considered tolerable > and > justified - roughly where should we draw the line? There is no line - at least not in the sense that we can say categorically "N burst good, M burst bad" because it will vary with the conditions. I'm content to let the admin have control over the maximum size of the TSO offload, the routers drop packets and/or set ECN, and a congestion control algorithm to keep things from melting and leave it at that. rick jones there is no rest for the wicked, yet the virtuous have no pillows From detlef.bosau at web.de Fri Sep 29 13:21:30 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 29 Sep 2006 22:21:30 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451D5E71.7090108@ieee.org> References: <20060925142037.112C067@aland.bbn.com> <8f884bb031b3678c4b56874456ec25aa@mac.com> <45196A07.8080102@web.de> <451973FD.50009@ieee.org> <451C5C3E.6080209@web.de> <451D5E71.7090108@ieee.org> Message-ID: <451D804A.5090007@web.de> Sireen Malik wrote: >> > Heavy-tailed sized files cause correlated arrivals of packets. Large > variance in file sizes causes correlations on large time scales. This > is why this is called long range memory, or long range dependence (LRD). I haven?t read all the relevant papers yet, but hasn?t been there some rumour that these LRD need at least a minimum buffer size on the routers? In other words: If we take care not to configure buffers too large, would this cure the problem? >> Not quite. This discussion ignores ACK clocking. Ideally, TCP should >> not be bursty. Ideally (Freds remaks on TDM like behaviour) TCP >> packets and ACK packets shall form an evenly spaced packet train >> which wraps around downstream and upstream. >> At least, that?s the idea behind the congavoid paper and following ones. >> > It has been argued that RTTs have a heavy-tailed distribution! > Really? I don?t believe this for practical cases. If RTT would have a heavy-tailed distribution it must be able to take arbitrary long values. In other words: This argument assumes and holds with infinite router queues. Due to some lack of silicon in the universe, router queues are necessariley finite ;-) In addition: Sometimes I read of "burst intervals" with several hours. So, there should be some autoregressive proces on a line which oscillates with a period of several hours. Doesn?t that assume that there exist e.g. TCP connections which exist long enough to produce such a behaviour? In other words: Are this results based on realistic system models? Are the system models used here "result oriented"? Or "reality oriented"? ;-) If we consider TCP and ACK packets as "energy" and consider how this energy is distributed in queues and links, so all this osciallating behaviour is a result of redistribution of energy, as in any oscillating symstem, right? Now when, say (I don?t know! I would appreciate actual statistics here!) one TCP flow in 10000 lasts longer than half an hour and so can exhibit a self similar behaviour, does this flow contain enough enegery to cause a problem to the whole system? Or couldn?t we simply ignore it? > > > > From faber at ISI.EDU Fri Sep 29 15:23:14 2006 From: faber at ISI.EDU (Ted Faber) Date: Fri, 29 Sep 2006 15:23:14 -0700 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> <4514D590.9010201@nuim.ie> <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> <20060928230300.GA22894@hut.isi.edu> Message-ID: <20060929222314.GK38884@hut.isi.edu> On Fri, Sep 29, 2006 at 09:00:02AM -0700, Lachlan Andrew wrote: > On 28/09/06, Ted Faber wrote: > >It might be easier to do this on DETER: > > > >http://www.isi.edu/deter > >http://www.isi.deterlab.net/doc.php3 > > Thanks for your input, Ted. Caltech's WAN-in-Lab also allows a > reproducible collaborative environment that could be used before > and/or after the meeting, but I think it is useful having face-to-face > contact in addition to remote collaboration. Sorry, I hadn't heard of it. I'm assuming this is it: http://wil.cs.caltech.edu/ FWIW the links to the WiL reports on http://wil.cs.caltech.edu/publications/papers.php (specifically http://wil.cs.caltech.edu/pubs/CRI-workshop-2006.pdf and http://wil.cs.caltech.edu/pubs/WiL-terena06.pdf ) seem to be off-line. I'm curious to read them. It sounded like you were suggesting something different - an in-person bake-off. While I think it's great to talk face-to-face, with as much interest as there seems to be in these measurements, it seems like reproducing the results in a way that the interested parties could all play with them while interest is high would be a good idea. We are networking people; I'm assuming we could look at this without being in the same room. Beyond a casual interest in this - I'm not working on congestion control right now - it really doesn't matter to me which collaborative testing environment people use or indeed if they take up the challenge at all. Full disclosure: some of my time is spent these days working on DETER, so I'm directly familiar with it and supporting it. But if you all hiked off to Emulab or WiL to do this, I wouldn't lose a wink of sleep. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060929/5ee3e2a6/attachment.bin From detlef.bosau at web.de Fri Sep 29 15:47:08 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 30 Sep 2006 00:47:08 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451D9EFC.8080707@ieee.org> References: <20060925142037.112C067@aland.bbn.com> <8f884bb031b3678c4b56874456ec25aa@mac.com> <45196A07.8080102@web.de> <451973FD.50009@ieee.org> <451C5C3E.6080209@web.de> <451D5E71.7090108@ieee.org> <451D7943.6060405@web.de> <451D9EFC.8080707@ieee.org> Message-ID: <451DA26C.6010604@web.de> Sireen Malik wrote: > > Ofcourse heavy-tails in reality are "truncated" . Their core idea > being that the probability of a large variate is finite. For example, > most packets arrive with 10msec delay but one packet arrives with 1 > sec (or more) delay! To be honest, I dont know what are the typical > buffer sizes these days but I think the trend has not changed towards > "small buffer" as yet. That doesn?t matter. Actual buffer sizes are implementation. Not science. The question is: Do small buffers cure the problem? And if so and there is no compelling reason for large buffers, the horse is dead and we shall dismount. (This may sound somewhat sarcastic. But it?s _exactly_ that way: When you discover that you?re riding a dead horse: dismount.) From lachlan.andrew at gmail.com Fri Sep 29 09:00:02 2006 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 29 Sep 2006 09:00:02 -0700 Subject: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc In-Reply-To: <20060928230300.GA22894@hut.isi.edu> References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00> <4514D590.9010201@nuim.ie> <56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu> <20060928230300.GA22894@hut.isi.edu> Message-ID: On 28/09/06, Ted Faber wrote: > On Wed, Sep 27, 2006 at 04:20:49PM -0700, Lachlan Andrew wrote: > > Greetings all, > > > > Since many interested parties will be around LA for PFLDnet, how about > > getting together after that (Friday 9 Feb) to re-run some of the > > disputed tests on one set of hardware, with everyone present to debate > > the results? > > > > You're all welcome to come to Caltech to do the testing. We can > > provide a few servers, dummynets and Gigabit switches. Everyone is > > welcome to bring their scripts, and any other hardware they need. > > > > If there is interest, we could also have things like a round-table > > discussion of the benefits of testing with different file-length > > distributions (like long lived flows to understand what is happening > > vs a range of flows to test suitability for deployment), and the > > benefits of repeating other people's tests vs testing in as many > > scenarios as possible. > > > > Who is interested in coming? > > It might be easier to do this on DETER: > > http://www.isi.edu/deter > http://www.isi.deterlab.net/doc.php3 Thanks for your input, Ted. Caltech's WAN-in-Lab also allows a reproducible collaborative environment that could be used before and/or after the meeting, but I think it is useful having face-to-face contact in addition to remote collaboration. (I didn't mention WAN-in-Lab explicitly in the previous email, since these experiments would probably not be using the optical links which make WAN-in-Lab unique, but the remote access infrastructure could still be used.) Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From detlef.bosau at web.de Fri Sep 29 17:44:11 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 30 Sep 2006 02:44:11 +0200 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <99C24D26-8A87-4B4B-AABE-50E84C558169@cisco.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de> <451ADA94.2030309@reed.com> <451AFC89.6010109@web.de> <99C24D26-8A87-4B4B-AABE-50E84C558169@cisco.com> Message-ID: <451DBDDB.1010003@web.de> Fred Baker wrote: > > I certainly encouraged Sally et al to publish RFC 3168, and yes I > would agree that something other than a loss-triggered approach has > real value, especially at STM-n speeds where the difference between > "nominal delay due to queuing" and "loss" is pretty sharp. Does somebody happen to know, whether there is some literature on this? > I don't think I would pick "50%"; it would be at a higher rate. > Of course. And I?m not sure whether there exists one such "load threshold" for all cases. But I could imagine that suitable values can be found particularly for backbone lines where the traffic pattern is perhaps pretty well known and predictable. Detlef From jheffner at psc.edu Sat Sep 30 10:10:18 2006 From: jheffner at psc.edu (John Heffner) Date: Sat, 30 Sep 2006 18:10:18 +0100 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <0b46688bfb6b82fde1d5683c842390a1@mac.com> References: <20060923103853.426C567@aland.bbn.com> <200609271153.16325.zec@tel.fer.hr> <11048837.1159401758631.JavaMail.perfgeek@mac.com> <200609281839.20384.zec@tel.fer.hr> <0b46688bfb6b82fde1d5683c842390a1@mac.com> Message-ID: <451EA4FA.1000301@psc.edu> rick jones wrote: >> It's obvious that doing hardware TSO for say an 8 K data chunk, i.e. 5 >> segments, provides great savings in terms of CPU cycles and I/O bus >> utilization spent on transmitting TCP streams. But what is the >> performance >> gain for going up from 8 K / 5 segment TSO to 64 K / 44 segment bursts, >> knowing that bursts that large clearly coudl be a double-edged sword? > > One of those wonderful "it depends" sorts of things. If you have > zero-copy, the diminishing returns are father out than if there is still > a non-trivial per-byte cost (eg from copying from user to kernel). CKO > and zero-copy address per-byte costs, TSO the per-packet. > > And as the TSO offload is increased, ACK processing becomes a greater > and greater percentage of the CPU overhead, which gives rise to > incentives for ACK avoidance heuristics :) > >> In other words, how large the TSO bursts could be considered tolerable >> and >> justified - roughly where should we draw the line? > > There is no line - at least not in the sense that we can say > categorically "N burst good, M burst bad" because it will vary with the > conditions. I'm content to let the admin have control over the maximum > size of the TSO offload, the routers drop packets and/or set ECN, and a > congestion control algorithm to keep things from melting and leave it at > that. I like to think of bursts as time rather than packets or bytes. I believe this to be a relatively scalable way to think about it. While it's true that there's really no absolute way to know that any particular burst size is okay or not, I think it's likely the case that a sub-millisecond burst is okay, and one that lasts tens of milliseconds is likely not. This gets into the range where buffers in a lot of production hardware can be overflowed, humans can notice the jitter, and it's likely to cause significant RTT spikes, especially if a few occur at the same time. Especially in the case of TSO, there's close to zero benefit to sending TSO segments that are longer than 1ms of bottleneck wire time, as the TCP processing load for that packet rate is going to be well under 0.1% on a modern machine. Incidentally, I cooked up a patch last week (I should in to netdev soon) to limit TSO segment size on slow connections based on packet time, not just fraction of the window size. At GigE speeds, I haven't seen in practice that a 64k burst (about 0.5ms) is ever a problem. -John From jheffner at psc.edu Sat Sep 30 11:23:41 2006 From: jheffner at psc.edu (John Heffner) Date: Sat, 30 Sep 2006 19:23:41 +0100 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de> <232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com> Message-ID: <451EB62D.4090100@psc.edu> Fred Baker wrote: > > On Sep 25, 2006, at 3:42 PM, Ritesh Kumar wrote: > >> The paper presents many details but the gist is that when TCP is >> paced, it takes very little time for the bottleneck queue to build up >> from nothing to the full queue size. > > actually, I'm not sure that ack clocking that worked perfectly (all > traffic is evenly paced throughout the RTT) or pacing that worked > perfectly would behave much differently in any given RTT. The big issue > with pacing in every RTT is that it is every RTT - you never step back > to being ack clocked and as a result are not responsive to the > millisecond-to-millisecond variations inherent in the network. > > My thought is that there are a few cases where you would like to use a > pacing algorithm to deal with momentary events, like when some > implementations get their input blocked and so throw away ACKs for a > while and then suddenly get an Ack that appears to permit them to send a > large volume all at once. Using some appropriate trigger, such as "the > current combination of effective window and available data permits me to > send more than N segments in a burst", I would hope it would send > whatever it chose to send at approximately cwnd/srtt. So there are multiple definitions of the term "pacing". :) I agree rate-based pacing is most likely not a good idea (for TCP -- some protocols are inherently rate-based). To expand on Fred's thoughts, I believe there are significant benefits to "pacing" meaning introducing an additional clock source other than acks, so you can spread out bursts. There are a number of cases where this can definitely help: 1) Big acks, due to thinning or lost acks 2) Compressed acks 3) Big writes or reads (i.e., big window updates) from inherently bursty applications. An example would be a filesystem-limited transfer, where you have frequently have to to stall a few ms for disk seeks. A CPU-bound application on a time-slicing system would be another example. Less clear: 4) Slow start The current state of the art in TCP is to either just send the burst (particularly in the case of compressed ACKs), or to reduce cwnd to avoid sending the burst. Sending the burst may overflow short queues, having a detrimental effect on performance, and/or create significant jitter. Reducing cwnd has a detrimental effect on performance, particularly at large window sizes, where the impact of a single reduction due to a transient event can be felt for hundreds of round-trip-times. (Issues with the responsiveness of congestion control obviously come into play here as well.) Renewed interest in delay-based congestion control may provide additional incentive for reducing bursts. The 2000 Aggarwal paper does raise some legitimate issues with using pacing. I think these issues are solvable... -John From lachlan.andrew at gmail.com Sat Sep 30 14:42:37 2006 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Sat, 30 Sep 2006 14:42:37 -0700 Subject: [e2e] Are Packet Trains / Packet Bursts a Problem in TCP? In-Reply-To: <451D804A.5090007@web.de> References: <20060925142037.112C067@aland.bbn.com> <8f884bb031b3678c4b56874456ec25aa@mac.com> <45196A07.8080102@web.de> <451973FD.50009@ieee.org> <451C5C3E.6080209@web.de> <451D5E71.7090108@ieee.org> <451D804A.5090007@web.de> Message-ID: Greetings Detlef, On 29/09/06, Detlef Bosau wrote: > I haven?t read all the relevant papers yet, but hasn?t been there some > rumour that these LRD need at least a minimum buffer size on the > routers? In other words: If we take care not to configure buffers too > large, would this cure the problem? What do you mean by "need"? It is well known that LRD needs large buffers in the sense that avoiding heavy loss with LRD traffic needs large buffers. I have never heard that LRD needs large buffers, in the sense that eliminating buffers eliminates LRD. May the rumours that you mention be refering to the first of these? Long-range dependence is a long-timescale phenomenon, and buffering primarily only affects short-timescale phenomena. Its interaction with flow control could in principle affect long-timescale phenomena, but lowering the buffer size would slow Reno down and thus increase (not decrease) the "long range"-ness of the dependence. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603