From braden@ISI.EDU Tue Jan 23 11:22:57 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA16176 for ; Tue, 23 Jan 2001 11:22:57 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0NJMvU17273 for ; Tue, 23 Jan 2001 11:22:57 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA12281 for end2end-interest@postel.org; Tue, 23 Jan 2001 19:22:57 GMT Date: Tue, 23 Jan 2001 19:22:57 GMT Message-Id: <200101231922.TAA12281@gra.isi.edu> To: end2end-interest@ISI.EDU X-Sun-Charset: US-ASCII Subject: [e2e] Back in service Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: X-IMAPbase: 1077580632 4281 NonJunk Junk Status: RO X-Status: X-Keywords: X-UID: 1 The End2end-interest list is back. (This may not be exactly momentous news, since only a half dozen of you noticed it was gone. It was turned off immediately after the recent viral infarction.) The end2end-interest list will now be provided as a service of the Jonathan B. Postal Center for Experimental Networking. Bob Braden From border@hns.com Tue Jan 23 11:35:10 2001 Received: from hnssysa.hns.com (hnssysa.hns.com [139.85.76.100]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA19249 for ; Tue, 23 Jan 2001 11:35:06 -0800 (PST) Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id OAA07433 for ; Tue, 23 Jan 2001 14:34:33 -0500 (EST) Message-ID: <3A6DDCC7.2368FCA0@hns.com> Date: Tue, 23 Jan 2001 14:34:31 -0500 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: end2end-interest@ISI.EDU References: <200007172227.PAA24532@elk.aciri.org> <3A6777FA.B529F22C@hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] Data + FIN Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 2 Is it common practice for a TCP stack to send a FIN with the last segment of data if the opportunity presents itself? We ran into the following scenario... SYN -------------> <------------- SYN+ACK ACK -------------> X<----- DATA <------------- FIN ACK -------------> [Doesn't ACK the FIN] Retransmission Timeout <------------- DATA+FIN We had not seen this before and were wondering if this is typical. This uncovered a bug (easily fixed) in our code because we queued the first FIN and ended up processing two FINs. (Since the FIN is included in the sequence number space, there are some here who think adding the FIN to the DATA segment is illegal because it makes the retransmitted segment bigger than the original. I did a quick perusal of a few RFCs (but definitely not all of the relevant RFCs) and didn't find anything which makes me think it is illegal. Illegal or not, since it is happening in the real world, we need to handle it.) John From tschudin@docs.uu.se Tue Jan 23 11:39:27 2001 Received: from radha.it.uu.se (tschudin@radha.it.uu.se [130.238.9.99]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA19794 for ; Tue, 23 Jan 2001 11:39:26 -0800 (PST) Received: from localhost (tschudin@localhost) by radha.it.uu.se (8.8.5/8.8.5) with ESMTP id UAA03394 for ; Tue, 23 Jan 2001 20:39:24 +0100 (MET) X-Authentication-Warning: radha.it.uu.se: tschudin owned process doing -bs Date: Tue, 23 Jan 2001 20:39:23 +0100 (MET) From: Christian Tschudin To: end2end-interest@ISI.EDU Subject: [e2e] CFP - OpenArch'2001 Short Paper Session - Ghosts of the Net! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 3 [Apologies if you have already received this CFP via other distribution lists.] CALL FOR PAPERS OpenArch'2001 - Short Paper Session http://www.docs.uu.se/~tschudin/oa2001-sps/ Organizer: Christian Tschudin Ghosts of the Net! Show us the new Ghosts of the Net: We want to know what these code spirits do there, how they look, how they behave, how you make them. Let the rays of mobile code penetrate the deepest corner of the dark network core and enlighten us with everything you know about the future of active network- ing, open signaling and programmable networks. Submit your venturesome but sound idea to the short paper session of Openarch'2001. We are seeking short papers on novel concepts related to the OpenArch'2001 themes (CFP can be found at http://www.open- arch.org/2001_cfp.html) For additional guidelines, consult the open list below on what we would like and what we don't want to see: Yes, please No, thanks Turing on the move Jacquard in the node Automate the net Humans in the loop Internet Deconstructivism Internet plus epsilon The fury in the net Zero jitter architectures Trust in code Darwinism Believe in design Kolmogorov Lempel-Ziv Code species Standards mammoths Self-* Command and Control Fragment, translate, tunnel! You shall have only one address Packet bartering Bandwidth plan economy ... ... Short papers with up to 4 pages (single spaced, less than 1600 words, PostScript or PDF format) should be sent to oa2001-sps@docs.uu.se Papers selection will be handled by Andrew Campbell and Christian Tschudin. Papers should be clear on which problem they address, the nature of the proposed solution, together with some initial results. Each accepted paper receives a 10+5 minutes presentation+question time slot in the Open Arch'2001 short paper session and will be reprinted in the on-site proceedings, one author has to present it. Important Dates: Submission deadline Feb 9, 2001 Notification to authors Mar 5, 2001 Final version of papers due Mar 31, 2001 OpenArch'2001 April 27-28, 2001 // eof From touch@ISI.EDU Tue Jan 23 11:40:30 2001 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA19963 for ; Tue, 23 Jan 2001 11:40:30 -0800 (PST) Message-ID: <3A6DDE1B.4CDA3744@isi.edu> Date: Tue, 23 Jan 2001 11:40:11 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: end2end-interest@ISI.EDU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] The End2end-interest list is back Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 4 The End2end-interest list is back. (This may not be exactly momentous news, since only a half dozen of you noticed it was gone. It was turned off immediately after the recent viral infarction.) The end2end-interest list will now be provided as a service of the Jonathan B. Postal Center for Experimental Networking. Further information on the Postel Center is available at http://www.postel.org/ The end2end-interest list is for discussion of research and design issues that are broadly related to the end-to-end aspects of computer networking protocols and architecture, and in particular the consequences of the end-to-end principle underlying TCP/IP. It is sponsored by the End-to-End Research Group, whose historical roots go back to the original ARPA-funded research project that developed the Internet architecture and protocols, and which now forms one group within the Internet Research Task Force (IRTF). This list is not to be used for job announcements, and only a very few Call-for-Paper announcements are appropriate here. If you wish to send a CFP or any other sort of administrative announcement to this list, please check first with Bob Braden (braden@isi.edu). Otherwise, don't. You will receive information on how to manage your mail list entry in a separate e-mail. Note- the list now uses "Mailman", rather than Majordomo. Joe Touch Director, Postel Center for Experimental Networking USC/ISI http://www.isi.edu/touch From touch@ISI.EDU Tue Jan 23 11:54:49 2001 Received: from dee.isi.edu (dee.isi.edu [128.9.160.175]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA21467 for ; Tue, 23 Jan 2001 11:54:49 -0800 (PST) Received: (from touch@localhost) by dee.isi.edu (8.9.3/8.9.3) id LAA15523 for end2end-interest@postel.org; Tue, 23 Jan 2001 11:54:49 -0800 (PST) (envelope-from touch) Date: Tue, 23 Jan 2001 11:54:49 -0800 (PST) From: Joe Touch Message-Id: <200101231954.LAA15523@dee.isi.edu> To: end2end-interest@ISI.EDU Subject: [e2e] FYI - "to" field Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 5 Hi, all, We're getting some wrinkles out of the mail system, which looked like they were OK, but are varying... Posts to the list should be sent to: end2end-interest@postel.org We are working to correct the mail headers to match this (rather than to go to ISI.EDU, which bounces). We appreciate your patience while this is getting fixed. Thanks, Joe From braden@ISI.EDU Tue Jan 23 13:59:37 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id NAA05740 for ; Tue, 23 Jan 2001 13:59:37 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0NLxaU13919 for ; Tue, 23 Jan 2001 13:59:36 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id VAA12495 for end2end-interest@postel.org; Tue, 23 Jan 2001 21:59:36 GMT Date: Tue, 23 Jan 2001 21:59:36 GMT Message-Id: <200101232159.VAA12495@gra.isi.edu> To: end2end-interest@ISI.EDU Subject: Re: [e2e] Back in service X-Sun-Charset: US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 6 *> *> *> The End2end-interest list is back. (This may not be exactly *> momentous news, since only a half dozen of you noticed it was gone. *> It was turned off immediately after the recent viral infarction.) *> *> The end2end-interest list will now be provided as a service of the *> Jonathan B. Postal Center for Experimental Networking. (sigh) e *> *> Bob Braden *> _______________________________________________ *> end2end-interest mailing list *> end2end-interest@postel.org *> http://www.postel.org/mailman/listinfo/end2end-interest *> From nahum@watson.ibm.com Tue Jan 23 14:01:52 2001 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA06179 for ; Tue, 23 Jan 2001 14:01:51 -0800 (PST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id RAA22628 for ; Tue, 23 Jan 2001 17:01:10 -0500 Received: from orinoco.watson.ibm.com (orinoco.watson.ibm.com [9.2.96.82]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id RAA32934 for ; Tue, 23 Jan 2001 17:01:10 -0500 Received: (from nahum@localhost) by orinoco.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id RAA40148 for end2end-interest@postel.org; Tue, 23 Jan 2001 17:01:09 -0500 From: Erich Nahum Message-Id: <200101232201.RAA40148@orinoco.watson.ibm.com> Subject: Re: [e2e] Data + FIN To: end2end-interest@ISI.EDU Date: Tue, 23 Jan 2001 17:01:09 -0500 (EST) Reply-to: nahum@watson.ibm.com (Erich M. Nahum) X-Url: http://www.research.ibm.com/people/n/nahum/ X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 7 John Border writes: > > Is it common practice for a TCP stack to send a FIN with the last segment of > data if the opportunity presents itself? We ran into the following > scenario... > > SYN -------------> > <------------- SYN+ACK > ACK -------------> > X<----- DATA > <------------- FIN > ACK -------------> [Doesn't ACK the FIN] > Retransmission Timeout > <------------- DATA+FIN > > We had not seen this before and were wondering if this is typical. Not only is this legal, but I believe it happens relatively frequently with HTTP 1.0 traffic for large files. A WWW server will queue a bunch of data (say 64KB) into the socket layer, then close the socket. Since it can write the data asynchronously into the socket buffer faster than the socket drains (i.e., is acked by the remote host), the tcp code can identify the last segment and piggyback the FIN seamlessly. In fact, certain implementations of sendfile() include a close option to explicitly cause this to happen on *all* transfers, not just large ones where the race condition above happens. This not only reduces the number of packets required to transfer an HTTP response (typically 8-14 KB), and thus improves network utilization, but is also more efficient in terms of server CPU cycles. It avoids another transition between user and kernel space and reduces the number of packets host CPU has to queue to the network card. AIX does this, as does NT, I believe, and most likely other Unixes. I have a paper which includes this very topic if people are interested. As to *how frequently* it happens, somebody with ready access to packet traces can better answer that question. Two years ago, Anja Feldman gave me a number that was (I believe) on the order of 40% of TCP connection were doing this, based on a packet trace from AT&T. -Erich -- Erich M. Nahum IBM T.J. Watson Research Center Networking Research P.O. Box 704 nahum@watson.ibm.com Yorktown Heights NY 10598 From touch@ISI.EDU Tue Jan 23 14:14:43 2001 Received: (from touch@localhost) by boreas.isi.edu (8.9.3/8.9.3) id OAA07614 for end2end-interest@postel.org; Tue, 23 Jan 2001 14:14:43 -0800 (PST) Date: Tue, 23 Jan 2001 14:14:43 -0800 (PST) From: Joe Touch Message-Id: <200101232214.OAA07614@boreas.isi.edu> To: end2end-interest@ISI.EDU Subject: [e2e] another caveat - mail source name has changed Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 8 Hi, again, Just to point it out in case it hasn't been noticed: The end2end-interest list is now using the Mailman system, rather than the previous Majordomo. As a result, the source "from" name has changed to: end2end-interest-admin You may want to adjust your mail filters accordingly... Joe From braden@ISI.EDU Tue Jan 23 15:36:12 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA18216 for ; Tue, 23 Jan 2001 15:36:12 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0NNa9U06250; Tue, 23 Jan 2001 15:36:09 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA12693; Tue, 23 Jan 2001 23:36:09 GMT Date: Tue, 23 Jan 2001 23:36:09 GMT Message-Id: <200101232336.XAA12693@gra.isi.edu> To: end2end-interest@ISI.EDU, border@hns.com Subject: Re: [e2e] Data + FIN X-Sun-Charset: US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 9 *> the original. I did a quick perusal of a few RFCs (but definitely not all of *> the relevant RFCs) and didn't find anything which makes me think it is *> illegal. Illegal or not, since it is happening in the real world, we need to *> handle it.) It was certainly the intent that it be legal. Indeed, piggybacking FINs on the last data packet was worth a bonus point in the "Pillsburys" (avoiding the forbidden b-word) during initial TCP imkplementation phase in the late 1970s. I interpret the last paragraph of page 26 of RFC 793 as saying it IS legal. The seq space occupied by the FIN is defined as part of the SEG.LEN, so it will generally fit into the window. The detailed rules beginning on p. 65 clearly are meant to handle FIN bits on the last data segment. Bob Braden *> *> *> John *> _______________________________________________ *> end2end-interest mailing list *> end2end-interest@postel.org *> http://www.postel.org/mailman/listinfo/end2end-interest *> From braden@ISI.EDU Wed Jan 24 09:03:41 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA06231 for ; Wed, 24 Jan 2001 09:03:41 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0OH3eU20766 for ; Wed, 24 Jan 2001 09:03:40 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA13075 for end2end-interest@postel.org; Wed, 24 Jan 2001 17:03:40 GMT Date: Wed, 24 Jan 2001 17:03:40 GMT Message-Id: <200101241703.RAA13075@gra.isi.edu> To: end2end-interest@postel.org Content-Type: X-sun-attachment Subject: [e2e] Call for papers Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 10 ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 46 ----- Begin Included Message ----- >From wolisz@fokus.gmd.de Wed Jan 24 04:08:20 2001 Date: Wed, 24 Jan 2001 13:07:58 +0100 From: Adam Wolisz Reply-To: wolisz@ee.tu-berlin.de Organization: TU Berlin und GMD Fokus X-Mailer: Mozilla 4.5 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: braden@ISI.EDU Subject: Call for papers Content-Type: multipart/alternative; boundary="------------500FB2BDC36BBCACEDB12B8B" Content-Length: 2065 X-Lines: 61 Bob, please have a look at the call for papers for a the Special Issue of the IEEE Personal Communication Magazine on "Mobile and Wireless Internet: Architectures and Protocols" http://www-tkn.ee.tu-berlin.de/special_issues.html to be published in the IVth Quarter of 2001, (Submission deadline June 1st, 2001.) I believe this call might be of interest to the end-to-end community. Please feel free to froward this announcement, to the list, or drop it, if you prefer so. Best regards Adam Wolisz Professor of Electrical Engineering and Computer Science Technical University of Berlin ----- End Included Message ----- ---------- X-Sun-Data-Type: html X-Sun-Encoding-Info: 7bit X-Sun-Charset: us-ascii X-Sun-Content-Lines: 22 Bob,

please have a look at the call for papers for a the Special Issue
of the IEEE Personal Communication Magazine on
"Mobile and Wireless Internet:  Architectures and Protocols"

http://www-tkn.ee.tu-berlin.de/special_issues.html

to be published in the IVth Quarter of 2001,

(Submission deadline  June 1st, 2001.)

I believe this call might be of interest to the
end-to-end community.
Please feel free to froward this announcement,
to the list, or drop it, if you prefer so.
 

Best regards
Adam Wolisz
Professor of Electrical Engineering
and Computer Science
Technical University of Berlin
 
 
  From touch@ISI.EDU Wed Jan 24 11:14:56 2001 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA20756 for ; Wed, 24 Jan 2001 11:14:56 -0800 (PST) Message-ID: <3A6F299F.563E8FDC@isi.edu> Date: Wed, 24 Jan 2001 11:14:39 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: end2end-interest@postel.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] test Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 11 Please ignore... Joe From touch@ISI.EDU Wed Jan 24 11:39:17 2001 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA23261 for ; Wed, 24 Jan 2001 11:39:17 -0800 (PST) Message-ID: <3A6F2F54.2FD31C1F@isi.edu> Date: Wed, 24 Jan 2001 11:39:00 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: end2end-interest@postel.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] one more test (pls ignore) Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 12 From touch@ISI.EDU Wed Jan 24 11:42:32 2001 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA23682 for ; Wed, 24 Jan 2001 11:42:31 -0800 (PST) Message-ID: <3A6F3016.A40078BA@isi.edu> Date: Wed, 24 Jan 2001 11:42:14 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: end2end-interest@postel.org Subject: Re: [e2e] FYI - "to" field References: <200101231954.LAA15523@dee.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 13 Joe Touch wrote: > > Hi, all, > > We're getting some wrinkles out of the mail system, > which looked like they were OK, but are varying... > > Posts to the list should be sent to: > > end2end-interest@postel.org > > We are working to correct the mail headers to > match this (rather than to go to ISI.EDU, which bounces). FYI - this has now been corrected. Thanks to a few of you for pointing this out. Joe From kandlur@us.ibm.com Wed Jan 24 13:00:53 2001 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id NAA02057 for ; Wed, 24 Jan 2001 13:00:49 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA358972 for ; Wed, 24 Jan 2001 15:59:40 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id PAA203406 for ; Wed, 24 Jan 2001 15:57:31 -0500 Importance: Normal To: end2end-interest@postel.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Dilip D Kandlur" Date: Wed, 24 Jan 2001 16:04:39 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/24/2001 04:00:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [e2e] Reminder: CFP: ACM SIGCOMM 2001 (deadline this week!) Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 14 CALL FOR PAPERS ACM SIGCOMM 2001 CONFERENCE August 27 - August 31, 2001 Mandeville Auditorium, UC San Diego, CA, USA. http://www.acm.org/sigcomm/sigcomm2001 Important Dates: Paper submission: January 26, 2001 Tutorial proposals: February 12, 2001 Notification of acceptance: April 23, 2001 Camera ready papers: May 21, 2001 The SIGCOMM 2001 conference seeks papers describing significant research contributions to the field of computer and data communication networks. Authors are invited to submit full papers concerned with both theory and practice. Areas of interest include, but are not limited to: - Distributed application networking infrastructure. - Distributed common application services, middleware protocols, and signaling. - Routing, switching, and addressing. - Resource sharing, quality of service, multimedia networks, and OS support. - Multimedia networking. - Networking aspects of the WWW. - Heterogeneous internetworking, large-scale networks. - Network management. - Active network architectures and protocols. - Important experimental results from operational networks and lessons learned from prototype implementations. - Wireless networking and support for nomadic computing. - Analysis and design of computer network architectures and algorithms. SIGCOMM 2001 is a single-track, highly selective conference at which successful submissions typically report results firmly substantiated by experiment, implementation, simulation, or mathematical analysis. In addition to the technical program (paper presentations), SIGCOMM 2001 will offer tutorials by noted instructors on the two days preceding the actual conference, and feature an outrageous opinion session where fresh and unconventional perspectives will be offered. Submission Instructions: ------------------------ Papers must be less than 20 double-spaced pages long (formatted for printing in the Proceedings, papers may not be longer than 12 pages), have an abstract of 100-150 words, and be original material that has not been previously published nor is currently under review by another conference or journal. Authors must submit papers electronically, using the instructions at http://www.acm.org/sigs/sigcomm/sigcomm2001/submission/index.htm. Authors not able to comply with these instructions should contact the Program Co-Chairs at sigcomm2001@seas.upenn.edu . Papers submitted after the deadline will not be considered without an ahead-of-time extension from the Program Co-Chairs. All submitted papers will be judged based on their quality and relevance through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Consult the on-line submission instructions for information on preparing a manuscript for double-blind review. Authors of accepted papers will need to sign an ACM copyright release form and present their paper at the conference. The Proceedings of the conference will be published as a special issue of ACM SIGCOMM Computer Communication Review. The Program Committee may also select a few papers for possible publication in the IEEE/ACM Transactions on Networking. Electronic copies of the accepted papers will be published on the SIGCOMM 2001 web site prior to the conference unless authors specifically request that this not be done. Tutorials: ---------- SIGCOMM 2001 will begin with two days of full-day and half-day tutorials covering single topics in detail, at both the introductory or advanced level. Individuals interested in submitting tutorial proposals are encouraged to contact the Tutorial Chair before the deadline to discuss the proposed content. Student Paper Award ------------------- Papers submitted by students may be considered for a student-paper award, which includes full conference registration and a travel grant of approximately $500. To be eligible, the student must be the sole author of the paper, or the first author and primary contributor. A cover letter or email to the Program Chairs must identify the paper as a candidate for this competition. SIGCOMM Award: -------------- The keynote speaker at SIGCOMM 2001 will be the 2001 winner of the ACM SIGCOMM Award for lifetime contributions to the field of computer communication. Procedures for nominating candidates for the SIGCOMM Award can be obtained from Scott Shenker (shenker@aciri.org). From HOJABRI@aol.com Wed Jan 24 14:12:50 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA10347 for ; Wed, 24 Jan 2001 14:12:50 -0800 (PST) From: HOJABRI@aol.com Received: from imo-r04.mx.aol.com (imo-r04.mx.aol.com [152.163.225.4]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0OMCnU28143; Wed, 24 Jan 2001 14:12:49 -0800 (PST) Received: from HOJABRI@aol.com by imo-r04.mx.aol.com (mail_out_v29.5.) id k.bd.b1da0a2 (4006); Wed, 24 Jan 2001 17:11:44 -0500 (EST) Message-ID: Date: Wed, 24 Jan 2001 17:11:42 EST To: end2end-interest@ISI.EDU, confctrl@ISI.EDU MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_bd.b1da0a2.27a0ad1e_boundary" Content-Disposition: Inline X-Mailer: 6.0 sub 149 Subject: [e2e] INTERNATIONAL TELECOMMUNICATION SYMPOSIUM Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: discussion of end-2-end research and design principles List-Unsubscribe: , List-Archive: Status: RO X-Status: X-Keywords: X-UID: 15 --part1_bd.b1da0a2.27a0ad1e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I WOULD APPRECIATE IT IF YOU FORWARD THE ATTACHED ANNOUNCEMENT TO YOUR MAILING LIST. REGARDS, DR. F. HOJABRI PRESIDENT SHARIF UNIVERSITY ASSOCIATION --part1_bd.b1da0a2.27a0ad1e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I WOULD APPRECIATE IT IF YOU FORWARD THE ATTACHED ANNOUNCEMENT TO YOUR
MAILING LIST.

REGARDS,
DR. F. HOJABRI
PRESIDENT
SHARIF UNIVERSITY ASSOCIATION
--part1_bd.b1da0a2.27a0ad1e_boundary-- From tschammer@fokus.gmd.de Thu Jan 25 04:24:33 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id EAA15457 for ; Thu, 25 Jan 2001 04:24:32 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PCOVU16995; Thu, 25 Jan 2001 04:24:31 -0800 (PST) Received: from fokus.gmd.de (crest [193.175.132.109]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id NAA24985; Thu, 25 Jan 2001 13:24:13 +0100 (MET) Message-ID: <3A701900.CFF99CDA@fokus.gmd.de> Date: Thu, 25 Jan 2001 13:16:00 +0100 From: Volker Tschammer Reply-To: tschammer@fokus.gmd.de Organization: GMD Fokus X-Mailer: Mozilla 4.7 [en-gb] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: Cabernet Events , tccc@ieee.org, tcgn@ieee.org, itc@ieee.org, spects02@comp.leeds.ac.uk, news-announce-conferences@uunet.uu.net, end2end-interest@ISI.EDU, int-serv@ISI.EDU, cost264@lip6.fr, conf@colmar.uha.fr, conferences@iao.fhg.de, cfp@mmlab.snu.ac.kr, rm@mash.cs.berkeley.edu, enternet@bbn.com, giga@tele.pitt.edu, comswtc@ieee.org Content-Type: multipart/alternative; boundary="------------6557CE010B404E6FE0A028E7" Subject: [e2e] 2nd Call for Papers - IFIP I3E-Conference Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 16 --------------6557CE010B404E6FE0A028E7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit * Apologies if you receive multiple copies of this * Deadline approaching: February, 15, 2001 I3E The First IFIP Conference on e-Commerce, e-Business, e-Government 4-5 October 2001 in Zürich, Switzerland Announcement and 2nd CALL FOR PAPERS SCOPE This conference is the first IFIP conference on e-commerce, e-business, and e-government sponsored by the three committees TC6, TC8, and TC11. It provides a forum for users, engineers, and scientists in academia, industry, and government to present their latest findings in e-commerce, e-business, or e-government applications and the underlying technology to support those applications. Areas of particular interest include but are not limited to: * Pre-sales support, ordering, settlement, delivery, and payment * Post-sales services and customer care * Innovative business models and business process re-engineering * Interorganizational systems, virtual organizations, and virtual markets * Supply chains, work flow management, control and audit mechanisms * Procurement, negotiations and dynamic pricing models (bidding, auctions) * Trading of intangible goods * Information & communication platforms, mobile agents, unified messaging * Security, privacy, and consumer protection * Smart Cards and biometrics * Information retrieval, data mining, semantic web * Legal, social, cross-cultural issues * Trust and confidence in digital signatures and certificates * Mobile e-commerce and ubiquitous electronic markets * Innovative government services for the citizen * Strategic management of e-commerce, e-business, e-government systems * Measuring of E-Commerce impact/results MAIN TRACK and MINITRACKS The conference will comprise a main track with papers in the topics above and several minitracks dedicated to special topics. INFORMATION for MINITRACK CHAIRS Proposal for minitracks should describe the title, scope and organizational structure of the minitrack. Minitrack chairs are responsible for both organizing the review process and promotion of their minitrack. Proposals for minitracks should be send electronically as Word or PDF files following the link at the conference homepage until December 10th, 2000. INFORMATION FOR AUTHORS Submissions should describe original work (not submitted or published elsewhere) and be 20 double-spaced pages in length. Submissions should include title, authors and a 150-word abstract as a front page. Identify the author responsible for correspondence, incl. the author’s name, mailing address, telephone and fax numbers, and e-mail address. The core paper should include the title only and no info about the authors. One of the authors of each paper must register and present the paper at the conference. The proceedings of the conference will be published by Kluwer Academic Publishers. Best papers are selected by the best paper award committee. Authors are requested to submit their manuscripts electronically as a Microsoft Word document, PDF, or in Postscript format by following instructions at the conference home page (www.ifi.unizh.ch/I3E-conference). Please note that together with the Conference, there are several mini tracks addressing specific subjects. You may wish to submit your paper under one of these topics. Submission address for the conference and the mini tracks is the same and is given below. Submission address: I3E.conference@netacademy.org. GENERAL INFORMATION For more information about the conference please visit our web site at www.ifi.unizh.ch/I3E-conference IMPORTANT DEADLINES Papers due: February 15, 2001 (deadline extended) Acceptance: May 1, 2001 Final papers due: June 15, 2001 Authors registration: June 15, 2001 COMMITTEES General Chair K. Bauknecht, Univ. Zürich, CH Programme Chair B. Schmid, Univ. St. Gallen, CH V. Tschammer, GMD FOKUS, D Programme Committee D. Avison, Essec Bus. School, F M. Bichler, Univ. of Econ., Vienna, A L. M. Camarinha-Matos, Univ. Nova, Lisboa, PT W. Cellary, Univ. of Econ., Poznan, PL E. Clemons, Univ. of Pennsylvania, US D. Deschoolmeester, Gent, B J. Dietz, TU Delft, NL F. Douglis, AT&T Labs, US J.H.P. Eloff, Rand Afrikaans Univ., ZA S. Field, IBM, Zürich, CH M. Funabashi, Hitachi Ltd., JP R.K.L. Gay, NTU, Singapore B.C. Glasson, Curtin Univ., AUS J. Griese, Univ. Bern, CH P. Grimm, TU Ilmenau, D D. Gritzalis, AUEB, Athens, GR V. Hara, Telecom Finland, FIN F. Kamoun, ENSI, Tunis, Tunisia D. Khakhar, Lund Univ., S K. Koen, Atio Corp., Johannesburg, ZA D. Konstantas, Univ. Geneva, CH W. Lamersdorf, Univ. of Hamburg, D R. Lee, Erasmus Uni., Rotterdam, NL*) C. Linnhoff-Popien, Univ. of Munich, D T. Magedanz, IKV++, Berlin, D M. Mendes, UNICAMP, Brasil M. Merz, Ponton, Hamburg, D Z. Milosevic, DSTC, Brisbane, AUS A. Molina, Univ. of Edinburgh, UK P. Moody, IncoTech, L E. Neuhold, Univ. of Darmstadt, D L.J.M. Nieuwenhuis, kpn, NL V. Ouzounis, GMD FOKUS, Berlin, D R. Posch, TU Graz, A K. Rannenberg, Microsoft Research Cambridge, UK K. Stanoevska, Univ. St. Gallen, CH Ch. Steinfeld, Michigan State Univ., US M. Stolze, IBM, Rüschlikon ,CH R. Suomi, Turku School of Econ., FIN P. Swatman, Univ. Koblenz-Landau, D P. Timmers, European Commission, B A. Tsalgatidou, Univ. of Athens, GR M. Waidner, IBM, Rüschlikon, CH H. Weigand, Univ. Tilburg, NL R. Wigand, Syracuse University, US L. Yngstrom, DSV, Stockholm, S H.-D. Zimmermann, U. St. Gallen, CH Conference Organisation H. Haeuschen, Univ. Zürich L. Kuendig, Univ. Zürich, CH L.G. Mason, NTU, Singapore H. Rudin, Consultant, Zürich, CH --------------6557CE010B404E6FE0A028E7 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit * Apologies if you receive multiple copies of this *

      Deadline approaching: February, 15, 2001

I3E
The First IFIP Conference on e-Commerce, e-Business, e-Government
4-5 October 2001 in Zürich, Switzerland

Announcement  and 2nd CALL FOR PAPERS

SCOPE
This conference is the first IFIP conference on e-commerce, e-business, and e-government sponsored by the three
committees TC6, TC8, and TC11. It provides a forum for users, engineers, and scientists in academia, industry,
and government to present their latest findings in e-commerce, e-business, or e-government applications and the
underlying technology to support those applications. Areas of particular interest include but are not limited to:
* Pre-sales support, ordering, settlement, delivery, and payment
* Post-sales services and customer care
* Innovative business models and business process re-engineering
* Interorganizational systems, virtual organizations, and virtual markets
* Supply chains, work flow management, control and audit mechanisms
* Procurement, negotiations and dynamic pricing models (bidding, auctions)
* Trading of intangible goods
* Information & communication platforms, mobile agents, unified messaging
* Security, privacy, and consumer protection
* Smart Cards and biometrics
* Information retrieval, data mining, semantic web
* Legal, social, cross-cultural issues
* Trust and confidence in digital signatures and certificates
* Mobile e-commerce and ubiquitous electronic markets
* Innovative government services for the citizen
* Strategic management of e-commerce, e-business, e-government systems
* Measuring of E-Commerce impact/results

MAIN TRACK and MINITRACKS
The conference will comprise a main track with papers in the topics above and several minitracks dedicated to
special topics.

INFORMATION for MINITRACK CHAIRS
Proposal for minitracks should describe the title, scope and organizational structure of the minitrack. Minitrack
chairs are responsible for both organizing the review process and promotion of their minitrack. Proposals for
minitracks should be send electronically as Word or PDF files following the link at the conference homepage until
December 10th, 2000.

INFORMATION FOR AUTHORS
Submissions should describe original work (not submitted or published elsewhere) and be 20 double-spaced pages
in length. Submissions should include title, authors and a 150-word abstract as a front page. Identify the author
responsible for correspondence, incl. the author’s name, mailing address, telephone and fax numbers, and e-mail
address. The core paper should include the title only and no info about the authors. One of the authors of each
paper must register and present the paper at the conference. The proceedings of the conference will be published
by Kluwer Academic Publishers. Best papers are selected by the best paper award committee.

Authors are requested to submit their manuscripts electronically as a Microsoft Word document, PDF, or in
Postscript format by following instructions at the conference home page (www.ifi.unizh.ch/I3E-conference). Please
note that together with the Conference, there are several mini tracks addressing specific subjects. You may wish to
submit your paper under one of these topics. Submission address for the conference and the mini tracks is the same
and is given below.

Submission address:
I3E.conference@netacademy.org.

GENERAL INFORMATION
For more information about the conference please visit our web site at
www.ifi.unizh.ch/I3E-conference

IMPORTANT DEADLINES
Papers due:    February 15, 2001  (deadline extended)
Acceptance:    May 1, 2001
Final papers due:  June 15, 2001
Authors registration:  June 15, 2001

COMMITTEES

General Chair
K. Bauknecht, Univ. Zürich, CH

Programme Chair
B. Schmid, Univ. St. Gallen, CH
V. Tschammer, GMD FOKUS, D

Programme Committee
D. Avison, Essec Bus. School, F
M. Bichler, Univ. of Econ., Vienna,  A
L. M. Camarinha-Matos, Univ. Nova, Lisboa,  PT
W. Cellary, Univ. of Econ., Poznan, PL
E. Clemons, Univ. of Pennsylvania, US
D. Deschoolmeester, Gent, B
J. Dietz, TU Delft, NL
F. Douglis, AT&T Labs, US
J.H.P. Eloff, Rand Afrikaans Univ., ZA
S. Field, IBM, Zürich, CH
M. Funabashi, Hitachi Ltd., JP
R.K.L. Gay, NTU, Singapore
B.C. Glasson, Curtin Univ., AUS
J. Griese, Univ. Bern, CH
P. Grimm, TU Ilmenau, D
D. Gritzalis, AUEB, Athens, GR
V. Hara, Telecom Finland, FIN
F. Kamoun, ENSI, Tunis, Tunisia
D. Khakhar, Lund Univ., S
K. Koen, Atio Corp., Johannesburg, ZA
D. Konstantas, Univ. Geneva, CH
W. Lamersdorf, Univ. of Hamburg, D
R. Lee, Erasmus Uni., Rotterdam, NL*)
C. Linnhoff-Popien, Univ. of Munich, D
T. Magedanz, IKV++, Berlin, D
M. Mendes, UNICAMP, Brasil
M. Merz, Ponton, Hamburg, D
Z. Milosevic, DSTC,  Brisbane, AUS
A. Molina, Univ. of Edinburgh, UK
P. Moody, IncoTech, L
E. Neuhold, Univ. of Darmstadt, D
L.J.M. Nieuwenhuis, kpn, NL
V. Ouzounis, GMD FOKUS, Berlin, D
R. Posch, TU Graz, A
K. Rannenberg, Microsoft Research Cambridge, UK
K. Stanoevska, Univ. St. Gallen, CH
Ch. Steinfeld, Michigan State Univ., US
M. Stolze, IBM, Rüschlikon ,CH
R. Suomi, Turku School of Econ., FIN
P. Swatman, Univ. Koblenz-Landau, D
P. Timmers, European Commission, B
A. Tsalgatidou, Univ. of Athens, GR
M. Waidner, IBM, Rüschlikon, CH
H. Weigand, Univ. Tilburg, NL
R. Wigand, Syracuse University, US
L. Yngstrom, DSV, Stockholm, S
H.-D. Zimmermann, U. St. Gallen,  CH

Conference Organisation
H. Haeuschen, Univ. Zürich
L. Kuendig, Univ. Zürich, CH
L.G. Mason, NTU, Singapore
H. Rudin, Consultant, Zürich, CH --------------6557CE010B404E6FE0A028E7-- From bmah@cisco.com Thu Jan 25 10:08:15 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA14625 for ; Thu, 25 Jan 2001 10:08:13 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PI8CU28549 for ; Thu, 25 Jan 2001 10:08:12 -0800 (PST) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA28447; Thu, 25 Jan 2001 10:08:19 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id f0PI85C97694; Thu, 25 Jan 2001 10:08:05 -0800 (PST) (envelope-from bmah) Message-Id: <200101251808.f0PI85C97694@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4 To: end2end-interest@ISI.EDU Cc: bmah@cisco.com From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1776877369P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 25 Jan 2001 10:08:05 -0800 Subject: [e2e] pchar-1.3 available Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 17 --==_Exmh_-1776877369P Content-Type: text/plain; charset=us-ascii I'm most pleased to announce the release of pchar-1.3, a utility for characterizing the individual links along a path between two network hosts. pchar has been tested on various versions of FreeBSD, NetBSD, OpenBSD, Linux, Solaris, OSF/1, and IRIX, with the primary development on FreeBSD and Solaris. pchar is written is C++, primarily using recent versions of gcc, but with some testing also on the SparcWorks C++ compiler. pchar supports IPv4 and, where applicable, IPv6. Recent additions to pchar include: New analysis algorithms based on the least median of squares linear fit method, new probe types (ICMP and ICMPv6), the ability to set the outgoing interface of probes, and a new "tiny traceroute" mode. A number of bugs have been fixed as well; most notably, IPv6 probes will now return (more) correct values for the last hop of a path. The CHANGES file included in the pchar distribution provides more details. The file format used for tracefiles has changed, unfortunately in an incompatable way. Files from pchar-1.2 and earlier are incompatible with pchar-1.3 and vice versa. Conversion between file formats is a possibility, but has not been implemented yet. More information, as well as downloadable source code, can be found at: http://www.employees.org/~bmah/Software/pchar/ Questions and comments are welcome, and can be emailed to or . --==_Exmh_-1776877369P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6cGuF2MoxcVugUsMRAnqqAJ9JFldjAA7CFqjNNAcj1UmrIcuOgACg2Zoy yh7dmDhx6XPjvo1p23Fs/t8= =mfIE -----END PGP SIGNATURE----- --==_Exmh_-1776877369P-- From HOJABRI@aol.com Thu Jan 25 11:46:46 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA27565 for ; Thu, 25 Jan 2001 11:46:46 -0800 (PST) From: HOJABRI@aol.com Received: from imo-r19.mx.aol.com (imo-r19.mx.aol.com [152.163.225.73]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PJkiU19640; Thu, 25 Jan 2001 11:46:45 -0800 (PST) Received: from HOJABRI@aol.com by imo-r19.mx.aol.com (mail_out_v29.5.) id k.f9.6dfec6b (3930); Thu, 25 Jan 2001 14:46:26 -0500 (EST) Message-ID: Date: Thu, 25 Jan 2001 14:46:26 EST To: end2end-interest@ISI.EDU CC: confctrl@ISI.EDU MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_f9.6dfec6b.27a1dc92_boundary" Content-Disposition: Inline X-Mailer: 6.0 sub 171 Subject: [e2e] International Telecommunication Symposium Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 18 --part1_f9.6dfec6b.27a1dc92_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This message is posted by Sharif University Association, and we apologize if it is duplicate. Fredun Hojabri President Sharif University Association ------------------------------------------------------- INTERNATIONAL SYMPOSIUM ON TELECOMMUNICATIONS (IST2001) September 1 - 3, 2001 Esteghlal Grand Hotel TEHRAN, IRAN THEME: DIALOGUE OF CIVILIZATIONS THROUGH TELECOMMUNICATIONS Organized tours to : Isfahan, Shiraz and Tehran on 30 - 31 of August, 4 - 5 of September 2001 The first International Symposium on Telecommunications will be organized by the Iran Telecommunication Research Center (ITRC). The Symposium will be sponsored by IEEE, IEE, IFIP and ICT. It aims to provide a broad international forum as well as an outstanding opportunity for scientific researchers, academicians and telecommunication engineers to discuss new and emerging technologies, progress in standards, services and their applications in telecommunication and information systems. The event will feature world- renowned plenary speakers, tutorial presentations and focused mini-symposia. Scope: Topics to be addressed include, but are not limited to the following: Adaptive Communications Social implications of telecommunications Signal processing for communications Personal communication networks and systems Broadband ISDN and ATM high- speed networks and systems New network services and applications Network management Network architectures and standards Intelligent networks and communications software systems Electronic commerce IP Telephony Multimedia (speech, image and video) communications Interconnection networks Optical communications and networking Smart Antennas Satellite Systems and applications Security and authentication Regulation and public policy Wireless Communications Deregulation and Privatization. A more Focused Mini- Symposium Will be Organized By Dr. Guy Omidyar Mini- Symposium on Mobile and Wireless Communication Networks: Integration of fixed and portable wireless access technologies and mobility features into fixed and mobile IP networks is a new paradigm. This approach presents a cost effective and efficient way to provide seamless end- to- end connectivity and ubiquitous access. This wireless market has grown rapidly and is expected to generate billions of dollars in revenues. The deployment of broadband cellular- based technologies including demand for internet mobility and their integration with emerging Broadband Wireless Access Networks (BWANs) are becoming increasingly important. Mobility and connection management, location management, connection establishment, quality of service, provisioning for voice, video, image and data are some of the focus areas of this Mini- symposium. Contributions from standardization and research consortiums are accepted on mobile, satellite and personal communication- from 3 rd to 4 th generations, Wireless Applications Protocols (WAP), 3GPP and UMTS/ IMT2000. Topics to be covered in the technical session of this Mini- Symposium include, but are not limited to: Models of mobile and wireless networks Performance analysis and design of wireless systems. Wireless tele- traffic study and traffic characterization and management Wireless LAN architectures Radio interface Mobility management and roaming Mobile multimedia networking Wireless security Wireless in the local loops Wireless and mobile cellular internet Mobile and wireless ATM networks Multiple access techniques Experimental mobile and wireless networks and trials Satellite network architecture Signal processing for wireless Medium of Presentation: ENGLISH Call for Papers: Papers are solicited which describe original work suitable for the symposium. Prospective authors are requested to submit 3 copies of an extended summary of about 400 words. Deadlines: Extended summary: March 1, 2001 Notification of acceptance: May 1, 2001 Final paper submission: July 1, 2001 Advance registration: July 1, 2001 Tutorial Proposal (in any area of the scope of the conference): March 1, 2001 Information for Authors: The final paper submission should be double column and single- spaced (Times Roman font sign) with 4 pages or less in length. Submissions should include: title, author( s), affiliation( s), abstract and list of keywords. Identify the author responsible for correspondence, including the author's name, position, mailing address, telephone and fax numbers and e - mail address. One of the authors of each accepted paper must present the paper at IST 2001. A sample of the final paper format will be sent to the authors. Address for Submissions: Authors are requested to submit their manuscripts either electronically as PDF or Postscript format or hard copy to the following address: a. eslami@ itrc. ac. ir The postal address is: IST2001 International Affairs, Iran Telecommunication Research Center End of North Kargar St, P. O. Box 14155- 3961 Tehran, 14399 Iran General Information: For more information please visit the Web site at: http:// www. itrc. ac. ir/ ist2001/ Or send your notification of interest to e- mail : a. eslami@ itrc. ac. ir Tel/ Fax: (9821) 8009885 Tel: (9821) 8872988/ 9 Chairman: Mohammad Hakkak, m.hakkak@itrc.ac.ir Technical Program Chair: Farokh Marvasti, farokh. marvasti@ kcl. ac. uk Steering Committee: G. Omidyar, Computer Sciences Corporation, USA M. Malek Zavarei, Lucent Technologies, Bell Labs, USA M. Hakkak, Director of Iran Telecom Research Center, Iran F. Marvasti, King's College London, UK --part1_f9.6dfec6b.27a1dc92_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit This message is posted by Sharif University Association, and we apologize if
it is duplicate.

Fredun Hojabri
President
Sharif University Association
-------------------------------------------------------

INTERNATIONAL SYMPOSIUM ON
TELECOMMUNICATIONS (IST2001)
September 1 - 3, 2001
Esteghlal Grand Hotel TEHRAN, IRAN

THEME: DIALOGUE OF CIVILIZATIONS THROUGH TELECOMMUNICATIONS

Organized tours to :
Isfahan, Shiraz and Tehran on 30 - 31 of August, 4 - 5 of September 2001

The first International Symposium on Telecommunications will be organized by
the                 
Iran Telecommunication Research Center (ITRC). The Symposium will be
sponsored by IEEE, IEE, IFIP and ICT. It aims to provide a broad
international forum as well as an outstanding opportunity for scientific
researchers, academicians and telecommunication engineers to discuss new and
emerging technologies, progress in standards, services and their applications
in telecommunication and information systems. The event will feature world-
renowned plenary speakers, tutorial presentations and focused mini-symposia.

Scope:
Topics to be addressed include, but are not limited to the following:
Adaptive Communications
Social implications of telecommunications
Signal processing for communications
Personal communication networks and systems
Broadband ISDN and ATM high- speed networks and systems
New network services and applications
Network management
Network architectures and standards
Intelligent networks and communications software systems
Electronic commerce
IP Telephony
Multimedia (speech, image and video) communications
Interconnection networks
Optical communications and networking
Smart Antennas
Satellite Systems and applications
Security and authentication
Regulation and public policy
Wireless Communications
Deregulation and Privatization.

A more Focused Mini- Symposium Will be Organized By Dr. Guy Omidyar

Mini- Symposium on Mobile and Wireless Communication Networks:
Integration of fixed and portable wireless access technologies and mobility
features into fixed and mobile IP networks is a new paradigm. This approach
presents a cost effective and efficient way to provide seamless end- to- end
connectivity and ubiquitous access. This wireless market has grown rapidly
and is expected to generate billions of dollars in revenues. The deployment
of broadband cellular- based technologies including demand for internet
mobility and their integration with emerging Broadband Wireless Access
Networks (BWANs) are becoming increasingly important. Mobility and connection
management, location management, connection establishment, quality of
service, provisioning for voice, video, image and data are some of the focus
areas of this Mini- symposium.
Contributions from standardization and research consortiums are accepted on
mobile, satellite and personal communication- from 3 rd to 4 th generations,
Wireless Applications Protocols (WAP), 3GPP and UMTS/ IMT2000. Topics to be
covered in the technical session of this Mini- Symposium include, but are not
limited to:
Models of mobile and wireless networks
Performance analysis and design of wireless systems.
Wireless tele- traffic study and traffic characterization and management
Wireless LAN architectures
Radio interface
Mobility management and roaming
Mobile multimedia networking
Wireless security
Wireless in the local loops
Wireless and mobile cellular internet
Mobile and wireless ATM networks
Multiple access techniques
Experimental mobile and wireless networks and trials
Satellite network architecture
Signal processing for wireless

Medium of Presentation: ENGLISH

Call for Papers:
Papers are solicited which describe original work suitable for the symposium.
Prospective authors are requested to submit 3 copies of an extended summary
of about 400 words.

Deadlines:
Extended summary: March 1, 2001
Notification of acceptance: May 1, 2001
Final paper submission: July 1, 2001
Advance registration: July 1, 2001
Tutorial Proposal (in any area of the scope of the conference): March 1, 2001

Information for Authors:
The final paper submission should be double column and single- spaced (Times
Roman font sign) with 4 pages or less in length. Submissions should include:
title, author( s),
affiliation( s), abstract and list of keywords. Identify the author
responsible for
correspondence, including the author's name, position, mailing address,
telephone and fax numbers and e - mail address. One of the authors of each
accepted paper must present the paper at IST 2001. A sample of the final
paper format will be sent to the authors.

Address for Submissions:
Authors are requested to submit their manuscripts either electronically as
PDF or
Postscript format or hard copy to the following address: a. eslami@ itrc. ac.
ir
The postal address is:
IST2001
International Affairs, Iran Telecommunication Research Center
End of North Kargar St,
P. O. Box 14155- 3961
Tehran, 14399  
Iran  

General Information:
For more information please visit the Web site at:
http:// www. itrc. ac. ir/ ist2001/
Or send your notification of interest to
e- mail : a. eslami@ itrc. ac. ir
Tel/ Fax: (9821) 8009885
Tel: (9821) 8872988/ 9

Chairman:
Mohammad Hakkak, m.hakkak@itrc.ac.ir

Technical Program Chair:
Farokh Marvasti, farokh. marvasti@ kcl. ac. uk

Steering Committee:
G. Omidyar, Computer Sciences Corporation, USA
M. Malek Zavarei, Lucent Technologies, Bell Labs, USA
M. Hakkak, Director of Iran Telecom Research Center, Iran
F. Marvasti, King's College London, UK


--part1_f9.6dfec6b.27a1dc92_boundary-- From helbakou@americasm06.nt.com Thu Jan 25 17:11:14 2001 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA01114 for ; Thu, 25 Jan 2001 17:11:13 -0800 (PST) Received: from ertpg14e1.nortelnetworks.com (zrtph06m.us.nortel.com [47.125.208.110]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f0Q178316969 for ; Thu, 25 Jan 2001 20:07:13 -0500 (EST) Received: by ertpg14e1.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA23678; Thu, 25 Jan 2001 20:07:37 -0500 Date: Thu, 25 Jan 2001 20:07:37 -0500 Message-Id: <200101260107.UAA23678@ertpg14e1.nortelnetworks.com> To: end2end-interest@postel.org From: "Elbakoury, Hesham [SC5:323:EXCH]" Content-Type: multipart/alternative; Subject: [e2e] Scalability of Ip Multicast Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 19 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08589.D0541900 Content-Type: text/plain; charset="iso-8859-1" Can any one point me to work (Papers, documents, reports, ... etc) that has been done in the area of improving the scalability of IP multicast. Thanks Hesham ------_=_NextPart_001_01C08589.D0541900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scalability of Ip Multicast

Can any one point me to work (Papers, = documents, reports, ... etc) that has been done in the area of = improving the scalability of IP multicast.

   Thanks

   Hesham

------_=_NextPart_001_01C08589.D0541900-- From richard@starburst.demon.co.uk Thu Jan 25 20:08:11 2001 Received: from starburst.demon.co.uk (starburst.demon.co.uk [194.222.114.233]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id UAA14749 for ; Thu, 25 Jan 2001 20:08:10 -0800 (PST) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id EAA01719; Fri, 26 Jan 2001 04:07:24 GMT From: Richard Wendland Message-Id: <200101260407.EAA01719@starburst.demon.co.uk> Subject: Re: [e2e] Data + FIN To: nahum@watson.ibm.com Date: Fri, 26 Jan 2001 04:07:23 +0000 (GMT) Cc: end2end-interest@postel.org Reply-To: richard@netcraft.com In-Reply-To: <200101232201.RAA40148@orinoco.watson.ibm.com> from "Erich Nahum" at Jan 23, 2001 05:01:09 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 20 > As to *how frequently* it happens, somebody with ready access > to packet traces can better answer that question. Two years ago, > Anja Feldman gave me a number that was (I believe) on the order > of 40% of TCP connection were doing this, based on a packet trace > from AT&T. I analysed some sample traces I have from the monthly Netcraft Web Server Survey, which shows about 80% of FIN segments carry data on connections transferring over 4096 bytes of data in that direction. But when the connection carries little data it is dramatically less, about 1.3% for connections carrying 1024 bytes or less data, eg a HTTP HEAD response. This fits in well with your suggestion that only when data queues on the host is the FIN usually piggybacked onto the last data segment. The 80% result suggests most, if not all, server OSs are capable of piggybacked FIN onto data segments in some circumstances. Caveats: my analysis only considers the HTTP response side of each connection, not the short GET/HEAD request side. The analysis is of connections to web servers at different IP addresses from a single FreeBSD RFC1323 enabled client system. But since I only look at the HTTP response direction, that would be observing TCP from a wide variety of web servers and OSs. I looked at the last 10 monthly surveys, >4096 byte transfers varied from 76.9% to 84.1% between months, with no particular trend over time, and <=1024 byte transfers from varied from 1.0% to 2.0%. The traces analysed had 47,000 >4096 byte transfers and 445,000 <=1024 byte transfers. The way the samples are selected isn't properly random, so this isn't truly representative of public web servers as a whole - but I'd expect this to be reasonably indicative of higher latency connections. Low latency connections might behave quite differently of course, as data might queue less. Richard -- http://www.netcraft.com/survey/ Richard Wendland richard@netcraft.com From jmulik@unix.temple.edu Thu Jan 25 20:09:31 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id UAA14821 for ; Thu, 25 Jan 2001 20:09:28 -0800 (PST) Received: from typhoon.ocis.temple.edu (jmulik@typhoon.ocis.temple.edu [155.247.166.103]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0Q49RU09103 for ; Thu, 25 Jan 2001 20:09:28 -0800 (PST) Received: from localhost (jmulik@localhost) by typhoon.ocis.temple.edu (8.11.0/8.11.0) with ESMTP id f0Q48nr01979; Thu, 25 Jan 2001 23:08:49 -0500 (EST) Date: Thu, 25 Jan 2001 23:08:49 -0500 (EST) From: Jaiwant Mulik X-X-Sender: To: "Bruce A. Mah" cc: Subject: Re: [e2e] pchar-1.3 available In-Reply-To: <200101251808.f0PI85C97694@bmah-freebsd-0.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 21 Hi Mr. Mah, While compiling your code under linux 2.2.16-22 (Redhat 7.0) I get the following error: [jmulik:1121-1 ~/pchar-1.3]$make c++ -g -O2 -I. -DSIZEOF_BOOL=1 -DHAVE_SOCKLEN_T=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_STRINGS_H=1 -DHAVE_FEATURES_H=1 -D_BSD_SOURCE=1 -DHAVE_HERROR=1 -DHAVE_SNPRINTF=1 -DHAVE_LIBM=1 -DHAVE_IPV6=1 -DNEED_RANDOM_PROTO=1 -c main.cc -o main.o main.cc: In function `int main (int, char **)': main.cc:596: `srandom' undeclared (first use this function) main.cc:596: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [main.o] Error 1 Any suggestions ? bye, On Thu, 25 Jan 2001, Bruce A. Mah wrote: > I'm most pleased to announce the release of pchar-1.3, a utility for > characterizing the individual links along a path between two network > hosts. > > pchar has been tested on various versions of FreeBSD, NetBSD, OpenBSD, > Linux, Solaris, OSF/1, and IRIX, with the primary development on > FreeBSD and Solaris. pchar is written is C++, primarily using recent > versions of gcc, but with some testing also on the SparcWorks C++ > compiler. pchar supports IPv4 and, where applicable, IPv6. > > Recent additions to pchar include: New analysis algorithms based on > the least median of squares linear fit method, new probe types (ICMP > and ICMPv6), the ability to set the outgoing interface of probes, and > a new "tiny traceroute" mode. A number of bugs have been fixed as > well; most notably, IPv6 probes will now return (more) correct values > for the last hop of a path. The CHANGES file included in the pchar > distribution provides more details. > > The file format used for tracefiles has changed, unfortunately in an > incompatable way. Files from pchar-1.2 and earlier are incompatible > with pchar-1.3 and vice versa. Conversion between file formats is a > possibility, but has not been implemented yet. > > More information, as well as downloadable source code, can be found at: > > http://www.employees.org/~bmah/Software/pchar/ > > Questions and comments are welcome, and can be emailed to > or . > > > Jaiwant Mulik ----------------------------------------------------------------------- Email : jmulik@unix.temple.edu (preferred), jmulik@acm.org Home page : http://unix.temple.edu/~jmulik Office hours : Tuesday: 4:40pm to 6:40pm, Friday: 10:40am to 12:40pm Location : Room 1043/1044, Wachman Hall. Phones : (215) 204-3197 (o), (215) 777-4828 (r) ----------------------------------------------------------------------- Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ? "Lets look at this from a logical point of view" - Prof. in class. From padhye@moose.aciri.org Thu Jan 25 21:32:27 2001 Received: from moose.aciri.org (moose.aciri.org [192.150.187.26]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id VAA20402 for ; Thu, 25 Jan 2001 21:32:27 -0800 (PST) Received: (from padhye@localhost) by moose.aciri.org (8.11.1/8.11.1) id f0Q5WLv84191; Thu, 25 Jan 2001 21:32:21 -0800 (PST) (envelope-from padhye) From: Jitendra Padhye Message-Id: <200101260532.f0Q5WLv84191@moose.aciri.org> Subject: Re: [e2e] Data + FIN In-Reply-To: <200101260407.EAA01719@starburst.demon.co.uk> from Richard Wendland at "Jan 26, 2001 4: 7:23 am" To: richard@netcraft.com Date: Thu, 25 Jan 2001 21:32:21 -0800 (PST) Cc: nahum@watson.ibm.com, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 22 > > As to *how frequently* it happens, somebody with ready access > > to packet traces can better answer that question. Two years ago, > > Anja Feldman gave me a number that was (I believe) on the order > > of 40% of TCP connection were doing this, based on a packet trace > > from AT&T. > I have written a TBIT (http://www.aciri.org/tbit/) test to check this. A scan of about 10,000 web servers showed that web servers running Linux 2.0.35-37 (based on NMAP identification) are least likely to piggyback the FIN on the last data packet. Overall, about 28% of the web servers did not piggyback the FIN on the last data packet. There are a few caveats: a. The 10,000 web servers are from a trace taken at a web proxy, this is not a representative sample in any way. b. I set the MSS to 536 bytes. I wonder if the results will be different with a different MSS. c. For each web server, I downloaded the base page (GET /). Unfortunately, I did not keep track of the amount of data transferred. Richard's data clearly indicates that this is important. - Jitu From J.Crowcroft@cs.ucl.ac.uk Fri Jan 26 00:26:50 2001 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id AAA02320 for ; Fri, 26 Jan 2001 00:26:49 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Jan 2001 08:26:39 +0000 To: "Elbakoury, Hesham [SC5:323:EXCH]" cc: end2end-interest@postel.org Subject: Re: [e2e] Scalability of Ip Multicast In-reply-to: Your message of "Thu, 25 Jan 2001 20:07:37 EST." <200101260107.UAA23678@ertpg14e1.nortelnetworks.com> Date: Fri, 26 Jan 2001 08:26:38 +0000 Message-ID: <26266.980497598@cs.ucl.ac.uk> From: Jon Crowcroft Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 23 a good start is On the Aggregatability of Multicast Forwarding State David Thaler (Microsoft), Mark Handley (AT&T Center for Internet Research at ICSI (ACIRI)) IEEE Infocom 2000 - can be fetched from: http://www.comnet.technion.ac.il/infocom2000/program.html#41 refers to mos tthe other up to date work... In message <200101260107.UAA23678@ertpg14e1.nortelnetworks.com>, "Elbakoury, He sham [SC5:323:EXCH]" typed: >>This message is in MIME format. Since your mail reader does not understand >>this format, some or all of this message may not be legible. >> >>------_=_NextPart_001_01C08589.D0541900 >>Content-Type: text/plain; >> charset="iso-8859-1" >> >>Can any one point me to work (Papers, documents, reports, ... etc) that has >>been done in the area of improving the scalability of IP multicast. >> >> Thanks >> >> Hesham >> >> >>------_=_NextPart_001_01C08589.D0541900 >>Content-Type: text/html; >> charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >>>charset=3Diso-8859-1"> >>>5.5.2652.35"> >>Scalability of Ip Multicast >> >> >> >>

Can any one point me to work (Papers, = >>documents, reports, ... etc) that has been done in the area of = >>improving the scalability of IP multicast.

>> >>

   Thanks >>

>> >>

   Hesham >>

>> >> >> >>------_=_NextPart_001_01C08589.D0541900-- >>_______________________________________________ >>end2end-interest mailing list >>end2end-interest@postel.org >>http://www.postel.org/mailman/listinfo/end2end-interest cheers jon From slow@caltech.edu Fri Jan 26 16:30:58 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA25289 for ; Fri, 26 Jan 2001 16:30:58 -0800 (PST) Received: from imap.cs.caltech.edu (imap.cs.caltech.edu [131.215.44.17]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0R0UwU13680 for ; Fri, 26 Jan 2001 16:30:58 -0800 (PST) Received: from [131.215.44.217] (HELO caltech.edu) by imap.cs.caltech.edu (CommuniGate Pro SMTP 3.3.1) with ESMTP id 808380 for end2end-interest@isi.edu; Fri, 26 Jan 2001 16:26:30 -0800 Message-ID: <3A7216F3.995BAF51@caltech.edu> Date: Fri, 26 Jan 2001 16:31:47 -0800 From: Steven Low Reply-To: slow@caltech.edu Organization: Caltech X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: end2end-interest@ISI.EDU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] [Fwd: RED-->ECN] Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 24 > From: Steven Low > To: hari@lcs.mit.edu, slow@caltech.edu > CC: cwcam@caltech.edu, ecn-interest@research.att.com, end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, wch@its.caltech.edu > > > Hi Hari, > > I completely agree that there are unresolved issues with the > third approach (drastically reduce buffer overslows so that > losses become primarily due to wireless effects), and you > nicely touch upon several of them. But I'd like to make two > philosophical points about ECN & congestion control first > (which I hope belongs to this list at least peripherally). > > I think the approach of > congesting the network in order to obtain congestion information > as the current TCP does, which is necessary without ECN, > becomes unnecessary with ECN. With AQM, we can decouple > congestion measure & feedback from performance measure such > as loss, delay or queue length. Then, 'congestion' > means 'demand exceeds supply' and congestion signal curbs demands > but the queue can be controlled in a way that maintains good > performance such as low loss & delay. Whether REM can succeed > doing this is a separate matter, but I think this is the approach > we ought to take in designing our congestion control. Alternatively, > when we couple congestion measure with performance measure, > 'congestion' necessarily means 'bad performance' such as high > loss or delay, and we do not have the *option* (even if we have > the means) of maintaing low loss & delay in times > of congestion (i.e. when new sources joining or capacity drops). > In other words, when there are more sources, loss or delay must be > increased in order to produce high enough signal intensity for > sources to futher cut back their rates; moreover signal intensity > must stay high not only during transient > when new soruces first start but also afterwards. > > REM tries to fix this, not through the exponential form of its > marking probabiltiy function, but by using a different congestion > measure and update rule, that maintains high utilization and low > queue in equilibrium. Again, there can be alternative ways to > achieving this, but I think this is what we should aim for. > And to achieve this it is critical that we decouple congestion > measure from performance measure. > > The second philosophical point is an interesting implication > of the recent extensive works on heavy-tailed traffics and their > origin. It implies that the misc-elephant mix (i.e. > most files are small but most packets belong to long files) > that characterizes current traffics may be a permanent and > essential feature, not an artifice of current applications or > user behavior. The end-to-end congestion control, properly > designed, can be an ideal mechanism in such an environment, > where elephants (that care about bandwidth) > are controlled to maximally utilize the network > in such a way that leaves the queues close to empty, so that > mice (that are delay sensitive) can fly through the network > with little delay. Again, this require a new TCP/AQM strategy > that achieves high utilization + low queue, and ECN (or > explicit notification) helps. > > A common objection to end-to-end congestion control is that > most TCP connections are short and hence end-to-end congestion > control is ineffective. I believe the observation is correct > but not the conclusion. Since HTTP uses TCP and web files > have mice-elephant mix, most TCP connections are therefore mice, > which indeed should not be the primary object for end to end > control. End to end control should target elephants, not mice. > Mice suffer large delay currently, not because they are end to > end controlled, but because the current congestion control (even > just of elephants) can produce large queues in the path of mice. > > So, with the a TCP/AQM strategy that maintains high utilization > and low queue in equilibrium (regardless of hte number of sources), > buffer is used *only* to absorb *transient* bursts. This can be > very different with a scheme that uses, say, queue length to > measure congestion; with such a scheme, we do not have control > on the equilibrium value of the queue - it is determined solely by > the network topology and #sources and hence can be high depending > on scenario. When queues are always high, they do not have > reserve to handle burst. But when queues are always low, I > think bursts can be much better handled. > > So much for such vague philosophical discussions. Since this > is getting too long, I'd defer discussion on the unresolved > issues with the third approach to some other time (except to > point out that one big challenge is the heterogeneity of > routers during transition when some routers mark packets > and some drop packets to indicate congestion). Btw, I don't > think the three approaches are mutually exclusive and can't > complement each other. > > Steven > > ____________________________________________________________ > Steven Low, Assoc Prof of CS and EE > Caltech, Pasadena, CA91125 > Tel: +1 626 395 6767 Fax: +1 626 792 4257 > slow@caltech.edu > netlab.caltech.edu > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 2001 > >Delivered-To: ecn-interest@research.att.com > >X-url: http://nms.lcs.mit.edu/~hari/ > >To: slow@caltech.edu > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, wch@its.caltech.edu, > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu > >Subject: Re: RED-->ECN > >Mime-Version: 1.0 > >Date: Fri, 26 Jan 2001 15:56:20 -0500 > >From: Hari Balakrishnan > > > > > >Steven, > > > >REM is an interesting idea for using ECN, and I rather like it from a research > >standpoint because it doesn't have discontinuities (cf. RED) that make analysis > >harder. However, I'm generally skeptical that any scheme can be shown to > >eliminate essentially all buffer overflow losses under _all_ conditions > >(offered load), and yet accommodate bursts and provide reasonably low delays... > > especially when not all offered traffic is reacting or reacting in different > >ways from multiplicative-decrease. Even a small fraction of unresponsive > >traffic may make life problematic. > > > >Some years ago, I found it pretty hard to tune RED for this, to enhance my ELN > >scheme. REM may be more promising, but my gut feeling (as a network engineer) > >tells me that it wouldn't be prudent to such implicit deductions about loss > >causes in practice... > > > >Hari > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: > > > >> [Sorry for the previous broken msg...] > >> > >> Hi Saverio, > >> > >> Another point I'd like to add is that the addition of ECN > >> may open up new opportunities for network control, some of > >> which we may not even envision now. Without ECN we are > >> stuck with using loss (or delay) as the only means to > >> communicate between network and TCP sources. > >> Let me give an example. > >> > >> There are two types of losses in wireless environment: > >> 1. due to congestion (e.g. buffer overflow), and > >> 2. due to wireles effect (handoffs, fast fading, interference etc). > >> One problem with TCP over wireless links is that TCP cannot > >> differentiate > >> between the two and essentially assume all losses are due to > >> congestion and reduce its rate. Most of the current proposed > >> solutions are based on two ideas. > >> > >> The first idiea is to hide type 1 (wireless) losses from TCP source, > >> so it sees only congestion losses and react properly. Examples > >> are various local recovery schemes, snoop, split TCP etc. > >> The first idea is to inform the TCP source which of the two > >> types a loss belongs, so that TCP can react properly; e.g. ELN schemes. > >> > >> Availability of ECN allows a third approach: to eliminate type 2 > >> (congestion) losses, so that TCP source only sees wireless losses > >> and therefore know how to react. But we still need to measure and > >> feedback 'congestion' so that sources know to reduce their rates > >> when new sources join or capacity drops. By 'congestion', I don't > >> mean 'high loss', but simply 'demand exceeds supply' so everyone > >> should reduce their demand. Since buffer overflow is now eliminated > >> (assume we can do this, see below), we need a different mechanism to > >> measure and to feedback this 'congestion' information. Here is > >> where ECN comes in. When we decouple the measure+feedback of > >> congestion from loss, we must have ECN to provide the feedback. > >> > >> Now, can we possibly keep the queue small (greatly reduce buffer > >> overflow) *yet highly utilized*? Recent research works seem to > >> provide > >> reasons to be optimistic. One example is in our paper: > >> REM: Active Queue Management > >> on our website: > >> netlab.caltech.edu > >> > >> Steven > >> > >> > >> > >> > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 > >> >From: "K. K. Ramakrishnan" > >> >To: Saverio Mascolo > >> >Cc: ecn-interest@research.att.com > >> > > >> >Saverio, > >> >I am glad you see ECN as an evolution from RED. > >> >This is our motivation also: > >> >to have ECN incorporated and deployed with an > >> >Active Queue Management scheme. > >> > > >> >However, it is difficult to agree with the other observations you make: > >> >if congestion was only caused by "one packet" as you say, then > >> >one might wonder why we need to actually do a whole lot to > >> >one might wonder why we need to actually do a whole lot to > >> >either react to or avoid congestion. Unfortunately, that isn't the case. > >> > > >> >If you look at a congestion epoch, there are likely to be multiple > >> >packets, > >> >potentially from multiple flows, that are impacted: > >> >either being marked or dropped. > >> >ECN helps substantially in not dropping packet*s* - and especially > >> >when the window size for those flows that have their packets > >> >marked, it helps by not having them suffer a time-out. > >> > > >> >Further: the amount of complexity in either the router (especially > >> >in the router) or the end-system is not significant. I know that > >> >may be a matter of opinion. > >> >But in a router, the change is so minimal, I haven't heard anyone > >> >complain of complexity of implementation. > >> > > >> >There is no violation of layering, at all. I don't see why you say so. > >> > > >> > K. K. Ramakrishnan > >> >Saverio Mascolo wrote: > >> > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN saves one > >> >> packet, which is the packet that > >> >> RED would drop to signal congestion, by setting a bit in the header. > >> >> Thus, to save just > >> >> ONE PACKET, ECN introduces complexity in routers, in the > >> >> protocol, violation of layering, etc...For these reasons I don't think > >> >> that ECN would give an improvement to RED that is commensurate to its > >> >> complexity.Is there any point that I miss? Saverio > >> >> > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html -- __________________________________________________________________ Steven Low, Assoc Prof of CS & EE slow@caltech.edu netlab.caltech.edu Tel: (626) 395-6767 Caltech MC256-80 Fax: (626) 792-4257 Pasadena CA 91125 From bmah@cisco.com Fri Jan 26 16:44:56 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA26943 for ; Fri, 26 Jan 2001 16:44:56 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0R0iuU16581 for ; Fri, 26 Jan 2001 16:44:56 -0800 (PST) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA24837; Fri, 26 Jan 2001 16:45:04 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id f0R0iok75829; Fri, 26 Jan 2001 16:44:50 -0800 (PST) (envelope-from bmah) Message-Id: <200101270044.f0R0iok75829@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4 To: Jaiwant Mulik Cc: "Bruce A. Mah" , end2end-interest@ISI.EDU Subject: Re: [e2e] pchar-1.3 available In-Reply-To: References: Comments: In-reply-to Jaiwant Mulik message dated "Thu, 25 Jan 2001 23:08:49 -0500." From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1189169353P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 26 Jan 2001 16:44:49 -0800 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 25 --==_Exmh_-1189169353P Content-Type: text/plain; charset=us-ascii If memory serves me right, Jaiwant Mulik wrote: > While compiling your code under linux 2.2.16-22 (Redhat 7.0) I get the > following error: Lesson learned: Don't do releases around Chinese New Year. Way too much time spent housecleaning, calling relatives, and eating, not enough time left for multi-platform compatability testing. OK. It's a one-line fix...you want to apply the patch below or wait for 1.3.1 (because there's a few other build bugs that slipped through the cracks too). Hopefully I'll have this out in a few days. Sorry this release was kind of rough, and doubly sorry for spamming this whole list with the patch. Bruce. Index: pc.h =================================================================== RCS file: /users5/bmah/src/CVS/pc/pc.h,v retrieving revision 1.25 retrieving revision 1.26 diff -c -r1.25 -r1.26 *** pc.h 2001/01/10 16:08:50 1.25 --- pc.h 2001/01/26 04:37:39 1.26 *************** *** 128,133 **** --- 128,134 ---- #ifdef NEED_RANDOM_PROTO extern "C" { long random(void); + void srandom(unsigned int); } #endif /* NEED_RANDOM_PROTO */ --==_Exmh_-1189169353P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6choB2MoxcVugUsMRAl6wAKDILlwTR1GhXnhKnfLxD4KJ3oFx2gCePzkJ 2+qahzKcbxfV8SG+Vcd7gIk= =9z71 -----END PGP SIGNATURE----- --==_Exmh_-1189169353P-- From misra@newworld.cs.umass.edu Fri Jan 26 17:44:10 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA02477 for ; Fri, 26 Jan 2001 17:44:10 -0800 (PST) Received: from newworld.cs.umass.edu (IDENT:root@newworld.cs.umass.edu [128.119.245.93]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0R1iAU26273 for ; Fri, 26 Jan 2001 17:44:10 -0800 (PST) Received: from nissar.cs.umass.edu (IDENT:misra@nissar.cs.umass.edu [128.119.245.97]) by newworld.cs.umass.edu (8.9.3/8.8.8) with ESMTP id UAA14399; Fri, 26 Jan 2001 20:44:07 -0500 Date: Fri, 26 Jan 2001 20:44:07 -0500 (EST) From: Vishal Misra X-Sender: misra@nissar.cs.umass.edu To: Steven Low cc: end2end-interest@ISI.EDU Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: <200101270036.TAA12756@newworld.cs.umass.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 26 On Fri, 26 Jan 2001, Steven Low wrote: > > In other words, when there are more sources, loss or delay must be > > increased in order to produce high enough signal intensity for > > sources to futher cut back their rates; moreover signal intensity > > must stay high not only during transient > > when new soruces first start but also afterwards. > > > > REM tries to fix this, not through the exponential form of its > > marking probabiltiy function, but by using a different congestion > > measure and update rule, that maintains high utilization and low > > queue in equilibrium. Steven, AQM in the absence of ECN can be counter productive. If you try to control the buffer to low levels, then you reduce delays. However that means that loss must go up almost quadratically (taking the simplified throughput equation for TCP, sqrt(p)*RTT = Constant since link capacity is not changing). That increases the probability of redundant retransmissions as also the probability of flows going into timeouts. Goodput suffers. Hence, decoupling congestion measure and performance measure may not help if your feedback mechanism is drops instead of marks, and will in all likelihood hurt performance. Thus, ECN is *critical* for the success of AQM schemes. -Vishal From slow@caltech.edu Fri Jan 26 18:11:26 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id SAA04437 for ; Fri, 26 Jan 2001 18:11:26 -0800 (PST) Received: from imap.cs.caltech.edu (imap.cs.caltech.edu [131.215.44.17]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0R2BPU00700 for ; Fri, 26 Jan 2001 18:11:25 -0800 (PST) Received: from [131.215.44.217] (HELO caltech.edu) by imap.cs.caltech.edu (CommuniGate Pro SMTP 3.3.1) with ESMTP id 808435; Fri, 26 Jan 2001 18:06:57 -0800 Message-ID: <3A722E7F.5DC40DEB@caltech.edu> Date: Fri, 26 Jan 2001 18:12:15 -0800 From: Steven Low Reply-To: slow@caltech.edu Organization: Caltech X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vishal Misra CC: end2end-interest@ISI.EDU, sanjeewa@caltech.edu Subject: Re: [e2e] [Fwd: RED-->ECN] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 27 > AQM in the absence of ECN can be counter productive. If you try to > control the buffer to low levels, then you reduce delays. However that > means that loss must go up almost quadratically (taking the > simplified throughput equation for TCP, sqrt(p)*RTT = Constant since link > capacity is not changing). That increases the probability of redundant > retransmissions as also the probability of flows going into > timeouts. Goodput suffers. Hence, decoupling congestion measure and > performance measure may not help if your feedback mechanism is drops > instead of marks, and will in all likelihood hurt performance. Thus, ECN > is *critical* for the success of AQM schemes. > > -Vishal Hi Vishal, I completely agree that ECN would be great for AQM. I agree also with your observation that larger delay in fact reduces loss rate. However I'm not sure if I agree that AQM without ECN *necessarily* leads to worse performance. I think it probably depends on 1) various parameters of the scenario, and 2) the specific AQM scheme. Our preliminary ns-2 simulations with REM actually shows improvement in goodput and delay over DropTail (using NewReno) both with or without ECN (see preprint "REM: Active Queue Management" on our website at the end of this email). I can imagine one can probably design scenarios where what you describe is the case. An interesting question is to characterize the conditions under which AQM without ECN helps or hurts. Another question is whether we should rely on large (queueing) delay to keep loss rate down? This doesn't seem a good idea, nor necessary. Steven ps. We hope to post our ns-2 scripts so that anyone interested can play with REM. __________________________________________________________________ Steven Low, Assoc Prof of CS & EE slow@caltech.edu netlab.caltech.edu Tel: (626) 395-6767 Caltech MC256-80 Fax: (626) 792-4257 Pasadena CA 91125 From bmah@cisco.com Mon Jan 29 14:52:24 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA29829 for ; Mon, 29 Jan 2001 14:52:24 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0TMqMU03496 for ; Mon, 29 Jan 2001 14:52:23 -0800 (PST) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA16711; Mon, 29 Jan 2001 14:52:27 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id f0TMq1e07673; Mon, 29 Jan 2001 14:52:01 -0800 (PST) (envelope-from bmah) Message-Id: <200101292252.f0TMq1e07673@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4 To: end2end-interest@ISI.EDU Cc: bmah@cisco.com From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1088897927P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 29 Jan 2001 14:52:01 -0800 Subject: [e2e] pchar-1.3.1 available Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 28 --==_Exmh_1088897927P Content-Type: text/plain; charset=us-ascii Correcting several problems with last week's release of pchar-1.3 (affecting some Solaris and Linux machines, as well as the SNMP support), I've released pchar-1.3.1, at the usual location: http://www.employees.org/~bmah/Software/pchar/ Bruce. --==_Exmh_1088897927P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6dfQR2MoxcVugUsMRAiynAJ9Y58+ro9iTT74smtBnagffLqydPgCgtXw5 GFo6a/++olubFNgnT66k7Ig= =lA7B -----END PGP SIGNATURE----- --==_Exmh_1088897927P-- From matt_wakeley@agilent.com Mon Jan 29 21:13:22 2001 Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id VAA08576 for ; Mon, 29 Jan 2001 21:13:22 -0800 (PST) Received: from msgrel1.and.agilent.com (msgrel1.and.agilent.com [130.30.33.104]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id C166D7A6 for ; Mon, 29 Jan 2001 22:13:21 -0700 (MST) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [156.140.232.231]) by msgrel1.and.agilent.com (Postfix) with ESMTP id 1865717D for ; Tue, 30 Jan 2001 00:13:21 -0500 (EST) Received: from agilent.com (cos1nai135105.cos.agilent.com [141.184.135.105]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id VAA06577 for ; Mon, 29 Jan 2001 21:13:19 -0800 (PST) Message-ID: <3A764D6D.1829C5B@agilent.com> Date: Mon, 29 Jan 2001 21:13:17 -0800 From: Matt Wakeley Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "reflector, end2end" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] Nagle algorithm clarification Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 29 Hi, RFC 1122 Requirements for Internet Hosts states: "A TCP SHOULD implement the Nagle Algorithm [TCP:9]" and the reference is: '[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.' Under "discussion" is the following: "The Nagle algorithm is generally as follows: If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the sending TCP buffers all user data (regardless of the PSH bit), until the outstanding data has been acknowledged or until the TCP can send a full-sized segment." So, I turn to RFC896 and find that it's official status is "unknown" - what does that mean? How can an RFC that is a "standard" mandate the implementation of an RFC of "unknown" status? Anyway, RFC 896 Congestion Control in IP/TCP Internetworks (the Nagle algorithm) states: "inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unacknowledged. This inhibition is to be unconditional; no timers, tests for size of data received, or other conditions are required." 896 states "This inhibition is to be unconditional" but 1122 adds "or until the TCP can send a full-sized segment". So, there appears to be a conflict in the RFCs. Any comments on which is the correct implementation? -Matt From dab@frantic.bsdi.com Tue Jan 30 08:17:15 2001 Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA29535 for ; Tue, 30 Jan 2001 08:17:05 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.10.1/8.10.1) id f0UGGWx00618; Tue, 30 Jan 2001 10:16:32 -0600 (CST) Date: Tue, 30 Jan 2001 10:16:32 -0600 (CST) From: David Borman Message-Id: <200101301616.f0UGGWx00618@frantic.bsdi.com> To: end2end-interest@postel.org, matt_wakeley@agilent.com Subject: Re: [e2e] Nagle algorithm clarification Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 30 Matt, > From: Matt Wakeley > Subject: [e2e] Nagle algorithm clarification > Date: Mon, 29 Jan 2001 21:13:17 -0800 ... > Anyway, RFC 896 Congestion Control in IP/TCP Internetworks (the Nagle > algorithm) > states: > > "inhibit the sending of new TCP segments when > new outgoing data arrives from the user if any previously > transmitted data on the connection remains unacknowledged. This > inhibition is to be unconditional; no timers, tests for size of > data received, or other conditions are required." > > 896 states "This inhibition is to be unconditional" but 1122 adds "or until > the TCP can send a full-sized segment". > > So, there appears to be a conflict in the RFCs. Any comments on which is the > correct implementation? RFC-1122 is the standard, so from a standards viewpoint, it's description overrides RFC 896. The purpose of the Nagle algorithm is to avoid sending lots of small packets. So, when you've queued up enough data for a full packet, there is no longer any advantage in delaying that packet, since you won't be able to put any more data into it. The refinements in RFC-1122 are based on the 5 years of experience after RFC-896 was published. -David Borman, dab@bsdi.com From braden@ISI.EDU Tue Jan 30 09:23:52 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA06266 for ; Tue, 30 Jan 2001 09:23:52 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0UHNoU04776; Tue, 30 Jan 2001 09:23:50 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA00973; Tue, 30 Jan 2001 17:23:50 GMT Date: Tue, 30 Jan 2001 17:23:50 GMT Message-Id: <200101301723.RAA00973@gra.isi.edu> To: end2end-interest@postel.org, matt_wakeley@agilent.com Subject: Re: [e2e] Nagle algorithm clarification X-Sun-Charset: US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 31 *> *> So, I turn to RFC896 and find that it's official status is "unknown" - what *> does that mean? How can an RFC that is a "standard" mandate the *> implementation of an RFC of "unknown" status? Mattm The "Unknown" status was Jon Postel's choice of wording. Maybe a better term would have been "pre-standards". In 1984 when RFC896 was written, the Internet was still very much in the research phase. The IETF had not yet been formed (if I recall correctly without looking it up); its predecessor task forces INARCH and Gateway Algorithms were just starting up (as was the End-to-End Task Force, BTW). The technical development of the Internet was under the direction of the IAB, whose membership was basically chosen by the US government -- ARPA, NSF, DOE, and NASA, mostly from the research community. The only Internet "vendor" was BBN. There were no Internet standards as we now know them. If you asked a person from the media about the "Internet", you would have drawn a complete blank. To answer your other question, lots of RFCs mandate the use of basic pieces of computer science and mathematics that are described by documents that are not standards. The description of an algorithm does not have to be a standard, in order to be required by a document that IS a standard. *> states: *> *> "inhibit the sending of new TCP segments when *> new outgoing data arrives from the user if any previously *> transmitted data on the connection remains unacknowledged. This *> inhibition is to be unconditional; no timers, tests for size of *> data received, or other conditions are required." *> *> 896 states "This inhibition is to be unconditional" but 1122 adds "or until *> the TCP can send a full-sized segment". *> *> So, there appears to be a conflict in the RFCs. Any comments on which is the *> correct implementation? *> *> -Matt *> Uhhh, maybe you should take the later document as more authoritative? Bob Braden From raj@cup.hp.com Tue Jan 30 10:16:15 2001 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA12555 for ; Tue, 30 Jan 2001 10:16:15 -0800 (PST) Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel1.hp.com (Postfix) with ESMTP id 9AA06167D; Tue, 30 Jan 2001 10:16:07 -0800 (PST) Received: from cup.hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id KAA02869; Tue, 30 Jan 2001 10:16:06 -0800 (PST) Message-ID: <3A7704E6.A619CB3A@cup.hp.com> Date: Tue, 30 Jan 2001 10:16:06 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: end2end-interest@postel.org Cc: matt_wakeley@agilent.com Subject: Re: [e2e] Nagle algorithm clarification References: <200101301616.f0UGGWx00618@frantic.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 32 > RFC-1122 is the standard, so from a standards viewpoint, it's > description overrides RFC 896. > > The purpose of the Nagle algorithm is to avoid sending lots > of small packets. So, when you've queued up enough data for a > full packet, there is no longer any advantage in delaying that > packet, since you won't be able to put any more data into it. > The refinements in RFC-1122 are based on the 5 years of experience > after RFC-896 was published. Though IIRC, 1122's describing what to do in terms of SND.mumble tends/tended to lead stack writers to interpret the nagle algorithm on a segment by segment basis rather than the correct (imho :) per-send basis. I think there was a discussion about that on tcp-impl (or maybe it was here) but I cannot recall if another RFC was going to be forthcoming on that or not. rick jones -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... From atiq@ou.edu Tue Jan 30 18:18:33 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id SAA05658 for ; Tue, 30 Jan 2001 18:18:33 -0800 (PST) Received: from msmailhub.ou.edu (msmailhub.oulan.ou.edu [129.15.87.16]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0V2IXU00242 for ; Tue, 30 Jan 2001 18:18:33 -0800 (PST) Received: by msmailhub.oulan.ou.edu with Internet Mail Service (5.5.2650.21) id ; Tue, 30 Jan 2001 20:18:32 -0600 Message-ID: <372E9068C013D211891F00805F9FD1C20688C941@mail3.oulan.ou.edu> From: "Atiquzzaman, Mohammed" To: "'end2end-interest@isi.edu'" Date: Tue, 30 Jan 2001 20:18:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [e2e] CFP: Quality of Service over Next-Generation Data Networks Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 33 Call for Papers and Announcement Conference on Quality of Service over Next-Generation Data Networks (IT302, SPIE QoS 2001) http://spie.org/web/meetings/calls/itcom01/confs/IT302.html Part of SPIE's ITCom 2001 - International Symposium and Exhibit on the Convergence of Information Technology and Communications, 20-24 August 2001, Denver, Colorado. Conference Chair ---------------- Mohammed Atiquzzaman, Univ. of Oklahoma, USA Mahbub Hassan, Univ. of New South Wales, Australia Program Committee ----------------- Johnson Agbinya, Vodafone (Australia) Michael S. Borella, 3Com Raouf Boutaba, Univ. of Waterloo (Canada) Candan Cankaya, Alcatel USA, Inc. Subrata De, Vodafone (Australia) Arjan Durresi, Wu-chi Feng, The Ohio State Univ. Nasir Ghani, Sorrento Networks Mounir Hamdi, Hong Kong Univ. of Science and Technology (Hong Kong) Felix Hartanto, Chinese Univ. of Hong Kong William A. Ivancic, NASA Glenn Research Ctr. Sanjay Jha, Univ. of New South Wales (Australia) Marwan Krunz, Univ. of Arizona Wai Sum Lai, AT&T Labs. Vinod Mirchandani, Motorola (Australia) Josi Neuman de Souza, Federal Univ. of Ceara (Brazil) Neeraj K. Sharma, Clarkson Univ. Samar Singh, Univ. of California/Riverside Harsha Sirisena, Univ. of Canterbury (New Zealand) Liren Zhang, Nanyang Technological Univ. (Singapore) Bing Zheng, Univ. of Dayton The best-effort service model of the current Internet does not provide Quality of Service (QoS) guarantees to multimedia and other business-critical transactions. The convergence of services through the Internet means that the next generation data networks will have to support the negotiation and assurance of QoS. In recognition of this need, several efforts have been launched. The Integrated Services (intserv) service model is based on reserving resources for those connections or flows that need QoS assurance. To support this mode of operation, the RSVP signaling protocol has been developed, although other suitable protocols can be used as well. Recently, enhancements have been proposed for RSVP to handle aggregated flows. Complementary to Intserv, the Differentiated Services model classifies and marks all traffic into several classes at network entry so that core routers can simply forward packets according to the QoS requirements of different service classes. In another direction, the Multiprotocol Label Switching (MPLS) paradigm has been developed to enable the efficient support of QoS and the offering of new QoS capabilities. Currently, new mechanisms are under investigation to support QoS over wireless access networks for mobile users. This conference aims to bring together the work that has been carried out in the area of Quality of Service over Next Generation Data Networks. Topics to be covered in this conference include: Integrated and Differentiated Services QoS mapping from Integrated Services to Differentiated Services Active Buffer Management techniques, ex. RED. LAN QoS Multiprotocol Label Switching QoS guarantees in 3G wireless multimedia networks QoS based routing QoS management in multi-bearer IP networks including PSTN, ISDN, satellite, GSM, GPRS and CDMA networks Impact of media compression in QoS networks QoS over Mobile IP QoS enabled MAC design Submitted abstracts should be of approximately 250 words. Authors should submit their abstracts from conference website http://spie.org/web/meetings/calls/itcom01/confs/IT302.html. There will be a proceedings, published by SPIE, distributed at the conference. Accepted papers will be allocated up to 12 pages in the proceedings. Important dates --------------- Abstracts due from authors: 19 February 2001 Manuscripts due from authors: 28 May 2001 Mohammed Atiquzzaman Tel: (405) 325 8077 School of Computer Science Fax: (520) 962 8422, University of Oklahoma (405) 325 4044 200 Felgar St., Room EL-154 Email: atiq@ou.edu Norman, OK 73019-6151 atiq@ieee.org www.cs.ou.edu/~atiq From craig@aland.bbn.com Wed Jan 31 07:38:19 2001 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id HAA11017 for ; Wed, 31 Jan 2001 07:38:19 -0800 (PST) Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id KAA51087 for ; Wed, 31 Jan 2001 10:37:56 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200101311537.KAA51087@aland.bbn.com> To: end2end-interest@postel.org Reply-To: Craig Partridge From: Craig Partridge Date: Wed, 31 Jan 2001 10:37:56 -0500 Subject: [e2e] SIGCOMM Latin America Advance Program available Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 34 Hi folks: FYI, since I know a lot of folks on this list are interested. The advance program and registration information for SIGCOMM's Workshop on Data Communication in Latin American and the Caribbean is now up. A number of E2E-ers will be presenting and we've got a great keynote speaker (Jose Maria Figueres, head of the UN technology program and former president of Costa Rica). And we've got the usual SIGCOMM student travel grant program. The web site is: http://www.acm.org/sigcomm/sigcomm-la/main.html Conference papers (in Spanish and English) should be begin to appear at the site next week. Craig From ewz@cc.gatech.edu Wed Jan 31 08:41:48 2001 Received: from burdell.cc.gatech.edu (root@burdell.cc.gatech.edu [130.207.3.207]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA16560 for ; Wed, 31 Jan 2001 08:41:39 -0800 (PST) Received: from erlang.cc.gatech.edu (erlang.cc.gatech.edu [130.207.8.104]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id LAA15065; Wed, 31 Jan 2001 11:41:38 -0500 (EST) Received: (from ewz@localhost) by erlang.cc.gatech.edu (8.9.3+Sun/8.9.1) id LAA12059; Wed, 31 Jan 2001 11:41:11 -0500 (EST) Date: Wed, 31 Jan 2001 11:41:11 -0500 (EST) Message-Id: <200101311641.LAA12059@erlang.cc.gatech.edu> From: Ellen Witte Zegura To: end2end-interest@postel.org Cc: ewz@cc.gatech.edu Subject: [e2e] thoughts on router-level topology modeling Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 35 I was recently inspired to write down some thoughts on router-level topology modeling. They are below. Comments welcome. Ellen ----- On occasion, people ask me whether they should use GT-ITM[1] to generate topologies for Internet simulations. Usually they mention the Faloutsos work observing power laws in measurements of Internet topology[2], and perhaps they point to some of the more recent topology generators such as Inet[3] and BRITE[4]. Here is an answer. Let me start by explaining that the GT-ITM software package implements a collection of topology generation methods, including standard random graphs, Waxman's variant on random graphs, and the transit-stub method. The transit-stub method uses the other methods to build up a topology whose high-level structure arguably reflects the high-level structure of the Internet, and it is probably the most widely used method in GT-ITM. In principle, any of the graphs generated by GT-ITM could be interpreted as modeling either the router-level Internet topology (where vertices are routers and edges are one-hop connectivity) or the autonomous-system level Internet topology (where vertices are autonomous systems and edges represent peering agreements). In practice, however, transit-stub graphs should be interpreted as router-level models, since they explicitly group vertices into domains, and reflect that grouping in the connectivity between vertices. The graphs generated by the transit-stub method (and indeed by all the methods currently implemented in GT-ITM) will NOT generally have structure described by power laws. I say "generally" because the transit-stub method in particular has many parameters; the structure of the graphs that are generated can vary widely (even for the same size and number of edges) depending on the parameters. It is therefore difficult to make statements that apply to all instantiations of the method. Does that mean you shouldn't use the transit-stub method? If you need an AS-level representation, I would not recommend it. However, if you need a router-level representation, I think it remains a reasonable choice. Let me explain why. First, the power law observations have primarily focused on the autonomous-system level representation of the Internet, because that data is available via BGP route tables. Data on the router-level topology of the Internet can only be obtained indirectly (e.g., by inference from traceroute measurements), since network administrators don't like to reveal details of internal topology. I believe it remains an open question whether the router-level Internet topology has power-law behavior. It wouldn't surprise me if it does, but it also wouldn't surprise me if router-level topology has more complex structural behavior, due to differences in intradomain and interdomain connectivity. Second, many simulations will involve topologies with a few 100s of nodes, due to limitations on simulation speed. My intuition says that these topologies are too small for discussions of power laws (i.e., linear on a log-log plot) to make much sense. And if you are simulating an even smaller topology (few 10s of nodes) a multi-domain topology probably doesn't make much sense. Third, the other options for router-level models are fairly limited. The newer topology generation methods that I know about (BRITE, Inet) target AS-level representation, not router-level representation. They do a fairly good job generating large graphs (1000s of vertices) with power-law behavior similar to that observed in the snapshots of the Internet AS-level topology. But they aren't intended as router-level models. I don't claim the transit-stub method is the last word in router-level topology modeling. Indeed, I'm sure it's not, and I know of some specific things that would improve it. For example, transit domains should have explicitly designated border router vertices, to which all external edges are connected, rather than using all vertices as endpoints of external edges. However, I do think it is currently a reasonable choice for moderate size router-level topologies. Ellen Zegura January 2001 [1] http://www.cc.gatech.edu/projects/gtitm/ [2] Faloutsos, Faloutsos and Faloutsos, On power-law relationships of the Internet topology, Proceedings of Sigcomm 1999. http://www.acm.org/sigcomm/sigcomm99/papers/session7-2.html [3] Jin, Chen and Jamin, Inet: Internet topology generator, Technical report CSE-TR-433-00, Dept of EECS, U. of Michigan. http://topology.eecs.umich.edu/inet/ [4] Medina, Matta and Byers, On the origin of power-laws in Internet topologies, ACM Computer Communication Review, April 2000. http://www.cs.bu.edu/faculty/matta/Research/BRITE/ From touch@ISI.EDU Wed Jan 31 14:21:41 2001 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA28260 for ; Wed, 31 Jan 2001 14:21:41 -0800 (PST) Message-ID: <3A788F9E.F4D9C806@isi.edu> Date: Wed, 31 Jan 2001 14:20:14 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: end2end-interest@postel.org Content-Type: multipart/mixed; boundary="------------8B95D4DE1007ABA2B3CC1311" Subject: [e2e] test of MIME email Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 36 This is a multi-part message in MIME format. --------------8B95D4DE1007ABA2B3CC1311 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a test of MIME-encapsulated mail. Please ignore... Joe --------------8B95D4DE1007ABA2B3CC1311 Content-Type: image/jpeg; name="pcen-logo-small.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="pcen-logo-small.jpg" /9j/4AAQSkZJRgABAgEBLAEsAAD/7QE6UGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABABLAAA AAEAAQEsAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAE4QklNJxAAAAAAAAoAAQAAAAAAAAAC OEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAAB AFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQQAAAAAAAACAAA4QklNBAIAAAAA AAIAAFBIVVQINQAAAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEhVVAg0AAAAAAAEAAAAADhCSU0EBgAA AAAABwAGAAAAAQEA//4AJ0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDQuMAD/ 7gAOQWRvYmUAZEAAAAAB/9sAhAACAgICAgICAgICAwICAgMEAwICAwQFBAQEBAQFBgUFBQUF BQYGBwcIBwcGCQkKCgkJDAwMDAwMDAwMDAwMDAwMAQMDAwUEBQkGBgkNCgkKDQ8ODg4ODw8M DAwMDA8PDAwMDAwMDwwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCABdAJ0DAREA AhEBAxEB/90ABAAU/8QBogAAAAcBAQEBAQAAAAAAAAAABAUDAgYBAAcICQoLAQACAgMBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAIBAwMCBAIGBwMEAgYCcwECAxEEAAUhEjFBUQYTYSJx gRQykaEHFbFCI8FS0eEzFmLwJHKC8SVDNFOSorJjc8I1RCeTo7M2F1RkdMPS4ggmgwkKGBmE lEVGpLRW01UoGvLj88TU5PRldYWVpbXF1eX1ZnaGlqa2xtbm9jdHV2d3h5ent8fX5/c4SFho eIiYqLjI2Oj4KTlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+hEAAgIBAgMFBQQFBgQIAwNt AQACEQMEIRIxQQVRE2EiBnGBkTKhsfAUwdHhI0IVUmJy8TMkNEOCFpJTJaJjssIHc9I14kSD F1STCAkKGBkmNkUaJ2R0VTfyo7PDKCnT4/OElKS0xNTk9GV1hZWltcXV5fVGVmZ2hpamtsbW 5vZHV2d3h5ent8fX5/c4SFhoeIiYqLjI2Oj4OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6 /9oADAMBAAIRAxEAPwD7+Yq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX/ 0Pv5irsVdirsVdirsVdirsVdirsVYd5r/MLyN5FtxdecfNuk+W4WZUQ6hdRQszOSFCozcmJI PQZZjxTyGoglXz9df85qfkXPdyaZ5L1LWvzT1lZWgXSfJmj3mrSNIppQNFGEpXavKmbGHYur lHiMOGPfIiI+ZRaFvf8AnJH8xjZfWtM/5xs81wFn4o3mG+07QYgKV+OTUprdR9BORPZ8InfL D4Hi+61t5Jef85UfnRBeKmsWf5O/l/Z8/wB8uuedtJnnjUnZT9X1KnLtshzMx9maat5zP9WE v+JW2Z6F+fXnTXb22s4/zR/KQ3U7BfqFtqkhdi5AVULxuCSem+9conptPHkMh/zVfT2jaR+Y V9YSjzR5qXR71n/croUFq5VR3Mt5BOrcvD0hTxOYRyYYH0w4h/SJ/wB6YpeiIpVEVnMjKAGk agLEdzQAb+wzFKrsCuxV2Kv/0fv5irsVdirsVdirsVdiqS+YvMnl7yjo195i81a5YeW9B0xP U1DWdTuI7W1gStKyTSsqLUmgqeuSjEzIERZPQK/Pn8yP+flv5P6LFqdr+UukX/5u39g4gl8w pJHonle3nYEhZ9Z1H01NOtIo3qPs50Ol9mtROjmIxA9/1H3RFkseJ8R+Z/8AnNf86Pzp1LUP K3lXzF5i8yaoABb+RfyE0mYQkMDVbzzPqsUtwB2Zrey4Gh4vTfN9i7Bw4ICRgAAd5Zjwj4QB v5mJRxMg8hf84m/85VecoodVtvyb/Lb8obh1Kw+b/wAy7m587+aAB9mQR3jXtpGw7AW0VPDI 5+0tFp9vGlLyxAQH+m+r5SK0X1vD/wA4Kfmr5l0uLTvzR/5zR/MnVbOWFUvvL/lMQeXNNAI+ KJIbcuhQVoKoNu2afJ23pIknHpYnzmTM/b+tPCe9G6D/AM+uP+cW9Ou473zJB5u/MWdDV18y a9PJG5/yltFtSfpOCXtXqqrHGEP6sf12vCH0V5O/5xE/5xo8gTQ3PlL8mfLmk3NvLHPDc+g0 8gliNUfnO8jclPQ1zWZ+2dZnrjyE17h91JAA5Pe9H0bS/L+mWujaNZR6fpdkrJa2UVeEasxY gVJ2qxOa6czM2eaUzyKuxV2KuxV2Kv8A/9L7+Yq7FXYq7FXYq7FX5i/85Q/8/M/yz/Jq4vfJ /wCVlva/m1+YVsWivZoLgjQtMkA6XF3FyNxIp6xQHbo0iHbOk7J9mc+u9c/Rj7yNz/VH6eTE yp+Oxb/nLv8A5z787rGX1f8AMBreUq3XT/Kuiru4DAAWsJUePOZtvtHO6hpuz+xcXEaie87z l7uvyFBjuX6ofkb/AM+m/wAtvLEGnan+e3mS5/NDVYF9X/CNi81hoNtM9OdCjrcT9KFi0Ybu mctr/bCciRpoiP8ASIBlXu5D48TIRfqT5Q8jeTfy/wBIg0DyP5W0rylo1sipFpuk2kVpFRBx BYRKvI07tUnuc5LUarLqJceWRkfM2yZVmOrsVdirsVdirsVdirsVdirsVf/T+/mKuxV2KuxV KNf1/RPKui6p5j8yara6HoOi273eraveyrDb28EYqzyOxAAAwxiZEACyVfzrf85of8/GvMv5 xtqv5dfkxeXnk38q4Xkg1TzNE722p+YYhVa1oj2to4/3XtJIP7wqPgz0fsL2UGKsupFz5iPS Pv6E+XJgZJn/AM4c/wDPtTX/AM2LXSfzG/PFL3yZ+XE/C50TyXGpt9W1mA7q8zbNZ27dtvUd d14Ahjk9t+1MNJeLDUp/7GP6z5XQ69yiL+gTyZ5I8o/l35d07yl5G8uaf5U8taUnp2GjabAs ECDu3FR8TNSrM1WY7kk55rqNTl1EzPLIykep/H2M2U5QrsVdirsVdirsVdirsVdirsVdirsV f//U+/mKuxV2KoPUNQsdJsL7VdUvIdP03TbeS61C/uHWOGCCFS8ksjsQFVFBJJNAMQL2Cv5q f+c3v+cxdX/5yU1TU9E8q391of8Azjr5QvBb2oBMEnmfUUIZZ5V5UdFKc4UIoifvXHNkVfUf Z3sCOigM+cfvJch/N93n/OPTlzaybfTP/Pvn/nAS0v4NF/5yA/PPQoLm1vo47/8ALT8ubyIv EsbUeHU9Qik2bkKNBEwIpSR9yoGD7Se0RxE6fTn1cpSHT+jHz7z05c7TGL9yc88ZuxV2KuxV 2KuxV2KuxV2KuxV2KuxV2KuxV//V+/mKuxV2Kvx3/wCfkX57az5k17Q/+cQ/y51iPTbjzJbj Vvzm8xq/7vT9HRWmFrcFa8EMSG4nqQeAjXpIRnbeyHZAyyOqy/RDl7x1+HT+l7mMj0fL/wDz g7/zjTpH/OR/5of471bRHH/OOX5MT/UfKmiXiuE1vVFAkDS9BJV6XNzv1MUVClQN/wC0vbh0 mPhgayTFR/oQ7/efvs9GMQ/R/wD5ze/5zE89f84o3HkNfK/5WW/m7Q/M0VyuoeY9RmntbG3u oyPq9nE8KMDKyJI7A0ooFOucT2J2Pj7SlKMsvBLoKsy7zVjkyMqfAT/8/l/zEgnWG5/JzynG 7EcYjq92rsCabVizeZPZDT45+HLUgSPIECz8OLf4I4n6Ef8AOJX/ADn/APl9/wA5M6g3krVN Hf8ALn8z0iee08tXNytza6nFEC0jaddFImkdFBZ4mjVgvxDkoJGh7Y7Az9m1KR4oE0JDv7iO jIG0V/zlf/zn3+Wf/OM13L5PtdPl/MH80mt1n/wnZTLDb2CyryifUrsh/RLghljVGkZaGiqQ 2DsjsDUdo+qPpgOcj+jvKDKn52aL/wA/k/zJGppda5+Tflm98sQXSRal+jL2/imjVm/u1u5V lgElOgZRU+Gbafs7ojLwoaoeL3Gqvu2P2c0cRfpF/wA4V/8AOYdx/wA5Z235oXF55Oi8myeR 9VtY9MtIrlrkzadqCzNbPM7KlJQYGDhRx6UzT9tdjy7NlCMpcRlG+VdaTE2+CPOv/P3rzxof nLznoXl/8ovLup6J5d13UdM0zUrrUbyOWe2tLh4opZUWIhWdFDEDYVzeaL2Sx6rAMsM97b0L ANbi76ddkGTDY/8An87+YEzpHF+Ufk6R32VF1i8LE+AHpVORxezGkyyEYauMiegon5cS8Rfq d/zhf/zlH/0NT+WerebdR0ay8s+afLmtTaTr/l2yne4jiQxpNazhpFVuM0bmlR1VvDNF212U ezs/h3xAgEGqtkDb4X/PT/n6/rP5e/m/59/LryF+WOl+Y9I8ianNol1q2r3lxbXM17Zu0N06 xQq6iL1VYRmtWArQVpm17G9m8faOLj8YCXWIHEY917jmgyp9h/lZ/wA5s+WPO/8Azif5n/5y U1zSl0+88gW1+vnfyfp0hne3v7RqQwRNJwJFwkkLIWp9v2OaftLsuWh1XgTO21S5Cj1+HX3J BsPz58sf8/b/AM6POeuaD5a8rfkF5e13XvM91FZaDplnqN9LLczzGiqiiGp8Sew3zo5+yumx 4xlnqQIS5S4dj3fxMeIv3ktjcNbW7Xaol0Y0NykZJQSUHIKTuQD0ziTV7M1fArsVf//W+/mK uxVh/wCYHnXR/wAuPI3m7z75gnS30byfpN3q2oO7BAY7WJpOAJ/acjio7kgZZhxSyzjCPORA HxV/LXc6l53876DqfmeaNtT/AD2/5zN83SaXpApxKaF9aSKZY6bRpcXZjtwR0ihbtns0MWPR 4Y4Qahjjcj7u/wC2XxDW/pn/ACH/ACg0D8iPyn8mfld5djH1Xy1Yql/e/tXd/MTLeXTk7kyz Mzb9BRegGeSdp6+Wu1Es0up28gOQ+TMCn51/8/f/ADidM/Jj8t/I8ThZfOHm031wgO7W+kWs jEEdx6txEfmM6P2KwceqnP8Amx+8/wBqJPyy/wCcZfz+/LT8hPy3/PuPzF+X6+f/AMyvzLjs 9O8lJfWdtNpun2tta3EXrzz3HJ1pLclzHGhL8VBYdRuO1PZ3V6ztDxyQMe1G9wI+XffnSBKg x/8A5wh8v+YdU/5yA8t+fdFtLi58r/kPZ6j56/MHXoQRBbWml6dcvFbvINi91JSIIPiKljSi tSn2r7Rx6ng0mI3IyF106Ae/dYjqgfyG/L/Xf+cvv+cnfLeg+ddVuLuT8xdauvMX5k6qXMc8 lhbq17fpE6/YaRVEEZA+DkKbLmy9oJHs3s0Y8PpuoDy7z7/PzQNy/qw0r8rvy50TyPH+Wule SNFsvIMdkNP/AMIpZxGxe3CCPhJCykPUDdmqSdySd88pGzY+Ef8AnCX/AJxD/Mj/AJxg/Nb8 973VL7Rbj8rfOLww+Q4rS4mk1Ew2l3cSWrXMLRBI+EE5Q0kY1Gbztrto9pmBMOHgFc7u6/Ug Cn47/wDOY35naJ5g/wCc1/PvnHWbBb/yr5J82adpF3pULxwm8tPLjwwXMQkb4Q08kUoqwI33 2zv+xdOcHZUfUImUSbOwBnyv7GB5vs/8kPzJ0f8A5z1/5yefy1fflrpHlT8gND8lX91r/wCW KW9lOmoyk/VYru5vILaKRJfVvFaMwupT0lKtWpzlu0OxcPZvZ5lOp5ZSFSF7Dn6T15HfzSDZ foR/zh//AM4Zaf8A84lXX5nS6d5/vfONp5/vbZ9P064tFtU06ysJLn6rEzCaU3Evp3AV5WC1 47KK5z2u7Uz62MBlIPAKBrf4nryZAU/Fv/nP298z/nh/zmT+ZHlvyHoba/qXkDRl0ew0y3Ue rPHoOnSavqbgADkyGScAdTxCjcgZ1/YGT8h2Vl1RG5l161UR9pLE7lDf8+//APnKO1/ITzD+ Y2la5f28Pkzz75WvtQtJLkfuo9e0i0mudPG9QPrK84CCN2MY7Zl+1ehGs00NTi9VVy6xlX3H 7ysTT61/586eSLq81L86fzW1ONZJjHp3l+2u2UcnuZmkv74g9t2irTx9swPa4jT6fT6Ufwiz 8Bwj9KxfunnBs3Yq7FX/1/v5irsVfmF/z9U/MK/0P8ifLn5VaH8Wufnd5ltNFEQ+01lZOl1K FA/nn9BD7Mc6r2Q0fj6zjPLGL+J2H6T8GMny7/ziL+Wenedf+c37+1MH1vyZ/wA4h+Vbfy95 bdRyhbVYB9UEjEbFnuJbyYf5Sg9s6P2k1vh6EyGxzSrz4ef3AD4rW/ufurfXtppllealfzra 2OnwSXN7cvsscUSl3dvZVBJzzMAk0GT+Yr/n4x/zkd5I/wCciPzX8pXn5Za7L5g8jeTPLhs7 bUXt7i1im1C8uHmumjiuUjcgRpCvIoKkGlRnqvsp2Zl0WCZzR4ZSPI9wG3LztrkbfZ//ADgv /wA4Sf8AOIX5wf8AOPvkHzx5z8rQ/mD+Yh+tHz07a1qkaQXn12cx201lBdRRKscQVR8HF6Fq tWuee9pT1eLNPHnlIG9xxWN9+hqmYfq75f8AyU/K7yb5B1v8tPI/kjR/JXk/zBZ3Vnqek6Na RWyTC8hMEskvBayOUNCzkk9zmvw5DinGY5gg/JL+ZT8oPNWt/wDOCf8AzloZPPfl2bU5fy9u r/y/5l06EhZ7jSr5OCX1kZOKvyi4TR1IDiq1BNR6vrsePt3QfuJDi5i+8fwnu/HRqGxfrF+c P/P2L8jfLnky6ufyjh1Hz353vLcjTLbULGfTtNsZGU0lv5bj0nZUPVIQxbpyUfFnGab2U1cp fv6xwHORIO3lR++gz4mQ/kB/znBrOk/84t2P50/85Ywny1Pq2sXmm/l/rFtp0kMvmqFIHuIJ ILG3VzCWaOSNXdY42Cq/RuRwcnZsdVq5YtADOI6n5E9Nr+Kb23fj5/zib+Y35NaH/wA5C63+ aX/OSCpd+XLm11nUY9HudJOuQXWr6tODxmt+Eq0iSWRgxU/EFz0Pt3s/UZdANNgjxH0g7gUI ++uoDAHd77F/zlJ+Q3/ON2u/nx5y/wCcX/r/AJn87/nQ7J5dnu9Bh0DQPJVj60s3oWtsZGku iGkDBfTjjqi8tqqdHpuwO0NXjx4NVUMOPkBXF9l/MpsDk/QH/nDLXG/5xs/5xHi/N/8A5yV/ MbV7G08+6mNcs4vMFxd3z2NnfuI7CG2tqTS87oE3LLGvR6kAKxHPdqiOu1pxaTGKGw4RRlXM n8ckjYPgr/nAj8zvI+uf85vefPzC8/ap9R1380Jtbi/L6xe2nuWudS17UlmEPKKNxHwtVZSz 8Vp32zqe29Bn0/Y+LDEXw0Z10qyf9kejGJ3fIX/OX35GS/8AOO3/ADkN57/L21tWg8oajMPM n5eTyrRX0jU3aQQoRQEWs4kt+n7APfJ+xvaBy4Dp5VcOV/zT+o/eFkH7u/8APrfyZL5W/wCc TtB1W4tzBcefNd1bzBVhQvCZRZQN8jHaAj2Nc5v2vzeJrzH+bED/AH36WUeT9Fc5dk7FXYq/ /9D2D/0Vt/5xQqB6fnbfof0LGP13WdUPY3tH+bH/AEwY8Qa/6K2/84n94/OwHj+hY/4XWRl7 H9oAXwg/5wXiD59ufzG0X/nPz/nMz8htU/LnR9Zn/KT8lbGXWfMWpatZm1C6gZmuAhXm60dr e3Vd6n4uwzfaLQ5exOz8+XP6Zy2j52K28xZJ9yg2WB/84m/85P8A5Vf84a3v57eVvz1tvNFn +Znmrz5dXmoQWWlG5Q2dutLeUzNJHyMkk0rACu1D3yz2j7G1evni8CIOOMdjYAN93wpANc31 3ef8/WP+cQNXs7zStUh823Wm6lBJa6haXOgiSGWCZTHIkiCduSsrEEU3Gc4PZPtGBBERYP8A OCeIPz41SX/n0dq+qalqdPzRsW1G5mujp9gL+C1g9V2f0reFNo40rRFGyigzMPZPbcjvklf/ AAz9qLD6g/5x7/5y/wD+fef/ADjH5f8AMHl38q5PPVtaeZtRXVNYuNS028vrmedIVhQerIRR VVdh4knvmHk9me0ssjKQ4iepkCT8bTxB9CaT/wA/Vf8AnE7Ul/0jUPNmkSmZokt7rQLiR2UH 4ZB9VacUfsK8vEDKZ+y3aEf8nfuI/WvEGG/nB+Zf/PvX/nK7RNPv/wAyP01JqVnE0Ohea7by 55jsNYtYufIrDd21gweMmvwOXSpPw1xwdj9qaaXFjiYnylEfpWw84/LD/nHn/n235E1mz8z/ AFTzp+Yt3bss2kw+cdF8yalZxOCGWRbNNJggk9vVRxleqwdpajbMTIDoZxr5cSRQe/f85FH/ AJxC/wCck9L8pab+Zl15/udP8mzXE+iWPl7QfNVmFe6SONzLFb6YeXFYwFJHwgmmxOVYNDrs JvGeAnunGP3SV8j63/zjD/z7a0UwJLF+b1/NO1Pq9paeaXdBSoZw+noADSg365mnT9rkWMky PLJf++XZO7f/AJxe/wCfaOlzabqcsv5karHBNFO+kzWnm25ikCEOYrmKPTalGpxYVFRtXGWm 7Y5Gc/8AlZ/x5dn0h+enmT/nCr/nJ7QPKflb8xNd83RaL5Tu3vdAtdK0fzJpKpKYvq1HCacB RUJCggUFabE5i4uyO0MMuLHGUZd8Tv8AMFbDAvyY/LP/AJ97fkJ59tfzA8m6j5gvPNWm28sG l3Ovwa3qEVk8xAaeCOazCpNxBQP1CswHXJ5cPahiYzOQg8wZE/pWwzT/AJyIH/OCX/OTt75V uvzV81ahJqfk1LqDSNQ0warpsohuzG00M0iWwDJyiBAP2TWnU5i4dDrsMuLHGUTysGj7lsPo fyh/zkh/zix5U8vaF5R8oed9K0Xy3oNtFpuh6Xb213HBbwQLxSNaw9gOp69Tg1Gg1kpmWWMu I8yea2Hplh+fn5R6r9XGmecodQa74/VVtra7lMnI0XiEgJNTsKZinSZRzj9ybemafrFnqtrB eWS3LW9wSI2ltp4GqrFTySZEddx3Hv0yo4yOdfMKmmVq/wD/0ZtL+VX/AD8xuZHZfyi/JSyW Vi1F0TywQlTWnxeoT171zvxr+zx/yMz/ADmx37lBPyO/5+Z3ZUP5R/JnSwdyw0Lyqab9NrCY 798I7T7Oj/yJzn/Oku73r/nGv/nIf8z/ACJr3/OQH5L/AJ7+W/KMXnn8jvKB86Tap5OtYbK1 u7YWy3T280dtHFFyRZY/iRB1II2rmF2l2dDVQw5sWWc45JiHrJJ3J777mQL5p8qfll/zm/8A 85reT9J/PC1/Nf8AL7Q/LXm+e8Gk+Xp9PiWbT4rW6ktmhYrpVy7cTESOUzMRQmlaDcDtHQdj Slp7y8Ue4+ncXt6h9zGzJNX/AOfZH/OUuoPXVP8AnILyhEGIDG202avEClQFtod/bAPbTTDp l/037UcKl/0SO/NTUR/ua/5yH0kkj4hDo1w4qOg3uI/nXIS9tcHSGQ++f9q8KItv+fNWoM3+ nf8AOQUCqa8jD5bZmr7c9RGVn24xgbYT/pv2Lwvo38mv+fVf5G+RbTXo/wA1Lp/zpvNSlt20 e7uIrnRBpqRBxIsYsr4lzKWBJc7cRTqc1eu9sNTmMfBHh1z5Sv5x6JEXtjf8+7P+cPCKD8oV jHUBNa1pafKl9mv/ANE+v/nj/SQ/4lPCFP8A6J0f84e/+Wmb/uO65/2X4/6Jtd/Oj/pIf8St BcP+fdv/ADiKnL0fyxubZmFC8PmHXkNPCov8ifaPWHmY/wCkh/xK0EQv/Pv3/nF6OIQ2/lHX rSNTVVg82eYYwDWuwGoUGP8Aoi1Z58H/ACrh/wAStBRm/wCffv8AzjlJy9Gz852fJeP7jzn5 hG/83xXzb/PAPaDUdY4z/mR/UgxCgP8AnAH8kkNYfM35nQDjx4x+edbAoPncHE9v5j/Bj/0g RwDz+ZRUP/OCH5SWzF7bzx+a9uxHEtH591xTTw2uMh/LeX/U8X/KuP6kiNMk03/nDr8vdNuI Zx+YP5s3iQkVtLn8wPMDwuo/ZZVu1JHtXIT7XnL/ACeP/SR/UmnpHlz8i/LHl3T0sh5m86av KkkjnUdQ8z6tJM3M/CpCXKR0QUUUTtvU1OYmTWGZ2jEe4Jp6Zo/l3T9Gt1t4Wub4o/NbvUJ5 Ly4B229acu9BTYVzHnkMlT3IK7FX/9L7+Yq7FX81n/OaunfldP8A85h/nZLrnnH8xtK5Wmnn zRY+SfLVlqCrF+irISia5m12z5QEcTIZIQobahoGPqXY0pjs7DcYHc8PHKt7Ncoy37mB5v1m /wCfclv5Wtv+cY9Dj8j6xr2t+UTrusNod35k02z0vUAv1k+sjw2N9qERUT+oVb1ASNiopU8b 7TnIddLxABKhdEkculiJ5eSY8n3bnPsnYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq//Z --------------8B95D4DE1007ABA2B3CC1311-- From touch@ISI.EDU Wed Jan 31 15:57:56 2001 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA13459 for ; Wed, 31 Jan 2001 15:57:56 -0800 (PST) Message-ID: <3A78A629.620CEEF6@isi.edu> Date: Wed, 31 Jan 2001 15:56:25 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: end2end-interest@postel.org Subject: Re: [e2e] test of MIME email (question about MIME) References: <200101312250.f0VMoDS15294@chinstrap.CS.Princeton.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 37 Hi, all, There were enough questions regarding this that I figured I'd send to the list. The purpose of the test was to make sure the mail system did not defeat MIME, _not_ to support or endorse it for most posts. Earlier postings included a trailer (a mail list signature) that, I was later shown, broke a MIME standard. The purpose of the test was to verify that the list was configured to avoid that error. I'm not endorsing sending MIME to this list - it's basically a discussion list. However, MIME is sometimes sent even as a wrapper for ASCII from some mailers (which those without can easily enough ignore), and I wanted to make sure the mailer did not a-prior defeat it. I hope that helps... Joe From hussein@ee.washington.edu Wed Jan 31 20:09:41 2001 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id UAA09376 for ; Wed, 31 Jan 2001 20:09:40 -0800 (PST) Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id UAA02381; Wed, 31 Jan 2001 20:09:26 -0800 (PST) Date: Wed, 31 Jan 2001 20:09:23 -0800 (PST) From: Alhussein Abouzeid To: Steven Low cc: end2end-interest@postel.org Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: <3A7216F3.995BAF51@caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 38 Hi Steven, I generally agree with your approach below but have three, also philosophical, comments that I'd like to share with you regarding the decoupling of congestion measures from performance measures. Clearly, decoupling these two measures may greatly help in the design of congestion control algorithms, since the congestion information becomes explicitly available (through say, ECN). However, even with the use of ECN, full decoupling is not possible. The reason is that ECN packets themselves might be lost if sudden congestion takes place. Another point is regarding your argument that controlling "elephants" will result in low queue levels and hence "mice" will be able to run quickly through the network. While this argument seems quite sensible, at least to me, it is problematic if you imagine the arrival of many such mice - say a mice invasion. Will the ECN marking rate/scheme used for signaling the elephants be enough to pro-actively avoid congestion from this mice invasion? I think that, at least, this is an important part of the puzzle that should not be taken lightly. In other words, the so called *transient* effect due to the mice population has to be accommodated and handled as carefully as the elephants' *steady state* effect. Finally, I'd like to add one more point; that the same level of decoupling that you propose can still be achieved using AQM without ECN. In one context, RED can be viewed as a controller that estimates the state and acts upon the estimate. The average queue size is taken as a measure of the state and the feedback signal is a function of the state estimate. However, the average queue size need not be the only measure of congestion. Indeed, some recent works suggested measuring the arrival rate directly (using some filter to smooth out transients) and using this as the measure of congestion. In some sense, such schemes attempts to achieve the rightful objective you mentioned; decide whether demand exceeds capacity. Both approaches (queue-based or rate-based) have some problems that are too involved to detail here. If the AQM router uses a rate-based measure of congestion and drops packets when demand exceeds capacity (according to some reasonable algorithm), then we effectively achieve the same level of decoupling, and also in this case, the (average) buffer level can be kept low. In summary, in my opinion, ECN is a much more decent way of informing the sources about congestion, instead of the "cruel" way of packet dropping. As mentioned by others, it also saves the efforts of all the routers (if any) that processed the packet before it was finally dropped somewhere along the path, and also the effort of the source in detecting the packet loss. It has other virtues along the same lines that I am not listing here. It can be used to distinguish between congestion-related and non congestion-related losses only to some degree of reliability. Other than that (which are by no means minor enhancements), I don't think ECN is *essential* for the decoupling between congestion control and performance measures (e.g. queuing delay). Just a few thoughts. Sincerely, -Alhussein. On Fri, 26 Jan 2001, Steven Low wrote: > > > From: Steven Low > > To: hari@lcs.mit.edu, slow@caltech.edu > > CC: cwcam@caltech.edu, ecn-interest@research.att.com, end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, wch@its.caltech.edu > > > > > > Hi Hari, > > > > I completely agree that there are unresolved issues with the > > third approach (drastically reduce buffer overslows so that > > losses become primarily due to wireless effects), and you > > nicely touch upon several of them. But I'd like to make two > > philosophical points about ECN & congestion control first > > (which I hope belongs to this list at least peripherally). > > > > I think the approach of > > congesting the network in order to obtain congestion information > > as the current TCP does, which is necessary without ECN, > > becomes unnecessary with ECN. With AQM, we can decouple > > congestion measure & feedback from performance measure such > > as loss, delay or queue length. Then, 'congestion' > > means 'demand exceeds supply' and congestion signal curbs demands > > but the queue can be controlled in a way that maintains good > > performance such as low loss & delay. Whether REM can succeed > > doing this is a separate matter, but I think this is the approach > > we ought to take in designing our congestion control. Alternatively, > > when we couple congestion measure with performance measure, > > 'congestion' necessarily means 'bad performance' such as high > > loss or delay, and we do not have the *option* (even if we have > > the means) of maintaing low loss & delay in times > > of congestion (i.e. when new sources joining or capacity drops). > > In other words, when there are more sources, loss or delay must be > > increased in order to produce high enough signal intensity for > > sources to futher cut back their rates; moreover signal intensity > > must stay high not only during transient > > when new soruces first start but also afterwards. > > > > REM tries to fix this, not through the exponential form of its > > marking probabiltiy function, but by using a different congestion > > measure and update rule, that maintains high utilization and low > > queue in equilibrium. Again, there can be alternative ways to > > achieving this, but I think this is what we should aim for. > > And to achieve this it is critical that we decouple congestion > > measure from performance measure. > > > > The second philosophical point is an interesting implication > > of the recent extensive works on heavy-tailed traffics and their > > origin. It implies that the misc-elephant mix (i.e. > > most files are small but most packets belong to long files) > > that characterizes current traffics may be a permanent and > > essential feature, not an artifice of current applications or > > user behavior. The end-to-end congestion control, properly > > designed, can be an ideal mechanism in such an environment, > > where elephants (that care about bandwidth) > > are controlled to maximally utilize the network > > in such a way that leaves the queues close to empty, so that > > mice (that are delay sensitive) can fly through the network > > with little delay. Again, this require a new TCP/AQM strategy > > that achieves high utilization + low queue, and ECN (or > > explicit notification) helps. > > > > A common objection to end-to-end congestion control is that > > most TCP connections are short and hence end-to-end congestion > > control is ineffective. I believe the observation is correct > > but not the conclusion. Since HTTP uses TCP and web files > > have mice-elephant mix, most TCP connections are therefore mice, > > which indeed should not be the primary object for end to end > > control. End to end control should target elephants, not mice. > > Mice suffer large delay currently, not because they are end to > > end controlled, but because the current congestion control (even > > just of elephants) can produce large queues in the path of mice. > > > > So, with the a TCP/AQM strategy that maintains high utilization > > and low queue in equilibrium (regardless of hte number of sources), > > buffer is used *only* to absorb *transient* bursts. This can be > > very different with a scheme that uses, say, queue length to > > measure congestion; with such a scheme, we do not have control > > on the equilibrium value of the queue - it is determined solely by > > the network topology and #sources and hence can be high depending > > on scenario. When queues are always high, they do not have > > reserve to handle burst. But when queues are always low, I > > think bursts can be much better handled. > > > > So much for such vague philosophical discussions. Since this > > is getting too long, I'd defer discussion on the unresolved > > issues with the third approach to some other time (except to > > point out that one big challenge is the heterogeneity of > > routers during transition when some routers mark packets > > and some drop packets to indicate congestion). Btw, I don't > > think the three approaches are mutually exclusive and can't > > complement each other. > > > > Steven > > > > ____________________________________________________________ > > Steven Low, Assoc Prof of CS and EE > > Caltech, Pasadena, CA91125 > > Tel: +1 626 395 6767 Fax: +1 626 792 4257 > > slow@caltech.edu > > netlab.caltech.edu > > > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 2001 > > >Delivered-To: ecn-interest@research.att.com > > >X-url: http://nms.lcs.mit.edu/~hari/ > > >To: slow@caltech.edu > > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, wch@its.caltech.edu, > > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu > > >Subject: Re: RED-->ECN > > >Mime-Version: 1.0 > > >Date: Fri, 26 Jan 2001 15:56:20 -0500 > > >From: Hari Balakrishnan > > > > > > > > >Steven, > > > > > >REM is an interesting idea for using ECN, and I rather like it from a research > > >standpoint because it doesn't have discontinuities (cf. RED) that make analysis > > >harder. However, I'm generally skeptical that any scheme can be shown to > > >eliminate essentially all buffer overflow losses under _all_ conditions > > >(offered load), and yet accommodate bursts and provide reasonably low delays... > > > especially when not all offered traffic is reacting or reacting in different > > >ways from multiplicative-decrease. Even a small fraction of unresponsive > > >traffic may make life problematic. > > > > > >Some years ago, I found it pretty hard to tune RED for this, to enhance my ELN > > >scheme. REM may be more promising, but my gut feeling (as a network engineer) > > >tells me that it wouldn't be prudent to such implicit deductions about loss > > >causes in practice... > > > > > >Hari > > > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: > > > > > >> [Sorry for the previous broken msg...] > > >> > > >> Hi Saverio, > > >> > > >> Another point I'd like to add is that the addition of ECN > > >> may open up new opportunities for network control, some of > > >> which we may not even envision now. Without ECN we are > > >> stuck with using loss (or delay) as the only means to > > >> communicate between network and TCP sources. > > >> Let me give an example. > > >> > > >> There are two types of losses in wireless environment: > > >> 1. due to congestion (e.g. buffer overflow), and > > >> 2. due to wireles effect (handoffs, fast fading, interference etc). > > >> One problem with TCP over wireless links is that TCP cannot > > >> differentiate > > >> between the two and essentially assume all losses are due to > > >> congestion and reduce its rate. Most of the current proposed > > >> solutions are based on two ideas. > > >> > > >> The first idiea is to hide type 1 (wireless) losses from TCP source, > > >> so it sees only congestion losses and react properly. Examples > > >> are various local recovery schemes, snoop, split TCP etc. > > >> The first idea is to inform the TCP source which of the two > > >> types a loss belongs, so that TCP can react properly; e.g. ELN schemes. > > >> > > >> Availability of ECN allows a third approach: to eliminate type 2 > > >> (congestion) losses, so that TCP source only sees wireless losses > > >> and therefore know how to react. But we still need to measure and > > >> feedback 'congestion' so that sources know to reduce their rates > > >> when new sources join or capacity drops. By 'congestion', I don't > > >> mean 'high loss', but simply 'demand exceeds supply' so everyone > > >> should reduce their demand. Since buffer overflow is now eliminated > > >> (assume we can do this, see below), we need a different mechanism to > > >> measure and to feedback this 'congestion' information. Here is > > >> where ECN comes in. When we decouple the measure+feedback of > > >> congestion from loss, we must have ECN to provide the feedback. > > >> > > >> Now, can we possibly keep the queue small (greatly reduce buffer > > >> overflow) *yet highly utilized*? Recent research works seem to > > >> provide > > >> reasons to be optimistic. One example is in our paper: > > >> REM: Active Queue Management > > >> on our website: > > >> netlab.caltech.edu > > >> > > >> Steven > > >> > > >> > > >> > > >> > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 > > >> >From: "K. K. Ramakrishnan" > > >> >To: Saverio Mascolo > > >> >Cc: ecn-interest@research.att.com > > >> > > > >> >Saverio, > > >> >I am glad you see ECN as an evolution from RED. > > >> >This is our motivation also: > > >> >to have ECN incorporated and deployed with an > > >> >Active Queue Management scheme. > > >> > > > >> >However, it is difficult to agree with the other observations you make: > > >> >if congestion was only caused by "one packet" as you say, then > > >> >one might wonder why we need to actually do a whole lot to > > >> >one might wonder why we need to actually do a whole lot to > > >> >either react to or avoid congestion. Unfortunately, that isn't the case. > > >> > > > >> >If you look at a congestion epoch, there are likely to be multiple > > >> >packets, > > >> >potentially from multiple flows, that are impacted: > > >> >either being marked or dropped. > > >> >ECN helps substantially in not dropping packet*s* - and especially > > >> >when the window size for those flows that have their packets > > >> >marked, it helps by not having them suffer a time-out. > > >> > > > >> >Further: the amount of complexity in either the router (especially > > >> >in the router) or the end-system is not significant. I know that > > >> >may be a matter of opinion. > > >> >But in a router, the change is so minimal, I haven't heard anyone > > >> >complain of complexity of implementation. > > >> > > > >> >There is no violation of layering, at all. I don't see why you say so. > > >> > > > >> > K. K. Ramakrishnan > > >> >Saverio Mascolo wrote: > > >> > > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN saves one > > >> >> packet, which is the packet that > > >> >> RED would drop to signal congestion, by setting a bit in the header. > > >> >> Thus, to save just > > >> >> ONE PACKET, ECN introduces complexity in routers, in the > > >> >> protocol, violation of layering, etc...For these reasons I don't think > > >> >> that ECN would give an improvement to RED that is commensurate to its > > >> >> complexity.Is there any point that I miss? Saverio > > >> >> > > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html > > -- > __________________________________________________________________ > Steven Low, Assoc Prof of CS & EE > slow@caltech.edu netlab.caltech.edu > Tel: (626) 395-6767 Caltech MC256-80 > Fax: (626) 792-4257 Pasadena CA 91125 > _______________________________________________ > end2end-interest mailing list > end2end-interest@postel.org > http://www.postel.org/mailman/listinfo/end2end-interest > From slow@caltech.edu Thu Feb 1 00:22:44 2001 Received: from imap.cs.caltech.edu (imap.cs.caltech.edu [131.215.44.17]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id AAA28174 for ; Thu, 1 Feb 2001 00:22:44 -0800 (PST) Received: from [131.215.44.217] (HELO caltech.edu) by imap.cs.caltech.edu (CommuniGate Pro SMTP 3.3.1) with ESMTP id 812262; Thu, 01 Feb 2001 00:17:48 -0800 Message-ID: <3A791D05.2D416AD8@caltech.edu> Date: Thu, 01 Feb 2001 00:23:33 -0800 From: Steven Low Reply-To: slow@caltech.edu Organization: Caltech X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alhussein Abouzeid CC: end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 39 Hi Alhussein I should clarify what I meant by 'decoupling of congestion measure from performance measure'. I want to distinguish between the *measure* of congestion and the *feedback* of congestion. The measure of congestion, vaguely, should track the number of users or available capacity and this is the information to which users react by adjusting their rates (windows). For example, DropTail measures congestion by loss rate (i.e. congestion = high loss), the original RED measures it by average queue (ie. congestion = high queue). Alternatively, you can measure it by a number you compute, e.g., based on queue length and rate, as you suggested. Then, congestion can simply mean 'demand>supply', but it is possible to update the congestion measure in a way that drives the queue or loss to a very low value, and therefore, the congestion measure can settle down to a high value, telling sources to keep their rates low, while loss and delay are kept low. This is the key benefit, which cannot be achieved without decoupling, for otherwise congestion measure (in this case, loss or queue) must be kept high to send the right signal to users (unless one adapts RED parameters dynamically). This is the first type of decoupling. Note that even with the first type fo decoupling, performance measures such as loss, queue, delay or rate, are used to *update* the congestion measure, but the equilibrium *value* of the congestion measure is determined "solely" (in an idealized world) by the network topology, number of users etc, not by the flow control algorithm. Now, how is the congestion measure fed back? This can be done implicitly through what can be observed at the source, e.g. loss or delay. Or it can be done explicitly using ECN or management packets. This is decoupling the *feedback* of congestion measure from performance measure. By "decoupling", I always meant the first kind of decoupling, which I think is more important in determining the equilibrium behavior of congestion control. I agree with you completely that ECN helps in the second type of decoupling, but not the first type which has to do with the design of AQM (choice of congestion measure and its update rule). In wireless environment, however, because of the two kinds of losses (congestion & random loss), the second type of decoupling becomes useful as well. Regarding your mice-elephant comment, mice invasion may indeed be a problem. But that makes it all the more important that elephants are controlled to leave queues empty (in the absence of mice), and this seems hard to do if congestion measure is coupled with performance measure - empty queue then automatically invites elephants to raise their rates. If empty queue does not mean "increase you rate", then elephants must be fed back (through ECN or probabilistical dropping) other necessary information to set their rates. Steven Alhussein Abouzeid wrote: > > Hi Steven, > > I generally agree with your approach below but have three, also > philosophical, comments that I'd like to share with you regarding the > decoupling of congestion measures from performance measures. > > Clearly, decoupling these two measures may greatly help in the design of > congestion control algorithms, since the congestion information becomes > explicitly available (through say, ECN). However, even with > the use of ECN, full decoupling is not possible. The reason is that ECN > packets themselves might be lost if sudden congestion takes place. > > Another point is regarding your argument that controlling "elephants" will > result in low queue levels and hence "mice" will be able to run quickly > through the network. While this argument seems quite sensible, at least to > me, it is problematic if you imagine the arrival of many such mice - say a > mice invasion. Will the ECN marking rate/scheme used for signaling the > elephants be enough to pro-actively avoid congestion from this mice > invasion? I think that, at least, this is an important part of the puzzle > that should not be taken lightly. In other words, the so called > *transient* effect due to the mice population has to be accommodated and > handled as carefully as the elephants' *steady state* effect. > > Finally, I'd like to add one more point; that the same level of > decoupling that you propose can still be achieved using AQM without ECN. > In one context, RED can be viewed as a controller that estimates the state > and acts upon the estimate. The average queue size is taken as a measure > of the state and the feedback signal is a function of the state > estimate. However, the average queue size need not be the only measure of > congestion. Indeed, some recent works suggested measuring the arrival rate > directly (using some filter to smooth out transients) and using this as > the measure of congestion. In some sense, such schemes attempts to achieve > the rightful objective you mentioned; decide whether demand exceeds > capacity. Both approaches (queue-based or rate-based) have some problems > that are too involved to detail here. If the AQM router uses a > rate-based measure of congestion and drops packets when > demand exceeds capacity (according to some reasonable algorithm), then > we effectively achieve the same level of decoupling, and also in this > case, the (average) buffer level can be kept low. > > In summary, in my opinion, ECN is a much more decent way of informing the > sources about congestion, instead of the "cruel" way of packet > dropping. As mentioned by others, it also saves the efforts of all the > routers (if any) that processed the packet before it was finally dropped > somewhere along the path, and also the effort of the source in detecting > the packet loss. It has other virtues along the same lines that I am not > listing here. It can be used to distinguish between congestion-related > and non congestion-related losses only to some degree of reliability. > Other than that (which are by no means minor enhancements), I don't think > ECN is *essential* for the decoupling between congestion control and > performance measures (e.g. queuing delay). > > Just a few thoughts. Sincerely, > > -Alhussein. > > On Fri, 26 Jan 2001, Steven Low wrote: > > > > > > From: Steven Low > > > To: hari@lcs.mit.edu, slow@caltech.edu > > > CC: cwcam@caltech.edu, ecn-interest@research.att.com, end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, wch@its.caltech.edu > > > > > > > > > Hi Hari, > > > > > > I completely agree that there are unresolved issues with the > > > third approach (drastically reduce buffer overslows so that > > > losses become primarily due to wireless effects), and you > > > nicely touch upon several of them. But I'd like to make two > > > philosophical points about ECN & congestion control first > > > (which I hope belongs to this list at least peripherally). > > > > > > I think the approach of > > > congesting the network in order to obtain congestion information > > > as the current TCP does, which is necessary without ECN, > > > becomes unnecessary with ECN. With AQM, we can decouple > > > congestion measure & feedback from performance measure such > > > as loss, delay or queue length. Then, 'congestion' > > > means 'demand exceeds supply' and congestion signal curbs demands > > > but the queue can be controlled in a way that maintains good > > > performance such as low loss & delay. Whether REM can succeed > > > doing this is a separate matter, but I think this is the approach > > > we ought to take in designing our congestion control. Alternatively, > > > when we couple congestion measure with performance measure, > > > 'congestion' necessarily means 'bad performance' such as high > > > loss or delay, and we do not have the *option* (even if we have > > > the means) of maintaing low loss & delay in times > > > of congestion (i.e. when new sources joining or capacity drops). > > > In other words, when there are more sources, loss or delay must be > > > increased in order to produce high enough signal intensity for > > > sources to futher cut back their rates; moreover signal intensity > > > must stay high not only during transient > > > when new soruces first start but also afterwards. > > > > > > REM tries to fix this, not through the exponential form of its > > > marking probabiltiy function, but by using a different congestion > > > measure and update rule, that maintains high utilization and low > > > queue in equilibrium. Again, there can be alternative ways to > > > achieving this, but I think this is what we should aim for. > > > And to achieve this it is critical that we decouple congestion > > > measure from performance measure. > > > > > > The second philosophical point is an interesting implication > > > of the recent extensive works on heavy-tailed traffics and their > > > origin. It implies that the misc-elephant mix (i.e. > > > most files are small but most packets belong to long files) > > > that characterizes current traffics may be a permanent and > > > essential feature, not an artifice of current applications or > > > user behavior. The end-to-end congestion control, properly > > > designed, can be an ideal mechanism in such an environment, > > > where elephants (that care about bandwidth) > > > are controlled to maximally utilize the network > > > in such a way that leaves the queues close to empty, so that > > > mice (that are delay sensitive) can fly through the network > > > with little delay. Again, this require a new TCP/AQM strategy > > > that achieves high utilization + low queue, and ECN (or > > > explicit notification) helps. > > > > > > A common objection to end-to-end congestion control is that > > > most TCP connections are short and hence end-to-end congestion > > > control is ineffective. I believe the observation is correct > > > but not the conclusion. Since HTTP uses TCP and web files > > > have mice-elephant mix, most TCP connections are therefore mice, > > > which indeed should not be the primary object for end to end > > > control. End to end control should target elephants, not mice. > > > Mice suffer large delay currently, not because they are end to > > > end controlled, but because the current congestion control (even > > > just of elephants) can produce large queues in the path of mice. > > > > > > So, with the a TCP/AQM strategy that maintains high utilization > > > and low queue in equilibrium (regardless of hte number of sources), > > > buffer is used *only* to absorb *transient* bursts. This can be > > > very different with a scheme that uses, say, queue length to > > > measure congestion; with such a scheme, we do not have control > > > on the equilibrium value of the queue - it is determined solely by > > > the network topology and #sources and hence can be high depending > > > on scenario. When queues are always high, they do not have > > > reserve to handle burst. But when queues are always low, I > > > think bursts can be much better handled. > > > > > > So much for such vague philosophical discussions. Since this > > > is getting too long, I'd defer discussion on the unresolved > > > issues with the third approach to some other time (except to > > > point out that one big challenge is the heterogeneity of > > > routers during transition when some routers mark packets > > > and some drop packets to indicate congestion). Btw, I don't > > > think the three approaches are mutually exclusive and can't > > > complement each other. > > > > > > Steven > > > > > > ____________________________________________________________ > > > Steven Low, Assoc Prof of CS and EE > > > Caltech, Pasadena, CA91125 > > > Tel: +1 626 395 6767 Fax: +1 626 792 4257 > > > slow@caltech.edu > > > netlab.caltech.edu > > > > > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 2001 > > > >Delivered-To: ecn-interest@research.att.com > > > >X-url: http://nms.lcs.mit.edu/~hari/ > > > >To: slow@caltech.edu > > > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, wch@its.caltech.edu, > > > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu > > > >Subject: Re: RED-->ECN > > > >Mime-Version: 1.0 > > > >Date: Fri, 26 Jan 2001 15:56:20 -0500 > > > >From: Hari Balakrishnan > > > > > > > > > > > >Steven, > > > > > > > >REM is an interesting idea for using ECN, and I rather like it from a research > > > >standpoint because it doesn't have discontinuities (cf. RED) that make analysis > > > >harder. However, I'm generally skeptical that any scheme can be shown to > > > >eliminate essentially all buffer overflow losses under _all_ conditions > > > >(offered load), and yet accommodate bursts and provide reasonably low delays... > > > > especially when not all offered traffic is reacting or reacting in different > > > >ways from multiplicative-decrease. Even a small fraction of unresponsive > > > >traffic may make life problematic. > > > > > > > >Some years ago, I found it pretty hard to tune RED for this, to enhance my ELN > > > >scheme. REM may be more promising, but my gut feeling (as a network engineer) > > > >tells me that it wouldn't be prudent to such implicit deductions about loss > > > >causes in practice... > > > > > > > >Hari > > > > > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: > > > > > > > >> [Sorry for the previous broken msg...] > > > >> > > > >> Hi Saverio, > > > >> > > > >> Another point I'd like to add is that the addition of ECN > > > >> may open up new opportunities for network control, some of > > > >> which we may not even envision now. Without ECN we are > > > >> stuck with using loss (or delay) as the only means to > > > >> communicate between network and TCP sources. > > > >> Let me give an example. > > > >> > > > >> There are two types of losses in wireless environment: > > > >> 1. due to congestion (e.g. buffer overflow), and > > > >> 2. due to wireles effect (handoffs, fast fading, interference etc). > > > >> One problem with TCP over wireless links is that TCP cannot > > > >> differentiate > > > >> between the two and essentially assume all losses are due to > > > >> congestion and reduce its rate. Most of the current proposed > > > >> solutions are based on two ideas. > > > >> > > > >> The first idiea is to hide type 1 (wireless) losses from TCP source, > > > >> so it sees only congestion losses and react properly. Examples > > > >> are various local recovery schemes, snoop, split TCP etc. > > > >> The first idea is to inform the TCP source which of the two > > > >> types a loss belongs, so that TCP can react properly; e.g. ELN schemes. > > > >> > > > >> Availability of ECN allows a third approach: to eliminate type 2 > > > >> (congestion) losses, so that TCP source only sees wireless losses > > > >> and therefore know how to react. But we still need to measure and > > > >> feedback 'congestion' so that sources know to reduce their rates > > > >> when new sources join or capacity drops. By 'congestion', I don't > > > >> mean 'high loss', but simply 'demand exceeds supply' so everyone > > > >> should reduce their demand. Since buffer overflow is now eliminated > > > >> (assume we can do this, see below), we need a different mechanism to > > > >> measure and to feedback this 'congestion' information. Here is > > > >> where ECN comes in. When we decouple the measure+feedback of > > > >> congestion from loss, we must have ECN to provide the feedback. > > > >> > > > >> Now, can we possibly keep the queue small (greatly reduce buffer > > > >> overflow) *yet highly utilized*? Recent research works seem to > > > >> provide > > > >> reasons to be optimistic. One example is in our paper: > > > >> REM: Active Queue Management > > > >> on our website: > > > >> netlab.caltech.edu > > > >> > > > >> Steven > > > >> > > > >> > > > >> > > > >> > > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 > > > >> >From: "K. K. Ramakrishnan" > > > >> >To: Saverio Mascolo > > > >> >Cc: ecn-interest@research.att.com > > > >> > > > > >> >Saverio, > > > >> >I am glad you see ECN as an evolution from RED. > > > >> >This is our motivation also: > > > >> >to have ECN incorporated and deployed with an > > > >> >Active Queue Management scheme. > > > >> > > > > >> >However, it is difficult to agree with the other observations you make: > > > >> >if congestion was only caused by "one packet" as you say, then > > > >> >one might wonder why we need to actually do a whole lot to > > > >> >one might wonder why we need to actually do a whole lot to > > > >> >either react to or avoid congestion. Unfortunately, that isn't the case. > > > >> > > > > >> >If you look at a congestion epoch, there are likely to be multiple > > > >> >packets, > > > >> >potentially from multiple flows, that are impacted: > > > >> >either being marked or dropped. > > > >> >ECN helps substantially in not dropping packet*s* - and especially > > > >> >when the window size for those flows that have their packets > > > >> >marked, it helps by not having them suffer a time-out. > > > >> > > > > >> >Further: the amount of complexity in either the router (especially > > > >> >in the router) or the end-system is not significant. I know that > > > >> >may be a matter of opinion. > > > >> >But in a router, the change is so minimal, I haven't heard anyone > > > >> >complain of complexity of implementation. > > > >> > > > > >> >There is no violation of layering, at all. I don't see why you say so. > > > >> > > > > >> > K. K. Ramakrishnan > > > >> >Saverio Mascolo wrote: > > > >> > > > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN saves one > > > >> >> packet, which is the packet that > > > >> >> RED would drop to signal congestion, by setting a bit in the header. > > > >> >> Thus, to save just > > > >> >> ONE PACKET, ECN introduces complexity in routers, in the > > > >> >> protocol, violation of layering, etc...For these reasons I don't think > > > >> >> that ECN would give an improvement to RED that is commensurate to its > > > >> >> complexity.Is there any point that I miss? Saverio > > > >> >> > > > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html > > > > -- > > __________________________________________________________________ > > Steven Low, Assoc Prof of CS & EE > > slow@caltech.edu netlab.caltech.edu > > Tel: (626) 395-6767 Caltech MC256-80 > > Fax: (626) 792-4257 Pasadena CA 91125 > > _______________________________________________ > > end2end-interest mailing list > > end2end-interest@postel.org > > http://www.postel.org/mailman/listinfo/end2end-interest > > -- __________________________________________________________________ Steven Low, Assoc Prof of CS & EE slow@caltech.edu netlab.caltech.edu Tel: (626) 395-6767 Caltech MC256-80 Fax: (626) 792-4257 Pasadena CA 91125 From julian_satran@il.ibm.com Thu Feb 1 03:56:11 2001 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id DAA12444 for ; Thu, 1 Feb 2001 03:56:08 -0800 (PST) From: julian_satran@il.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA105582; Thu, 1 Feb 2001 12:55:34 +0100 Received: from d12mta05.de.ibm.com (d12mta05_cs0 [9.165.222.239]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA40428; Thu, 1 Feb 2001 12:55:34 +0100 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12569E6.00417F78 ; Thu, 1 Feb 2001 12:55:24 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: slow@caltech.edu cc: Alhussein Abouzeid , end2end-interest@postel.org, ecn-interest@research.att.com Message-ID: Date: Thu, 1 Feb 2001 13:21:27 +0200 Subject: Re: [e2e] [Fwd: RED-->ECN] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 40 I would be very interested to understand how you see the "virtual-measure", you are suggesting exists, relate to accepted theory. It is usually though that high utilization rates and long queues are related (i.e., you have long queues when utilization goes up) and this is the reason queue length is used as a measure of congestion. And this is true for all accepted queueing models. Do you have in mind some "quantum statistics" for networks that we are all unaware of? Do those have some tunnel effects that allow you to dream about high utilization AND short queues? Is there some mathematics that can support your statements? Julo Julian Satran IBM Research Lab. at Haifa Steven Low on 01/02/2001 10:23:33 Please respond to slow@caltech.edu To: Alhussein Abouzeid cc: end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] Hi Alhussein I should clarify what I meant by 'decoupling of congestion measure from performance measure'. I want to distinguish between the *measure* of congestion and the *feedback* of congestion. The measure of congestion, vaguely, should track the number of users or available capacity and this is the information to which users react by adjusting their rates (windows). For example, DropTail measures congestion by loss rate (i.e. congestion = high loss), the original RED measures it by average queue (ie. congestion = high queue). Alternatively, you can measure it by a number you compute, e.g., based on queue length and rate, as you suggested. Then, congestion can simply mean 'demand>supply', but it is possible to update the congestion measure in a way that drives the queue or loss to a very low value, and therefore, the congestion measure can settle down to a high value, telling sources to keep their rates low, while loss and delay are kept low. This is the key benefit, which cannot be achieved without decoupling, for otherwise congestion measure (in this case, loss or queue) must be kept high to send the right signal to users (unless one adapts RED parameters dynamically). This is the first type of decoupling. Note that even with the first type fo decoupling, performance measures such as loss, queue, delay or rate, are used to *update* the congestion measure, but the equilibrium *value* of the congestion measure is determined "solely" (in an idealized world) by the network topology, number of users etc, not by the flow control algorithm. Now, how is the congestion measure fed back? This can be done implicitly through what can be observed at the source, e.g. loss or delay. Or it can be done explicitly using ECN or management packets. This is decoupling the *feedback* of congestion measure from performance measure. By "decoupling", I always meant the first kind of decoupling, which I think is more important in determining the equilibrium behavior of congestion control. I agree with you completely that ECN helps in the second type of decoupling, but not the first type which has to do with the design of AQM (choice of congestion measure and its update rule). In wireless environment, however, because of the two kinds of losses (congestion & random loss), the second type of decoupling becomes useful as well. Regarding your mice-elephant comment, mice invasion may indeed be a problem. But that makes it all the more important that elephants are controlled to leave queues empty (in the absence of mice), and this seems hard to do if congestion measure is coupled with performance measure - empty queue then automatically invites elephants to raise their rates. If empty queue does not mean "increase you rate", then elephants must be fed back (through ECN or probabilistical dropping) other necessary information to set their rates. Steven Alhussein Abouzeid wrote: > > Hi Steven, > > I generally agree with your approach below but have three, also > philosophical, comments that I'd like to share with you regarding the > decoupling of congestion measures from performance measures. > > Clearly, decoupling these two measures may greatly help in the design of > congestion control algorithms, since the congestion information becomes > explicitly available (through say, ECN). However, even with > the use of ECN, full decoupling is not possible. The reason is that ECN > packets themselves might be lost if sudden congestion takes place. > > Another point is regarding your argument that controlling "elephants" will > result in low queue levels and hence "mice" will be able to run quickly > through the network. While this argument seems quite sensible, at least to > me, it is problematic if you imagine the arrival of many such mice - say a > mice invasion. Will the ECN marking rate/scheme used for signaling the > elephants be enough to pro-actively avoid congestion from this mice > invasion? I think that, at least, this is an important part of the puzzle > that should not be taken lightly. In other words, the so called > *transient* effect due to the mice population has to be accommodated and > handled as carefully as the elephants' *steady state* effect. > > Finally, I'd like to add one more point; that the same level of > decoupling that you propose can still be achieved using AQM without ECN. > In one context, RED can be viewed as a controller that estimates the state > and acts upon the estimate. The average queue size is taken as a measure > of the state and the feedback signal is a function of the state > estimate. However, the average queue size need not be the only measure of > congestion. Indeed, some recent works suggested measuring the arrival rate > directly (using some filter to smooth out transients) and using this as > the measure of congestion. In some sense, such schemes attempts to achieve > the rightful objective you mentioned; decide whether demand exceeds > capacity. Both approaches (queue-based or rate-based) have some problems > that are too involved to detail here. If the AQM router uses a > rate-based measure of congestion and drops packets when > demand exceeds capacity (according to some reasonable algorithm), then > we effectively achieve the same level of decoupling, and also in this > case, the (average) buffer level can be kept low. > > In summary, in my opinion, ECN is a much more decent way of informing the > sources about congestion, instead of the "cruel" way of packet > dropping. As mentioned by others, it also saves the efforts of all the > routers (if any) that processed the packet before it was finally dropped > somewhere along the path, and also the effort of the source in detecting > the packet loss. It has other virtues along the same lines that I am not > listing here. It can be used to distinguish between congestion-related > and non congestion-related losses only to some degree of reliability. > Other than that (which are by no means minor enhancements), I don't think > ECN is *essential* for the decoupling between congestion control and > performance measures (e.g. queuing delay). > > Just a few thoughts. Sincerely, > > -Alhussein. > > On Fri, 26 Jan 2001, Steven Low wrote: > > > > > > From: Steven Low > > > To: hari@lcs.mit.edu, slow@caltech.edu > > > CC: cwcam@caltech.edu, ecn-interest@research.att.com, end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, wch@its.caltech.edu > > > > > > > > > Hi Hari, > > > > > > I completely agree that there are unresolved issues with the > > > third approach (drastically reduce buffer overslows so that > > > losses become primarily due to wireless effects), and you > > > nicely touch upon several of them. But I'd like to make two > > > philosophical points about ECN & congestion control first > > > (which I hope belongs to this list at least peripherally). > > > > > > I think the approach of > > > congesting the network in order to obtain congestion information > > > as the current TCP does, which is necessary without ECN, > > > becomes unnecessary with ECN. With AQM, we can decouple > > > congestion measure & feedback from performance measure such > > > as loss, delay or queue length. Then, 'congestion' > > > means 'demand exceeds supply' and congestion signal curbs demands > > > but the queue can be controlled in a way that maintains good > > > performance such as low loss & delay. Whether REM can succeed > > > doing this is a separate matter, but I think this is the approach > > > we ought to take in designing our congestion control. Alternatively, > > > when we couple congestion measure with performance measure, > > > 'congestion' necessarily means 'bad performance' such as high > > > loss or delay, and we do not have the *option* (even if we have > > > the means) of maintaing low loss & delay in times > > > of congestion (i.e. when new sources joining or capacity drops). > > > In other words, when there are more sources, loss or delay must be > > > increased in order to produce high enough signal intensity for > > > sources to futher cut back their rates; moreover signal intensity > > > must stay high not only during transient > > > when new soruces first start but also afterwards. > > > > > > REM tries to fix this, not through the exponential form of its > > > marking probabiltiy function, but by using a different congestion > > > measure and update rule, that maintains high utilization and low > > > queue in equilibrium. Again, there can be alternative ways to > > > achieving this, but I think this is what we should aim for. > > > And to achieve this it is critical that we decouple congestion > > > measure from performance measure. > > > > > > The second philosophical point is an interesting implication > > > of the recent extensive works on heavy-tailed traffics and their > > > origin. It implies that the misc-elephant mix (i.e. > > > most files are small but most packets belong to long files) > > > that characterizes current traffics may be a permanent and > > > essential feature, not an artifice of current applications or > > > user behavior. The end-to-end congestion control, properly > > > designed, can be an ideal mechanism in such an environment, > > > where elephants (that care about bandwidth) > > > are controlled to maximally utilize the network > > > in such a way that leaves the queues close to empty, so that > > > mice (that are delay sensitive) can fly through the network > > > with little delay. Again, this require a new TCP/AQM strategy > > > that achieves high utilization + low queue, and ECN (or > > > explicit notification) helps. > > > > > > A common objection to end-to-end congestion control is that > > > most TCP connections are short and hence end-to-end congestion > > > control is ineffective. I believe the observation is correct > > > but not the conclusion. Since HTTP uses TCP and web files > > > have mice-elephant mix, most TCP connections are therefore mice, > > > which indeed should not be the primary object for end to end > > > control. End to end control should target elephants, not mice. > > > Mice suffer large delay currently, not because they are end to > > > end controlled, but because the current congestion control (even > > > just of elephants) can produce large queues in the path of mice. > > > > > > So, with the a TCP/AQM strategy that maintains high utilization > > > and low queue in equilibrium (regardless of hte number of sources), > > > buffer is used *only* to absorb *transient* bursts. This can be > > > very different with a scheme that uses, say, queue length to > > > measure congestion; with such a scheme, we do not have control > > > on the equilibrium value of the queue - it is determined solely by > > > the network topology and #sources and hence can be high depending > > > on scenario. When queues are always high, they do not have > > > reserve to handle burst. But when queues are always low, I > > > think bursts can be much better handled. > > > > > > So much for such vague philosophical discussions. Since this > > > is getting too long, I'd defer discussion on the unresolved > > > issues with the third approach to some other time (except to > > > point out that one big challenge is the heterogeneity of > > > routers during transition when some routers mark packets > > > and some drop packets to indicate congestion). Btw, I don't > > > think the three approaches are mutually exclusive and can't > > > complement each other. > > > > > > Steven > > > > > > ____________________________________________________________ > > > Steven Low, Assoc Prof of CS and EE > > > Caltech, Pasadena, CA91125 > > > Tel: +1 626 395 6767 Fax: +1 626 792 4257 > > > slow@caltech.edu > > > netlab.caltech.edu > > > > > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 2001 > > > >Delivered-To: ecn-interest@research.att.com > > > >X-url: http://nms.lcs.mit.edu/~hari/ > > > >To: slow@caltech.edu > > > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, wch@its.caltech.edu, > > > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu > > > >Subject: Re: RED-->ECN > > > >Mime-Version: 1.0 > > > >Date: Fri, 26 Jan 2001 15:56:20 -0500 > > > >From: Hari Balakrishnan > > > > > > > > > > > >Steven, > > > > > > > >REM is an interesting idea for using ECN, and I rather like it from a research > > > >standpoint because it doesn't have discontinuities (cf. RED) that make analysis > > > >harder. However, I'm generally skeptical that any scheme can be shown to > > > >eliminate essentially all buffer overflow losses under _all_ conditions > > > >(offered load), and yet accommodate bursts and provide reasonably low delays... > > > > especially when not all offered traffic is reacting or reacting in different > > > >ways from multiplicative-decrease. Even a small fraction of unresponsive > > > >traffic may make life problematic. > > > > > > > >Some years ago, I found it pretty hard to tune RED for this, to enhance my ELN > > > >scheme. REM may be more promising, but my gut feeling (as a network engineer) > > > >tells me that it wouldn't be prudent to such implicit deductions about loss > > > >causes in practice... > > > > > > > >Hari > > > > > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: > > > > > > > >> [Sorry for the previous broken msg...] > > > >> > > > >> Hi Saverio, > > > >> > > > >> Another point I'd like to add is that the addition of ECN > > > >> may open up new opportunities for network control, some of > > > >> which we may not even envision now. Without ECN we are > > > >> stuck with using loss (or delay) as the only means to > > > >> communicate between network and TCP sources. > > > >> Let me give an example. > > > >> > > > >> There are two types of losses in wireless environment: > > > >> 1. due to congestion (e.g. buffer overflow), and > > > >> 2. due to wireles effect (handoffs, fast fading, interference etc). > > > >> One problem with TCP over wireless links is that TCP cannot > > > >> differentiate > > > >> between the two and essentially assume all losses are due to > > > >> congestion and reduce its rate. Most of the current proposed > > > >> solutions are based on two ideas. > > > >> > > > >> The first idiea is to hide type 1 (wireless) losses from TCP source, > > > >> so it sees only congestion losses and react properly. Examples > > > >> are various local recovery schemes, snoop, split TCP etc. > > > >> The first idea is to inform the TCP source which of the two > > > >> types a loss belongs, so that TCP can react properly; e.g. ELN schemes. > > > >> > > > >> Availability of ECN allows a third approach: to eliminate type 2 > > > >> (congestion) losses, so that TCP source only sees wireless losses > > > >> and therefore know how to react. But we still need to measure and > > > >> feedback 'congestion' so that sources know to reduce their rates > > > >> when new sources join or capacity drops. By 'congestion', I don't > > > >> mean 'high loss', but simply 'demand exceeds supply' so everyone > > > >> should reduce their demand. Since buffer overflow is now eliminated > > > >> (assume we can do this, see below), we need a different mechanism to > > > >> measure and to feedback this 'congestion' information. Here is > > > >> where ECN comes in. When we decouple the measure+feedback of > > > >> congestion from loss, we must have ECN to provide the feedback. > > > >> > > > >> Now, can we possibly keep the queue small (greatly reduce buffer > > > >> overflow) *yet highly utilized*? Recent research works seem to > > > >> provide > > > >> reasons to be optimistic. One example is in our paper: > > > >> REM: Active Queue Management > > > >> on our website: > > > >> netlab.caltech.edu > > > >> > > > >> Steven > > > >> > > > >> > > > >> > > > >> > > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 > > > >> >From: "K. K. Ramakrishnan" > > > >> >To: Saverio Mascolo > > > >> >Cc: ecn-interest@research.att.com > > > >> > > > > >> >Saverio, > > > >> >I am glad you see ECN as an evolution from RED. > > > >> >This is our motivation also: > > > >> >to have ECN incorporated and deployed with an > > > >> >Active Queue Management scheme. > > > >> > > > > >> >However, it is difficult to agree with the other observations you make: > > > >> >if congestion was only caused by "one packet" as you say, then > > > >> >one might wonder why we need to actually do a whole lot to > > > >> >one might wonder why we need to actually do a whole lot to > > > >> >either react to or avoid congestion. Unfortunately, that isn't the case. > > > >> > > > > >> >If you look at a congestion epoch, there are likely to be multiple > > > >> >packets, > > > >> >potentially from multiple flows, that are impacted: > > > >> >either being marked or dropped. > > > >> >ECN helps substantially in not dropping packet*s* - and especially > > > >> >when the window size for those flows that have their packets > > > >> >marked, it helps by not having them suffer a time-out. > > > >> > > > > >> >Further: the amount of complexity in either the router (especially > > > >> >in the router) or the end-system is not significant. I know that > > > >> >may be a matter of opinion. > > > >> >But in a router, the change is so minimal, I haven't heard anyone > > > >> >complain of complexity of implementation. > > > >> > > > > >> >There is no violation of layering, at all. I don't see why you say so. > > > >> > > > > >> > K. K. Ramakrishnan > > > >> >Saverio Mascolo wrote: > > > >> > > > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN saves one > > > >> >> packet, which is the packet that > > > >> >> RED would drop to signal congestion, by setting a bit in the header. > > > >> >> Thus, to save just > > > >> >> ONE PACKET, ECN introduces complexity in routers, in the > > > >> >> protocol, violation of layering, etc...For these reasons I don't think > > > >> >> that ECN would give an improvement to RED that is commensurate to its > > > >> >> complexity.Is there any point that I miss? Saverio > > > >> >> > > > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html > > > > -- > > __________________________________________________________________ > > Steven Low, Assoc Prof of CS & EE > > slow@caltech.edu netlab.caltech.edu > > Tel: (626) 395-6767 Caltech MC256-80 > > Fax: (626) 792-4257 Pasadena CA 91125 > > _______________________________________________ > > end2end-interest mailing list > > end2end-interest@postel.org > > http://www.postel.org/mailman/listinfo/end2end-interest > > -- __________________________________________________________________ Steven Low, Assoc Prof of CS & EE slow@caltech.edu netlab.caltech.edu Tel: (626) 395-6767 Caltech MC256-80 Fax: (626) 792-4257 Pasadena CA 91125 From misra@newworld.cs.umass.edu Thu Feb 1 06:33:33 2001 Received: from newworld.cs.umass.edu (IDENT:root@newworld.cs.umass.edu [128.119.245.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id GAA23338 for ; Thu, 1 Feb 2001 06:33:33 -0800 (PST) Received: from nissar.cs.umass.edu (IDENT:misra@nissar.cs.umass.edu [128.119.245.97]) by newworld.cs.umass.edu (8.9.3/8.8.8) with ESMTP id JAA11548; Thu, 1 Feb 2001 09:33:10 -0500 Date: Thu, 1 Feb 2001 09:33:10 -0500 (EST) From: Vishal Misra X-Sender: misra@nissar.cs.umass.edu To: julian_satran@il.ibm.com cc: end2end-interest@postel.org Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: <200102011216.HAA29271@newworld.cs.umass.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 42 On Thu, 1 Feb 2001 julian_satran@il.ibm.com wrote: > accepted queueing models. Do you have in mind some "quantum statistics" > for networks that we are all unaware of? Do those have some tunnel effects > that allow you to dream about high utilization AND short queues? Is there > some mathematics that can support your statements? Yes, it is called "Control theory" and has been around for hundreds of years. Steven is talking about a *closed loop* control system. TCP (which is responsible for most of the queues in IP networks) is not an open loop protocol. You cannot apply open loop queueing theory models to describe the behavior of "elephants" which Steven was discussing. If your traffic is purely "elephant" then it is possible to design controllers which simultaneously give low delay and (near) full utilization. Several research groups have already done it and demonstrated it both mathematically and through simulations/testbeds. The presence of "mice" complicates things a bit since even though they might be carried by TCP they don't live long enough to be classified as "controllable". -Vishal From mascolo@poliba.it Thu Feb 1 08:23:32 2001 Received: from cstar.poliba.it (IDENT:root@cstar.poliba.it [193.204.49.36]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA02692 for ; Thu, 1 Feb 2001 08:23:30 -0800 (PST) Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by cstar.poliba.it (8.11.0/8.11.0) with SMTP id f11GMTU10573; Thu, 1 Feb 2001 17:22:29 +0100 Message-ID: <008c01c08c6b$4655eec0$723bccc1@poliba.it> From: "Saverio Mascolo" To: , "Michael B Greenwald" Cc: , "Alhussein Abouzeid" , , References: <200102011340.f11DeET20308@codex.cis.upenn.edu> Subject: R: [e2e] [Fwd: RED-->ECN] Date: Thu, 1 Feb 2001 17:23:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 43 Hi all, I would introduce another element of discussion...Explicit congestion indication was proposed in the ATM community...after a while they concluded that it was necessary a richer feedback in order to obtain an effective "regularization" of queue dynamics, utilization etc...thus it was proposed explicit rate indication such ERICA algorithm. Saverio > Thu, 1 Feb 2001 13:21:27 +0200 > julian_satran@il.ibm.com > > I would be very interested to understand how you see the "virtual-measure", > you are suggesting exists, relate to accepted theory. It is usually > though that high utilization rates and long queues are related (i.e., you > have long queues when utilization goes up) > > A quibble: Queue length is a function of variance (burstiness), not (just) > of arrival rate. If the input rate exceeds the output rate, queue length > *becomes* unbounded ("infinite"). If the input rate is less than the > output rate, then (independent of variations in inter-arrival time) the > queue length is 0 -- always empty. For an arbitrarily low *average* input > rate, and a long enough interval, and an unbounded queue, I can construct > an arrival schedule that will cause an arbitrarily high *average* queue > length. > > However, what you say is _basically_ true in the real world because as the > input rate approaches the output rate the queue length becomes much more > sensitive to smaller and smaller variations (not to mention that max queue > length *is* bounded), so queue length in practice is probably usually a > reasonable indicator of load. The control needed to smooth flows as > arrival rates get higher is likely to be fragile, and is probably > inconsistent with the philosophy of most people on end2end. But Steven > Low's statements are not immediately dismissable as being totally > self-contradictory, or in the category of perpetual motion machines. > Not to say that there aren't plenty of other arguments to be made, but > dismissing it out of hands on the grounds of ludicrousness isn't one of > them. > > and this is the reason queue > length is used as a measure of congestion. And this is true for all > accepted queueing models. Do you have in mind some "quantum statistics" > for networks that we are all unaware of? Do those have some tunnel effects > that allow you to dream about high utilization AND short queues? Is there > some mathematics that can support your statements? > > Julo > > Julian Satran > IBM Research Lab. at Haifa > > > > Steven Low on 01/02/2001 10:23:33 > > Please respond to slow@caltech.edu > > To: Alhussein Abouzeid > cc: end2end-interest@postel.org, ecn-interest@research.att.com > Subject: Re: [e2e] [Fwd: RED-->ECN] > > > > > Hi Alhussein > > I should clarify what I meant by 'decoupling of congestion measure > from performance measure'. > > I want to distinguish between the > *measure* of congestion and the *feedback* of congestion. The > measure of congestion, vaguely, should track the number of users > or available capacity and this is the information to which users > react by adjusting their rates (windows). For example, DropTail > measures congestion by loss rate (i.e. congestion = high loss), > the original RED measures it by average queue > (ie. congestion = high queue). Alternatively, you can measure > it by a number you compute, e.g., based on queue length and rate, > as you suggested. Then, congestion can simply mean 'demand>supply', > but it is possible to update the congestion measure in a way that > drives the queue or loss to a very low value, and therefore, the > congestion measure can settle down to a high value, telling sources > to keep their rates low, while loss and delay are kept low. > This is the key benefit, which cannot be achieved without decoupling, > for otherwise congestion measure (in this case, loss or queue) must > be kept high to send the right signal to users (unless one adapts RED > parameters dynamically). This is the first type of decoupling. > > Note that even with the first type fo decoupling, > performance measures such as loss, queue, delay or rate, > are used to *update* the congestion measure, but the equilibrium > *value* of the congestion measure is determined "solely" (in an > idealized > world) by the network topology, number of users etc, not by the > flow control algorithm. > > Now, how is the congestion measure fed back? This can be done > implicitly through what can be observed at the source, e.g. loss > or delay. Or it can be done explicitly using ECN or management > packets. This is decoupling the *feedback* of congestion measure > from performance measure. > > By "decoupling", I always meant the first kind of decoupling, which > I think is more important in determining the equilibrium behavior > of congestion control. > > I agree with you completely that ECN helps in the second type of > decoupling, > but not the first type which has to do with the design of AQM (choice > of congestion measure and its update rule). In wireless environment, > however, > because of the two kinds of losses (congestion & random loss), the > second > type of decoupling becomes useful as well. > > Regarding your mice-elephant comment, mice invasion may indeed be a > problem. But that makes it all the more important that elephants are > controlled to leave queues empty (in the absence of mice), and this > seems > hard to do if congestion measure is coupled with performance measure - > empty queue then automatically invites elephants to raise their rates. > If empty queue does not mean "increase you rate", then elephants must > be fed back (through ECN or probabilistical dropping) other necessary > information to set their rates. > > Steven > > > Alhussein Abouzeid wrote: > > > > Hi Steven, > > > > I generally agree with your approach below but have three, also > > philosophical, comments that I'd like to share with you regarding the > > decoupling of congestion measures from performance measures. > > > > Clearly, decoupling these two measures may greatly help in the design of > > congestion control algorithms, since the congestion information becomes > > explicitly available (through say, ECN). However, even with > > the use of ECN, full decoupling is not possible. The reason is that ECN > > packets themselves might be lost if sudden congestion takes place. > > > > Another point is regarding your argument that controlling "elephants" > will > > result in low queue levels and hence "mice" will be able to run quickly > > through the network. While this argument seems quite sensible, at least > to > > me, it is problematic if you imagine the arrival of many such mice - say > a > > mice invasion. Will the ECN marking rate/scheme used for signaling the > > elephants be enough to pro-actively avoid congestion from this mice > > invasion? I think that, at least, this is an important part of the puzzle > > that should not be taken lightly. In other words, the so called > > *transient* effect due to the mice population has to be accommodated and > > handled as carefully as the elephants' *steady state* effect. > > > > Finally, I'd like to add one more point; that the same level of > > decoupling that you propose can still be achieved using AQM without ECN. > > In one context, RED can be viewed as a controller that estimates the > state > > and acts upon the estimate. The average queue size is taken as a measure > > of the state and the feedback signal is a function of the state > > estimate. However, the average queue size need not be the only measure of > > congestion. Indeed, some recent works suggested measuring the arrival > rate > > directly (using some filter to smooth out transients) and using this as > > the measure of congestion. In some sense, such schemes attempts to > achieve > > the rightful objective you mentioned; decide whether demand exceeds > > capacity. Both approaches (queue-based or rate-based) have some problems > > that are too involved to detail here. If the AQM router uses a > > rate-based measure of congestion and drops packets when > > demand exceeds capacity (according to some reasonable algorithm), then > > we effectively achieve the same level of decoupling, and also in this > > case, the (average) buffer level can be kept low. > > > > In summary, in my opinion, ECN is a much more decent way of informing the > > sources about congestion, instead of the "cruel" way of packet > > dropping. As mentioned by others, it also saves the efforts of all the > > routers (if any) that processed the packet before it was finally dropped > > somewhere along the path, and also the effort of the source in detecting > > the packet loss. It has other virtues along the same lines that I am not > > listing here. It can be used to distinguish between congestion-related > > and non congestion-related losses only to some degree of reliability. > > Other than that (which are by no means minor enhancements), I don't think > > ECN is *essential* for the decoupling between congestion control and > > performance measures (e.g. queuing delay). > > > > Just a few thoughts. Sincerely, > > > > -Alhussein. > > > > On Fri, 26 Jan 2001, Steven Low wrote: > > > > > > > > > From: Steven Low > > > > To: hari@lcs.mit.edu, slow@caltech.edu > > > > CC: cwcam@caltech.edu, ecn-interest@research.att.com, > end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, > wch@its.caltech.edu > > > > > > > > > > > > Hi Hari, > > > > > > > > I completely agree that there are unresolved issues with the > > > > third approach (drastically reduce buffer overslows so that > > > > losses become primarily due to wireless effects), and you > > > > nicely touch upon several of them. But I'd like to make two > > > > philosophical points about ECN & congestion control first > > > > (which I hope belongs to this list at least peripherally). > > > > > > > > I think the approach of > > > > congesting the network in order to obtain congestion information > > > > as the current TCP does, which is necessary without ECN, > > > > becomes unnecessary with ECN. With AQM, we can decouple > > > > congestion measure & feedback from performance measure such > > > > as loss, delay or queue length. Then, 'congestion' > > > > means 'demand exceeds supply' and congestion signal curbs demands > > > > but the queue can be controlled in a way that maintains good > > > > performance such as low loss & delay. Whether REM can succeed > > > > doing this is a separate matter, but I think this is the approach > > > > we ought to take in designing our congestion control. > Alternatively, > > > > when we couple congestion measure with performance measure, > > > > 'congestion' necessarily means 'bad performance' such as high > > > > loss or delay, and we do not have the *option* (even if we have > > > > the means) of maintaing low loss & delay in times > > > > of congestion (i.e. when new sources joining or capacity drops). > > > > In other words, when there are more sources, loss or delay must be > > > > increased in order to produce high enough signal intensity for > > > > sources to futher cut back their rates; moreover signal intensity > > > > must stay high not only during transient > > > > when new soruces first start but also afterwards. > > > > > > > > REM tries to fix this, not through the exponential form of its > > > > marking probabiltiy function, but by using a different congestion > > > > measure and update rule, that maintains high utilization and low > > > > queue in equilibrium. Again, there can be alternative ways to > > > > achieving this, but I think this is what we should aim for. > > > > And to achieve this it is critical that we decouple congestion > > > > measure from performance measure. > > > > > > > > The second philosophical point is an interesting implication > > > > of the recent extensive works on heavy-tailed traffics and their > > > > origin. It implies that the misc-elephant mix (i.e. > > > > most files are small but most packets belong to long files) > > > > that characterizes current traffics may be a permanent and > > > > essential feature, not an artifice of current applications or > > > > user behavior. The end-to-end congestion control, properly > > > > designed, can be an ideal mechanism in such an environment, > > > > where elephants (that care about bandwidth) > > > > are controlled to maximally utilize the network > > > > in such a way that leaves the queues close to empty, so that > > > > mice (that are delay sensitive) can fly through the network > > > > with little delay. Again, this require a new TCP/AQM strategy > > > > that achieves high utilization + low queue, and ECN (or > > > > explicit notification) helps. > > > > > > > > A common objection to end-to-end congestion control is that > > > > most TCP connections are short and hence end-to-end congestion > > > > control is ineffective. I believe the observation is correct > > > > but not the conclusion. Since HTTP uses TCP and web files > > > > have mice-elephant mix, most TCP connections are therefore mice, > > > > which indeed should not be the primary object for end to end > > > > control. End to end control should target elephants, not mice. > > > > Mice suffer large delay currently, not because they are end to > > > > end controlled, but because the current congestion control (even > > > > just of elephants) can produce large queues in the path of mice. > > > > > > > > So, with the a TCP/AQM strategy that maintains high utilization > > > > and low queue in equilibrium (regardless of hte number of sources), > > > > buffer is used *only* to absorb *transient* bursts. This can be > > > > very different with a scheme that uses, say, queue length to > > > > measure congestion; with such a scheme, we do not have control > > > > on the equilibrium value of the queue - it is determined solely by > > > > the network topology and #sources and hence can be high depending > > > > on scenario. When queues are always high, they do not have > > > > reserve to handle burst. But when queues are always low, I > > > > think bursts can be much better handled. > > > > > > > > So much for such vague philosophical discussions. Since this > > > > is getting too long, I'd defer discussion on the unresolved > > > > issues with the third approach to some other time (except to > > > > point out that one big challenge is the heterogeneity of > > > > routers during transition when some routers mark packets > > > > and some drop packets to indicate congestion). Btw, I don't > > > > think the three approaches are mutually exclusive and can't > > > > complement each other. > > > > > > > > Steven > > > > > > > > ____________________________________________________________ > > > > Steven Low, Assoc Prof of CS and EE > > > > Caltech, Pasadena, CA91125 > > > > Tel: +1 626 395 6767 Fax: +1 626 792 4257 > > > > slow@caltech.edu > > > > netlab.caltech.edu > > > > > > > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 2001 > > > > >Delivered-To: ecn-interest@research.att.com > > > > >X-url: http://nms.lcs.mit.edu/~hari/ > > > > >To: slow@caltech.edu > > > > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, > wch@its.caltech.edu, > > > > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu > > > > >Subject: Re: RED-->ECN > > > > >Mime-Version: 1.0 > > > > >Date: Fri, 26 Jan 2001 15:56:20 -0500 > > > > >From: Hari Balakrishnan > > > > > > > > > > > > > > >Steven, > > > > > > > > > >REM is an interesting idea for using ECN, and I rather like it from > a research > > > > >standpoint because it doesn't have discontinuities (cf. RED) that > make analysis > > > > >harder. However, I'm generally skeptical that any scheme can be > shown to > > > > >eliminate essentially all buffer overflow losses under _all_ > conditions > > > > >(offered load), and yet accommodate bursts and provide reasonably > low delays... > > > > > especially when not all offered traffic is reacting or reacting in > different > > > > >ways from multiplicative-decrease. Even a small fraction of > unresponsive > > > > >traffic may make life problematic. > > > > > > > > > >Some years ago, I found it pretty hard to tune RED for this, to > enhance my ELN > > > > >scheme. REM may be more promising, but my gut feeling (as a network > engineer) > > > > >tells me that it wouldn't be prudent to such implicit deductions > about loss > > > > >causes in practice... > > > > > > > > > >Hari > > > > > > > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: > > > > > > > > > >> [Sorry for the previous broken msg...] > > > > >> > > > > >> Hi Saverio, > > > > >> > > > > >> Another point I'd like to add is that the addition of ECN > > > > >> may open up new opportunities for network control, some of > > > > >> which we may not even envision now. Without ECN we are > > > > >> stuck with using loss (or delay) as the only means to > > > > >> communicate between network and TCP sources. > > > > >> Let me give an example. > > > > >> > > > > >> There are two types of losses in wireless environment: > > > > >> 1. due to congestion (e.g. buffer overflow), and > > > > >> 2. due to wireles effect (handoffs, fast fading, interference > etc). > > > > >> One problem with TCP over wireless links is that TCP cannot > > > > >> differentiate > > > > >> between the two and essentially assume all losses are due to > > > > >> congestion and reduce its rate. Most of the current proposed > > > > >> solutions are based on two ideas. > > > > >> > > > > >> The first idiea is to hide type 1 (wireless) losses from TCP > source, > > > > >> so it sees only congestion losses and react properly. Examples > > > > >> are various local recovery schemes, snoop, split TCP etc. > > > > >> The first idea is to inform the TCP source which of the two > > > > >> types a loss belongs, so that TCP can react properly; e.g. ELN > schemes. > > > > >> > > > > >> Availability of ECN allows a third approach: to eliminate type 2 > > > > >> (congestion) losses, so that TCP source only sees wireless losses > > > > >> and therefore know how to react. But we still need to measure > and > > > > >> feedback 'congestion' so that sources know to reduce their rates > > > > >> when new sources join or capacity drops. By 'congestion', I > don't > > > > >> mean 'high loss', but simply 'demand exceeds supply' so everyone > > > > >> should reduce their demand. Since buffer overflow is now > eliminated > > > > >> (assume we can do this, see below), we need a different mechanism > to > > > > >> measure and to feedback this 'congestion' information. Here is > > > > >> where ECN comes in. When we decouple the measure+feedback of > > > > >> congestion from loss, we must have ECN to provide the feedback. > > > > >> > > > > >> Now, can we possibly keep the queue small (greatly reduce buffer > > > > >> overflow) *yet highly utilized*? Recent research works seem to > > > > >> provide > > > > >> reasons to be optimistic. One example is in our paper: > > > > >> REM: Active Queue Management > > > > >> on our website: > > > > >> netlab.caltech.edu > > > > >> > > > > >> Steven > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 > > > > >> >From: "K. K. Ramakrishnan" > > > > >> >To: Saverio Mascolo > > > > >> >Cc: ecn-interest@research.att.com > > > > >> > > > > > >> >Saverio, > > > > >> >I am glad you see ECN as an evolution from RED. > > > > >> >This is our motivation also: > > > > >> >to have ECN incorporated and deployed with an > > > > >> >Active Queue Management scheme. > > > > >> > > > > > >> >However, it is difficult to agree with the other observations you > make: > > > > >> >if congestion was only caused by "one packet" as you say, then > > > > >> >one might wonder why we need to actually do a whole lot to > > > > >> >one might wonder why we need to actually do a whole lot to > > > > >> >either react to or avoid congestion. Unfortunately, that isn't > the case. > > > > >> > > > > > >> >If you look at a congestion epoch, there are likely to be > multiple > > > > >> >packets, > > > > >> >potentially from multiple flows, that are impacted: > > > > >> >either being marked or dropped. > > > > >> >ECN helps substantially in not dropping packet*s* - and > especially > > > > >> >when the window size for those flows that have their packets > > > > >> >marked, it helps by not having them suffer a time-out. > > > > >> > > > > > >> >Further: the amount of complexity in either the router > (especially > > > > >> >in the router) or the end-system is not significant. I know that > > > > >> >may be a matter of opinion. > > > > >> >But in a router, the change is so minimal, I haven't heard anyone > > > > >> >complain of complexity of implementation. > > > > >> > > > > > >> >There is no violation of layering, at all. I don't see why you > say so. > > > > >> > > > > > >> > K. K. Ramakrishnan > > > > >> >Saverio Mascolo wrote: > > > > >> > > > > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN saves > one > > > > >> >> packet, which is the packet that > > > > >> >> RED would drop to signal congestion, by setting a bit in the > header. > > > > >> >> Thus, to save just > > > > >> >> ONE PACKET, ECN introduces complexity in routers, in the > > > > >> >> protocol, violation of layering, etc...For these reasons I > don't think > > > > >> >> that ECN would give an improvement to RED that is commensurate > to its > > > > >> >> complexity.Is there any point that I miss? Saverio > > > > >> >> > > > > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html > > > > > > -- > > > __________________________________________________________________ > > > Steven Low, Assoc Prof of CS & EE > > > slow@caltech.edu netlab.caltech.edu > > > Tel: (626) 395-6767 Caltech MC256-80 > > > Fax: (626) 792-4257 Pasadena CA 91125 > > > _______________________________________________ > > > end2end-interest mailing list > > > end2end-interest@postel.org > > > http://www.postel.org/mailman/listinfo/end2end-interest > > > > > -- > __________________________________________________________________ > Steven Low, Assoc Prof of CS & EE > slow@caltech.edu netlab.caltech.edu > Tel: (626) 395-6767 Caltech MC256-80 > Fax: (626) 792-4257 Pasadena CA 91125 > > > > From J.Crowcroft@cs.ucl.ac.uk Thu Feb 1 08:40:28 2001 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id IAA04873 for ; Thu, 1 Feb 2001 08:40:26 -0800 (PST) Received: from baby.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Feb 2001 16:40:02 +0000 To: end2end-interest , ecn-interest , J.Crowcroft@cs.ucl.ac.uk Subject: Re: R: [e2e] [Fwd: RED-->ECN] In-reply-to: Your message of "Thu, 01 Feb 2001 17:23:09 +0100." <008c01c08c6b$4655eec0$723bccc1@poliba.it> Date: Thu, 01 Feb 2001 16:39:56 +0000 Message-ID: <1422.981045596@cs.ucl.ac.uk> From: Jon Crowcroft Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 44 In message <008c01c08c6b$4655eec0$723bccc1@poliba.it>, Saverio Mascolo typed: >>I would introduce another element of discussion...Explicit congestion >>indication was proposed in the ATM community...after a while they concluded >>that it was necessary a richer feedback in order to obtain an effective >>"regularization" of queue dynamics, utilization etc...thus it was proposed >>explicit rate indication such ERICA algorithm. the difference between explicit rate feedback and binary feedback can be overstated - 1/the bit can be set for a number of flows - if the number of flows is large, and they respond corectly then the effect can be nearly the same as setting the "right" explicit rate per flow 2/ the rate of change of flows per "rtt" might be such that telling someone the "right" explicit rate half an rtt ago maybe no better and might be worse than binary feedback per flow. in some of the discussion below, the distinction between the reason for drop tail (demand >= supply) and RED+ECN (demand is _approaching_ supply and AQM triggers set) is correctly made - the AQM mechanism can take into account a lot of other factors (number of current flows, rate of change of number of flows, even relative RTT of flows (hard to measure though, esp. in today's assymetric routed interdomain path internet:-)) by the way, the idea of a "quantum mechanics" of queues had occurred to me - not to "perform magic" like quantum tunneling, but the use of quantum statistics to model the population of queues for very large systems might not be so far fetched..(yes, i know there are a few orders of magnitude of orders of magnitude difference in scale, but its still fun to think of) >>> Thu, 1 Feb 2001 13:21:27 +0200 >>> julian_satran@il.ibm.com >>> >>> I would be very interested to understand how you see the >>"virtual-measure", >>> you are suggesting exists, relate to accepted theory. It is usually >>> though that high utilization rates and long queues are related (i.e., >>you >>> have long queues when utilization goes up) >>> >>> A quibble: Queue length is a function of variance (burstiness), not (just) >>> of arrival rate. If the input rate exceeds the output rate, queue length >>> *becomes* unbounded ("infinite"). If the input rate is less than the >>> output rate, then (independent of variations in inter-arrival time) the >>> queue length is 0 -- always empty. For an arbitrarily low *average* input >>> rate, and a long enough interval, and an unbounded queue, I can construct >>> an arrival schedule that will cause an arbitrarily high *average* queue >>> length. >>> >>> However, what you say is _basically_ true in the real world because as the >>> input rate approaches the output rate the queue length becomes much more >>> sensitive to smaller and smaller variations (not to mention that max queue >>> length *is* bounded), so queue length in practice is probably usually a >>> reasonable indicator of load. The control needed to smooth flows as >>> arrival rates get higher is likely to be fragile, and is probably >>> inconsistent with the philosophy of most people on end2end. But Steven >>> Low's statements are not immediately dismissable as being totally >>> self-contradictory, or in the category of perpetual motion machines. >>> Not to say that there aren't plenty of other arguments to be made, but >>> dismissing it out of hands on the grounds of ludicrousness isn't one of >>> them. >>> >>> and this is the reason queue >>> length is used as a measure of congestion. And this is true for all >>> accepted queueing models. Do you have in mind some "quantum >>statistics" >>> for networks that we are all unaware of? Do those have some tunnel >>effects >>> that allow you to dream about high utilization AND short queues? Is >>there >>> some mathematics that can support your statements? >>> >>> Julo >>> >>> Julian Satran >>> IBM Research Lab. at Haifa >>> >>> >>> >>> Steven Low on 01/02/2001 10:23:33 >>> >>> Please respond to slow@caltech.edu >>> >>> To: Alhussein Abouzeid >>> cc: end2end-interest@postel.org, ecn-interest@research.att.com >>> Subject: Re: [e2e] [Fwd: RED-->ECN] >>> >>> >>> >>> >>> Hi Alhussein >>> >>> I should clarify what I meant by 'decoupling of congestion measure >>> from performance measure'. >>> >>> I want to distinguish between the >>> *measure* of congestion and the *feedback* of congestion. The >>> measure of congestion, vaguely, should track the number of users >>> or available capacity and this is the information to which users >>> react by adjusting their rates (windows). For example, DropTail >>> measures congestion by loss rate (i.e. congestion = high loss), >>> the original RED measures it by average queue >>> (ie. congestion = high queue). Alternatively, you can measure >>> it by a number you compute, e.g., based on queue length and rate, >>> as you suggested. Then, congestion can simply mean 'demand>supply', >>> but it is possible to update the congestion measure in a way that >>> drives the queue or loss to a very low value, and therefore, the >>> congestion measure can settle down to a high value, telling sources >>> to keep their rates low, while loss and delay are kept low. >>> This is the key benefit, which cannot be achieved without decoupling, >>> for otherwise congestion measure (in this case, loss or queue) must >>> be kept high to send the right signal to users (unless one adapts RED >>> parameters dynamically). This is the first type of decoupling. >>> >>> Note that even with the first type fo decoupling, >>> performance measures such as loss, queue, delay or rate, >>> are used to *update* the congestion measure, but the equilibrium >>> *value* of the congestion measure is determined "solely" (in an >>> idealized >>> world) by the network topology, number of users etc, not by the >>> flow control algorithm. >>> >>> Now, how is the congestion measure fed back? This can be done >>> implicitly through what can be observed at the source, e.g. loss >>> or delay. Or it can be done explicitly using ECN or management >>> packets. This is decoupling the *feedback* of congestion measure >>> from performance measure. >>> >>> By "decoupling", I always meant the first kind of decoupling, which >>> I think is more important in determining the equilibrium behavior >>> of congestion control. >>> >>> I agree with you completely that ECN helps in the second type of >>> decoupling, >>> but not the first type which has to do with the design of AQM (choice >>> of congestion measure and its update rule). In wireless environment, >>> however, >>> because of the two kinds of losses (congestion & random loss), the >>> second >>> type of decoupling becomes useful as well. >>> >>> Regarding your mice-elephant comment, mice invasion may indeed be a >>> problem. But that makes it all the more important that elephants are >>> controlled to leave queues empty (in the absence of mice), and this >>> seems >>> hard to do if congestion measure is coupled with performance measure - >>> empty queue then automatically invites elephants to raise their rates. >>> If empty queue does not mean "increase you rate", then elephants must >>> be fed back (through ECN or probabilistical dropping) other necessary >>> information to set their rates. >>> >>> Steven >>> >>> >>> Alhussein Abouzeid wrote: >>> > >>> > Hi Steven, >>> > >>> > I generally agree with your approach below but have three, also >>> > philosophical, comments that I'd like to share with you regarding the >>> > decoupling of congestion measures from performance measures. >>> > >>> > Clearly, decoupling these two measures may greatly help in the design >>of >>> > congestion control algorithms, since the congestion information >>becomes >>> > explicitly available (through say, ECN). However, even with >>> > the use of ECN, full decoupling is not possible. The reason is that >>ECN >>> > packets themselves might be lost if sudden congestion takes place. >>> > >>> > Another point is regarding your argument that controlling "elephants" >>> will >>> > result in low queue levels and hence "mice" will be able to run >>quickly >>> > through the network. While this argument seems quite sensible, at >>least >>> to >>> > me, it is problematic if you imagine the arrival of many such mice - >>say >>> a >>> > mice invasion. Will the ECN marking rate/scheme used for signaling >>the >>> > elephants be enough to pro-actively avoid congestion from this mice >>> > invasion? I think that, at least, this is an important part of the >>puzzle >>> > that should not be taken lightly. In other words, the so called >>> > *transient* effect due to the mice population has to be accommodated >>and >>> > handled as carefully as the elephants' *steady state* effect. >>> > >>> > Finally, I'd like to add one more point; that the same level of >>> > decoupling that you propose can still be achieved using AQM without >>ECN. >>> > In one context, RED can be viewed as a controller that estimates the >>> state >>> > and acts upon the estimate. The average queue size is taken as a >>measure >>> > of the state and the feedback signal is a function of the state >>> > estimate. However, the average queue size need not be the only >>measure of >>> > congestion. Indeed, some recent works suggested measuring the arrival >>> rate >>> > directly (using some filter to smooth out transients) and using this >>as >>> > the measure of congestion. In some sense, such schemes attempts to >>> achieve >>> > the rightful objective you mentioned; decide whether demand exceeds >>> > capacity. Both approaches (queue-based or rate-based) have some >>problems >>> > that are too involved to detail here. If the AQM router uses a >>> > rate-based measure of congestion and drops packets when >>> > demand exceeds capacity (according to some reasonable algorithm), >>then >>> > we effectively achieve the same level of decoupling, and also in this >>> > case, the (average) buffer level can be kept low. >>> > >>> > In summary, in my opinion, ECN is a much more decent way of informing >>the >>> > sources about congestion, instead of the "cruel" way of packet >>> > dropping. As mentioned by others, it also saves the efforts of all >>the >>> > routers (if any) that processed the packet before it was finally >>dropped >>> > somewhere along the path, and also the effort of the source in >>detecting >>> > the packet loss. It has other virtues along the same lines that I am >>not >>> > listing here. It can be used to distinguish between >>congestion-related >>> > and non congestion-related losses only to some degree of reliability. >>> > Other than that (which are by no means minor enhancements), I don't >>think >>> > ECN is *essential* for the decoupling between congestion control and >>> > performance measures (e.g. queuing delay). >>> > >>> > Just a few thoughts. Sincerely, >>> > >>> > -Alhussein. >>> > >>> > On Fri, 26 Jan 2001, Steven Low wrote: >>> > >>> > > >>> > > > From: Steven Low >>> > > > To: hari@lcs.mit.edu, slow@caltech.edu >>> > > > CC: cwcam@caltech.edu, ecn-interest@research.att.com, >>> end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, >>> wch@its.caltech.edu >>> > > > >>> > > > >>> > > > Hi Hari, >>> > > > >>> > > > I completely agree that there are unresolved issues with the >>> > > > third approach (drastically reduce buffer overslows so that >>> > > > losses become primarily due to wireless effects), and you >>> > > > nicely touch upon several of them. But I'd like to make two >>> > > > philosophical points about ECN & congestion control first >>> > > > (which I hope belongs to this list at least peripherally). >>> > > > >>> > > > I think the approach of >>> > > > congesting the network in order to obtain congestion information >>> > > > as the current TCP does, which is necessary without ECN, >>> > > > becomes unnecessary with ECN. With AQM, we can decouple >>> > > > congestion measure & feedback from performance measure such >>> > > > as loss, delay or queue length. Then, 'congestion' >>> > > > means 'demand exceeds supply' and congestion signal curbs demands >>> > > > but the queue can be controlled in a way that maintains good >>> > > > performance such as low loss & delay. Whether REM can succeed >>> > > > doing this is a separate matter, but I think this is the approach >>> > > > we ought to take in designing our congestion control. >>> Alternatively, >>> > > > when we couple congestion measure with performance measure, >>> > > > 'congestion' necessarily means 'bad performance' such as high >>> > > > loss or delay, and we do not have the *option* (even if we have >>> > > > the means) of maintaing low loss & delay in times >>> > > > of congestion (i.e. when new sources joining or capacity drops). >>> > > > In other words, when there are more sources, loss or delay must >>be >>> > > > increased in order to produce high enough signal intensity for >>> > > > sources to futher cut back their rates; moreover signal intensity >>> > > > must stay high not only during transient >>> > > > when new soruces first start but also afterwards. >>> > > > >>> > > > REM tries to fix this, not through the exponential form of its >>> > > > marking probabiltiy function, but by using a different congestion >>> > > > measure and update rule, that maintains high utilization and low >>> > > > queue in equilibrium. Again, there can be alternative ways to >>> > > > achieving this, but I think this is what we should aim for. >>> > > > And to achieve this it is critical that we decouple congestion >>> > > > measure from performance measure. >>> > > > >>> > > > The second philosophical point is an interesting implication >>> > > > of the recent extensive works on heavy-tailed traffics and their >>> > > > origin. It implies that the misc-elephant mix (i.e. >>> > > > most files are small but most packets belong to long files) >>> > > > that characterizes current traffics may be a permanent and >>> > > > essential feature, not an artifice of current applications or >>> > > > user behavior. The end-to-end congestion control, properly >>> > > > designed, can be an ideal mechanism in such an environment, >>> > > > where elephants (that care about bandwidth) >>> > > > are controlled to maximally utilize the network >>> > > > in such a way that leaves the queues close to empty, so that >>> > > > mice (that are delay sensitive) can fly through the network >>> > > > with little delay. Again, this require a new TCP/AQM strategy >>> > > > that achieves high utilization + low queue, and ECN (or >>> > > > explicit notification) helps. >>> > > > >>> > > > A common objection to end-to-end congestion control is that >>> > > > most TCP connections are short and hence end-to-end congestion >>> > > > control is ineffective. I believe the observation is correct >>> > > > but not the conclusion. Since HTTP uses TCP and web files >>> > > > have mice-elephant mix, most TCP connections are therefore mice, >>> > > > which indeed should not be the primary object for end to end >>> > > > control. End to end control should target elephants, not mice. >>> > > > Mice suffer large delay currently, not because they are end to >>> > > > end controlled, but because the current congestion control (even >>> > > > just of elephants) can produce large queues in the path of mice. >>> > > > >>> > > > So, with the a TCP/AQM strategy that maintains high utilization >>> > > > and low queue in equilibrium (regardless of hte number of >>sources), >>> > > > buffer is used *only* to absorb *transient* bursts. This can be >>> > > > very different with a scheme that uses, say, queue length to >>> > > > measure congestion; with such a scheme, we do not have control > > > > on the equilibrium value of the queue - it is determined solely >>by >>> > > > the network topology and #sources and hence can be high depending >>> > > > on scenario. When queues are always high, they do not have >>> > > > reserve to handle burst. But when queues are always low, I >>> > > > think bursts can be much better handled. >>> > > > >>> > > > So much for such vague philosophical discussions. Since this >>> > > > is getting too long, I'd defer discussion on the unresolved >>> > > > issues with the third approach to some other time (except to >>> > > > point out that one big challenge is the heterogeneity of >>> > > > routers during transition when some routers mark packets >>> > > > and some drop packets to indicate congestion). Btw, I don't >>> > > > think the three approaches are mutually exclusive and can't >>> > > > complement each other. >>> > > > >>> > > > Steven >>> > > > >>> > > > ____________________________________________________________ >>> > > > Steven Low, Assoc Prof of CS and EE >>> > > > Caltech, Pasadena, CA91125 >>> > > > Tel: +1 626 395 6767 Fax: +1 626 792 4257 >>> > > > slow@caltech.edu >>> > > > netlab.caltech.edu >>> > > > >>> > > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 >>2001 >>> > > > >Delivered-To: ecn-interest@research.att.com >>> > > > >X-url: http://nms.lcs.mit.edu/~hari/ >>> > > > >To: slow@caltech.edu >>> > > > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, >>> wch@its.caltech.edu, >>> > > > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu >>> > > > >Subject: Re: RED-->ECN >>> > > > >Mime-Version: 1.0 >>> > > > >Date: Fri, 26 Jan 2001 15:56:20 -0500 >>> > > > >From: Hari Balakrishnan >>> > > > > >>> > > > > >>> > > > >Steven, >>> > > > > >>> > > > >REM is an interesting idea for using ECN, and I rather like it >>from >>> a research >>> > > > >standpoint because it doesn't have discontinuities (cf. RED) >>that >>> make analysis >>> > > > >harder. However, I'm generally skeptical that any scheme can be >>> shown to >>> > > > >eliminate essentially all buffer overflow losses under _all_ >>> conditions >>> > > > >(offered load), and yet accommodate bursts and provide >>reasonably >>> low delays... >>> > > > > especially when not all offered traffic is reacting or reacting >>in >>> different >>> > > > >ways from multiplicative-decrease. Even a small fraction of >>> unresponsive >>> > > > >traffic may make life problematic. >>> > > > > >>> > > > >Some years ago, I found it pretty hard to tune RED for this, to >>> enhance my ELN >>> > > > >scheme. REM may be more promising, but my gut feeling (as a >>network >>> engineer) >>> > > > >tells me that it wouldn't be prudent to such implicit deductions >>> about loss >>> > > > >causes in practice... >>> > > > > >>> > > > >Hari >>> > > > > >>> > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: >>> > > > > >>> > > > >> [Sorry for the previous broken msg...] >>> > > > >> >>> > > > >> Hi Saverio, >>> > > > >> >>> > > > >> Another point I'd like to add is that the addition of ECN >>> > > > >> may open up new opportunities for network control, some of >>> > > > >> which we may not even envision now. Without ECN we are >>> > > > >> stuck with using loss (or delay) as the only means to >>> > > > >> communicate between network and TCP sources. >>> > > > >> Let me give an example. >>> > > > >> >>> > > > >> There are two types of losses in wireless environment: >>> > > > >> 1. due to congestion (e.g. buffer overflow), and >>> > > > >> 2. due to wireles effect (handoffs, fast fading, interference >>> etc). >>> > > > >> One problem with TCP over wireless links is that TCP cannot >>> > > > >> differentiate >>> > > > >> between the two and essentially assume all losses are due to >>> > > > >> congestion and reduce its rate. Most of the current proposed >>> > > > >> solutions are based on two ideas. >>> > > > >> >>> > > > >> The first idiea is to hide type 1 (wireless) losses from TCP >>> source, >>> > > > >> so it sees only congestion losses and react properly. >>Examples >>> > > > >> are various local recovery schemes, snoop, split TCP etc. >>> > > > >> The first idea is to inform the TCP source which of the two >>> > > > >> types a loss belongs, so that TCP can react properly; e.g. ELN >>> schemes. >>> > > > >> >>> > > > >> Availability of ECN allows a third approach: to eliminate type >>2 >>> > > > >> (congestion) losses, so that TCP source only sees wireless >>losses >>> > > > >> and therefore know how to react. But we still need to >>measure >>> and >>> > > > >> feedback 'congestion' so that sources know to reduce their >>rates >>> > > > >> when new sources join or capacity drops. By 'congestion', I >>> don't >>> > > > >> mean 'high loss', but simply 'demand exceeds supply' so >>everyone >>> > > > >> should reduce their demand. Since buffer overflow is now >>> eliminated >>> > > > >> (assume we can do this, see below), we need a different >>mechanism >>> to >>> > > > >> measure and to feedback this 'congestion' information. Here >>is >>> > > > >> where ECN comes in. When we decouple the measure+feedback of >>> > > > >> congestion from loss, we must have ECN to provide the >>feedback. >>> > > > >> >>> > > > >> Now, can we possibly keep the queue small (greatly reduce >>buffer >>> > > > >> overflow) *yet highly utilized*? Recent research works seem >>to >>> > > > >> provide >>> > > > >> reasons to be optimistic. One example is in our paper: >>> > > > >> REM: Active Queue Management >>> > > > >> on our website: >>> > > > >> netlab.caltech.edu >>> > > > >> >>> > > > >> Steven >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 >>> > > > >> >From: "K. K. Ramakrishnan" >>> > > > >> >To: Saverio Mascolo >>> > > > >> >Cc: ecn-interest@research.att.com >>> > > > >> > >>> > > > >> >Saverio, >>> > > > >> >I am glad you see ECN as an evolution from RED. >>> > > > >> >This is our motivation also: >>> > > > >> >to have ECN incorporated and deployed with an >>> > > > >> >Active Queue Management scheme. >>> > > > >> > >>> > > > >> >However, it is difficult to agree with the other observations >>you >>> make: >>> > > > >> >if congestion was only caused by "one packet" as you say, >>then >>> > > > >> >one might wonder why we need to actually do a whole lot to >>> > > > >> >one might wonder why we need to actually do a whole lot to >>> > > > >> >either react to or avoid congestion. Unfortunately, that >>isn't >>> the case. >>> > > > >> > >>> > > > >> >If you look at a congestion epoch, there are likely to be >>> multiple >>> > > > >> >packets, >>> > > > >> >potentially from multiple flows, that are impacted: >>> > > > >> >either being marked or dropped. >>> > > > >> >ECN helps substantially in not dropping packet*s* - and >>> especially >>> > > > >> >when the window size for those flows that have their packets >>> > > > >> >marked, it helps by not having them suffer a time-out. >>> > > > >> > >>> > > > >> >Further: the amount of complexity in either the router >>> (especially >>> > > > >> >in the router) or the end-system is not significant. I know >>that >>> > > > >> >may be a matter of opinion. >>> > > > >> >But in a router, the change is so minimal, I haven't heard >>anyone >>> > > > >> >complain of complexity of implementation. >>> > > > >> > >>> > > > >> >There is no violation of layering, at all. I don't see why >>you >>> say so. >>> > > > >> > >>> > > > >> > K. K. Ramakrishnan >>> > > > >> >Saverio Mascolo wrote: >>> > > > >> > >>> > > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN >>saves >>> one >>> > > > >> >> packet, which is the packet that >>> > > > >> >> RED would drop to signal congestion, by setting a bit in >>the >>> header. >>> > > > >> >> Thus, to save just >>> > > > >> >> ONE PACKET, ECN introduces complexity in routers, in the >>> > > > >> >> protocol, violation of layering, etc...For these reasons I >>> don't think >>> > > > >> >> that ECN would give an improvement to RED that is >>commensurate >>> to its >>> > > > >> >> complexity.Is there any point that I miss? Saverio >>> > > > >> >> >>> > > > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html >>> > > >>> > > -- >>> > > __________________________________________________________________ >>> > > Steven Low, Assoc Prof of CS & EE >>> > > slow@caltech.edu netlab.caltech.edu >>> > > Tel: (626) 395-6767 Caltech MC256-80 >>> > > Fax: (626) 792-4257 Pasadena CA 91125 >>> > > _______________________________________________ >>> > > end2end-interest mailing list >>> > > end2end-interest@postel.org >>> > > http://www.postel.org/mailman/listinfo/end2end-interest >>> > > >>> >>> -- >>> __________________________________________________________________ >>> Steven Low, Assoc Prof of CS & EE >>> slow@caltech.edu netlab.caltech.edu >>> Tel: (626) 395-6767 Caltech MC256-80 >>> Fax: (626) 792-4257 Pasadena CA 91125 >>> >>> >>> >>> >> cheers jon From mascolo@poliba.it Thu Feb 1 09:12:01 2001 Received: from cstar.poliba.it (IDENT:root@cstar.poliba.it [193.204.49.36]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA08733 for ; Thu, 1 Feb 2001 09:11:59 -0800 (PST) Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by cstar.poliba.it (8.11.0/8.11.0) with SMTP id f11H6Oh00985; Thu, 1 Feb 2001 18:08:54 +0100 Message-ID: <013701c08c71$bbcf6c20$723bccc1@poliba.it> From: "Saverio Mascolo" To: "end2end-interest" , "ecn-interest" References: <1422.981045596@cs.ucl.ac.uk> Subject: R: R: [e2e] [Fwd: RED-->ECN] Date: Thu, 1 Feb 2001 18:06:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 45 Could someone point me to some paper comparing ECN to RED? Thanks Saverio ----- Original Message ----- From: Jon Crowcroft To: end2end-interest ; ecn-interest ; Sent: Thursday, February 01, 2001 5:39 PM Subject: Re: R: [e2e] [Fwd: RED-->ECN] > > In message <008c01c08c6b$4655eec0$723bccc1@poliba.it>, Saverio Mascolo typed: > > >>I would introduce another element of discussion...Explicit congestion > >>indication was proposed in the ATM community...after a while they concluded > >>that it was necessary a richer feedback in order to obtain an effective > >>"regularization" of queue dynamics, utilization etc...thus it was proposed > >>explicit rate indication such ERICA algorithm. > > the difference between explicit rate feedback and binary feedback can > be overstated - > 1/the bit can be set for a number of flows - if the number of flows is > large, and they respond corectly then the effect can be nearly the same > as setting the "right" explicit rate per flow > > 2/ the rate of change of flows per "rtt" might be such that telling > someone the "right" explicit rate half an rtt ago maybe no better and > might be worse than binary feedback per flow. > > in some of the discussion below, the distinction between the reason > for drop tail (demand >= supply) and RED+ECN (demand is _approaching_ supply > and AQM triggers set) is correctly made - the AQM mechanism can take > into account a lot of other factors (number of current flows, rate of > change of number of flows, even relative RTT of flows (hard to measure > though, esp. in today's assymetric routed interdomain path internet:-)) > > by the way, the idea of a "quantum mechanics" of queues had occurred > to me - not to "perform magic" like quantum tunneling, but the use of > quantum statistics to model the population of queues for very large > systems might not be so far fetched..(yes, i know there are a few > orders of magnitude of orders of magnitude difference in scale, but > its still fun to think of) > > >>> Thu, 1 Feb 2001 13:21:27 +0200 > >>> julian_satran@il.ibm.com > >>> > >>> I would be very interested to understand how you see the > >>"virtual-measure", > >>> you are suggesting exists, relate to accepted theory. It is usually > >>> though that high utilization rates and long queues are related (i.e., > >>you > >>> have long queues when utilization goes up) > >>> > >>> A quibble: Queue length is a function of variance (burstiness), not (just) > >>> of arrival rate. If the input rate exceeds the output rate, queue length > >>> *becomes* unbounded ("infinite"). If the input rate is less than the > >>> output rate, then (independent of variations in inter-arrival time) the > >>> queue length is 0 -- always empty. For an arbitrarily low *average* input > >>> rate, and a long enough interval, and an unbounded queue, I can construct > >>> an arrival schedule that will cause an arbitrarily high *average* queue > >>> length. > >>> > >>> However, what you say is _basically_ true in the real world because as the > >>> input rate approaches the output rate the queue length becomes much more > >>> sensitive to smaller and smaller variations (not to mention that max queue > >>> length *is* bounded), so queue length in practice is probably usually a > >>> reasonable indicator of load. The control needed to smooth flows as > >>> arrival rates get higher is likely to be fragile, and is probably > >>> inconsistent with the philosophy of most people on end2end. But Steven > >>> Low's statements are not immediately dismissable as being totally > >>> self-contradictory, or in the category of perpetual motion machines. > >>> Not to say that there aren't plenty of other arguments to be made, but > >>> dismissing it out of hands on the grounds of ludicrousness isn't one of > >>> them. > >>> > >>> and this is the reason queue > >>> length is used as a measure of congestion. And this is true for all > >>> accepted queueing models. Do you have in mind some "quantum > >>statistics" > >>> for networks that we are all unaware of? Do those have some tunnel > >>effects > >>> that allow you to dream about high utilization AND short queues? Is > >>there > >>> some mathematics that can support your statements? > >>> > >>> Julo > >>> > >>> Julian Satran > >>> IBM Research Lab. at Haifa > >>> > >>> > >>> > >>> Steven Low on 01/02/2001 10:23:33 > >>> > >>> Please respond to slow@caltech.edu > >>> > >>> To: Alhussein Abouzeid > >>> cc: end2end-interest@postel.org, ecn-interest@research.att.com > >>> Subject: Re: [e2e] [Fwd: RED-->ECN] > >>> > >>> > >>> > >>> > >>> Hi Alhussein > >>> > >>> I should clarify what I meant by 'decoupling of congestion measure > >>> from performance measure'. > >>> > >>> I want to distinguish between the > >>> *measure* of congestion and the *feedback* of congestion. The > >>> measure of congestion, vaguely, should track the number of users > >>> or available capacity and this is the information to which users > >>> react by adjusting their rates (windows). For example, DropTail > >>> measures congestion by loss rate (i.e. congestion = high loss), > >>> the original RED measures it by average queue > >>> (ie. congestion = high queue). Alternatively, you can measure > >>> it by a number you compute, e.g., based on queue length and rate, > >>> as you suggested. Then, congestion can simply mean 'demand>supply', > >>> but it is possible to update the congestion measure in a way that > >>> drives the queue or loss to a very low value, and therefore, the > >>> congestion measure can settle down to a high value, telling sources > >>> to keep their rates low, while loss and delay are kept low. > >>> This is the key benefit, which cannot be achieved without decoupling, > >>> for otherwise congestion measure (in this case, loss or queue) must > >>> be kept high to send the right signal to users (unless one adapts RED > >>> parameters dynamically). This is the first type of decoupling. > >>> > >>> Note that even with the first type fo decoupling, > >>> performance measures such as loss, queue, delay or rate, > >>> are used to *update* the congestion measure, but the equilibrium > >>> *value* of the congestion measure is determined "solely" (in an > >>> idealized > >>> world) by the network topology, number of users etc, not by the > >>> flow control algorithm. > >>> > >>> Now, how is the congestion measure fed back? This can be done > >>> implicitly through what can be observed at the source, e.g. loss > >>> or delay. Or it can be done explicitly using ECN or management > >>> packets. This is decoupling the *feedback* of congestion measure > >>> from performance measure. > >>> > >>> By "decoupling", I always meant the first kind of decoupling, which > >>> I think is more important in determining the equilibrium behavior > >>> of congestion control. > >>> > >>> I agree with you completely that ECN helps in the second type of > >>> decoupling, > >>> but not the first type which has to do with the design of AQM (choice > >>> of congestion measure and its update rule). In wireless environment, > >>> however, > >>> because of the two kinds of losses (congestion & random loss), the > >>> second > >>> type of decoupling becomes useful as well. > >>> > >>> Regarding your mice-elephant comment, mice invasion may indeed be a > >>> problem. But that makes it all the more important that elephants are > >>> controlled to leave queues empty (in the absence of mice), and this > >>> seems > >>> hard to do if congestion measure is coupled with performance measure - > >>> empty queue then automatically invites elephants to raise their rates. > >>> If empty queue does not mean "increase you rate", then elephants must > >>> be fed back (through ECN or probabilistical dropping) other necessary > >>> information to set their rates. > >>> > >>> Steven > >>> > >>> > >>> Alhussein Abouzeid wrote: > >>> > > >>> > Hi Steven, > >>> > > >>> > I generally agree with your approach below but have three, also > >>> > philosophical, comments that I'd like to share with you regarding the > >>> > decoupling of congestion measures from performance measures. > >>> > > >>> > Clearly, decoupling these two measures may greatly help in the design > >>of > >>> > congestion control algorithms, since the congestion information > >>becomes > >>> > explicitly available (through say, ECN). However, even with > >>> > the use of ECN, full decoupling is not possible. The reason is that > >>ECN > >>> > packets themselves might be lost if sudden congestion takes place. > >>> > > >>> > Another point is regarding your argument that controlling "elephants" > >>> will > >>> > result in low queue levels and hence "mice" will be able to run > >>quickly > >>> > through the network. While this argument seems quite sensible, at > >>least > >>> to > >>> > me, it is problematic if you imagine the arrival of many such mice - > >>say > >>> a > >>> > mice invasion. Will the ECN marking rate/scheme used for signaling > >>the > >>> > elephants be enough to pro-actively avoid congestion from this mice > >>> > invasion? I think that, at least, this is an important part of the > >>puzzle > >>> > that should not be taken lightly. In other words, the so called > >>> > *transient* effect due to the mice population has to be accommodated > >>and > >>> > handled as carefully as the elephants' *steady state* effect. > >>> > > >>> > Finally, I'd like to add one more point; that the same level of > >>> > decoupling that you propose can still be achieved using AQM without > >>ECN. > >>> > In one context, RED can be viewed as a controller that estimates the > >>> state > >>> > and acts upon the estimate. The average queue size is taken as a > >>measure > >>> > of the state and the feedback signal is a function of the state > >>> > estimate. However, the average queue size need not be the only > >>measure of > >>> > congestion. Indeed, some recent works suggested measuring the arrival > >>> rate > >>> > directly (using some filter to smooth out transients) and using this > >>as > >>> > the measure of congestion. In some sense, such schemes attempts to > >>> achieve > >>> > the rightful objective you mentioned; decide whether demand exceeds > >>> > capacity. Both approaches (queue-based or rate-based) have some > >>problems > >>> > that are too involved to detail here. If the AQM router uses a > >>> > rate-based measure of congestion and drops packets when > >>> > demand exceeds capacity (according to some reasonable algorithm), > >>then > >>> > we effectively achieve the same level of decoupling, and also in this > >>> > case, the (average) buffer level can be kept low. > >>> > > >>> > In summary, in my opinion, ECN is a much more decent way of informing > >>the > >>> > sources about congestion, instead of the "cruel" way of packet > >>> > dropping. As mentioned by others, it also saves the efforts of all > >>the > >>> > routers (if any) that processed the packet before it was finally > >>dropped > >>> > somewhere along the path, and also the effort of the source in > >>detecting > >>> > the packet loss. It has other virtues along the same lines that I am > >>not > >>> > listing here. It can be used to distinguish between > >>congestion-related > >>> > and non congestion-related losses only to some degree of reliability. > >>> > Other than that (which are by no means minor enhancements), I don't > >>think > >>> > ECN is *essential* for the decoupling between congestion control and > >>> > performance measures (e.g. queuing delay). > >>> > > >>> > Just a few thoughts. Sincerely, > >>> > > >>> > -Alhussein. > >>> > > >>> > On Fri, 26 Jan 2001, Steven Low wrote: > >>> > > >>> > > > >>> > > > From: Steven Low > >>> > > > To: hari@lcs.mit.edu, slow@caltech.edu > >>> > > > CC: cwcam@caltech.edu, ecn-interest@research.att.com, > >>> end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, > >>> wch@its.caltech.edu > >>> > > > > >>> > > > > >>> > > > Hi Hari, > >>> > > > > >>> > > > I completely agree that there are unresolved issues with the > >>> > > > third approach (drastically reduce buffer overslows so that > >>> > > > losses become primarily due to wireless effects), and you > >>> > > > nicely touch upon several of them. But I'd like to make two > >>> > > > philosophical points about ECN & congestion control first > >>> > > > (which I hope belongs to this list at least peripherally). > >>> > > > > >>> > > > I think the approach of > >>> > > > congesting the network in order to obtain congestion information > >>> > > > as the current TCP does, which is necessary without ECN, > >>> > > > becomes unnecessary with ECN. With AQM, we can decouple > >>> > > > congestion measure & feedback from performance measure such > >>> > > > as loss, delay or queue length. Then, 'congestion' > >>> > > > means 'demand exceeds supply' and congestion signal curbs demands > >>> > > > but the queue can be controlled in a way that maintains good > >>> > > > performance such as low loss & delay. Whether REM can succeed > >>> > > > doing this is a separate matter, but I think this is the approach > >>> > > > we ought to take in designing our congestion control. > >>> Alternatively, > >>> > > > when we couple congestion measure with performance measure, > >>> > > > 'congestion' necessarily means 'bad performance' such as high > >>> > > > loss or delay, and we do not have the *option* (even if we have > >>> > > > the means) of maintaing low loss & delay in times > >>> > > > of congestion (i.e. when new sources joining or capacity drops). > >>> > > > In other words, when there are more sources, loss or delay must > >>be > >>> > > > increased in order to produce high enough signal intensity for > >>> > > > sources to futher cut back their rates; moreover signal intensity > >>> > > > must stay high not only during transient > >>> > > > when new soruces first start but also afterwards. > >>> > > > > >>> > > > REM tries to fix this, not through the exponential form of its > >>> > > > marking probabiltiy function, but by using a different congestion > >>> > > > measure and update rule, that maintains high utilization and low > >>> > > > queue in equilibrium. Again, there can be alternative ways to > >>> > > > achieving this, but I think this is what we should aim for. > >>> > > > And to achieve this it is critical that we decouple congestion > >>> > > > measure from performance measure. > >>> > > > > >>> > > > The second philosophical point is an interesting implication > >>> > > > of the recent extensive works on heavy-tailed traffics and their > >>> > > > origin. It implies that the misc-elephant mix (i.e. > >>> > > > most files are small but most packets belong to long files) > >>> > > > that characterizes current traffics may be a permanent and > >>> > > > essential feature, not an artifice of current applications or > >>> > > > user behavior. The end-to-end congestion control, properly > >>> > > > designed, can be an ideal mechanism in such an environment, > >>> > > > where elephants (that care about bandwidth) > >>> > > > are controlled to maximally utilize the network > >>> > > > in such a way that leaves the queues close to empty, so that > >>> > > > mice (that are delay sensitive) can fly through the network > >>> > > > with little delay. Again, this require a new TCP/AQM strategy > >>> > > > that achieves high utilization + low queue, and ECN (or > >>> > > > explicit notification) helps. > >>> > > > > >>> > > > A common objection to end-to-end congestion control is that > >>> > > > most TCP connections are short and hence end-to-end congestion > >>> > > > control is ineffective. I believe the observation is correct > >>> > > > but not the conclusion. Since HTTP uses TCP and web files > >>> > > > have mice-elephant mix, most TCP connections are therefore mice, > >>> > > > which indeed should not be the primary object for end to end > >>> > > > control. End to end control should target elephants, not mice. > >>> > > > Mice suffer large delay currently, not because they are end to > >>> > > > end controlled, but because the current congestion control (even > >>> > > > just of elephants) can produce large queues in the path of mice. > >>> > > > > >>> > > > So, with the a TCP/AQM strategy that maintains high utilization > >>> > > > and low queue in equilibrium (regardless of hte number of > >>sources), > >>> > > > buffer is used *only* to absorb *transient* bursts. This can be > >>> > > > very different with a scheme that uses, say, queue length to > >>> > > > measure congestion; with such a scheme, we do not have control > > > > > on the equilibrium value of the queue - it is determined solely > >>by > >>> > > > the network topology and #sources and hence can be high depending > >>> > > > on scenario. When queues are always high, they do not have > >>> > > > reserve to handle burst. But when queues are always low, I > >>> > > > think bursts can be much better handled. > >>> > > > > >>> > > > So much for such vague philosophical discussions. Since this > >>> > > > is getting too long, I'd defer discussion on the unresolved > >>> > > > issues with the third approach to some other time (except to > >>> > > > point out that one big challenge is the heterogeneity of > >>> > > > routers during transition when some routers mark packets > >>> > > > and some drop packets to indicate congestion). Btw, I don't > >>> > > > think the three approaches are mutually exclusive and can't > >>> > > > complement each other. > >>> > > > > >>> > > > Steven > >>> > > > > >>> > > > ____________________________________________________________ > >>> > > > Steven Low, Assoc Prof of CS and EE > >>> > > > Caltech, Pasadena, CA91125 > >>> > > > Tel: +1 626 395 6767 Fax: +1 626 792 4257 > >>> > > > slow@caltech.edu > >>> > > > netlab.caltech.edu > >>> > > > > >>> > > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 > >>2001 > >>> > > > >Delivered-To: ecn-interest@research.att.com > >>> > > > >X-url: http://nms.lcs.mit.edu/~hari/ > >>> > > > >To: slow@caltech.edu > >>> > > > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, > >>> wch@its.caltech.edu, > >>> > > > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu > >>> > > > >Subject: Re: RED-->ECN > >>> > > > >Mime-Version: 1.0 > >>> > > > >Date: Fri, 26 Jan 2001 15:56:20 -0500 > >>> > > > >From: Hari Balakrishnan > >>> > > > > > >>> > > > > > >>> > > > >Steven, > >>> > > > > > >>> > > > >REM is an interesting idea for using ECN, and I rather like it > >>from > >>> a research > >>> > > > >standpoint because it doesn't have discontinuities (cf. RED) > >>that > >>> make analysis > >>> > > > >harder. However, I'm generally skeptical that any scheme can be > >>> shown to > >>> > > > >eliminate essentially all buffer overflow losses under _all_ > >>> conditions > >>> > > > >(offered load), and yet accommodate bursts and provide > >>reasonably > >>> low delays... > >>> > > > > especially when not all offered traffic is reacting or reacting > >>in > >>> different > >>> > > > >ways from multiplicative-decrease. Even a small fraction of > >>> unresponsive > >>> > > > >traffic may make life problematic. > >>> > > > > > >>> > > > >Some years ago, I found it pretty hard to tune RED for this, to > >>> enhance my ELN > >>> > > > >scheme. REM may be more promising, but my gut feeling (as a > >>network > >>> engineer) > >>> > > > >tells me that it wouldn't be prudent to such implicit deductions > >>> about loss > >>> > > > >causes in practice... > >>> > > > > > >>> > > > >Hari > >>> > > > > > >>> > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: > >>> > > > > > >>> > > > >> [Sorry for the previous broken msg...] > >>> > > > >> > >>> > > > >> Hi Saverio, > >>> > > > >> > >>> > > > >> Another point I'd like to add is that the addition of ECN > >>> > > > >> may open up new opportunities for network control, some of > >>> > > > >> which we may not even envision now. Without ECN we are > >>> > > > >> stuck with using loss (or delay) as the only means to > >>> > > > >> communicate between network and TCP sources. > >>> > > > >> Let me give an example. > >>> > > > >> > >>> > > > >> There are two types of losses in wireless environment: > >>> > > > >> 1. due to congestion (e.g. buffer overflow), and > >>> > > > >> 2. due to wireles effect (handoffs, fast fading, interference > >>> etc). > >>> > > > >> One problem with TCP over wireless links is that TCP cannot > >>> > > > >> differentiate > >>> > > > >> between the two and essentially assume all losses are due to > >>> > > > >> congestion and reduce its rate. Most of the current proposed > >>> > > > >> solutions are based on two ideas. > >>> > > > >> > >>> > > > >> The first idiea is to hide type 1 (wireless) losses from TCP > >>> source, > >>> > > > >> so it sees only congestion losses and react properly. > >>Examples > >>> > > > >> are various local recovery schemes, snoop, split TCP etc. > >>> > > > >> The first idea is to inform the TCP source which of the two > >>> > > > >> types a loss belongs, so that TCP can react properly; e.g. ELN > >>> schemes. > >>> > > > >> > >>> > > > >> Availability of ECN allows a third approach: to eliminate type > >>2 > >>> > > > >> (congestion) losses, so that TCP source only sees wireless > >>losses > >>> > > > >> and therefore know how to react. But we still need to > >>measure > >>> and > >>> > > > >> feedback 'congestion' so that sources know to reduce their > >>rates > >>> > > > >> when new sources join or capacity drops. By 'congestion', I > >>> don't > >>> > > > >> mean 'high loss', but simply 'demand exceeds supply' so > >>everyone > >>> > > > >> should reduce their demand. Since buffer overflow is now > >>> eliminated > >>> > > > >> (assume we can do this, see below), we need a different > >>mechanism > >>> to > >>> > > > >> measure and to feedback this 'congestion' information. Here > >>is > >>> > > > >> where ECN comes in. When we decouple the measure+feedback of > >>> > > > >> congestion from loss, we must have ECN to provide the > >>feedback. > >>> > > > >> > >>> > > > >> Now, can we possibly keep the queue small (greatly reduce > >>buffer > >>> > > > >> overflow) *yet highly utilized*? Recent research works seem > >>to > >>> > > > >> provide > >>> > > > >> reasons to be optimistic. One example is in our paper: > >>> > > > >> REM: Active Queue Management > >>> > > > >> on our website: > >>> > > > >> netlab.caltech.edu > >>> > > > >> > >>> > > > >> Steven > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 > >>> > > > >> >From: "K. K. Ramakrishnan" > >>> > > > >> >To: Saverio Mascolo > >>> > > > >> >Cc: ecn-interest@research.att.com > >>> > > > >> > > >>> > > > >> >Saverio, > >>> > > > >> >I am glad you see ECN as an evolution from RED. > >>> > > > >> >This is our motivation also: > >>> > > > >> >to have ECN incorporated and deployed with an > >>> > > > >> >Active Queue Management scheme. > >>> > > > >> > > >>> > > > >> >However, it is difficult to agree with the other observations > >>you > >>> make: > >>> > > > >> >if congestion was only caused by "one packet" as you say, > >>then > >>> > > > >> >one might wonder why we need to actually do a whole lot to > >>> > > > >> >one might wonder why we need to actually do a whole lot to > >>> > > > >> >either react to or avoid congestion. Unfortunately, that > >>isn't > >>> the case. > >>> > > > >> > > >>> > > > >> >If you look at a congestion epoch, there are likely to be > >>> multiple > >>> > > > >> >packets, > >>> > > > >> >potentially from multiple flows, that are impacted: > >>> > > > >> >either being marked or dropped. > >>> > > > >> >ECN helps substantially in not dropping packet*s* - and > >>> especially > >>> > > > >> >when the window size for those flows that have their packets > >>> > > > >> >marked, it helps by not having them suffer a time-out. > >>> > > > >> > > >>> > > > >> >Further: the amount of complexity in either the router > >>> (especially > >>> > > > >> >in the router) or the end-system is not significant. I know > >>that > >>> > > > >> >may be a matter of opinion. > >>> > > > >> >But in a router, the change is so minimal, I haven't heard > >>anyone > >>> > > > >> >complain of complexity of implementation. > >>> > > > >> > > >>> > > > >> >There is no violation of layering, at all. I don't see why > >>you > >>> say so. > >>> > > > >> > > >>> > > > >> > K. K. Ramakrishnan > >>> > > > >> >Saverio Mascolo wrote: > >>> > > > >> > > >>> > > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN > >>saves > >>> one > >>> > > > >> >> packet, which is the packet that > >>> > > > >> >> RED would drop to signal congestion, by setting a bit in > >>the > >>> header. > >>> > > > >> >> Thus, to save just > >>> > > > >> >> ONE PACKET, ECN introduces complexity in routers, in the > >>> > > > >> >> protocol, violation of layering, etc...For these reasons I > >>> don't think > >>> > > > >> >> that ECN would give an improvement to RED that is > >>commensurate > >>> to its > >>> > > > >> >> complexity.Is there any point that I miss? Saverio > >>> > > > >> >> > >>> > > > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html > >>> > > > >>> > > -- > >>> > > __________________________________________________________________ > >>> > > Steven Low, Assoc Prof of CS & EE > >>> > > slow@caltech.edu netlab.caltech.edu > >>> > > Tel: (626) 395-6767 Caltech MC256-80 > >>> > > Fax: (626) 792-4257 Pasadena CA 91125 > >>> > > _______________________________________________ > >>> > > end2end-interest mailing list > >>> > > end2end-interest@postel.org > >>> > > http://www.postel.org/mailman/listinfo/end2end-interest > >>> > > > >>> > >>> -- > >>> __________________________________________________________________ > >>> Steven Low, Assoc Prof of CS & EE > >>> slow@caltech.edu netlab.caltech.edu > >>> Tel: (626) 395-6767 Caltech MC256-80 > >>> Fax: (626) 792-4257 Pasadena CA 91125 > >>> > >>> > >>> > >>> > >> > > cheers > > jon > From huitema@exchange.microsoft.com Thu Feb 1 09:16:51 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA09664 for ; Thu, 1 Feb 2001 09:16:51 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Feb 2001 08:52:34 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Feb 2001 08:53:19 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 1 Feb 2001 08:53:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: [e2e] [Fwd: RED-->ECN] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Feb 2001 08:53:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2e] [Fwd: RED-->ECN] Thread-Index: AcCMYaQ57AjiOV74TxusmJnOqnjaZwAB2PdA From: "Christian Huitema" To: "Vishal Misra" , Cc: X-OriginalArrivalTime: 01 Feb 2001 16:53:19.0226 (UTC) FILETIME=[7A95A5A0:01C08C6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id JAA09664 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 46 Well, I think we have to define elephants, mice and maybe add a 3rd category, ants. From a TCP point of vew, I would say that elephants are those sessions whose behavior approaches the asymptotic behavior of the "congestion avoidance" phase, mice are those whose behavior is essentially limited by the slow-start algorithm, and ants are those who simply exchange a couple packets, and are thus not affected at all, even by slow start. In the current TCP spec, an application in slow start mode will exchange N packets in log2(N/X) round trips, where X is the initial window. The average window will be N/log2(X), unless the session encounters a packet loss. These are the ants: their rate is not limited by losses. If the current packet loss is L, the average interval between losses will be 1/L. If the number N is larger than 1/L, but not much larger, then the window before the loss wil be approximately 1/2L, and after the first loss will be 1/4L, and that will probably be sufficient to carry the remaining packets. These sessions, that carry about 1/L packets, are the mice. The average window for the mice will be about 1/(L.(1-log2(L.X))). This is larger than the individual windows of ants. The average window of elephants, according to the classic models, is supposed to be 2/sqrt(L). At the statistical equilibrium, the loss rate, or the RED marking rate, is supposed to be such that everything stabilizes. For the large values of L that we have today, of the order of 1%, the window of elephants tend to be much larger than the window of mice. Assuming X=1, and L=4%, the effective window of mice is about 4, and the asymptotic window of elephants is 10: on average, the elephants run more than twice faster than mice. From a selfish point of view, it makes sense for an application to just keep one TCP connection open, rather than go back to slow start with a new connection. But consider now what happens if we increase the capacity of the network. We want to provide better services, faster transmission for both elephants and mice, and for that we will tend toward lower loss rates (or lower marking rates). Assume we drop the loss rate to 0.1%, a value which is in fact mentioned in many service level agreements. The average window of elephants increases to about 63, which is good: our FTP transfer are now 6 time faster than they were on the congested link that showed a 4% loss rate. But, at the same time, the effective window of mice grows to about 91: now, mice are runnng faster than elephants. There is much less incentive to string several mice together and make them an elephant. Lets pursue the exercize, increase the network capacity some more, so that the loss rate drops to 0.01%. Life becomes even better for mice -- their average window increases to about 700, while the average window of elephants is only 200. At this point, it pays to split the elephant into a string of mice. For a large file transfer, one gets better results if one closes the connection after about 10,000 packets, and restart a new one. Isn't that funny? Indeed, the root of the problem, from a control point of view, is that the window of mice grows as 0(-1/(L.log(L)), while the window of elephants grows as 0(1/sqrt(L)). As you decrease the loss rate, you make life much better for mice than for elephants. Indeed, all this is a simplistic reasoning on averages. Decreasing the loss rate has another effect, that of increasing the average interval between control signals, specially for elephants -- the interval increases linearly with the average throughput of the connection. Less frequent control means more variability -- the rate observed by similar connections will be expected vary widely. I believe that the only way to solve this problem is to change the CA algorithm. The only way elephants can keep ahead of mice is, if their window scales as 0(1/L), instead of 0(1/sqrt(L)). -- Christian Huitema -----Original Message----- From: Vishal Misra [mailto:misra@newworld.cs.umass.edu] Sent: Thursday, February 01, 2001 6:33 AM To: julian_satran@il.ibm.com Cc: end2end-interest@postel.org Subject: Re: [e2e] [Fwd: RED-->ECN] On Thu, 1 Feb 2001 julian_satran@il.ibm.com wrote: > accepted queueing models. Do you have in mind some "quantum > statistics" for networks that we are all unaware of? Do those have > some tunnel effects that allow you to dream about high utilization AND > short queues? Is there some mathematics that can support your > statements? Yes, it is called "Control theory" and has been around for hundreds of years. Steven is talking about a *closed loop* control system. TCP (which is responsible for most of the queues in IP networks) is not an open loop protocol. You cannot apply open loop queueing theory models to describe the behavior of "elephants" which Steven was discussing. If your traffic is purely "elephant" then it is possible to design controllers which simultaneously give low delay and (near) full utilization. Several research groups have already done it and demonstrated it both mathematically and through simulations/testbeds. The presence of "mice" complicates things a bit since even though they might be carried by TCP they don't live long enough to be classified as "controllable". -Vishal From J.Crowcroft@cs.ucl.ac.uk Thu Feb 1 09:33:54 2001 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id JAA12552 for ; Thu, 1 Feb 2001 09:33:53 -0800 (PST) Received: from baby.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Feb 2001 17:33:28 +0000 To: Christian Huitema cc: end2end-interest Subject: Re: [e2e] [Fwd: RED-->ECN] In-reply-to: Your message of "Thu, 01 Feb 2001 08:53:13 PST." Date: Thu, 01 Feb 2001 17:33:24 +0000 Message-ID: <1601.981048804@cs.ucl.ac.uk> From: Jon Crowcroft Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 47 In message , Christian Huitema typed: >>I believe that the only way to solve this problem is to change the CA >>algorithm. The only way elephants can keep ahead of mice is, if their >>window scales as 0(1/L), instead of 0(1/sqrt(L)). Christian all jolly technically true and all that, but what about the intrinsic value of content - tcp is used for downloads - most short downloads are part of web sessions with a sequence of interactions where as most long downlaods are fetching new (microsoft?:-) releases - why shouldnt the poor interactive user getter a better deal...what about shortest job first scheduling argument for overall average numeber of jobs compelted in a workload mix? eh? j. From mascolo@poliba.it Thu Feb 1 10:10:06 2001 Received: from deemail.poliba.it (deemail.poliba.it [193.204.59.11]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA18692 for ; Thu, 1 Feb 2001 10:10:04 -0800 (PST) Received: from deectl18 (193.204.59.114) by deemail.poliba.it with SMTP (Eudora Internet Mail Server 2.1); Thu, 1 Feb 2001 18:09:29 +0100 Message-ID: <013801c08c71$bfde8bc0$723bccc1@poliba.it> From: "Saverio Mascolo" To: "end2end-interest" , "ecn-interest" References: <1422.981045596@cs.ucl.ac.uk> Subject: R: R: [e2e] [Fwd: RED-->ECN] Date: Thu, 1 Feb 2001 18:09:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 48 Could someone point me to papers comparing ECN to RED? Thanks Saverio ----- Original Message ----- From: Jon Crowcroft To: end2end-interest ; ecn-interest ; Sent: Thursday, February 01, 2001 5:39 PM Subject: Re: R: [e2e] [Fwd: RED-->ECN] > > In message <008c01c08c6b$4655eec0$723bccc1@poliba.it>, Saverio Mascolo typed: > > >>I would introduce another element of discussion...Explicit congestion > >>indication was proposed in the ATM community...after a while they concluded > >>that it was necessary a richer feedback in order to obtain an effective > >>"regularization" of queue dynamics, utilization etc...thus it was proposed > >>explicit rate indication such ERICA algorithm. > > the difference between explicit rate feedback and binary feedback can > be overstated - > 1/the bit can be set for a number of flows - if the number of flows is > large, and they respond corectly then the effect can be nearly the same > as setting the "right" explicit rate per flow > > 2/ the rate of change of flows per "rtt" might be such that telling > someone the "right" explicit rate half an rtt ago maybe no better and > might be worse than binary feedback per flow. > > in some of the discussion below, the distinction between the reason > for drop tail (demand >= supply) and RED+ECN (demand is _approaching_ supply > and AQM triggers set) is correctly made - the AQM mechanism can take > into account a lot of other factors (number of current flows, rate of > change of number of flows, even relative RTT of flows (hard to measure > though, esp. in today's assymetric routed interdomain path internet:-)) > > by the way, the idea of a "quantum mechanics" of queues had occurred > to me - not to "perform magic" like quantum tunneling, but the use of > quantum statistics to model the population of queues for very large > systems might not be so far fetched..(yes, i know there are a few > orders of magnitude of orders of magnitude difference in scale, but > its still fun to think of) > > >>> Thu, 1 Feb 2001 13:21:27 +0200 > >>> julian_satran@il.ibm.com > >>> > >>> I would be very interested to understand how you see the > >>"virtual-measure", > >>> you are suggesting exists, relate to accepted theory. It is usually > >>> though that high utilization rates and long queues are related (i.e., > >>you > >>> have long queues when utilization goes up) > >>> > >>> A quibble: Queue length is a function of variance (burstiness), not (just) > >>> of arrival rate. If the input rate exceeds the output rate, queue length > >>> *becomes* unbounded ("infinite"). If the input rate is less than the > >>> output rate, then (independent of variations in inter-arrival time) the > >>> queue length is 0 -- always empty. For an arbitrarily low *average* input > >>> rate, and a long enough interval, and an unbounded queue, I can construct > >>> an arrival schedule that will cause an arbitrarily high *average* queue > >>> length. > >>> > >>> However, what you say is _basically_ true in the real world because as the > >>> input rate approaches the output rate the queue length becomes much more > >>> sensitive to smaller and smaller variations (not to mention that max queue > >>> length *is* bounded), so queue length in practice is probably usually a > >>> reasonable indicator of load. The control needed to smooth flows as > >>> arrival rates get higher is likely to be fragile, and is probably > >>> inconsistent with the philosophy of most people on end2end. But Steven > >>> Low's statements are not immediately dismissable as being totally > >>> self-contradictory, or in the category of perpetual motion machines. > >>> Not to say that there aren't plenty of other arguments to be made, but > >>> dismissing it out of hands on the grounds of ludicrousness isn't one of > >>> them. > >>> > >>> and this is the reason queue > >>> length is used as a measure of congestion. And this is true for all > >>> accepted queueing models. Do you have in mind some "quantum > >>statistics" > >>> for networks that we are all unaware of? Do those have some tunnel > >>effects > >>> that allow you to dream about high utilization AND short queues? Is > >>there > >>> some mathematics that can support your statements? > >>> > >>> Julo > >>> > >>> Julian Satran > >>> IBM Research Lab. at Haifa > >>> > >>> > >>> > >>> Steven Low on 01/02/2001 10:23:33 > >>> > >>> Please respond to slow@caltech.edu > >>> > >>> To: Alhussein Abouzeid > >>> cc: end2end-interest@postel.org, ecn-interest@research.att.com > >>> Subject: Re: [e2e] [Fwd: RED-->ECN] > >>> > >>> > >>> > >>> > >>> Hi Alhussein > >>> > >>> I should clarify what I meant by 'decoupling of congestion measure > >>> from performance measure'. > >>> > >>> I want to distinguish between the > >>> *measure* of congestion and the *feedback* of congestion. The > >>> measure of congestion, vaguely, should track the number of users > >>> or available capacity and this is the information to which users > >>> react by adjusting their rates (windows). For example, DropTail > >>> measures congestion by loss rate (i.e. congestion = high loss), > >>> the original RED measures it by average queue > >>> (ie. congestion = high queue). Alternatively, you can measure > >>> it by a number you compute, e.g., based on queue length and rate, > >>> as you suggested. Then, congestion can simply mean 'demand>supply', > >>> but it is possible to update the congestion measure in a way that > >>> drives the queue or loss to a very low value, and therefore, the > >>> congestion measure can settle down to a high value, telling sources > >>> to keep their rates low, while loss and delay are kept low. > >>> This is the key benefit, which cannot be achieved without decoupling, > >>> for otherwise congestion measure (in this case, loss or queue) must > >>> be kept high to send the right signal to users (unless one adapts RED > >>> parameters dynamically). This is the first type of decoupling. > >>> > >>> Note that even with the first type fo decoupling, > >>> performance measures such as loss, queue, delay or rate, > >>> are used to *update* the congestion measure, but the equilibrium > >>> *value* of the congestion measure is determined "solely" (in an > >>> idealized > >>> world) by the network topology, number of users etc, not by the > >>> flow control algorithm. > >>> > >>> Now, how is the congestion measure fed back? This can be done > >>> implicitly through what can be observed at the source, e.g. loss > >>> or delay. Or it can be done explicitly using ECN or management > >>> packets. This is decoupling the *feedback* of congestion measure > >>> from performance measure. > >>> > >>> By "decoupling", I always meant the first kind of decoupling, which > >>> I think is more important in determining the equilibrium behavior > >>> of congestion control. > >>> > >>> I agree with you completely that ECN helps in the second type of > >>> decoupling, > >>> but not the first type which has to do with the design of AQM (choice > >>> of congestion measure and its update rule). In wireless environment, > >>> however, > >>> because of the two kinds of losses (congestion & random loss), the > >>> second > >>> type of decoupling becomes useful as well. > >>> > >>> Regarding your mice-elephant comment, mice invasion may indeed be a > >>> problem. But that makes it all the more important that elephants are > >>> controlled to leave queues empty (in the absence of mice), and this > >>> seems > >>> hard to do if congestion measure is coupled with performance measure - > >>> empty queue then automatically invites elephants to raise their rates. > >>> If empty queue does not mean "increase you rate", then elephants must > >>> be fed back (through ECN or probabilistical dropping) other necessary > >>> information to set their rates. > >>> > >>> Steven > >>> > >>> > >>> Alhussein Abouzeid wrote: > >>> > > >>> > Hi Steven, > >>> > > >>> > I generally agree with your approach below but have three, also > >>> > philosophical, comments that I'd like to share with you regarding the > >>> > decoupling of congestion measures from performance measures. > >>> > > >>> > Clearly, decoupling these two measures may greatly help in the design > >>of > >>> > congestion control algorithms, since the congestion information > >>becomes > >>> > explicitly available (through say, ECN). However, even with > >>> > the use of ECN, full decoupling is not possible. The reason is that > >>ECN > >>> > packets themselves might be lost if sudden congestion takes place. > >>> > > >>> > Another point is regarding your argument that controlling "elephants" > >>> will > >>> > result in low queue levels and hence "mice" will be able to run > >>quickly > >>> > through the network. While this argument seems quite sensible, at > >>least > >>> to > >>> > me, it is problematic if you imagine the arrival of many such mice - > >>say > >>> a > >>> > mice invasion. Will the ECN marking rate/scheme used for signaling > >>the > >>> > elephants be enough to pro-actively avoid congestion from this mice > >>> > invasion? I think that, at least, this is an important part of the > >>puzzle > >>> > that should not be taken lightly. In other words, the so called > >>> > *transient* effect due to the mice population has to be accommodated > >>and > >>> > handled as carefully as the elephants' *steady state* effect. > >>> > > >>> > Finally, I'd like to add one more point; that the same level of > >>> > decoupling that you propose can still be achieved using AQM without > >>ECN. > >>> > In one context, RED can be viewed as a controller that estimates the > >>> state > >>> > and acts upon the estimate. The average queue size is taken as a > >>measure > >>> > of the state and the feedback signal is a function of the state > >>> > estimate. However, the average queue size need not be the only > >>measure of > >>> > congestion. Indeed, some recent works suggested measuring the arrival > >>> rate > >>> > directly (using some filter to smooth out transients) and using this > >>as > >>> > the measure of congestion. In some sense, such schemes attempts to > >>> achieve > >>> > the rightful objective you mentioned; decide whether demand exceeds > >>> > capacity. Both approaches (queue-based or rate-based) have some > >>problems > >>> > that are too involved to detail here. If the AQM router uses a > >>> > rate-based measure of congestion and drops packets when > >>> > demand exceeds capacity (according to some reasonable algorithm), > >>then > >>> > we effectively achieve the same level of decoupling, and also in this > >>> > case, the (average) buffer level can be kept low. > >>> > > >>> > In summary, in my opinion, ECN is a much more decent way of informing > >>the > >>> > sources about congestion, instead of the "cruel" way of packet > >>> > dropping. As mentioned by others, it also saves the efforts of all > >>the > >>> > routers (if any) that processed the packet before it was finally > >>dropped > >>> > somewhere along the path, and also the effort of the source in > >>detecting > >>> > the packet loss. It has other virtues along the same lines that I am > >>not > >>> > listing here. It can be used to distinguish between > >>congestion-related > >>> > and non congestion-related losses only to some degree of reliability. > >>> > Other than that (which are by no means minor enhancements), I don't > >>think > >>> > ECN is *essential* for the decoupling between congestion control and > >>> > performance measures (e.g. queuing delay). > >>> > > >>> > Just a few thoughts. Sincerely, > >>> > > >>> > -Alhussein. > >>> > > >>> > On Fri, 26 Jan 2001, Steven Low wrote: > >>> > > >>> > > > >>> > > > From: Steven Low > >>> > > > To: hari@lcs.mit.edu, slow@caltech.edu > >>> > > > CC: cwcam@caltech.edu, ecn-interest@research.att.com, > >>> end2end@isi.edu.rliu@yak.ugcs.caltech.edu, siew@its.caltech.edu, > >>> wch@its.caltech.edu > >>> > > > > >>> > > > > >>> > > > Hi Hari, > >>> > > > > >>> > > > I completely agree that there are unresolved issues with the > >>> > > > third approach (drastically reduce buffer overslows so that > >>> > > > losses become primarily due to wireless effects), and you > >>> > > > nicely touch upon several of them. But I'd like to make two > >>> > > > philosophical points about ECN & congestion control first > >>> > > > (which I hope belongs to this list at least peripherally). > >>> > > > > >>> > > > I think the approach of > >>> > > > congesting the network in order to obtain congestion information > >>> > > > as the current TCP does, which is necessary without ECN, > >>> > > > becomes unnecessary with ECN. With AQM, we can decouple > >>> > > > congestion measure & feedback from performance measure such > >>> > > > as loss, delay or queue length. Then, 'congestion' > >>> > > > means 'demand exceeds supply' and congestion signal curbs demands > >>> > > > but the queue can be controlled in a way that maintains good > >>> > > > performance such as low loss & delay. Whether REM can succeed > >>> > > > doing this is a separate matter, but I think this is the approach > >>> > > > we ought to take in designing our congestion control. > >>> Alternatively, > >>> > > > when we couple congestion measure with performance measure, > >>> > > > 'congestion' necessarily means 'bad performance' such as high > >>> > > > loss or delay, and we do not have the *option* (even if we have > >>> > > > the means) of maintaing low loss & delay in times > >>> > > > of congestion (i.e. when new sources joining or capacity drops). > >>> > > > In other words, when there are more sources, loss or delay must > >>be > >>> > > > increased in order to produce high enough signal intensity for > >>> > > > sources to futher cut back their rates; moreover signal intensity > >>> > > > must stay high not only during transient > >>> > > > when new soruces first start but also afterwards. > >>> > > > > >>> > > > REM tries to fix this, not through the exponential form of its > >>> > > > marking probabiltiy function, but by using a different congestion > >>> > > > measure and update rule, that maintains high utilization and low > >>> > > > queue in equilibrium. Again, there can be alternative ways to > >>> > > > achieving this, but I think this is what we should aim for. > >>> > > > And to achieve this it is critical that we decouple congestion > >>> > > > measure from performance measure. > >>> > > > > >>> > > > The second philosophical point is an interesting implication > >>> > > > of the recent extensive works on heavy-tailed traffics and their > >>> > > > origin. It implies that the misc-elephant mix (i.e. > >>> > > > most files are small but most packets belong to long files) > >>> > > > that characterizes current traffics may be a permanent and > >>> > > > essential feature, not an artifice of current applications or > >>> > > > user behavior. The end-to-end congestion control, properly > >>> > > > designed, can be an ideal mechanism in such an environment, > >>> > > > where elephants (that care about bandwidth) > >>> > > > are controlled to maximally utilize the network > >>> > > > in such a way that leaves the queues close to empty, so that > >>> > > > mice (that are delay sensitive) can fly through the network > >>> > > > with little delay. Again, this require a new TCP/AQM strategy > >>> > > > that achieves high utilization + low queue, and ECN (or > >>> > > > explicit notification) helps. > >>> > > > > >>> > > > A common objection to end-to-end congestion control is that > >>> > > > most TCP connections are short and hence end-to-end congestion > >>> > > > control is ineffective. I believe the observation is correct > >>> > > > but not the conclusion. Since HTTP uses TCP and web files > >>> > > > have mice-elephant mix, most TCP connections are therefore mice, > >>> > > > which indeed should not be the primary object for end to end > >>> > > > control. End to end control should target elephants, not mice. > >>> > > > Mice suffer large delay currently, not because they are end to > >>> > > > end controlled, but because the current congestion control (even > >>> > > > just of elephants) can produce large queues in the path of mice. > >>> > > > > >>> > > > So, with the a TCP/AQM strategy that maintains high utilization > >>> > > > and low queue in equilibrium (regardless of hte number of > >>sources), > >>> > > > buffer is used *only* to absorb *transient* bursts. This can be > >>> > > > very different with a scheme that uses, say, queue length to > >>> > > > measure congestion; with such a scheme, we do not have control > > > > > on the equilibrium value of the queue - it is determined solely > >>by > >>> > > > the network topology and #sources and hence can be high depending > >>> > > > on scenario. When queues are always high, they do not have > >>> > > > reserve to handle burst. But when queues are always low, I > >>> > > > think bursts can be much better handled. > >>> > > > > >>> > > > So much for such vague philosophical discussions. Since this > >>> > > > is getting too long, I'd defer discussion on the unresolved > >>> > > > issues with the third approach to some other time (except to > >>> > > > point out that one big challenge is the heterogeneity of > >>> > > > routers during transition when some routers mark packets > >>> > > > and some drop packets to indicate congestion). Btw, I don't > >>> > > > think the three approaches are mutually exclusive and can't > >>> > > > complement each other. > >>> > > > > >>> > > > Steven > >>> > > > > >>> > > > ____________________________________________________________ > >>> > > > Steven Low, Assoc Prof of CS and EE > >>> > > > Caltech, Pasadena, CA91125 > >>> > > > Tel: +1 626 395 6767 Fax: +1 626 792 4257 > >>> > > > slow@caltech.edu > >>> > > > netlab.caltech.edu > >>> > > > > >>> > > > >From owner-ecn-interest@research.att.com Sat Jan 27 08:02:12 > >>2001 > >>> > > > >Delivered-To: ecn-interest@research.att.com > >>> > > > >X-url: http://nms.lcs.mit.edu/~hari/ > >>> > > > >To: slow@caltech.edu > >>> > > > >Cc: ecn-interest@research.att.com, cwcam@caltech.edu, > >>> wch@its.caltech.edu, > >>> > > > > siew@its.caltech.edu, rliu@yak.ugcs.caltech.edu > >>> > > > >Subject: Re: RED-->ECN > >>> > > > >Mime-Version: 1.0 > >>> > > > >Date: Fri, 26 Jan 2001 15:56:20 -0500 > >>> > > > >From: Hari Balakrishnan > >>> > > > > > >>> > > > > > >>> > > > >Steven, > >>> > > > > > >>> > > > >REM is an interesting idea for using ECN, and I rather like it > >>from > >>> a research > >>> > > > >standpoint because it doesn't have discontinuities (cf. RED) > >>that > >>> make analysis > >>> > > > >harder. However, I'm generally skeptical that any scheme can be > >>> shown to > >>> > > > >eliminate essentially all buffer overflow losses under _all_ > >>> conditions > >>> > > > >(offered load), and yet accommodate bursts and provide > >>reasonably > >>> low delays... > >>> > > > > especially when not all offered traffic is reacting or reacting > >>in > >>> different > >>> > > > >ways from multiplicative-decrease. Even a small fraction of > >>> unresponsive > >>> > > > >traffic may make life problematic. > >>> > > > > > >>> > > > >Some years ago, I found it pretty hard to tune RED for this, to > >>> enhance my ELN > >>> > > > >scheme. REM may be more promising, but my gut feeling (as a > >>network > >>> engineer) > >>> > > > >tells me that it wouldn't be prudent to such implicit deductions > >>> about loss > >>> > > > >causes in practice... > >>> > > > > > >>> > > > >Hari > >>> > > > > > >>> > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote: > >>> > > > > > >>> > > > >> [Sorry for the previous broken msg...] > >>> > > > >> > >>> > > > >> Hi Saverio, > >>> > > > >> > >>> > > > >> Another point I'd like to add is that the addition of ECN > >>> > > > >> may open up new opportunities for network control, some of > >>> > > > >> which we may not even envision now. Without ECN we are > >>> > > > >> stuck with using loss (or delay) as the only means to > >>> > > > >> communicate between network and TCP sources. > >>> > > > >> Let me give an example. > >>> > > > >> > >>> > > > >> There are two types of losses in wireless environment: > >>> > > > >> 1. due to congestion (e.g. buffer overflow), and > >>> > > > >> 2. due to wireles effect (handoffs, fast fading, interference > >>> etc). > >>> > > > >> One problem with TCP over wireless links is that TCP cannot > >>> > > > >> differentiate > >>> > > > >> between the two and essentially assume all losses are due to > >>> > > > >> congestion and reduce its rate. Most of the current proposed > >>> > > > >> solutions are based on two ideas. > >>> > > > >> > >>> > > > >> The first idiea is to hide type 1 (wireless) losses from TCP > >>> source, > >>> > > > >> so it sees only congestion losses and react properly. > >>Examples > >>> > > > >> are various local recovery schemes, snoop, split TCP etc. > >>> > > > >> The first idea is to inform the TCP source which of the two > >>> > > > >> types a loss belongs, so that TCP can react properly; e.g. ELN > >>> schemes. > >>> > > > >> > >>> > > > >> Availability of ECN allows a third approach: to eliminate type > >>2 > >>> > > > >> (congestion) losses, so that TCP source only sees wireless > >>losses > >>> > > > >> and therefore know how to react. But we still need to > >>measure > >>> and > >>> > > > >> feedback 'congestion' so that sources know to reduce their > >>rates > >>> > > > >> when new sources join or capacity drops. By 'congestion', I > >>> don't > >>> > > > >> mean 'high loss', but simply 'demand exceeds supply' so > >>everyone > >>> > > > >> should reduce their demand. Since buffer overflow is now > >>> eliminated > >>> > > > >> (assume we can do this, see below), we need a different > >>mechanism > >>> to > >>> > > > >> measure and to feedback this 'congestion' information. Here > >>is > >>> > > > >> where ECN comes in. When we decouple the measure+feedback of > >>> > > > >> congestion from loss, we must have ECN to provide the > >>feedback. > >>> > > > >> > >>> > > > >> Now, can we possibly keep the queue small (greatly reduce > >>buffer > >>> > > > >> overflow) *yet highly utilized*? Recent research works seem > >>to > >>> > > > >> provide > >>> > > > >> reasons to be optimistic. One example is in our paper: > >>> > > > >> REM: Active Queue Management > >>> > > > >> on our website: > >>> > > > >> netlab.caltech.edu > >>> > > > >> > >>> > > > >> Steven > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500 > >>> > > > >> >From: "K. K. Ramakrishnan" > >>> > > > >> >To: Saverio Mascolo > >>> > > > >> >Cc: ecn-interest@research.att.com > >>> > > > >> > > >>> > > > >> >Saverio, > >>> > > > >> >I am glad you see ECN as an evolution from RED. > >>> > > > >> >This is our motivation also: > >>> > > > >> >to have ECN incorporated and deployed with an > >>> > > > >> >Active Queue Management scheme. > >>> > > > >> > > >>> > > > >> >However, it is difficult to agree with the other observations > >>you > >>> make: > >>> > > > >> >if congestion was only caused by "one packet" as you say, > >>then > >>> > > > >> >one might wonder why we need to actually do a whole lot to > >>> > > > >> >one might wonder why we need to actually do a whole lot to > >>> > > > >> >either react to or avoid congestion. Unfortunately, that > >>isn't > >>> the case. > >>> > > > >> > > >>> > > > >> >If you look at a congestion epoch, there are likely to be > >>> multiple > >>> > > > >> >packets, > >>> > > > >> >potentially from multiple flows, that are impacted: > >>> > > > >> >either being marked or dropped. > >>> > > > >> >ECN helps substantially in not dropping packet*s* - and > >>> especially > >>> > > > >> >when the window size for those flows that have their packets > >>> > > > >> >marked, it helps by not having them suffer a time-out. > >>> > > > >> > > >>> > > > >> >Further: the amount of complexity in either the router > >>> (especially > >>> > > > >> >in the router) or the end-system is not significant. I know > >>that > >>> > > > >> >may be a matter of opinion. > >>> > > > >> >But in a router, the change is so minimal, I haven't heard > >>anyone > >>> > > > >> >complain of complexity of implementation. > >>> > > > >> > > >>> > > > >> >There is no violation of layering, at all. I don't see why > >>you > >>> say so. > >>> > > > >> > > >>> > > > >> > K. K. Ramakrishnan > >>> > > > >> >Saverio Mascolo wrote: > >>> > > > >> > > >>> > > > >> >> Hi All, I see ECN as an evolution of RED. Basically ECN > >>saves > >>> one > >>> > > > >> >> packet, which is the packet that > >>> > > > >> >> RED would drop to signal congestion, by setting a bit in > >>the > >>> header. > >>> > > > >> >> Thus, to save just > >>> > > > >> >> ONE PACKET, ECN introduces complexity in routers, in the > >>> > > > >> >> protocol, violation of layering, etc...For these reasons I > >>> don't think > >>> > > > >> >> that ECN would give an improvement to RED that is > >>commensurate > >>> to its > >>> > > > >> >> complexity.Is there any point that I miss? Saverio > >>> > > > >> >> > >>> > > > >> >> http://www-dee.poliba.it/dee-web/Personale/mascolo.html > >>> > > > >>> > > -- > >>> > > __________________________________________________________________ > >>> > > Steven Low, Assoc Prof of CS & EE > >>> > > slow@caltech.edu netlab.caltech.edu > >>> > > Tel: (626) 395-6767 Caltech MC256-80 > >>> > > Fax: (626) 792-4257 Pasadena CA 91125 > >>> > > _______________________________________________ > >>> > > end2end-interest mailing list > >>> > > end2end-interest@postel.org > >>> > > http://www.postel.org/mailman/listinfo/end2end-interest > >>> > > > >>> > >>> -- > >>> __________________________________________________________________ > >>> Steven Low, Assoc Prof of CS & EE > >>> slow@caltech.edu netlab.caltech.edu > >>> Tel: (626) 395-6767 Caltech MC256-80 > >>> Fax: (626) 792-4257 Pasadena CA 91125 > >>> > >>> > >>> > >>> > >> > > cheers > > jon > From braden@ISI.EDU Thu Feb 1 10:17:56 2001 Received: (from braden@localhost) by boreas.isi.edu (8.9.3/8.9.3) id KAA19930 for end2end-interest; Thu, 1 Feb 2001 10:17:56 -0800 (PST) Date: Thu, 1 Feb 2001 10:17:56 -0800 (PST) From: Bob Braden Message-Id: <200102011817.KAA19930@boreas.isi.edu> To: end2end-interest@ISI.EDU Content-Type: X-sun-attachment Subject: [e2e] I-D ACTION:draft-carpenter-midtax-00.txt Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 49 ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 64 The following Internet Draft should be of interest to this mailing list, and perhaps this is the appropriate venue for a discussion of it. Bob Braden _____________________________________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Middle boxes: taxonomy and issues Author(s) : B. Carpenter Filename : draft-carpenter-midtax-00.txt Pages : 15 Date : 30-Jan-01 This document is intended as input to IETF discussion about 'middle boxes' - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-midtax-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-carpenter-midtax-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-carpenter-midtax-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End Included Message ----- ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Content-Lines: 22 X-Sun-Content-Length: 494 X-Sun-Charset: us-ascii --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010130111555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-carpenter-midtax-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-carpenter-midtax-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010130111555.I-D@ietf.org> --OtherAccess-- From huitema@exchange.microsoft.com Thu Feb 1 10:21:33 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA20471 for ; Thu, 1 Feb 2001 10:21:33 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Feb 2001 09:52:21 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Feb 2001 09:53:06 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 1 Feb 2001 09:53:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: [e2e] [Fwd: RED-->ECN] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Feb 2001 09:52:54 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2e] [Fwd: RED-->ECN] Thread-Index: AcCMdauINpadmprTQUi7sdUf6//13QAAZ6Gg From: "Christian Huitema" To: "Jon Crowcroft" Cc: "end2end-interest" X-OriginalArrivalTime: 01 Feb 2001 17:53:05.0898 (UTC) FILETIME=[D4685CA0:01C08C77] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id KAA20471 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 50 Jon, Yes, we could indeed decide that penalizing long sessions is a good thing. But, guess what, the guys writing the download applications are no dummies. If they observe that loop until EOF open connection go to current file location get an additional 5 megabytes, or the rest of the file if less ... gets then better performance than just "open a connection and get the file," guess what they will do? Indeed, you could call that an intelligence test -- smart elephants morph into mice, the other ones go the way of the dinosaurs. But then, why are we bothering writing complex requirements for TCP? -- Christian Huitema -----Original Message----- From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk] Sent: Thursday, February 01, 2001 9:33 AM To: Christian Huitema Cc: end2end-interest Subject: Re: [e2e] [Fwd: RED-->ECN] In message , Christian Huitema typed: >>I believe that the only way to solve this problem is to change the CA >>algorithm. The only way elephants can keep ahead of mice is, if their >>window scales as 0(1/L), instead of 0(1/sqrt(L)). Christian all jolly technically true and all that, but what about the intrinsic value of content - tcp is used for downloads - most short downloads are part of web sessions with a sequence of interactions where as most long downlaods are fetching new (microsoft?:-) releases - why shouldnt the poor interactive user getter a better deal...what about shortest job first scheduling argument for overall average numeber of jobs compelted in a workload mix? eh? j. From braden@ISI.EDU Thu Feb 1 11:18:17 2001 Received: (from braden@localhost) by boreas.isi.edu (8.9.3/8.9.3) id LAA28844; Thu, 1 Feb 2001 11:18:17 -0800 (PST) Date: Thu, 1 Feb 2001 11:18:17 -0800 (PST) From: Bob Braden Message-Id: <200102011918.LAA28844@boreas.isi.edu> To: J.Crowcroft@cs.ucl.ac.uk, huitema@exchange.microsoft.com Subject: RE: [e2e] [Fwd: RED-->ECN] Cc: end2end-interest@postel.org X-Sun-Charset: US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 51 *> *> Jon, *> *> Yes, we could indeed decide that penalizing long sessions is a good *> thing. But, guess what, the guys writing the download applications are *> no dummies. If they observe that *> loop until EOF *> open connection *> go to current file location *> get an additional 5 megabytes, or the rest of the file *> if less *> ... gets then better performance than just "open a connection and get *> the file," guess what they will do? Indeed, you could call that an *> intelligence test -- smart elephants morph into mice, the other ones go *> the way of the dinosaurs. But then, why are we bothering writing complex *> requirements for TCP? Christian, Unhh, maybe because the Internet is heterogeneous, and some parts of it will always have 4% loss rates rather than .01%? It is unclear whether your interesting observation is a bug, as you suggest, or rather a feature that results from the basic packet physics. Why is it a bad thing if users can optimize their service by opening multiple TCP connections? Bob Braden From luigi@info.iet.unipi.it Thu Feb 1 11:52:24 2001 Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA05604 for ; Thu, 1 Feb 2001 11:52:23 -0800 (PST) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id UAA56535; Thu, 1 Feb 2001 20:54:25 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200102011954.UAA56535@info.iet.unipi.it> Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: <200102011918.LAA28844@boreas.isi.edu> from Bob Braden at "Feb 1, 2001 11:18:17 am" To: Bob Braden Date: Thu, 1 Feb 2001 20:54:25 +0100 (CET) CC: J.Crowcroft@cs.ucl.ac.uk, huitema@exchange.microsoft.com, end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 52 > Christian, > > Unhh, maybe because the Internet is heterogeneous, and some parts of it > will always have 4% loss rates rather than .01%? > > It is unclear whether your interesting observation is a bug, as you > suggest, or rather a feature that results from the basic packet physics. > Why is it a bad thing if users can optimize their service by opening > multiple TCP connections? because depending on the number of connections the dynamics of the set of tcp connections change from AIMD to MIMD to no-congestion-control as below: HTTP head request to get file_size # 2 RTT n = file_size / initial_window ; for i = 0 to n-1 do # all this in parallel, 2RTT + n*fork delay get a chunk of size initial_window at offset i*initial_window & done and voila. total 4RTT, no cong.control, fully compliant TCP. (i don't remember if christian's model assumed that the loss changes with the number of connections, but probably not. ) cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . ----------------------------------+----------------------------------------- From jrex@research.att.com Thu Feb 1 12:02:46 2001 Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA13156 for ; Thu, 1 Feb 2001 12:02:46 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id MAA07488 for ; Thu, 1 Feb 2001 12:02:44 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id BB32A1E0CA for ; Thu, 1 Feb 2001 15:02:42 -0500 (EST) Received: from chips-ha.research.att.com (chips-ha.research.att.com [135.207.27.139]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA06298; Thu, 1 Feb 2001 15:02:41 -0500 (EST) Received: (from jrex@localhost) by chips-ha.research.att.com (SGI-8.9.3/8.8.5) id PAA48396; Thu, 1 Feb 2001 15:02:41 -0500 (EST) Date: Thu, 1 Feb 2001 15:02:41 -0500 (EST) Message-Id: <200102012002.PAA48396@chips-ha.research.att.com> From: Jennifer Rexford To: end2end-interest@ISI.EDU Subject: [e2e] CFP for JSAC issue on Internet Proxy Services (May 1, 2001 deadline) Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 53 =========================================================================== CALL FOR PAPERS IEEE Journal on Selected Areas in Communications INTERNET PROXY SERVICES (http://www.argreenhouse.com/society/J-SAC/Calls/internet.html) With the rapid growth of the Web in the past few years, proxies have become a crucial part of the Internet infrastructure. Acting as an intermediary between clients and servers, proxies perform a variety of important functions that improve network efficiency and user performance for Web and multimedia transfers. For example, proxies cache popular resources, anonymize client requests, and transform or adapt server responses. Network administrators install proxies to reduce network load and user latency, and Web hosting companies use proxies to reduce the load on origin servers. In addition, proxies form the core part of content distribution networks that replicate and distribute data from a variety of locations in the Internet. Possible topics include, but are not limited to: Web proxy services (e.g., caching, content adaptation, prefetching, anonymization) Multimedia proxy services (e.g., caching, retransmission, transcoding, smoothing, recording) Distributed, hierarchical, and cooperative caching Interception proxies and surrogate proxies Content distribution networks Testbeds, prototypes, and commercial products File system, I/O, and operating system issues for proxies Protocol issues for proxies (e.g., HTTP, RTSP, ICAP, ICP, CARP, WPAD, etc.) Traffic measurement and performance evaluation of proxies Original, previously unpublished research articles will be considered. Authors should follow the IEEE J-SAC manuscript format described in the Information for Authors or on the inside back cover of any issue of J-SAC. Prospective authors are requested to e-mail their manuscripts as a postscript or pdf attachment to Jennifer Rexford, or if this is not possible, to mail six paper copies, according to the following timetable: Manuscript submission: May 1, 2001 Acceptance notification: October 1, 2001 Final manuscript due: January 1, 2002 Publication: 2nd Quarter 2002 Jennifer Rexford AT&T Labs - Research 180 Park Avenue, Rm A169 Florham Park, NJ 07932 jrex@research.att.com Ellen Zegura College of Computing Georgia Tech Atlanta, GA 30332-0280 ewz@cc.gatech.edu Peter Danzig Akamai 875 College Avenue Menlo Park, CA 94025 danzig@danzigthomas.com Ernst Biersack Corporate Communications Dept Institut Eurecom Sophia Antipolis, France erbi@eurecom.fr =========================================================================== From cannara@attglobal.net Thu Feb 1 12:10:27 2001 Received: from prserv.net (out4.prserv.net [32.97.166.34]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA14059 for ; Thu, 1 Feb 2001 12:10:26 -0800 (PST) Received: from attglobal.net (slip-32-100-70-29.ca.us.prserv.net[32.100.70.29]) by prserv.net (out4) with SMTP id <2001020120102420401aiap9e>; Thu, 1 Feb 2001 20:10:24 +0000 Message-ID: <3A79C338.E4C1D0B0@attglobal.net> Date: Thu, 01 Feb 2001 12:12:40 -0800 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: end2end-interest Subject: Re: [e2e] [Fwd: RED-->ECN] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 54 Good, Christian. One observation of real TCPs in real corporate networks comes to mind here -- two user-application phases: a) user sets up some operations on a remote host, using system commands, scripts, etc., ending in an FTP request; b) the FTP request results in multi-MB transfer. This happens many times every day in design firms. Suppose the router feeding the bottleneck link, say a T1, has simple FIFO queuing. Users in phase a) suffer huge delays, simply because even one other user already in phase b) has a host dumping a many-packet window into its LAN side of the router -- these packets are queued for output ahead of almost every single-packet command a phase a) user emits. Since the data packets are typically full sized, they take 8mS each to enter a T1. Suppose the round-trip delay is 100mS, then a 12-packet TCP transmit window for the FTP host will double the delay each phase a) user command experiences. If these commands are part of a lengthy script, for instance, the actual user will see his 20-second command sequence bumper to 40 seconds, etc. If phase b) is occurring in both directions on the link, the users in phase a) have their normal delays at least quadrupled. Obviously, the networks-for-dummies solution of buying another T1 might help a bit, but the best thing is to treat the small-packet, tick-tock commands with priority, say weighted queuing, round-robin queues distinguished by packet size, etc. But, how many network admins actually understand this and how to fix it? We all know how many, or should know. Any network (taken as a system) that can't easily and automatically figure these simple things out is not a true system, certainly not a feedback-control system of any sort. We know TCP is a poor example of feedback control, because it often exerts the wrong 'control', so something more intelligent needs to be done in the network itself. Take one more example, happening every second of every TCP day -- the odd- packet timer problem. A corporate net with connections around the world experiences round-trip delays on the order of 1/4 second. A set of database lookups for common applications (Oracle, PeopleSoft, etc.) usually take one, two or three packets of data in either direction. Running on defaulted TCP incurs a penalty -- when many of the operations take an odd number of packets to complete, the receiving TCP, being defaulted these many years to Ack alternate packets, will not Ack the 1st, 3rd, etc. packet right away. Instead, it will go into Ack timeout, typically defaulted to 200mS. So, if the round-trip delay is 200mS the overall application responsiveness is now cut in about half. Does the receiving TCP evidence a "systems-control" intelligence that uses the consistent input from the sender that packets come in odd numbers? None that I've seen. Unless the admin is smart and realizes that common TCPs (Microsoft, Sun...) and their writers don't have a clue about many real-life networking issues, he/she will leave the defaulted Ack timer, perhaps not even knowing it exists, and go trying to buy higher bitrate links, only to discover little if any effect. The above are two everyday examples that can be addressed directly by attention to how the network and aged TCP can be improved to actually enter the millenium respectably. Of course, we consultants love this myopic, bureaucratic Internet stuff. {:o] Alex Christian Huitema wrote: > > Jon, > > Yes, we could indeed decide that penalizing long sessions is a good > thing. But, guess what, the guys writing the download applications are > no dummies. If they observe that > loop until EOF > open connection > go to current file location > get an additional 5 megabytes, or the rest of the file > if less > .... gets then better performance than just "open a connection and get > the file," guess what they will do? Indeed, you could call that an > intelligence test -- smart elephants morph into mice, the other ones go > the way of the dinosaurs. But then, why are we bothering writing complex > requirements for TCP? > > -- Christian Huitema > > -----Original Message----- > From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk] > Sent: Thursday, February 01, 2001 9:33 AM > To: Christian Huitema > Cc: end2end-interest > Subject: Re: [e2e] [Fwd: RED-->ECN] > > In message , > Christian > Huitema typed: > > >>I believe that the only way to solve this problem is to change the CA > >>algorithm. The only way elephants can keep ahead of mice is, if their > >>window scales as 0(1/L), instead of 0(1/sqrt(L)). > > Christian > > all jolly technically true and all that, but what about the intrinsic > value of content - tcp is used for downloads - most short downloads > are part of web sessions with a sequence of interactions where as most > long downlaods are fetching new (microsoft?:-) releases - why shouldnt > the poor interactive user getter a better deal...what about shortest > job first scheduling argument for overall average numeber of jobs > compelted in a workload mix? eh? > > j. From huitema@exchange.microsoft.com Thu Feb 1 12:10:35 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA14066 for ; Thu, 1 Feb 2001 12:10:35 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Feb 2001 11:31:29 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Feb 2001 11:32:14 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 1 Feb 2001 11:32:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: [e2e] [Fwd: RED-->ECN] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Feb 2001 11:32:02 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2e] [Fwd: RED-->ECN] Thread-Index: AcCMg8i7Xnrm4QgKSP6ffSJc5FupZwAAHPvg From: "Christian Huitema" To: "Bob Braden" , Cc: X-OriginalArrivalTime: 01 Feb 2001 19:32:10.0213 (UTC) FILETIME=[AB7ED950:01C08C85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id MAA14066 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 55 > It is unclear whether your interesting observation is a bug, > as you suggest, or rather a feature that results from the > basic packet physics. Why is it a bad thing if users can > optimize their service by opening multiple TCP connections? Well, if the result is that people actually bypass the congestion avoidance algorithm for high speed transmissions at the cost of more complex implementations, then maybe we ought to fix the algorithm so they can use simpler software while remaining "legal." -- Christian Huitema From huitema@exchange.microsoft.com Thu Feb 1 12:10:36 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA14068 for ; Thu, 1 Feb 2001 12:10:35 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Feb 2001 11:38:01 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Feb 2001 11:38:46 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 1 Feb 2001 11:38:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: [e2e] [Fwd: RED-->ECN] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Feb 2001 11:38:34 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2e] [Fwd: RED-->ECN] Thread-Index: AcCMg8i7Xnrm4QgKSP6ffSJc5FupZwAAc6nQ From: "Christian Huitema" To: "Bob Braden" Cc: X-OriginalArrivalTime: 01 Feb 2001 19:38:42.0009 (UTC) FILETIME=[95062C90:01C08C86] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id MAA14068 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 56 My specific suggestion would be to start using linear increase (increase the window by a constant x for each Ack) instead of the sublinear increase we have now (increase by 1/W), for the high speed connections (e.g. when W > 40). We can tune the constant "x" so that the increase at the threshold point (W=40?) is equal on both sides of the threshold (e.g., x=1/40). The behavior would remain exactly the same in the case of high error rates, but we would gain better control in the case of low error rates. Then, the application designers would not be forced into "optimisations." -- Christian Huitema > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: Thursday, February 01, 2001 11:18 AM > To: J.Crowcroft@cs.ucl.ac.uk; Christian Huitema > Cc: end2end-interest@postel.org > Subject: RE: [e2e] [Fwd: RED-->ECN] > > > *> > *> Jon, > *> > *> Yes, we could indeed decide that penalizing long > sessions is a good > *> thing. But, guess what, the guys writing the download > applications are > *> no dummies. If they observe that > *> loop until EOF > *> open connection > *> go to current file location > *> get an additional 5 megabytes, or the rest of the file > *> if less > *> ... gets then better performance than just "open a > connection and get > *> the file," guess what they will do? Indeed, you could > call that an > *> intelligence test -- smart elephants morph into mice, > the other ones go > *> the way of the dinosaurs. But then, why are we bothering > writing complex > *> requirements for TCP? > > Christian, > > Unhh, maybe because the Internet is heterogeneous, and some > parts of it will always have 4% loss rates rather than .01%? > > It is unclear whether your interesting observation is a bug, > as you suggest, or rather a feature that results from the > basic packet physics. Why is it a bad thing if users can > optimize their service by opening multiple TCP connections? > > Bob Braden > > From padhye@moose.aciri.org Thu Feb 1 12:30:15 2001 Received: from moose.aciri.org (moose.aciri.org [192.150.187.26]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA16555 for ; Thu, 1 Feb 2001 12:30:15 -0800 (PST) Received: (from padhye@localhost) by moose.aciri.org (8.11.1/8.11.1) id f11KUEd01456 for end2end-interest@postel.org; Thu, 1 Feb 2001 12:30:14 -0800 (PST) (envelope-from padhye) From: Jitendra Padhye Message-Id: <200102012030.f11KUEd01456@moose.aciri.org> Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: from Christian Huitema at "Feb 1, 2001 11:32: 2 am" To: end2end-interest@postel.org Date: Thu, 1 Feb 2001 12:30:14 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 57 If users replace elephant connections with armies of mice, just because of the low loss rate guaranteed by the SLA, won't the loss rate increase? Perhaps the increase will be enough to make elephants more attractive than the armies of mice, once again? I can not imagine that the loss rate specified in SLAs continues to remain valid regardless of the characteristics of the traffic you send in. - Jitu > > It is unclear whether your interesting observation is a bug, > > as you suggest, or rather a feature that results from the > > basic packet physics. Why is it a bad thing if users can > > optimize their service by opening multiple TCP connections? > > Well, if the result is that people actually bypass the congestion > avoidance algorithm for high speed transmissions at the cost of more > complex implementations, then maybe we ought to fix the algorithm so > they can use simpler software while remaining "legal." > > -- Christian Huitema > From huitema@exchange.microsoft.com Thu Feb 1 12:45:23 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA18251 for ; Thu, 1 Feb 2001 12:45:23 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Feb 2001 12:37:32 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Feb 2001 12:38:17 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 1 Feb 2001 12:38:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: [e2e] [Fwd: RED-->ECN] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Feb 2001 12:38:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2e] [Fwd: RED-->ECN] Thread-Index: AcCMiQ06SQB9Nk17SgCSQw6ttcp4jgABQh8g From: "Christian Huitema" To: "Luigi Rizzo" Cc: X-OriginalArrivalTime: 01 Feb 2001 20:38:12.0759 (UTC) FILETIME=[E55B6270:01C08C8E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id MAA18251 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 58 > and voila. total 4RTT, no cong.control, fully compliant TCP. > (i don't remember if christian's model assumed that the loss > changes with the number of connections, but probably not. ) The loss rate does indeed change with the number of connections. You have to increase the loss rate to the point where the global load matches demand. For example, if the congestion window W of all connections follow a 0(1/sqrt(L)) law, the loss rate will vary as 0(N^2). If W follows a 0(1/L) law, the loss rate will vary as 0(1/N). If you have a mix, then you get to be somewhere in between... My model assumed a somewhat polite file transfer, that kept only one connection open at a time. -- Christian Huitema From luigi@info.iet.unipi.it Thu Feb 1 12:49:55 2001 Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA18818 for ; Thu, 1 Feb 2001 12:49:54 -0800 (PST) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id VAA56697; Thu, 1 Feb 2001 21:52:05 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200102012052.VAA56697@info.iet.unipi.it> Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: from Christian Huitema at "Feb 1, 2001 11:38:34 am" To: Christian Huitema Date: Thu, 1 Feb 2001 21:52:05 +0100 (CET) CC: Bob Braden , end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 59 > My specific suggestion would be to start using linear increase (increase > the window by a constant x for each Ack) instead of the sublinear > increase we have now (increase by 1/W), for the high speed connections the terminology is confusing... a constant-increase-per-ack means multiplicative increase over time. cheers luigi > (e.g. when W > 40). We can tune the constant "x" so that the increase at > the threshold point (W=40?) is equal on both sides of the threshold > (e.g., x=1/40). The behavior would remain exactly the same in the case > of high error rates, but we would gain better control in the case of low > error rates. Then, the application designers would not be forced into > "optimisations." > > -- Christian Huitema > > > -----Original Message----- > > From: Bob Braden [mailto:braden@ISI.EDU] > > Sent: Thursday, February 01, 2001 11:18 AM > > To: J.Crowcroft@cs.ucl.ac.uk; Christian Huitema > > Cc: end2end-interest@postel.org > > Subject: RE: [e2e] [Fwd: RED-->ECN] > > > > > > *> > > *> Jon, > > *> > > *> Yes, we could indeed decide that penalizing long > > sessions is a good > > *> thing. But, guess what, the guys writing the download > > applications are > > *> no dummies. If they observe that > > *> loop until EOF > > *> open connection > > *> go to current file location > > *> get an additional 5 megabytes, or the rest of the file > > *> if less > > *> ... gets then better performance than just "open a > > connection and get > > *> the file," guess what they will do? Indeed, you could > > call that an > > *> intelligence test -- smart elephants morph into mice, > > the other ones go > > *> the way of the dinosaurs. But then, why are we bothering > > writing complex > > *> requirements for TCP? > > > > Christian, > > > > Unhh, maybe because the Internet is heterogeneous, and some > > parts of it will always have 4% loss rates rather than .01%? > > > > It is unclear whether your interesting observation is a bug, > > as you suggest, or rather a feature that results from the > > basic packet physics. Why is it a bad thing if users can > > optimize their service by opening multiple TCP connections? > > > > Bob Braden > > > > > From slow@caltech.edu Thu Feb 1 14:13:53 2001 Received: from imap.cs.caltech.edu (imap.cs.caltech.edu [131.215.44.17]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA00524 for ; Thu, 1 Feb 2001 14:13:53 -0800 (PST) Received: from [131.215.44.217] (HELO caltech.edu) by imap.cs.caltech.edu (CommuniGate Pro SMTP 3.3.1) with ESMTP id 812761; Thu, 01 Feb 2001 14:08:47 -0800 Message-ID: <3A79DFCC.3912BB8@caltech.edu> Date: Thu, 01 Feb 2001 14:14:36 -0800 From: Steven Low Reply-To: slow@caltech.edu Organization: Caltech X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: julian_satran@il.ibm.com CC: Alhussein Abouzeid , end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 60 Julo I should indeed qualify my statements, but it's hard to be precise without getting too involved. Let me nonetheless try to give a rough sketch. All statements are made within the context of a simple deterministic fluid optimizaiton model of flow control first proposed by Frank Kelly, where one can think of the goal of flow control is to optimally allocate source rates so as to maximize aggreguate utility subject to capacity constraint. The issue is how to solve this convex program in a distributed manner. Different approaches to solve it leads to different flow control schemes; in other words, flow control can be thought of as a distributed algorithm to solve this convex program. It turns out that one can interpret various flow control algorithms, such as TCP AIMD, Vegas, RED, in this framework. The "congestion measure" in my previous emails is the lagrange multiplier. A view is to think of source rates as primal variables and congestion measures as dual variables, and the various algorithms as different primal-dual (Lagrange) methods to solve the otpimization program. The various schemes differ in a) what is the corresponding dual variable (lagrange multiplier) in the model (loss rate for AIMD/DropTail, queue length for RED, queueing delay for Vegas)? b) how is the dual variable updated? c) how is the primal variable updated? TCP source algorithm (AIMD, Vegas) are particular ways to do c), and AQM (RED,REM) are particular ways to do a) and b). Now, given a problem instance, the *equilibrium value* of the lagrange multiplier is fixed and is independent of the algorithm to reach it (i.e. flow control process). Therefore, if queue is used as the congestion measure, then we have no control on its equilibrium value; it will be high if, say, the number of sources is high. If instead, we compute some number as the congestion measure to which source rates react, then we can update the congestion measure in a way that drives the queue to zero and aggregate input rate to link capacity. How can you do this in networks? Examples are Frank Kelly and Srikant's virtual queue, the "price" in REM, or the probability in Misra's PI controller (which is equivalent to REM). Is this unconventional? Not at all. In economic systems, we set prices to control demand (and supply). When post office is overloaded, we raise price to hire more officers, not throwing away mails to curb demand. There are two limitations in such a simple framework. First these optimization models are convenient to describe only the equilibrium situation. Yet it already gives great insight on how various schemes behave. Even though the real network may always be in transient, it tells us the direction it is moving in. Second, stochastic effects are not captured (but see Kelly's papers). I hope I have not made everything much more confusing by being half precise. To really clear things up, I'd refer you to the followng papers: A Duality Model of TCP flow controls Optimization Flow Control, I: Basic Alg & Convergence Understanding Vegas: a daultiy model REM: Active Queue Management on our website: netlab.caltech.edu and various papers by Kelly, Srikant, Misra, Walrand and Anatharan. Steven julian_satran@il.ibm.com wrote: > > I would be very interested to understand how you see the "virtual-measure", > you are suggesting exists, relate to accepted theory. It is usually > though that high utilization rates and long queues are related (i.e., you > have long queues when utilization goes up) and this is the reason queue > length is used as a measure of congestion. And this is true for all > accepted queueing models. Do you have in mind some "quantum statistics" > for networks that we are all unaware of? Do those have some tunnel effects > that allow you to dream about high utilization AND short queues? Is there > some mathematics that can support your statements? > > Julo > > Julian Satran > IBM Research Lab. at Haifa From hussein@ee.washington.edu Thu Feb 1 16:26:00 2001 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA20591 for ; Thu, 1 Feb 2001 16:26:00 -0800 (PST) Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id QAA21463; Thu, 1 Feb 2001 16:25:50 -0800 (PST) Date: Thu, 1 Feb 2001 16:25:50 -0800 (PST) From: Alhussein Abouzeid To: Steven Low cc: misra@newworld.cs.umass.edu, end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: <3A791D05.2D416AD8@caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 61 Hi Steven, Thanks for the clarifications and replies. I'd like to bring in a relevant issue to discuss in connection to your proposed algorithm. In reference to the exponential packet marking used in REM, and apart from the nicities of it being continuous, and that REM offers much more than just proposing an exponential distribution dropping, my gut feeling is that the exponential distribution is actually the best choice, not because of its mathematical tractability (due to its memorylessness) but out of an engineering/mathematical points of view. The only work I know of that attempted to derive this marking function mathematically, though in an ATM environment, is "A random early discard framework for congestion control in ATM networks", AU: Mokhtar-A; Azizoglu-M, SO: IEEE ATM Workshop '99 Proceedings. Do you have any motivations behind choosing the shape of the marking/dropping function to be exponential, other than mathematical convenience. Indeed, relying on a fixed drop probability profile alone, without making it adaptive in some sense (using optimization-theoretic algorithms like REM or control-theoretic algorithms as Vishal's recent work or any other adaptive fashion) will most definitely result in an abysmal performance. However, in connection with your specific algorithm (REM), the shape of the marking function choice seems (to me, but you should know better) important. So my question in other words is: How would a different choice of the random drop/marking function affect the convergence properties of your algorithm. Regards, Alhussein. From fred@cisco.com Thu Feb 1 16:49:03 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA22758 for ; Thu, 1 Feb 2001 16:49:03 -0800 (PST) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA21384; Thu, 1 Feb 2001 16:48:31 -0800 (PST) Message-Id: <5.0.2.1.2.20010201163134.034476e0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 01 Feb 2001 16:39:44 -0800 To: Michael B Greenwald From: Fred Baker Subject: Re: [e2e] [Fwd: RED-->ECN] Cc: end2end-interest@postel.org, ecn-interest@research.att.com In-Reply-To: <200102011340.f11DeET20308@codex.cis.upenn.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 62 At 08:40 AM 2/1/01 -0500, Michael B Greenwald wrote: >If the input rate is less than the >output rate, then (independent of variations in inter-arrival time) the >queue length is 0 -- always empty. For an arbitrarily low *average* input >rate, and a long enough interval, and an unbounded queue, I can construct >an arrival schedule that will cause an arbitrarily high *average* queue >length. who told you that? I think you'll find that with any distribution, mean queue depth is not a binary flip-flop between zero and infinity. With poisson distributions (M/M/1) and a ratio if input rate to output rate of p and mean service interval m, Kleinrock tells me that the average time in queue (which is to say mean queue depth including the packet itself) p/m W = ----- 1 - p and in the general case average remaining service time W = -------------------------------- 1 - p That's far from a step function. From slow@caltech.edu Thu Feb 1 17:05:43 2001 Received: from imap.cs.caltech.edu (imap.cs.caltech.edu [131.215.44.17]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA24262 for ; Thu, 1 Feb 2001 17:05:43 -0800 (PST) Received: from [131.215.44.217] (HELO caltech.edu) by imap.cs.caltech.edu (CommuniGate Pro SMTP 3.3.1) with ESMTP id 812879; Thu, 01 Feb 2001 17:00:38 -0800 Message-ID: <3A7A0813.F57DA344@caltech.edu> Date: Thu, 01 Feb 2001 17:06:27 -0800 From: Steven Low Reply-To: slow@caltech.edu Organization: Caltech X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alhussein Abouzeid CC: misra@newworld.cs.umass.edu, end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 63 Alhussein > The only work I know of that attempted to derive this marking function > mathematically, though in an ATM environment, is "A random early > discard framework for congestion control in ATM networks", > AU: Mokhtar-A; Azizoglu-M, SO: IEEE ATM Workshop '99 Proceedings. Do you > have any motivations behind choosing the shape of the marking/dropping > function to be exponential, other than mathematical convenience. The motivation came from the abstract algorithm in our ToN paper where congestion is measured at each link by a number we call 'price' and each source needs the aggregate price, summed over all links in the path of the source, to set its rate (window). So the issue becomes how to feed back the *sum* of link prices over the path using a single bit. The trick is to make the *link* marking probability exponential in the link price. Then since the *end to end* marking probability, which is observable at the source, depends on the link marking probabilities in a multiplicative manner, the end2end prob becomes dependent on the *sum* of the prices (which appear in the exponent). In order words, the exponential form exploits the statistical independence of link marking to compute and feed back the *aggregate* price. Details in the paper. Do you know a website where I can download the paper you mentioned? > So my question in other words is: How would a different choice of the > random drop/marking function affect the convergence properties of your > algorithm. Using a linearized model, one can show that the convergence property depends on the marking function only through its derivative at equilibrium. This is true for any AQM, not just REM. Another related point is that the choice of the phi parameter in REM seems to be the trickiest. We do not have theoretical characterization on how to set these parameters, though we have good intuitions from extensive simulations. Steven > > Regards, > > Alhussein. -- __________________________________________________________________ Steven Low, Assoc Prof of CS & EE slow@caltech.edu netlab.caltech.edu Tel: (626) 395-6767 Caltech MC256-80 Fax: (626) 792-4257 Pasadena CA 91125 From hussein@ee.washington.edu Thu Feb 1 18:50:52 2001 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id SAA03628 for ; Thu, 1 Feb 2001 18:50:51 -0800 (PST) Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id SAA05329; Thu, 1 Feb 2001 18:50:48 -0800 (PST) Date: Thu, 1 Feb 2001 18:50:46 -0800 (PST) From: Alhussein Abouzeid To: Fred Baker cc: Michael B Greenwald , end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: <5.0.2.1.2.20010201163134.034476e0@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 64 On Thu, 1 Feb 2001, Fred Baker wrote: > At 08:40 AM 2/1/01 -0500, Michael B Greenwald wrote: > >If the input rate is less than the > >output rate, then (independent of variations in inter-arrival time) the > >queue length is 0 -- always empty. For an arbitrarily low *average* input > >rate, and a long enough interval, and an unbounded queue, I can construct > >an arrival schedule that will cause an arbitrarily high *average* queue > >length. > > who told you that? > > I think you'll find that with any distribution, mean queue depth is not a > binary flip-flop between zero and infinity. With poisson distributions > (M/M/1) and a ratio if input rate to output rate of p and mean service > interval m, Kleinrock tells me that the average time in queue (which is to > say mean queue depth including the packet itself) > > p/m > W = ----- > 1 - p > > and in the general case > > average remaining service time > W = -------------------------------- > 1 - p > > That's far from a step function. > Fred, I agree with your result (that the queue fluctuations are not step from 0 to infinity) but not with the approach. Kleinroch did tell you the above equations, but also said that they are only valid for p<1. If p=1, the system is critically (un)stable and for p>1, the average queue occupancy grows without bound (until buffer overflow). Thus, the key issue here is that we are dealing with a closed queueing system where the input rate is a function of the output rate, and hence I prefer Vishal's reasoning (please refer to his earlier e-mail). Regards, Alhussein. From J.Crowcroft@cs.ucl.ac.uk Fri Feb 2 00:21:36 2001 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id AAA25958 for ; Fri, 2 Feb 2001 00:21:35 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Feb 2001 08:21:00 +0000 To: Luigi Rizzo cc: Bob Braden , J.Crowcroft@cs.ucl.ac.uk, huitema@exchange.microsoft.com, end2end-interest@postel.org, J.Crowcroft@cs.ucl.ac.uk Subject: Re: [e2e] [Fwd: RED-->ECN] In-reply-to: Your message of "Thu, 01 Feb 2001 20:54:25 +0100." <200102011954.UAA56535@info.iet.unipi.it> Date: Fri, 02 Feb 2001 08:21:00 +0000 Message-ID: <10773.981102060@cs.ucl.ac.uk> From: Jon Crowcroft Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 65 tcp is end to end MANY end systems police the NUMBER of TCP conncetiosn you can make fro ma given address - try downloading from redhat for example:-) In message <200102011954.UAA56535@info.iet.unipi.it>, Luigi Rizzo typed: >>> Christian, >>> >>> Unhh, maybe because the Internet is heterogeneous, and some parts of it >>> will always have 4% loss rates rather than .01%? >>> >>> It is unclear whether your interesting observation is a bug, as you >>> suggest, or rather a feature that results from the basic packet physics. >>> Why is it a bad thing if users can optimize their service by opening >>> multiple TCP connections? >> >>because depending on the number of connections the dynamics of the >>set of tcp connections change from AIMD to MIMD to no-congestion-control >>as below: >> >> HTTP head request to get file_size # 2 RTT >> n = file_size / initial_window ; >> for i = 0 to n-1 do >> # all this in parallel, 2RTT + n*fork delay >> get a chunk of size initial_window at offset i*initial_window & >> done >> >>and voila. total 4RTT, no cong.control, fully compliant TCP. >>(i don't remember if christian's model assumed that the loss >>changes with the number of connections, but probably not. ) >> >> cheers >> luigi >>----------------------------------+----------------------------------------- >> Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) >> http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 >> Phone (510) 666 2927 . >>----------------------------------+----------------------------------------- cheers jon From mbgreen@dsl.cis.upenn.edu Fri Feb 2 02:00:36 2001 Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id CAA02771 for ; Fri, 2 Feb 2001 02:00:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.10.1/8.10.1) with SMTP id f12A0VT00912; Fri, 2 Feb 2001 05:00:31 -0500 (EST) Message-Id: <200102021000.f12A0VT00912@codex.cis.upenn.edu> To: Fred Baker cc: Michael B Greenwald , end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] In-reply-to: Your message of "Thu, 01 Feb 2001 16:39:44 PST." <5.0.2.1.2.20010201163134.034476e0@flipper.cisco.com> Date: Fri, 02 Feb 2001 05:00:30 EST From: Michael B Greenwald Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 66 Thu, 01 Feb 2001 16:39:44 -0800 Fred Baker At 08:40 AM 2/1/01 -0500, Michael B Greenwald wrote: >If the input rate is less than the >output rate, then (independent of variations in inter-arrival time) the >queue length is 0 -- always empty. For an arbitrarily low *average* input >rate, and a long enough interval, and an unbounded queue, I can construct >an arrival schedule that will cause an arbitrarily high *average* queue >length. who told you that? No one; it is trivially true (and rather uninteresting, and irrelevant except as a pedagogic example showing that avg qlen is not *purely* a function of input and output rates; qlen is also a function of the burstiness). I think you may have misread what I wrote because (a) what you write below doesn't contradict what I said --- it's just orthogonal to it, and (b) I never said anything about a step function. The fault may be mine because I thought I was quickly dashing off an obvious point, and in my haste I was probably unclear. If the max input rate is lower than the *constant* output rate, then I can't produce any queue size at all (because whenever a packet arrives, the previous packet was already drained from the queue), so it is uninteresting. If the avg input rate is higher than the avg output rate, the queue length grows without bound, so it is also uninteresting. But, assuming the max input burst rate exceeds the constant output rate, and the avg input rate is less than the avg output rate, then no matter what non-zero avg input and output rates you give me, I can produce a *particular* schedule in which the average queue length can be any size Q you desire (provided the queue was unbounded and I could look at the queue over a long enough time interval). Let the output process drain the queue at a constant rate O, and let the input process deliver bursts at rate I, producing a burst every t time units. Burst size must = I*t. Assume this results in an avg qlen of q. Send a burst of size (Q/q)I*t every (Q/q)*t time units, this will result in avg qlen of Q for input rate I and output rate O. As I said, these are unrealistic examples, intended only to quibble with the message that asserted that average queue length was purely a function of input rates (actually, they said "utilization"). I think you'll find that with any distribution, mean queue depth is not a binary flip-flop between zero and infinity. With poisson distributions (M/M/1) and a ratio if input rate to output rate of p and mean service interval m, Kleinrock tells me that the average time in queue (which is to say mean queue depth including the packet itself) p/m W = ----- 1 - p and in the general case average remaining service time W = -------------------------------- 1 - p That's far from a step function. From Derek.Mcauley@marconi.com Fri Feb 2 02:51:34 2001 Received: from headoffice10_fs ([194.128.74.8]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id CAA05776 for ; Fri, 2 Feb 2001 02:51:32 -0800 (PST) Received: FROM headoffice03_fs.headoffice.gecplc.com BY headoffice10_fs ; Fri Feb 02 10:47:50 2001 0000 Received: by HEADOFFICE03_FS with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Feb 2001 10:50:37 -0000 Message-ID: <66ADEEFA234AD4119AA600D0B7741E3A0135B828@HEADOFFICE03_FS> From: "Mcauley, Derek" To: end2end-interest@postel.org Subject: RE: [e2e] [Fwd: RED-->ECN] Date: Fri, 2 Feb 2001 10:50:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 67 It costs $25 http://www.metaproducts.com/MD.html Yours a user, Mac. -----Original Message----- From: Jon Crowcroft [mailto:J.Crowcroft@cs.ucl.ac.uk] Sent: 02 February 2001 08:21 To: Luigi Rizzo Cc: Bob Braden; J.Crowcroft@cs.ucl.ac.uk; huitema@exchange.microsoft.com; end2end-interest@postel.org; J.Crowcroft@cs.ucl.ac.uk Subject: Re: [e2e] [Fwd: RED-->ECN] tcp is end to end MANY end systems police the NUMBER of TCP conncetiosn you can make fro ma given address - try downloading from redhat for example:-) In message <200102011954.UAA56535@info.iet.unipi.it>, Luigi Rizzo typed: >>> Christian, >>> >>> Unhh, maybe because the Internet is heterogeneous, and some parts of it >>> will always have 4% loss rates rather than .01%? >>> >>> It is unclear whether your interesting observation is a bug, as you >>> suggest, or rather a feature that results from the basic packet physics. >>> Why is it a bad thing if users can optimize their service by opening >>> multiple TCP connections? >> >>because depending on the number of connections the dynamics of the >>set of tcp connections change from AIMD to MIMD to no-congestion-control >>as below: >> >> HTTP head request to get file_size # 2 RTT >> n = file_size / initial_window ; >> for i = 0 to n-1 do >> # all this in parallel, 2RTT + n*fork delay >> get a chunk of size initial_window at offset i*initial_window & >> done >> >>and voila. total 4RTT, no cong.control, fully compliant TCP. >>(i don't remember if christian's model assumed that the loss >>changes with the number of connections, but probably not. ) >> >> cheers >> luigi >>----------------------------------+--------------------------------------- -- >> Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) >> http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 >> Phone (510) 666 2927 . >>----------------------------------+--------------------------------------- -- cheers jon From mascolo@poliba.it Fri Feb 2 04:12:43 2001 Received: from cstar.poliba.it (IDENT:root@cstar.poliba.it [193.204.49.36]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id EAA11565 for ; Fri, 2 Feb 2001 04:12:42 -0800 (PST) Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by cstar.poliba.it (8.11.0/8.11.0) with SMTP id f12CCQO05219; Fri, 2 Feb 2001 13:12:26 +0100 Message-ID: <014301c08d11$7237e4c0$723bccc1@poliba.it> From: "Saverio Mascolo" To: , References: <3A7A0813.F57DA344@caltech.edu> Date: Fri, 2 Feb 2001 13:12:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [e2e] setting RED parameters to compare with ECN Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 68 Hi all, in the paper "TCP and explicit congestion notification" by S. Floyd is written: " In our simulation with RED gateways, the minimum threshold for the average queue size is set to 1/12-th of the buffer size, and the maximum threshold is set to three times the minimum threshold. The RED gateways drop all arriving packets when the average queue size exceeds the maximum threshold" I think that RED should drop all arriving packets only when the average queue size exceeds the maximum buffer size, i.e. never. In other words the dropping probability should be one only when the queue is full (drop tail behavior). Why should we enforce 100% dropping if the queue is not full? -Saverio From shivkuma@ra.ecse.rpi.edu Fri Feb 2 04:25:03 2001 Received: from ra.ecse.rpi.edu (ra.ecse.rpi.edu [128.113.61.205]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id EAA12566 for ; Fri, 2 Feb 2001 04:25:03 -0800 (PST) Received: from localhost (shivkuma@localhost) by ra.ecse.rpi.edu (8.9.2/8.9.2) with SMTP id HAA21728; Fri, 2 Feb 2001 07:25:53 -0500 (EST) Date: Fri, 2 Feb 2001 07:25:52 -0500 (EST) From: Shivkumar Kalyanaraman To: Saverio Mascolo cc: end2end-interest@postel.org, ecn-interest@research.att.com In-Reply-To: <014301c08d11$7237e4c0$723bccc1@poliba.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [e2e] Re: setting RED parameters to compare with ECN Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 69 There is a new gentle_RED variant around for a while which does not do that... http://www.aciri.org/floyd/red/gentle.html -Shiv === Shivkumar Kalyanaraman Asst. Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI) On Fri, 2 Feb 2001, Saverio Mascolo wrote: > Hi all, > > in the paper "TCP and explicit congestion notification" by S. Floyd is > written: > > " In our simulation with RED gateways, the minimum threshold for the average > queue size is set to 1/12-th of the buffer size, and the maximum threshold > is set to three times the minimum threshold. The RED gateways drop all > arriving packets when the average queue size exceeds the maximum threshold" > > I think that RED should drop all arriving packets only when the average > queue size exceeds the maximum buffer size, i.e. never. In other words the > dropping probability should be one only when the queue is full (drop tail > behavior). Why should we enforce 100% dropping if the queue is not full? > > -Saverio > > From michael_liaocn@yahoo.com Fri Feb 2 05:46:14 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id FAA18038 for ; Fri, 2 Feb 2001 05:46:14 -0800 (PST) Received: from web9901.mail.yahoo.com (web9901.mail.yahoo.com [216.136.129.36]) by tnt.isi.edu (8.11.1/8.11.1) with SMTP id f12DkDU19829 for ; Fri, 2 Feb 2001 05:46:13 -0800 (PST) Message-ID: <20010202134613.80525.qmail@web9901.mail.yahoo.com> Received: from [207.46.71.11] by web9901.mail.yahoo.com; Fri, 02 Feb 2001 05:46:13 PST Date: Fri, 2 Feb 2001 05:46:13 -0800 (PST) From: Michael Liao To: end2end-interest@ISI.EDU MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [e2e] how to trace TCP congestion window accurately? Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 70 Hi, folks Tracing TCP congestion window is a hard task, especially at the intermediate node (such as router), but is there someone who can provide me with links to documents on tracing TCP congestion window at routers? Thanks a lot in advance, and with best regards... Michael L. 02/02/2001 __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From minshall@redback.com Fri Feb 2 09:39:28 2001 Received: from smtp1.zocalo.net (smtp1.zocalo.net [157.22.1.67]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA09416 for ; Fri, 2 Feb 2001 09:39:28 -0800 (PST) Received: from red.redback.com (66.161.131.zocalo.net [131.161.253.66] (may be forged)) by smtp1.zocalo.net (8.9.1/8.9.1) with ESMTP id JAA05701; Fri, 2 Feb 2001 09:39:24 -0800 (PST) Received: from red.redback.com by red.redback.com (8.9.3) id JAA57532; Fri, 2 Feb 2001 09:39:21 -0800 (PST) Message-Id: <200102021739.JAA57532@red.redback.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alhussein Abouzeid cc: Steven Low , end2end-interest@postel.org Subject: Re: [e2e] [Fwd: RED-->ECN] In-reply-to: Your message of "Wed, 31 Jan 2001 20:09:23 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Feb 2001 09:39:21 -0800 From: Greg Minshall Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 71 there's a point here i've been mistaken on in the past, and though it is only a small thing, it is perhaps worth pointing out. > However, the average queue size need not be the only measure of > congestion. Indeed, some recent works suggested measuring the arrival rate > directly (using some filter to smooth out transients) and using this as > the measure of congestion. In some sense, such schemes attempts to achieve > the rightful objective you mentioned; decide whether demand exceeds > capacity. Both approaches (queue-based or rate-based) have some problems > that are too involved to detail here. i used to think that measuring average queue size was really just a proxy for measuring average arrival rate. however, V. Jacobson, K. Nichols, and K. Poduri have pointed out that the arrival rate might equal the link bandwidth (their example uses TCP ACK clocking, so no new packets show up until old ones leave), but there may still be a standing queue. thus, if i had been measuring arrival rate, i would have decided "no need to drop [mark] packets". whereas, i should have been measuring (and seeing) a standing queue and decided "i need to drop [mark] packets". cheers, Greg Minshall From isidro@yarilo.pluris.com Fri Feb 2 10:17:55 2001 Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA14501 for ; Fri, 2 Feb 2001 10:17:55 -0800 (PST) Received: from taiyan.pluris.com (taiyan.pluris.com [172.16.55.16]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA28192; Fri, 2 Feb 2001 10:17:44 -0800 (PST) Received: (from isidro@localhost) by taiyan.pluris.com (8.9.1b+Sun/8.8.8) id KAA10594; Fri, 2 Feb 2001 10:17:33 -0800 (PST) To: Michael B Greenwald Cc: Fred Baker , end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] References: <200102021000.f12A0VT00912@codex.cis.upenn.edu> From: Isidro Castineyra Date: 02 Feb 2001 10:17:33 -0800 In-Reply-To: Michael B Greenwald's message of "Fri, 02 Feb 2001 05:00:30 EST" Message-ID: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 72 Michael B Greenwald writes: > If the max input rate is lower than the *constant* output rate, then I > can't produce any queue size at all (because whenever a packet arrives, the > previous packet was already drained from the queue), so it is > uninteresting. This would be true if the time between packet arrivals was constant. When the inter-arrival time is variable (or the size of the packets is variable, or both), a queue will form even if the average input rate is lower than the average output rate -- -- Isidro Castineyra isidro@pluris.com (408) 861-3352 From mbgreen@dsl.cis.upenn.edu Fri Feb 2 10:38:06 2001 Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA17397 for ; Fri, 2 Feb 2001 10:38:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.10.1/8.10.1) with SMTP id f12IbxT05454; Fri, 2 Feb 2001 13:37:59 -0500 (EST) Message-Id: <200102021837.f12IbxT05454@codex.cis.upenn.edu> To: Isidro Castineyra cc: Michael B Greenwald , Fred Baker , end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] In-reply-to: Your message of "02 Feb 2001 10:17:33 PST." Date: Fri, 02 Feb 2001 13:37:58 EST From: Michael B Greenwald Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 73 02 Feb 2001 10:17:33 -0800 Isidro Castineyra Michael B Greenwald writes: > If the max input rate is lower than the *constant* output rate, then I > can't produce any queue size at all (because whenever a packet > arrives, the previous packet was already drained from the queue), so > it is uninteresting. This would be true if the time between packet arrivals was constant. When the inter-arrival time is variable (or the size of the packets is variable, or both), a queue will form even if the average input rate is lower than the average output rate Sigh. Note that I said *max* input rate, not avg. This bounds the smallest allowable inter-arrival time. This whole subject is both a minor point about an artificial example; I'm glad to continue discussing it, but no need to clutter up e2e. If other people want to talk to me about this, or correct me, or whatever, remove e2e/ecn. Thanks. From jcobb@utdallas.edu Fri Feb 2 14:35:34 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA20306 for ; Fri, 2 Feb 2001 14:35:34 -0800 (PST) From: jcobb@utdallas.edu Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f12MZYU01318 for ; Fri, 2 Feb 2001 14:35:34 -0800 (PST) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 1FEF91A0284 for ; Fri, 2 Feb 2001 16:35:32 -0600 (CST) Received: (from jcobb@localhost) by apache.utdallas.edu (8.9.1/8.9.1) id QAA04939 for end2end-interest@isi.edu; Fri, 2 Feb 2001 16:35:31 -0600 (CST) Date: Fri, 2 Feb 2001 16:35:31 -0600 (CST) Message-Id: <200102022235.QAA04939@apache.utdallas.edu> To: end2end-interest@ISI.EDU Subject: [e2e] ISADS 2001 Call for Participation Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 74 (* our apologies if you receive multiple copies *) ISADS 2001 CALL FOR PARTICIPATION The Fifth International Symposium on Autonomous Decentralized Systems Monday March 26 - Wednesday March 28, 2001 Dallas, Texas, USA http://isads.utdallas.edu Sponsored by: IEEE Computer Society Information Processing Society of Japan The Society of Instrument and Control Engineers of Japan The Institute of Electronics, Infor. and Communication Engineers, Japan In Cooperation with: International Federation for Information Processing International Federation of Automatic Control OMG TINA-C Manufacturing Science and Technology Center, Japan Scope: Driven by the continuous growth in the power, intelligence and openness of computer, communication and control technologies, possibilities and opportunities for realizing highly efficient and dependable business and control systems have been steadily increasing. Dynamically changing social and economic situations demand next-generation systems based on emerging technologies and applications. Such systems are expected to have the characteristics of living systems composed of largely autonomous and decentralized components. Such systems are called Autonomous Decentralized Systems (ADS). After four successful symposiums, the Fifth International Symposium on Autonomous Decentralized Systems (ISADS) will be held in Dallas, Texas, USA during March 26-28, 2001. While ISADS 2001 will primarily focus on advancements and innovation in the ADS concept, technologies and applications related to the increasingly important topic of *Electronic Commerce* are also included. The symposium features 13 paper sessions and seven panel sessions, whose titles are below. In addition to the paper and panel sessions, the following events have been organized. * Reception (March 26) * Banquet (March 27) * A tour and dinner at the famous Southfork Ranch of Dallas (March 28). * A plant tour of two telecommunication companies in the Dallas area, Alcatel and Nortel (March 29). For general information, including registration, see our World-Wide Web Page at: http://isads.utdallas.edu Important Deadlines: *March 1, 2001 - Deadline for early registration *March 2, 2001, 5:00 p.m. central time - Any reservation at the conference hotel received after the cut-off date will be accepted based on space availability Paper Sessions: *E-commerce Models and Protocols *High Assurance Systems *Fault Tolerance and Safety Critical Systems *Architecture and Models for Distributed Systems *E-commerce Technology and Architecture *Distributed Object Management Systems *Short Papers: Distributed Object Management and Control *Multiagent systems *Middleware Technologies *Agent Technology for E-commerce *Self Stabilizing Systems *Secure Systems and Applications *Modeling and Performance Panel Sessions: *XML and E-Business Frameworks *Agent-Based Electronic Commerce: Opportunities and Challenges *Embedded Systems *Mobile Computing and Communication *Robotics for Education and Entertainment *Security for the Web and E-Commerce Systems *Plenary closing panel: Future of Autonomous Decentralized Systems From slow@caltech.edu Fri Feb 2 15:09:06 2001 Received: from imap.cs.caltech.edu (imap.cs.caltech.edu [131.215.44.17]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA24409 for ; Fri, 2 Feb 2001 15:09:06 -0800 (PST) Received: from [131.215.44.217] (HELO caltech.edu) by imap.cs.caltech.edu (CommuniGate Pro SMTP 3.3.1) with ESMTP id 813660; Fri, 02 Feb 2001 15:04:01 -0800 Message-ID: <3A7B3E3B.80DA4719@caltech.edu> Date: Fri, 02 Feb 2001 15:09:47 -0800 From: Steven Low Reply-To: slow@caltech.edu Organization: Caltech X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Minshall CC: Alhussein Abouzeid , end2end-interest@postel.org, ecn-interest@research.att.com Subject: Re: [e2e] [Fwd: RED-->ECN] References: <200102021739.JAA57532@red.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 75 > i used to think that measuring average queue size was really just a proxy for > measuring average arrival rate. > > however, V. Jacobson, K. Nichols, and K. Poduri have pointed out that the > arrival rate might equal the link bandwidth (their example uses TCP ACK > clocking, so no new packets show up until old ones leave), but there may still > be a standing queue. > > thus, if i had been measuring arrival rate, i would have decided "no need to > drop [mark] packets". whereas, i should have been measuring (and seeing) a > standing queue and decided "i need to drop [mark] packets". > > cheers, Greg Minshall Indeed. When input rate equals the output rate in equilibrium, any (equilibrium) queue length is compatible, because rate of change of queue = input rate - output rate = 0 This means one can attmpt to match input to output rate, and achieve, in equilibrium, full utilizaiton when the queue length stabilizes. The value at which the queue stabilizes depends on the *process*, i.e., depends on how we do congestion control (TCP/AQM), especially AQM. In REM, the congestion measure (a number we call 'price') is incremented when the weighted sum of rate mismatch (input rate - output rate) and queue mismatch (current queue - target queue, target may be 0) is positive, and decremented otherwise. When the weighted sum is postive, it means either input rate exceeds output rate, or there is a large queue to be cleared, or both. So REM is striving to drive this weighted sum of mismatches to zero, and it can be zero (in equilibrium) *if and only if* the both mismatches are zero, i.e. input rate = output rate and queue = target. This is how REM achieves high utilization and low queue in equilibrium. Steven -- __________________________________________________________________ Steven Low, Assoc Prof of CS & EE slow@caltech.edu netlab.caltech.edu Tel: (626) 395-6767 Caltech MC256-80 Fax: (626) 792-4257 Pasadena CA 91125 From hollot@ecs.umass.edu Sat Feb 3 06:55:56 2001 Received: from snail.ecs.umass.edu (snail.ecs.umass.edu [128.119.91.94]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id GAA00139 for ; Sat, 3 Feb 2001 06:55:55 -0800 (PST) Received: from kira.ecs.umass.edu (dialup-14.ecs.umass.edu [128.119.86.164]) by snail.ecs.umass.edu (8.9.3+Sun/8.9.3) with SMTP id JAA22889; Sat, 3 Feb 2001 09:55:31 -0500 (EST) Message-Id: <3.0.32.20010203100118.02ab1560@pop.ecs.umass.edu> X-Sender: hollot@pop.ecs.umass.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 03 Feb 2001 10:01:30 -0500 To: slow@caltech.edu From: "C.V. Hollot" Subject: Re: [e2e] [Fwd: RED-->ECN] Cc: Greg Minshall , Alhussein Abouzeid , end2end-interest@postel.org, ecn-interest@research.att.com, misra@gaia.cs.umass.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 76 At 03:09 PM 2/2/01 -0800, Steven Low wrote: > >> i used to think that measuring average queue size was really just a proxy for >> measuring average arrival rate. >> >> however, V. Jacobson, K. Nichols, and K. Poduri have pointed out that the >> arrival rate might equal the link bandwidth (their example uses TCP ACK >> clocking, so no new packets show up until old ones leave), but there may still >> be a standing queue. >> >> thus, if i had been measuring arrival rate, i would have decided "no need to >> drop [mark] packets". whereas, i should have been measuring (and seeing) a >> standing queue and decided "i need to drop [mark] packets". >> >> cheers, Greg Minshall > >Indeed. When input rate equals the output rate in equilibrium, any >(equilibrium) >queue length is compatible, because > rate of change of queue = input rate - output rate = 0 >This means one can attmpt to match input to output rate, and achieve, in >equilibrium, >full utilizaiton when the queue length stabilizes. The value at which >the queue >stabilizes depends on the *process*, i.e., depends on >how we do congestion control (TCP/AQM), especially AQM. > >In REM, the congestion measure (a number we call 'price') is incremented >when >the weighted sum of rate mismatch (input rate - output rate) and queue >mismatch (current queue - target queue, target may be 0) is positive, >and >decremented otherwise. When the weighted sum is postive, it means >either input >rate exceeds output rate, or there is a large queue to be cleared, or >both. >So REM is striving to drive this weighted sum of mismatches to zero, and >it can >be zero (in equilibrium) *if and only if* the both mismatches are zero, >i.e. > input rate = output rate and queue = target. >This is how REM achieves high utilization and low queue in equilibrium. > >Steven > another point about measuring (and using) average queue size to mark packets: average queue size does contain (perhaps useful) information about instantaneous queue length and arrival rate. The real question is how to act on this information. If we use this averaged info to mark packets, then we are (implicilty) closing a feedback loop around "stale (averaged)" information. Queue averaging introduces additional time (phase) delay to the feedback (in addition to queuing and propagation delays)- and we know that delayed feedback contributes to poor and even unstable feedback behavior. For example, consider the task of controlling the level of water in your bath tub if you could only measure the "average level of water." In my opinion it is better to measure instantaneous queue length, and then, with a dynamic model of TCP/AQM in hand, develop AQM algorithms (based on instantaneous queue length) to achieve network performance objectives. for more details on TCP/AQM modelling and PI control see http://www-net.cs.umass.edu/~misra/ cvh -------------------------------------------------- C.V. Hollot Associate Professor ECE Department University of Massachusetts Amherst, MA 01003 ph: 413.545.1586 fax: 413.545.1993 From mascolo@poliba.it Sat Feb 3 07:21:39 2001 Received: from cstar.poliba.it (IDENT:root@cstar.poliba.it [193.204.49.36]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id HAA01801 for ; Sat, 3 Feb 2001 07:21:38 -0800 (PST) Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by cstar.poliba.it (8.11.0/8.11.0) with SMTP id f13FLBO15337; Sat, 3 Feb 2001 16:21:11 +0100 Message-ID: <001f01c08df4$e6269a00$723bccc1@poliba.it> From: "Saverio Mascolo" To: , "C.V. Hollot" Cc: "Greg Minshall" , "Alhussein Abouzeid" , , , References: <3.0.32.20010203100118.02ab1560@pop.ecs.umass.edu> Subject: R: [e2e] [Fwd: RED-->ECN] Date: Sat, 3 Feb 2001 16:20:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 77 What Hollot says is right. Averaging the queue makes much more difficult to control the queue level. In control terms is like to add another pole in the feedback loop. An interesting paper is also "Reasons not to deploy RED" by J. Bolot et. al. ( at http://citeseer.nj.nec.com/337634.html). This paper experiments average vs. instantaneous queue RED dropping. -s ----- Original Message ----- From: C.V. Hollot To: Cc: Greg Minshall ; Alhussein Abouzeid ; ; ; Sent: Saturday, February 03, 2001 4:01 PM Subject: Re: [e2e] [Fwd: RED-->ECN] > another point about measuring (and using) average queue size to mark packets: > average queue size does contain (perhaps useful) information about > instantaneous queue length and arrival rate. The real question is how to > act on this information. If we use this averaged info to mark packets, > then we are (implicilty) closing a feedback loop around "stale (averaged)" > information. > Queue averaging introduces additional time (phase) delay to the feedback > (in addition to queuing and propagation delays)- and we know that delayed > feedback contributes to poor and even unstable feedback behavior. > For example, consider the task of controlling the level of water in your > bath tub if you could only measure the "average level of water." > > In my opinion it is better to measure instantaneous queue length, and then, > with a dynamic model of TCP/AQM in hand, develop AQM algorithms (based on > instantaneous queue length) to achieve network performance objectives. > for more details on TCP/AQM modelling and PI control see > http://www-net.cs.umass.edu/~misra/ > > > cvh > -------------------------------------------------- > > C.V. Hollot > Associate Professor > ECE Department > University of Massachusetts > Amherst, MA 01003 > ph: 413.545.1586 > fax: 413.545.1993 > From floyd@elk.aciri.org Sat Feb 3 09:42:33 2001 Received: from elk.aciri.org (elk.aciri.org [192.150.187.21]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA10282 for ; Sat, 3 Feb 2001 09:42:33 -0800 (PST) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.11.1/8.11.1) with ESMTP id f13HgW555977 for ; Sat, 3 Feb 2001 09:42:32 -0800 (PST) (envelope-from floyd@elk.aciri.org) Message-Id: <200102031742.f13HgW555977@elk.aciri.org> To: end2end-interest@postel.org From: Sally Floyd Subject: Re: [e2e] [Fwd: RED-->ECN] Date: Sat, 03 Feb 2001 09:42:32 -0800 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 78 Please don't copy postings on this thread to both end2end-interest and ecn-interest, but just restrict it to end2end-interest. I am sure that anyone who is interested is already subscribed to end2end-interest, and it is bad form to clutter up people's mail boxes. Thanks, - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From hussein@ee.washington.edu Sat Feb 3 13:34:27 2001 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id NAA24855 for ; Sat, 3 Feb 2001 13:34:27 -0800 (PST) Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id NAA08910; Sat, 3 Feb 2001 13:34:13 -0800 (PST) Date: Sat, 3 Feb 2001 13:34:12 -0800 (PST) From: Alhussein Abouzeid To: "C.V. Hollot" cc: slow@caltech.edu, Greg Minshall , end2end-interest@postel.org, misra@gaia.cs.umass.edu, Saverio Mascolo Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: <3.0.32.20010203100118.02ab1560@pop.ecs.umass.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 79 The I in the PI controller is "Integrator", which is some sort of averaging. Just like the averaging of the queue size, a PI controller does introduce delay in the feedback (another pole as Saverio said), and it is some sort of averaging, right? You can on the other hand add a D controller (a zero). In all cases, you will end up optimizing responsiveness and unstability (KD) versus sluggishness and stability (I). The virtue of solving the problem using classical control approach is its simplicity, accuracy and insights, allowing one to bring in a well known set of control-theoretic tools to solve the problem, as you did in your Infocom papers, rather than using ad-hoc attempts to adjust the controller parameters. -Alhussein. On Sat, 3 Feb 2001, C.V. Hollot wrote: > At 03:09 PM 2/2/01 -0800, Steven Low wrote: > > > >> i used to think that measuring average queue size was really just a > proxy for > >> measuring average arrival rate. > >> > >> however, V. Jacobson, K. Nichols, and K. Poduri have pointed out that the > >> arrival rate might equal the link bandwidth (their example uses TCP ACK > >> clocking, so no new packets show up until old ones leave), but there may > still > >> be a standing queue. > >> > >> thus, if i had been measuring arrival rate, i would have decided "no > need to > >> drop [mark] packets". whereas, i should have been measuring (and seeing) a > >> standing queue and decided "i need to drop [mark] packets". > >> > >> cheers, Greg Minshall > > > >Indeed. When input rate equals the output rate in equilibrium, any > >(equilibrium) > >queue length is compatible, because > > rate of change of queue = input rate - output rate = 0 > >This means one can attmpt to match input to output rate, and achieve, in > >equilibrium, > >full utilizaiton when the queue length stabilizes. The value at which > >the queue > >stabilizes depends on the *process*, i.e., depends on > >how we do congestion control (TCP/AQM), especially AQM. > > > >In REM, the congestion measure (a number we call 'price') is incremented > >when > >the weighted sum of rate mismatch (input rate - output rate) and queue > >mismatch (current queue - target queue, target may be 0) is positive, > >and > >decremented otherwise. When the weighted sum is postive, it means > >either input > >rate exceeds output rate, or there is a large queue to be cleared, or > >both. > >So REM is striving to drive this weighted sum of mismatches to zero, and > >it can > >be zero (in equilibrium) *if and only if* the both mismatches are zero, > >i.e. > > input rate = output rate and queue = target. > >This is how REM achieves high utilization and low queue in equilibrium. > > > >Steven > > > > another point about measuring (and using) average queue size to mark packets: > average queue size does contain (perhaps useful) information about > instantaneous queue length and arrival rate. The real question is how to > act on this information. If we use this averaged info to mark packets, > then we are (implicilty) closing a feedback loop around "stale (averaged)" > information. > Queue averaging introduces additional time (phase) delay to the feedback > (in addition to queuing and propagation delays)- and we know that delayed > feedback contributes to poor and even unstable feedback behavior. > For example, consider the task of controlling the level of water in your > bath tub if you could only measure the "average level of water." > > In my opinion it is better to measure instantaneous queue length, and then, > with a dynamic model of TCP/AQM in hand, develop AQM algorithms (based on > instantaneous queue length) to achieve network performance objectives. > for more details on TCP/AQM modelling and PI control see > http://www-net.cs.umass.edu/~misra/ > > > cvh > -------------------------------------------------- > > C.V. Hollot > Associate Professor > ECE Department > University of Massachusetts > Amherst, MA 01003 > ph: 413.545.1586 > fax: 413.545.1993 > From misra@newworld.cs.umass.edu Sat Feb 3 14:10:24 2001 Received: from newworld.cs.umass.edu (IDENT:root@newworld.cs.umass.edu [128.119.245.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA27183 for ; Sat, 3 Feb 2001 14:10:23 -0800 (PST) Received: from nissar.cs.umass.edu (IDENT:misra@nissar.cs.umass.edu [128.119.245.97]) by newworld.cs.umass.edu (8.9.3/8.8.8) with ESMTP id RAA27389; Sat, 3 Feb 2001 17:10:20 -0500 Date: Sat, 3 Feb 2001 17:10:20 -0500 (EST) From: Vishal Misra X-Sender: misra@nissar.cs.umass.edu To: Alhussein Abouzeid cc: end2end-interest@postel.org, "C.V. Hollot" Subject: Re: [e2e] [Fwd: RED-->ECN] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 80 On Sat, 3 Feb 2001, Alhussein Abouzeid wrote: > > The I in the PI controller is "Integrator", which is some sort of > averaging. Just like the averaging of the queue size, a PI controller does > introduce delay in the feedback (another pole as Saverio said), and it is > some sort of averaging, right? The pole is at 0. The PI controller also has a zero, which is at a frequency higher than 0. > You can on the other hand add a D controller (a zero). In all cases, > you will end up optimizing responsiveness and unstability (KD) versus > sluggishness and stability (I). The PI controller is the P controller and I controller summed up in parallel, something like (in the Laplace domain, with gains k1 and k2) |-------[k1 P]------| (q-q_ref) -------| +---- p |-------[k2 I]------| This gives the transfer function between the error signal (q-q_ref) and the marking probability p. Call q - q_ref = q~ so p(s) = k1*q~(s)+k2*q~(s)/s you can conceptually think of that as p(s) = (s*k1(q~)+k2(q~(s))/s, which is ^ ^ ^ D P \int i.e. a D term and a P term going into an integrator (a queue). The classic Lindley equation for the queue then gives p(t+1) (new queue) in terms of the [total arrival+old queue]+. The feedback control will drive the total arrival to zero, i.e. q~-> 0, which means target buffer size is met and (q~)' -> 0, which implies that the rates are matched (this is also the "clear buffer, match rate" scheme of REM). At that point, the marking probability would have converged giving p(t+1) = [0+p(t)]+ -Vishal From F.P.Kelly@statslab.cam.ac.uk Sun Feb 4 05:39:34 2001 Received: from cougar.statslab.cam.ac.uk (exim@cougar.statslab.cam.ac.uk [131.111.20.6]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id FAA22559 for ; Sun, 4 Feb 2001 05:39:33 -0800 (PST) Received: from frank by cougar.statslab.cam.ac.uk with local (Exim 1.82 #2) id 14PPO7-0002dF-00; Sun, 4 Feb 2001 13:39:31 +0000 To: end2end-interest@postel.org Date: Sun, 4 Feb 2001 13:39:31 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Frank Kelly Subject: [e2e] RED-->ECN Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 82 If RED/ECN succeed in achieving smaller queue sizes, then fluctuations in queue sizes may become so fast that only some form of average is relevant for the stability of feedback control loops that include propagation delays. Should the averaging be done at the queues or at the end-systems? An advantage of using end-systems is that it is then easier to relate the time-constants implicit in any averaging to propagation delays. Some references on the impact of propagation delays on network stability are End-to-End Congestion Control for the Internet: Delays and Stability by R. Johari and D. Tan http://www.statslab.cam.ac.uk/cgi-bin/resreps.pl?term=2000-2&field=number Stability of Distributed Congestion Control with Heterogeneous Feedback Delays by L. Massoulie http://research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-111 Frank Kelly ------------------------------------------ web: www.statslab.cam.ac.uk/~frank/ email: f.p.kelly@statslab.cam.ac.uk ------------------------------------------ From campbell@comet.columbia.edu Sun Feb 4 21:09:56 2001 Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id VAA23305 for ; Sun, 4 Feb 2001 21:09:55 -0800 (PST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with SMTP id AAA23475; Mon, 5 Feb 2001 00:09:53 -0500 (EST) From: "Andrew T. Campbell" To: Cc: "Andrew Campbell \(E-mail\)" Date: Mon, 5 Feb 2001 00:08:45 -0800 Message-ID: <000601c08f4a$dcf1cd40$3d443b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [e2e] OPENARCH'01 Advanced Program Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 83 OPENARCH'01 Advanced Program The Fourth IEEE Conference on Open Architectures and Network Programming (OPENARCH) http://www.openarch.org/ April 27-28, Hilton Anchorage Hotel, Anchorage, Alaska Sponsored by the IEEE Communications Society Platinum Supporters Intel Corporation and Nortel Networks -------------------------------------------------------------------- PROGRAM AT A GLANCE OPENARCH is single-track format providing researchers, developers, and service providers with a focused, highly interactive opportunity to present, discuss, and absorb current work and future directions in active and programmable networks Keynote Speakers ---------------- Jonathan S. Turner, Washington University in Saint Louis Jeff Lawrence, CTO, Network Communications Group, Intel Panels ------ "Peer-to-Peer Overlays: Active Network Prospect or Challenger?" Organizer: David Wetherall, Asta Networks and University of Washington Panelists: Larry Peterson, Princeton University, Joe Touch and Bob Braden, USC ISI "Network Architectures in the Optical Age" Organizer: Aurel A. Lazar, Xbind Inc. and Columbia University Panelist: to be announced Conference Invited Talk ----------------------- Reflective Middleware Geoff Coulson, Lancaster University and Columbia University Paper Sessions -------------- Programmable Router Architectures Active Multicast Services Security Issues in Active Networks Programmable Networks Constructing Services Hot Topics Session Organizer: Christian Tchudin, Uppsala University http://www.openarch.org/2001_short.html CFP: Submission deadline Feb 9, 2001 OPENARCH is sponsored by the IEEE Communications Society and is co-located and organized in conjunction with INFOCOM. For registration details see: http://www.ieee-infocom.org/2001/registration.html For hotel details see: http://www.ieee-infocom.org/2001/hotel.html ----------------------------------------------------------- FULL ADVANCED OPENARCH PROGRAM ------------------------------------------------------------ Friday April 27 Opening Address Raj Yavatkar, Intel Corp. Keynote Address Jonathan S. Turner, Washington University in Saint Louis Session: Programmable Router Architectures VERA: An Extensible Router Architecture Scott Karlin, Larry Peterson Princeton University An Access Control Architecture for Programmable Routers Jun Gao, Peter Steenkiste, Carnegie Mellon University Dynamic Hardware Plugins (DHP): Exploiting Reconfigurable Hardware for High-Performance Programmable Routers David E. Taylor, Jonathan S. Turner, John W. Lockwood Washington University in Saint Louis Panel: Network Architectures in the Optical Age Organizer: Aurel A. Lazar, Xbind Inc. and Columbia University Panelists: To be announced Session: Active Multicast Services Building Multicast Services from Unicast Forwarding and Ephemeral State Ken Calvert, James Griffioen, Su Wen University of Kentucky Active Reliable Multicast on CANEs: A Case Study Matt Sanders, Ken Calvert, University of Kentucky Mark Keaton, TASC, Inc. Samrat Bhattacharjee, University of Maryland Stephen Zabele, TASC, Inc. Ellen Zegura, Georgia Institute of Technology Session: Security Issues in Active Networks Strong Security in Active Networks Sandra Murphy, Edward Lewis, Robert Watson, Richard Yee, NAI Labs at Network Associates Ralph Puga, MyCIO Securing Distributed Adaptation Jun Li, Mark Yarvis, Peter Reiher, University of California, Los Angeles Social Event ------------------------------------------------------------------------- Saturday April 28 Keynote Address Jeff Lawrence, CTO, Network Communications Group, Intel Session: Programmable Networks New Models and Algorithms for Programmable Networks Dan Raz, Yuval Shavitt, Bell Laboratories, Lucent Technologies Active Networking On A Programmable Network Platform Phil Yonghui Wang, Tal Lavian, Robert Duncan, Nortel Robert Jaeger, University of Maryland Regatta: A Framework for Automated Supervision of Network Clouds Vijak Sethaput, Harvard University Adnan Onart, Franco Travostino, Nortel Networks Panel: Peer-to-Peer Overlays: Active Network Prospect or Challenger? Organizer: David Wetherall, Asta Networks and University of Washington Panelists: Larry Peterson, Princeton University, Joe Touch and Bob Braden, USC ISI Session: Constructing Services Constructing End-to-End Paths for Playing Media Objects Larry Peterson, Akihiro Naka, Andy Bavier, Princeton University Providing Applications with Mobile Agent Technology Paulo Marques, Paulo Simoes, Luis Silva, Fernando Boavida Joao Gabriel, University of Coimbra Implementing Configurable Signalling in the MULTE-ORB Tom Kristensen, Ingvild Berlin Kalleberg, Thomas Plagemann, University of Oslo Conference Invited Talk Reflective Middleware Geoff Coulson, Lancaster University and Columbia University Hot Topics Session Organizer: Christian Tchudin, Uppsala University http://www.openarch.org/2001_short.html CFP: Submission deadline Feb 9, 2001 The best papers from the conference will be published as a special issue of Computer Networks on Programmable Networks. ------------------------------------------------------------------------ Organizing Committee General Chair: Raj Yavatkar, Intel Corp. Program Co-Chair: Andrew Campbell, Columbia University Program Co-Chair: David Wetherall, University of Washington Publications Chair: John Vicente, Intel Corp. Publicity Chair: Samrat Bhattacharjee, University of Maryland IEEE ComSoc Coordinator: Steve Weinstein, NEC USA Webmaster: Michael Kounavis, Columbia University Program Committee (members of the OC are also members of the PC): Vaduvur Bharghavan, UIUC Ken Calvert, University of Kentucky Jon Crowcroft, UCL, UK Gisli Hjalmtysson, AT&T Research Alden Jackson, BBN Technologies Aurel Lazar, Xbind Inc. Ian Marshall, BT Labs Gary Minden, University of Kansas Craig Partridge, BBN Technologies Dan Raz, Lucent Bell Labs Rolf Stadler, Columbia University Franco Travostino, Nortel Networks Christian Tschudin, Uppsala University Ian Wakeman, University of Sussex Yechiam Yemini, Columbia University Bob Braden, USC ISI Roy Campbell, UIUC Bruce Davie, Cisco David Hutchison, Lancaster University Kalai Kalaichelvan, Nortel Networks Ian Leslie, Cambridge University Nick Maxemchuk, AT&T Research Labs Giovanni Pacifici, IBM Larry Peterson, Princeton University Jonathan Smith, University Penn. Peter Steenkiste, CMU James Sterbenz, BBN Technologies David Tennenhouse, Intel Corp. Harrick Vin, UT Austin Ellen Zegura, Georgia Tech. From nichols@packetdesign.com Mon Feb 5 13:40:23 2001 Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id NAA20119 for ; Mon, 5 Feb 2001 13:40:23 -0800 (PST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f15LdgI07174; Mon, 5 Feb 2001 13:39:42 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3A7F1E03.E3EB71E@packetdesign.com> Date: Mon, 05 Feb 2001 13:41:23 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Saverio Mascolo CC: end2end-interest@postel.org Subject: Re: R: [e2e] [Fwd: RED-->ECN] References: <3.0.32.20010203100118.02ab1560@pop.ecs.umass.edu> <001f01c08df4$e6269a00$723bccc1@poliba.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 84 Saverio Mascolo wrote: > > What Hollot says is right. Averaging the queue makes much more difficult to > control the queue level. In control terms is like to add another pole in the > feedback loop. > An interesting paper is also "Reasons not to deploy RED" by J. Bolot et. al. > ( at http://citeseer.nj.nec.com/337634.html). > This paper experiments average vs. instantaneous queue RED dropping. > ... There are a lot of interesting things to look at in RED-type work and one of them is to closely examine the quality of the experiments that are done and cited in papers. Unless the above cited paper has changed since someone at Cisco asked me to look at it, all I can say is if your network looks like that of their experiments (set up, RTTs, traffic mix), then perhaps the results apply. There is a body of measurement work that shows that most networks look rather different from this. I'm personally interested in results that show some robustness, but this may not be currently fashionable. Kathie Nichols From mankin@ISI.EDU Mon Feb 5 21:08:40 2001 Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id VAA05487 for ; Mon, 5 Feb 2001 21:08:39 -0800 (PST) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id AAA17315; Tue, 6 Feb 2001 00:08:30 -0500 (EST) Posted-Date: Tue, 06 Feb 2001 00:12:48 -0500 Message-Id: <10102060512.AA23006@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Tue, 6 Feb 01 00:12:49 EST To: end2end-interest@postel.org Cc: floyd@aciri.org, mallman@grc.nasa.gov, craig@aland.bnn.com Reply-To: mankin@ISI.EDU Date: Tue, 06 Feb 2001 00:12:48 -0500 From: Allison Mankin Subject: [e2e] RFC 2414 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 85 The IETF Transport Area Directors have received a request to move RFC 2414, Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. September 1998. (Status: EXPERIMENTAL) to standards track. We'd like to ask the authors to re-publish here some supporting comments that they gave to the IESG, and we'd appreciate hearing from the broader end2end-interest community if the change to standards track is now appropriate. Thank you Allison (mankin@isi.edu) Scott (sob@harvard.edu From dino.saija@libero.it Tue Feb 6 03:21:42 2001 Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id DAA04448 for ; Tue, 6 Feb 2001 03:21:41 -0800 (PST) Received: from libero.it (193.70.192.61) by smtp1.libero.it (5.5.015.5) id 3A5C4F910106FA55 for end2end-interest@postel.org; Tue, 6 Feb 2001 12:21:03 +0100 Date: Tue, 6 Feb 2001 12:22:19 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain From: "dino.saija@libero.it" To: end2end-interest@postel.org X-XaM3-API-Version: 1.1.9.1.31 X-SenderIP: 194.185.160.247 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id DAA04448 Subject: [e2e] type of tcp Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 86 for my study, I'd like a white papers that specificate a different type of TCP (es.Reno etc..). How many different versions of TCP exist? thank you From J.Crowcroft@cs.ucl.ac.uk Tue Feb 6 03:53:39 2001 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id DAA06632 for ; Tue, 6 Feb 2001 03:53:38 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Feb 2001 11:53:12 +0000 To: "dino.saija@libero.it" cc: end2end-interest@postel.org, J.Crowcroft@cs.ucl.ac.uk Subject: Re: [e2e] type of tcp In-reply-to: Your message of "Tue, 06 Feb 2001 12:22:19 +0100." Date: Tue, 06 Feb 2001 11:53:13 +0000 Message-ID: <4288.981460393@cs.ucl.ac.uk> From: Jon Crowcroft Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 87 In message , "dino.saija@libero.it" typed: >>for my study, I'd like a white papers that specificate a different type >>of TCP (es.Reno etc..). How many different versions of TCP exist? actually different, or detectably different? http://www.aciri.org/tbit/ is a good place for starting wit h detection... for actual differences, its hard to say - just about any new OS release of bug fix nowdays from major "vendors (including opensources) changes TCP too :) cheers jon From padhye@moose.aciri.org Tue Feb 6 10:10:50 2001 Received: from moose.aciri.org (moose.aciri.org [192.150.187.26]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA10780 for ; Tue, 6 Feb 2001 10:10:50 -0800 (PST) Received: (from padhye@localhost) by moose.aciri.org (8.11.1/8.11.1) id f16IAll58248; Tue, 6 Feb 2001 10:10:47 -0800 (PST) (envelope-from padhye) From: Jitendra Padhye Message-Id: <200102061810.f16IAll58248@moose.aciri.org> Subject: Re: [e2e] type of tcp In-Reply-To: from "dino.saija@libero.it" at "Feb 6, 2001 12:22:19 pm" To: dino.saija@libero.it Date: Tue, 6 Feb 2001 10:10:47 -0800 (PST) Cc: end2end-interest@postel.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 88 > for my study, I'd like a white papers that specificate a different type > of TCP (es.Reno etc..). How many different versions of TCP exist? > thank you > Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Kevin Fall and Sally Floyd, Computer Communication Review, V. 26 N. 3, July 1996, pp. 5-21. http://www.aciri.org/floyd/papers/sacks.ps.Z also see RFCs 2581, 2582 and 2018. Jon is right, though: every TCP implementation has its own quirks. Depending on what you are trying to study, you may or may not have to take these into account. - Jitu From mascolo@poliba.it Tue Feb 6 10:54:05 2001 Received: from cstar.poliba.it (IDENT:root@cstar.poliba.it [193.204.49.36]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA17022 for ; Tue, 6 Feb 2001 10:54:04 -0800 (PST) Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by cstar.poliba.it (8.11.0/8.11.0) with SMTP id f16Ix7u18973; Tue, 6 Feb 2001 19:59:07 +0100 Message-ID: <008401c0906e$3a69fa00$723bccc1@poliba.it> From: "Saverio Mascolo" To: "Kathleen Nichols" Cc: References: <3.0.32.20010203100118.02ab1560@pop.ecs.umass.edu> <001f01c08df4$e6269a00$723bccc1@poliba.it> <3A7F1E03.E3EB71E@packetdesign.com> Subject: R: R: [e2e] [Fwd: RED-->ECN] Date: Tue, 6 Feb 2001 19:54:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 89 I have no reasons to believe that results reported in the paper below are not correct. Robust tuning of RED parameter is of course a great issue. Regarding Random Early Discard my question is: since the goal is to produce an early congestion indication through early dropping, why should we relate dropping to average queue instead of instantaneous queue? Average introduces delay and this is against the goal of having early congestion indication. Saverio Mascolo, Ph.D Associate Professor Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4 70125 Italy email: mascolo@poliba.it tel. +39 080 5963621 fax. +39 080 5963410 http://www-dee.poliba.it/dee-web/Personale/mascolo.html > Saverio Mascolo wrote: > > > > What Hollot says is right. Averaging the queue makes much more difficult to > > control the queue level. In control terms is like to add another pole in the > > feedback loop. > > An interesting paper is also "Reasons not to deploy RED" by J. Bolot et. al. > > ( at http://citeseer.nj.nec.com/337634.html). > > This paper experiments average vs. instantaneous queue RED dropping. > > > ... > > There are a lot of interesting things to look at in RED-type work and > one of them is to closely examine the quality of the experiments > that are done and cited in papers. Unless the above cited paper has > changed since someone at Cisco asked me to look at it, all I can > say is if your network looks like that of their experiments (set up, > RTTs, traffic mix), then perhaps the results apply. There is a body > of measurement work that shows that most networks look rather different > from this. I'm personally interested in results that show some > robustness, > but this may not be currently fashionable. > > Kathie Nichols > From P.Gevros@cs.ucl.ac.uk Tue Feb 6 12:03:32 2001 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id MAA25076 for ; Tue, 6 Feb 2001 12:03:32 -0800 (PST) Received: from sporty.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Feb 2001 20:03:13 +0000 X-Mailer: exmh version 2.0.2 To: Saverio Mascolo cc: end2end-interest cc: P.Gevros@cs.ucl.ac.uk Subject: Re: R: R: [e2e] [Fwd: RED-->ECN] In-reply-to: Your message of "Tue, 06 Feb 2001 19:54:26 +0100." <008401c0906e$3a69fa00$723bccc1@poliba.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Feb 2001 20:03:13 +0000 Message-ID: <2100.981489793@cs.ucl.ac.uk> From: Panos GEVROS Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 90 Saverio Mascolo writes: |I have no reasons to believe that results reported in the paper below are |not correct. |Robust tuning of RED parameter is of course a great issue. |Regarding Random Early Discard my question is: since the goal is to produce |an early congestion indication through early dropping, why should we relate |dropping to average queue instead of instantaneous queue? because we want occasional bursts to be able to pass through unharmed- this is important given the nature of data traffic- and in any case sporadic bursts and congestion are different things, cheers Panos |Average introduces delay and this is against the goal of having early |congestion indication. From atiq@ou.edu Tue Feb 6 12:12:46 2001 Received: from msmailhub.ou.edu (msmailhub.oulan.ou.edu [129.15.87.16]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA26106 for ; Tue, 6 Feb 2001 12:12:46 -0800 (PST) Received: by msmailhub.oulan.ou.edu with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 14:12:45 -0600 Message-ID: <372E9068C013D211891F00805F9FD1C20688C972@mail3.oulan.ou.edu> From: "Atiquzzaman, Mohammed" To: "'Saverio Mascolo'" , end2end-interest@postel.org Cc: Kathleen Nichols Subject: RE: R: [e2e] [Fwd: RED-->ECN] Date: Tue, 6 Feb 2001 14:12:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 91 > -----Original Message----- > From: Saverio Mascolo [mailto:mascolo@poliba.it] > Sent: Tuesday, February 06, 2001 10:54 AM > To: Kathleen Nichols > Cc: end2end-interest@postel.org > Subject: R: R: [e2e] [Fwd: RED-->ECN] > > > I have no reasons to believe that results reported in the > paper below are > not correct. > Robust tuning of RED parameter is of course a great issue. > Regarding Random Early Discard my question is: since the goal > is to produce > an early congestion indication through early dropping, why > should we relate > dropping to average queue instead of instantaneous queue? > Average introduces delay and this is against the goal of having early > congestion indication. Averaging would tend to filter out transient congestion (due to data bursts) but will take into account perstistent congestion. During transient congestion data will be discarded not by RED but by tail drop. Thanks Mohammed Atiquzzaman Tel: (405) 325 8077 School of Computer Science Fax: (520) 962 8422, University of Oklahoma (405) 325 4044 200 Felgar St., Room EL-154 Email: atiq@ou.edu Norman, OK 73019-6151 atiq@ieee.org www.cs.ou.edu/~atiq > > Saverio Mascolo, Ph.D > > Associate Professor > Dipartimento di Elettrotecnica ed Elettronica > Politecnico di Bari > Via Orabona 4 > 70125 Italy > email: mascolo@poliba.it > tel. +39 080 5963621 > fax. +39 080 5963410 > http://www-dee.poliba.it/dee-web/Personale/mascolo.html > > > Saverio Mascolo wrote: > > > > > > What Hollot says is right. Averaging the queue makes much > more difficult > to > > > control the queue level. In control terms is like to add > another pole in > the > > > feedback loop. > > > An interesting paper is also "Reasons not to deploy RED" > by J. Bolot et. > al. > > > ( at http://citeseer.nj.nec.com/337634.html). > > > This paper experiments average vs. instantaneous queue > RED dropping. > > > > > ... > > > > There are a lot of interesting things to look at in > RED-type work and > > one of them is to closely examine the quality of the experiments > > that are done and cited in papers. Unless the above cited paper has > > changed since someone at Cisco asked me to look at it, all I can > > say is if your network looks like that of their experiments (set up, > > RTTs, traffic mix), then perhaps the results apply. There is a body > > of measurement work that shows that most networks look > rather different > > from this. I'm personally interested in results that show some > > robustness, > > but this may not be currently fashionable. > > > > Kathie Nichols > > > From mascolo@poliba.it Wed Feb 7 05:11:25 2001 Received: from cstar.poliba.it (IDENT:root@cstar.poliba.it [193.204.49.36]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id FAA25092 for ; Wed, 7 Feb 2001 05:11:24 -0800 (PST) Received: from deectl18 (deectl18.poliba.it [193.204.59.114]) by cstar.poliba.it (8.11.0/8.11.0) with SMTP id f17DGau28131; Wed, 7 Feb 2001 14:16:36 +0100 Message-ID: <001101c09107$89e293a0$723bccc1@poliba.it> From: "Saverio Mascolo" To: "Atiquzzaman, Mohammed" , , References: <372E9068C013D211891F00805F9FD1C20688C972@mail3.oulan.ou.edu> Subject: R: R: [e2e] [Fwd: RED-->ECN] Date: Wed, 7 Feb 2001 14:11:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 92 I think that RED is a simple and effective idea. As it is usual with V. Jacobson proposals, it is an intelligent solution that takes into account engineering constraints. Thus I agree that RED is an easy task that should be performed by the network. Moreover I think that TCP Reno fast recovery should be a little bit modified to take into account RED and I think that dropping should be related to instantaneous queues. We are currently preparing a report on this. Thanks Saverio > Averaging would tend to filter out transient congestion (due to data bursts) > but will take into account perstistent congestion. During transient > congestion data will be discarded not by RED but by tail drop. > > Thanks > Mohammed Atiquzzaman Tel: (405) 325 8077 > School of Computer Science Fax: (520) 962 8422, > University of Oklahoma (405) 325 4044 > 200 Felgar St., Room EL-154 Email: atiq@ou.edu > Norman, OK 73019-6151 atiq@ieee.org > www.cs.ou.edu/~atiq > > > > > Saverio Mascolo, Ph.D > > > > Associate Professor > > Dipartimento di Elettrotecnica ed Elettronica > > Politecnico di Bari > > Via Orabona 4 > > 70125 Italy > > email: mascolo@poliba.it > > tel. +39 080 5963621 > > fax. +39 080 5963410 > > http://www-dee.poliba.it/dee-web/Personale/mascolo.html > > > > > Saverio Mascolo wrote: > > > > > > > > What Hollot says is right. Averaging the queue makes much > > more difficult > > to > > > > control the queue level. In control terms is like to add > > another pole in > > the > > > > feedback loop. > > > > An interesting paper is also "Reasons not to deploy RED" > > by J. Bolot et. > > al. > > > > ( at http://citeseer.nj.nec.com/337634.html). > > > > This paper experiments average vs. instantaneous queue > > RED dropping. > > > > > > > ... > > > > > > There are a lot of interesting things to look at in > > RED-type work and > > > one of them is to closely examine the quality of the experiments > > > that are done and cited in papers. Unless the above cited paper has > > > changed since someone at Cisco asked me to look at it, all I can > > > say is if your network looks like that of their experiments (set up, > > > RTTs, traffic mix), then perhaps the results apply. There is a body > > > of measurement work that shows that most networks look > > rather different > > > from this. I'm personally interested in results that show some > > > robustness, > > > but this may not be currently fashionable. > > > > > > Kathie Nichols > > > > > > From cdiot@sprintlabs.com Wed Feb 7 12:35:07 2001 Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA12346 for ; Wed, 7 Feb 2001 12:35:06 -0800 (PST) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Wed, 7 Feb 2001 12:34:50 -0800 Received: from sprintlabs.com (ip199-2-53-101.sprintlabs.com [199.2.53.101]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id DZL7JDJV; Wed, 7 Feb 2001 12:34:42 -0800 From: Christophe Diot Reply-To: Christophe Diot To: end2end-interest@postel.org Message-ID: <3A81B0E5.7BE2E909@sprintlabs.com> Date: Wed, 07 Feb 2001 12:32:37 -0800 Organization: Sprint ATL X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A8185ED.AA0746F0@activia.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] more about averaging Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 93 > > What Hollot says is right. Averaging the queue makes much more difficult to > > control the queue level. In control terms is like to add another pole in the > > feedback loop. > > An interesting paper is also "Reasons not to deploy RED" by J. Bolot et. al. > > ( at http://citeseer.nj.nec.com/337634.html). > > This paper experiments average vs. instantaneous queue RED dropping. > > > ... > > There are a lot of interesting things to look at in RED-type work and > one of them is to closely examine the quality of the experiments > that are done and cited in papers. Unless the above cited paper has > changed since someone at Cisco asked me to look at it, all I can > say is if your network looks like that of their experiments (set up, > RTTs, traffic mix), then perhaps the results apply. There is a body > of measurement work that shows that most networks look rather different > from this. I'm personally interested in results that show some > robustness, but this may not be currently fashionable. > > Kathie Nichols :-) ftp://ftp.sprintlabs.com/diot/aqm-gredi-ccr.zip ======================================================= christophe Diot | tel: 1(650)375.4539 Sprint ATL | fax: 1(650)375.4490 1 Adrian Court | cdiot@sprintlabs.com Burlingame CA 94010 | www.sprintlabs.com USA | From touch@ISI.EDU Thu Feb 8 09:04:50 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA07671 for ; Thu, 8 Feb 2001 09:04:50 -0800 (PST) Received: from isi.edu (ras31.isi.edu [128.9.176.131]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f18H4gU24463; Thu, 8 Feb 2001 09:04:42 -0800 (PST) Message-ID: <3A82D1AD.B9C9A3C5@isi.edu> Date: Thu, 08 Feb 2001 09:04:45 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: Jitendra Padhye , dino.saija@libero.it, end2end-interest@postel.org Subject: Re: [e2e] type of tcp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 94 My (partial) list includes: Tahoe Reno NewReno Vegas Boston Westwood Peach SACK (selective) FACK (fast) TACK (total) However, it's not clear whether these are comparable. Some (Boston) are whole new algorithms (for FEC); others affect individual components (ACK interpretation). Anyone recall others? Joe From hxw@eecs.umich.edu Thu Feb 8 09:55:44 2001 Received: from waltz.eecs.umich.edu (waltz.eecs.umich.edu [141.213.10.237]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA15890 for ; Thu, 8 Feb 2001 09:55:44 -0800 (PST) Received: from localhost (hxw@localhost) by waltz.eecs.umich.edu (8.9.3/8.9.1) with ESMTP id MAA09810; Thu, 8 Feb 2001 12:54:40 -0500 (EST) Date: Thu, 8 Feb 2001 12:54:40 -0500 (EST) From: Haining Wang To: Joe Touch cc: L.Wood@eim.surrey.ac.uk, end2end-interest@postel.org Subject: Re: [e2e] type of tcp In-Reply-To: <3A82D1AD.B9C9A3C5@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 95 Hi Joe, >Anyone recall others? TCP Santa Cruz URL is: http://www.cse.ucsc.edu/~chris/sctcp/sctcp.html Also we developed a variant of Slow-start named as Smooth-start, and a variant of fast-recovery named as robust-recovery. If interested, please check: http://www.eecs.umich.edu/~hxw/paper/smooth.ps http://www.eecs.umich.edu/~hxw/paper/recovery.ps Thanks, Haining From durst@mitre.org Thu Feb 8 10:17:46 2001 Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA20847 for ; Thu, 8 Feb 2001 10:17:45 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA29266; Thu, 8 Feb 2001 13:16:22 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA07029; Thu, 8 Feb 2001 13:16:21 -0500 (EST) Received: from dhcp-145-244.mitre.org (128.29.145.244) by mailhub1.mitre.org with SMTP id 5575504; Thu, 08 Feb 2001 13:15:41 -0500 Message-ID: <3A82E276.936301BA@mitre.org> Date: Thu, 08 Feb 2001 13:16:22 -0500 From: "Robert C. Durst" Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch CC: L.Wood@eim.surrey.ac.uk, end2end-interest@postel.org Subject: Re: [e2e] type of tcp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 96 Joe, >Anyone recall others? There's TCP SCPS, See http://www.scps.org/scps/assets/TCPExt4Sat.pdf Focus within TCP is on improving performance in a spacecraft environment (potentially high bit error rates, long delay, high asymmetry) and adding some services that spacecraft designers were interested in (rate-based pacing, record boundary marking, partial reliability service). Regards, Bob Durst durst@mitre.org From David_Eckhardt@PIPER.NECTAR.cs.cmu.edu Thu Feb 8 10:52:43 2001 Received: from cs.cmu.edu (CS.CMU.EDU [128.2.222.173]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id KAA25869 for ; Thu, 8 Feb 2001 10:52:43 -0800 (PST) Received: from PIPER.NECTAR.CS.CMU.EDU by cs.cmu.edu id aa16207; 8 Feb 2001 13:52 EST From: David.Eckhardt@cs.cmu.edu In-Reply-To: <3A82E276.936301BA@mitre.org> To: end2end-interest@postel.org Subject: Re: [e2e] type of tcp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22661.981658354.1@piper.nectar.cs.cmu.edu> Date: Thu, 08 Feb 2001 13:52:34 -0500 Message-ID: <22663.981658354@piper.nectar.cs.cmu.edu> Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 97 > "Robert C. Durst" : > See http://www.scps.org/scps/assets/TCPExt4Sat.pdf Fascinating. Is there a "TCP variants" web page somewhere that holds all of these? Dave Eckhardt From mallman@lerc.nasa.gov Thu Feb 8 12:10:28 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA06307 for ; Thu, 8 Feb 2001 12:10:27 -0800 (PST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA08432; Thu, 8 Feb 2001 15:10:15 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA10193; Thu, 8 Feb 2001 15:11:11 -0500 (EST) Message-Id: <200102082011.PAA10193@guns.lerc.nasa.gov> To: mankin@ISI.EDU From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: end2end-interest@postel.org, floyd@aciri.org, craig@aland.bnn.com Organization: BBN Technologies/NASA GRC Song-of-the-Day: Who Made Who Date: Thu, 08 Feb 2001 15:11:11 -0500 Subject: [e2e] Re: RFC 2414 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 98 > The IETF Transport Area Directors have received a request to move > RFC 2414, > Increasing TCP's Initial Window. M. Allman, S. Floyd, C. > Partridge. September 1998. (Status: EXPERIMENTAL) > to standards track. > > We'd like to ask the authors to re-publish here some supporting comments > that they gave to the IESG, and we'd appreciate hearing from > the broader end2end-interest community if the change to standards > track is now appropriate. The following is the summary of a conversation between Sally, Craig and myself. (Although, I'll note that neither of my co-authors reviewed this text specifically. I hope to have captured our conversation, but don't want to put words in their mouths.) Two data points of larger initial windows since the publication of RFC 2414: * Sally and Jitu's TBIT results: Results from the TBIT tool with Jitu, at "http://www.aciri.org/tbit/initwin.512.txt.gz", show that, with 512-byte packets, of the web servers tested: 214 used an initial window of 1 segments, 456 used an initial window of 2 segments, 407 used an initial window of 3 segments, 30 used an initial window of 4 segments, 12 used an initial window of 5 segments, 95 used an initial window of 6 segments, 2 used an initial window of 8 segments, and 8 used an initial window of >8 segments So clearly initial windows of two and three are common at web servers. The four web servers with an initial window of 17 segments have been tracked down to something old and obsolete, as I recall... * There are some fairly recent results on using a larger initial cwnd in our web server in: Mark Allman. A Web Server's View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000. http://roland.grc.nasa.gov/~mallman/papers/webobs-ccr.ps (The results are basically in agreement with the arguments made in 2414). And, a problem with the document: * A point has been raised that is not addressed in RFC 2414. That is, using a larger initial cwnd may potentially hose the RTO on slow links. If we measure the RTT of the (small) 3WHS, it does not predict the RTT caused by 4KB of data sent into the network back-to-back. This is not necessarily a problem caused by using more than one segment in the initial cwnd. We see the same problem if we use large packets. However, using a larger initial cwnd has the potential to aggrivate this problem. We should probably address this with some sort of workaround (don't time the 3WHS when using larger initial windows?). It seems our consensus is that we'd like to make a pass at the document to address the RTO problem. In addition, we can add some pointers to more recent work in this area (not as important as the RTO problem). And then we'd love to see larger initial cwnds put on standards track. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From molinero@stanford.edu Thu Feb 8 12:19:45 2001 Received: from smtp.Stanford.EDU (smtp.Stanford.EDU [171.64.14.23]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA07248 for ; Thu, 8 Feb 2001 12:19:45 -0800 (PST) Received: from madrid (DN800cb409.Stanford.EDU [128.12.180.9]) by smtp.Stanford.EDU (8.11.1/8.11.1) with SMTP id f18KJhW16293 for ; Thu, 8 Feb 2001 12:19:44 -0800 (PST) Message-ID: <009401c0920c$4cb3f9a0$09b40c80@stanford.edu> From: =?iso-8859-1?Q?Pablo_Molinero_Fern=E1ndez?= Cc: References: Subject: Re: [e2e] type of tcp Date: Thu, 8 Feb 2001 12:18:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 99 TCP Buffer Fill Avoidance http://klamath.stanford.edu/publications/HPNC98.pdf Pablo Molinero ----- Original Message ----- From: "Haining Wang" To: "Joe Touch" Cc: ; Sent: Thursday, February 08, 2001 9:54 AM Subject: Re: [e2e] type of tcp > > Hi Joe, > > >Anyone recall others? > > TCP Santa Cruz > > URL is: > http://www.cse.ucsc.edu/~chris/sctcp/sctcp.html > > > Also we developed a variant of Slow-start named > as Smooth-start, and a variant of fast-recovery > named as robust-recovery. If interested, please > check: > > http://www.eecs.umich.edu/~hxw/paper/smooth.ps > http://www.eecs.umich.edu/~hxw/paper/recovery.ps > > Thanks, > > Haining > > From mahesh@erg.abdn.ac.uk Thu Feb 8 12:50:26 2001 Received: from erg.abdn.ac.uk (diesel.erg.abdn.ac.uk [139.133.204.76]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA10501 for ; Thu, 8 Feb 2001 12:50:25 -0800 (PST) Received: from erg.abdn.ac.uk (indigo-mac.erg.abdn.ac.uk [139.133.207.14]) by erg.abdn.ac.uk (8.11.2/8.11.2) with ESMTP id f18KoNe17156; Thu, 8 Feb 2001 20:50:23 GMT Message-ID: <3A830690.790E3566@erg.abdn.ac.uk> Date: Thu, 08 Feb 2001 20:50:24 +0000 From: mahesh Reply-To: mahesh@erg.abdn.ac.uk Organization: Electronics Reasearch Group, University of Aberdeen X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: end2end-interest@postel.org Subject: Re: [e2e] type of tcp References: <009401c0920c$4cb3f9a0$09b40c80@stanford.edu> Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 8bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 100 More links: TCP variants/alternatives 1) I-TCP : Indirect TCP for Mobile Hosts http://http.cs.berkeley.edu/~gribble/cs294-7_wireless/summaries/itcp.html 2) WTCP : A Reliable Transport Protocol for Wireless Wide-Area Networks http://timely.crhc.uiuc.edu/Papers/winet00.wtcp.ps.gz 3) T/TCP TCP for Transactions http://www.kohala.com/start/ttcp.html 4) TCP Boston : A Fragmentation-tolerant TCP Protocol for ATM Networks http://lite.ncstrl.org:3803/Dienst/UI/2.0/Describe/ncstrl.bu_cs/96-014 5) TCP Santa Cruz : Improving TCP Congestion Control Over Internets with Heterogeneous Transmission Media http://www.cse.ucsc.edu/~chris/sctcp/sctcp.html 6) SCTP : stream control transmission protocol ? http://www.ietf.org/rfc/rfc2960.txt 7) SCPS : TP Space Communications Protocol Standards Transport Protocol http://www.scps.org/scps/ 8) MTCP : Mobile TCP http://www-tkn.ee.tu-berlin.de/bibl/ps/end2endmobitrans.ps.gz cheers, Mahesh. --- Pablo Molinero Fernández wrote: > TCP Buffer Fill Avoidance > > http://klamath.stanford.edu/publications/HPNC98.pdf > > Pablo Molinero > > ----- Original Message ----- > From: "Haining Wang" > To: "Joe Touch" > Cc: ; > Sent: Thursday, February 08, 2001 9:54 AM > Subject: Re: [e2e] type of tcp > > > > > Hi Joe, > > > > >Anyone recall others? > > > > TCP Santa Cruz > > > > URL is: > > http://www.cse.ucsc.edu/~chris/sctcp/sctcp.html > > > > > > Also we developed a variant of Slow-start named > > as Smooth-start, and a variant of fast-recovery > > named as robust-recovery. If interested, please > > check: > > > > http://www.eecs.umich.edu/~hxw/paper/smooth.ps > > http://www.eecs.umich.edu/~hxw/paper/recovery.ps > > > > Thanks, > > > > Haining > > > > From shalunov@internet2.edu Thu Feb 8 12:52:32 2001 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA10658 for ; Thu, 8 Feb 2001 12:52:30 -0800 (PST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id PAA22412 for ; Thu, 8 Feb 2001 15:52:29 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id AA9C0895; Thu, 8 Feb 2001 15:52:21 -0500 (EST) To: end2end-interest@postel.org Subject: Re: [e2e] type of tcp References: <22663.981658354@piper.nectar.cs.cmu.edu> From: stanislav shalunov Date: 08 Feb 2001 15:52:21 -0500 In-Reply-To: <22663.981658354@piper.nectar.cs.cmu.edu> Message-ID: <87snlovqwq.fsf@cain.internet2.edu> Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 101 David.Eckhardt@cs.cmu.edu writes: > Is there a "TCP variants" web page somewhere that holds all of > these? See http://dmoz.org/Computers/Internet/Protocols/Transmission_Protocols/TCP/ for a partial list. (Also, "Implementations" subcategory.) You can help make the list more complete by submitting additional resources. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain From ggm@dstc.edu.au Thu Feb 8 14:56:44 2001 Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA26415 for ; Thu, 8 Feb 2001 14:56:39 -0800 (PST) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id f18Mu2e28747 for ; Fri, 9 Feb 2001 08:56:02 +1000 (EST) To: end2end-interest@postel.org Subject: Re: [e2e] type of tcp In-reply-to: Your message of "Thu, 08 Feb 2001 13:52:34 EST." <22663.981658354@piper.nectar.cs.cmu.edu> Date: Fri, 09 Feb 2001 08:56:32 +1000 Message-ID: <12333.981672992@dstc.edu.au> From: George Michaelson Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 102 > "Robert C. Durst" : > See http://www.scps.org/scps/assets/TCPExt4Sat.pdf Fascinating. Is there a "TCP variants" web page somewhere that holds all of these? Do these have sufficiently deterministic differences that you could categorize them by CSP or some other low-level network equivalent of EBNF? Or network equivalents of the UNIX file command (the magic list) What is the notation to represent (minor divergences in) time-series of data exchange between asynchronous parties? cheers -George -- George Michaelson | DSTC Pty Ltd Email: ggm@dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au From mingyan@eecs.umich.edu Thu Feb 8 15:23:08 2001 Received: from smtp.eecs.umich.edu (smtp.eecs.umich.edu [141.213.4.44]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA29427 for ; Thu, 8 Feb 2001 15:23:07 -0800 (PST) Received: from wildwood.eecs.umich.edu (wildwood.eecs.umich.edu [141.213.4.68]) by smtp.eecs.umich.edu (8.11.2/8.11.2) with ESMTP id f18NN3106221; Thu, 8 Feb 2001 18:23:04 -0500 Date: Thu, 8 Feb 2001 18:23:03 -0500 (EST) From: Mingyan Liu To: David.Eckhardt@cs.cmu.edu cc: end2end-interest@postel.org Subject: Re: [e2e] type of tcp In-Reply-To: <22663.981658354@piper.nectar.cs.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 103 On Thu, 8 Feb 2001 David.Eckhardt@cs.cmu.edu wrote: > > "Robert C. Durst" : > > See http://www.scps.org/scps/assets/TCPExt4Sat.pdf > > Fascinating. Is there a "TCP variants" web page somewhere > that holds all of these? > This site contains many "variants": http://bbcr.uwaterloo.ca/~jpan/tcpair -Mingyan From sanacori@cci.unibs.it Fri Feb 9 01:45:37 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id BAA23654 for ; Fri, 9 Feb 2001 01:45:36 -0800 (PST) Received: from master.cci.unibs.it (master.cci.unibs.it [192.167.18.247]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f199jYU05033 for ; Fri, 9 Feb 2001 01:45:35 -0800 (PST) Received: from anthony (anthony.cci.unibs.it [192.167.18.227]) by master.cci.unibs.it (8.9.3/8.9.3) with SMTP id KAA24961; Fri, 9 Feb 2001 10:37:13 +0100 (MET) Message-ID: <006b01c0927d$3c04f8e0$e312a7c0@cci.unibs.it> Reply-To: "Antonino Sanacori" From: "Antonino Sanacori" To: Cc: Date: Fri, 9 Feb 2001 10:46:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [e2e] A problem installing pchar 1.3.1 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 104 Hi Mr. Mah When I try to install pchar 1.3.1 on my solaris 2.8 I get the following message: ./configure --prefix=my dir --with-PACKAGE=snmp --host=sparc-sun-solaris2.8 loading cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking for mawk... no checking for gawk... no checking for nawk... nawk checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes checking whether the C++ compiler (c++ ) is a cross-compiler... yes checking whether we are using GNU C++... yes checking whether c++ accepts -g... yes checking for a BSD compatible install... ./install-sh -c checking for pchar version number... 1.3.1 checking echo functionality... SysV-style checking size of bool... configure: error: can not run test program while cross compiling May you explain me the meaning of this error ? Thank you. dott. Antonino Sanacori Centro di Calcolo Interfacoltà Università degli Studi di Brescia tel: 030/3715717 fax: 030/3715720 email: sanacori@cci.unibs.it From veres@comet.columbia.edu Fri Feb 9 09:14:22 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA01999 for ; Fri, 9 Feb 2001 09:14:21 -0800 (PST) Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f19HEKU13151 for ; Fri, 9 Feb 2001 09:14:20 -0800 (PST) Received: from comet.columbia.edu (IDENT:root@locke.comet.columbia.edu [128.59.68.81]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id MAA23075; Fri, 9 Feb 2001 12:14:18 -0500 (EST) Message-ID: <3A84253A.78CFA3EE@comet.columbia.edu> Date: Fri, 09 Feb 2001 12:13:31 -0500 From: veres X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "end2end-interest@ISI.EDU" CC: veres@comet.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] Traffic Archive of TCP measuerements Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 105 Traces of TCP connections are available for download and analysis from our new traffic archive. Several detailed TCP measurements, between several hosts, are available, containing packet traces with timestamps and time-series of the amount of data delivered in short time intervals during persistent and short file tranfers (measurements as well as simulations): http://www.comet.columbia.edu/~veres/DATASETS/Datasets.html The datasets have been used in the analysis of TCP dynamics in the following papers: A. Veres, Zs. Kenesi, S. Molnar, G. Vattay, "On the Propagation of Long-Range Dependence in the Internet", Proc. ACM SIGCOMM 2000, Stockholm, Sweden, Sep. 2000 A. Veres, M. Boda, "The Chaotic Nature of TCP Congestion Control", Proc. IEEE INFOCOM 2000, Tel Aviv, March 2000 The datasets can be used freely. We welcome any comments and try to answer questions regarding the traces. If suitable, please use the e2e list for further discussions about the sets. Andras Veres From zm@csnet1.cs.tsinghua.edu.cn Sun Feb 11 17:03:19 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA17340 for ; Sun, 11 Feb 2001 17:03:18 -0800 (PST) Received: from mail.tsinghua.edu.cn (mail.tsinghua.edu.cn [166.111.8.18]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1C13DC06538 for ; Sun, 11 Feb 2001 17:03:15 -0800 (PST) Received: from csnet1.cs.tsinghua.edu.cn (csnet1.cs.tsinghua.edu.cn [166.111.68.118]) by mail.tsinghua.edu.cn (8.9.3/8.9.3) with ESMTP id JAA07411 for ; Mon, 12 Feb 2001 09:01:30 +0800 (CST) Received: from zhangmiao (xyq [166.111.69.226]) by csnet1.cs.tsinghua.edu.cn (8.9.2/8.9.2) with SMTP id IAA01068 for ; Mon, 12 Feb 2001 08:57:32 +0800 (CST) Message-Id: <200102120057.IAA01068@csnet1.cs.tsinghua.edu.cn> Date: Mon, 12 Feb 2001 9:3:8 +0800 From: Zhang Miao To: "end2end-interest@isi.edu" Organization: Tsinghua University X-mailer: FoxMail 3.0 beta 1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [e2e] How to create simulation scenario Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 106 Hi, I have some questions on how to create simulation scenario. Nowadays, many papers use NS to validate the new designed algorithms for end2end congestion control. After reading some papers, I see there are only 2 typical topologies. One is:(Topo1) s1 k1 \ / \ / s2--- r1 ---- r2 ---k2 . / \ . . / \ . sn kn The other is:(Topo2) s1 k1 \ / \ / r1 --- r2 ----r3 / | | \ / | | \ s2 k2 s3 k3 My question are as follows: 1. How many pairs should be used in topo1? Ususally, there are only tens of flows used in simulation. Is it enough to simulate the realistic scenario? If only a few flows are used, the behavior of individual flow will have much impact on the result. 2. How to set the bandwidth between r1 and r2 in topo1? Some paper used 1.5Mb. I doubt where this value came from. The bandwidth and the number of flows used in simulation determine the max cwnd for each TCP flows. Max cwnd will have impact on the duration time of slow start process. For example, if the bandwidth is relatively high, the TCP flow with finite data(say, 40KB) may terminate before congestion avoidance is started. 3. How to set the upper user scenario? Probably it is the most difficult in create a simulation. Usually, a mixture of permanent flows and transient flows is used. But how to design the exact scenario? What is the relation between "elephants" and "mice"(as Steven Low mentioned early)? If there are too many mice, the traffic will tend to be more bursty. 4. How to evalute the interaction between multiple routers and bottleneck links? In topo1, only one bottleneck link is used. In topo2, 2 bottleneck links are used, while only a few flows are introduced. Till now, I see little analysis on the interference between several routers. Could this impact be neglect? Thanks. ***************************************************************** * Zhang Miao * * Ph.D candidate,Department of Computer Science & Technology * * Tsinghua University,Beijing,China(100084) * * Tel: (8610)-62785822 * * Email: zm@csnet1.cs.tsinghua.edu.cn * ***************************************************************** From zm@csnet1.cs.tsinghua.edu.cn Sun Feb 11 17:36:50 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA20456 for ; Sun, 11 Feb 2001 17:36:49 -0800 (PST) Received: from mail.tsinghua.edu.cn (mail.tsinghua.edu.cn [166.111.8.18]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1C1ajC12621 for ; Sun, 11 Feb 2001 17:36:46 -0800 (PST) Received: from csnet1.cs.tsinghua.edu.cn (csnet1.cs.tsinghua.edu.cn [166.111.68.118]) by mail.tsinghua.edu.cn (8.9.3/8.9.3) with ESMTP id JAA11375 for ; Mon, 12 Feb 2001 09:35:05 +0800 (CST) Received: from zhangmiao (xyq [166.111.69.226]) by csnet1.cs.tsinghua.edu.cn (8.9.2/8.9.2) with SMTP id JAA01174 for ; Mon, 12 Feb 2001 09:31:08 +0800 (CST) Message-Id: <200102120131.JAA01174@csnet1.cs.tsinghua.edu.cn> Date: Mon, 12 Feb 2001 9:36:44 +0800 From: Zhang Miao To: "end2end-interest@isi.edu" Organization: Tsinghua University X-mailer: FoxMail 3.0 beta 1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [e2e] Can feedback be generated more fast in ECN? Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 107 Hi, In ECN-RED, router only marks the packet and let the receiving end to "echo" the congestion notification to the sender. I have a naive question. Can the feedback be sent directly from the congested router to the TCP sender? Some schemes of action at router are listed here: 1. Only mark the packet. (ECN) 2. Mark the packet and send a feedback to TCP sender immediately. 3. Send a feedback to TCP sender and drop the packet. This scheme can be used for droptail. The advantages of sending a feedback directly: 1. reduce the response time. 2. reduce the loss probability of feedback. consider the path of marked packet and the ACK with CN bit set. Disadvantages: 1. add more burden the reverse direction of the link. 2. add more burden to the router. Some mechanisms also need to be added to TCP to cope with the duplicate feedback in scheme 2. The designer of ECN must have thought of the scheme above. Can anyone tell me why this scheme was not used when ECN was designed? Thanks! ***************************************************************** * Zhang Miao * * Ph.D candidate,Department of Computer Science & Technology * * Tsinghua University,Beijing,China(100084) * * Tel: (8610)-62785822 * * Email: zm@csnet1.cs.tsinghua.edu.cn * ***************************************************************** From zm@csnet1.cs.tsinghua.edu.cn Sun Feb 11 23:16:17 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id XAA20043 for ; Sun, 11 Feb 2001 23:16:16 -0800 (PST) Received: from mail.tsinghua.edu.cn (mail.tsinghua.edu.cn [166.111.8.18]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1C7G2C05588 for ; Sun, 11 Feb 2001 23:16:04 -0800 (PST) Received: from csnet1.cs.tsinghua.edu.cn (csnet1.cs.tsinghua.edu.cn [166.111.68.118]) by mail.tsinghua.edu.cn (8.9.3/8.9.3) with ESMTP id PAA01392; Mon, 12 Feb 2001 15:14:21 +0800 (CST) Received: from zhangmiao (xyq [166.111.69.226]) by csnet1.cs.tsinghua.edu.cn (8.9.2/8.9.2) with SMTP id PAA01731; Mon, 12 Feb 2001 15:10:24 +0800 (CST) Message-Id: <200102120710.PAA01731@csnet1.cs.tsinghua.edu.cn> Date: Mon, 12 Feb 2001 15:15:58 +0800 From: Zhang Miao To: Hong Bin Liao CC: "end2end-interest@isi.edu" Subject: RE: [e2e] Can feedback be generated more fast in ECN? Organization: Tsinghua University X-mailer: FoxMail 3.0 beta 1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 108 First, I would like to say sorry. I have read the paper by Sally Floyd you mentioned before. But I forgot the related content when I wrote down my question. After re-read that paper, I still can't get the answer to the question. The author listed 2 disadvantages of Source Quench, and listed several advantages of source quench over ECN. There were no explicit answer to my question in it. The disadvantages of Source Quench mentioned: (1) the overhead of Source Quench traffic in times of congestion. (2) addtional load on the network in times of congestion. The author also admitted that: "the use of intelligent gateway mechanisms such as those in RED gateways would limit the overhead of the Source Quench traffic." Also, "Although we have not explored the dynamics of backward ECN mechanism such as Source Quench in our simulation, ..." Now, let us see the disadvantages of Source Quench mentioned in that paper. (1) Is the overhead of Source Quench traffic a significant problem? I guess this arguement was based on router of single processor architecture. The CPU in the router does everything, routing, forwarding, etc. But the architecture of router has changed a lot. We now have router with distributed architecture, with ASIC. The processing of Source Quench may be not a big problem now. (2) About the additional load If Source Quench introduces additional load to the network, ECN also does. Perhaps in ECN, the congestion will influence more broad than in Source Quench. (For the congestion will be "echoed" by the congested router with Source Quench). Addtionally, if the link is congested in one direction, can we deduce that the link is also congested in the reverse direction. The more often scenario is links with heterogenous load in the two directions. >please refer to "TCP and Explicit Congestion Notification" for more >information, especially Section 9.1 > >-----Original Message----- >From: Zhang Miao [mailto:zm@csnet1.cs.tsinghua.edu.cn] >Sent: Monday, February 12, 2001 9:37 AM >To: end2end-interest@isi.edu >Subject: [e2e] Can feedback be generated more fast in ECN? > > >Hi, > In ECN-RED, router only marks the packet and let the receiving end to >"echo" the >congestion notification to the sender. > I have a naive question. Can the feedback be sent directly from the >congested router >to the TCP sender? > Some schemes of action at router are listed here: >1. Only mark the packet. (ECN) >2. Mark the packet and send a feedback to TCP sender immediately. >3. Send a feedback to TCP sender and drop the packet. > This scheme can be used for droptail. > >The advantages of sending a feedback directly: >1. reduce the response time. >2. reduce the loss probability of feedback. > consider the path of marked packet and the ACK with CN bit set. > >Disadvantages: >1. add more burden the reverse direction of the link. >2. add more burden to the router. > > Some mechanisms also need to be added to TCP to cope with the >duplicate feedback >in scheme 2. > > The designer of ECN must have thought of the scheme above. Can anyone >tell me why >this scheme was not used when ECN was designed? > >Thanks! > ***************************************************************** * Zhang Miao * * Ph.D candidate,Department of Computer Science & Technology * * Tsinghua University,Beijing,China(100084) * * Tel: (8610)-62785822 * * Email: zm@csnet1.cs.tsinghua.edu.cn * ***************************************************************** From Rogerio.Andrade@Embrapa.br Tue Feb 13 02:40:57 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id CAA06175 for ; Tue, 13 Feb 2001 02:40:51 -0800 (PST) Received: from cacau.sede.embrapa.br (cacau.sede.embrapa.br [200.202.168.13]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1DAeXs08076 for ; Tue, 13 Feb 2001 02:40:42 -0800 (PST) Received: from arroz.sede.embrapa.br (arroz.sede.embrapa.br [10.10.10.31]) by mamona.sede.embrapa.br (8.10.1/8.10.1) with ESMTP id f1DAeJh14011; Tue, 13 Feb 2001 07:40:19 -0300 (EST) Received: from Embrapa.br (milheto [10.10.20.10]) by arroz.sede.embrapa.br (8.11.0/8.11.0) with ESMTP id f1DAeBP23305; Tue, 13 Feb 2001 07:40:18 -0300 (EST) Message-ID: <3A890ECD.A04F4EFC@Embrapa.br> Date: Tue, 13 Feb 2001 07:39:09 -0300 From: Rogerio de Carvalho Andrade X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Zhang Miao CC: "end2end-interest@isi.edu" , jamel@cin.ufpe.br Subject: Re: [e2e] Can feedback be generated more fast in ECN? References: <200102120131.JAA01174@csnet1.cs.tsinghua.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 109 Hi, Zhang. We have discussed it some time ago. I worked with this kind of "reverse notification" in my master dissertation (finished last month) using ICMP-SQM. We create an algorithm, named SQM-Response, that improve TCP congestion control mechanism. If you (all) are interested, you can download a postscript version of my dissertation from http://www.cin.ufpe.br/~rca3/tese/ (in portuguese) Andrade, Rogerio. "Algoritmo SQM-Response para Controle de Congestionamento do TCP em Redes com QoS" - UFPE - 2001 (in portuguese) - http://www.cin.ufpe.br/~rca3/tese/ We are working on a paper (in english) about it and we intend to submit it soon! Best regards, Rogerio. Zhang Miao wrote: > > Hi, > In ECN-RED, router only marks the packet and let the receiving end to "echo" the > congestion notification to the sender. > I have a naive question. Can the feedback be sent directly from the congested router > to the TCP sender? > Some schemes of action at router are listed here: > 1. Only mark the packet. (ECN) > 2. Mark the packet and send a feedback to TCP sender immediately. > 3. Send a feedback to TCP sender and drop the packet. > This scheme can be used for droptail. > > The advantages of sending a feedback directly: > 1. reduce the response time. > 2. reduce the loss probability of feedback. > consider the path of marked packet and the ACK with CN bit set. > > Disadvantages: > 1. add more burden the reverse direction of the link. > 2. add more burden to the router. > > Some mechanisms also need to be added to TCP to cope with the duplicate feedback > in scheme 2. > > The designer of ECN must have thought of the scheme above. Can anyone tell me why > this scheme was not used when ECN was designed? > > Thanks! > > ***************************************************************** > * Zhang Miao * > * Ph.D candidate,Department of Computer Science & Technology * > * Tsinghua University,Beijing,China(100084) * > * Tel: (8610)-62785822 * > * Email: zm@csnet1.cs.tsinghua.edu.cn * > ***************************************************************** From Rogerio.Andrade@Embrapa.br Tue Feb 13 02:53:33 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id CAA07121 for ; Tue, 13 Feb 2001 02:53:31 -0800 (PST) Received: from cacau.sede.embrapa.br (cacau.sede.embrapa.br [200.202.168.13]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1DArFs09432 for ; Tue, 13 Feb 2001 02:53:17 -0800 (PST) Received: from arroz.sede.embrapa.br (arroz.sede.embrapa.br [10.10.10.31]) by mamona.sede.embrapa.br (8.10.1/8.10.1) with ESMTP id f1DAr1h14579; Tue, 13 Feb 2001 07:53:01 -0300 (EST) Received: from Embrapa.br (milheto [10.10.20.10]) by arroz.sede.embrapa.br (8.11.0/8.11.0) with ESMTP id f1DAr3P24477; Tue, 13 Feb 2001 07:53:04 -0300 (EST) Message-ID: <3A8911D0.F2A3EA0C@Embrapa.br> Date: Tue, 13 Feb 2001 07:52:00 -0300 From: Rogerio de Carvalho Andrade X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Zhang Miao CC: Hong Bin Liao , "end2end-interest@isi.edu" Subject: Re: [e2e] Can feedback be generated more fast in ECN? References: <200102120710.PAA01731@csnet1.cs.tsinghua.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 110 Zhang Miao wrote: ... > (2) About the additional load > If Source Quench introduces additional load to the network, ECN also does. > Perhaps in ECN, the congestion will influence more broad than in Source Quench. > (For the congestion will be "echoed" by the congested router with Source Quench). > Addtionally, if the link is congested in one direction, can we deduce that the link > is also congested in the reverse direction. The more often scenario is links > with heterogenous load in the two directions. Correct! And I say more: if you can notificate congestions more quikly, you will have less dropped packets in a connection, that is, less congestion. []'s Rogerio. From floyd@elk.aciri.org Tue Feb 13 11:23:35 2001 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24723 for ; Tue, 13 Feb 2001 11:23:35 -0800 (PST) Received: from elk.aciri.org (elk.aciri.org [192.150.187.21]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f1DJNYs05527 for ; Tue, 13 Feb 2001 11:23:35 -0800 (PST) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.11.1/8.11.1) with ESMTP id f1DJL2559689; Tue, 13 Feb 2001 11:21:03 -0800 (PST) (envelope-from floyd@elk.aciri.org) Message-Id: <200102131921.f1DJL2559689@elk.aciri.org> To: Zhang Miao cc: "end2end-interest@isi.edu" From: Sally Floyd Subject: Re: [e2e] Can feedback be generated more fast in ECN? Date: Tue, 13 Feb 2001 11:21:02 -0800 Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 111 For more recent (1997 and 1998) discussions of reasons not to choose Source Quench as the default congestion notification mechanism, you would read the two notes "ECN vs. Source Quench" and "Addendum on Source Quench" listed at the bottom of the ECN web page at "http://www.aciri.org/floyd/ecn.html". I am also appending the second of these two notes below. - Sally Addendum on Source Quench: > To: braden@ISI.EDU > Subject: Re: Source Quench > Date: Thu, 07 May 1998 11:20:27 PDT > From: Sally Floyd > > ... > > These are all of the reasons that I can know for not doing > Source Quench: > > (1) It is not a general solution, particularly for multicast. Some > connections have receiver-based congestion control instead of > sender-based congestion control. (And in addition, one would not like > to have a "Source Quench" implosion in a multicast tree.) > > (2) Source Quench packets can be dropped, so they are not reliable. If > data packets in the forward direction carrying the CE (Congestion > Experienced) bit are dropped, then the application detects packet drops > and uses packet drops as an indication of congestion, so this is a > robust indication of congestion. And there are robust mechanisms that > receivers can use to inform senders that a packet has been received > with the CE (Congestion Experienced) bit set. > > (3) Even if well-done, Source Quench packets add traffic in the > reverse direction on what might be a congested path. > > (4) While there are some applications/environments where it might be > highly advantageous for the sender to receive some indication of > congestion without having to wait a roundtrip time, this is not the > common case. This is particularly true for a environment with active > queue management, which is the kind of environment that is most likely > to be using some new form of congestion indication. > > - Sally From touch@ISI.EDU Tue Feb 13 12:01:01 2001 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id MAA00145 for ; Tue, 13 Feb 2001 12:01:00 -0800 (PST) Message-ID: <3A8990EA.D6D80971@isi.edu> Date: Tue, 13 Feb 2001 11:54:18 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: end2end-interest@postel.org References: <200102120131.JAA01174@csnet1.cs.tsinghua.edu.cn> <3A890ECD.A04F4EFC@Embrapa.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] reminder about relocation of this list to postel.org Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 112 Just a reminder: end2end-interest has MOVED to postel.org Please direct your posts there; the isi.edu version will be taken down later today... Thanks, Joe (list coordinator) From matta@cs.bu.edu Tue Feb 13 15:14:56 2001 Received: from cs.bu.edu (root@CS.BU.EDU [128.197.10.2] (may be forged)) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA26124 for ; Tue, 13 Feb 2001 15:14:56 -0800 (PST) Received: from cs.bu.edu (matta@memphis [128.197.10.43]) by cs.bu.edu (8.10.1/8.10.1) with ESMTP id f1DNEjK17717; Tue, 13 Feb 2001 18:14:45 -0500 (EST) Message-ID: <3A89BFE3.4F638655@cs.bu.edu> Date: Tue, 13 Feb 2001 18:14:43 -0500 From: Ibrahim Matta Organization: Boston University, Computer Science Department X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: te-wg@UU.NET, irtf-rr@puck.nether.net, end2end-interest@postel.org, diffserv-interest@external.cisco.com, tccc@ieee.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [e2e] CFP IEEE Comm "Internet Quality of Service Routing" Sender: end2end-interest-admin@postel.org Errors-To: end2end-interest-admin@postel.org X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk List-Help: List-Archive: Status: RO X-Status: X-Keywords: X-UID: 113 Call For Papers IEEE Communications Magazine Feature Topic on "Internet Quality of Service Routing" URL: http://www.cs.bu.edu/faculty/matta/cfp/qosr.html Guest Editors: _____________ Marwan M. Krunz Ibrahim Matta Dept. Electrical & Computer Eng. Computer Science Dept. University of Arizona Boston University Tucson, AZ 85721 Boston, MA 02215 Email: krunz@ece.arizona.edu Email: matta@cs.bu.edu Phone: (520) 621-8731 Phone: (617) 358-1062 Fax: (520) 621-3862 Fax: (617) 353-6457 Scope: ______ QoS routing represents a radical shift from the traditional connectivity-based approach of currently deployed intra-domain (e.g., OSPF) and inter-domain (e.g., BGP) routing protocols. It calls for QoS-sensitive scalable solutions for path selection, state dissemination, multicasting, and topology aggregation. Emerging Internet services such as Differentiated Services (Diffserv) and Multi-Protocol Label Switching (MPLS) are likely to both require and justify the need for QoS-based routing solutions. This is reflected in a number of recent standardization activities that acknowledge the importance of QoS routing and that call for efficient, scalable solutions to it. Nonetheless, it has been recently recognized that existing QoS routing solutions have been developed "at some distance from the task of development of QoS architectures." In particular, current QoS architectural models, including Diffserv, seem to implicitly assume that various classes of traffic are forwarded along the same (best-effort) path, with service differentiation being achieved locally through appropriate packet scheduling at each router. Decoupling routing and QoS provisioning can lead to "inefficient" selection of routes, reducing the likelihood of meeting the applications' end-to-end QoS requirements. In recent years, extensive research has been published on QoS routing mechanisms, often in the context of traffic engineering. Several issues have been adequately addressed, while others remain to be tackled. The purpose of this Feature Topic is to summarize the state-of-the-art in QoS routing research. We solicit tutorial research articles and surveys that report on experimental and theoretical studies related to QoS routing. Topics of interest include, but are not limited to