From le at cs.unc.edu Tue Sep 7 23:42:10 2004 From: le at cs.unc.edu (Long Le) Date: Tue Sep 7 23:43:28 2004 Subject: [e2e] Active queue management and Internet traffic characteristics Message-ID: <20040908064210.GB7451@quartet.cs.unc.edu> Hi all, One stated advantage of active queue management such as RED in RFC 2309 (Recommendations on Queue Management and Congestion Avoidance in the Internet) is that RED can reduce the number of dropped packets by keeping the average queue size small because it will provide greater capacity to absorb packet bursts when packet bursts occur. So keeping a small queue can result in higher throughput. My questions are: 1. On what time scales do packet bursts occur in the Internet (if at all)? 2. Is the argument above true in practice? 3. To keep the average queue size small, the router probably needs to drop some arriving packets (if ECN is not used). So isn't the argument above counterintuitive? Any answers and comments are greatly appreciated. Thanks, Long From armada_cn at hotmail.com Wed Sep 8 00:58:38 2004 From: armada_cn at hotmail.com (Ji Andy) Date: Wed Sep 8 00:59:17 2004 Subject: [e2e] Re: Active queue management and Internet traffic characteristics Message-ID: Hi, long, I am also thinking on the similar questions these days. Most AQM schemes proposed only consider packet marking under the condition that traffic traversing the bottleneck is constructed by some TCP connections. Unresponsive traffic and short-lived flows are just perturbation in these schemes. When considering the properties of aggregated traffic, e.g., self-similarity or burstiness in multiple time scale, it is difficult to stablize the queue and keep packet marking probability low at the same time. I have submitted a paper on this topic to ICC'05. Regards, -Andy _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com From nfonseca at ic.unicamp.br Wed Sep 8 13:42:23 2004 From: nfonseca at ic.unicamp.br (nfonseca@ic.unicamp.br) Date: Wed Sep 8 13:43:14 2004 Subject: [e2e] Re: end2end-interest Digest, Vol 7, Issue 1 In-Reply-To: <200409081900.i88J05J02316@boreas.isi.edu> References: <200409081900.i88J05J02316@boreas.isi.edu> Message-ID: <2991.200.213.176.130.1094676143.squirrel@webmail.ic.unicamp.br> Dra Lomg Le, In C.A. V. Melo and N.L.S. da Fonseca, `Statistical Multiplexing of Multifractal flows`in Proc of IEEE ICC 2004 the `time scale of interest` of a queue fed by multifractal flows is computed. The ?time scale of interest`is the time scale at which the queue reaches its maximum size. In this paper IP flows are modeled as multfractal processes. Real network traces are used to generate numerical examples. Envelope process (minimalist models) are used to model IP flows. You may also read Matta?s original paper about `mice and elephant` As far as I remember the authors?connect the LRD concept to AQM nelson Fonseca > Send end2end-interest mailing list submissions to > end2end-interest@postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.postel.org/mailman/listinfo/end2end-interest > or, via email, send a message with subject or body 'help' to > end2end-interest-request@postel.org > > You can reach the person managing the list at > end2end-interest-owner@postel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of end2end-interest digest..." > > > Today's Topics: > > 1. Active queue management and Internet traffic characteristics > (Long Le) > 2. Re: Active queue management and Internet traffic > characteristics (Ji Andy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 8 Sep 2004 02:42:10 -0400 > From: Long Le > Subject: [e2e] Active queue management and Internet traffic > characteristics > To: end2end-interest@postel.org > Message-ID: <20040908064210.GB7451@quartet.cs.unc.edu> > Content-Type: text/plain; charset=us-ascii > > Hi all, > > One stated advantage of active queue management such as RED > in RFC 2309 (Recommendations on Queue Management and Congestion > Avoidance in the Internet) is that RED can reduce the number of > dropped packets by keeping the average queue size small because > it will provide greater capacity to absorb packet bursts when > packet bursts occur. So keeping a small queue can result in > higher throughput. > > My questions are: > > 1. On what time scales do packet bursts occur in the Internet > (if at all)? > 2. Is the argument above true in practice? > 3. To keep the average queue size small, the router probably > needs to drop some arriving packets (if ECN is not used). So > isn't the argument above counterintuitive? > > Any answers and comments are greatly appreciated. > > Thanks, > Long > > > > ------------------------------ > > Message: 2 > Date: Wed, 08 Sep 2004 07:58:38 +0000 > From: "Ji Andy" > Subject: [e2e] Re: Active queue management and Internet traffic > characteristics > To: end2end-interest@postel.org > Cc: le@cs.unc.edu > Message-ID: > Content-Type: text/plain; charset=gb2312; format=flowed > > Hi, long, > > I am also thinking on the similar questions these days. Most AQM schemes > proposed only consider packet marking under the condition that traffic > traversing the bottleneck is constructed by some TCP connections. > Unresponsive traffic and short-lived flows are just perturbation in these > schemes. When considering the properties of aggregated traffic, e.g., > self-similarity or burstiness in multiple time scale, it is difficult to > stablize the queue and keep packet marking probability low at the same > time. > > I have submitted a paper on this topic to ICC'05. > > Regards, > > -Andy > > _________________________________________________________________ > ?????????????????????????????? MSN Hotmail?? http://www.hotmail.com > > > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest@postel.org > http://www.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 7, Issue 1 > ********************************************** > From bltierney at lbl.gov Wed Sep 8 16:23:08 2004 From: bltierney at lbl.gov (Brian Tierney) Date: Wed Sep 8 16:24:26 2004 Subject: [e2e] CFP: Pfldnet2005: Third International Workshop on Protocols for very Long Distance Networks Message-ID: <0AF824A8-01EE-11D9-9227-000393DC690A@lbl.gov> Call For Papers =============================== Third International Workshop on Protocols for Fast Long-Distance Networks Lyon, France Feb 3-4, 2005 Pfldnet2005 ------------------------------------------------------------------- http://www.ens-lyon.fr/LIP/RESO/pfldnet2005 pfldnet2005@ens-lyon.fr Fast long-distance networks (i.e., networks operating at 622 Mbit/s, 2.5 Gbit/s, or 10 Gbit/s and spanning several countries or states) are now becoming commonplace. More and more researchers now routinely transfer between 10 GB and multi-TB datasets over gigabit networks. Application domains for such massive transfers include data-intensive Grids (e.g., in Particle Physics, Earth Observation, Bio informatics, and Radio Astronomy), database mirroring for Web sites (e.g., in e-commerce), and push-based Web cache updates. Although the network infrastructure is now in place, or will soon be, the transport and application protocols available to date perform rather poorly over such networks. Current versions of TCP, for instance, recover very slowly from packet loss when the RTT and the link capacity are large, thus requiring a large congestion window for high throughput. A number of research teams have begun investigating these protocol issues. The First International Workshop on Protocols for Fast Long-Distance Networks and the Second International Workshop on Protocols for Fast Long-Distance Networks were very successful in bringing together many researchers from the U.S., Asia and Europe who are working on these problems. This workshop will continue this tradition, and provide a perfect setting for researchers in this area to exchange ideas and experience. This single-track workshop will provide researchers and technologists with a focused, highly interactive opportunity to present, discuss and exchange experience on leading research, development and future directions in high performance transport and application protocols (TCP, UDP, HTTP, FTP, etc.) over fast long-distance networks. This year, a particular emphasis will be on End Systems Issues (hardware and software). Each day will start with a plenary talk and end with a panel. In between, formal presentations of papers will be followed by extensive and informal Q&A sessions. Authors are invited to submit unpublished extended abstract for consideration. In order to facilitate discussions, attendance will be limited to 60 participants. Please register early to ensure your participation. Depending on the number of people who register, we may need to restrict the number of people from a given organization to allow for a broader representation of the research community. Registration will open on October 1, 2004. Call For Papers Participants wishing to present a paper should send a four-pages extended abstract to pfldnet2005@ens-lyon.fr by October 15 (2004). Authors whose abstracts are selected for presentation will have the option to submit a full paper, to be published on the PFLDnet 2005 web site and in the PFLDnet 2005 proceedings. We may try to collect the best papers for a special edition of a journal, if the authors are interested. Scope The Pfldnet2005 workshop will focus on research issues and challenges as well as lessons learned from experience. Topics of interest include and are not limited to: ? Protocol issues in fast long-distance networks ? TCP enhancements and their comparison ? Novel data transport protocols designed for new application services ? RDMA over WANs ? Effects of shaping on TCP and UDP traffic ? Effects of striping and multistreaming ? Bulk-data transfer applications both TCP and non-TCP based ? Data replication and multicasting strategies and protocols ? Simulation-based results ? Experiments on real networks and actual measurements ? Experience with different types of hardware (PCs, routers, switches, Gigabit Ethernet cards, etc.) Important Dates Extended Abstract Submission Deadline: Oct 15 Reviews due: Nov 19 Acceptance Notification: Dec 5 Final paper submission: Jan 21 Workshop: 3-4 february Committees Co-Chairs: Pascale Vicat-Blanc Primet, INRIA ENS Lyon - FR Richard Hughes-Jones, Univ Manchester - UK Cheng Jin, Caltech - USA Steering Committee: Brian L Tierney, Lawrence Berkeley National Lab - USA Linda Winkler, Argonne National Lab, USA R. Les Cottrell , Stanford Linear Accelerator Center - USA Technical Program Committee: Bill Allcock (ANL - USA) Eitan Altman (INRIA France) Richard Carlson (Internet 2 - USA) Andrew Chien (UCSD - USA) Peter Clarke (UCL - UK) Les Cottrell (Stanford Linear Accelerator Center (USA) Cees De Laat (UvA - NL) Michel Diaz (LAAS -CNRS - FR) Sally Floyd (ICIR - USA) Tomohiro Kudoh (AIST JP) Douglas Leith (Hamilton Institute- IR) Steven Low (California Institute of Technology, USA) Jason Leigh (UIC - USA) Olivier Martin (CERN- CH) Medy Sanadidi (UCLA - USA) Robin Tasker (CCLRC - UK) Brian L Tierney (LBNL - USA) Gab Montenegro (SUN Microsystems - US) Local Organization Committee: Olivier Gluck (LIP - ENS Lyon) Brice Goglin (LIP - ENS Lyon) Jean-Christophe Mignot (LIP - ENS Lyon) Sylvie Boyer (LIP - ENS Lyon) PFLDnet 2005 is sponsored by: FoundryNetworks IBM -HPC Juniper Networks From chuahn_2 at hotmail.com Fri Sep 10 06:17:46 2004 From: chuahn_2 at hotmail.com (Chua Hong Nung) Date: Fri Sep 10 06:18:23 2004 Subject: [e2e] Performance factors of TCP Equation Model Message-ID: Factors of TCP Equation Model Hi, Firstly sorry my English is not good, but I have an unresolved problem which need an answer. TCP Equation Model of Padhye et al. is a function of RTT, RTO, loss rate and MSS. Since most researcher substitute RTO with 4RTT, the only parameters determine estimated throughputs are RTT and loss rate. I have been thinking these two scenarios for quite a long time, but still unresolved. Scenario 1: Bottleneck 400Kbps Share between 3 TCP flows and a TCP-Friendly Protocol flow. Ideally, fair bandwidth share is 100Kbps for each flow. Routers’ queue sizes are set to bandwidth delay product. Minimum RTT for TCP-Friendly flow is 44ms. Sources-------------Router----------------------Router----------------------Sinks 1ms 20ms 1ms Scenario 2: Bottleneck 1Mbps Share between 9 TCP flows and a TCP-Friendly Protocol flow. Ideally, fair bandwidth share is 100Kbps for each flow. Routers’ queue sizes are set to bandwidth delay product. Minimum RTT for TCP-Friendly flow is 24ms. Sources-------------Router----------------------Router----------------------Sinks 1ms 10ms 1ms If the TCP-Friendly Protocol flows in both scenarios employ the same model (Padhye et al.), with different RTT how they will eventually achieve the ideal bandwidth share, i.e. 100Kbps. I can’t see loss rate can do that. Thank you Chua _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger From braden at ISI.EDU Fri Sep 10 10:32:06 2004 From: braden at ISI.EDU (Bob Braden) Date: Fri Sep 10 10:32:25 2004 Subject: [e2e] (Forwarding CFP) Message-ID: <200409101732.KAA15853@gra.isi.edu> ******************* CALL FOR PAPERS ********************** Passive & Active Measurement Workshop (PAM2005) Boston, MA Mar 31-Apr 1, 2005 http://www.pam2005.org/ ********************************************************** IMPORTANT DATES: * Paper Submission: October 8, 2004 * Author Notification: December 10, 2004 * Camera Ready: January 20, 2005 CONFERENCE INFORMATION PAM'05, the sixth PAM workshop, is a two-day event focusing on research and practical applications of passive and active measurement and analysis techniques. Original papers describing novel work-in-progress are invited from the research, provider, and other communities on topics including, but not limited to: * Active Network Measurements * Passive Network Measurements * Performance Metrics * Traffic Statistics * Measurement Visualization * New Measurement Approaches & Techniques * Deployment of Measurement Infrastructure * New Measurement Initiatives * Applications of Network Measurements * Network Measurements and Security * Network Troubleshooting using Measurements * Embedded and Reconfigurable Hardware for Network Measurements Student participation is strongly encouraged. PAM has a tradition of being a true workshop with lively discussion and active participation from all attendees. As such, we favor submissions reporting exciting on-going work. SUBMISSION INFORMATION To ensure PAM2005 is fresh and interesting, we are soliciting extended abstracts in the first instance. These should be at most FOUR pages in length in the standard IEEE double-column format. The abstracts should present work-in-progress, explaining the basic approach and motivation. Comprehensive results are not expected at this stage, although the authors should comment on the results they expect to obtain; there are 3.5 months between the abstract submission and camera ready deadlines. If selected for publication, authors will be expected to produce an 8-10 page paper including results and validation. TECHNICAL PROGRAM COMMITTEE Constantine Dovrolis (Program Chair) Georgia Tech Suman Banerjee University of Wisconsin Chadi Barakat INRIA Supratik Bhattacharyya Sprint ATL Andre Broido CAIDA Nevil Brownlee University of Auckland Neal Cardwell Google K Claffy CAIDA Les Cottrell SLAC Mark Crovella Boston University Christophe Diot Intel Research Avi Freedman Akamai Ian Graham Endace Khaled Harfoush North Carolina State University Loki Jorgenson Apparent Networks Simon Leinen Switch David Meyer Cisco Systems Dina Papagiannaki Intel Research Ian Pratt University of Cambridge Matt Roughan University of Adelaide Kave Salamatian CNRS/LIP6 Anees Shaikh IBM T.J.Watson Patrick Thiran EPFL Alex Tudor Agilent Steve Uhlig Universite Catholique de Louvain Darryl Veitch University of Melbourne Apologies if you receive multiple copies of this CFP, but please forward to anyone you believe may be interested -- thanks! For any additional information, please contact Constantine Dovrolis (dovrolis@cc.gatech.edu). From ygu1 at cs.uic.edu Fri Sep 10 13:22:03 2004 From: ygu1 at cs.uic.edu (Yunhong Gu1) Date: Fri Sep 10 13:24:27 2004 Subject: [e2e] Performance factors of TCP Equation Model In-Reply-To: References: Message-ID: > > If the TCP-Friendly Protocol flows in both scenarios employ the same model > (Padhye et > al.), with different RTT how they will eventually achieve the ideal > bandwidth share, i.e. > 100Kbps. I can’t see loss rate can do that. > Hi, Chua, Why do you think loss rate cannot do that? Although the RTT values are different in the two scenarios, the loss rate can also be different, and this formula could still reach same results. 1.3 * MTU / (RTT * sqrt(LossRate)) Of course if the RTT value is too large, TCP flows may not reach 100% utilization of the bandwidth. In this case, the formula can only help to reach fairness on the same link. For example, in senario 1, all flows may end at 90kbps, whereas in scenario 2, all flows may end at 95kbps. I think your assumption that all flows will reach 100kbps is where the confliction comes from. regards, Yunhong From label_label_label_label at yahoo.com Sun Sep 12 03:54:53 2004 From: label_label_label_label at yahoo.com (Zaphod Beeblebrox) Date: Sun Sep 12 03:55:29 2004 Subject: [e2e] a few questions on TCP mechanism Message-ID: <20040912105453.54129.qmail@web61204.mail.yahoo.com> Hi, I have the following scenario: Source------->----->destination ^ | | | -------------feedback--------- Packet flows from source to destination via the intermediate nodes. There are multiple sources and destinations in the network flowing over multiple nodes. The flow of each packet can be said to be an set of The intermediate nodes may not have sufficient bandwidth to cater to intermediate nodes. Flows may have overlapping intermediate nodes. So I wish to find a way to make the data flow faster and faster and faster and faster and.. even faster. Given that the feedback/rate of delivery can only be measured when the packets reach the end point, a. is it possible to have a steady state system where all flows get the amount of bandwidth they need, and yet all the sources are at a maximum value? In other words if there are 20 such flows and the network capacity is K, each should get K/20. Is this possible? b. If the only source of feedback is the destination point, how is it possible for me to: 1. adjust my window size in T < RTT 2. and even if I do 1, the mechanism must be to adjust it in such a way that other contending sources also adjust it accordingly to reach capacity/number_of_flows. I know most people on this list would point me to some excellent research papers, but if there are solutions that work, why have they not been implemented? Or do I come to the conclusion that this is the best we have? -ZB __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From craig at aland.bbn.com Mon Sep 13 06:39:11 2004 From: craig at aland.bbn.com (Craig Partridge) Date: Mon Sep 13 06:39:35 2004 Subject: [e2e] a few questions on TCP mechanism In-Reply-To: Your message of "Sun, 12 Sep 2004 03:54:53 PDT." <20040912105453.54129.qmail@web61204.mail.yahoo.com> Message-ID: <20040913133911.7D54C1AC@aland.bbn.com> In message <20040912105453.54129.qmail@web61204.mail.yahoo.com>, Zaphod Beebleb rox writes: >a. is it possible to have a steady state system where >all flows get the amount of bandwidth they need, and >yet all the sources are at a maximum value? >In other words if there are 20 such flows and the >network capacity is K, each should get K/20. >Is this possible? Sure. There are lots of ways to do it if K is static and flows are long lived. The problem is that K is not static and a large fraction of flows are short. >b. If the only source of feedback is the destination >point, how is it possible for me to: >1. adjust my window size in T < RTT In general, you shouldn't. As I understand control theory, if you adjust in times smaller than the RTT, your control loop is unstable. Craig From michael.welzl at uibk.ac.at Mon Sep 13 08:42:06 2004 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Mon Sep 13 08:40:35 2004 Subject: [e2e] a few questions on TCP mechanism References: <20040913133911.7D54C1AC@aland.bbn.com> Message-ID: <000901c499a8$39a533e0$0200a8c0@fun> > >b. If the only source of feedback is the destination > >point, how is it possible for me to: > >1. adjust my window size in T < RTT > > In general, you shouldn't. As I understand control theory, if you adjust > in times smaller than the RTT, your control loop is unstable. Great that you bring this up: it's something that I never really understood - how does this thinking translate to TCP, which updates the rate with every ACK it gets (a lot more often than once per RTT)? Is TCP actually interpolating? Cheers, Michael From michael.welzl at uibk.ac.at Tue Sep 14 03:52:26 2004 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Tue Sep 14 03:55:40 2004 Subject: [e2e] Congestion control is not mandatory? Message-ID: <1095159145.4823.68.camel@lap10-c703.uibk.ac.at> How come? This is curious ... it just occured to me that RFC 2581 is just a Proposed Standard. That means that I can build a fully conformant TCP/IP which does not do congestion control, doesn't it? This is just weird... or is there a particular reason for this? Cheers, Michael From faber at ISI.EDU Tue Sep 14 10:34:01 2004 From: faber at ISI.EDU (Ted Faber) Date: Tue Sep 14 10:34:53 2004 Subject: [e2e] Congestion control is not mandatory? In-Reply-To: <1095159145.4823.68.camel@lap10-c703.uibk.ac.at> References: <1095159145.4823.68.camel@lap10-c703.uibk.ac.at> Message-ID: <20040914173401.GA91659@pun.isi.edu> On Tue, Sep 14, 2004 at 12:52:26PM +0200, Michael Welzl wrote: > How come? > > This is curious ... it just occured to me that RFC 2581 is > just a Proposed Standard. > > That means that I can build a fully conformant TCP/IP > which does not do congestion control, doesn't it? RFC 1122 says (on page 89): Recent work by Jacobson [TCP:7] on Internet congestion and TCP retransmission stability has produced a transmission algorithm combining "slow start" with "congestion avoidance". A TCP MUST implement this algorithm. So that's a "no." Or maybe a MUST NOT. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040914/6f51e6f9/attachment.bin From michael.welzl at uibk.ac.at Tue Sep 14 15:02:42 2004 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Tue Sep 14 14:59:46 2004 Subject: AW: [e2e] Congestion control is not mandatory? In-Reply-To: <20040914173401.GA91659@pun.isi.edu> Message-ID: > > This is curious ... it just occured to me that RFC 2581 is > > just a Proposed Standard. > > > > That means that I can build a fully conformant TCP/IP > > which does not do congestion control, doesn't it? > > RFC 1122 says (on page 89): > > Recent work by Jacobson [TCP:7] on Internet congestion and TCP > retransmission stability has produced a transmission algorithm > combining "slow start" with "congestion avoidance". A TCP MUST > implement this algorithm. > > > So that's a "no." Or maybe a MUST NOT. Ok, so you answered my question. Still, there are the somewhat weird facts that i) here's a standard RFC referencing a paper (not an RFC) with MUST implement while there's an RFC that specifies what's needed, and ii) RFC 2581 is a Proposed Standard. Heck, if that is not a Standard, what is? Do we need more implementations? :-) Cheers, Michael From label_label_label_label at yahoo.com Wed Sep 15 01:18:03 2004 From: label_label_label_label at yahoo.com (Zaphod Beeblebrox) Date: Wed Sep 15 01:18:48 2004 Subject: [e2e] a few questions on TCP mechanism In-Reply-To: Message-ID: <20040915081803.80571.qmail@web61201.mail.yahoo.com> --- Lloyd Wood wrote: > On Mon, 13 Sep 2004, Craig Partridge wrote: > > Someone wishing to be anonymous wrote: > > >b. If the only source of feedback is the > destination > > >point, how is it possible for me to: > > >1. adjust my window size in T < RTT > > > > In general, you shouldn't. As I understand > control theory, if you adjust > > in times smaller than the RTT, your control loop > is unstable. > > [Looks up from paging through Kuo's Automatic > Control Systems, 5th Ed.] > > As I understand control theory, if you adjust in > times smaller than > the RTT, you're simply overdamping. That is not > quite the same thing > as having an unstable control loop where damping is > negative overall. If one defines unstablity as the equivalent of a "pole"/infinite oscillation condition, this is correct I guess. However I am not too sure what classifies the system as over/under or critcally damped I(z)----H(z)------O(z) | | ---G(z)--- O(z)=I(z).H(z)/(1+G(z)H(z)) and all relevant equations are valid if it was a node by node window and not an end to end window. It is very easy to come to an equation of critical damping for the above. Can you tell me what exactly makes you say that this is an overdamped system if T > Oversampling and input to a control system to do > overdamping is not in > itself a bad thing. But the math does seem to be a > little bit more > involved than the arithmetic done at discrete > arrival events by TCP > endpoints, and proving stability becomes a little > harder. > I agree, RTT may vary, an ACK may drop etc, Is this what you are trying to convey? _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From faber at ISI.EDU Wed Sep 15 10:22:13 2004 From: faber at ISI.EDU (Ted Faber) Date: Wed Sep 15 10:23:03 2004 Subject: [e2e] Congestion control is not mandatory? In-Reply-To: References: <20040914173401.GA91659@pun.isi.edu> Message-ID: <20040915172213.GA3971@pun.isi.edu> On Wed, Sep 15, 2004 at 12:02:42AM +0200, Michael Welzl wrote: > > > This is curious ... it just occured to me that RFC 2581 is > > > just a Proposed Standard. > > > > > > That means that I can build a fully conformant TCP/IP > > > which does not do congestion control, doesn't it? > > > > RFC 1122 says (on page 89): > > > > Recent work by Jacobson [TCP:7] on Internet congestion and TCP > > retransmission stability has produced a transmission algorithm > > combining "slow start" with "congestion avoidance". A TCP MUST > > implement this algorithm. > > > > > > So that's a "no." Or maybe a MUST NOT. > > Ok, so you answered my question. Still, there are the somewhat > weird facts that i) here's a standard RFC referencing a paper > (not an RFC) with MUST implement while there's an RFC that > specifies what's needed, and ii) RFC 2581 is a Proposed Standard. I think this is largely inertial. This is one of the RFCs that the tcpm WG over in teh IETF is hoping to advance to DS, but the problem is interested competent manpower. If you'd like to join that set, we'd love to have you. I'd express that interest over in the tcpm mailing list. I know you know where it is. :-) If any of the authors of 2581 would like to pipe up here or on tcpm and tell me I'm wrong, I won't be offended. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040915/69ae1ae9/attachment.bin From iyengar at mail.eecis.udel.edu Fri Sep 17 16:35:59 2004 From: iyengar at mail.eecis.udel.edu (Janardhan Iyengar) Date: Fri Sep 17 16:37:11 2004 Subject: [e2e] Internet packet dynamics In-Reply-To: <2846497B437BF84BAD1A4CC407418D260400EF5F@exchange1.slac.stanford.edu> References: <2846497B437BF84BAD1A4CC407418D260400EF5F@exchange1.slac.stanford.edu> Message-ID: Hi all, I'm reviving an old thread about loss measurements in the Internet. Are there any packet loss rate measurements on small time scales, of the order of a few minutes, or even 10s of seconds maybe? thanks and regards, jana On Sat, 13 Mar 2004, Cottrell, Les wrote: > Fig. 2 in http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan04/ shows the packet losses seen by the PingER project (see http://www-iepm.slac.stanford.edu/pinger/) from the US to various regions of the world since Jan 1995. Other metrics can also be seen in the same web page (e.g. RTT and derived throughput ~ 1460Bytes/(RTT*sqrt(loss)). > > -----Original Message----- > From: David G. Andersen [mailto:dga@lcs.mit.edu] > Sent: Friday, March 12, 2004 6:44 PM > To: Sam Liang > Cc: end2end-interest@postel.org > Subject: Re: [e2e] Internet packet dynamics > > On Fri, Mar 12, 2004 at 04:46:27PM -0800, Sam Liang scribed: > > > > Vern Paxson's excellent Sigcomm 97 paper, "End-to-End Internet > > Packet Dynamics", told us a lot about the Internet traffic > > characteristics. But seven years have passed. The Internet has changed > > a lot. In particular, the packet loss rate has dropped a lot. But it's > > not zero. Are there any recent work that study the current Internet > > traffic patterns, such as packet loss rates? > > Quite a few. You can get some packte loss numbers in a more recent IMC paper of mine, and I'm sure there are numerous other sources: > > http://nms.lcs.mit.edu/papers/bestpath-imc2003.html > > As you assume, the loss rate we observed in 2002-ish is much lower than observed by Paxson97. The e2e loss numbers we observed in the 2001 RON study were also quite a bit lower than those that Paxson saw. Those 5 years were a pretty good period for internet bandwidth growth and technological improvement. > > -Dave > > -- > work: dga@lcs.mit.edu me: dga@pobox.com > MIT Laboratory for Computer Science http://www.angio.net/ > --------------------------------------------------------------- Visit www.narmada.org, www.indiatogether.org --------------------------------------------------------------- From braden at ISI.EDU Mon Sep 20 16:20:42 2004 From: braden at ISI.EDU (Bob Braden) Date: Mon Sep 20 16:21:36 2004 Subject: [e2e] NewArch Final Technical Report Message-ID: <200409202320.QAA19734@gra.isi.edu> Readers of this list may be interested in the Final Technical Report produced by the DARPA-funded NewArch project. The report ranges widely over the general topic of "How we would have designed the Internet if we knew then what we know now", and it contains quite a bit of interesting material. Much of it was written by Dave Clark, with caviling from other members of the project. The document is available in PDF and PS at: http://www.isi.edu/newarch Bob Braden From vern at icir.org Tue Sep 21 17:11:29 2004 From: vern at icir.org (Vern Paxson) Date: Tue Sep 21 17:11:43 2004 Subject: [e2e] Internet packet dynamics Message-ID: <200409220011.i8M0BTp3043151@jaguar.icir.org> > Are there any packet loss rate measurements on small time scales, of the > order of a few minutes, or even 10s of seconds maybe? You may find: On the Constancy of Internet Path Properties Y. Zhang, N. Duffield, V. Paxson, and S. Shenker Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001. http://www.icir.org/vern/papers/constancy-IMW01.ps.gz of interest in this regard. Vern From touch at ISI.EDU Tue Sep 21 18:54:00 2004 From: touch at ISI.EDU (Joe Touch) Date: Tue Sep 21 18:54:57 2004 Subject: [e2e] a few questions on TCP mechanism In-Reply-To: <000901c499a8$39a533e0$0200a8c0@fun> References: <20040913133911.7D54C1AC@aland.bbn.com> <000901c499a8$39a533e0$0200a8c0@fun> Message-ID: <4150DB38.2080207@isi.edu> Michael Welzl wrote: >>>b. If the only source of feedback is the destination >>>point, how is it possible for me to: >>>1. adjust my window size in T < RTT >> >>In general, you shouldn't. As I understand control theory, if you adjust >>in times smaller than the RTT, your control loop is unstable. > > Great that you bring this up: it's something that I never really > understood - how does this thinking translate to TCP, which > updates the rate with every ACK it gets (a lot more often than > once per RTT)? Is TCP actually interpolating? TCP doesn't have a 'rate'. It merely keeps track of how many outstanding packets it can tolerate. Although the window as a whole is updated for each ACK, each ACK updates only a portion of the window that is "one RTT old". TCP adjusts its RTT estimate as well, but that's an average. On the whole the amount TCP changes per packet is basically limited by how much a packet that's one RTT old can affect things. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040921/611e8736/signature.bin From mallman at icir.org Tue Sep 21 19:25:36 2004 From: mallman at icir.org (Mark Allman) Date: Tue Sep 21 19:27:53 2004 Subject: [e2e] Internet packet dynamics In-Reply-To: Message-ID: <20040922022536.1AF4D1E12B6@lawyers.icir.org> > Are there any packet loss rate measurements on small time scales, of > the order of a few minutes, or even 10s of seconds maybe? Also, this has a few plots of loss rates / periods / etc. that might be of interest: Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss Rates With TCP, ACM Performance Evaluation Review, 31(3), December 2003. http://www.icir.org/mallman/papers/least-per-dec2003.ps allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040921/a1ea55be/attachment.bin From jshen_cad at yahoo.com.cn Wed Sep 22 05:18:29 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Wed Sep 22 05:19:47 2004 Subject: [e2e] Packet size distribution across different application In-Reply-To: <20040922022536.1AF4D1E12B6@lawyers.icir.org> Message-ID: <20040922121829.95023.qmail@web15406.mail.cnb.yahoo.com> Hi, Are there any statistics on packet size distribution across different protocol , e.g. packet size distribution of VoIP, packet size distribution of Video conference etc. Jing ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From dmchiu at ie.cuhk.edu.hk Wed Sep 22 18:15:11 2004 From: dmchiu at ie.cuhk.edu.hk (Dah Ming Chiu) Date: Wed Sep 22 18:15:48 2004 Subject: [e2e] Packet size distribution across different application References: <20040922121829.95023.qmail@web15406.mail.cnb.yahoo.com> Message-ID: <47a201c4a10a$c987ed90$db60bd89@iepclan.ie.cuhk.edu.hk> Hi, I am also interested in this. Not only the packet size, but also average transmission rate (I guess this depends on the encoding used etc), and the distribution of the duration (or "holding time") for various multimedia applications, in both LAN and WAN scenarios. Thanks Dah Ming Chiu ----- Original Message ----- From: "Jing Shen" To: "end-to-end list" Sent: Wednesday, September 22, 2004 8:18 PM Subject: [e2e] Packet size distribution across different application > Hi, > > Are there any statistics on packet size distribution > across different protocol , e.g. packet size > distribution of VoIP, packet size distribution of > Video conference etc. > > Jing > From biazsaa at eng.auburn.edu Thu Sep 23 06:22:50 2004 From: biazsaa at eng.auburn.edu (Saad Biaz) Date: Thu Sep 23 06:23:52 2004 Subject: [e2e] Header length field in IP header Message-ID: The header length HL of IP header has 4 bits. Normally, the header length HL would be a number from 5 (no options) to 15. Since the IP header is at least 5, I wonder if the field HL can take the values 0, 1, 2, 3, or 4 to mean something else. If it takes such values (0-4), what is the meaning? Thank you- ---------------------------------------------------------------------- Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 114 Dunstan Hall Auburn University Fax : (334) 844 6329 Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz ---------------------------------------------------------------------- From touch at ISI.EDU Thu Sep 23 09:24:09 2004 From: touch at ISI.EDU (Joe Touch) Date: Thu Sep 23 09:25:10 2004 Subject: [e2e] Header length field in IP header In-Reply-To: References: Message-ID: <4152F8A9.2090500@isi.edu> Error - drop the packet. If the IP version field is 4 (I'm assuming you mean IPv4), there are required fixed-length fields. As per RFC791, pg 11: > IHL: 4 bits > > Internet Header Length is the length of the internet header in 32 > bit words, and thus points to the beginning of the data. Note that > the minimum value for a correct header is 5. I.e., this would mean an "incorrect header". Joe Saad Biaz wrote: > The header length HL of IP header has 4 bits. > Normally, the header length HL would be a number from 5 (no options) to > 15. Since the IP header is at least 5, I wonder if the field HL can take > the values 0, 1, 2, 3, or 4 to mean something else. If it takes such values > (0-4), what is the meaning? > > Thank you- > > ---------------------------------------------------------------------- > Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 > 114 Dunstan Hall Auburn University Fax : (334) 844 6329 > Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz > ---------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040923/b5fb8369/signature.bin From mycroft at netbsd.org Thu Sep 23 09:57:52 2004 From: mycroft at netbsd.org (Charles M. Hannum) Date: Thu Sep 23 09:58:53 2004 Subject: [e2e] Header length field in IP header In-Reply-To: References: Message-ID: <200409231657.52670.mycroft@netbsd.org> On Thursday 23 September 2004 13:22, Saad Biaz wrote: > The header length HL of IP header has 4 bits. > Normally, the header length HL would be a number from 5 (no options) to > 15. Since the IP header is at least 5, I wonder if the field HL can take > the values 0, 1, 2, 3, or 4 to mean something else. If it takes such values > (0-4), what is the meaning? Mostly that every(?) existing implementation will simply drop the packets. From craig at aland.bbn.com Thu Sep 23 10:22:20 2004 From: craig at aland.bbn.com (Craig Partridge) Date: Thu Sep 23 10:22:51 2004 Subject: [e2e] Header length field in IP header In-Reply-To: Your message of "Thu, 23 Sep 2004 09:24:09 PDT." <4152F8A9.2090500@isi.edu> Message-ID: <20040923172220.3708C1AB@aland.bbn.com> In message <4152F8A9.2090500@isi.edu>, Joe Touch writes: >Error - drop the packet. If the IP version field is 4 (I'm assuming you >mean IPv4), there are required fixed-length fields. As per RFC791, pg 11: Joe: You're quite right, but realize the point here -- we have found some free bits!! All we need to do is write a standards document that says values 0,1,2,3 and 4 are to be interpreted as "5 + a bit value to be determined" and we get 5 more values we can signal in the IP header! Diff serv has more bits to play with! Craig From touch at ISI.EDU Thu Sep 23 10:39:19 2004 From: touch at ISI.EDU (Joe Touch) Date: Thu Sep 23 10:39:57 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <20040923172220.3708C1AB@aland.bbn.com> References: <20040923172220.3708C1AB@aland.bbn.com> Message-ID: <41530A47.2050903@isi.edu> Craig Partridge wrote: > In message <4152F8A9.2090500@isi.edu>, Joe Touch writes: > > >>Error - drop the packet. If the IP version field is 4 (I'm assuming you >>mean IPv4), there are required fixed-length fields. As per RFC791, pg 11: > > > Joe: > > You're quite right, but realize the point here -- we have found some > free bits!! > > All we need to do is write a standards document that says values > 0,1,2,3 and 4 are to be interpreted as "5 + a bit value to be determined" > and we get 5 more values we can signal in the IP header! Diff serv > has more bits to play with! > > Craig The best part of that is the packets will be dropped by all intervening routers, since they're not "unused" but rather "errors to drop", which means you'll get the diff serv you deserve ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040923/a1ae0ea8/signature.bin From biazsaa at eng.auburn.edu Thu Sep 23 10:48:14 2004 From: biazsaa at eng.auburn.edu (Saad Biaz) Date: Thu Sep 23 10:49:18 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <20040923172220.3708C1AB@aland.bbn.com> Message-ID: On Thu, 23 Sep 2004, Craig Partridge wrote: > > In message <4152F8A9.2090500@isi.edu>, Joe Touch writes: > > >Error - drop the packet. If the IP version field is 4 (I'm assuming you > >mean IPv4), there are required fixed-length fields. As per RFC791, pg 11: > > Joe: > > You're quite right, but realize the point here -- we have found some > free bits!! That was exactly my intent! > All we need to do is write a standards document that says values > 0,1,2,3 and 4 are to be interpreted as "5 + a bit value to be determined" > and we get 5 more values we can signal in the IP header! Diff serv > has more bits to play with! Geee, and I was thinking Diffserv too! Thank you- ---------------------------------------------------------------------- Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 114 Dunstan Hall Auburn University Fax : (334) 844 6329 Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz ---------------------------------------------------------------------- From touch at ISI.EDU Thu Sep 23 11:01:23 2004 From: touch at ISI.EDU (Joe Touch) Date: Thu Sep 23 11:02:31 2004 Subject: [e2e] Header length field in IP header In-Reply-To: References: Message-ID: <41530F73.6040902@isi.edu> PS - if you're going to pick some bits to modify that existing routers might already drop, why not just use another IP version? Joe Saad Biaz wrote: > On Thu, 23 Sep 2004, Craig Partridge wrote: > > >>In message <4152F8A9.2090500@isi.edu>, Joe Touch writes: >> >> >>>Error - drop the packet. If the IP version field is 4 (I'm assuming you >>>mean IPv4), there are required fixed-length fields. As per RFC791, pg 11: >> >>Joe: >> >>You're quite right, but realize the point here -- we have found some >>free bits!! > > > > That was exactly my intent! > > >>All we need to do is write a standards document that says values >>0,1,2,3 and 4 are to be interpreted as "5 + a bit value to be determined" >>and we get 5 more values we can signal in the IP header! Diff serv >>has more bits to play with! > > > Geee, and I was thinking Diffserv too! > > Thank you- > > > > ---------------------------------------------------------------------- > Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 > 114 Dunstan Hall Auburn University Fax : (334) 844 6329 > Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz > ---------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040923/449408de/signature.bin From biazsaa at eng.auburn.edu Thu Sep 23 11:15:01 2004 From: biazsaa at eng.auburn.edu (Saad Biaz) Date: Thu Sep 23 11:15:53 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <41530A47.2050903@isi.edu> Message-ID: On Thu, 23 Sep 2004, Joe Touch wrote: > > > The best part of that is the packets will be dropped by all intervening > routers, since they're not "unused" but rather "errors to drop", which > means you'll get the diff serv you deserve ;-) Joe: I wonder if we would have trains today if engineers reacted as you are doing now. If someone proposed to use trains in the 18th century, you would tell him: "Where would you use trains? there are no tracks". ---------------------------------------------------------------------- Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 114 Dunstan Hall Auburn University Fax : (334) 844 6329 Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz ---------------------------------------------------------------------- From touch at ISI.EDU Thu Sep 23 11:18:41 2004 From: touch at ISI.EDU (Joe Touch) Date: Thu Sep 23 11:19:43 2004 Subject: [e2e] Header length field in IP header In-Reply-To: References: Message-ID: <41531381.70202@isi.edu> I'm not advocating for not creating new services. I don't see any utility to using "unused bits" in IPv4, which aren't actually unused so much as 'declared invalid', vs. just changing the IP version number, adding an option, or any of a dozen other more conventional ways. The key here is that using these unused bits doesn't buy anything; if packets that don't know this mod will drop the bits, then why not just use an IP option? or a new version that has IPv4 with another 32 bits, all for Diff Serv? Joe Saad Biaz wrote: > On Thu, 23 Sep 2004, Joe Touch wrote: > > >> >>The best part of that is the packets will be dropped by all intervening >>routers, since they're not "unused" but rather "errors to drop", which >>means you'll get the diff serv you deserve ;-) > > > Joe: > > I wonder if we would have trains today if engineers reacted as you are > doing now. If someone proposed to use trains in the 18th century, > you would tell him: "Where would you use trains? there are no tracks". > > > ---------------------------------------------------------------------- > Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 > 114 Dunstan Hall Auburn University Fax : (334) 844 6329 > Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz > ---------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040923/c9cb452a/signature.bin From fred at cisco.com Thu Sep 23 11:21:45 2004 From: fred at cisco.com (Fred Baker) Date: Thu Sep 23 11:22:54 2004 Subject: [e2e] Header length field in IP header In-Reply-To: References: <20040923172220.3708C1AB@aland.bbn.com> Message-ID: <6.1.2.0.2.20040923111926.06128cd8@mira-sjc5-b.cisco.com> At 12:48 PM 09/23/04 -0500, Saad Biaz wrote: > > You're quite right, but realize the point here -- we have found some > > free bits!! > >That was exactly my intent! we now have a truly useful way to implement RFC 3514. We can not only have "evil" packets, but can now identify five classes of Evil packets, for appropriate service categories. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 170 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040923/cdc73f7f/attachment-0001.bin From dga at lcs.mit.edu Thu Sep 23 11:33:10 2004 From: dga at lcs.mit.edu (David G. Andersen) Date: Thu Sep 23 11:33:53 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <41530F73.6040902@isi.edu> References: <41530F73.6040902@isi.edu> Message-ID: <20040923183310.GA80478@lcs.mit.edu> On Thu, Sep 23, 2004 at 11:01:23AM -0700, Joe Touch scribed: > PS - if you're going to pick some bits to modify that existing routers > might already drop, why not just use another IP version? May I suggest IPv8? In addition to being aesthetically pleasing as a power of two, you can talk to up to 8 galaxies with it... or at least, one person who may well be from another galaxy. ;-) -Dave From Steven.Berson at aero.org Thu Sep 23 11:53:57 2004 From: Steven.Berson at aero.org (Steven Berson) Date: Thu Sep 23 11:55:52 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <20040923183310.GA80478@lcs.mit.edu> References: <41530F73.6040902@isi.edu> <20040923183310.GA80478@lcs.mit.edu> Message-ID: <41531BC5.7080307@aero.org> IPv8 is already taken - see RFC 1621. Cheers, Steve David G. Andersen wrote: >On Thu, Sep 23, 2004 at 11:01:23AM -0700, Joe Touch scribed: > > >>PS - if you're going to pick some bits to modify that existing routers >>might already drop, why not just use another IP version? >> >> > > May I suggest IPv8? In addition to being aesthetically pleasing >as a power of two, you can talk to up to 8 galaxies with it... or >at least, one person who may well be from another galaxy. ;-) > > -Dave > > From fred at cisco.com Thu Sep 23 11:57:23 2004 From: fred at cisco.com (Fred Baker) Date: Thu Sep 23 11:57:53 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <20040923183310.GA80478@lcs.mit.edu> References: <41530F73.6040902@isi.edu> <20040923183310.GA80478@lcs.mit.edu> Message-ID: <6.1.2.0.2.20040923115648.05ca5338@mira-sjc5-b.cisco.com> At 02:33 PM 09/23/04 -0400, David G. Andersen wrote: >May I suggest IPv8? In addition to being aesthetically pleasing as a >power of two, you can talk to up to 8 galaxies with it... or at least, one >person who may well be from another galaxy. ;-) The designer of IPv8 *is* from another galaxy... From label_label_label_label at yahoo.com Thu Sep 23 14:20:30 2004 From: label_label_label_label at yahoo.com (Zaphod Beeblebrox) Date: Thu Sep 23 14:20:52 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <41531381.70202@isi.edu> Message-ID: <20040923212030.84134.qmail@web51306.mail.yahoo.com> (I just wanted to keep the flow of the argument going, no disrespect meant to anyone) as an humble observation by an observer from another galaxy, Why don't earthlings do this: DNS-------DNS----DNS | | | Endhost1----NAT1-------NAT2---NAT3-----endhost2 Since all end hosts will always do a name resolution, we can treat that as a way to setup the path :), just like a TCP handshake :) In other words, if I want to talk to endhost1.beeblebrox.com wants to talk to endhost2.end2end.org , it contacts the DNS on NAT1, gets a local IP on each side, NAT1 contacts NAT2 and gets a locally significant IP on each side and so on... we could use nice words and call it "downstream on demand IP distribution mode" Hope this helps :), -ZB _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From touch at ISI.EDU Thu Sep 23 15:46:04 2004 From: touch at ISI.EDU (Joe Touch) Date: Thu Sep 23 15:51:19 2004 Subject: [e2e] updated policy on Calls for Papers/Participation Message-ID: <4153522C.3050802@isi.edu> Hi, all, The E2E list has had a policy effective May 2003 that restricts conference announcements as follows: - one call for papers/submissions - one call for participation The limit applied to each conference meeting; workshops, tutorials, and adjunct meetings count as a single conference event, and are permitted only two overall posts. ----- This limit had not taken into account the more common practice of calls for papers including a call for tutorials, workshops, etc. Effective immediately, the limit is extended to three posts, in cases where the first call includes requests for proposals for adjunct events as follows: - one call for papers/submissions and proposals for adjunct events - one call for papers/submissions to adjunct events only if the first call included a request for event proposals - one call for participation for the overall group of events For those of you not interested in administrativia, we now return to our regularly scheduled technical ratholes ;-) Joe (list administrator) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040923/5660af6c/signature.bin From mallman at icir.org Thu Sep 23 21:10:01 2004 From: mallman at icir.org (Mark Allman) Date: Thu Sep 23 21:34:55 2004 Subject: [e2e] Header length field in IP header In-Reply-To: Message-ID: <20040924041001.C88461E2C3F@lawyers.icir.org> > The header length HL of IP header has 4 bits. Normally, the header > length HL would be a number from 5 (no options) to > 15. Since the IP header is at least 5, I wonder if the field HL can take > the values 0, 1, 2, 3, or 4 to mean something else. If it takes such values > (0-4), what is the meaning? BTW, Eddie Kohler has suggested doing just this for TCP to allow for more option space. Basically, a TCP offset of 0=48 bytes of TCP options, 1=64 bytes, 2=128 bytes, 3=256 bytes and 4=there is no payload. The TCPM WG has been discussing these issues, and it'd be great to see some commentary on tcpm@ietf.org on this topic. Eddie has a draft: draft-kohler-tcpm-extopt-00.txt Also, Wes Eddy has another draft that provides a scheme to provide for more option space in TCP. It is in the draft: draft-eddy-tcp-loo-01.txt Also, for kicks I did a little experiment and hacked tcptraceroute (really libnet) to use a TCP offset of zero. I beat on a FreeBSD 4.8 host across the country and it discarded the SYN (but, the SYN made it to the endhost). I hit a Solaris 9 box across the state and not only did the SYN make it, but a valid SYN+ACK was returned! All I can figure is that Solaris assumes 20 bytes of TCP header and processes options if the offset is >= 5. Interesting, though. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040924/f3532290/attachment.bin From sudeepg at cse.iitb.ac.in Thu Sep 23 23:52:39 2004 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Fri Sep 24 01:39:59 2004 Subject: [e2e] Netspec Message-ID: Hi All, Does anyone have a copy of Netspec? It used to open-source and available on http://www.ittc.ku.edu/netspec/. Its no longer there. I need it for testing of end-to-end application performance on my MPLS test-bed. It emulates many application traffic like MPEG, VoIP, FTP and measure their end-to-end performance. And this is what I need to do. I can use traffic generators (like TG) for the same, but I want to do application performance analysis for different applications. Is there another alternative with which I can know and generate traffic similar to different applications? Thanks and regards, Sudeep On Thu, 23 Sep 2004, Steven Berson wrote: > IPv8 is already taken - see RFC 1621. > > Cheers, > Steve > > David G. Andersen wrote: > >> On Thu, Sep 23, 2004 at 11:01:23AM -0700, Joe Touch scribed: >> >>> PS - if you're going to pick some bits to modify that existing routers >>> might already drop, why not just use another IP version? >>> >> >> May I suggest IPv8? In addition to being aesthetically pleasing >> as a power of two, you can talk to up to 8 galaxies with it... or >> at least, one person who may well be from another galaxy. ;-) >> >> -Dave >> > > -- When a great leader's work is done, people say "we did it ourselves". -Lao Tzu From sudeepg at cse.iitb.ac.in Fri Sep 24 07:28:37 2004 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Fri Sep 24 07:23:13 2004 Subject: [e2e] Netspec In-Reply-To: <4154287A.1040702@oar.net> References: <4154287A.1040702@oar.net> Message-ID: Thanks a lot Prasad. I would definitely try the tool. This solves me a problem for VoIP and other stream traffic. But, I am not sure if elastic traffic (like ftp, http, mail or ERP) can be done using this. Can you kindly suggest some way? Thanks and regards, Sudeep On Fri, 24 Sep 2004, Prasad Calyam wrote: > hi Sudeep, > You could try our software "H.323 Beacon" > It generates various codecs traffic (VoIP traffic) and determines > network performance and end-user perceived quality scores (E-Model > parameters) for the test traffic stream.... > > The software can be found at- > http://www.itecohio.org/beacon > > Let me know if you have questions or comments about the tool... > > -Prasad > > Sudeep Goyal wrote: > >> Hi All, >> Does anyone have a copy of Netspec? It used to open-source and available on >> http://www.ittc.ku.edu/netspec/. Its no longer there. I need it for testing >> of end-to-end application performance on my MPLS test-bed. It emulates many >> application traffic like MPEG, VoIP, FTP and measure their end-to-end >> performance. And this is what I need to do. >> >> I can use traffic generators (like TG) for the same, but I want to do >> application performance analysis for different applications. Is there >> another alternative with which I can know and generate traffic similar to >> different applications? >> >> Thanks and regards, >> Sudeep >> >> >> >> >> On Thu, 23 Sep 2004, Steven Berson wrote: >> >>> IPv8 is already taken - see RFC 1621. >>> >>> Cheers, >>> Steve >>> >>> David G. Andersen wrote: >>> >>>> On Thu, Sep 23, 2004 at 11:01:23AM -0700, Joe Touch scribed: >>>> >>>>> PS - if you're going to pick some bits to modify that existing routers >>>>> might already drop, why not just use another IP version? >>>>> >>>> >>>> May I suggest IPv8? In addition to being aesthetically pleasing >>>> as a power of two, you can talk to up to 8 galaxies with it... or >>>> at least, one person who may well be from another galaxy. ;-) >>>> >>>> -Dave >>>> >>> >>> >> > > -- When a great leader's work is done, people say "we did it ourselves". -Lao Tzu From s.malik at tuhh.de Fri Sep 24 08:46:08 2004 From: s.malik at tuhh.de (Sireen Habib Malik) Date: Fri Sep 24 08:46:58 2004 Subject: [e2e] Netspec In-Reply-To: References: <4154287A.1040702@oar.net> Message-ID: <41544140.107@tuhh.de> Hi, Here is one reference paper for generating web-traffic,"A Light Weight Traffic Source for Web Traffic Simulation "in GLOBECOM/CAMAD-2004. Paper copy at: http://www.tu-harburg.de/et6/papers/papers_all.html Hope it helps, Malik Sudeep Goyal wrote: > Thanks a lot Prasad. I would definitely try the tool. This solves me a > problem for VoIP and other stream traffic. But, I am not sure if > elastic traffic (like ftp, http, mail or ERP) can be done using this. > Can you kindly suggest some way? > > Thanks and regards, > Sudeep > > > On Fri, 24 Sep 2004, Prasad Calyam wrote: > >> hi Sudeep, >> You could try our software "H.323 Beacon" >> It generates various codecs traffic (VoIP traffic) and determines >> network performance and end-user perceived quality scores (E-Model >> parameters) for the test traffic stream.... >> >> The software can be found at- >> http://www.itecohio.org/beacon >> >> Let me know if you have questions or comments about the tool... >> >> -Prasad >> >> Sudeep Goyal wrote: >> >>> Hi All, >>> Does anyone have a copy of Netspec? It used to open-source and >>> available on http://www.ittc.ku.edu/netspec/. Its no longer there. I >>> need it for testing of end-to-end application performance on my MPLS >>> test-bed. It emulates many application traffic like MPEG, VoIP, FTP >>> and measure their end-to-end performance. And this is what I need to >>> do. >>> >>> I can use traffic generators (like TG) for the same, but I want to >>> do application performance analysis for different applications. Is >>> there another alternative with which I can know and generate traffic >>> similar to different applications? >>> >>> Thanks and regards, >>> Sudeep >>> >>> >>> >>> >>> On Thu, 23 Sep 2004, Steven Berson wrote: >>> >>>> IPv8 is already taken - see RFC 1621. >>>> >>>> Cheers, >>>> Steve >>>> >>>> David G. Andersen wrote: >>>> >>>>> On Thu, Sep 23, 2004 at 11:01:23AM -0700, Joe Touch scribed: >>>>> >>>>>> PS - if you're going to pick some bits to modify that existing >>>>>> routers might already drop, why not just use another IP version? >>>>>> >>>>> >>>>> May I suggest IPv8? In addition to being aesthetically pleasing >>>>> as a power of two, you can talk to up to 8 galaxies with it... or >>>>> at least, one person who may well be from another galaxy. ;-) >>>>> >>>>> -Dave >>>>> >>>> >>>> >>> >> >> > -- Sireen Malik, M.Sc. PhD. Candidate, Communication Networks Technical University of Hamburg-Harburg FSP 4-06 (room 3008) Denickestr. 17 21073 Hamburg, Deutschland Tel: +49 (40) 42-878-3387 Fax: +49 (40) 42-878-2941 E-Mail: s.malik@tuhh.de --In this ugly time, the only true protest is beauty. (Phil Ochs) From touch at ISI.EDU Fri Sep 24 11:02:31 2004 From: touch at ISI.EDU (Joe Touch) Date: Fri Sep 24 11:03:14 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <20040924041001.C88461E2C3F@lawyers.icir.org> References: <20040924041001.C88461E2C3F@lawyers.icir.org> Message-ID: <41546137.30100@isi.edu> Mark Allman wrote: >>The header length HL of IP header has 4 bits. Normally, the header >>length HL would be a number from 5 (no options) to >>15. Since the IP header is at least 5, I wonder if the field HL can take >>the values 0, 1, 2, 3, or 4 to mean something else. If it takes such values >>(0-4), what is the meaning? > > > BTW, Eddie Kohler has suggested doing just this for TCP to allow for > more option space. Basically, a TCP offset of 0=48 bytes of TCP > options, 1=64 bytes, 2=128 bytes, 3=256 bytes and 4=there is no payload. IP specificially prohibits values under 5. TCP has no such prohibition, though it doesn't address it either way. That which is not prohibited MUST be allowed, IMO. Your experiments below validate that approach, happily ;-) However, I still believe (and will post to TCPM separately) that Eddy's approach which uses an option to override vanilla TCP data length field is a better way to go; it corresponds to window scaling, and how IP jumbograms are handled. I don't believe there is a measurable difference to how uncompliant middleboxes would handle either version - both could fail where not supported. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040924/8178bfe0/signature.bin From zartash at lums.edu.pk Fri Sep 24 12:51:23 2004 From: zartash at lums.edu.pk (Zartash Afzal Uzmi) Date: Fri Sep 24 12:56:01 2004 Subject: [e2e] Header length field in IP header In-Reply-To: <20040923212030.84134.qmail@web51306.mail.yahoo.com> Message-ID: > -----Original Message----- > From: end2end-interest-bounces@postel.org > [mailto:end2end-interest-bounces@postel.org]On Behalf Of Zaphod > Beeblebrox > Sent: Friday, September 24, 2004 2:21 AM > To: end2end-interest@postel.org > Subject: Re: [e2e] Header length field in IP header > > > (I just wanted to keep the flow of the argument going, > no disrespect meant to anyone) > > as an humble observation by an observer from another > galaxy, > > Why don't earthlings do this: > > > DNS-------DNS----DNS > | | | > Endhost1----NAT1-------NAT2---NAT3-----endhost2 > > > Since all end hosts will always do a name resolution, > we can treat that as a way to setup the path :), just > like a TCP handshake :) unless the source uses destinaiton's IP address without going through the name resolution. And if I trust arp caching, I am always going to get the same route. Further, this same route may have been "tore off" by the intermediate NAT gateways! So yes, the scheme will work in another galaxy where inhabitants do obey lots of constraints but earthlings are a different creature, they will go ahead and call your NAT gateway an LSR :) > In other words, if I want to talk to > endhost1.beeblebrox.com wants to talk to > endhost2.end2end.org , it contacts the DNS on NAT1, > gets a local IP on each side, NAT1 contacts NAT2 and > gets a locally significant IP on each side and so > on... > we could use nice words and call it "downstream on > demand IP distribution mode" > > Hope this helps :), > > -ZB > > > > > _______________________________ > Do you Yahoo!? > Express yourself with Y! Messenger! Free. Download now. > http://messenger.yahoo.com > From dissolved at comcast.net Fri Sep 24 13:19:24 2004 From: dissolved at comcast.net (dissolved) Date: Fri Sep 24 13:20:07 2004 Subject: [e2e] Clarification needed on delayed acks and sliding window protocol Message-ID: <200409242019.i8OKJZJ00987@boreas.isi.edu> Hello. I was hoping someone could clarify a few things for me regarding some TCP algorithms. I've read TCP/IP illustrated VOL1 5 times and still cant find the answer. 1. The nagle algorithm is mostly used on interactive sessions. Which means, we wont see it on stuff like FTP transfers. What we WILL see, while using FTP transfers, is TCP's sliding window protocol. Am I right so far? Now, sliding window protocol looks something like this on a sniffer Host A -------> host B (1k bytes of data) Host A ------> host B (1k bytes of data) Host A <----- -Host B (ack) Correct? 2. Is the delayed acknowledgement algorithm used in conjunction with the TCP sliding window protocol? I had heard that when the sliding window protocol is used, the delayed ACK timer never has a chance to go off. 3. Is the nagle algorithm used in conjunction with the delayed ack algorithm? 4. What determines if the nagle algorithm, or sliding window protocol will be used in a session? The application layer? The amount of data being transferred? Thank you Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040924/cbb8b00c/attachment.html From craig at aland.bbn.com Fri Sep 24 14:38:05 2004 From: craig at aland.bbn.com (Craig Partridge) Date: Fri Sep 24 14:39:07 2004 Subject: [e2e] Clarification needed on delayed acks and sliding window protocol In-Reply-To: Your message of "Fri, 24 Sep 2004 16:19:24 EDT." <200409242019.i8OKJZJ00987@boreas.isi.edu> Message-ID: <20040924213805.580651AB@aland.bbn.com> In message <200409242019.i8OKJZJ00987@boreas.isi.edu>, "dissolved" writes: >1. The nagle algorithm is mostly used on interactive sessions. Which means, >we wont see it on stuff like FTP transfers. What we WILL see, while using >FTP transfers, is TCP's sliding window protocol. Am I right so far? > > > >Now, sliding window protocol looks something like this on a sniffer > >Host A -------> host B (1k bytes of data) > >Host A ------> host B (1k bytes of data) > >Host A <----- -Host B (ack) > >Correct? Yes (assuming 1KB is the MSS). Note the Nagle algorithm could be on in this case (indeed, is highly likely to be on, as the FTP application may not be writing data in 1KB chunks, and Nagle ensures that maximum sized segments get sent). >2. Is the delayed acknowledgement algorithm used in conjunction with the TCP >sliding window protocol? I had heard that when the sliding window protocol >is used, the delayed ACK timer never has a chance to go off. The answer is subtle. The rule is you delay an ack unless you've received 2MSS's worth of data, in which case you ack immediately. So, during those times in the TCP connection that less than two segments are in flight, or in which you have an odd number of segments in flight (so the last one arrives alone and has to wait for a delayed ack) >3. Is the nagle algorithm used in conjunction with the delayed ack >algorithm? Yes, they are independent. >4. What determines if the nagle algorithm, or sliding window protocol will >be used in a session? The application layer? The amount of data being >transferred? Sliding window is always in effect. Nagle is on or off depending on what you've set for your connection. Craig From touch at ISI.EDU Fri Sep 24 15:51:18 2004 From: touch at ISI.EDU (Joe Touch) Date: Fri Sep 24 15:54:11 2004 Subject: [e2e] Clarification needed on delayed acks and sliding window protocol In-Reply-To: <200409242019.i8OKJZJ00987@boreas.isi.edu> References: <200409242019.i8OKJZJ00987@boreas.isi.edu> Message-ID: <4154A4E6.4020509@isi.edu> dissolved wrote: > Hello. I was hoping someone could clarify a few things for me regarding > some TCP algorithms. I?ve read TCP/IP illustrated VOL1 5 times and still > cant find the answer. > > 1. The nagle algorithm is mostly used on interactive sessions. Which > means, we wont see it on stuff like FTP transfers. What we WILL see, > while using FTP transfers, is TCP?s sliding window protocol. Am I right > so far? That depends on what you mean by interactive. Nagle should be NOT be used on interactive sessions where the interaction involves multi-byte exchanges. There is the danger of splitting the 'message' units across packets and incurring unnecessary delays. While Nagle should be ON for telnet and bulk transfer, it should be OFF for multi-byte message exchanges, e.g., HTTP. --- Some of the rest of the questions I'll address off-line, since they're probably common knowledge for most on ths list. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040924/687e181a/signature.bin From dissolved at comcast.net Fri Sep 24 14:52:09 2004 From: dissolved at comcast.net (dissolved) Date: Sat Sep 25 09:13:52 2004 Subject: [e2e] Clarification needed on delayed acks and sliding window protocol In-Reply-To: <20040924213805.580651AB@aland.bbn.com> Message-ID: <200409242152.i8OLqNJ04733@boreas.isi.edu> Thanks Craig for the prompt response. So the sliding window protocol is always in effect. And the delayed ACK timer is always counting. It is just when certain conditions are met that, they are invoked. If I use interactive sessions, nagle will always be used to ensure the network doesn't get fluttered with 1byte segments. Now: If Host A (the sender), sends three segments to Host B (each segment MSS...say 1460bytes), then Host B will ack when it receives 2 of the 3 segments. Is this correct? That would explain my sniffer output I've been seeing. Thanks Ryan -----Original Message----- From: Craig Partridge [mailto:craig@aland.bbn.com] Sent: Friday, September 24, 2004 5:38 PM To: dissolved Cc: end2end-interest@postel.org Subject: Re: [e2e] Clarification needed on delayed acks and sliding window protocol In message <200409242019.i8OKJZJ00987@boreas.isi.edu>, "dissolved" writes: >1. The nagle algorithm is mostly used on interactive sessions. Which means, >we wont see it on stuff like FTP transfers. What we WILL see, while using >FTP transfers, is TCP's sliding window protocol. Am I right so far? > > > >Now, sliding window protocol looks something like this on a sniffer > >Host A -------> host B (1k bytes of data) > >Host A ------> host B (1k bytes of data) > >Host A <----- -Host B (ack) > >Correct? Yes (assuming 1KB is the MSS). Note the Nagle algorithm could be on in this case (indeed, is highly likely to be on, as the FTP application may not be writing data in 1KB chunks, and Nagle ensures that maximum sized segments get sent). >2. Is the delayed acknowledgement algorithm used in conjunction with the TCP >sliding window protocol? I had heard that when the sliding window protocol >is used, the delayed ACK timer never has a chance to go off. The answer is subtle. The rule is you delay an ack unless you've received 2MSS's worth of data, in which case you ack immediately. So, during those times in the TCP connection that less than two segments are in flight, or in which you have an odd number of segments in flight (so the last one arrives alone and has to wait for a delayed ack) >3. Is the nagle algorithm used in conjunction with the delayed ack >algorithm? Yes, they are independent. >4. What determines if the nagle algorithm, or sliding window protocol will >be used in a session? The application layer? The amount of data being >transferred? Sliding window is always in effect. Nagle is on or off depending on what you've set for your connection. Craig From braden at ISI.EDU Sat Sep 25 10:58:29 2004 From: braden at ISI.EDU (Bob Braden) Date: Sat Sep 25 10:59:08 2004 Subject: [e2e] Clarification needed on delayed acks and sliding window protocol Message-ID: <200409251758.KAA21586@gra.isi.edu> *> > *> >Now, sliding window protocol looks something like this on a sniffer *> > *> >Host A -------> host B (1k bytes of data) *> > *> >Host A ------> host B (1k bytes of data) *> > *> >Host A <----- -Host B (ack) *> > *> >Correct? *> *> Yes (assuming 1KB is the MSS). Note the Nagle algorithm could be on in *> this case (indeed, is highly likely to be on, as the FTP application may *> not be writing data in 1KB chunks, and Nagle ensures that maximum sized *> segments get sent). *> I think this is a confusing question. Your example above seems to be showing the use of delayed ACKs, which is a much more constrained algorithm than is required by a sliding window. TCP was always a sliding window protocol. With a sliding window, an equally valid sequence might be: Host A -------> host B (1k bytes of data) Host A <------ Host B (ack 1K) Host A ------> host B (1k bytes of data) Host A <------ Host B (ack 1K (immediate ACK, no delayed ACKs) or it might be: Host A -------> host B (1k bytes of data) Host A <------ Host B (ack 1K) Host A ------> host B (1k bytes of data) Host A -------> host B (1k bytes of data) Host A -------> host B (1k bytes of data) Host A <------ Host B (ack 1K) Host A -------> host B (1k bytes of data) Host A <------ Host B (ack 2K) Host A <------ Host B (ack 1K) (etc.) Bob Braden From label_label_label_label at yahoo.com Sun Sep 26 12:45:04 2004 From: label_label_label_label at yahoo.com (Zaphod Beeblebrox) Date: Sun Sep 26 12:46:08 2004 Subject: [e2e] Header length field in IP header In-Reply-To: Message-ID: <20040926194504.10566.qmail@web51309.mail.yahoo.com> Hi, > > > > > > (I just wanted to keep the flow of the argument > going, > > no disrespect meant to anyone) > > > > as an humble observation by an observer from > another > > galaxy, > > > > Why don't earthlings do this: > > > > > > DNS-------DNS----DNS > > | | | > > Endhost1----NAT1-------NAT2---NAT3-----endhost2 > > > > > > Since all end hosts will always do a name > resolution, > > we can treat that as a way to setup the path :), > just > > like a TCP handshake :) > > unless the source uses destinaiton's IP address > without going through the > name resolution. And if I trust arp caching, I am > always going to get the > same route. Further, this same route may have been > "tore off" by the > intermediate NAT gateways! So yes, the scheme will > work in another galaxy > where inhabitants do obey lots of constraints but > earthlings are a different > creature, they will go ahead and call your NAT > gateway an LSR :) exactly! (if LSR is indeed what I understand it is, as per the hitch hikers guide to the galaxy) "Primitive protocols" ( :-p ) like IP are not needed in that case, right? And again , we would need to "lookup the name" only when setting up the path at the ingress, hence that would help eliminate a lot of problems. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From gdc at iki.fi Tue Sep 28 06:10:13 2004 From: gdc at iki.fi (Dado Colussi) Date: Tue Sep 28 06:11:28 2004 Subject: [e2e] Observations on RFC 3448 (TFRC) Message-ID: Hi folks, I went through the RFC 3448 (TFRC) in quite detail recently and made some observations I thought I might share here. Section 4.4 Expiration of nofeedback timer: If (X_calc > 2*X_recv) X_calc can be computed only when p > 0. The given code fragment assumes a valid X_calc. Section 4.6 Scheduling of Packet Transmissions: on 4th line: course-grain Should be coarse-grain? Section 5.5 History Discounting: The elements from 1 to n of DF_i array are initialized to 1. DF_0 is left uninitialized. It is, however, referred to in the last code fragment when a new loss event occurs: for (i = n-1 to 0 step -1) { DF_(i+1) = DF * DF_i } DF_1 is set to DF_0 which is effectively a random value. DF_0 is initialized to 0 only right after that. Thus, the random value traverses through the DF_i array until discarded after n loss events. Section 6.2 Expiration of feedback timer, bullet 2: Calculate the measured receive rate, X_recv, based on the packets received within the previous R_m seconds. Feedback is sent approximately once per round-trip time, if data packet have been received since last feedback. If the data rate is less than one packet per round-trip time, feedback is sent only at "rounds" where data messages have been received. However, X_calc is calculated over a R_m seconds. Now, if the data rate is less than one packet per round-trip time, X_calc is calculated using one packet over a time frame of R_m seconds. For a source sending a packet every fourth round, the receiver calculates X_recv four times larger than it really is. How about calculating X_recv over the time between two consecutive feedbacks? Section 6.3 Receiver initialization: When the first packet is received: ... o Set the feedback timer to expire after R_i seconds. In section 4.2 Sender initialization the sender's estimate of round-trip time time is explicitly left undefined until measured. Thus, the first packet contains an undefined value as round-trip time estimate and the feedback timer gets initialized to an undefined time. I solved this by sending feedback for each packet until the sender provided a valid estimate. Section 6.3.1 Initializing the Loss History after the First Loss Event ... the TFRC receiver calculates the loss interval that would be required to produce the data rate X_recv, and uses this synthetic loss interval to seed the loss history mechanism. The document is not being explicit how the seeding is done. The NS-2 implementation appears to seed the first element of the loss history array. I first interpreted this so that all n elements are to be seeded. Another issue that crossed my mind is related to ECN. What if the very first packet contans ECN bit? Best regards, Dado From braden at ISI.EDU Tue Sep 28 22:14:14 2004 From: braden at ISI.EDU (Braden) Date: Tue Sep 28 21:15:27 2004 Subject: [e2e] Re: Thank you! Message-ID: An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040929/1d40f27c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Price.com Type: application/octet-stream Size: 18842 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040929/1d40f27c/Price.obj From matthew at cs.uni-bonn.de Fri Sep 24 08:52:46 2004 From: matthew at cs.uni-bonn.de (Matthias Frank) Date: Thu Sep 30 17:04:09 2004 Subject: [e2e] IEEE LCN + workshops Call for Participation Message-ID: <415442CE.7000209@cs.uni-bonn.de> ======================================================================= This is not spam! This e2e-mailing has been approved by Bob Braden. Apologies if you receive multiple copies of this Call for Participation ======================================================================= A D V A N C E T E C H N I C A L P R O G R A M + K E Y N O T E S LCN 2004 The 29th Annual IEEE Conference on Local Computer Networks (LCN) Tampa/Florida November 16-18, 2004 Please check the conference + workshop URLs for timing information and further details on the program as well as a one-page schedule overview. - LCN: IEEE Conference on Local Computer Networks, http://www.ieeelcn.org/ - EmNetS: IEEE Workshop on Embedded Networked Sensors, http://www.cse.unsw.edu.au/~emnet/ - WLN: IEEE Workshop on Wireless Local Networks, http://wln2004.cs.bonn.edu/ - HSLN: IEEE Workshop on High-Speed Local Networks, http://www.cs.iit.edu/~hsln/ Highlights of this year's conference + workshops are: - LCN keynote by Hari Balakrishnan (MIT) on Opportunities and Challenges in High-Rate Wireless Sensor Networking - LCN keynote by Raj Jain (Nayna Networks) on Networking 2004: Trends and Issues - EmNetS keynote by Daniela Rus (MIT) on Autonomous Mobile Networks - HSLN keynote by Joseph L. Hellerstein (IBM T.J. Watson Research Center) on Autonomic Computing and Network Management - WLN keynote by Elizabeth Belding-Royer on Wireless Networking Outside of the Simulator - HSLN panel discussion "What has happened to the I/O network?" - combined workshops poster session on Tuesday Nov 16 - LCN plenary poster session on Wednesday Nov 17 Please note the early (discounted) registration deadline ends October 15, 2004. On behalf of the IEEE LCN team, Matthias Frank, Uni Bonn