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 <sharad2833 at yahoo.com> 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<http://us.rd.yahoo.com/evt=41244/*http://smallbusiness.yahoo.com/>.
>
>
>
-------------- 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: <e971dd124a35be132e2c7c22a2ad69f0@cse.unsw.edu.au>

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 <doug.leith at nuim.ie> 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 <doug.leith at nuim.ie> 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: <E6F7A586E0A3F94D921755964F6BE00649D84F@EXCHANGE2.cs.cornell.edu>


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: <E6F7A586E0A3F94D921755964F6BE00649D84F@EXCHANGE2.cs.cornell.edu>
References: <E6F7A586E0A3F94D921755964F6BE00649D84F@EXCHANGE2.cs.cornell.edu>
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: <aa7d2c6d0609221426r10b84619gb6065d8bd2cc451d@mail.gmail.com>
Message-ID: <E6F7A586E0A3F94D921755964F6BE00649D85C@EXCHANGE2.cs.cornell.edu>


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 <francis at cs.cornell.edu> 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.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>

-----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 
> <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 <http://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: <E6F7A586E0A3F94D921755964F6BE00649D861@EXCHANGE2.cs.cornell.edu>

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: <E6F7A586E0A3F94D921755964F6BE00649D864@EXCHANGE2.cs.cornell.edu>

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: <E6F7A586E0A3F94D921755964F6BE00649D84F@EXCHANGE2.cs.cornell.edu>
References: <E6F7A586E0A3F94D921755964F6BE00649D84F@EXCHANGE2.cs.cornell.edu>
Message-ID: <B73E95B8-C1D6-4080-B66C-CFAB99507FC8@cisco.com>


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: <BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>


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: <BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
Message-ID: <f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>

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 <fred at cisco.com> 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>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com>
Message-ID: <f47983b00609251635o4abafabp598a427c531d6c82@mail.gmail.com>

On 9/25/06, Fred Baker <fred at cisco.com> 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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
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 <fred at cisco.com> 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: <E6F7A586E0A3F94D921755964F6BE00649D864@EXCHANGE2.cs.cornel l.edu>
References: <603BF90EB2E7EB46BF8C226539DFC20701316A80@EVS-EC1-NODE1.surrey.ac.uk>
	<E6F7A586E0A3F94D921755964F6BE00649D864@EXCHANGE2.cs.cornell.edu>
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>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: <E6F7A586E0A3F94D921755964F6BE00649DA0A@EXCHANGE2.cs.cornell.edu>


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.html>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: <f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
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.
  <http://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.html>.

(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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<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>	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<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: <Your message of "Mon, 25 Sep 2006 18:45:00 PDT."
	<8f884bb031b3678c4b56874456ec25aa@mac.com>
	<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>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<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" <dpreed at reed.com> 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 <shemminger at osdl.org>

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: <F583735E-7B5B-4DE1-8D4D-EAE353CFF4A2@koganei.wide.ad.jp>

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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>
	<45196899.8030105@web.de>
Message-ID: <F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>


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: <F583735E-7B5B-4DE1-8D4D-EAE353CFF4A2@koganei.wide.ad.jp>
References: <20060923103853.426C567@aland.bbn.com>	<232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com>	<451973E6.5050409@reed.com>
	<200609271153.16325.zec@tel.fer.hr>
	<F583735E-7B5B-4DE1-8D4D-EAE353CFF4A2@koganei.wide.ad.jp>
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 <mort at ieee.org>
  *> 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
  *> 	<end2end-interest.postel.org>
  *> 
  *> 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: <F583735E-7B5B-4DE1-8D4D-EAE353CFF4A2@koganei.wide.ad.jp>
References: <20060923103853.426C567@aland.bbn.com>	<232CF6ED-0C4E-458D-BCC3-8623F1534C36@cisco.com>	<451973E6.5050409@reed.com>
	<200609271153.16325.zec@tel.fer.hr>
	<F583735E-7B5B-4DE1-8D4D-EAE353CFF4A2@koganei.wide.ad.jp>
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: <F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
References: <20060923103853.426C567@aland.bbn.com>	<4517E2C4.8040300@web.de><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
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.

<http://www.ee.surrey.ac.uk/Personal/L.Wood><L.Wood at surrey.ac.uk> 

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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<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>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>
	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<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>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<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: <aa7d2c6d0609271946xd8cfa7fxbcded8db39e0eec5@mail.gmail.com>
References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de>	
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	
	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>
	<45196899.8030105@web.de>	
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<aa7d2c6d0609271946xd8cfa7fxbcded8db39e0eec5@mail.gmail.com>
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>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>
	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<aa7d2c6d0609271946xd8cfa7fxbcded8db39e0eec5@mail.gmail.com>
	<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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<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: <aa7d2c6d0609271620h74a5cffxae22fd46daaa3f29@mail.gmail.com>

Greetings all,

On 23/09/06, rhee at ncsu.edu <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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<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: <F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<006301c6e0ff$1dd52cb0$d22dd783@baybridge> <45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
Message-ID: <aa7d2c6d0609271946xd8cfa7fxbcded8db39e0eec5@mail.gmail.com>

Greetings Fred,

On 26/09/06, Fred Baker <fred at cisco.com> 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: <aa7d2c6d0609271946xd8cfa7fxbcded8db39e0eec5@mail.gmail.com>
References: <20060923103853.426C567@aland.bbn.com> <4517E2C4.8040300@web.de>
	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>
	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>
	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<aa7d2c6d0609271946xd8cfa7fxbcded8db39e0eec5@mail.gmail.com>
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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<451ADA94.2030309@reed.com> <451AFC89.6010109@web.de>
	<99C24D26-8A87-4B4B-AABE-50E84C558169@cisco.com>
	<451B1B14.6070109@reed.com>
Message-ID: <E9C108B4-49C0-45AE-849B-B6AA32ABD40D@cisco.com>

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>	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>	<aa7d2c6d0609271946xd8cfa7fxbcded8db39e0eec5@mail.gmail.com>	<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>
	<aa7d2c6d0609271620h74a5cffxae22fd46daaa3f29@mail.gmail.com>
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" <lachlan.andrew at gmail.com>
To: <rhee at ncsu.edu>
Cc: "Douglas Leith" <doug.leith at nuim.ie>; <netdev at vger.kernel.org>; 
<floyd at icsi.berkeley.edu>; <lisongxu at gmail.com>; "Injong Rhee" 
<rhee at eos.ncsu.edu>; <end2end-interest at postel.org>
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 <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: <aa7d2c6d0609271620h74a5cffxae22fd46daaa3f29@mail.gmail.com>
References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00>
	<4514D590.9010201@nuim.ie>
	<56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu>
	<aa7d2c6d0609271620h74a5cffxae22fd46daaa3f29@mail.gmail.com>
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 <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: <aa7d2c6d0609290900o47981571tf2a593cd8cd6eafc@mail.gmail.com>
References: <001b01c6deb8$c0375bc0$4a580e98@ncsu2cc0c3fa00>
	<4514D590.9010201@nuim.ie>
	<56271.66.57.32.78.1158997517.squirrel@webmail.ncsu.edu>
	<aa7d2c6d0609271620h74a5cffxae22fd46daaa3f29@mail.gmail.com>
	<20060928230300.GA22894@hut.isi.edu>
	<aa7d2c6d0609290900o47981571tf2a593cd8cd6eafc@mail.gmail.com>
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 <faber at isi.edu> 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>
	<aa7d2c6d0609271620h74a5cffxae22fd46daaa3f29@mail.gmail.com>
	<20060928230300.GA22894@hut.isi.edu>
Message-ID: <aa7d2c6d0609290900o47981571tf2a593cd8cd6eafc@mail.gmail.com>

On 28/09/06, Ted Faber <faber at isi.edu> 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><BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>	<006301c6e0ff$1dd52cb0$d22dd783@baybridge>	<45196899.8030105@web.de>
	<F6AB1B16-1792-4DC1-A748-55BD5AC8EF12@cisco.com>
	<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>	<BA5D8983-6317-4FFA-93AB-92A969C09B97@cisco.com>	<f47983b00609251542o50394395r66db170e6f5f1e47@mail.gmail.com>
	<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: <aa7d2c6d0609301442v33a6d851j77357f7dc0169228@mail.gmail.com>

Greetings Detlef,

On 29/09/06, Detlef Bosau <detlef.bosau at web.de> 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