From craig at bbn.com Tue Jun 1 02:57:41 2004 From: craig at bbn.com (Craig Partridge) Date: Tue Jun 1 02:58:46 2004 Subject: [e2e] How could I know one RTT estimation techniques better than the other? In-Reply-To: Your message of "Fri, 28 May 2004 22:40:47 +0800." <1085755247.40b74f6f9f261@www.e-web.uum.edu.my> Message-ID: <20040601095742.F195F1AB@aland.bbn.com> I don't think anyone's ever studied in great detail what the standards for an RTT estimation algorithm should be. However, what people have typically used in the path is something like this. First, remember that the key issue is the RTO algorithm -- the RTT estimator is used to set a timeout function using the RTO value -- and what you really care about is when a timeout goes off. Given you are evaluating when timeouts occur, there are two goals: 1. Few or no spurious timeouts. That is, if the timeout goes off, the packet is, with very high probability, lost. Furthermore, this is with very high probability over just about any network path you can imagine (including flapping network lines, wireless, etc). 2. Timeouts that occur soon in cases where a packet is really lost. In short, the perfect RTO algorithm would never timeout when a packet isn't lost, and timeout the moment a packet is lost. The goals are ordered -- if you've got lots of spurious timeouts, your algorithm is no good. If timeouts take a little while when packets are lost, that's OK. Thanks! Craig In message <1085755247.40b74f6f9f261@www.e-web.uum.edu.my>, "Osman Ghazali (FTM )" writes: >Hi, >I have two layered multicast protocols (LMPs). The protocols use different >RTT eatimation techniques. I created another LMP exactly the same >as the first LMP but with the second LMP's RTT estimation technique.The >problem I have now is how could I know which RTT estimation is more >appropriate/accurate/better for layered multicast. Is there any metric >for RTT or any way we can evaluate RTT estimation techniques. > >Thank you. >Osman From craig at bbn.com Tue Jun 1 05:54:22 2004 From: craig at bbn.com (Craig Partridge) Date: Tue Jun 1 05:55:05 2004 Subject: [e2e] How could I know one RTT estimation techniques better thanthe other? In-Reply-To: Your message of "Tue, 01 Jun 2004 07:25:09 EDT." <003601c447cb$19425fd0$f4fea8c0@IBM4280A0F5353> Message-ID: <20040601125422.478401AC@aland.bbn.com> Hi Hari: Your point about RTT estimation to manage pacing is one I'd overlooked. Many thanks! I'm not sure I agree however, with your metrics. In the late 80s and early 90s, there was a lot of discussion about how fast the RTT estimator should react, and as I recall the discussion, the key requirements were that the RTT estimator should be fairly robust against short-term transients (esp. conditions that typically varied over an RTT -- such as queue length) and also be aggressive about accepting bad news (longer RTTs), while conservative about accepting good news (shorter RTTs) So I don't think RTT estimation vis-a-vis cross traffic is quite the right measure. But I'm not sure I know what is. Craig From hannes.ekstrom at ericsson.com Tue Jun 1 06:37:00 2004 From: hannes.ekstrom at ericsson.com (=?ISO-8859-1?Q?Hannes_Ekstr=F6m_=28KI/EAB=29?=) Date: Tue Jun 1 06:47:06 2004 Subject: [e2e] How could I know one RTT estimation techniques better t han the other? Message-ID: <034BEFD03799D411A59F00508BDF75460D71DB51@esealnt448.al.sw.ericsson.se> Hi, we wrote a paper for this year's Infocom, where we propose a new retransmission timer for TCP. For the evaluation, we used a set of metrics that you may find useful. You can find the paper here: http://www.ieee-infocom.org/2004/Papers/52_3.PDF /Hannes -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org]On Behalf Of Craig Partridge Sent: den 1 juni 2004 11:58 To: Osman Ghazali (FTM) Cc: end2end-interest@postel.org Subject: Re: [e2e] How could I know one RTT estimation techniques better than the other? I don't think anyone's ever studied in great detail what the standards for an RTT estimation algorithm should be. However, what people have typically used in the path is something like this. First, remember that the key issue is the RTO algorithm -- the RTT estimator is used to set a timeout function using the RTO value -- and what you really care about is when a timeout goes off. Given you are evaluating when timeouts occur, there are two goals: 1. Few or no spurious timeouts. That is, if the timeout goes off, the packet is, with very high probability, lost. Furthermore, this is with very high probability over just about any network path you can imagine (including flapping network lines, wireless, etc). 2. Timeouts that occur soon in cases where a packet is really lost. In short, the perfect RTO algorithm would never timeout when a packet isn't lost, and timeout the moment a packet is lost. The goals are ordered -- if you've got lots of spurious timeouts, your algorithm is no good. If timeouts take a little while when packets are lost, that's OK. Thanks! Craig In message <1085755247.40b74f6f9f261@www.e-web.uum.edu.my>, "Osman Ghazali (FTM )" writes: >Hi, >I have two layered multicast protocols (LMPs). The protocols use different >RTT eatimation techniques. I created another LMP exactly the same >as the first LMP but with the second LMP's RTT estimation technique.The >problem I have now is how could I know which RTT estimation is more >appropriate/accurate/better for layered multicast. Is there any metric >for RTT or any way we can evaluate RTT estimation techniques. > >Thank you. >Osman From rik at rikwade.com Tue Jun 1 07:13:53 2004 From: rik at rikwade.com (Rik Wade) Date: Tue Jun 1 07:14:06 2004 Subject: [e2e] How could I know one RTT estimation techniques better thanthe other? In-Reply-To: <20040601125422.478401AC@aland.bbn.com> References: <20040601125422.478401AC@aland.bbn.com> Message-ID: <40BC8F21.1040905@rikwade.com> Craig Partridge wrote: >I'm not sure I agree however, with your metrics. In the late 80s and >early 90s, there was a lot of discussion about how fast the RTT >estimator should react, and as I recall the discussion, the key >requirements were that the RTT estimator should be fairly robust >against short-term transients (esp. conditions that typically varied >over an RTT -- such as queue length) and also be aggressive about >accepting bad news (longer RTTs), while conservative about accepting >good news (shorter RTTs) > > I did quite a bit of work with RTT and throughput estimation for transport protocols as part of my PhD. I was mainly looking at ways and means of pro-actively avoiding congestion, so began by looking at the work done in TCP Vegas and others. My final estimator implementation was somewhat simplified and looked solely at variation in RTT rather than computing throughput estimations. I found this to work well, at least in a simulation environment (ns-2). My protocol used variation in RTT to adjust the flow of tokens in to a token bucket, replacing the traditional congestion window and providing a bit more flexibility in terms of burstabiltiy and shaping. I would second the issue that Craig mentions above. The tuning of this component is down to the speed at which it reacts to these values. I did most of my work in simulation, but I would definitely recommend supporting it with practical experiments on a live network. I, for one, found simulation to be a bit too clinical to get a feel for how a "real" protocol should react to these RTT figures. One of my items of future work was to consider how a protocol may be "self-tuning" in this sense because one thing I learned was that hard-wired values in protocols can be a Bad Thing and certainly don't transfer well from a simulated to live environment. This could, however, just be down to my skill with ns-2 ;-) -- Rik Wade From dpreed at reed.com Tue Jun 1 07:17:40 2004 From: dpreed at reed.com (David P. Reed) Date: Tue Jun 1 07:31:06 2004 Subject: [e2e] How could I know one RTT estimation techniques better than In-Reply-To: <20040601095742.F195F1AB@aland.bbn.com> References: <20040601095742.F195F1AB@aland.bbn.com> Message-ID: <6.0.1.1.2.20040601100858.05420ec0@127.0.0.1> Good points. I don't think it is wise to decouple the algorithm too much from its use - it only needs to be accurate when the data is actually used. There is another point underlying this - the RTT estimator generates results which are used as a function of the input event time (the sending of a message expected to be acknowledged, usually). The measure needs to become available at about the time the RTO would be used - which is the time of expected arrival itself. So there are a finite number of points when the statistic used to evaluate the RTT estimator must be evaluated - all other points in time do not exist from the point of view of quality statistics. For this reason, decoupling the RTT quality statistic from the actual packet send/arrival event stream seems to be problematic. At 05:57 AM 6/1/2004, Craig Partridge wrote: >I don't think anyone's ever studied in great detail what the standards >for an RTT estimation algorithm should be. However, what people have >typically used in the path is something like this. > >First, remember that the key issue is the RTO algorithm -- the RTT >estimator is used to set a timeout function using the RTO value -- and >what you really care about is when a timeout goes off. > >Given you are evaluating when timeouts occur, there are two goals: > > 1. Few or no spurious timeouts. That is, if the timeout goes off, > the packet is, with very high probability, lost. Furthermore, this > is with very high probability over just about any network path > you can imagine (including flapping network lines, wireless, etc). > > 2. Timeouts that occur soon in cases where a packet is really lost. > >In short, the perfect RTO algorithm would never timeout when a packet isn't >lost, and timeout the moment a packet is lost. > >The goals are ordered -- if you've got lots of spurious timeouts, your >algorithm is no good. If timeouts take a little while when packets are >lost, that's OK. > >Thanks! > >Craig > > >In message <1085755247.40b74f6f9f261@www.e-web.uum.edu.my>, "Osman Ghazali >(FTM >)" writes: > > >Hi, > >I have two layered multicast protocols (LMPs). The protocols use different > >RTT eatimation techniques. I created another LMP exactly the same > >as the first LMP but with the second LMP's RTT estimation technique.The > >problem I have now is how could I know which RTT estimation is more > >appropriate/accurate/better for layered multicast. Is there any metric > >for RTT or any way we can evaluate RTT estimation techniques. > > > >Thank you. > >Osman From surendar at cse.nd.edu Tue Jun 1 16:08:46 2004 From: surendar at cse.nd.edu (Surendar Chandra) Date: Tue Jun 1 16:08:10 2004 Subject: [e2e] Deadline Extended: IEEE SECON 2004 Message-ID: <20040601230846.GA24023@sys.cse.nd.edu> ========================================================================== CALL FOR PAPERS IEEE SECON 2004 First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks Technically Co-Sponsored By: IEEE ComSoc TCCC Santa Clara, California October 4-7, 2004 Paper submissions due (via EDAS): June 7, 2004 ******** (EXTENDED TO JUNE 13, 11.59PM PDT - FIRM DEADLINE) ******** http://www.ieee-secon.org/2004 ========================================================================== The convergence of the Internet, communications and information technologies, coupled with recent engineering advances, is paving the way for a new generation of inexpensive mobile devices, sensors and actuators. It is the distributed and ad hoc deployment of networks of these network devices and sensors that bears promises for a significant impact, not only on science and engineering, but equally importantly on a broad range of applications relating to critical infrastructure protection and security, health care, the environment, energy, food safety, production processing, quality of life, and the economy. This new IEEE Communications Society conference will provide a forum to exchange ideas, techniques, and applications, discuss best practices, raise awareness and share experiences among researchers, practitioners, standard developers and policy makers in the field of sensor and ad hoc networks and systems. The conference will be organized to provide for a degree of collegiality and continuity in the discussions of the various topics among participants from the industrial, governmental and academic sectors. Original technical papers, which address the communications, networking, systems and algorithmic aspects of ad hoc and sensor networks, as well as those that describe practical deployment and implementation experiences are solicited for presentation at the conference and publication in the conference proceedings. Papers presenting novel contributions in such disciplines as digital signal processing, communications, networking protocols and architectures, algorithms, embedded systems, middleware and information management, and novel applications are solicited. PAPERS: Two types of submissions will be accepted for review in this conference: * FULL papers describing original, previously unpublished research work, experimental efforts, practical experiences, and industrial and commercial developments in sensor and ad hoc communications and networks. Papers with a deep focus on a specific discipline or stimulated by the synergistic interaction of diverse disciplines are encouraged. * SHORT papers focusing on future research directions, industry challenges and novel approaches in the field of sensor and ad hoc communications and networks. Papers in this category must be visionary, innovative and forward- looking. Particular topics of interest include, but are not limited to: * New architectures, protocols and access control to support communication, localization, time synchronization, routing and data dissemination in heterogeneous, large-scale distributed, ad hoc networks and sensor networks * Novel algorithms and theories for management, supervisory control and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Industrial and commercial developments and applications * Modeling and performance evaluation of large-scale distributed and ad hoc sensor networks, practical implementations, and real-work experiences * Theories and models on fundamental information and communication aspects of wireless ad hoc and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and ad hoc networks * Integration of sensors into engineered systems, including novel techniques for sensor renewable power sources, mechanisms for on-sensor self- calibration and self-testing and efficient schemes to maximize accuracy and minimize false alarms * Chip-based systems incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware and tools for ad hoc and sensor network applications development, deployment and management TUTORIALS AND PANELS: Proposals for tutorials and panels on current topics in the field of ad hoc and sensor networking and applications are solicited. Panels related to the commercial application and development of sensors and ad hoc networks are especially encouraged. DEMOS AND EXPO: Demonstrations that showcase the practical implementations, industrial and commercial developments, and new applications for ad hoc and sensor networks are solicited. SUBMISSION AND REVIEW PROCESS: * All submissions will be handled electronically via EDAS (http://edas.info). Please refer to the appropriate link and information at the conference website, http://www.ieee-secon.org/2004. * The conference will only accept for review original papers that have not been previously published and are not currently under review by another conference or journal. All submissions will be handled electronically and must be in PDF or PostScript format. * The length of FULL papers (describing original, previously unpublished research work, experimental efforts, practical experiences, etc.) must NOT exceed 10 IEEE conference-style pages (US "Letter" size, 8.5 x 11 inches) including text, figures and references, in two-column, single-space format, with a font size of 11 points. * The length of SHORT papers (focusing on future research directions, industry challenges, highly novel approaches, etc.) must not exceed 6 IEEE conference-style pages (US "Letter" size, 8.5 x 11 inches) including text, figures and references, in two-column, single-space format, with a font size of 11 points. * Papers not following these guidelines will be rejected. * All submissions will be reviewed for technical merits and relevance to the conference. * Accepted papers will be published in the conference proceedings. IMPORTANT DATES: Paper submissions due: June 7, 2004 (Extended to June 13, 11.59PM PDT) Tutorial/Panel Proposals due: July 12, 2004 Notification date: August 1, 2004 Camera-ready version due: August 20, 2004 GENERAL CHAIR: Taieb Znati, University of Pittsburgh, and NSF znati@cs.pitt.edu GENERAL VICE-CHAIR: C. S. Raghavendra, University of Southern California raghu@usc.edu TECHNICAL PROGRAM CO-CHAIRS: Sung-Ju Lee Prasant Mohapatra Krishna Sivalingam HP Laboratories UC Davis UMBC sjlee@hpl.hp.com prasant@cs.ucdavis.edu krishna@umbc.edu PANELS CHAIR: Fred Bauer, fred@fredbauer.com TUTORIALS CO-CHAIRS: Tom LaPorta, Pennsylvania State University, tlp@cse.psu.edu Cedric Westphal, Nokia, cedric.westphal@nokia.com PUBLICITY CHAIR: Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu For more information, please visit the conference website http://www.ieee-secon.org/2004 or contact one of the conference co-chairs. TECHNICAL PROGRAM COMMITTEE Prathima Agrawal, Auburn Kevin Almeroth, UCSB Mary Baker, HP Labs Suman Banerjee, University of Wisconsin Stefano Basagni, Northeastern Elizabeth Belding-Royer, UCSB Christian Bettstetter, DoCoMo Euro-Labs Philippe Bonnet, University of Copenhagen Andrew Campbell, Columbia Erdal Cayirci, Istanbul Technical University Surendar Chandra, Notre Dame Marco Conti, IIT Institute - CNR Pisa David Culler, UC Berkeley Samir Das, SUNY Stony Brook Anthony Ephremides, University of Maryland Deborah Estrin, UCLA John Fisher, MIT JJ Garcia-Luna-Aceves, UCSC Mario Gerla, UCLA Silvia Giordano, SUPSI of Lugano Zygmunt Haas, Cornell University Richard Han, University of Colorado Paul Havinga, University of Twente Wendi Heinzelman, University of Rochester Sanjay Jha, UNSW, Sydney Anupam Joshi, UMBC Sneha Kasera, Utah Young-Bae Ko, Ajou University Robin Kravetz, UIUC Bhaskar Krishnamachari, USC Lakshman Krishnamurthy, Intel Srikanth Krishnamurthy, UCR Marwan Krunz, Arizona P.R. Kumar, UIUC Kevin Lai, HP Koen Langendoen, Delft University of Technology Bo Li, Hong Kong University of Science and Technology Li Li, Bell Labs, Lucent Technologies Mingyan Liu, Michigan Richard Martin, Rutgers University Seapahn Megerian, University of Wisconsin Lynette Millett, The National Academies Thyagarajan Nandagopal (Bell Labs, Lucent Technologies) Peng Ning, NCSU Charles Perkins, Nokia Research Center Lili Qiu, Microsoft Parmesh Ramanathan, University of Wisconsin Jason Redi, BBN Martin Reisslein, ASU Paolo Santi, CNR Andreas Savvides, Yale Curt Schurgers, UCSD Sergio Servetto, Cornell Rajeev Shorey, NUS Singapore Suresh Singh, Portland State Univ Emin Sirer, Cornell University Raghupathy Sivakumar, Georgia Tech. Mani Srivastava, UCLA John Stankovic, University of Virginia William Su, Boeing Gaurav Sukhatme, USC Yu-Chee Tseng, National Chiao-Tung Univ. Cedric Westphal, Nokia Stephen Wicker, Cornell Adam Wolisz, Technical University of Berlin Mark Yarvis, Intel Corporation Qian Zhang, Microsoft Research Asia Michele Zorzi, Universita'di Ferrara ========================================================================== From cngreddy at rediffmail.com Wed Jun 2 10:17:36 2004 From: cngreddy at rediffmail.com (its me gangs) Date: Wed Jun 2 10:18:14 2004 Subject: [e2e] information needed for my M.Tech Project Message-ID: <20040602171736.25920.qmail@webmail35.rediffmail.com> An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040602/d1780ad2/attachment.html -------------- next part -------------- Hi everybody, I am new baby of our networking family. I'm Gangadhara reddy doing M.Tech at National Institute of Technology,Calicut.( NDIA.) I am doing my one year M.Tech project in the area of internet measurement tools area. now i have 3 options. 1. developing a new tool to measure any quatity (like capacity,TCP throughput..etc.,) 2.using existing tool, developing any application(eg: auto tuning of TCP buffer size depending on the Available bandwidth of the end-end ptah to increase the throughput of TCP conection.) 3. modification of existing tool by relaxing it's assumptions. so what way it will be good for me. and pls . give me some of the potential problems which i can take it as a project. waiting for u r suggestions...... yours sincerely, gangadhar From touch at ISI.EDU Fri Jun 25 16:02:11 2004 From: touch at ISI.EDU (Joe Touch) Date: Fri Jun 25 16:02:50 2004 Subject: [e2e] test - please ignore Message-ID: <40DCAEF3.6010800@isi.edu> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040625/76a86ced/signature.bin From b_a_denny at yahoo.com Thu Jun 24 14:27:11 2004 From: b_a_denny at yahoo.com (Barbara Denny) Date: Fri Jun 25 16:49:49 2004 Subject: [e2e] Charlie Lynn Message-ID: <20040624212711.29937.qmail@web14309.mail.yahoo.com> It was with great sadness and shock that I learned Charlie Lynn died unexpectedly at his home on Monday. Charlie was a long-time contributor and supporter of the Internet and I am sure he has many friends on this mailing list. To those who may not have known Charlie, he was a great friend, mentor, and engineer who was always ready to lend a helping hand no matter when you needed him. He spent his entire career at BBN after receiving his Ph.D. from MIT and worked tirelessly on countless Internet research projects from its early beginnings. He never went after any attention for all his contributions but he helped us enormously. He will be greatly missed both personally and professionally. Services will be held in his upstate New York hometown. barbara __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From craig at bbn.com Fri Jun 25 06:26:57 2004 From: craig at bbn.com (Craig Partridge) Date: Fri Jun 25 16:49:50 2004 Subject: [e2e] sad news - Charlie Lynn passed away Message-ID: <20040625132657.EB0871A8@aland.bbn.com> Hi folks: I just learned this today. Charlie Lynn, whom several of you no doubt remember for his wonderful contributions to TCP implementations (as I recall he did the TOPS-20 TCP), network management, and the Wideband network, passed away on Monday. And lest that list of past accomplishments mislead you, Charlie was continuing to do outstanding work up until the day he died. Craig ***************************** Date: Thu, 24 Jun 2004 09:40:48 -0400 To: bbn-all@bbn.com From: Ed Campbell Subject: BBN-ALL:Sad News... We are very sorry to inform you that our colleague, Charlie Lynn, unexpectedly passed away at home this past Monday. Charlie spent his entire professional career at BBN, joining right after completing his Ph.D. at MIT. His long and productive career here touched many people. He enjoyed, and was very good at, mentoring both young and not-so-young engineers. Charlie often worked late into the night and on the weekends, but his colleagues always found him the easiest person to reach when they needed his help. He worked in many BBN departments over the years, most recently working within the Internetworking Research Department as a Division Scientist. His quiet presence will be sorely missed. Services for Charlie will be held in his hometown in upstate New York, and his friends at BBN will plan a remembrance in Cambridge at a later date. Ed Campbell From puddinghead_wilson007 at yahoo.co.uk Fri Jun 25 16:49:44 2004 From: puddinghead_wilson007 at yahoo.co.uk (=?iso-8859-1?q?Puddinhead=20Wilson?=) Date: Fri Jun 25 16:49:51 2004 Subject: [e2e] information needed for my M.Tech Project In-Reply-To: <20040602171736.25920.qmail@webmail35.rediffmail.com> Message-ID: <20040603095016.69711.qmail@web25107.mail.ukl.yahoo.com> Read Nagel's algorithm ;)................. --- its me gangs wrote: > Hi everybody, > I am new baby of our networking family. > I'm Gangadhara reddy doing M.Tech at National > Institute of Technology,Calicut.( NDIA.) I am doing > my one year M.Tech project in the area of internet > measurement tools area. > now i have 3 options. > > 1. developing a new tool to measure any > quatity (like > capacity,TCP throughput..etc.,) > 2.using existing tool, developing any > application(eg: auto > tuning of TCP buffer size depending on > the Available > bandwidth of the end-end ptah to > increase the throughput > of TCP conection.) > 3. modification of existing tool by > relaxing it's > assumptions. > > so what way it will be good for me. and pls . give > me some of the potential problems which i can take > it as a project. > > waiting for u r suggestions...... > > yours sincerely, > gangadhar ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From osman at uum.edu.my Fri Jun 25 16:49:45 2004 From: osman at uum.edu.my (Osman Ghazali (FTM)) Date: Fri Jun 25 16:49:52 2004 Subject: [e2e] A metric to evaluate RTT estimation techniques for layered (multi-rate) multicast protocols In-Reply-To: <1086227226.40be831a9b67b@www.e-web.uum.edu.my> References: <1086227226.40be831a9b67b@www.e-web.uum.edu.my> Message-ID: <1086327946.40c00c8a86b9a@www.e-web.uum.edu.my> Hi, I am referring to my previous email(How could I know a RTT estimation technique is better than other other estimation techniques) I am particularly interested in RTT estimation for layered multicast protocols (LMPs), where most of the protocols employ TCP throughput models to regulate their receiving rates. RTT estimation for layered multicast communication, however, due to the feedback implosion problem at the sender, is rather difficult than RTT estimation for unicast. I have got a number of RTT estimation techniques in my list, i.e. the techniques proposed by Luby, Basu, Rhee, etc. However, currently my problem is how to know which technique is the most appropriate technique for LMPs. Here, I prefer not to use the word accurate because I think for layered multicast communication, the most accurate RTT estimation is not necessary the most appropriate RTT estimation. There are other factors have to be considered, such as feedback implosion, processing overhead, etc. A metric would greatly help me to compare and evaluate those techniques. Alternatively I will evaluate the techniques based on the performance a LMP (indirect evaluation). I mean, I will perform many runs of a LMP, where each run will have the same setting and parameters but a different RTT estimation technique. Then, I will see how the LMP performs in each run. Finally, again, Is there any metric for RTT estimation techniques (for layered maulticast) ? or Any suggestion of how to evaluate RTT estimation techniques (for layered multicast) ? Thank you. Osman From osman at uum.edu.my Fri Jun 25 16:50:48 2004 From: osman at uum.edu.my (Osman Ghazali (FTM)) Date: Fri Jun 25 16:50:49 2004 Subject: [e2e] A metric to evaluate RTT estimation techniques for layered (multi-rate) multicast protocols Message-ID: <1086227226.40be831a9b67b@www.e-web.uum.edu.my> Hi, I am referring to my previous email(How could I know a RTT estimation technique is better than other other estimation techniques) I am particularly interested in RTT estimation for layered multicast protocols (LMPs), where most of the protocols employ TCP throughput models to regulate their receiving rates. RTT estimation for layered multicast communication, however, due to the feedback implosion problem at the sender, is rather difficult than RTT estimation for unicast. I have got a number of RTT estimation techniques in my list, i.e. the techniques proposed by Luby, Basu, Rhee, etc. However, currently my problem is how to know which technique is the most appropriate technique for LMPs. Here, I prefer not to use the word accurate because I think for layered multicast communication, the most accurate RTT estimation is not necessary the most appropriate RTT estimation. There are other factors have to be considered, such as feedback implosion, processing overhead, etc. A metric would greatly help me to compare and evaluate those techniques. Alternatively I will evaluate the techniques based on the performance a LMP (indirect evaluation). I mean, I will perform many runs of a LMP, where each run will have the same setting and parameters but a different RTT estimation technique. Then, I will see how the LMP performs in each run. Finally, again, Is there any metric for RTT estimation techniques (for layered maulticast) ? or Any suggestion of how to evaluate RTT estimation techniques (for layered multicast) ? Thank you. Osman From touch at ISI.EDU Fri Jun 25 16:59:48 2004 From: touch at ISI.EDU (Joe Touch) Date: Fri Jun 25 16:59:46 2004 Subject: [e2e] ASWN 2004 - Applications and Services in Wireless Networks - call for participation Message-ID: <40DCBC74.6080401@isi.edu> ======================================================================= Call For Participation http://csr.bu.edu/aswn2004 4th Workshop on Applications and Services in Wireless Networks Boston, Massachusetts, USA August 8-11, 2004 Sponsored by: IEEE Communications Society, IEEE TCPC, WWRF-WG2 REGISTRATION at http://csr.bu.edu/aswn2004/registration.html Highlights of ASWN 2004 ======================= * Keynote speech by Professor Andrew Campbell (Columbia University) on "Showstoppers for Sensors" * Invited talk by Professor Matt Welsh (Harvard University) on "Sensor Networks for Emergency Medical Care" * Presentations of peer-reviewed technical papers organized into eight sessions: + Resource Discovery and Management + Security and Accounting + Performance Modeling and Evaluation + Scheduling and Clustering + Overlay and P2P Services + Multimedia Transport + Routing and Mobility + Distributed and Middleware Services * A panel on latest research and developments * A Networking Reception (Poster Session/Industry Showcase) Speaker: Firas Abi-Nassif, Airvana, Inc. * Two half-day tutorials by Dr. Milind M. Buddhikot (Lucent Bell Labs): + Integrated Public Wireless Networks + Security in Public Wireless Networks Web Links ========= Technical Program at http://csr.bu.edu/aswn2004/schedule.html Committees at http://csr.bu.edu/aswn2004/committees.html Tutorials at http://csr.bu.edu/aswn2004/tutorial.html Registration at http://csr.bu.edu/aswn2004/registration.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040625/2a1e05da/signature.bin From touch at ISI.EDU Fri Jun 25 17:04:23 2004 From: touch at ISI.EDU (Joe Touch) Date: Fri Jun 25 17:04:49 2004 Subject: [e2e] SIGCOMM 2004 Call for Participation Message-ID: <40DCBD87.1090901@isi.edu> Call for Participation ACM SIGCOMM 2004 Conference August 30 - September 3, 2004 Portland, Oregon http://www.acm.org/sigcomm/sigcomm2004 Registration for SIGCOMM 2004 is now open! Advanced registration will be available till August 2. Important Dates: Early Registration ends August 2, 2004 Hotel Registration ends August 2, 2004 Student Grant application ends June 28, 2004 Technical Program is Tuesday August 31---Thursday September 2 Tutorials are Monday August 30, and Friday September 3 Workshops are Monday August 30, and Friday September 3 Highlights of SIGCOMM 2004 ------------------------------------------ ACM SIGCOMM is pleased to announce that the recipient of the 2004 SIGCOMM Award is Professor Simon Lam of University of Texas, Austin, who will give the keynote address in the opening session on Tuesday. The technical program consists of 31 refereed papers and includes four innovative Workshops and three Tutorials. The three tutorials are: * Traffic Modeling 101: Methods and Results for Single Links and Whole Networks, Mark Crovella, Boston University * Unwanted Traffic: Attacks, Detection and Potential Solutions, Dina Katabi, MIT and Balachander Krishnamurthy, AT & T Research * Architectural Considerations for Unusual and Challenged Networks, Kevin Fall, Intel Research and Robert Durst, The MITRE Corporation The four Workshops feature: * Future Directions in Network Architecture (FDNA-04), Kevin Fall, Intel Research and S. Keshav, U. of Waterloo * NetGames-04, Wu-chang Feng, Oregon Health and Science University * Workshop on Practice and Theory of Incentives and Game Theory in Networked Systems (PINS), Dina Katabi, MIT and Rahul Sami, MIT * Network Troubleshooting: Research, Theory and Operations Practice Meets Malfunctioning Reality (NeTs), Jon C. R. Bennett, Harvard University and Mark Allman, ICIR In addition, there will be an interesting poster session, a stimulating banquet, and, of course, a provocative outrageous opinions session! For details about registration and the conference, visit the conference web site at http://www.acm.org/sigcomm/sigcomm2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040625/9c6f89fb/signature.bin From wumin_noname at hotmail.com Sat Jun 26 17:29:18 2004 From: wumin_noname at hotmail.com (Wu Min) Date: Sat Jun 26 17:29:51 2004 Subject: [e2e] Premium Service Message-ID: I am wondering whether Premium service as described in `RFC 2638 - A Two-bit Differentiated Services Architecture for the Internet' is practical under congestive network in high speed backbone. _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo From legout at castify.net Mon Jun 28 02:45:30 2004 From: legout at castify.net (Arnaud Legout) Date: Mon Jun 28 02:46:54 2004 Subject: [e2e] A metric to evaluate RTT estimation techniques for layered (multi-rate) multicast protocols In-Reply-To: <1086327946.40c00c8a86b9a@www.e-web.uum.edu.my> References: <1086227226.40be831a9b67b@www.e-web.uum.edu.my> <1086327946.40c00c8a86b9a@www.e-web.uum.edu.my> Message-ID: <40DFE8BA.3070607@castify.net> Hi, Osman Ghazali (FTM) wrote: >Finally, again, >Is there any metric for RTT estimation techniques (for layered maulticast) ? >or >Any suggestion of how to evaluate RTT estimation techniques (for layered >multicast) ? > > it is not possible to answer such a question if you don't say what you want to do. In case you want to be TCP-friendly, find your worst receiver and measure the RTT with respect to him as if it is a unicast receiver. If you don't want to slow down too much your MC session, define a criteria to find a representative receiver. Here again, the problem is the same as for unicast RTT. In both cases, the problem is not RTT estimation, but representative receiver discovery. If you want to do something else, how do you use the RTT? If you have a layered multicast scheme, you probably have a receiver driven protocol. In this case does it make sense to use a RTT estimation, which supposes to send feedback to the source. In case you use OTT, is it relevant in your context (asymmetric links, etc.)? I know that I don't give any hint on how to measure the RTT for layered multicast, but I would like to stress that is is very dependent on what you want to do. Regards, Arnaud. -- ---------------------------------------------------------------------- Arnaud Legout, Ph.D. Castify Networks Phone : 00.33.4.93.00.27.07 2229, route des Cretes Fax : 06560 Sophia Antipolis E-mail: legout@castify.net FRANCE Web : http://www.castify.net ---------------------------------------------------------------------- From frasker at hotmail.com Wed Jun 30 14:56:29 2004 From: frasker at hotmail.com (Fat Bouy) Date: Wed Jun 30 14:57:01 2004 Subject: [e2e] DiffServ Message-ID: Hi, As far as I understand, Differentiated Service defines per-hop treatment only. How about routing, i.e., finding paths to route flows? I am not quite clear about this part. Does one use RSVP to setup path as well? _________________________________________________________________ Download the latest MSN Messenger http://messenger.msn.com.my