From salman at cs.columbia.edu Sat Jul 1 13:22:09 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Sat, 1 Jul 2006 16:22:09 -0400 (EDT) Subject: [e2e] MSS and cwnd increase Message-ID: I am wondering how the Linux 2.6 updates its congestion window when a CBR stream (packet size << MSS) is sent over TCP. In general, if I am sending 100 packets every second with a packet size of one byte and assuming each packet is ACKed, then increasing window by one every RTT (during congestion avoidance) will artifically inflate the window. Thus, the cwnd calculation should not assume that the last packet sent contained MSS bytes of data. The rfc and the code and seem to imply that cwnd increase is MSS-based. I haven't confirmed either way (still testing it) and will like to know: 1) What is the RFC suggested way? 2) How Linux 2.6 is implementing it? Regards, Salman From ian.mcdonald at jandi.co.nz Sat Jul 1 15:54:34 2006 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Sun, 2 Jul 2006 10:54:34 +1200 Subject: [e2e] MSS and cwnd increase In-Reply-To: References: Message-ID: <5640c7e00607011554o76fc79ffn784e4121d3a4b6f4@mail.gmail.com> On 7/2/06, Salman Abdul Baset wrote: > I am wondering how the Linux 2.6 updates its congestion window when a CBR > stream (packet size << MSS) is sent over TCP. > > In general, if I am sending 100 packets every second with a packet size > of one byte and assuming each packet is ACKed, then increasing window by > one every RTT (during congestion avoidance) will artifically inflate the > window. Thus, the cwnd calculation should not assume that the last packet > sent contained MSS bytes of data. > > The rfc and the code and seem to imply that cwnd increase is MSS-based. I > haven't confirmed either way (still testing it) and will like to know: > 1) What is the RFC suggested way? > 2) How Linux 2.6 is implementing it? > Linux has changed to use RFC 3465 Appropriate Byte Counting (ABC) for exactly this sort of reason. This can be turned off or on but is on by default. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand From weixl at caltech.edu Sat Jul 1 16:23:01 2006 From: weixl at caltech.edu (Xiaoliang (David) Wei) Date: Sat, 1 Jul 2006 16:23:01 -0700 Subject: [e2e] MSS and cwnd increase References: Message-ID: <02f901c69d65$5b25f5f0$f63b010a@baybridge> Hi Salman, > The rfc and the code and seem to imply that cwnd increase is MSS-based. I > haven't confirmed either way (still testing it) and will like to know: > 1) What is the RFC suggested way? RFC2581 -- TCP Congestion Control-- suggests to count SMSS (acknowledged packets) in cwnd increment. RFC3465 -- TCP Congestion Control with Appropriate Byte Counting (ABC)-- suggests to count the acknowledged byte instead of packets in cwnd increment. > 2) How Linux 2.6 is implementing it? Linux 2.6.16 (and later versions) implemented ABC for Reno. ABC is not implemented for other congestion control algorithms like HS-TCP yet. (Maybe later versions will implement ABC for other congestion control algorithms. But not sure yet...) -David From touch at ISI.EDU Sat Jul 1 16:50:06 2006 From: touch at ISI.EDU (Joe Touch) Date: Sat, 01 Jul 2006 16:50:06 -0700 Subject: [e2e] MSS and cwnd increase In-Reply-To: References: Message-ID: <44A70A2E.5070206@isi.edu> Salman Abdul Baset wrote: > I am wondering how the Linux 2.6 updates its congestion window when a CBR > stream (packet size << MSS) is sent over TCP. The better question is why are you sending CBR over TCP? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060701/a12411d6/signature.bin From salman at cs.columbia.edu Sat Jul 1 23:45:17 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Sun, 2 Jul 2006 02:45:17 -0400 (EDT) Subject: [e2e] MSS and cwnd increase In-Reply-To: <44A70A2E.5070206@isi.edu> References: <44A70A2E.5070206@isi.edu> Message-ID: We want to understand the TCP behavior when it carries cbr(voice) traffic. You might be aware that Skype is also sending voice over TCP in certain scenarios. Ofcourse, I am not going to suggest that it is a good idea to do that; rather, we are trying to understand various circumstances (packet loss, delay) under which a Skype like application can possibly send voice traffic over TCP without incurring too much delay and jitter. NAT and firewall restrictions are examples of settings where an application may want to send voice over TCP. Again, the purpose is to understand the effects and this does not imply that we are recommending this practice. regards, Salman On Sat, 1 Jul 2006, Joe Touch wrote: > > > Salman Abdul Baset wrote: > > I am wondering how the Linux 2.6 updates its congestion window when a CBR > > stream (packet size << MSS) is sent over TCP. > > The better question is why are you sending CBR over TCP? > > Joe > > From perfgeek at mac.com Sun Jul 2 12:48:16 2006 From: perfgeek at mac.com (rick jones) Date: Sun, 2 Jul 2006 12:48:16 -0700 Subject: [e2e] MSS and cwnd increase In-Reply-To: References: Message-ID: <3c29f1dffe4d04e4413417afcc8dd58b@mac.com> On Jul 1, 2006, at 1:22 PM, Salman Abdul Baset wrote: > I am wondering how the Linux 2.6 updates its congestion window when a > CBR > stream (packet size << MSS) is sent over TCP. > > In general, if I am sending 100 packets every second with a packet size > of one byte and assuming each packet is ACKed, then increasing window > by > one every RTT (during congestion avoidance) will artifically inflate > the > window. Thus, the cwnd calculation should not assume that the last > packet > sent contained MSS bytes of data. > > The rfc and the code and seem to imply that cwnd increase is > MSS-based. I > haven't confirmed either way (still testing it) and will like to know: > 1) What is the RFC suggested way? > 2) How Linux 2.6 is implementing it? "Interestingly" might be one way to describe it. IIRC the netdev archives should have details, but Linux 2.6 does ABC, using the byte-based heuristics from the RFC, but then applies it to a packet-based cwnd. It will only increase the cwnd by one packet after an entire MSS has been exchanged, which means if you are sending a stream of sub-MSS packets, it takes rather longer to increase the cwnd than one might normally expect from a packet-counting congestion control mechanism. rick jones Wisdom teeth are impacted, people are affected by the effects of events From Taehyun.Kim at freescale.com Mon Jul 3 08:35:48 2006 From: Taehyun.Kim at freescale.com (Kim Taehyun-R01121) Date: Mon, 3 Jul 2006 08:35:48 -0700 Subject: [e2e] MSS and cwnd increase In-Reply-To: Message-ID: <945AE3A40736D642B6BD3E3BA33CFBFF5B88D9@az33exm23.fsl.freescale.net> I studied a similar problem (video streaming over TCP) to quantify the impact of TCP on the buffering delay. Please refer http://www-static.cc.gatech.edu/~ammar/papers/vcip_final.pdf Tkim > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of > Salman Abdul Baset > Sent: Sunday, July 02, 2006 1:45 AM > To: Joe Touch > Cc: end2end-interest at postel.org > Subject: Re: [e2e] MSS and cwnd increase > > > We want to understand the TCP behavior when it carries > cbr(voice) traffic. You might be aware that Skype is also > sending voice over TCP in certain scenarios. > > Ofcourse, I am not going to suggest that it is a good idea to > do that; rather, we are trying to understand various > circumstances (packet loss, delay) under which a Skype like > application can possibly send voice traffic over TCP without > incurring too much delay and jitter. NAT and firewall > restrictions are examples of settings where an application > may want to send voice over TCP. Again, the purpose is to > understand the effects and this does not imply that we are > recommending this practice. > > regards, > Salman > > > On Sat, 1 Jul 2006, Joe Touch wrote: > > > > > > > Salman Abdul Baset wrote: > > > I am wondering how the Linux 2.6 updates its congestion > window when > > > a CBR stream (packet size << MSS) is sent over TCP. > > > > The better question is why are you sending CBR over TCP? > > > > Joe > > > > > From touch at ISI.EDU Mon Jul 3 09:10:20 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 03 Jul 2006 09:10:20 -0700 Subject: [e2e] MSS and cwnd increase In-Reply-To: References: <44A70A2E.5070206@isi.edu> Message-ID: <44A9416C.1000500@isi.edu> Salman Abdul Baset wrote: > We want to understand the TCP behavior when it carries cbr(voice) traffic. > You might be aware that Skype is also sending voice over TCP in certain > scenarios. > > Ofcourse, I am not going to suggest that it is a good idea to > do that; rather, we are trying to understand various circumstances > (packet loss, delay) under which a Skype like application can possibly > send voice traffic over TCP without incurring too much delay and jitter. > NAT and firewall restrictions are examples of settings where an > application may want to send voice over TCP. Again, the purpose is to > understand the effects and this does not imply that we are recommending this > practice. Sure. It might be useful to compare different implementations of TCP, since those variations may be substantial as well, FWIW. > regards, > Salman > > > On Sat, 1 Jul 2006, Joe Touch wrote: > >> >> Salman Abdul Baset wrote: >>> I am wondering how the Linux 2.6 updates its congestion window when a CBR >>> stream (packet size << MSS) is sent over TCP. >> The better question is why are you sending CBR over TCP? >> >> Joe >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060703/7dd71952/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Thu Jul 6 02:54:03 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 06 Jul 2006 10:54:03 +0100 Subject: [e2e] network coding and spam and anonymous email... Message-ID: so looking at my spamassassing classified mail (quite a large folder as you can imagine) it is becoming increasing plausible that one could _code_ legitiamte messages simply as a set of references to spam - the nice thing about this is that there is so much spam that it acts as fairly uniform random cover traffic (crowds) and the number of spam sources compared to legit current email sources is large and its routing is obfuscated, so you'd get pseudanomity really nicely the details are quite complex, but I am sure that you can work them out. a really neat thing is that we are seeing increasing numbers of apparently meaningful spam and spam with attachments (smap and eggs, spam and chips), so one could even probably send quite complex messages with attachments via the spam-channel... thoughts? -----------------------------> p.s. I have the undoubtworthy honour of having been chosen to chair the OO session of the ACM SIGCOMM Symposium to be held in fabulous Pisa, Italy, this september http://www.acm.org/sigs/sigcomm/sigcomm2006/ I've noticed that it has been increasingly dificult for North American researchers to travel (indeed, they don't even have to go south of the border to hear many people speak Spanish), and even the programme committtee found it easier to meet in the quiet of Seattle rather than hold the PC session during one of the fascinating 11 parallel sessions on photonic wireless switched router XML-based management at IEEE Infocom in Barcelona, Spain, where the spanish is spoken by less people anyhow and you can't get such a good marguerita. So I am looking for two things 1/ people that are going to be in Pisa for the conference, and ae interested in offering OO talks, please contact me - my e-mail address is used by many people I havnt met before, offering interesting items and services, so don't be shy. 2/ As a modest example of an OO talk topic, I have prepared one on the topic dear to my heart we would like to support our impoverished american cousins in their research by giving them an outlet easier to attend in these days of restricted travel budget, hence I would like to seek interest in a SIGCXOMM North American Workshop This would follow hot on the heals of the Latin American workshop, but would not require anyone getting a visa, or even passport, or learning Latin of course. Perhaps this could be useful for FIND projects... thank you for your interest, and, of course, in the words of that fine Californian Governator, "Pasta la vista, baby". ciao Gianni From dpreed at reed.com Thu Jul 6 07:10:57 2006 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Jul 2006 10:10:57 -0400 Subject: [e2e] network coding and spam and anonymous email... In-Reply-To: References: Message-ID: <44AD19F1.5080807@reed.com> The nice thing about this is that the "spam coding dictionary" provides a way to code actual spam in a tiny number of bits, thus completely solving the spam problem. :-) :-) Spammers become like the retired comedians at a Catskills resort who shout out "17" and every other comedian breaks out laughing, until the next one shouts "73". Jon Crowcroft wrote: > so looking at my spamassassing classified mail (quite a large folder > as you can imagine) it is becoming increasing plausible that > one could _code_ legitiamte messages simply as a set of references > to spam - the nice thing about this is that there is so much spam that > it acts as fairly uniform random cover traffic (crowds) and the number > of spam sources compared to legit current email sources is large and > its routing is obfuscated, so you'd get pseudanomity really nicely > > the details are quite complex, but I am sure that you can work them > out. a really neat thing is that we are seeing increasing numbers of > apparently meaningful spam and spam with attachments (smap and eggs, > spam and chips), so one could even probably send quite complex > messages with attachments via the spam-channel... > > thoughts? > > -----------------------------> > > p.s. > > I have the undoubtworthy honour of having been chosen to chair the OO session of > the ACM SIGCOMM Symposium to be held in fabulous Pisa, Italy, this september > http://www.acm.org/sigs/sigcomm/sigcomm2006/ > > I've noticed that it has been increasingly dificult for North American researchers to travel > (indeed, they don't even have to go south of the border to hear many people speak Spanish), and > even the programme committtee found it easier to meet in the quiet of Seattle rather than hold the > PC session during one of the fascinating 11 parallel sessions on > photonic wireless switched router XML-based management at > IEEE Infocom in Barcelona, Spain, where the spanish is spoken by less people anyhow > and you can't get such a good marguerita. > > So I am looking for two things > 1/ people that are going to be in Pisa for the conference, and ae interested in offering OO > talks, please contact me - my e-mail address is used by many people I havnt met before, offering > interesting items and services, so don't be shy. > > 2/ As a modest example of an OO talk topic, I have prepared one on the topic dear to my heart > we would like to support our impoverished american cousins in their research by giving them an outlet > easier to attend in these days of restricted travel budget, hence I would like to seek interest in a SIGCXOMM North American Workshop > This would follow hot on the heals of the Latin American workshop, but would not require anyone getting a visa, or even passport, > or learning Latin of course. Perhaps this could be useful for FIND projects... > > > thank you for your interest, and, of course, in the words of that fine Californian Governator, "Pasta la vista, baby". > > ciao > > Gianni > > > > > From saikat at cs.cornell.edu Thu Jul 6 07:30:07 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Thu, 06 Jul 2006 15:30:07 +0100 Subject: [e2e] network coding and spam and anonymous email... In-Reply-To: References: Message-ID: <1152196207.7931.171.camel@localhost.localdomain> On Thu, 2006-07-06 at 10:54 +0100, Jon Crowcroft wrote: > one could _code_ legitiamte messages simply as a set of references > to spam - the nice thing about this is that there is so much spam that > it acts as fairly uniform random cover traffic Awsome idea -- change the role of spam from background noise to a carrier signal! A first-stab feasibility analysis is promising. Based on my corpus of spam and e2e mails, spam has feature-set (think unique words) of roughly 300K while e2e has only 30K. Unfortunately, they have only 7.5K words in common, so a simple mapping may not be sufficient, but one can easily construct a dictionary that maps the basis-vector for spam onto the basis-vector for e2e. With that mapping, a legitimate email can become a linear-combination of the spam messages. If the mapping is based on the most frequent words, here is what it might look like. For e2e (words in decreasing frequency of use) ----------- 1. tcp (makes sense) 2. but (apparently we disagree a lot) 3. internet 4. there 5. e2e (duh) For spam [*] --------- 1. software (makes sense; targeted spam) 2. please (apparently they are more persuasive) 3. $69.95 4. free 5. viagra (no comment) -- Saikat * it took me a while to cherry-pick my spam corpus for the desired effect -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060706/26a96d82/attachment.bin From aaa at cs.stanford.edu Thu Jul 6 13:06:44 2006 From: aaa at cs.stanford.edu (Amr A. Awadallah) Date: Thu, 06 Jul 2006 13:06:44 -0700 Subject: [e2e] network coding and spam and anonymous email... In-Reply-To: References: Message-ID: <44AD6D54.1090409@cs.stanford.edu> note sure if you are aware of this site, but it lets you encrypt real messages to look like spam: http://www.spammimic.com/index.shtml -- amr >so looking at my spamassassing classified mail (quite a large folder >as you can imagine) it is becoming increasing plausible that >one could _code_ legitiamte messages simply as a set of references >to spam - the nice thing about this is that there is so much spam that >it acts as fairly uniform random cover traffic (crowds) and the number >of spam sources compared to legit current email sources is large and >its routing is obfuscated, so you'd get pseudanomity really nicely > >the details are quite complex, but I am sure that you can work them >out. a really neat thing is that we are seeing increasing numbers of >apparently meaningful spam and spam with attachments (smap and eggs, >spam and chips), so one could even probably send quite complex >messages with attachments via the spam-channel... > >thoughts? > >-----------------------------> > >p.s. > >I have the undoubtworthy honour of having been chosen to chair the OO session of >the ACM SIGCOMM Symposium to be held in fabulous Pisa, Italy, this september >http://www.acm.org/sigs/sigcomm/sigcomm2006/ > >I've noticed that it has been increasingly dificult for North American researchers to travel >(indeed, they don't even have to go south of the border to hear many people speak Spanish), and >even the programme committtee found it easier to meet in the quiet of Seattle rather than hold the >PC session during one of the fascinating 11 parallel sessions on >photonic wireless switched router XML-based management at >IEEE Infocom in Barcelona, Spain, where the spanish is spoken by less people anyhow >and you can't get such a good marguerita. > >So I am looking for two things >1/ people that are going to be in Pisa for the conference, and ae interested in offering OO >talks, please contact me - my e-mail address is used by many people I havnt met before, offering >interesting items and services, so don't be shy. > >2/ As a modest example of an OO talk topic, I have prepared one on the topic dear to my heart >we would like to support our impoverished american cousins in their research by giving them an outlet >easier to attend in these days of restricted travel budget, hence I would like to seek interest in a SIGCXOMM North American Workshop >This would follow hot on the heals of the Latin American workshop, but would not require anyone getting a visa, or even passport, >or learning Latin of course. Perhaps this could be useful for FIND projects... > > >thank you for your interest, and, of course, in the words of that fine Californian Governator, "Pasta la vista, baby". > >ciao > >Gianni > > > > From shemminger at osdl.org Fri Jul 7 21:34:20 2006 From: shemminger at osdl.org (Stephen Hemminger) Date: Fri, 7 Jul 2006 21:34:20 -0700 Subject: [e2e] MSS and cwnd increase In-Reply-To: References: Message-ID: <20060707213420.335831a7@localhost.localdomain> On Sat, 1 Jul 2006 16:22:09 -0400 (EDT) Salman Abdul Baset wrote: > I am wondering how the Linux 2.6 updates its congestion window when a CBR > stream (packet size << MSS) is sent over TCP. > > In general, if I am sending 100 packets every second with a packet size > of one byte and assuming each packet is ACKed, then increasing window by > one every RTT (during congestion avoidance) will artifically inflate the > window. Thus, the cwnd calculation should not assume that the last packet > sent contained MSS bytes of data. > > The rfc and the code and seem to imply that cwnd increase is MSS-based. I > haven't confirmed either way (still testing it) and will like to know: > 1) What is the RFC suggested way? > 2) How Linux 2.6 is implementing it? > > Regards, > Salman There is also a heuristic in Linux that does not increase the cwnd unless congestion window was full (see RFC2861). This prevents the artificial increase that would happen with stream based applications. The code is in 2.4 and 2.6 kernels. -- If one would give me six lines written by the hand of the most honest man, I would find something in them to have him hanged. -- Cardinal Richlieu From houyou at fmi.uni-passau.de Fri Jul 7 08:38:36 2006 From: houyou at fmi.uni-passau.de (Amine M. Houyou) Date: Fri, 07 Jul 2006 17:38:36 +0200 Subject: [e2e] Call for Participation: IWSOS 2006 (EuroNGI IA.8.2), 18-20 Sept., Passau, Germany Message-ID: <44AE7FFC.1010408@fmi.uni-passau.de> Dear Colleagues, CALL FOR PARTICIPATION - IWSOS 2006 **************************************************************** New Trends in EuroNGI Architectures and Services: First International Workshop on Self-Organizing Systems (IWSOS 2006) September 18-20, 2006 University of Passau, Germany http://www.fmi.uni-passau.de/iwsos **************************************************************** /---------------------------------------------\ | EARLY REGISTRATION DEADLINE: AUGUST 1, 2006 | \---------------------------------------------/ http://www.iwsos.net.fmi.uni-passau.de/registration.html Early registration fee is 330 EUR. The participation is free of charge for EuroNGI participants. **************************************************************** For details of the workshop program refer to: http://www.iwsos.net.fmi.uni-passau.de/technical-program.html For other important pending deadlines please refer to: http://www.iwsos.net.fmi.uni-passau.de/home/important-dates.html **************************************************************** We are looking forward to your presence in our beautiful city. Apologies for the multiple copies. Best regards, Amine Houyou Patrick Wuechner Hermann de Meer -- MEng. EE. Amine M. Houyou Chair for Computer Communications and Networks - Prof. De Meer - Faculty for Computer Science and Mathematics University of Passau Innstr. 43 D-94032 Passau Germany http://www.net.fmi.uni-passau.de From bkarp at cs.ucl.ac.uk Tue Jul 11 10:09:46 2006 From: bkarp at cs.ucl.ac.uk (Brad Karp) Date: Tue, 11 Jul 2006 18:09:46 +0100 Subject: [e2e] ACM SIGCOMM 2006 Call for Participation / Early Registration Deadline Message-ID: <20060711170946.GC52010@boffin.cs.ucl.ac.uk> Call for Participation ACM SIGCOMM 2006 Conference Monday - Friday, September 11th-15th, 2006 Pisa, Italy http://www.acm.org/sigs/sigcomm/sigcomm2006/ EARLY REGISTRATION DEADLINE: August 1st Main conference: September 12th-14th Workshops: September 11th and 15th Tutorial: September 11th The conference organizers cordially invite you to attend ACM SIGCOMM 2006, the annual flagship conference of the Special Interest Group on Data Communication (SIGCOMM). As in recent years, the three-day main conference will be accompanied by two days devoted to workshops and a tutorial on related topics: WORKSHOPS - Workshop on Challenged Networks, CHANTS 2006 - Workshop on Internet Network Management, INM 2006 - Workshop on Large-Scale Attack Defense, LSAD 2006 - Workshop on Mining Network Data, MineNet 2006 TUTORIAL - Wireless Mesh Networks: From Theory to Deployed Systems Victor Bahl, Microsoft Research CONFERENCE REGISTRATION NOW AVAILABLE ONLINE http://www.acm.org/sigs/sigcomm/sigcomm2006/?registrations You may now register online for SIGCOMM 2006 and the associated workshops and tutorial; the registration web site accepts payment by credit card over SSL. Early (discounted) registration continues through August 1st. HOTEL INFORMATION NOW AVAILABLE ONLINE: RESERVE EARLY! http://www.acm.org/sigs/sigcomm/sigcomm2006/?hotels Attendees are urged to reserve hotel rooms as early as possible, as two other conferences will take place concurrently with SIGCOMM in Pisa, and hotel rooms in the most convenient locations are likely to sell out early. SIGCOMM AWARD WINNER The main conference will open with an address by Domenico Ferrari, the 2006 winner of the ACM SIGCOMM Award for lifetime contribution to the field of computer communications. CONFERNCE TECHNICAL PROGRAM The single-track program consists of 37 papers representing the best recent results in networking research. The advance program is now available online at: http://sigcomm06.stanford.edu/discussion/ There will also be a poster session, where researchers present work in progress, and an outrageous opinions session, during which attendees compete to offer the most comically unorthodox views in networking research. We look forward to seeing you in Pisa from the 11th to the 15th of September! Best, for the SIGCOMM 2006 Organizing Committee, Brad Karp From xwy at ics.uci.edu Mon Jul 10 15:24:44 2006 From: xwy at ics.uci.edu (Xiaowei Yang) Date: Mon, 10 Jul 2006 15:24:44 -0700 Subject: [e2e] CFP: HotNets-V -- ACM Workshop on Hot Topics in Networks Message-ID: <87hd1p85eb.wl%xwy@ics.uci.edu> Call for papers HotNets-V: Fifth Workshop on Hot Topics in Networks Irvine, California, USA November 29-30, 2006 Submission deadline: Friday, 11 August 2006 (11:59pm Pacific Daylight Time) URL: http://www.acm.org/sigs/sigcomm/HotNets-V/ The Fifth Workshop on Hot Topics in Networks, HotNets-V, will bring together researchers in the networking systems community to engage in lively discussion of future trends in networking research and technology. The workshop will provide a venue for researchers to present and discuss ideas that have the potential to significantly impact the community in the long term; its goal is to promote community-wide discussions of those ideas. Each potential participant should submit a short position paper describing such an idea. The paper could, for example, expose a new problem, advocate a new solution, or re-frame or debunk existing work. We encourage submissions of early work, with novel and interesting ideas, across the broad range of networking systems research. Work introduced at HotNets-V, once fully thought through, completed, and written up in a finished form, may be relevant to conferences such as SIGCOMM, NSDI, SOSP, OSDI, SenSys, or MobiCom, or may have not yet found a home in the current spectrum of networking systems conferences. Topics of interest include, but are by no means limited to: * Hardware and operating system structure for robust networking and resistance to attack * Alternatives to traditional, point-to-point, packet-oriented transport protocols * Systems dependent on network measurement: How much does measurement help? How precise must measurement be? * User-initiated, decentralized secure network clusters * New network architectures, relevant -- or not * Death and life of the end-to-end argument * Decentralization versus centralization: the pendulum swings? * Overlay, peer-to-peer, and programmable network infrastructures * Sensor networks, storage area networks, and other examples of "extreme" networking * Internet-scale systems: are they really similar to parallel systems? * Improving the programmability and availability of networked systems * Wireless networks, mobility, and pervasive computing * Network failures, vulnerabilities, and exploits: detection, analysis and defenses * Network management and control * Novel distributed applications and services, including systems for content distribution and real-time media * Economics of networked infrastructure * Lessons drawn from failed research, and controversial or disruptive topics Position papers will be selected based on originality, technical merit, and the likelihood that their authors' presentations and interventions will lead to insightful technical discussions at the workshop. Online copies of accepted position papers will be made publicly available via the Web prior to the workshop, and printed proceedings will be published. Additionally, a workshop summary will be published in ACM SIGCOMM's Computer Communication Review (CCR), widely disseminating the ideas discussed at the workshop. Attendance will be limited to around 60 people in order to ensure an interactive workshop atmosphere. Invitations to attend the workshop will be extended according to the following priorities: * the Program and Steering Committees, and one author per paper * co-authors of accepted and submitted papers, preferring students as available scholarships allow * event sponsor representatives and additional authors of submitted papers at the discretion of the Program Chairs Hotnets-V is sponsored by ACM SIGCOMM. Submission Instructions Submitted papers must be no longer than 6 pages (10 point font, 1 inch margins). Authors may choose to submit a blind or non-blind paper. A blind submission will not indicate the names or affiliations of the authors in the paper; a non-blind submission will include the names and affiliations of each author on the first page of the paper. Only electronic submissions in PostScript or PDF will be accepted. Submissions must be written in English, render without error using standard tools (Ghostview or Acrobat Reader), and print on US-Letter sized paper. HotNets-V reviews will follow standard academic practice, although some rejected papers may not receive full-length reviews. Submission information will be posted at http://www.acm.org/sigcomm/HotNets-V. Important Dates: Submissions due: Friday, 11 August 2006 (11:59pm Pacific Daylight Time) No extensions will be granted. Notification of acceptance: Monday, 16 October 2006 Camera-ready copy due: Wednesday, 8 November 2006 Workshop: Wednesday-Thursday, 29-30 November 2006 Beckman Center, Irvine, California Organizers: General Chair: Xiaowei Yang, UC Irvine Program Committee: Frank Dabek, Google Cristian Estan, University of Wisconsin Anja Feldmann, TU M?nchen Rebecca Isaacs, Microsoft Research Eddie Kohler, UCLA (Co-chair) Ratul Mahajan, Microsoft Research Greg Minshall, unaffiliated (Co-chair) Vivek Pai, Princeton Vern Paxson, ICSI/LBNL Sylvia Ratnasamy, Intel Research From ramu20 at gmail.com Fri Jul 14 03:46:12 2006 From: ramu20 at gmail.com (ramu yerukala) Date: Fri, 14 Jul 2006 16:16:12 +0530 Subject: [e2e] statistics perpose Message-ID: Dear sir, I need any statistical data for my analysation if you have that type of data please send me. thanking you. On 7/10/06, end2end-interest-request at postel.org < end2end-interest-request at postel.org> wrote: > > Send end2end-interest mailing list submissions to > end2end-interest at postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.postel.org/mailman/listinfo/end2end-interest > or, via email, send a message with subject or body 'help' to > end2end-interest-request at postel.org > > You can reach the person managing the list at > end2end-interest-owner at 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. Call for Participation: IWSOS 2006 (EuroNGI IA.8.2), 18-20 > Sept., Passau, Germany (Amine M. Houyou) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 07 Jul 2006 17:38:36 +0200 > From: "Amine M. Houyou" > Subject: [e2e] Call for Participation: IWSOS 2006 (EuroNGI IA.8.2), > 18-20 Sept., Passau, Germany > To: end2end-interest at postel.org > Message-ID: <44AE7FFC.1010408 at fmi.uni-passau.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Dear Colleagues, > > > CALL FOR PARTICIPATION - IWSOS 2006 > > **************************************************************** > > New Trends in EuroNGI Architectures and Services: > First International Workshop on Self-Organizing Systems > (IWSOS 2006) > September 18-20, 2006 > University of Passau, Germany > http://www.fmi.uni-passau.de/iwsos > > **************************************************************** > > /---------------------------------------------\ > | EARLY REGISTRATION DEADLINE: AUGUST 1, 2006 | > \---------------------------------------------/ > > http://www.iwsos.net.fmi.uni-passau.de/registration.html > > Early registration fee is 330 EUR. > The participation is free of charge for EuroNGI participants. > > **************************************************************** > > For details of the workshop program refer to: > http://www.iwsos.net.fmi.uni-passau.de/technical-program.html > > For other important pending deadlines please refer to: > http://www.iwsos.net.fmi.uni-passau.de/home/important-dates.html > > **************************************************************** > > We are looking forward to your presence in our beautiful city. > > Apologies for the multiple copies. > > Best regards, > > Amine Houyou > Patrick Wuechner > Hermann de Meer > > > -- > MEng. EE. Amine M. Houyou > Chair for Computer Communications and Networks - Prof. De Meer - Faculty > for Computer Science and Mathematics > University of Passau > Innstr. 43 > D-94032 Passau > Germany > http://www.net.fmi.uni-passau.de > > > > > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 29, Issue 6 > *********************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060714/4523bd90/attachment.html From mascolo at poliba.it Tue Jul 18 04:46:01 2006 From: mascolo at poliba.it (Saverio Mascolo) Date: Tue, 18 Jul 2006 13:46:01 +0200 Subject: [e2e] TCP Westwood+ linux 2.16.18 kernel implementation Message-ID: <001a01c6aa5f$c3d2b960$723bccc1@HPSM> We have updated the TCP Westwood+ linux kernel implementation with the two following changes: o RTT_min is updated each time a timeout event occurs (in order to cope with hard handovers in wireless scenarios) o The bandwidth estimate filter is now initialized with the first bandwidth sample in order to have better performances in the case of small file transfers. The patch has been applied to the mainstream kernel and it will be available for kernels >= 2.6.18. The patch is available at: http://c3lab.poliba.it/index.php/Westwood:Experimental where you can also find a patch to Web100 (http://www.web100.org) in order to enable the logging of the "end to end bandwidth estimate" variable used by westwood+. I remember for sake of completeness that the only diffrence between westwood and westwood+ is the "bandwidth estimate" algorithm that in westwood+ provides a measure of used bandwdith that is not aliased. best, saverio mascolo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060718/33cf5cb2/attachment.html From salman at cs.columbia.edu Fri Jul 21 22:48:07 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Sat, 22 Jul 2006 01:48:07 -0400 (EDT) Subject: [e2e] TCP and Implementation Related Questions Message-ID: 1) I want to confirm if Windows XP implements: a) RFC 2581 TCP Congestion Window (probably) b) RFC 2861 TCP Congestion Window Validation (not sure) c) RFC 3465 Appropriate Byte Counting (probably not) Does anyone know if they will be supported in Windows Vista? 2) RFC 2861 specified two key points a) Congestion window should be reduced after a idle period. b) Congestion window should not be increased more than the application rate if application is rate-limited or, saying it differently, cwnd should not be increased if current cwnd was not fully utilized. This is an experimental RFC. Are there any updates to this? Is it recommended that all implementations should support it? 3) If an implementation only follows RFC 2581, then even for a rate-limited application, the cwnd will keep increasing, beyond the rate at which application is sending data. There are some interesting effects of this phenomena for CBR traffic. To check that, RFC 2861 proposed to limit cwnd increase if the cwnd was not fully utilized. 4) Does ns2 implement RFC 2861? I don't think so because if I rate limit the application (use CBR over TCP), cwnd keeps increasing beyond the application rate. 5) Finally, does anyone know how to get the cwnd variable in Windows? I don't think this is possible using getsockopt() (Linux, TCP_INFO) but have not been able to confirm the non-existence of such a method. Regards, Salman From salman at cs.columbia.edu Sat Jul 22 11:02:43 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Sat, 22 Jul 2006 14:02:43 -0400 (EDT) Subject: [e2e] rfc2581bis-01 and RFC 2861 Message-ID: (Note: This post is being sent to tcpm and end2end-interest mailing lists) The issue is that RFC 2861 (Experimental) suggests to cap cwnd if application is rate limited. For example, for sending CBR over TCP with RTT of 100ms and CBR rate of 10ms, the cwnd should not theoretically increase beyond 11. The latest TCP congestion control draft: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-01.txt does not allude to RFC 2861. This latest draft perhaps tries to combine the RFC 2581 (TCP Congestion Control) and RFC 3465 (Appropriate Byte Couting) in one document. In $3.1, (page 5, par 5) it suggests: "The RECOMMENDED way to increase cwnd during congestion avoidance is to count the number of bytes that have been acknowledged by ACKs for new data. (A drawback of this implementation is that it requires maintaining an additional state variable.) When the number of bytes acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS bytes. Note that during congestion avoidance, cwnd MUST NOT be increased by more than SMSS bytes per RTT. This method both allows TCPs to increase cwnd by one segment per RTT in the face of delayed ACKs and provides robustness against ACK Division attacks." It clearly states that cwnd should be increased if number of bytes in current cwnd have been acknowledged. This implies that cwnd increase will also happen for CBR traffic, albeit at a slower rate because of application rate limitation. I am not sure if it is an intentional omission by the authors but this seems to have significant implications for sending CBR over TCP. For example, delays incurred by CBR stream can be quite different because of cwnd limitation (due to application rate). Regards, Salman From michael.welzl at uibk.ac.at Sun Jul 23 23:05:25 2006 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: 24 Jul 2006 08:05:25 +0200 Subject: [e2e] TCP and Implementation Related Questions In-Reply-To: References: Message-ID: <1153721125.4764.12.camel@lap10-c703.uibk.ac.at> > 3) If an implementation only follows RFC 2581, then even for a > rate-limited application, the cwnd will keep increasing, beyond the rate > at which application is sending data. There are some interesting effects > of this phenomena for CBR traffic. To check that, RFC 2861 proposed to > limit cwnd increase if the cwnd was not fully utilized. I don't think so; as far as I know, this is why the term "FlightSize" was introduced - the calculations are not just based on the previous value of cwnd, but the actual number of bytes in flight. > 4) Does ns2 implement RFC 2861? I don't think so because if I rate limit > the application (use CBR over TCP), cwnd keeps increasing beyond the > application rate. Because we have the "Flightsize" term, with or without RFC 2861, that shouldn't happen. Cheers, Michael From L.Wood at surrey.ac.uk Mon Jul 24 11:10:50 2006 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Mon, 24 Jul 2006 19:10:50 +0100 Subject: [e2e] TCP and Implementation Related Questions In-Reply-To: References: Message-ID: <7.0.1.0.0.20060724190432.075ff7b8@surrey.ac.uk> For an overview of Vista TCP features (and testing against Windows Server 2003 for a geo satellite delay environment -- they didn't test against anything else...), see slides and video at http://www.iet.tv/ 26 Jun 2006 Technology - Communications IP over Satcom for Military Users David Race and Paul Thomas Event: Military SatComs 2006 (search on Microsoft) This describes Microsoft's "Compound TCP" implementation. They made a big deal about having a 64K window improving the Vista stack performance in that environment, as if that wasn't the obvious thing to do with a 16-bit pointer on a machine with a gig of memory. See also A Compound TCP Approach for High-speed and Long Distance Networks Technical paper on an experimental variant of TCP optimised for high-speed, long-distance networks. research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=940 Compound TCP: A Scalable and TCP-Friendly Congestion Control for High Speed Networks http://www.hpcc.jp/pfldnet2006/paper/s4_01.pdf http://www.hpcc.jp/pfldnet2006/slides/s4_01.pdf I expect from this that Microsoft's cwnd implementation will be somewhat outside RFC specs - more aggressive? Can't find any internet drafts describing it either; it seems they've not bothered with the IETF. (Does the IETF still do bakeoffs, anyway?) I believe that as TCP is an ever-decreasing amount of internet traffic, non-RFC changes to deployed congestion control really don't matter as a threat to The State of Internet Congestion That Must Be Preserved At All Costs and the Illusion that TCP Friendliness Matters. But as an endhost upgrade, Windows Vista deployment will have a significant effect on network performance for its userbase. L. hey, faster spam from 0wnd machines! At Saturday 22/07/2006 01:48 -0400, Salman Abdul Baset wrote: >1) I want to confirm if Windows XP implements: > a) RFC 2581 TCP Congestion Window (probably) > b) RFC 2861 TCP Congestion Window Validation (not sure) > c) RFC 3465 Appropriate Byte Counting (probably not) > >Does anyone know if they will be supported in Windows Vista? > >2) RFC 2861 specified two key points > a) Congestion window should be reduced after a idle period. > b) Congestion window should not be increased more than the application > rate if application is rate-limited or, saying it differently, cwnd > should not be increased if current cwnd was not fully utilized. > > This is an experimental RFC. Are there any updates to this? Is it > recommended that all implementations should support it? > >3) If an implementation only follows RFC 2581, then even for a >rate-limited application, the cwnd will keep increasing, beyond the rate >at which application is sending data. There are some interesting effects >of this phenomena for CBR traffic. To check that, RFC 2861 proposed to >limit cwnd increase if the cwnd was not fully utilized. > >4) Does ns2 implement RFC 2861? I don't think so because if I rate limit >the application (use CBR over TCP), cwnd keeps increasing beyond the >application rate. > >5) Finally, does anyone know how to get the cwnd variable in Windows? I >don't think this is possible using getsockopt() (Linux, TCP_INFO) but have >not been able to confirm the non-existence of such a method. > >Regards, >Salman From jsj at ieee.org Tue Jul 25 19:28:10 2006 From: jsj at ieee.org (Scott Johnson) Date: Tue, 25 Jul 2006 22:28:10 -0400 Subject: [e2e] TCP and Implementation Related Questions In-Reply-To: <7.0.1.0.0.20060724190432.075ff7b8@surrey.ac.uk> References: <7.0.1.0.0.20060724190432.075ff7b8@surrey.ac.uk> Message-ID: <44C6D33A.5000405@ieee.org> A reasonably detailed explanation of MS' Server 2003 stack is here: http://www.microsoft.com/downloads/details.aspx?FamilyID=06c60bfe-4d37-4f50-8587-8b68d32fa6ee&displaylang=en This is in Word format. It is also available online (readable in a browser). Based on Lloyd Wood's IET link, I believe the server 2003 implementation will be employed inVista too. Regards, Scott Johnson Lloyd Wood wrote: > For an overview of Vista TCP features (and testing against Windows > Server 2003 for a geo satellite delay environment -- they didn't test > against anything else...), see slides and video at > http://www.iet.tv/ > > 26 Jun 2006 Technology - Communications > IP over Satcom for Military Users > David Race and Paul Thomas > Event: Military SatComs 2006 > (search on Microsoft) > > This describes Microsoft's "Compound TCP" implementation. They made a > big deal about having a 64K window improving the Vista stack > performance in that environment, as if that wasn't the obvious thing > to do with a 16-bit pointer on a machine with a gig of memory. See also > > A Compound TCP Approach for High-speed and Long Distance Networks > Technical paper on an experimental variant of TCP optimised for > high-speed, long-distance networks. > research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=940 > > > Compound TCP: A Scalable and TCP-Friendly Congestion Control for High > Speed Networks > http://www.hpcc.jp/pfldnet2006/paper/s4_01.pdf > > http://www.hpcc.jp/pfldnet2006/slides/s4_01.pdf > > I expect from this that Microsoft's cwnd implementation will be > somewhat outside RFC specs - more aggressive? Can't find any internet > drafts describing it either; it seems they've not bothered with the > IETF. (Does the IETF still do bakeoffs, anyway?) > > I believe that as TCP is an ever-decreasing amount of internet > traffic, non-RFC changes to deployed congestion control really don't > matter as a threat to The State of Internet Congestion That Must Be > Preserved At All Costs and the Illusion that TCP Friendliness Matters. > But as an endhost upgrade, Windows Vista deployment will have a > significant effect on network performance for its userbase. > > L. > > hey, faster spam from 0wnd machines! > > At Saturday 22/07/2006 01:48 -0400, Salman Abdul Baset wrote: > >> 1) I want to confirm if Windows XP implements: >> a) RFC 2581 TCP Congestion Window (probably) >> b) RFC 2861 TCP Congestion Window Validation (not sure) >> c) RFC 3465 Appropriate Byte Counting (probably not) >> >> Does anyone know if they will be supported in Windows Vista? >> >> 2) RFC 2861 specified two key points >> a) Congestion window should be reduced after a idle period. >> b) Congestion window should not be increased more than the application >> rate if application is rate-limited or, saying it differently, cwnd >> should not be increased if current cwnd was not fully utilized. >> >> This is an experimental RFC. Are there any updates to this? Is it >> recommended that all implementations should support it? >> >> 3) If an implementation only follows RFC 2581, then even for a >> rate-limited application, the cwnd will keep increasing, beyond the rate >> at which application is sending data. There are some interesting effects >> of this phenomena for CBR traffic. To check that, RFC 2861 proposed to >> limit cwnd increase if the cwnd was not fully utilized. >> >> 4) Does ns2 implement RFC 2861? I don't think so because if I rate limit >> the application (use CBR over TCP), cwnd keeps increasing beyond the >> application rate. >> >> 5) Finally, does anyone know how to get the cwnd variable in Windows? I >> don't think this is possible using getsockopt() (Linux, TCP_INFO) but >> have >> not been able to confirm the non-existence of such a method. >> >> Regards, >> Salman > > -- Regards, Scott Johnson jsj at ieee.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060725/7792b024/attachment.html From mathis at psc.edu Wed Jul 26 13:57:30 2006 From: mathis at psc.edu (Matt Mathis) Date: Wed, 26 Jul 2006 16:57:30 -0400 (EDT) Subject: [e2e] Default maximum receiver window In-Reply-To: <7.0.1.0.0.20060724190432.075ff7b8@surrey.ac.uk> References: <7.0.1.0.0.20060724190432.075ff7b8@surrey.ac.uk> Message-ID: On Mon, 24 Jul 2006, Lloyd Wood wrote: > .... They made a > big deal about having a 64K window improving the Vista stack > performance in that environment, as if that wasn't the obvious thing > to do with a 16-bit pointer on a machine with a gig of memory. BTW: Linux 2.6.17 now has sender and receiver side autotuning and a 4 MB DEFAULT maximum window size. Yes, by default it negotiates a TCP window scale of 7. 4 MB is sufficient to support about 100 Mb/s on a 300 ms path or 1 Gb/s on a 30 ms path, assuming you have enough data and an extremely clean (loss-less) network. We live in interesting times.... --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.