From rhee at eos.ncsu.edu Fri Jul 2 12:45:08 2004 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Fri Jul 2 12:44:11 2004 Subject: [e2e] Uodates on BIC-TCP Message-ID: <200407021943.i62Jh8YJ005789@uni01mr.unity.ncsu.edu> We are happy to update you about our progress with BIC, one of many TCP variants designed for high-speed long-distance networks. You can find more information about the updates from the official BIC web site: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm 1 A new version of BIC (Version 1.1) is now available as Linux patch from the BIC web site. This version improves on transmission burstiness in the Linux TCP implementation and adds new features to increase its scalability. 2. We have been working on a new variant of TCP, called CUBIC. It is an enhancement to BIC; it is designed to improve the TCP-friendliness and RTT-fairness of BIC. It also greatly simplifies window control by employing a cubic window growth function. The details about CUBIC, its simulation and experimental results can be found in our BIC web site. You may glance through our new white paper available on the site to get a feel for the performance of CUBIC. You may also find our NS simulation code, simulation setup script, and Linux patch for CUBIC in the web site. (The script is not up yet, but will be up within a couple of days.) 3. BIC Version 1.0 is now bundled with the latest version of Linux 2.6. When you download the latest Linux 2.6 tree from ftp.kernel.org you will find BIC. It implements only the BIC congestion control algorithm -- it does not implement some features of fast SACK processing functionality which is known to reduce ACK processing overhead greatly. So the performance may not be as good as reported by others who are using our original BIC patch. 4. New burst control: The patches you can find from our BIC web site contain an implementation of our new burst control algorithm. It reduces packet burst, especially, during fast recovery by controlling packet-in-flight more intelligently. Our test indicates that this algorithm greatly contributes to avoidance of many timeouts and transmission rate fluctuations. As far as we know, there are several third-party evaluations of BIC-TCP going on at several research and commercial sites around the world. We will keep you updates on their results as soon as they become known to us. Your comments/feedback will be highly appreciated. Thanks Injong Rhee and Lisong Xu. Department of Computer Science North Carolina State University http://www.csc.ncsu.edu/faculty/rhee From rhee at eos.ncsu.edu Fri Jul 2 13:02:33 2004 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Fri Jul 2 13:01:08 2004 Subject: [e2e] Updates on BIC-TCP In-Reply-To: <200407021943.i62Jh8YJ005789@uni01mr.unity.ncsu.edu> Message-ID: <200407022000.i62K0WYJ010880@uni01mr.unity.ncsu.edu> Misspelled the subject line... > -----Original Message----- > From: end2end-interest-bounces@postel.org [mailto:end2end-interest- > bounces@postel.org] On Behalf Of Injong Rhee > To: end2end-interest@postel.org > Subject: [e2e] Uodates on BIC-TCP > > > We are happy to update you about our progress with BIC, one of many TCP > variants designed for high-speed long-distance networks. > You can find more information about the updates from the official BIC web > site: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index.htm > > 1 A new version of BIC (Version 1.1) is now available as Linux patch > from > the BIC web site. This version improves on transmission burstiness in the > Linux TCP implementation and adds new features to increase its scalability. > > 2. We have been working on a new variant of TCP, called CUBIC. It is an > enhancement to BIC; it is designed to improve the TCP-friendliness and > RTT-fairness of BIC. It also greatly simplifies window control by > employing > a cubic window growth function. The details about CUBIC, its simulation > and > experimental results can be found in our BIC web site. You may glance > through our new white paper available on the site to get a feel for the > performance of CUBIC. > > You may also find our NS simulation code, simulation setup script, and > Linux > patch for CUBIC in the web site. (The script is not up yet, but will be up > within a couple of days.) > > 3. BIC Version 1.0 is now bundled with the latest version of Linux 2.6. > When you download the latest Linux 2.6 tree from ftp.kernel.org > you will find BIC. > > It implements only the BIC congestion control algorithm -- it does not > implement some features of fast SACK processing functionality which is > known > to reduce ACK processing overhead greatly. So the performance may not be > as > good as reported by others who are using our original BIC patch. > > 4. New burst control: The patches you can find from our BIC web site > contain an implementation of our new burst control algorithm. It reduces > packet burst, especially, during fast recovery by controlling > packet-in-flight more intelligently. Our test indicates that this > algorithm > greatly contributes to avoidance of many timeouts and transmission rate > fluctuations. > > As far as we know, there are several third-party evaluations of BIC-TCP > going on at several research and commercial sites around the world. We > will > keep you updates on their results as soon as they become known to us. > Your comments/feedback will be highly appreciated. > > Thanks > > Injong Rhee and Lisong Xu. > Department of Computer Science > North Carolina State University > http://www.csc.ncsu.edu/faculty/rhee > > > From heejune at snut.ac.kr Sun Jul 4 20:19:40 2004 From: heejune at snut.ac.kr (Heejune AHN) Date: Sun Jul 4 20:20:19 2004 Subject: [e2e] A implementation question on TFRC algorithm Message-ID: <001801c4623e$e873e3e0$3551f6cb@heejune> Hi, while implementing a streaming server, I am currently doing TFRC transport adaptation module. After reviewing several papers of Sally Floyd and A. Zakhor, I sill cannot implement it just because I cannot understand one thing: "How to calculate Round-trip time in Receiver?" -------------------------------------------- it is written in her paper how to get Roud Trip time in Sender, measuing the feedback for same sequence num. (now my quetion, when the Rx decide to reply it?) I need this value because "Rx should report feedback to the sender at least once per round-trip time if it has received packets in that interval" (page 3 of SIGCOM 2000 publication, Equation-based Congestion control for Unicast Application, Sally Floyd et al). I checked it from D. Tan and A. Zakhor papers in IEEE multimedia, but the mechanism is not clear. Maybe I can check with Sally's ns-2 simulation script, but it is too much her computer-setting dependent script. I think it is not a big problem on their work, but I just want to know how they implemented it. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040705/ddfdb077/attachment.html From tcp_lq at 163.com Sun Jul 4 23:41:14 2004 From: tcp_lq at 163.com (Lv Qian) Date: Sun Jul 4 23:40:34 2004 Subject: [e2e] A implementation question on TFRC algorithm Message-ID: <200407050640.i656e9J11502@boreas.isi.edu> Heejune AHN£¬ ¡¡¡¡Hi,according to RFC 3448, section 3.2.1, each data packet sent by the data sender contains the sender's current estimate of the round trip time, which will be used by the receiver. ======== 2004-07-05 11:19:40 ======== Hi, while implementing a streaming server, I am currently doing TFRC transport adaptation module. After reviewing several papers of Sally Floyd and A. Zakhor, I sill cannot implement it just because I cannot understand one thing: "How to calculate Round-trip time in Receiver?" -------------------------------------------- it is written in her paper how to get Roud Trip time in Sender, measuing the feedback for same sequence num. (now my quetion, when the Rx decide to reply it?) I need this value because "Rx should report feedback to the sender at least once per round-trip time if it has received packets in that interval" (page 3 of SIGCOM 2000 publication, Equation-based Congestion control for Unicast Application, Sally Floyd et al). I checked it from D. Tan and A. Zakhor papers in IEEE multimedia, but the mechanism is not clear. Maybe I can check with Sally's ns-2 simulation script, but it is too much her computer-setting dependent script. I think it is not a big problem on their work, but I just want to know how they implemented it. Thanks. = = = = = = = = = = = = = = = = = = = = = = Lv Qian, School of Computer Engineering, Nanyang Technological University 2004-07-05 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040705/82f0bb92/attachment.html From magnus.westerlund at ericsson.com Mon Jul 5 01:48:24 2004 From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Mon Jul 5 01:49:19 2004 Subject: [e2e] A implementation question on TFRC algorithm In-Reply-To: <001801c4623e$e873e3e0$3551f6cb@heejune> References: <001801c4623e$e873e3e0$3551f6cb@heejune> Message-ID: <40E915D8.1090809@ericsson.com> Hi Heejune, I think the missing question here is, what transport protocol are you trying to implement TFRC over? RTP/UDP? In that case you will have some problems. Standard RTP does not have sufficient information to implement TFRC over. You will require certain extensions, and also there is the big question if your manage to get the feedback to report frequently enough per the TFRC requirements. The IETF AVT WG are currently looking into what would be required to implement TFRC over RTP. There is an initial proposal in the draft: http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-00.txt Please note that this is very initial work and will require more discussion. Cheers Magnus Heejune AHN wrote: > Hi, while implementing a streaming server, I am currently doing TFRC > transport adaptation module. > > After reviewing several papers of Sally Floyd and A. Zakhor, I sill > cannot implement it just because > I cannot understand one thing: > > "How to calculate Round-trip time in Receiver?" > -------------------------------------------- > it is written in her paper how to get Roud Trip time in Sender, measuing > the feedback for same sequence num. > (now my quetion, when the Rx decide to reply it?) > > I need this value because > "Rx should report feedback to the sender at least once per round-trip > time if it has received packets in that interval" > (page 3 of SIGCOM 2000 publication, Equation-based Congestion control > for Unicast Application, Sally Floyd et al). > I checked it from D. Tan and A. Zakhor papers in IEEE multimedia, > but the mechanism is not clear. > > Maybe I can check with Sally's ns-2 simulation script, but it is too > much her computer-setting dependent script. > I think it is not a big problem on their work, but I just want to know > how they implemented it. > > Thanks. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com From jshen_cad at yahoo.com.cn Wed Jul 7 03:35:19 2004 From: jshen_cad at yahoo.com.cn (=?gb2312?q?Jing=20Shen?=) Date: Wed Jul 7 03:36:29 2004 Subject: [e2e] Relationship between DNS request and server performance Message-ID: <20040707103519.72210.qmail@web15408.mail.cnb.yahoo.com> Hi, I'm reading some paper on DNS system, and I noticed there is some paper on DNS system in upcoming Sigcomm . But, is there any work on analize relationship between DNS server traffic ( or amount of incoming DNS resolution requiries) and CPU load ( or something alike) ? thanks Jing Shen _________________________________________________________ Do You Yahoo!? 100Õ×ÓÊÏä¹»²»¹»Óã¿ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/100m/*http://cn.promo.yahoo.com/minisite/100m/ From tphelan at sonusnet.com Wed Jul 7 06:22:01 2004 From: tphelan at sonusnet.com (Phelan, Tom) Date: Wed Jul 7 06:22:33 2004 Subject: [e2e] A implementation question on TFRC algorithm Message-ID: Hi Heejune, The DCCP implementation of TFRC (CCID3, see draft-ietf-dccp-ccid3-05.txt) uses a "window counter", sent with each packet. It's a four-bit counter that's increased once each quarter-RTT. So the receiver interprets each increase of four in the counter value (with wrap) as a round trip time. It's actually a little more complicated than the above explanation, so see the draft if you need the details. Tom Phelan > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, July 05, 2004 4:48 AM > To: Heejune AHN > Cc: end2end-interest@postel.org > Subject: Re: [e2e] A implementation question on TFRC algorithm > > > Hi Heejune, > > I think the missing question here is, what transport protocol are you > trying to implement TFRC over? RTP/UDP? In that case you will > have some > problems. Standard RTP does not have sufficient information > to implement > TFRC over. You will require certain extensions, and also there is the > big question if your manage to get the feedback to report frequently > enough per the TFRC requirements. > > The IETF AVT WG are currently looking into what would be required to > implement TFRC over RTP. There is an initial proposal in the draft: > http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-00.txt > > Please note that this is very initial work and will require more > discussion. > > Cheers > > Magnus > > Heejune AHN wrote: > > > Hi, while implementing a streaming server, I am currently > doing TFRC > > transport adaptation module. > > > > After reviewing several papers of Sally Floyd and A. > Zakhor, I sill > > cannot implement it just because > > I cannot understand one thing: > > > > "How to calculate Round-trip time in Receiver?" > > -------------------------------------------- > > it is written in her paper how to get Roud Trip time in > Sender, measuing > > the feedback for same sequence num. > > (now my quetion, when the Rx decide to reply it?) > > > > I need this value because > > "Rx should report feedback to the sender at least once per > round-trip > > time if it has received packets in that interval" > > (page 3 of SIGCOM 2000 publication, Equation-based > Congestion control > > for Unicast Application, Sally Floyd et al). > > I checked it from D. Tan and A. Zakhor papers in IEEE multimedia, > > but the mechanism is not clear. > > > > Maybe I can check with Sally's ns-2 simulation script, but > it is too > > much her computer-setting dependent script. > > I think it is not a big problem on their work, but I just > want to know > > how they implemented it. > > > > Thanks. > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > From craig at bbn.com Wed Jul 7 10:59:13 2004 From: craig at bbn.com (Craig Partridge) Date: Wed Jul 7 10:59:29 2004 Subject: [e2e] Relationship between DNS request and server performance In-Reply-To: Your message of "Wed, 07 Jul 2004 18:35:19 +0800." <20040707103519.72210.qmail@web15408.mail.cnb.yahoo.com> Message-ID: <20040707175913.3B7301A8@aland.bbn.com> There's a lot of data -- it doesn't tend to get published. Some of it gets presented at NANOG. I'd dig there for starters -- look for names and go from there. Craig In message <20040707103519.72210.qmail@web15408.mail.cnb.yahoo.com>, =?gb2312?q ?Jing=20Shen?= writes: >Hi, > > I'm reading some paper on DNS system, and I noticed >there is some paper on DNS system in upcoming Sigcomm >. > > But, is there any work on analize relationship >between DNS server traffic ( or amount of incoming DNS >resolution requiries) and CPU load ( or something >alike) ? > > thanks > > >Jing Shen > >_________________________________________________________ >Do You Yahoo!? >100Õ×ÓÊÏä¹»²»¹»Óã¿ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ >http://cn.rd.yahoo.com/mail_cn/tag/100m/*http://cn.promo.yahoo.com/minisite/10 >0m/ From ron.lee at samsung.com Fri Jul 9 00:04:18 2004 From: ron.lee at samsung.com (Ron Lee) Date: Fri Jul 9 00:05:36 2004 Subject: [e2e] a question about the deployment of SACK TCP Message-ID: <0I0K000UOOYYWP@ms7.samsung.com> An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040709/cd2fa0d5/attachment.html From claypool at cs.WPI.EDU Fri Jul 9 07:55:17 2004 From: claypool at cs.WPI.EDU (Mark Claypool) Date: Fri Jul 9 08:00:36 2004 Subject: [e2e] a question about the deployment of SACK TCP In-Reply-To: <0I0K000UOOYYWP@ms7.samsung.com> References: <0I0K000UOOYYWP@ms7.samsung.com> Message-ID: <16622.45525.980598.968316@saagar.wpi.edu> Ron Lee writes: > Only 5% of the TCP connections actually use SACK, (From Anja > Feldmann, trace from 12/99) according to > http://www.icir.org/floyd/sack-questions.html of October 2000. Is > there an up-to-date answer to this? What fraction of the > bytes/packets/TCP-flows in the Internet are SACK-capable? Our analysis of some data gathered from a commercial broadband provider in Fall 2003 shows about 90% of the flows are SACK-enabled. Further analysis suggests that SACK significantly reduces the number of retransmissions compared to the non-SACK enabled flows. More details can be found in: Todd DeSantis and David Loose. "TCP Traffic Analysis", Major Qualifying Project MQP-MLC-MT03, Computer Science Department, Fall 2003. Sponsored by Motorola. (Advisors Mark Claypool and Robert Kinicki) Online at: http://www.cs.wpi.edu/~claypool/mqp/motorola/ Mark ------------------------------------------------------------------------ Mark Claypool CS Associate Professor claypool@cs.wpi.edu Worcester Polytechnic Institute http://www.cs.wpi.edu/~claypool/ From kostas at cs.sunysb.edu Fri Jul 9 14:22:20 2004 From: kostas at cs.sunysb.edu (Kostas Pentikousis) Date: Fri Jul 9 14:23:35 2004 Subject: [e2e] a question about the deployment of SACK TCP In-Reply-To: <16622.45525.980598.968316@saagar.wpi.edu> References: <0I0K000UOOYYWP@ms7.samsung.com> <16622.45525.980598.968316@saagar.wpi.edu> Message-ID: On Fri, 9 Jul 2004, Mark Claypool wrote: |Ron Lee writes: | > Only 5% of the TCP connections actually use SACK, (From Anja | > Feldmann, trace from 12/99) according to Off-the-box Windows 2000/XP/2003, Solaris 9, and Linux 2.4+ advertize SACK capability. No patches needed. | > there an up-to-date answer to this? What fraction of the | > bytes/packets/TCP-flows in the Internet are SACK-capable? "in the Internet" is quite difficult to say. Padhye & Floyd used TBIT in "Identifying the TCP Behavior of Web Servers" to determine what TCP flavors are deployed "out there". (Ignore for a moment the fact the study is limited to web servers.) They found that a large percentage of hosts (more than half) advertize SACK, but only 6% of hosts use SACK correctly (see also their NANOG presentation: http://www.nanog.org/mtg-0010/tcp.html) |Our analysis of some data gathered from a commercial broadband |provider in Fall 2003 shows about 90% of the flows are SACK-enabled. We've been studying traces from the NLANR/PMA repository for some time now. The first batch of results from 12 different sites (see "Quantifying the deployment of TCP options - A comparative study", http://www.cs.stonybrook.edu/~kostas/art/) shows that SACK is likely to be advertized in the vast majority of TCP connections (~80%). Nevertheless, the percentage of "pure ACKs" in the traces is relatively high, which begs the question: how many SACK blocks are actually transmitted (let alone taken advantage of)? |Further analysis suggests that SACK significantly reduces the |number of retransmissions compared to the non-SACK enabled flows. This is quite interesting (esp. cf. Balakrishnan et al., "TCP Behavior of a Busy Internet Server: Analysis and Improvements"). In any case, enabling SACK and getting a benefit from it are two different things. Although it is quite possible that nowadays more than 6% of the hosts use SACK correctly, our results indicate that SACK is not accompanied by large windows advertisements, which could significantly reduce the benefits from SACK deployment "out there". Best regards, Kostas __________________________________________________________________ Kostas Pentikousis www.cs.stonybrook.edu/~kostas From lars.eggert at netlab.nec.de Sat Jul 10 00:08:55 2004 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Sat Jul 10 00:09:41 2004 Subject: [e2e] a question about the deployment of SACK TCP In-Reply-To: References: <0I0K000UOOYYWP@ms7.samsung.com> <16622.45525.980598.968316@saagar.wpi.edu> Message-ID: <40EF9607.60301@netlab.nec.de> Kostas Pentikousis wrote: > On Fri, 9 Jul 2004, Mark Claypool wrote: > > |Ron Lee writes: > | > Only 5% of the TCP connections actually use SACK, (From Anja > | > Feldmann, trace from 12/99) according to > > Off-the-box Windows 2000/XP/2003, Solaris 9, and Linux 2.4+ > advertize SACK capability. No patches needed. FreeBSD-CURRENT (finally) gained SACK support last week, too, and I think it's enabled by default. Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3360 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040710/473e9062/smime.bin From E.Hamadani at city.ac.uk Sat Jul 10 04:12:30 2004 From: E.Hamadani at city.ac.uk (Ehsan Hamadani) Date: Sat Jul 10 04:15:44 2004 Subject: [e2e] Question about TCP data flow Message-ID: <002f01c4666e$caf9c9e0$1d59288a@city> Hi all, Is there any reference about current Internet traffic characteristics such as the percentage of TCP data, the percentage of DNS messages, etc?? The last paper that I have seen in this area is "Wide-Area Internet Traffic Patterns and Characteristics" by "Kevin Thompson, Gregory J. Miller, and Rick Wilder" which was published in 1997. I would appreciate if someone can introduce me a more recent results about this issue. Thanks Ehsan ------------------------------------------------------------- Ehsan Hamadani, PhD student School of Engineering & Mathematical Science CITY University London, EC1V 0HB United Kingdom Telephone: +44(0)2070403886 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20040710/73a23d62/attachment.html From mallman at icir.org Mon Jul 12 06:22:55 2004 From: mallman at icir.org (Mark Allman) Date: Mon Jul 12 06:23:43 2004 Subject: [e2e] a question about the deployment of SACK TCP In-Reply-To: Message-ID: <20040712132255.C656777ADFC@guns.icir.org> > | > there an up-to-date answer to this? What fraction of the > | > bytes/packets/TCP-flows in the Internet are SACK-capable? > > "in the Internet" is quite difficult to say. Padhye & Floyd used > TBIT in "Identifying the TCP Behavior of Web Servers" to determine > what TCP flavors are deployed "out there". (Ignore for a moment > the fact the study is limited to web servers.) They found that a > large percentage of hosts (more than half) advertize SACK, but > only 6% of hosts use SACK correctly (see also their NANOG > presentation: http://www.nanog.org/mtg-0010/tcp.html) I agree, it's difficult to precisely quantify. But, a couple of quick results from our recent measurements .... * The fraction of web servers that advertise SACK capability is approximately 68%. * The fraction of web servers that do not use SACK in some way is quite low (~3%). That is not to say that the web servers always use SACK in the best possible way --- just that they use some SACK info at some point. * The fraction of clients at one particular site we traced was about 88%. (This agrees with some rough analysis we have done of a couple of other sites.) * Of the connections we observed whereby the client and server agreed to use SACK nearly all of the clients generated SACK blocks in connections with retransmitted packets. While it is difficult to make a one-sided analysis terribly conclusive in this area this result seems to indicate that clients are, in fact, generating SACK information when needed. And, further, the SACK information we observed nearly always falls along segment boundaries --- further suggesting its accuracy. The details on all of this (except the rough hand-wave about corroborating sites) is available in: Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. May 2004. http://www.icir.org/mallman/papers/tcp-evo-submit.ps Comments welcome and appreciated! allman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040712/67cc5bb2/attachment.bin From josegil1 at motorola.com Mon Jul 12 14:30:43 2004 From: josegil1 at motorola.com (Gil Jose-josegil1) Date: Mon Jul 12 14:32:01 2004 Subject: [e2e] a question about the deployment of SACK TCP Message-ID: Has anybody investigated if the SACK-based loss recovery mechanism as specified in RFC 3517 is actually implemented and what is its performance in the live Internet? I believe to have read that the fact that SACK information is exchanged does not imply that a SACK-based loss recovery mechanism is in use, and if it is it might not follow RFC3517. I haven't finished reading the papers proposed in this thread but please advise if these or other papers contain such investigation. Jose -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org] On Behalf Of Mark Allman Sent: 12 July 2004 14:23 To: Kostas Pentikousis Cc: Mark Claypool; ron.lee@samsung.com; end2end-interest@postel.org Subject: Re: [e2e] a question about the deployment of SACK TCP > | > there an up-to-date answer to this? What fraction of the > | > bytes/packets/TCP-flows in the Internet are SACK-capable? > > "in the Internet" is quite difficult to say. Padhye & Floyd used TBIT > in "Identifying the TCP Behavior of Web Servers" to determine what TCP > flavors are deployed "out there". (Ignore for a moment the fact the > study is limited to web servers.) They found that a large percentage > of hosts (more than half) advertize SACK, but only 6% of hosts use > SACK correctly (see also their NANOG > presentation: http://www.nanog.org/mtg-0010/tcp.html) I agree, it's difficult to precisely quantify. But, a couple of quick results from our recent measurements .... * The fraction of web servers that advertise SACK capability is approximately 68%. * The fraction of web servers that do not use SACK in some way is quite low (~3%). That is not to say that the web servers always use SACK in the best possible way --- just that they use some SACK info at some point. * The fraction of clients at one particular site we traced was about 88%. (This agrees with some rough analysis we have done of a couple of other sites.) * Of the connections we observed whereby the client and server agreed to use SACK nearly all of the clients generated SACK blocks in connections with retransmitted packets. While it is difficult to make a one-sided analysis terribly conclusive in this area this result seems to indicate that clients are, in fact, generating SACK information when needed. And, further, the SACK information we observed nearly always falls along segment boundaries --- further suggesting its accuracy. The details on all of this (except the rough hand-wave about corroborating sites) is available in: Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. May 2004. http://www.icir.org/mallman/papers/tcp-evo-submit.ps Comments welcome and appreciated! allman From touch at ISI.EDU Tue Jul 20 17:03:13 2004 From: touch at ISI.EDU (Joe Touch) Date: Tue Jul 20 17:04:24 2004 Subject: [e2e] CFP: International Infrastructure Survivability Workshop (IISW'04) Message-ID: <40FDB2C1.2040703@isi.edu> Subject: CFP: International Infrastructure Survivability Workshop (IISW'04) Date: Tue, 20 Jul 2004 11:22:52 -0700 From: Joe Touch Reply-To: Calin Curescu To: End-to-end CALL FOR PAPERS: International Infrastructure Survivability Workshop (IISW'04) """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Overloads, Attacks and Failures: the Trade-off against Time www.ida.liu.se/~calcu/iisw04 To be held in conjunction with the 25th IEEE International Real-Time Systems Symposium (RTSS04) December 5-8, 2004 Lisbon, Portugal SCOPE: Society today is increasingly dependent on critical infrastructures that constitute the backbone for delivery of its essential services. Many critical services such as power supplies, public transport, telecommunications, banking and finance, and defence will be increasingly relying on information infrastructures, not only for management and control but also for monitoring outages and recovery. Combinations of wireless and ad hoc networks with fixed networks are becoming a reality in many domains. Traditional solutions in dependable systems build in robustness at the production stage. Using redundancy, feedback mechanisms, and careful sensitivity analysis the system is shown to stay in its characterised operational profile and shows graceful degradation when components fail. In today's networked infrastructures it is more difficult to achieve these goals due to the following developments: * New infrastructures are built as partial overlays with old infrastructures making the emerging system of systems irregular in its architecture. * Introduction of new services, emerging trends and deregulation contribute to unbalancing phenomena: operational conditions may change abruptly creating traffic/flow patterns not foreseen by operators. * Prevalence of software brings with it the weaknesses of COTS, making systems more susceptible to "normal" failures and malicious attempts to bring down a service. * Tomorrow's networked systems will have to face the challenge of survivability: delivering critical services in a timely manner in presence of overloads, attacks and failures. In this workshop we intend to bring together research that addresses the above issues by incorporating metrics that represent the use of scarce resources, reflecting timing performance, anticipating outages and mobilising system reconfigurations to stall outages or recover from partial failures. Practical experience reports are highly encouraged. Papers that describe original unpublished work are solicited and selected papers will be published in a special issue of the International Journal on Critical Infrastructures (IJCIS). The topics of interest cover, but are not limited to, the following areas: * Models and architectures for network survivability * Network fault-tolerance: wireless networks, sensor networks, IP networks * Interoperability between hybrid wireline/wireless networks * Fraud and intrusion Detection, Prediction, and Countermeasures * Survivable architectures for e-commerce * Security and availability of web services * Support for QoS * Adaptive systems theory and practice * Quality metrics in open systems * Availability/Performance trade-offs * Security/Performance trade-offs * Case studies and experimental studies WORKSHOP CHAIR: Simin Nadjm-Tehrani, Link?ping University, Sweden, simin@ida.liu.se ORGANISATION CHAIR: Calin Curescu, Link?ping University, Sweden, calcu@ida.liu.se Program Committee: Calin Curescu, Link?ping University, Sweden Marc Dacier, Eur?com, France Teresa A. Dahlberg, UNC Charlotte, USA Luiz A. DaSilva, VirginiaTech, USA Val?rie Issarny, INRIA, France John Knight, University of Virginia, USA H?kan Kvarnstr?m, TeliaSonera, Sweden Simin Nadjm-Tehrani, Link?ping University, Sweden Heinz Thielmann, Fraunhofer SIT, Germany Lonnie Welch, Ohio University, USA IMPORTANT DATES: Submission deadline: 4 September 2004 Acceptance notification: 4 October 2004 Final version due: 4 November 2004 SUBMISSION GUIDELINES: Original work not published and not subject to review elsewhere is solicited. Papers should be of length 8-10 pages in standard IEEE format, including: abstract, 3-5 keywords, and corresponding author's e-mail. -------------- 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/20040720/f1b17ec6/signature.bin From touch at ISI.EDU Tue Jul 20 17:05:22 2004 From: touch at ISI.EDU (Joe Touch) Date: Tue Jul 20 17:06:25 2004 Subject: [e2e] CFP for CCR issue on "Internet Vital Statistics" Message-ID: <40FDB342.1070802@isi.edu> CALL FOR PAPERS Measuring the Internet's Vital Statistics A Special Issue of ACM SIGCOMM COMPUTER COMMUNICATION REVIEW There are a number of measurements of the Internet's basic properties that are tremendously useful for researchers to know. A solid understanding of key Internet properties is useful for: * creating quality models to evaluate innovative new protocols, algorithms and architectures * understanding the overall context with which a new system will inevitably have to cope if/when deployed * gaining an appreciation for the variety and breadth of situations one may encounter when measuring the Internet Yet, as the Internet has grown, many of these measurements are no longer widely circulated -- often because they are viewed as operational rather than of research interest. Assumptions based on dated information about the operational Internet are used every day by researchers. Unreliable assumptions about the Internet's key properties may lead to everything from wasted time in appreciating the breadth of scenarios one must take into account in measurement analysis to simulation studies that are not of practical import because of the inaccurate models. The goal of this special issue is to begin the practice of periodically publishing measurement studies of the Internet that concisely provide reliable, easily accessible information for researchers to use and build on. Our aim is to complement traditional measurement venues that emphasize new measurement techniques and evaluations of new protocols and architectures, by updating the community's working knowledge of the basic properties. Examples of measurements that would be of interest are: * a breakdown of the types of bad/defective/broken DNS queries received at the typical root server; * how frequently the TCP/UDP checksum and the MAC-layer CRC disagree; * the distribution of traffic among different applications (perhaps, measured at different points in the network); * the ratio of local traffic to global traffic; * how often the forward and return paths of a TCP connection differ; * how often traffic is reordered; * the variation in BGP route prefixes advertised over the course of a typical minute, hour, day, week, and month; * distributions of round-trip times experienced in the network Our expectation is that each paper will be short: a description of the methodology by which the data was captured and where it was gathered, a presentation of results, and where possible, a comparison of the current results with those of prior years (and other researchers). The focus of the papers should be on the data, rather than on developing new methodologies. We encourage authors to collaborate to illustrate information from multiple vantage points in the network. In addition, we especially solicit papers that are coupled to public release of measurement datasets (even if anonymized in some form). Our aim is to initiate a cycle whereby the community constantly updates our collective understanding of the Internet's basic properties. Therefore, following the publication of this special issue, CCR and Sigcomm will endeavor to continuously publish papers on the Internet's basic properties to keep the community's perspective fresh. Please submit papers to the special issue by email to ccr-ivs@lists.csail.mit.edu For further information and submission details please see http://www.acm.org/sigcomm/ccr/ivs Please address questions about content or submission procedure to ccr-ivs@lists.csail.mit.edu Schedule: Submissions due November 1, 2004 Acceptance decisions December 3, 2004 Publication January, 2005 Special Issue Editors Mark Allman, ICIR Craig Partridge, BBN -------------- 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/20040720/b0538b8f/signature.bin From koenig at Informatik.TU-Cottbus.DE Wed Jul 21 07:23:26 2004 From: koenig at Informatik.TU-Cottbus.DE (=?ISO-8859-1?Q?Hartmut_K=F6nig?=) Date: Wed Jul 21 13:18:11 2004 Subject: [e2e] Call for Participation IEEE ICNP 2004 Message-ID: <40FE7C5E.1060000@informatik.tu-cottbus.de> Dear colleague, enclosed please find the Call for Participation for IEEE ICNP 2004 held in Berlin, the capitol of Germany, October 5th - 8th, 2004. ICNP 2004 is organized by BTU Cottbus, the Brandenburg University of Technology Cottbus and University of Mannheim. Advanced registration deadline is August 31st, 2004. You can find more information on conference program and registration at the ICNP web site http://www.icnp2004.de.vu (Conference Program and Registration/Hotels) ICNP 2004 features are: * Invited talk by Henning Schulzrinne (Columbia University New York), * 4 tutorials on overlay networks, router architectures, content delivery networks, and the SCTP protocol, * 2 and a half-day single track of peer-reviewed papers on routing, wireless networks, peer-to-peer and overlay networks, performance evaluation, network management, and security * student poster session * social event with an excursion to the castle of Sanscouci at Potsdam. We are looking forward to meeting you at ICNP 2004, Hartmut Koenig and Wolfgang Effelsberg. -- ________________________________________________________________________ Hartmut K?nig Tel: +49 355 69 22 36 koenig@informatik.tu-cottbus.de Fax: +49 355 69 21 27 BTU Cottbus LS Rechnernetze und Kommunikationssysteme PF 10 13 44, D-03013 Cottbus, Germany http://www-rnks.informatik.tu-cottbus.de ________________________________________________________________________ From chuahn_2 at hotmail.com Wed Jul 28 06:15:10 2004 From: chuahn_2 at hotmail.com (Chua Hong Nung) Date: Wed Jul 28 06:15:54 2004 Subject: [e2e] How to estimate packet loss? Message-ID: Hi, In TFRC it is suggested that loss event fraction models TCP more accurately than loss fraction does. However I am quite confuse of how to estimate packets in a loss interval. Given this data packets, would someone please tell me how to estimate packets in a loss interval. packets sent: 1 2 3 4(loss) 5(loss) 6 7 8 9 10 11 12 13(loss) 14(loss) 15(loss) 16 17 18 19 20 21(loss) 22 23 24 interval1 = 13 - 6 or interval1 = 13 - 4 ? interval2 = 21 - 16 or interval2 = 21 - 13 ? Thank you. Chua _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ From M.Handley at cs.ucl.ac.uk Wed Jul 28 07:06:32 2004 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Wed Jul 28 07:08:56 2004 Subject: [e2e] How to estimate packet loss? In-Reply-To: Your message of "Wed, 28 Jul 2004 13:15:10 -0000." Message-ID: <64636.1091023592@aardvark.cs.ucl.ac.uk> >In TFRC it is suggested that loss event fraction models TCP more >accurately than loss fraction does. However I am quite confuse of how to >estimate packets in a loss interval. Given this data packets, would someone >please tell me how to estimate packets in a loss interval. > >packets sent: 1 2 3 4(loss) 5(loss) 6 7 8 9 10 11 12 >13(loss) 14(loss) 15(loss) 16 17 18 19 20 21(loss) 22 23 24 > >interval1 = 13 - 6 or interval1 = 13 - 4 ? >interval2 = 21 - 16 or interval2 = 21 - 13 ? You don't say anything about the packets/RTT, which determines which losses are in the same loss event. So less make some assumptions: We're transmitting less than 8 and more that 3 packets per RTT, so there are three loss events in your trace: packets 4 and 5 are part of loss event 1 packets 13, 14 and 15 and part of loss event 2 packet 21 is part of loss event 3. Now it doesn't matter all that much exactly how you measure loss, so long as each packet (lost or otherwise) is part of exactly one loss interval. So: interval 1 could include packets 4 to 12 (9 packets) interval 2 could include packets 13 to 20 (8 packets) Hope this helps, Mark From fcao at CS.Princeton.EDU Thu Jul 29 00:27:59 2004 From: fcao at CS.Princeton.EDU (Fengyun Cao) Date: Thu Jul 29 00:29:10 2004 Subject: [e2e] look for female Sigcomm attendee to share room Message-ID: Hi, sorry for the spam. I'm a female grad student and am looking for a female to share a Sigcomm hotel room. I will arrive on Monday and leave on Friday during the conference week and so hope to share the room for four nights. It is negotiable if your schedule is a bit different. Because the hotel discount rate requires booking room before 8/2, I look forward to any reply as soon as possible! Thanks a lot, Fengyun Cao From arjuna at dcs.kcl.ac.uk Thu Jul 29 01:22:36 2004 From: arjuna at dcs.kcl.ac.uk (Arjuna Sathiaseelan) Date: Thu Jul 29 01:23:59 2004 Subject: [e2e] TCP Performance in Satellite Networks Message-ID: <14239.195.92.67.79.1091089356.squirrel@195.92.67.79> Dear All, I am a PhD student and am testing the performance of TCP on Satellite Networks when packet reordering occurs. I am a novice, so please excuse me if somethings are irrelevant. I perform reordering by normal distribution and packets are delayed in the range of 0ms to 200ms. This error module was attached to all the satellite nodes. I use an Iridium constellation network. I perform experiments for 100s. The maximum congestion window was set to 500. >From what I see is that when I use Sally Floyd's RR-TCP and TCP DSACK - the performance was similar to standard TCP SACK. DSACK's were generated and received successfully but the restoration of the congestion window upon false retransmits never took place!! Even though I had a high maximum window size, the congestion window grew only upto 10 segments. Moreover when I increase the dupthresh values (to 4,5,6), I see more timeout events, so I guess increasing the dupthresh values when reordering occurs is not the right way since it leads to more timeouts because of the large RTT. Am I right? I would like to know why does RR-TCP and DSACK have no impact on the performance. Has anyone tested the performance of both the protocols on a Satellite environment? I would be very much obliged if someone could clarify these doubts please. Regards, Arjuna From jussara at dcc.ufmg.br Sat Jul 31 09:43:48 2004 From: jussara at dcc.ufmg.br (Jussara Marques de Almeida) Date: Sat Aug 7 08:09:49 2004 Subject: [e2e] SIGMETRICS 2005 - CFP Message-ID: <200407311643.i6VGhmFj000735@dcc.ufmg.br> Apologies in advance if you receive multiple copies of this message. ------------------------------------------------------------------------------- CALL FOR PAPERS ACM SIGMETRICS 2005 International Conference on Measurement & Modeling of Computer Systems Sponsored by ACM SIGMETRICS June 6-10, 2005, Banff, Canada http://www.cse.cuhk.edu.hk/conference/sigmetrics2005 The ACM SIGMETRICS conference solicits papers on the development and application of state-of-the-art, broadly-applicable analytic, simulation, and measurement-based performance evaluation techniques. Of particular interest is work that furthers the state-of-the-art in performance evaluation methods, or those that creatively apply previously developed methods to understand or to gain important insights into key design trade-offs in complex computer/communication systems. Topics of interest include, but are not limited to: - Performance-oriented design and evaluation studies of: communication networks, Internet servers, computer architectures, database systems, operating systems, distributed systems, multimedia systems, file and I/O subsystems, memory systems, real-time systems, and fault-tolerant systems. - Performance methodology techniques and algorithms for: analytic modeling, system measurement and monitoring, model verification and validation, workload characterization, simulation, statistical analysis, stochastic modeling including queues and Petri nets, experimental design, reliability analysis, performance optimization, and hybrid models. SUBMISSION GUIDELINES: PAPERS: Papers should not exceed 20 double-spaced pages including figures and tables. Papers must be submitted electronically in printable postscript or pdf form; for detailed submission instructions, refer to the above URL. All submissions will be reviewed using a double-blind review process. The identity of authors and referees will not be revealed to each other. To ensure blind reviewing, authors' names and affiliations should not appear in the paper; bibliographic references should be made in such a way as to preserve author anonymity. HOT TOPIC SESSIONS: Proposals are solicited for a hot topic session, in which a group of speakers will present and discuss their recent results in an area. Send proposals to the program chairs, identifying the organizer of the session, the session title, three to five speakers, the titles of their talks, and a short abstract of each talk. WORKSHOPS: One or more workshops will immediately precede the conference. Send proposals of no more than 1-2 pages to the general chairs. Include the proposed title, brief description of topics, intended audience, and membership of workshop organizing committee. Postscript or pdf is preferred. TUTORIALS: A series of tutorials will immediately precede the conference. Send proposals of no more than 1-2 pages for 90 minute or 3 hours tutorials to the tutorials chair. Include the proposed title, brief description of material, intended audience, assumed background of attendees, and the name, affiliation, contact information (email & phone) and brief biography of speaker(s). Postscript or pdf is preferred. IMPORTANT DATES (tentative): October 22, 2004: Abstract registration. October 29, 2004: Submission of papers, hot topic proposals, workshops and tutorial proposals. January 28, 2005: Notification of acceptance. ORGANIZATION: General Chairs: Derek Eager University of Saskatchewan eager@cs.usask.ca Carey Williamson University of Calgary carey@cpsc.ucalgary.ca Program Chairs: Sem Borst Bell Labs and CWI sem@research.bell-labs.com or sem.borst@cwi.nl John C. S. Lui The Chinese University of Hong Kong cslui@cse.cuhk.edu.hk Tutorial Chairs: Kimberly Keeton HP Labs kkeeton@hpl.hp.com Vishal Misra Columbia University misra@cs.columbia.edu The complete conference and program committees can be found at the above URL.