From detlef.bosau at web.de Thu Sep 1 05:04:47 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 01 Sep 2005 14:04:47 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited References: <430E1862.23935C68@web.de> Message-ID: <4316EE5F.7060203@web.de> I've learned some interesting thins on this matter in some offline discussions. In consequence, I know less then ever, but that's life.... Basically, I?ve learned that loss detection via RTO should only be the last ressort. Actually, loss detection should be done mostly by the observation of ACKs, particularly SACK. Marc Allman refered rfcs 3517 and 3782. In consequence, RTO estimators are not that important for the performance of TCP. They must be large enough to avoid too many spurious timeouts. If they are a little bit too large, it's at least not disastrous. They are only a last resort, if anything else fails. The "spurious timeout" problem often claimed in mobile wireless networks thus should be basically a problem with extreme delay spikes. As to my understanding, we can exclude other problems, the only problem with TCP in mobile wireless networks are unexpected, or unforeseeable respectively, delay spikes or a sudden increase of delays. This can be due to - scheduling (voice is priorized over data) - route change (I don?t know whether this is that important, because much of this is micromobility) - changes in physical path properties. -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Thu Sep 1 05:05:19 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 01 Sep 2005 14:05:19 +0200 Subject: [e2e] Summary. Re: Retransmission Timouts revisited References: <430E1862.23935C68@web.de> Message-ID: <4316EE7F.8060700@web.de> I've learned some interesting thins on this matter in some offline discussions. In consequence, I know less then ever, but that's life.... Basically, I?ve learned that loss detection via RTO should only be the last ressort. Actually, loss detection should be done mostly by the observation of ACKs, particularly SACK. Marc Allman refered rfcs 3517 and 3782. In consequence, RTO estimators are not that important for the performance of TCP. They must be large enough to avoid too many spurious timeouts. If they are a little bit too large, it's at least not disastrous. They are only a last resort, if anything else fails. However, I have some few questions left. 1.: I?ve read a huge number of papers concerned about spurious timeouts in mobile wireless networks, e.g. GPRS. What is the reason for this? Hier kommen jetzt Delay Spikes rein. Die Frage ist, ob wir Delay Spikes abfangen m?ssen und wie wir das k?nnen. Hier kann auch PTE sehr gut helfen. Hier reichen ganz einfache Tiefpa?filter. 2.: -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Thu Sep 1 06:46:10 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 01 Sep 2005 15:46:10 +0200 Subject: [e2e] Message <4316EE7F.8060700@web.de>: Please ignore. References: <430E1862.23935C68@web.de> <4316EE7F.8060700@web.de> Message-ID: <43170622.4BE6832B@web.de> Message <4316EE7F.8060700 at web.de> went out here by mistake. I apologize for the inconvenience. -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From francesco at net.infocom.uniroma1.it Thu Sep 1 06:58:06 2005 From: francesco at net.infocom.uniroma1.it (Francesco Vacirca) Date: Thu, 01 Sep 2005 15:58:06 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <4316EE5F.7060203@web.de> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> Message-ID: <431708EE.8070807@net.infocom.uniroma1.it> > The "spurious timeout" problem often claimed in mobile wireless networks > thus should be basically a problem with extreme delay spikes. This is correct: delay spikes that are not "seen" in the first and second order moments of rtt distributions and that are used for the RTO setting. > > As to my understanding, we can exclude other problems, the only problem > with TCP in mobile wireless networks are unexpected, or unforeseeable > respectively, delay spikes or a sudden increase of delays. Well, packet losses are the main problem... and they should be hidden to TCP with wireless link layer protocol and persistant retransmissions... Spurious timeouts are a second (marginal) problem that in my opinion (and in my research) are not frequent events in a well engineered GPRS/UMTS network. Francesco > > This can be due to > - scheduling (voice is priorized over data) > - route change (I don?t know whether this is that important, because > much of this is micromobility) > - changes in physical path properties. > From weddy at grc.nasa.gov Thu Sep 1 07:30:37 2005 From: weddy at grc.nasa.gov (Wesley Eddy) Date: Thu, 1 Sep 2005 10:30:37 -0400 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <431708EE.8070807@net.infocom.uniroma1.it> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> Message-ID: <20050901143037.GA12130@grc.nasa.gov> On Thu, Sep 01, 2005 at 03:58:06PM +0200, Francesco Vacirca wrote: > > Spurious timeouts are a second (marginal) problem that in my opinion > (and in my research) are not frequent events in a well engineered > GPRS/UMTS network. > Just curious ... Does this definition of "well-designed" include those networks run by major service providers? I've witnessed a few timeouts due not to loss in the data path, but delay of either data or acks (TCP Timestamp or DSACK options make it clear that loss is not the problem), over one provider's North American CDMA 2000 network. I presume that those delay spikes were contributed to by exactly the ARQ persistence you advocate, among other factors. In my (subjective) real world experience, data loss on this particular network is pretty rare, and timeouts are common enough that you see 3 or 4 of them doing normal things like web-surfing, fetchmail, and ssh over the course of an hour. I use such a link frequently and have several traces and other measurements (circa Spring 2004) that support this. -Wes -- Wesley M. Eddy Verizon FNS / NASA GRC http://roland.grc.nasa.gov/~weddy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050901/4264975a/attachment.bin From francesco at net.infocom.uniroma1.it Thu Sep 1 08:01:15 2005 From: francesco at net.infocom.uniroma1.it (Francesco Vacirca) Date: Thu, 01 Sep 2005 17:01:15 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <20050901143037.GA12130@grc.nasa.gov> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <20050901143037.GA12130@grc.nasa.gov> Message-ID: <431717BB.1090309@net.infocom.uniroma1.it> Wesley Eddy wrote: > On Thu, Sep 01, 2005 at 03:58:06PM +0200, Francesco Vacirca wrote: > >>Spurious timeouts are a second (marginal) problem that in my opinion >>(and in my research) are not frequent events in a well engineered >>GPRS/UMTS network. >> > > Just curious ... Does this definition of "well-designed" include those > networks run by major service providers? Well-designed is the wrong definition... I can just say that in the GPRS/UMTS network I analyzed spurious timeouts were a quite rare events with respect to "normal" timeouts and fast retransmit events. I've witnessed a few timeouts > due not to loss in the data path, but delay of either data or acks (TCP > Timestamp or DSACK options make it clear that loss is not the problem), > over one provider's North American CDMA 2000 network. I presume that > those delay spikes were contributed to by exactly the ARQ persistence > you advocate, among other factors. Loss is not the problem IF (and only if) you do not have many losses... and possibly you do not have losses on the wireless channel but just due to congestion. Of course ARQ persistancy can lead to spurious timeout... but I believe that it is better a spurious timeout that a "normal" timeout with packet losses Do you believe that if you are not persistant in retransmission the next packet can arrive without timeout expiration? In my (subjective) real world > experience, data loss on this particular network is pretty rare, and > timeouts are common enough that you see 3 or 4 of them doing normal > things like web-surfing, fetchmail, and ssh over the course of an hour. > I use such a link frequently and have several traces and other > measurements (circa Spring 2004) that support this. This is different from my experience ;-) maybe this is due to the fact that different 3G networks have different terminal population (mobile terminal and data cards) with different TCP implementations. Francesco > > -Wes > From weddy at grc.nasa.gov Thu Sep 1 08:05:13 2005 From: weddy at grc.nasa.gov (Wesley Eddy) Date: Thu, 1 Sep 2005 11:05:13 -0400 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <431717BB.1090309@net.infocom.uniroma1.it> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <20050901143037.GA12130@grc.nasa.gov> <431717BB.1090309@net.infocom.uniroma1.it> Message-ID: <20050901150512.GB12130@grc.nasa.gov> On Thu, Sep 01, 2005 at 05:01:15PM +0200, Francesco Vacirca wrote: > > maybe this is due to the fact that different 3G networks have different > terminal population (mobile terminal and data cards) with different TCP > implementations. > I think this is probably the case. The differences in observation are probably due much more to the network's configuration than the TCP implementation. Whether the user is stationary or mobile between towers also makes a big difference in what kinds of problems are prevalent. -Wes -- Wesley M. Eddy Verizon FNS / NASA GRC http://roland.grc.nasa.gov/~weddy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050901/b7464099/attachment.bin From francesco at net.infocom.uniroma1.it Thu Sep 1 08:36:16 2005 From: francesco at net.infocom.uniroma1.it (Francesco Vacirca) Date: Thu, 01 Sep 2005 17:36:16 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <20050901150512.GB12130@grc.nasa.gov> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <20050901143037.GA12130@grc.nasa.gov> <431717BB.1090309@net.infocom.uniroma1.it> <20050901150512.GB12130@grc.nasa.gov> Message-ID: <43171FF0.5030304@net.infocom.uniroma1.it> I agree... also the spurious timeout estimation method can influence the results... How did you estimate that? Francesco Wesley Eddy wrote: > On Thu, Sep 01, 2005 at 05:01:15PM +0200, Francesco Vacirca wrote: > >>maybe this is due to the fact that different 3G networks have different >>terminal population (mobile terminal and data cards) with different TCP >>implementations. >> > > > I think this is probably the case. The differences in observation are > probably due much more to the network's configuration than the TCP > implementation. Whether the user is stationary or mobile between towers > also makes a big difference in what kinds of problems are prevalent. > > -Wes > From detlef.bosau at web.de Thu Sep 1 10:07:25 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 01 Sep 2005 19:07:25 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <20050901143037.GA12130@grc.nasa.gov> <431717BB.1090309@net.infocom.uniroma1.it> Message-ID: <4317354D.4040002@web.de> Francesco Vacirca wrote: > > Well-designed is the wrong definition... I can just say that in the > GPRS/UMTS network I analyzed spurious timeouts were a quite rare events > with respect to "normal" timeouts and fast retransmit events. > > I've witnessed a few timeouts The question is: What is "few"? In addition: Are these timeouts due to "real" delay spikes? Or due to normal delay variation? From what I?ve learned recently, we could use k=4 in RTO=E+k*V as it is proposed in a revised version of the congavoid paper. Perhaps, we could even use k=8. However, we can make RTO sufficiently large to cope with "normal fluctuations". My basic question is: Are these timeouts due to the TCP implementations in use? Or due to unforseeable spikes? In case of the latter: How often does this happen? Is it an "issue", i.e. it happens three or four times a minute? Or is it neglectible, e.g. it happens two or three times a year? > >> due not to loss in the data path, but delay of either data or acks (TCP >> Timestamp or DSACK options make it clear that loss is not the problem), >> over one provider's North American CDMA 2000 network. I presume that >> those delay spikes were contributed to by exactly the ARQ persistence >> you advocate, among other factors. > The more I think about our actual discussion, the more I dont expect spurious timeouts as a result only from ARQ that often. Perhaps, a great deal of ARQ caused latency variation can be covered by a sufficiently large choice of K. I don?t know. At this point, I think there is no alternative to real traces which reflect observed latencies in different scenarios. Anyhing else would result in speculation. > > Loss is not the problem IF (and only if) you do not have many losses... > and possibly you do not have losses on the wireless channel but just due > to congestion. Personally I make a strong difference between 802.11 networks and mobile wireless networks like GPRS or UMTS. From what I have read in many manuals for WLAN and from what I have seen in practical experience, loss is no issue there. If your run those networks properly (and placing sender and receiver on two sides of a wall from reinforced concrete does surely not mean to run the network properly), you can reach corruption rates as seen in Ethernet. In mobile wireless networks, the situation is different for two reasons. 1. The physical properties of a path are often beyound the user?s control. If a user stays outside, he hardly can influence the weather. A user has limited influence on the traffic, think of multiplath shading due to reflection at vehicles, etc. 2. Typically, mobile wireless networks are used for line switching, best effort packet switching, QoS packet switching in parallel. So, in some situation a packet must be postponed becuase a time slot or a packet is reserved for traffic with higher priority. I did not mention roaming here. I?m using a mobile phone for about 10 years now. And sometimes I must have roamed among differenct cells while I was talking to somebody with my cell phone for sure. Honestly: I did not notice that. And when I don?t notice roaming in a speech flow, it?s somewhat hard to make me believe that micromobility is really an issue ;-) This is admittedly no strong scientific argument. > > Of course ARQ persistancy can lead to spurious timeout... but I believe > that it is better a spurious timeout that a "normal" timeout with packet > losses > Do you believe that if you are not persistant in retransmission the next > packet can arrive without timeout expiration? I?m not quite sure whether I got you correctly. What exactly do you mean by ARQ persistancy? Do you mean a "stop'n wail" scheme, i.e. you send one packet as long until it is successfuly delivered, than the next one? I.e. you inhibit packet reordering? From what I?ve leardn from the RFCs, Mark Allman pointed me at, some degree of packet reordering should not really result in a problem. > > In my (subjective) real world > >> experience, data loss on this particular network is pretty rare, and >> timeouts are common enough that you see 3 or 4 of them doing normal >> things like web-surfing, fetchmail, and ssh over the course of an hour. Sounds af if theres not really something to worry about. >> I use such a link frequently and have several traces and other >> measurements (circa Spring 2004) that support this. > > > This is different from my experience ;-) > maybe this is due to the fact that different 3G networks have different > terminal population (mobile terminal and data cards) with different TCP > implementations. > And that?s why I said that real traces are helpful here. At least with respect to the different degree of mobility, different locations etc. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From fla at inescporto.pt Fri Sep 2 07:04:07 2005 From: fla at inescporto.pt (Filipe Abrantes) Date: Fri, 02 Sep 2005 15:04:07 +0100 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <431708EE.8070807@net.infocom.uniroma1.it> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> Message-ID: <43185BD7.2090402@inescporto.pt> Hi Francesco, Francesco Vacirca wrote: >> The "spurious timeout" problem often claimed in mobile wireless >> networks thus should be basically a problem with extreme delay spikes. > > > This is correct: delay spikes that are not "seen" in the first and > second order moments of rtt distributions and that are used for the RTO > setting. > >> >> As to my understanding, we can exclude other problems, the only >> problem with TCP in mobile wireless networks are unexpected, or >> unforeseeable respectively, delay spikes or a sudden increase of delays. > > > Well, packet losses are the main problem... and they should be hidden to > TCP with wireless link layer protocol and persistant retransmissions... > Well, if packet loss is hidden by L2 retransmissions, then, packet loss would become delay, which can become spurious timeouts (depending on the delay increase) right? Then spurious timeouts won't be that marginal... Best regards Filipe > > Spurious timeouts are a second (marginal) problem that in my opinion > (and in my research) are not frequent events in a well engineered > GPRS/UMTS network. > > Francesco > >> >> This can be due to >> - scheduling (voice is priorized over data) >> - route change (I don?t know whether this is that important, because >> much of this is micromobility) >> - changes in physical path properties. >> > > -- Filipe Lameiro Abrantes INESC Porto Campus da FEUP Rua Dr. Roberto Frias, 378 4200-465 Porto Portugal Phone: +351 22 209 4266 E-mail: fla at inescporto.pt From jloiacon at csc.com Fri Sep 2 07:42:24 2005 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 2 Sep 2005 10:42:24 -0400 Subject: [e2e] OT: NANOG off the air? In-Reply-To: <43171FF0.5030304@net.infocom.uniroma1.it> Message-ID: Are end-of-end readers that also subscribe to NANOG receiving NANOG posts after 8/30? Thanks, Joe Francesco Vacirca To: weddy at grc.nasa.gov Retransmission Timouts revisited Sent by: end2end-interest -bounces 09/01/2005 11:36 AM I agree... also the spurious timeout estimation method can influence the results... How did you estimate that? Francesco Wesley Eddy wrote: > On Thu, Sep 01, 2005 at 05:01:15PM +0200, Francesco Vacirca wrote: > >>maybe this is due to the fact that different 3G networks have different >>terminal population (mobile terminal and data cards) with different TCP >>implementations. >> > > > I think this is probably the case. The differences in observation are > probably due much more to the network's configuration than the TCP > implementation. Whether the user is stationary or mobile between towers > also makes a big difference in what kinds of problems are prevalent. > > -Wes > From francesco at net.infocom.uniroma1.it Fri Sep 2 08:54:07 2005 From: francesco at net.infocom.uniroma1.it (Francesco Vacirca) Date: Fri, 02 Sep 2005 17:54:07 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <43185BD7.2090402@inescporto.pt> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> Message-ID: <4318759F.7010906@net.infocom.uniroma1.it> Filipe Abrantes wrote: >> >> Well, packet losses are the main problem... and they should be hidden >> to TCP with wireless link layer protocol and persistant >> retransmissions... >> > > Well, if packet loss is hidden by L2 retransmissions, then, packet loss > would become delay, which can become spurious timeouts (depending on the > delay increase) right? Then spurious timeouts won't be that marginal... > I'm agree with that... what I'm trying to say is that L2 retransmissions are due to transmission errors on the wireless channel... and with all kind of ARQ protocols (from Stop'n Wait to Selective Repeat) if you drop packet K (because one or more PDUs belonging to that TCP-SDU reached the max number of retransmissions N), that implies that if packet K+1 crosses the wireless channel it will arrive after the moment that K would arrived with some more retransmissions... and this implies that if the RTO would expire for K with infinite retransmissions, it would expire also for K+1 with N retransmissions... with no advantages for TCP, but with some small disadvantages that I do not think could influence the overall goodput. Moreover with FRTO (or other mechanisms) TCP can recover a spurious timeout, but a normal timeout (due to real loss) can just be recovered by slow-start because it is a real loss with RTO expiration and there is no possibility to distinguish it from a congestion event (without explicit notification). f. > Best regards > > Filipe > >> >> Spurious timeouts are a second (marginal) problem that in my opinion >> (and in my research) are not frequent events in a well engineered >> GPRS/UMTS network. > > >> >> Francesco >> >>> >>> This can be due to >>> - scheduling (voice is priorized over data) >>> - route change (I don?t know whether this is that important, because >>> much of this is micromobility) >>> - changes in physical path properties. >>> >> >> > From bmanning at vacation.karoshi.com Fri Sep 2 09:11:02 2005 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Fri, 2 Sep 2005 16:11:02 +0000 Subject: [e2e] OT: NANOG off the air? In-Reply-To: References: <43171FF0.5030304@net.infocom.uniroma1.it> Message-ID: <20050902161102.GA22284@vacation.karoshi.com.> yes. On Fri, Sep 02, 2005 at 10:42:24AM -0400, Joe Loiacono wrote: > > > > > Are end-of-end readers that also subscribe to NANOG receiving NANOG posts > after 8/30? > > Thanks, > > Joe > > > > Francesco > Vacirca To: weddy at grc.nasa.gov > @net.infocom.uni Subject: Re: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: > roma1.it> Retransmission Timouts revisited > Sent by: > end2end-interest > -bounces > > > 09/01/2005 11:36 > AM > > > > > > I agree... also the spurious timeout estimation method can influence the > results... How did you estimate that? > > Francesco > > Wesley Eddy wrote: > > On Thu, Sep 01, 2005 at 05:01:15PM +0200, Francesco Vacirca wrote: > > > >>maybe this is due to the fact that different 3G networks have different > >>terminal population (mobile terminal and data cards) with different TCP > >>implementations. > >> > > > > > > I think this is probably the case. The differences in observation are > > probably due much more to the network's configuration than the TCP > > implementation. Whether the user is stationary or mobile between towers > > also makes a big difference in what kinds of problems are prevalent. > > > > -Wes > > > From detlef.bosau at web.de Fri Sep 2 09:26:04 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 02 Sep 2005 18:26:04 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> Message-ID: <43187D1C.6040300@web.de> Filipe Abrantes wrote: >> > > Well, if packet loss is hidden by L2 retransmissions, then, packet loss > would become delay correct > , which can become spurious timeouts (depending on the not necessarily. ARQ etc. results in varying latencies => VAR becomses large => RTO becomes large. My guess (as usual, I?m willing to accept contradiction) is, that we a certain variance in our delay and that?s it. -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Fri Sep 2 11:03:24 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 02 Sep 2005 20:03:24 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> <4318759F.7010906@net.infocom.uniroma1.it> Message-ID: <431893EC.4080608@web.de> Francesco Vacirca wrote: > I'm agree with that... what I'm trying to say is that L2 retransmissions > are due to transmission errors on the wireless channel... and with all > kind of ARQ protocols (from Stop'n Wait to Selective Repeat) if you drop > packet K (because one or more PDUs belonging to that TCP-SDU reached the > max number of retransmissions N), that implies that if packet K+1 > crosses the wireless channel it will arrive after the moment that K > would arrived with some more retransmissions... and this implies that if I admit: I cannot follow. Packet K is lost. Packet K+1 not. What?s the problem? And what do you mean with "K+1 .... will arrive after the moment K would arrived with...."? K did not arrive. So K?s arrivale time in case of ... does not matter. > the RTO would expire for K with infinite retransmissions, it would > expire also for K+1 with N retransmissions... with no advantages for Why? I do not the the connection from your maximum retransmission count N and the TCP RTO. In addition, N is purely a L2 topic. For TCP/IP, a packet is either delivered and experiences a certian latency or it is lost. > TCP, but with some small disadvantages that I do not think could > influence the overall goodput. > Moreover with FRTO (or other mechanisms) TCP can recover a spurious > timeout, but a normal timeout (due to real loss) can just be recovered > by slow-start because it is a real loss with RTO expiration and there is > no possibility to distinguish it from a congestion event (without > explicit notification). Nevertheless, there are situations where a slow start is not necessary. Basically, my question is: Do spurious timeouts happen really that often? Or in different terms: From what I?ve learned during the last few weeks, 3G networks are basically understood, spurious timeouts do happen, occasionally, now and then. If so, we are able to detect them and recover from, e.g. unnecessar congestion handling. So, for the case of TCP over 3G networks: Is this case closed? Just a question. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From fla at inescporto.pt Fri Sep 2 11:24:18 2005 From: fla at inescporto.pt (Filipe Abrantes) Date: Fri, 02 Sep 2005 19:24:18 +0100 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <431893EC.4080608@web.de> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> <4318759F.7010906@net.infocom.uniroma1.it> <431893EC.4080608@web.de> Message-ID: <431898D2.4070707@inescporto.pt> Detlef Bosau wrote: > Francesco Vacirca wrote: > >> I'm agree with that... what I'm trying to say is that L2 >> retransmissions are due to transmission errors on the wireless >> channel... and with all kind of ARQ protocols (from Stop'n Wait to >> Selective Repeat) if you drop packet K (because one or more PDUs >> belonging to that TCP-SDU reached the max number of retransmissions >> N), that implies that if packet K+1 crosses the wireless channel it >> will arrive after the moment that K would arrived with some more >> retransmissions... and this implies that if > > > > > I admit: I cannot follow. > > Packet K is lost. Packet K+1 not. What?s the problem? > > And what do you mean with "K+1 .... will arrive after the moment K would > arrived with...."? > > K did not arrive. > > So K?s arrivale time in case of ... does not matter. > Hmmmm, some misunderstanding here i beleive: packet K and K+1 arrive at destination, (K is the seqno of TCP), however packet K has to be retransmitted in some wireless hop in the path, due to transmission errors. What Francesco was saying (if i understood it correctly) is that this restransmission will lead to an increase of the rtt which will be noted by the sender both in packet K and packet K+1 because packet K+1 goes imediatly after packet K. So if packet K time's out, then packet K+1 will also timeout. Francesco claimed that this would have some effect on the spurious timeout detection which i didn't quite understood, but im also not that familiar with rto estimation procedures. Regards, Filipe >> the RTO would expire for K with infinite retransmissions, it would >> expire also for K+1 with N retransmissions... with no advantages for > > > Why? > > I do not the the connection from your maximum retransmission count N and > the TCP RTO. In addition, N is purely a L2 topic. For TCP/IP, a packet > is either delivered and experiences a certian latency or it is lost. > > >> TCP, but with some small disadvantages that I do not think could >> influence the overall goodput. >> Moreover with FRTO (or other mechanisms) TCP can recover a spurious >> timeout, but a normal timeout (due to real loss) can just be recovered >> by slow-start because it is a real loss with RTO expiration and there >> is no possibility to distinguish it from a congestion event (without >> explicit notification). > > > > Nevertheless, there are situations where a slow start is not necessary. > > Basically, my question is: Do spurious timeouts happen really that often? > > Or in different terms: From what I?ve learned during the last few weeks, > 3G networks are basically understood, spurious timeouts do happen, > occasionally, now and then. If so, we are able to detect them and > recover from, e.g. unnecessar congestion handling. > > So, for the case of TCP over 3G networks: Is this case closed? > > Just a question. > > Detlef > -- Filipe Lameiro Abrantes INESC Porto Campus da FEUP Rua Dr. Roberto Frias, 378 4200-465 Porto Portugal Phone: +351 22 209 4266 E-mail: fla at inescporto.pt From detlef.bosau at web.de Fri Sep 2 12:27:44 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 02 Sep 2005 21:27:44 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> <4318759F.7010906@net.infocom.uniroma1.it> <431893EC.4080608@web.de> <431898D2.4070707@inescporto.pt> Message-ID: <4318A7B0.6000103@web.de> Filipe Abrantes wrote: > >> > > Hmmmm, some misunderstanding here i beleive: packet K and K+1 arrive at > destination, (K is the seqno of TCP), however packet K has to be > retransmitted in some wireless hop in the path, due to transmission O.k. > errors. What Francesco was saying (if i understood it correctly) is that > this restransmission will lead to an increase of the rtt which will be > noted by the sender both in packet K and packet K+1 because packet K+1 > goes imediatly after packet K. So if packet K time's out, then packet O.k. > K+1 will also timeout. Francesco claimed that this would have some > effect on the spurious timeout detection which i didn't quite > understood, but im also not that familiar with rto estimation procedures. So, there is some variation in the end to end latency. Right? RTO = E + 2*V, in later Implementations: RTO = E + 4*V. Variance increases => RTO increases. That?s the simple view. The other problem is perhaps the delay spike, you talk about, because we try to maintain the packet order at any cost. This was my question, whether delay spikes were a problem. One way to hide delay spikes from a sender are PEP. Another, perhaps much more appealing way (and _please_, if this sounds reasonable and no one did it, let me the chance to publish it myself....) because it does not require any PEP or splitting or something else on L3 and above is to exploit the robustness TCP following actual RFCs against packet reordering, is to interleave the radio blocks of more than one TCP packet and thus to spread delay spikes about several packets. It?s just a rough idea now. However, if it is helpful, please leave it to me. If it is nonsense, please tell it to me as well. It would be a possiblity to map a behaviour, TCP cannot deal with, unto one which can be dealt with without difficulties. One could call this "delay spreading". I don?t know, whether it works. I thouht of it spontaneously yesterday after the recent posts here. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Fri Sep 2 12:34:32 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 02 Sep 2005 21:34:32 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> <4318759F.7010906@net.infocom.uniroma1.it> <431893EC.4080608@web.de> <431898D2.4070707@inescporto.pt> <4318A7B0.6000103@web.de> Message-ID: <4318A948.3040203@web.de> Detlef Bosau wrote: > Another, perhaps much more appealing way (and _please_, if this sounds > reasonable and no one did it, let me the chance to publish it > myself....) because it does not require any PEP or splitting or > something else on L3 and above is to exploit the robustness TCP > following actual RFCs against packet reordering, is to interleave the > radio blocks of more than one TCP packet and thus to spread delay spikes > about several packets. It?s just a rough idea now. However, if it is > helpful, please leave it to me. If it is nonsense, please tell it to me > as well. It would be a possiblity to map a behaviour, TCP cannot deal > with, unto one which can be dealt with without difficulties. > One could call this "delay spreading". I don?t know, whether it works. > I thouht of it spontaneously yesterday after the recent posts here. > > Detlef > > > Basically, this is nothing really new. We do this for ages as "code spreading" or "interleaving" in any FEC technique. It?s only the idea to do the same for ARQ. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Sat Sep 3 10:20:12 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 03 Sep 2005 19:20:12 +0200 Subject: [e2e] Wireless Channel Properties References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> <4318759F.7010906@net.infocom.uniroma1.it> <431893EC.4080608@web.de> <431898D2.4070707@inescporto.pt> <4318A7B0.6000103@web.de> Message-ID: <4319DB4B.965F253D@web.de> Detlef Bosau wrote: > One way to hide delay spikes from a sender are PEP. > > Another, perhaps much more appealing way (and _please_, if this sounds > reasonable and no one did it, let me the chance to publish it > myself....) because it does not require any PEP or splitting or > something else on L3 and above is to exploit the robustness TCP > following actual RFCs against packet reordering, is to interleave the > radio blocks of more than one TCP packet and thus to spread delay spikes > about several packets. It?s just a rough idea now. However, if it is > helpful, please leave it to me. If it is nonsense, please tell it to me Of course, there is one problem. One could prove this in a "scientific manner", i.e. assume some more or less sophisticated "system model" and conclude something from that. This would not be convincing, but a pure "ivory tower" way of thinking. What would be needed, are _real_ traces of _real_ channels. In a trace, a channel has two states: good and bad. Not because I only can count: 0, 1, inf..... ;-) But because in mobile wireless networks a sender sends a sequence of radio blocks. And a radio block either will reach the sender or get lost. Is there any possibility to obtain traces like this? Anything else would be pure hand waving. It is just interesting to see, wether a channel behaves like this: +: radio block is delivered -: radio block fails Example 1: +-+-+-+-+-+-+-+-+- or like this: Example 2: +++++++++++++++++-+++++++++++-+++++++++++++++++++- or linke this: Exampel 3: +++++++-----------++++++++++++--+++++++++++++++++++++++++++++--- the list can be continued. I expect, possible Interleaving strategies must reflect these patterns in order to really _spread_ a delay spike about several packets. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From davide+e2e at cs.cmu.edu Sat Sep 3 11:01:26 2005 From: davide+e2e at cs.cmu.edu (Dave Eckhardt) Date: Sat, 03 Sep 2005 14:01:26 -0400 Subject: [e2e] Wireless Channel Properties In-Reply-To: <4319DB4B.965F253D@web.de> Message-ID: <3533.1125770486@piper.nectar.cs.cmu.edu> Here are some (bit-level) traces: http://www.cs.cmu.edu/~davide/wltraces Dave Eckhardt From francesco at net.infocom.uniroma1.it Mon Sep 5 04:26:13 2005 From: francesco at net.infocom.uniroma1.it (Francesco Vacirca) Date: Mon, 05 Sep 2005 13:26:13 +0200 Subject: [e2e] Spurious Timeouts in mobile wireless networks, was: Re: Retransmission Timouts revisited In-Reply-To: <431898D2.4070707@inescporto.pt> References: <430E1862.23935C68@web.de> <4316EE5F.7060203@web.de> <431708EE.8070807@net.infocom.uniroma1.it> <43185BD7.2090402@inescporto.pt> <4318759F.7010906@net.infocom.uniroma1.it> <431893EC.4080608@web.de> <431898D2.4070707@inescporto.pt> Message-ID: <431C2B55.5050505@net.infocom.uniroma1.it> Filipe Abrantes wrote: > > > Detlef Bosau wrote: > >> Francesco Vacirca wrote: >> >>> I'm agree with that... what I'm trying to say is that L2 >>> retransmissions are due to transmission errors on the wireless >>> channel... and with all kind of ARQ protocols (from Stop'n Wait to >>> Selective Repeat) if you drop packet K (because one or more PDUs >>> belonging to that TCP-SDU reached the max number of retransmissions >>> N), that implies that if packet K+1 crosses the wireless channel it >>> will arrive after the moment that K would arrived with some more >>> retransmissions... and this implies that if >> >> >> >> >> >> I admit: I cannot follow. >> >> Packet K is lost. Packet K+1 not. What?s the problem? >> >> And what do you mean with "K+1 .... will arrive after the moment K >> would arrived with...."? >> >> K did not arrive. >> >> So K?s arrivale time in case of ... does not matter. >> > > Hmmmm, some misunderstanding here i beleive: packet K and K+1 arrive at > destination, (K is the seqno of TCP), however packet K has to be > retransmitted in some wireless hop in the path, due to transmission > errors. What Francesco was saying (if i understood it correctly) is that > this restransmission will lead to an increase of the rtt which will be > noted by the sender both in packet K and packet K+1 because packet K+1 > goes imediatly after packet K. So if packet K time's out, then packet > K+1 will also timeout. Francesco claimed that this would have some > effect on the spurious timeout detection which i didn't quite > understood, but im also not that familiar with rto estimation procedures. > My point is a little bit different... I know I'm not good in explain that... I'll try again: One important point: -usually there is just one timer for on-flight TCP packets Two different situations: 1) finite number of retransmissions 2) infinite number of retransmissions (or very high) in case 1) if packet K is dropped because it is reached the maximum number of retransmission attempts, K+1 can arrive: A) before RTO expiration... and K is probably retransmitted with fast retransmit B) after RTO expiration... and K is retransmitted because of RTO expiration in case 2) with the same channel condition of 1A, K will arrive before RTO expiration... no retransmissions in case 2) with the same channel condition of 1B, K will arrive after RTO expiration... and K is retransmitted because of RTO expiration (Spurious retransmission) From a TCP point of view, I think that 2) is always better than 1) regards, f. From salkesh at cc.gatech.edu Mon Sep 5 17:12:35 2005 From: salkesh at cc.gatech.edu (Alkesh Shah) Date: Mon, 5 Sep 2005 20:12:35 -0400 (EDT) Subject: [e2e] Paper on TCP Message-ID: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu> Hi, I wanted the follwing two papers. If anybody has them please mail them to me... My email address - salkesh at cc.gatech.edu 1) V. Jacobson. "Modified TCP congestion avoidance algorithm". 2) J. Hoe. "Start-up dynamics of TCP's congestion control and avoidance schemes". Master's thesis, Massachusetts Institute of Technology, June 1995 Thanks. rgds, alkesh From faber at ISI.EDU Tue Sep 6 08:02:10 2005 From: faber at ISI.EDU (Ted Faber) Date: Tue, 6 Sep 2005 08:02:10 -0700 Subject: [e2e] Paper on TCP In-Reply-To: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu> References: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu> Message-ID: <20050906150210.GD32839@pun.isi.edu> On Mon, Sep 05, 2005 at 08:12:35PM -0400, Alkesh Shah wrote: > Hi, > > I wanted the follwing two papers. If anybody has them please mail them to > me... My email address - salkesh at cc.gatech.edu > > 1) V. Jacobson. "Modified TCP congestion avoidance algorithm". ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail It's an e-mail message to this list. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050906/d86d8668/attachment.bin From detlef.bosau at web.de Tue Sep 6 11:06:36 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 06 Sep 2005 20:06:36 +0200 Subject: [e2e] Wireless Channel Properties References: <3533.1125770486@piper.nectar.cs.cmu.edu> Message-ID: <431DDAAC.1AEB6E39@web.de> Dave Eckhardt wrote: > > Here are some (bit-level) traces: > http://www.cs.cmu.edu/~davide/wltraces > > Dave Eckhardt Thanks a lot! I did not run them on my little simulation program yet, because my little simulation, .... "program" is perhaps a too big word, which I wrote the last few days cannot read from bit level traces yet. However, as far as I have seen when I first looked at your traces, the results appear to be quite harmless. Of course, there are some drops. This is no problem. Packet drops occur in networks for various reasons. >From a mobile networks perspective, these drops are typically not perceived by a TCP flow. Typically, in mobile networks, we have something like this: L2 PDU -------- ARQ -------- FEC -------- MAC/Scheduling/Micromobiliy/Roaming -------- Radio So, latencies perceived by L2 PDUs are mainly due to 1. Radio, Serialization Delay, Propagation Dely 2. MAC/Scheduling Delay 3. some "virual propagation delay" due to FEC overhead 4. ARQ Retransmissions. Recently, I was told about some interleaving done in UMTS. Q.: Where is this done in the layer diagramm above? In my little program, radio blocks have a constant length (i.e. it doesn?t matter) and there ist no Mac/Scheduling delay. Thus, a block is sent and received or it is sent and dropped. At the moment, I simulate stop?n wait ARQ. When I think of typical radio block lengths (about 170 bit AFAIK), typical radio link bandwidth (e.g. 2 MBit/s physikal in UMTS or less due to CDMA spreading) a typical UMTS cell (several hundred meters) will hardly keep severel blocks "on the air", hence I don?t see a reason for sliding window here. O.k. Concering delay spikes, which may cause trouble to TCP, these results from ARQ in my little program. So, I?m about to add an error model which allows a block to pass or which causes a block to fail. On this layer, there are only these two alternatives. I played around with some error models today, dropped one block in ten or 20 blocks in hundred, I used different sizes of ARQ buffers and different retransmission strategies (FIFO, random, failed packet is left in place and repeated, failed packet is appended to the queue) and all yielded different delay traces. My error models were far more aggressive than what I?ve seen from Dave?s WLAN traces. Alas - when I generated srtt, svar and RTO with the typical TCP algorithms and compared RTO and "observed" rtt, anything was perfectly fine! Depending on the success/failure ratio on the "FEC layer" the path caused different latencies and thus exhibited a different bandwidth to the user. That?s life. However, I did not yet achieve spurious timeouts, at least not unexpectedly often. As I wrote in earlier posts, some amount of spurious timeouts is _tolerated_ by the RTO. So at the moment, I?m afraid I can use Dave?s traces as error model - and TCP may be perfectly lucky whith it. Either I?m a bad programmer (which is surely true, I?m one of the worst programmers I know at all) or TCP?s timers remain obstinate and refuse to have any problems... A possible alternative of course is, that I use much to "soft" error models. Perhaps, the situation will change when I drop 20 % or 30 % of my radio blocks. Another alternative is, that I have to consider scheduling delays. So my question to the list is: Q: What exactly causes delay spikes / unduly often spurious timeouts in mobile wireless networks? Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From alokdube at hotpop.com Tue Sep 6 12:39:11 2005 From: alokdube at hotpop.com (Alok) Date: Wed, 7 Sep 2005 01:09:11 +0530 Subject: [e2e] Paper on TCP References: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu> <20050906150210.GD32839@pun.isi.edu> Message-ID: <004d01c5b31a$a9f451d0$1c0218ac@rs.riverstonenet.com> interesting to read the archives... kinda sad i missed that era..wonder if we ever have it again :-)..no nice new problems to solve :-( ----- Original Message ----- From: "Ted Faber" To: "Alkesh Shah" Cc: Sent: Tuesday, September 06, 2005 8:32 PM Subject: Re: [e2e] Paper on TCP From faber at ISI.EDU Tue Sep 6 13:53:49 2005 From: faber at ISI.EDU (Ted Faber) Date: Tue, 6 Sep 2005 13:53:49 -0700 Subject: [e2e] Paper on TCP In-Reply-To: <004d01c5b31a$a9f451d0$1c0218ac@rs.riverstonenet.com> References: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu> <20050906150210.GD32839@pun.isi.edu> <004d01c5b31a$a9f451d0$1c0218ac@rs.riverstonenet.com> Message-ID: <20050906205349.GM1069@pun.isi.edu> On Wed, Sep 07, 2005 at 01:09:11AM +0530, Alok wrote: > interesting to read the archives... > > kinda sad i missed that era..wonder if we ever have it again :-)..no nice > new problems to solve :-( There are *always* nice new problems to solve. :-) But you do have to hunt harder... -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050906/132eeaa2/attachment.bin From rik at rikwade.com Tue Sep 6 14:35:40 2005 From: rik at rikwade.com (Rik Wade) Date: Wed, 7 Sep 2005 09:35:40 +1200 (NZST) Subject: [e2e] Paper on TCP In-Reply-To: <004d01c5b31a$a9f451d0$1c0218ac@rs.riverstonenet.com> References: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu> <20050906150210.GD32839@pun.isi.edu> <004d01c5b31a$a9f451d0$1c0218ac@rs.riverstonenet.com> Message-ID: <49123.134.159.99.8.1126042540.squirrel@www.rikwade.com> On Wed, September 7, 2005 07:39, Alok wrote: > interesting to read the archives... > > kinda sad i missed that era..wonder if we ever have it again :-)..no nice > new problems to solve :-( There are many problems still to solve in the context of the current Internet architecture. However, more interesting ones appear as we stop thinking in terms of this architecture and look at new ways of processing and transporting Internet traffic. -- rik From alokdube at hotpop.com Tue Sep 6 16:32:47 2005 From: alokdube at hotpop.com (Alok) Date: Wed, 7 Sep 2005 05:02:47 +0530 Subject: [e2e] Paper on TCP References: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu><20050906150210.GD32839@pun.isi.edu><004d01c5b31a$a9f451d0$1c0218ac@rs.riverstonenet.com> <49123.134.159.99.8.1126042540.squirrel@www.rikwade.com> Message-ID: <000d01c5b33b$4ba3b730$6401a8c0@rs.riverstonenet.com> Would appreciate a "problem defination" to start with in that case, ----- Original Message ----- From: "Rik Wade" To: Sent: Wednesday, September 07, 2005 3:05 AM Subject: Re: [e2e] Paper on TCP > > On Wed, September 7, 2005 07:39, Alok wrote: > > interesting to read the archives... > > > > kinda sad i missed that era..wonder if we ever have it again :-)..no nice > > new problems to solve :-( > > There are many problems still to solve in the context of the current > Internet architecture. However, more interesting ones appear as we stop > thinking in terms of this architecture and look at new ways of processing > and transporting Internet traffic. > -- > rik > > From garmitage at swin.edu.au Tue Sep 6 18:10:16 2005 From: garmitage at swin.edu.au (grenville armitage) Date: Wed, 07 Sep 2005 11:10:16 +1000 Subject: [e2e] Paper on TCP In-Reply-To: <000d01c5b33b$4ba3b730$6401a8c0@rs.riverstonenet.com> References: <3476.130.207.114.110.1125965555.squirrel@webmail.cc.gatech.edu><20050906150210.GD32839@pun.isi.edu><004d01c5b31a$a9f451d0$1c0218ac@rs.riverstonenet.com> <49123.134.159.99.8.1126042540.squirrel@www.rikwade.com> <000d01c5b33b$4ba3b730$6401a8c0@rs.riverstonenet.com> Message-ID: <431E3DF8.3020302@swin.edu.au> Alok wrote: > Would appreciate a "problem defination" to start with in that case, I've been impressed by Detlef in recent weeks, who isn't waiting for someone to spoon feed a problem definition, instead going off and digging around to figure out the problems. Perhaps you could take on the challenge of writing and publishing some potential problem definitions? cheers, gja From jamjoom at us.ibm.com Tue Sep 6 12:23:16 2005 From: jamjoom at us.ibm.com (Hani Jamjoom) Date: Tue, 6 Sep 2005 15:23:16 -0400 Subject: [e2e] NETGAMES'05 (Call for Participation) Message-ID: Many apologies if you receive duplicates of this message _____________________________________ CALL FOR PARTICIPATION NETGAMES?05 The 4th Workshop on Network and Systems Support for Games http://www.research.ibm.com/netgames2005/ ____________________________________ in cooperation with ACM SIGCOMM The 4th Workshop on Network and Systems Support for Games (NETGAMES?05) will be held in T.J. Watson Research Center, Hawthorne, NY on October 10-11, 2005. The NETGAMES workshop brings together researchers and developers from academia and industry to share ideas and present new research in understanding networked games and in enabling the next generation of online games. _____________________________________ LOCATION & DATE IBM T.J. Watson Research Center Hawthorn, NY October 10-11, 2005 _____________________________________ PROGRAM NETGAMES?05 features papers and extended abstracts describing research related to networked games on all platforms. This year, presentation topics will include: MOBILE & WIRELESS GAMES .. ?Networked Game Mobility Model for First-Person-Shooter Games? Swee Ann Tan, W. Lau, Alan Loh (Curtin U. of Tech, Australia) .. ?On the Effects of Loose Causal Consistency in Mobile Multiplayer Games? Angie Chandler, Joe Finney (Lancaster University, UK) .. ?Programming Interactive Real-Time Games over WLAN for Pocket PCs with J2ME and .NET CF? Andreas Janecek, Helmut Hlavacs (Univ. of Vienna, Austria) .. ?Framework for Evaluation of Networked Mobile Games? Leo Petrak, Olaf Landsiedel, Klaus Wehrle (Univ. of T?bingen, Germany) CHEATING & FAIRNESS .. ?A Systematic Classification of Cheating in Online Games? Jeff Yan, Brian Randell (University of Newcastle, UK) .. ?Addressing Cheating in Distributed MMOGs? Patric Kabus, Wesley Terpstra, Mariano Cilia, Alejandro Buchmann (Darmstadt Univ. of Technology, Germany) .. ?Fairness in Dead-Reckoning based Distributed Multi-Player Games? Sudhir Aggarwal, Hemant Banavar (Florida State University), Sarit Mukherjee, Sampath Rangarajan (Bell Labs/Lucent Tech) MULTIPLAYER GAME ARCHITECTURE .. ?A Distributed Event Delivery Method with Load Balancing for MMORPG? Shinya Yamamoto, Yoshihiro Murata, Keiichi Yasumoto, Minoru Ito (Nara Institute of Science and Technology, Japan) .. ?Dynamic Microcell Assignment for Massively Multiplayer Online Gaming? Bart De Vleeschauwer, Bruno Van Den Bossche, Tom Verdickt, Filip De Turck, Bart Dhoedt, Piet Demeester (Ghent Univ., Belgium) .. ?A Challenge for Reusing Multiplayer Online Games without Modifying Binaries? Yugo Kaneda, Hitomi Takahashi, Masato Saito, Hiroto Aida, Hideyuki Tokuda (Keio University, Japan) NETWORK EFFECTS ON GAMES .. ?Influence of Network Latency and Packet Loss on Consistency in Networked Racing Games? Takahiro Yasui, Yutaka Ishibashi, Tomohito Ikedo (Nagoya Institute of Technology, Japan) .. ?The Effect of Latency and Network Limitations on MMORPGs ? (A Field Study of Everquest2)? Tobias Fritsch, Hartmut Ritter, Jochen Schiller (Freie Universit?t Berlin, Germany) .. ?Analysis of Factors Affecting Players' Performance and Perception in Multiplayer Games? Matthias Dick, Oliver Wellnitz, Lars Wolf (TU Braunschweig, Germany) .. ?Packetization Interval of Haptic Media in Networked Virtual Environments? Masaki Fujimoto, Yutaka Ishibashi (Nagoya Institute of Technology, Japan) ONLINE GAMING SERVICE .. ?FreeRank: Implementing Independent Ranking Service for Multiplayer Online Games? Li Tang (Tsinghua University, China) .. ?Patch Scheduling for On-line Games? Chris Chambers, Wu-chang Feng (Portland State University) .. ?Game Server Selection for Multiple Players? Steven Gargolinski, Christopher St. Pierre, Mark Claypool (Worcester Polytechnic Institute, USA) GAME TRAFFIC CHARACTERIZATION .. ?On the 802.11 Turbulence of Nintendo DS and Sony PSP Hand- held Network Games? Mark Claypool (Worcester Polytechnic Institute, USA) .. ?Traffic Characteristics of a Massively Multiplayer Online Role Playing Game and Its Implications? Jaechul Kim (Seoul National University, Republic of Korea) .. ?Dissecting Server-Discovery Traffic Patterns Generated By Multiplayer First Person Shooter Games? Sebastian Zander, David Kennedy, Grenville Armitage (Swinburne University of Technology, Australia) There will also be a panel session titled: ?Research in Online Games: An Industry Perspective? For additional information see the conference web site: http://www.research.ibm.com/netgames2005/ _____________________________________ REGISTRATION Registration is now open: http://www.regonline.com/eventinfo.asp?EventId=29371 Fees: Full Registration ($100), ACM Members ($75), and all Students ($35) A list of nearby hotels has been posted on the conference website. _____________________________________ IMPORTANT DATES Early Registration: September 20, 2005 _____________________________________ ORGANIZING COMMITTEE Program Chair: Debanjan Saha (IBM T.J. Watson Research Center) Publicity Chair: Hani Jamjoom (IBM T.J. Watson Research Center) Finance Chair: Sambit Sahu (IBM T.J. Watson Research Center) Technical Program Committee: Grenville Armitage (Swinburne University, Australia) Adrian Cheok (National University of Singapore, Singapore) Mark Claypool (Worcester Polytechnic Institute) Wu-chang Feng (Portland State University) Tristan Henderson (Dartmouth College) Sugih Jamin (University of Michigan) Brian Levine (University of Massachusetts) Sarit Mukherjee (Lucent Bell Labs) Anees Shaikh (IBM T.J. Watson Research Center) Lars Wolf (Tech Univ Braunschweig, Germany) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050906/f76b83d6/attachment-0001.html From keshav at uwaterloo.ca Wed Sep 7 15:44:19 2005 From: keshav at uwaterloo.ca (S. Keshav) Date: Wed, 07 Sep 2005 18:44:19 -0400 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 5 In-Reply-To: Message-ID: Detlef, > > Q: What exactly causes delay spikes / unduly often spurious timeouts in > mobile wireless networks? As your mail indicates, delay spikes are due to link-level (i.e. what is called 'Radio Link Protocol' or RLP) retransmissions, which attempt to hide link losses from higher layers. They can _also_ be caused by opportunistic scheduling, used, for example, in EvDO, where a mobile with a good channel gets all the resources, causing delays for other mobiles. A possible (and perhaps only?) way in which a TCP connection gets spurious timeouts is as follows: The channel is in a 'good' state wrt a particular mobile, so that a mobile gets all its packets through with low RTT, and it sets its RTO small. Now, if the channel goes into a bad state, the mobile will experience a 'spurious' timeout. While plausible, this scenario may not actually play out in real life (and in your simulations) for one or more of the following reasons: 1. The mobile may not move, so it does not change from a good to bad area, staying all the time in a good or bad area. 2. The connection may be too short, so that during the lifetime of a connection, the mobile does not change channel state. 3. The connection may be long, but the initial RTO may be so high, that during the connection lifetime the RTO is never short enough to be a problem even when the mobile has a 'bad' channel state. 4. The variations in the channel state may be so rapid that, from the perspective of a connection, all it sees is the average channel state, so the RTO is roughly correct. 5. The RTO may be wrong, but the coarse timeout granularity may be long enough (it used to be 500ms granularity), so that even the shortest timeout is not long enough to cause a spurious timeout. 6. Channel conditions may not differ so much in the 'good' and 'bad' states. So, there are many reasons, why, even with the known variations in channel delay on a cell phone link, we may not see spurious timeouts. It would be nice if a cell phone operator reading this list were to actually verify (or contradict) this using real data traces. Opportunistic scheduling, will, I think, tend to exacerbate the differences between 'good' and 'bad' channel state (caveat #6 above). However, the other causes may yet cause spurious timeouts to be avoided. I should add that I am not an expert in cell phone links, so my analysis above is purely seat-of-the-pants, but its looks reasonable, at least to me. regards keshav From detlef.bosau at web.de Thu Sep 8 07:21:49 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 08 Sep 2005 16:21:49 +0200 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 5 References: Message-ID: <432048FD.D9F347F6@web.de> "S. Keshav" wrote: > > > As your mail indicates, delay spikes are due to link-level (i.e. what is > called 'Radio Link Protocol' or RLP) retransmissions, which attempt to hide > link losses from higher layers. They can _also_ be caused by opportunistic > scheduling, used, for example, in EvDO, where a mobile with a good channel > gets all the resources, causing delays for other mobiles. O.k. At the moment, I have no "feeling" for the effects of opportunistic scheduling. However, it should not really matter. In general, I think, the NO will adapt the number of time slots used for a packet channel to the actual load due to line switching traffic. This will result in a increase or decrease of bandwidth depending on the load. Because I have no real idea about 3G networks (it?s admittedly more or less smattering) I don?t know whether scheduling conflicts occur and how often. However, they would defer some radio block for some few time slots. I think, a backoff on Ethernet might be harder ;-) I don?t think it?s something for a TCP sender to care about. > > A possible (and perhaps only?) way in which a TCP connection gets spurious > timeouts is as follows: > > The channel is in a 'good' state wrt a particular mobile, so that a mobile > gets all its packets through with low RTT, and it sets its RTO small. Now, > if the channel goes into a bad state, the mobile will experience a > 'spurious' timeout. I think, this is thre recipe used in the hiccup-tool (I don?t remember the author, it was an Morten Schlagers homepage for a long time and Reiner Ludwig used it extensively in his PhD thesis. However, I don?t remember, who originally wrote it) and in my dump "simulations" here. I simulate a long period where the network is in "good state", so that the variance drops near to zero, and then I change the network to a bad state. Having bad states to often or to close to each other will cause the variance to increase and therefore no spurious timeout occurs.... > > While plausible, this scenario may not actually play out in real life (and > in your simulations) for one or more of the following reasons: > > 1. The mobile may not move, so it does not change from a good to bad area, > staying all the time in a good or bad area. > In addition: Depending on the cell size, a mobile that moves may change the cell. In fact, this can cause a spurious timeout itself. However, I was told a few days ago that a cell change may cause some "settling" anyway (different timeslot allocation, different network load, different SNR, CS, symbol set,....), so spurious timeouts are not "the" problem in this case but more some "collateral event", the word "damage" would be too hard. ..... > > 6. Channel conditions may not differ so much in the 'good' and 'bad' states. Or channel conditions change rather smoothly from 'good' to 'bad' from the L3 view, because a sophisticated retransmission schemme smoothens latency changes. I don?t know how this is done in practical implementations. But it can be achieved quite easily with spreading techniques. > > So, there are many reasons, why, even with the known variations in channel > delay on a cell phone link, we may not see spurious timeouts. It would be Hence, the Q: uestion is: Are spurious timeouts a relevant problem? Or is this some kind of "network?s Nessie" ? > nice if a cell phone operator reading this list were to actually verify (or > contradict) this using real data traces. And I?m afraid, no one really would do so :-( Ideally, I would like to feed a real block-level trace of a network into a simulation to see what happens and to study the effect of different retransmission schemes on the latencies seen for IP packets. But I?m afraid, data like this will not be given to the public by NOs. (Contraditions by operators are mostly appreciated!) > > Opportunistic scheduling, will, I think, tend to exacerbate the differences > between 'good' and 'bad' channel state (caveat #6 above). However, the other > causes may yet cause spurious timeouts to be avoided. > Q: Is this done _below_ ARQ? If so (and I expect so), a properly chosen ARQ scheme could alleviate the effects of opportnistic scheduling. > I should add that I am not an expert in cell phone links, so my analysis > above is purely seat-of-the-pants, but its looks reasonable, at least to me. > My expertise on this one is even much less than yours ;-) So, I?m curious how much operators shake their heads when reading our discussion ;-) However, they are always welcome to enlighten us with the truth :-) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From tek at lucent.com Thu Sep 8 14:22:02 2005 From: tek at lucent.com (Thierry Klein) Date: Thu, 08 Sep 2005 17:22:02 -0400 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 5 In-Reply-To: <432048FD.D9F347F6@web.de> References: <432048FD.D9F347F6@web.de> Message-ID: <4320AB7A.8090703@lucent.com> >>They can _also_ be caused by opportunistic >>scheduling, used, for example, in EvDO, where a mobile with a good channel >>gets all the resources, causing delays for other mobiles. >> >> > > >O.k. At the moment, I have no "feeling" for the effects of opportunistic >scheduling. >However, it should not really matter. In general, I think, the NO will >adapt the number of time slots >used for a packet channel to the actual load due to line switching >traffic. This will result in a increase or decrease of bandwidth >depending on the load. > > We have investigated opportunistic scheduling and their impact on TCP and shown that scheduling can indeed cause spurious timeouts (in particular if the PF scheduling algorithm is considered). We have also proposed a modified scheduling algorithm to include the first and second moments of the inter-scheduling interval in the scheduling decision. These results have been published at Globecom 2004 in: T. Klein, K. Leung and H. Zheng, "Improved TCP performance in wireless IP networks through enhanced opportunistic scheduling algorithms", Globecom 2004, pp. 2744 - 2748. Thierry Klein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050908/efff0225/attachment.html From detlef.bosau at web.de Thu Sep 8 16:32:48 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 09 Sep 2005 01:32:48 +0200 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 5 References: <432048FD.D9F347F6@web.de> <4320AB7A.8090703@lucent.com> Message-ID: <4320CA20.CF4AD269@web.de> > Thierry Klein wrote: > > > > > > We have investigated opportunistic scheduling and their impact on TCP > and shown that scheduling can indeed cause spurious timeouts (in > particular if the PF scheduling algorithm is considered). We have also > proposed a modified scheduling algorithm to include the first and > second moments of the inter-scheduling interval in the scheduling > decision. Having not yet read your paper (I will do so as soon as possible, unfortunately I have not yet access to the paper), one question is: Should we really modify the _scheduling_? Basically, this is nothing specific to mobile wireless networks. Some ages ago (not to much, something in between :-)) "Multimedia over IP networks" was modern. (Admittedly, I?m not a multimedia guy.) When I implement QoS in packet switching networks, I will always have to obey my QoS contracts. And then I can put the rest on the network. First, QoS is served, best effort is left for the rest, or the rest is left for best effort. So, my first question is: Does changing the scheduling algorithm affect QoS traffic / voice traffic etc.? If so, this would hardly be accepted by cell phone users, as they pay their operator for making and receiving phone calls. However, basically I?m fixing my big picture. And at the moment, my big picture is: 1.: Spurious timeouts are not really an important issue. They are at least that rare that they cause no big harm. 2.: If they occur, there are knwon techniques to overcome them or to deal with them. You can use an approriate ARQ scheme which "spreads" delays about several packets, you can use PEP (I-TCP, Dumb Spoofing, ReSoA, whatever you prefer), you can use TCP/Eifel to alleviate the effects a posterirori, you can increase your RTO, perhaps you choose RTO=E+50*V in Jacobson?s algorithm, when you want to avoid unnecessary delay in necessary retransmissions, refer to RFC 3517 or RFC 3782. Some basic lesson I learned during the last few weeks, especially from Mark Allman is: 1. Timouts are a mess. Period. (This was written earlier by Lixia Zhang.) 2. If there is a mess, we should clean up. So, I will sharpen this somewhat: We can replace VJ?s algorithm by RTO = E + 100 * V + 5 minutes spare time and use the aformentioned RFC for loss detection. There are some cases, where this cannot be done or where this is somewhat unfortunate. I?m not ready with this. I still learn and try to understand. In theses cases, timeouts are a last ressort and thus are a necessary evil. At least, and I admit Mark Allman made me shake and tremble there, for me the question arose: What?s this whole RTO debate good for? For _me_ it?s good because I learn a lot. When I sometimes sharpen things, it?s perhaps my "nature", my way of thinking. However, my _basic_ intention at the moment is to understand things. And one thing, I?ve learned is that the timeout debate is basically closed and well understood. Perhaps, we can create scenarios where spurious timeouts occur. However, basically it?s not that worthwile. It?s however always a good idea to have a certain repertoire of approaches handy, if someone raises the "spurious timeout issue" in a discussion. However, when I return to my own initial question: "Is there a problem with TCP in mobile wireless networks?" I learned: If there is one, it?s certainly not (longer) the (spurious) timeout debate. Perhaps we can make some minor improvements there, but basically the issue is understood. So, I will fix my big picture and look for the next problem :-) Science is like a colouring book :-) You always look for pages which no one has painted before :-) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Fri Sep 9 06:09:02 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 09 Sep 2005 15:09:02 +0200 Subject: [e2e] Scheduling, was: Re: end2end-interest Digest, Vol 19, Issue 5 References: <432048FD.D9F347F6@web.de> <4320AB7A.8090703@lucent.com> <4320CA20.CF4AD269@web.de> Message-ID: <4321896E.F31AA76D@web.de> I?ve just seen that we talk about different concepts in "opportunistic scheduling". In a very first stage of PTE, I thought about the problem similar to that tackled by Thieryy (however not that formal) and that forgot about this for the moment. One problem tackled in Thierry?s paper is (please correct me if I?m wrong) the problem of different connection qualities. Of course, it?s a problem if a mobile with a bad connection usurps the whole channel for retransmissions whereas a mobile with a good channel get?s no time slots. >From a first glance, the PF algorithm (which is enhanced by Thierry) chooses a packet from a flow which achieved small throughput in the past whereas packets from flows with high throughput are postponed. This concept still resides totally in the "packet switching domain". What I had in mind was that mobile networks often combine packet switching and line switching. E.g. GPRS fully resides within the GSM technology and the GPRS packet channel(s, there are lots of channels there) are multiplexed with the voice channels. So, the time slot allocation must first satisfy the requirements for voice scheduling and afterwards packet channels may be sent. Voice is given priority over data. So, at the moment, I thought about "half a layer deepr" then Thierry. Just to say that. Otherwise a term like "scheduling conflict" would make no sense. What I was talking about was the problem to allocate a data channel cell in presence of voice traffic. However, I would be glad if someone could help me here, because I always have difficulties to understand the details of GSM etc., the multiplexing algorithms are horrible complex. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From nina.taft at intel.com Sun Sep 11 10:04:38 2005 From: nina.taft at intel.com (Taft, Nina) Date: Sun, 11 Sep 2005 10:04:38 -0700 Subject: [e2e] Internet Measurement Conference 2005 - Call For Pariticipation - New Venue Information Message-ID: Dear Colleagues, Due to the disaster caused by hurricane Katrina in New Orleans, we have decided to move the Internet Measurement Conference (IMC 2005) to Berkeley, California. Please note that we are NOT changing the dates of the conference which will still be October 19-21. Details on the new venue and cut-off dates are included below. Please register ASAP. (The Usenix website for IMC will be updated very shortly with the information below.) Internet Measurement Conference Sponsored by ACM SIGCOMM in cooperation with Usenix October 19-21, 2005 Berkeley, CA USA The fifth Internet Measurement Conference (IMC 2005) is a two and one-half day event focusing on Internet measurement and analysis. Join us for the latest research on Internet data analysis and its applications. The conference this year will cover a range of topics including security, P2P, wireless, monitoring, data reduction and other related topics. TECHNICAL PROGRAM To view the full technical program, please see: http://www.usenix.org/events/imc05/tech/ ACCOMODATIONS: The conference will be held in the Claremont Hotel in Berkeley, CA. This is a beautiful hotel nestled in the Berkeley Hills and located roughly 1.5 miles from the University of California at Berkeley campus. To receive the discount rate of $185/night for the conference you MUST book your room before September 26th. Please tell them you are with the Internet Measurement Conference to receive our bulk discount rate. After Sept. 26th rooms are not guaranteed and the rate will increase! So please book your reservation promptly. The hotel will be ready to start taking reservations on Monday Sept. 12th. For information on the hotel and how to make a reservation, please see: http://www.claremontresort.com/, or call them. Telephone: +1 800 551 7266 or +1 510 843 3000 Should you need alternate options for hotels, you can consider The Durant Hotel (http://www.hoteldurant.com/) or the Bancroft Hotel (http://www.bancrofthotel.com/). Please note that these are 1.5 miles from the Claremont, so we strongly encourage you to stay at the Claremont. REGISTRATION To register on-line, please go to: http://www.usenix.org/events/imc05/registration/ Please register for IMC no later than Oct. 7th, 2005. TRANSPORTION from airports to the Claremont Hotel The IMC official web page will be updated shortly with detailed information on how to get from the local airports to the hotel. In the meantime, please note that both San Francisco and Oakland International airports service the resort. The Oakland airport is closer and is located approximately 20-25 minutes from the Claremont. The San Francisco airport is a larger airport situated 45 minutes (driving time) away from the resort. Should you have any remaining questions, especially due to the change of venue, please feel free to contact any of the members of the IMC steering committee (emails below). We look forward to seeing you there, IMC Steering Committee, Nina Taft, nina.taft at intel.com Mark Crovella, crovella at cs.bu.edu Bala Krishnamurthy, bala at research.att.com Bruce Maggs, bmm at cs.cmu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050911/327863c2/attachment.html From detlef.bosau at web.de Tue Sep 13 03:53:46 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 13 Sep 2005 12:53:46 +0200 Subject: [e2e] Is there an implementation of TCP flow control in NS2? Message-ID: <4326AFBA.8480C6A@web.de> Please don?t wonder when I ask this here. I placed this question (dynamic AWND) yesterday into the ns-users list, after having subscribed to this list again after a break of about two years. I think, I?m going to unsubscribe again. The ns-users list is simply useless. One of the most important facts in using mailing lists is that after the third question like "Urgent!!!!!!!! I lost my shoes!!!!!!", "Urgent!!!!! Need help!!!!! I?m going to take an exam!!!! Help me!!!!!" Or "I cannot install the ns2, there are much of this funny files ending with .cc, what?s hat?", "Where is the ns2 documentation? There are much of that strange .h files, but they are apparently no _help_ files" etc. etc. etc., any user who has in fact an idea of what the ns2 is or what programming is all about will simply unsubscribe. In addition, it is simply not possible to follow this lare amount of mails there. Perhaps, one could think about a ns-users list with a better administration. At least questions like: "which linux must i install on my nt?" or "will nt work in mac when i install my ns in linux?" or similar should be made to disappear. It?s not only annoying but simply impossible to pick out that one useful post of the hundred posts each day that way. >From my own observation, I?ve seen that there are universities the students of which boast with large ns2 knowlege - however in fact, there is none. And there is a clear reason for this: There is no introduction into the ns2, no lectures, no ns2 users group etc. etc. at these universities. In nearly every village in Germany you have a Linux Users Group. I don?t know how this is in Stuttgart but in larger and more important villages like Markl/Inn or Oberammergau you surely find one ;-) So, if there is some guy having problems with Linux, he can ask there and will perhaps get assistance. In addition, one can arrange some kind of kknowledge transfer and education there. Please excuse me, when I?m upset on this one. The ns2 is a useful tool. It is very common and it?s, in general, a real good work. (It can be seen, however, that many programmers contributed to this work and that not all of them are equally skilled. But that?s life.) It would be a pity, when a useful and helpful program with many men years of work in it and much excellent knowledge therein will perhaps become less attractive in the long run, because there is no useful venue to discuss ns2 matters. >From what I?ve seen in this one single day, I?m about to suggest to close the ns-users list and to start a new discussion venue from scratch. I don?t believe that ns-users can be salvaged. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Tue Sep 13 09:19:13 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 13 Sep 2005 18:19:13 +0200 Subject: [e2e] Is there an implementation of TCP flow control in NS2? References: <4326AFBA.8480C6A@web.de> Message-ID: <4326FC01.5000206@web.de> Lloyd Wood wrote: > > But complaining about ns misses the point. You may as well complain I don?t complain about ns. Please don?t misunderstand me there. I only wanted to say that ns itself and it?s acceptance by the users as well as its benefit suffer from this situation. But this is not a problem due to ns. > about why universities don't teach you practical programming 'here's a That is more than what I said. However, I?m not willing to accept, that a CS student can graduate without a sound programing expertise. That?s exactly the same as if a surgeon could graduate without knowing to hold a knife. From my education and from my professional experience, I say that excellent programing skills are compulsory for any computer scientist. They are a "must". For a computer scientist a computer is what a knife is for a surgeon. > ten-year-old codebase and here's how to figure out how it works' In some commercial programs, the codebase is even older *sigh* ;-) (Unfortunately, I have no knowledge about COBOL, RPG and PL/1 and I don?t like FORTRAN IV very much :-)) > skills. Universities just expect you pick everything up by osmosis; Which is basically a good strategy. > hey, get students to spend enough time in a room with computers, and > maybe they'll learn to control them. The principle works with > libraries, books and reading, right? And it works the same way for programing. I once told a student, he should _READ_ programs. It was always helpful for me to _read_ programs. Not that stupid samples from textbooks. But reading large programs. And I even learned countless things and techniques from reading the ns2 source. Detlef From matta at cs.bu.edu Tue Sep 13 15:02:59 2005 From: matta at cs.bu.edu (Ibrahim Matta) Date: Tue, 13 Sep 2005 18:02:59 -0400 Subject: [e2e] IEEE ICNP 2005 Travel Award Programs Message-ID: <0511C607B17F804EBE96FFECD1FD98595459B4@cs-exs2.cs-nt.bu.edu> IEEE ICNP 2005, which is to be held in Boston (Nov 6 - Nov 9), is offering travel awards to encourage participation from constituents who otherwise are not able to attend the conference - namely graduate students who are not presenting papers at the conference, and faculty members belonging to (or at institutions serving) under-represented groups. The deadlines for application to these travel awards are fast approaching! If you are interested in either of these travel grant programs, please refer to the Web site of the conference at http://csr.bu.edu/icnp2005. Please feel free to spread the word... Best regards, Ibrahim From Jon.Crowcroft at cl.cam.ac.uk Tue Sep 13 23:41:27 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 14 Sep 2005 07:41:27 +0100 Subject: [e2e] Is sanity in NS2? In-Reply-To: Message from Lloyd Wood of "Tue, 13 Sep 2005 16:34:22 BST." Message-ID: Lloyd, this is so on the money in pretty much every comment that I really have to support it. The story of NS is as the story of IP, but sadly, not as the story of O. I think the open source/commons implication is part of the problem, but also the success disasster that NS became is partly because they made it too easy (analogous to socket programming) so anyone who could wield a bit of tcl or modify an existing bit of C++, thought they could build an interesting new simulation, and didnt have to acquire any disciple to do so - some people (typically hard put upon PhD students either strongly self motivated and sef-disciplined) managed to do some useful things, but an awful lot are those hotmail/yahoo email folks you allude to, (I have no idea where they are really from - are they using such addresses because they are afraid their university will catch them plagiarising, or are they blocked in china?) and they do more harm than good. anecdote - about 6-7 years ago we went through a lot of papers on tcp/aqm that had used ns (on the order of 100 papers) and tried to find the ns code to see if we could reproduce the results - around 50% of the papers appeared to be either bogus (when you got th code it didnt work with the alleged version of ns) or appeard to have graphs generated from a single run of ns (thre first one). quite a few were based o na (short lived) bug in the congestion control code in ns, (EPFL and others confirmed this bug - i cannot remember the exact detail, but it meant that the otcl and c++ variables weren't bound, so if you varied one, the other one didnt - this meant that the results for cwnd were basically random - papers were publised on this too). before ns, there was XSim, and real and the other descendants of the MIT simulator, which had a similar series of problems, although were sufficiently hard to use that most people ended up doing pretty much clean 100% rewrites of the relevant part of the code for their thesis work, and ended up i) understanding it ii) validating it iii) getting lots of meaningful results out iv) abandoning it completely upon graduating... Your comments about opnet also apply to matlab and other propietary and quite good (or very good, respectively) tools, that are supported so long as the relevant supervisrs ask for funds - they are relatively expensive for UK university budgets so are typically default-off - which is ludicrous really given the time it can save a student and supervisor and quality improvement in results.... we attempted to do an NS re-write in java (jns and jvs) which worked pretty well and several folks picked up on it, but exactly the same thing started to happen to us (at UCL) so I abandoned the program of work (though others picked up on it and it is on sourceforge i believe (not due to us) but i dont know how active it is - one specific thing that attempted to do was to make it "proper programming" to use the simulator, so the tecchnical bar was set a bit higher than just throwing some modified tcl at something and hoping... so trying to counter the point i made above by setting an implict "qualifying exam" to drive jns - but i think its evidence that at least in the case of educational software, open source may not be a good idea... supporting your point again. agree with your points on support mail lists etc too in fact i think this is the nearly first time i agree 100% with what you wrote! cheers jon p.s. another anecdote - the person who re-wrote pim at cisco did work on multicast in ns for his phd. yes, he found the same problems. so did others. i wish i'd told them to write their own simulator. mea culpa. In missive , Lloyd Wood typed: >>Detlef, >> >>There is an ns-developers list, with a much higher signal-to-noise >>ratio, and moderation of posts from non-subscribers by Tom Henderson. >>But that list is focused on fixing bugs in behaviour in ns (with a >>current emphasis from Lacage on rewriting the 802.11 code while making >>all other ns programmers look silly), rather than explaining observed >>behaviour of ns without reference to code. The pending move to >>sourceforge should make more lists and tools available. >> >>The contact link at the bottom of various ns webpages like e.g.: >>http://www.isi.edu/nsnam/ns/ >>is _still_ the ns-users list address, which is irresponsible, since it >>encourages questions without participation or knowledge of context of >>the list -- and the after-the-fact autofaq that gets mailed out >>doesn't seem to help. This can be considered an example of either open >>source trying to externalise its support costs, or the tragedy of the >>commons in action. >> >>These days, everybody is using ns, presumably because it's free, which >>arguably is of benefit towards students and their universities. (I >>wouldn't want to be a student trying to use Opnet and have the >>license expire because academics who don't use Opnet are bickering >>about which budget payment for the next year's license should come out >>of. Or be considering going part-time as a PhD student and realising >>you'd then being exposed to license and server access worries. Or >>discovering there's been an Opnet upgrade and the user interface has >>changed entirely. Again. In some very important respects, ns gives PhD >>students slightly more control over their destinies.) >> >>I spent a couple of years in the late 90s answering mail on the >>ns-users list; I was the first in my university to use ns, so got to >>grips with it very very slowly, while others who followed me got on >>far faster, since there was some local help for installation etc., and >>once over those hurdles they actually knew how to program. (as a >>strategy this worked -- I received enough help from others that I >>could figure out how to create some trivial solvable problems using >>ns, write them up, and graduate. But it's risky and not for everyone.) >> >>In answering questions on ns (while also asking unanswered questions >>more of the form 'these documented commands don't work and ns crashes! >>Why?' -- ns multicast is a complete trainwreck, PIM-SM never worked >>for me), I have now left myself open to years and years of questions >>from yahoo/hotmail-using students who have trouble stringing coherent >>sentences together. I imagine it's much the same for anyone else who >>has contributed to ns, and shudder to think how much mail e.g. Floyd >>or Heidemann must get on a daily basis. This discourages experienced >>participation in the ns-users mailing list; after graduation I >>realised I had to unsubscribe for my own sanity. >> >>Yes, a moderated ns-users list would be a good thing, but it would be >>a full-time job, and there's no ns-related charitable foundation. >>(Although sourceforge can accept paypal donations, so there could be a >>way of channelling money... hmmm. What's the business case? What's >>the selling point for donations?) >> >>But complaining about ns misses the point. You may as well complain >>about why universities don't teach you practical programming 'here's a >>ten-year-old codebase and here's how to figure out how it works' >>skills. Universities just expect you pick everything up by osmosis; >>hey, get students to spend enough time in a room with computers, and >>maybe they'll learn to control them. The principle works with >>libraries, books and reading, right? >> >>Universities are effectively trying to outsource their support >>costs, too, in an increasingly short-term world. >> >>L. >> >>recommends http://polaris.gseis.ucla.edu/pagre/network.html >> >> >>On Tue, 13 Sep 2005, Detlef Bosau wrote: >> >>> Please don=B4t wonder when I ask this here. >>> >>> I placed this question (dynamic AWND) yesterday into the ns-users list, >>> after having subscribed to this list again after a break of about two >>> years. >>> >>> I think, I=B4m going to unsubscribe again. The ns-users list is simply >>> useless. One of the most important facts in using mailing lists is that >>> after the third question like "Urgent!!!!!!!! I lost my shoes!!!!!!", >>> "Urgent!!!!! Need help!!!!! I=B4m going to take an exam!!!! Help me!!!!= >>!" >>> Or "I cannot install the ns2, there are much of this funny files ending >>> with .cc, what=B4s hat?", "Where is the ns2 documentation? There are mu= >>ch >>> of that strange .h files, but they are apparently no _help_ files" etc. >>> etc. etc., any user who has in fact an idea of what the ns2 is or what >>> programming is all about will simply unsubscribe. In addition, it is >>> simply not possible to follow this lare amount of mails there. >>> >>> Perhaps, one could think about a ns-users list with a better >>> administration. At least questions like: "which linux must i install >>> on my nt?" or "will nt work in mac when i install my ns in linux?" >>> or similar should be made to disappear. It=B4s not only annoying but >>> simply impossible to pick out that one useful post of the hundred >>> posts each day that way. >>> >>> >From my own observation, I=B4ve seen that there are universities the >>> students of which boast with large ns2 knowlege - however in fact, ther= >>e >>> is none. >>> And there is a clear reason for this: There is no introduction into the >>> ns2, no lectures, no ns2 users group etc. etc. at these universities. >>> >>> In nearly every village in Germany you have a Linux Users Group. >>> >>> I don=B4t know how this is in Stuttgart but in larger and more importan= >>t >>> villages like Markl/Inn or Oberammergau you surely find one ;-) >>> >>> So, if there is some guy having problems with Linux, he can ask there >>> and will perhaps get assistance. In addition, one can arrange some kind >>> of kknowledge transfer and education there. >>> >>> Please excuse me, when I=B4m upset on this one. The ns2 is a useful too= >>l. >>> It is very common and it=B4s, in general, a real good work. >>> (It can be seen, however, that many programmers contributed to this wor= >>k >>> and that not all of them are equally skilled. But that=B4s >>> life.) It would be a pity, when a useful and helpful program with many >>> men years of work in it and much excellent knowledge therein >>> will perhaps become less attractive in the long run, because there is n= >>o >>> useful venue to discuss ns2 matters. >>> >>> >From what I=B4ve seen in this one single day, I=B4m about to suggest t= >>o >>> close the ns-users list and to start a new discussion venue from >>> scratch. >>> I don=B4t believe that ns-users can be salvaged. >>> >>> Detlef >>> >>> -- >>> Detlef Bosau >>> Galileistrasse 30 >>> 70565 Stuttgart >>> Mail: detlef.bosau at web.de >>> Web: http://www.detlef-bosau.de >>> Mobile: +49 172 681 9937 >> >> cheers jon From detlef.bosau at web.de Wed Sep 14 06:52:13 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 14 Sep 2005 15:52:13 +0200 Subject: [e2e] Is sanity in NS2? References: Message-ID: <43282B0D.9010303@web.de> May I first, once again, refer to the quote on Wesley Eddy?s Homepage: "Mathematicians stand on each other's shoulders while computer scientists stand on each other's toes." -- R. W. Hamming Jon Crowcroft wrote: > I think the open source/commons implication is part of the problem, but also > the success disasster that NS became is partly because they made it too easy > (analogous to socket programming) > so anyone who could wield a bit of tcl or modify an existing bit of C++, > thought they could build an interesting new simulation, and didnt have to acquire > any disciple to do so - some people (typically hard put upon PhD students either > strongly self motivated and sef-disciplined) managed to do some useful things, but > an awful lot are those hotmail/yahoo email folks you allude to, > (I have no idea where they are really from - are they using such > addresses because they are afraid their university will catch them plagiarising, > or are they blocked in china?) and they do more harm than good. It?s a difficult issue. First of all: I don?t think that something must be complicated in order to be good. I don?t believe in the "Quality by obscuracy" principle. (I must admit: I never submitted something to the IOCCC.) I?m a strong believer of clarity. Unfortunately, the clarity of the NS code is somewhat different in different parts of the NS. Concerning my own NS code: This mostly consists of evil hacks, as I?m a bad programer. If someone wants to have a look at it (at his own risk of course and I take no responsiblity for any consequences such as brain damage, loss of any kind of programming expertise etc.) he can have a look at my homepage: http://www.detlef-bosau.de/ns-2.26-cvs.2005.03.15.tgz It?s not documented in any way. Don?t look for PTE. It?s not that I?m not interested in PTE anly longer. It?s because much of the ideas came to me when my chair got broken and so, I had to go to the IKEA furniture shop (is this correct? I did not find it in my dictionary.) to buy a new one. Therefore, it?s called "ikea". However, I could not use this name for copyright reasons, so I renamed my approach to "Path Tail Emulation". Basically, open source programs may work fine. Take Linux as an example. However, contributing to a large program requires knowledge and self disciipline. (I lack both of it....) Particularly for the NS, it requires a very deep and very broad knowledge of programming techniques. And I?ld better not talk about my first steps into the NS2 world. You would roll on the floor laughing. The problem was: There was no one to teach me. So, basically I believe into open software and open source programs. However, this requires two necessary things: 1.: An excellent maintenance of the program. I think, Linux Torvalds, Lars Wirzenius etc. spent at least that much time for maintenance and code integration than all contributors together spend in programming. (It?s a guess, I did not talk to one of them two.) 2.: An excellent programming education. That?s a matter of course for computer scientists. And if there is any school with a different attitude, it?s clear what must change there. A computer scientist is bascially an engineer, the computer is his engine and programming is his hammer and his screwdriver. Of course, some programmers are more gifted than others. However, a computer scientist is an _excellent_ programmer anyway - or he is no computer scientist. > > anecdote - about 6-7 years ago we went through a lot of papers on tcp/aqm that > had used ns (on the order of 100 papers) and tried to find the ns code to see if > we could reproduce the results - around 50% of the papers appeared to be either bogus (when you > got th code it didnt work with the alleged version of ns) or appeard to have graphs generated > from a single run of ns (thre first one). quite a few were based o na (short lived) bug in the > congestion control code in ns, (EPFL and others confirmed this bug - i cannot remember the exact detail, > but it meant that the otcl and c++ variables weren't bound, so if you varied one, the other one didnt - > this meant that the results for cwnd were basically random - papers were publised on this too). > The _serious_ issue behind this anecdote is: Who has ever validated NS2 code? How much papers are based upon "irreproducible simulations"? In consequence, I think: Simulation proves anything and nothing. It?s basically what Keshav mentions on his homepage. It?s the _rationale_ that must be convincing. Not one simulation. Simulation results may result from a "lucky choice" in your scenario or from sum "lucky bugs". You might kill me for that example. But when I think of the TCP-AP approach, Mobihoc 2005, ElRakabawy, Klemm, Lindemann, I simply don?t buy it. I contacted the authors and asked for the rationale of this apporach. I don?t got one. The authors refered to the simulations. First: I don?t have the source. Second: I don?t have the time to analyze each simulation artefact. This paper "proves" its approach with "a pletora" (i.e. two) scenarios and no rationale. I don?t understand, why this paper was accepted. It?s an embarrassment for the whole community. I conducted a similar approach years ago - and I had to learn it was wrong. It was a bitter lesson. You can imagine my aggravation. > before ns, there was XSim, and real and the other descendants of the MIT simulator, which had a similar series of > problems, although were sufficiently hard to use that most people ended up doing pretty much clean 100% > rewrites of the relevant part of the code for their thesis work, and ended up > i) understanding it > ii) validating it > iii) getting lots of meaningful results out > iv) abandoning it completely upon graduating... The pity is iv. That?s why I wrote the qote above. It?s hardly possible to reinvent the wheel each time you do a research. And it?s a validation matter. Why did I ask for AWND and flow control? Because I want to compare my own PTE approach with a "dumb spoofing approach" (look at Mark Allman?s work on that one). It?s basically no problem to introduce a "dynamic AWND" into the NS2. It?s the problem to have the TCP sender react properly particularly on zero windows. In addition, a split gateway or a PEP using PTE has to obey some rules for the proper definition of the AWND. It?s not that I don?t want to do this myself (although I would be glad to use existing code here) or that I was not able to do this myself. Of couse I?m able to. It?s a matter of validation. And I?m afraid that a submitted paper would be rejected, because the reveiwer simply does not believe me or the scenario is not "complex" enough or whatever excuse is used. To be honest: I?m still not sure, wheter I will use a simulation in a paper. > > > Your comments about opnet also apply to matlab and other propietary and quite good (or very good, respectively) > tools, that are supported so long as the relevant supervisrs ask for funds - they are relatively expensive for The problem with proprietary code is that I cannot validate it. I cannot read the code. I have to "believe" it. > UK university budgets so are typically default-off - which is ludicrous really given the time it can save a student > and supervisor and quality improvement in results.... > > we attempted to do an NS re-write in java (jns and jvs) which worked pretty well and several folks picked up on it, > but exactly the same thing started to happen to us (at UCL) so I abandoned the program of work (though others > picked up on it and it is on sourceforge i believe (not due to us) but i dont know how active it is - > > one specific thing that attempted to do was to make it "proper programming" to use the simulator, > so the tecchnical bar was set a bit higher than just throwing some modified tcl at something and hoping... I basically don?t believe that making thinks more complicated would be more helpful. In my opinion, the main issue is discipline and proper maintenance. Particularly, it?s a bad idea to ad arbitrary "contributors" on the NS2 homepage without any consideration if 1. the contributed code is _relevant_, 2. the contributed code is _correct_, 3. the contributed code conforms to certain standards which consider the quality of code as well as some style rules. AFAIK, in commercial companies you have programmes who _intergrate_ contributed code. Who rework the programming style, who care for proper documentation etc. > so trying to counter the point i made above by setting an implict "qualifying exam" to drive jns - Nice idea! > but i think its evidence that at least in the case of educational software, open source may not be a good idea... > supporting your point again. > At least for me, I?m an unemployed person, there is no alternative to open source software. > agree with your points on support mail lists etc too > > in fact i think this is the nearly first time i agree 100% with what you wrote! We all are happy for both of you :-) Refering to Hamming once again: Feel perfectly free to continue to do so :-) (And yes, someone told me that a book on the NS2 would be helpful.... However, at the moment I don?t dare to start a project like this. First, I don?t know wheter I?m able to do so. Second, there are other things more important, e.g. to find a job in Germany at the age of 42. Perhaps, I should apply as a test person for coffins. However, this is not adequate for a person interested in packet switching, as undertakers usually prefer to do line switching.) (And please, don?t sent me comments on my programming style. I know, if I ever wrote a book on the NS2, I would look for a co-author who is a gifted programmer....) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From mallman at icir.org Wed Sep 14 07:17:06 2005 From: mallman at icir.org (Mark Allman) Date: Wed, 14 Sep 2005 10:17:06 -0400 Subject: [e2e] Is sanity in NS2? In-Reply-To: <43282B0D.9010303@web.de> Message-ID: <20050914141706.9E62F77A720@guns.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20050914/396bd555/attachment-0001.ksh -------------- 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/20050914/396bd555/attachment-0001.bin From Jon.Crowcroft at cl.cam.ac.uk Wed Sep 14 07:30:11 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 14 Sep 2005 15:30:11 +0100 Subject: [e2e] google-to-google Message-ID: So google are buying dark fiber. why? There can only be one reason: google will stop searching the web, and then indexing it. They will host all the web on their machines (plenty of space). (see article in the excellent technical trade press journal the onion). So whats the dark fiber for? Well you link up all the google clusters directly - no routers, just a full mesh between google.countrycode Now, if it was me, I would go one step further. A well known result from Physics #101 is that if you drop a ball down a frictionless straightline tunnel between any two points on the surface of a ball, it will take the same time to traverse and just come to a stop at the other side. For an object of the radius and mass of Earth, this is around 56 minutes. So we connect all the google clusters on the earth by straightline tunnels and provide a _transport_ service between these points (both undermining airlines, trains, but not short hall journeys, but certainyl solving global warming largely). You then run fiber, or even line of sight laser links down these tunnels too, giving minium RTT (and still no routers, no DWDM switches, multiplexors or whatever). You can run quantum crypto on these links easily too and the key distribution problem goes away. (although thinking about it, wiretap/lawful intercept at the center of the earth is probably outside Bush's jurisdiction, (and certainly outsde his technical jurisprudence). So there it is - TJ Watson was right. One computer. No wires. no routers. complete fault tolerance/resilience. cheap, secure, and entertaining. (oh and with the google talk, blog, gmail etc, no phone or tv networks either). one problem - if there are too many end points, we need to put the earth from all those holes somewhere, so google needs to buy some space research outfit (how much is the European Space Agency or Chinese or russians compared with Nasa or Northrop, these days?). no wait, one more optimisation: put the google systems at the _center_ rather than round the edges - halves the RTT. and probably could survive an asteroid impact properly then too. hmm, could we implement a turing machine in the currents in the earth's iron core? hmmm...very long term research project (eat your heart out Geni ... wait, there's a bug - if we dig out all the earth, then send it into orbit, the mass alters, and the transit time thru the tunnels goes up.....oh but it can't be that much...quick back of envelope calculation, no its ok...phew. j. From detlef.bosau at web.de Wed Sep 14 07:59:44 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 14 Sep 2005 16:59:44 +0200 Subject: [e2e] Is sanity in NS2? References: Message-ID: <43283AE0.550595CE@web.de> Jon Crowcroft wrote: > > i dont think i disagree with 98% of what you say... > Encouraging. > In missive <43282B0D.9010303 at web.de>, Detlef Bosau typed: > > >>The problem with proprietary code is that I cannot validate it. I cannot > >> read the code. I have to "believe" it. > > you can validate a simulation. > you dont have to have the code - Although this is correct in theory, it is quite difficult to do practically. The best, and basically the only _real_, validation is to compare simulation results with reality. If you can?t do this, e.g. because you don?t have a network which is large enough or you have no UMTS testbed or whatever, you have to rely upon simulations. It?s an excuse. Of course. Most simulations are an excuse. And mostly, they are a _weak_ excuse. (I got a paper rejected because the reviewer wanted to see an implementation, not a simulation. And in commercial business, no one is interested in simulations. I have seen this myself. When there is a database system to be sold and this has to work with 1.000 clients in parallel, there _are_ companies who simply say: You want to sell me your system? Go ahead! Make a demonstration with 1.000 clients and then we can continue the discussion. And I perfectly understand this attitude.) > > > >>I basically don't believe that making thinks more complicated would be = > >>more helpful. > > I am not suggesting making it more complex - i am suggesting that > there is a level of competence that in systems that require > programming rather than script hacking, is more in evidence. > Working with the NS2 _requires_ programming. When you work with protocols in the NS2, most of the work is done in the .cc Code. I don?t know anything about the history of NS2, so I can only guess why Tcl was ever used here. However, I have a quite old PC who tells me the story well: When I rebuild the system, even the _link_ run takes about half an hour. Therefore I guess, Tcl was used to have a means to plumb NS2 components together without having to compile parts of the system and toing a link run afterwards. Today, one could argue that one could drop the whole Tcl/OTcl/TclCl part of the NS2 and rewrite it totally in C++ or Java. (Basically, I prefer C++ , but this is a matter of taste.) At least, the whole program would becomae much more clear then. Basically, the NS2 is a framework, a set of components with which you can model networks. And basically, it does not really matter whether these components are glued together in Tcl or in C++. Pure C++ would be clear and easy to understand. I guess, Tcl was only used to spare compliation time and link time. (This is however a guess of mine, perhaps someone could add _knowledge_ here.) The problem with unbound variables you mentioned is simply a consequence of this Tcl/C++ interaction which eventually becomes quite cumbersome to understand. And simply spoken: It?s not really necessary today. Howver, we could agree here in that respect that even to write a main.cc and to run a compiler would deter those guys who simply plumb together a short Tcl spript by copy?n paste and think that this is "working with the NS2". Although a main program in C++ would not necessarily be more complex or longer than one in Tcl. > >>In my opinion, the main issue is discipline and proper maintenance. > > I agree (and lloyd made this point too ) - the open source communities > that are succesful and continuing in quality have moderation. > > what would be nice is if papers submitted using open source, submitted > the code for audit AS WELL, before the paper could be accepted. (and I agree here. Altghouh I don?t know how this can be done practically. It?s an interesting thought to submit a paper double blind, e.g. for Mobicom, and to write: I must not tell you my name, but the programs used for this paper can be found at www.detlef-bosau.de/..... Perhaps, my provider can offer me a pseudoynm.... The more important problem is, that a reviewer must be willing and able to _read_ this code. Basically, this would require some competence for the reviewer as well. > before the code could be rolled into a distribution) - only if both > paper and code are ok, is either paper or code accepted. This is a good idea. I?m waiting for the first conference to do so. > in the medical world when papers on clinical trials are submitted the > clinical trial itself (and data) are audited. this is a Good Thing. In theory. And if done practically, this is also true. However, there are often "somwhat unfortunate exceptions from the rule" here.... As I said: It?s somewhat unfortunate. > > the other stuff people do with NS should be kept in the classroom > imho > > btw, i've given up coding- i find it too painful on my hands. It may be painful on your hands. However, for me: Do I have an alternative? And, you might disagree here as well but I can live with that: Only a programmer can read programs. No violinist, no pianist ever stopped playing when he started teaching. Perhaps, elder singers will not perform in the Opera in public, when they get older and it?s simply to strenous for a singer at age 83 to give a public concert. However, they all do not stop playing or stop singing. I did not learn Java during my education. How should I ever review a Java program without ever having written one myself? I couldn?t. I could make some quotes from some textbooks, but I would not have the least idea, what Java is all about. When I shall review programs written in Java, I must _write_ programs in Java. When I shall value programs, I must _write_ programs. Would you practice piano playing with a supervisor who always says: "Oh, when I remember the good old days, where I played the piano myself, it was, let me think, in the 1930s or so..."? I don?t think so. You would escape and look for a new teacher. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From fanye at us.ibm.com Wed Sep 14 08:08:16 2005 From: fanye at us.ibm.com (Fan Ye) Date: Wed, 14 Sep 2005 11:08:16 -0400 Subject: [e2e] (no subject) Message-ID: Jon, This is the first time I ever post on e2e list, although I've subscribed to it several years. I'm really astonished to see your technical discussion on ns drifting, or "accidentally dropping", onto some language attacking an ethnic group (see below quoted text). You may not have the intention, but what you wrote seems to imply that all these guys are clueless chinese students who dont know a better way to plagiarize. > (I have no idea where they are really from - are they using such > addresses because they are afraid their university will catch them > plagiarising, ^^^^^^^^^^^^^^^^ > or are they blocked in china?) and they do more harm than good. ^^^^^^ I'm very, very upset to see this kind of language, not to mention at a least expected place, a technical discussion list. I have little clue about why these people use hotmail or yahoo address either. My guess (from my own, limited experience 6+ years ago), is that many schools in china simply do not provide an email address to every student, or the habit of Internet users in china differs from here a lot, people (including graduate students) simply use one email address for everything, they consider this a convenience. I've got emails from such students as well, and they asked valid, technical questions. I didnt have the chance to check out their publication, but I would have a hard time to believe they are just poor plagiarizers without a better means to conceal identity. To check the validity of your claim that these guys (at least most) are from china, I did a quick sampling on ns-users 2005 Aug archieve. At the end is a sorted list of those who used yahoo addresses. Of these 31 guys, only 4 have chinese names. I can reasonably say that nearly 90% of them are NOT from china. So how did you find out 1) they're plagiarizing 2) they're from china? Fan __________________________________________________________________ From: aashaikh_pk at yahoo.com (ayaz shaikh) From: aashaikh_pk at yahoo.com (ayaz shaikh) From: ahmedbelhoul2 at yahoo.com (Ahmed Belhoul) From: alexandreadames at yahoo.com.br (=?iso-8859-1?q?Alexandre=20=FFffffc1dames=20Alves=20Pontes?=) From: alexandreadames at yahoo.com.br (=?iso-8859-1?q?Alexandre=20=FFffffc1dames=20Alves=20Pontes?=) From: altaf8031 at yahoo.com (altaf hussain) From: altaf8031 at yahoo.com (Altaf Hussain) From: anrew791 at yahoo.com (andrew lloyd) From: anrew791 at yahoo.com (andrew lloyd) From: anrew791 at yahoo.com (andrew lloyd) From: anrew791 at yahoo.com (andrew lloyd) From: anrew791 at yahoo.com (andrew lloyd) From: bijuissac at yahoo.com (Biju Issac) From: bijuissac at yahoo.com (Biju Issac) From: born2bewild200 at yahoo.com (Just Me) From: busybee032002 at yahoo.com (sarah Guo) From: coolns2 at yahoo.com (cherie) From: coolns2 at yahoo.com (cherie) From: ebenezer_a at yahoo.com (Ebenezer) From: ehsan_ataie59 at yahoo.com (Ehsan Ataie) From: ess_hs at yahoo.com (essam abuosamra) From: ess_hs at yahoo.com (essam abuosamra) From: gasyed2003 at yahoo.com (Ghalib Asadullah) From: jagadish_kranti at yahoo.com (jagadish kranti) From: jn_lavina at yahoo.com (Lavina Jain) From: joysmilelol at yahoo.com (joy smilelol) From: joysmilelol at yahoo.com (joy smilelol) From: joysmilelol at yahoo.com (joy smilelol) From: joysmilelol at yahoo.com (joy smilelol) From: mansoor_jafry at yahoo.com (mansoor) From: milismrc at yahoo.com (Marico DS) From: mrhuangzhihong at yahoo.com.cn (=?gb2312?q?=D6=B2=BA=EA=20=BB=C6?=) From: nazir_fawad at yahoo.com (Fawad Nazir) From: nazir_fawad at yahoo.com (Fawad Nazir) From: nazir_fawad at yahoo.com (Fawad Nazir) From: nazir_fawad at yahoo.com (Fawad Nazir) From: nazir_fawad at yahoo.com (Fawad Nazir) From: nittingarg_iiitmg at yahoo.com (nittin garg) From: rajagopal_452 at yahoo.com (Raja Sombhotla) From: rana_aa at yahoo.com (rana abu nafisa) From: raneem31 at yahoo.com (Rana) From: raneem31 at yahoo.com (Rana Alhalimi) From: reddymythili29 at yahoo.com (enugala mythili) From: romdoul2002 at yahoo.com (TAING Nguon) From: sheng_jin2003 at yahoo.com.cn (Sheng Jin) From: shicheng969 at yahoo.com.cn (shicheng) From: sumanth_smiles at yahoo.com (Sumanth Sarma, Hallegiri) From: zarkonovicic at yahoo.com (zarko novicic) From: zillurcse at yahoo.com (zillur rahman) From: zillurcse at yahoo.com (zillur rahman) end2end-interest-bounces at postel.org wrote on 09/14/2005 02:41:27 AM: > Lloyd, > > this is so on the money in pretty much every comment that I really > have to support it. > > The story of NS is as > the story of IP, but sadly, not as > the story of O. > > I think the open source/commons implication is part of the problem, but also > the success disasster that NS became is partly because they made it too easy > (analogous to socket programming) > so anyone who could wield a bit of tcl or modify an existing bit of C++, > thought they could build an interesting new simulation, and didnt > have to acquire > any disciple to do so - some people (typically hard put upon PhD > students either > strongly self motivated and sef-disciplined) managed to do some > useful things, but > an awful lot are those hotmail/yahoo email folks you allude to, > (I have no idea where they are really from - are they using such > addresses because they are afraid their university will catch them > plagiarising, > or are they blocked in china?) and they do more harm than good. > > anecdote - about 6-7 years ago we went through a lot of papers on tcp/aqm that > had used ns (on the order of 100 papers) and tried to find the ns > code to see if > we could reproduce the results - around 50% of the papers appeared > to be either bogus (when you > got th code it didnt work with the alleged version of ns) or appeard > to have graphs generated > from a single run of ns (thre first one). quite a few were based o > na (short lived) bug in the > congestion control code in ns, (EPFL and others confirmed this bug - > i cannot remember the exact detail, > but it meant that the otcl and c++ variables weren't bound, so if > you varied one, the other one didnt - > this meant that the results for cwnd were basically random - papers > were publised on this too). > > before ns, there was XSim, and real and the other descendants of the > MIT simulator, which had a similar series of > problems, although were sufficiently hard to use that most people > ended up doing pretty much clean 100% > rewrites of the relevant part of the code for their thesis work, and ended up > i) understanding it > ii) validating it > iii) getting lots of meaningful results out > iv) abandoning it completely upon graduating... > > > Your comments about opnet also apply to matlab and other propietary > and quite good (or very good, respectively) > tools, that are supported so long as the relevant supervisrs ask for > funds - they are relatively expensive for > UK university budgets so are typically default-off - which is > ludicrous really given the time it can save a student > and supervisor and quality improvement in results.... > > we attempted to do an NS re-write in java (jns and jvs) which worked > pretty well and several folks picked up on it, > but exactly the same thing started to happen to us (at UCL) so I > abandoned the program of work (though others > picked up on it and it is on sourceforge i believe (not due to us) > but i dont know how active it is - > > one specific thing that attempted to do was to make it "proper > programming" to use the simulator, > so the tecchnical bar was set a bit higher than just throwing some > modified tcl at something and hoping... > so trying to counter the point i made above by setting an implict > "qualifying exam" to drive jns - > but i think its evidence that at least in the case of educational > software, open source may not be a good idea... > supporting your point again. > > agree with your points on support mail lists etc too > > in fact i think this is the nearly first time i agree 100% with > what you wrote! > > cheers > jon > p.s. another anecdote - the person who re-wrote pim at cisco did > work on multicast in ns for his phd. > yes, he found the same problems. so did others. i wish i'd told them > to write their own simulator. > mea culpa. > > > > In missive ac.uk>, Lloyd Wood typed: > > >>Detlef, > >> > >>There is an ns-developers list, with a much higher signal-to-noise > >>ratio, and moderation of posts from non-subscribers by Tom Henderson. > >>But that list is focused on fixing bugs in behaviour in ns (with a > >>current emphasis from Lacage on rewriting the 802.11 code while making > >>all other ns programmers look silly), rather than explaining observed > >>behaviour of ns without reference to code. The pending move to > >>sourceforge should make more lists and tools available. > >> > >>The contact link at the bottom of various ns webpages like e.g.: > >>http://www.isi.edu/nsnam/ns/ > >>is _still_ the ns-users list address, which is irresponsible, since it > >>encourages questions without participation or knowledge of context of > >>the list -- and the after-the-fact autofaq that gets mailed out > >>doesn't seem to help. This can be considered an example of either open > >>source trying to externalise its support costs, or the tragedy of the > >>commons in action. > >> > >>These days, everybody is using ns, presumably because it's free, which > >>arguably is of benefit towards students and their universities. (I > >>wouldn't want to be a student trying to use Opnet and have the > >>license expire because academics who don't use Opnet are bickering > >>about which budget payment for the next year's license should come out > >>of. Or be considering going part-time as a PhD student and realising > >>you'd then being exposed to license and server access worries. Or > >>discovering there's been an Opnet upgrade and the user interface has > >>changed entirely. Again. In some very important respects, ns gives PhD > >>students slightly more control over their destinies.) > >> > >>I spent a couple of years in the late 90s answering mail on the > >>ns-users list; I was the first in my university to use ns, so got to > >>grips with it very very slowly, while others who followed me got on > >>far faster, since there was some local help for installation etc., and > >>once over those hurdles they actually knew how to program. (as a > >>strategy this worked -- I received enough help from others that I > >>could figure out how to create some trivial solvable problems using > >>ns, write them up, and graduate. But it's risky and not for everyone.) > >> > >>In answering questions on ns (while also asking unanswered questions > >>more of the form 'these documented commands don't work and ns crashes! > >>Why?' -- ns multicast is a complete trainwreck, PIM-SM never worked > >>for me), I have now left myself open to years and years of questions > >>from yahoo/hotmail-using students who have trouble stringing coherent > >>sentences together. I imagine it's much the same for anyone else who > >>has contributed to ns, and shudder to think how much mail e.g. Floyd > >>or Heidemann must get on a daily basis. This discourages experienced > >>participation in the ns-users mailing list; after graduation I > >>realised I had to unsubscribe for my own sanity. > >> > >>Yes, a moderated ns-users list would be a good thing, but it would be > >>a full-time job, and there's no ns-related charitable foundation. > >>(Although sourceforge can accept paypal donations, so there could be a > >>way of channelling money... hmmm. What's the business case? What's > >>the selling point for donations?) > >> > >>But complaining about ns misses the point. You may as well complain > >>about why universities don't teach you practical programming 'here's a > >>ten-year-old codebase and here's how to figure out how it works' > >>skills. Universities just expect you pick everything up by osmosis; > >>hey, get students to spend enough time in a room with computers, and > >>maybe they'll learn to control them. The principle works with > >>libraries, books and reading, right? > >> > >>Universities are effectively trying to outsource their support > >>costs, too, in an increasingly short-term world. > >> > >>L. > >> > >>recommends http://polaris.gseis.ucla.edu/pagre/network.html > >> > >> > >>On Tue, 13 Sep 2005, Detlef Bosau wrote: > >> > >>> Please don=B4t wonder when I ask this here. > >>> > >>> I placed this question (dynamic AWND) yesterday into the ns-users list, > >>> after having subscribed to this list again after a break of about two > >>> years. > >>> > >>> I think, I=B4m going to unsubscribe again. The ns-users list is simply > >>> useless. One of the most important facts in using mailing lists is that > >>> after the third question like "Urgent!!!!!!!! I lost my shoes!!!!!!", > >>> "Urgent!!!!! Need help!!!!! I=B4m going to take an exam!!!! Help me!!!!= > >>!" > >>> Or "I cannot install the ns2, there are much of this funny files ending > >>> with .cc, what=B4s hat?", "Where is the ns2 documentation? There are mu= > >>ch > >>> of that strange .h files, but they are apparently no _help_ files" etc. > >>> etc. etc., any user who has in fact an idea of what the ns2 is or what > >>> programming is all about will simply unsubscribe. In addition, it is > >>> simply not possible to follow this lare amount of mails there. > >>> > >>> Perhaps, one could think about a ns-users list with a better > >>> administration. At least questions like: "which linux must i install > >>> on my nt?" or "will nt work in mac when i install my ns in linux?" > >>> or similar should be made to disappear. It=B4s not only annoying but > >>> simply impossible to pick out that one useful post of the hundred > >>> posts each day that way. > >>> > >>> >From my own observation, I=B4ve seen that there are universities the > >>> students of which boast with large ns2 knowlege - however in fact, ther= > >>e > >>> is none. > >>> And there is a clear reason for this: There is no introduction into the > >>> ns2, no lectures, no ns2 users group etc. etc. at these universities. > >>> > >>> In nearly every village in Germany you have a Linux Users Group. > >>> > >>> I don=B4t know how this is in Stuttgart but in larger and more importan= > >>t > >>> villages like Markl/Inn or Oberammergau you surely find one ;-) > >>> > >>> So, if there is some guy having problems with Linux, he can ask there > >>> and will perhaps get assistance. In addition, one can arrange some kind > >>> of kknowledge transfer and education there. > >>> > >>> Please excuse me, when I=B4m upset on this one. The ns2 is a useful too= > >>l. > >>> It is very common and it=B4s, in general, a real good work. > >>> (It can be seen, however, that many programmers contributed to this wor= > >>k > >>> and that not all of them are equally skilled. But that=B4s > >>> life.) It would be a pity, when a useful and helpful program with many > >>> men years of work in it and much excellent knowledge therein > >>> will perhaps become less attractive in the long run, because there is n= > >>o > >>> useful venue to discuss ns2 matters. > >>> > >>> >From what I=B4ve seen in this one single day, I=B4m about to suggest t= > >>o > >>> close the ns-users list and to start a new discussion venue from > >>> scratch. > >>> I don=B4t believe that ns-users can be salvaged. > >>> > >>> Detlef > >>> > >>> -- > >>> Detlef Bosau > >>> Galileistrasse 30 > >>> 70565 Stuttgart > >>> Mail: detlef.bosau at web.de > >>> Web: http://www.detlef-bosau.de > >>> Mobile: +49 172 681 9937 > >> > >> > > cheers > > jon > From Jon.Crowcroft at cl.cam.ac.uk Wed Sep 14 06:56:00 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 14 Sep 2005 14:56:00 +0100 Subject: [e2e] Is sanity in NS2? In-Reply-To: Message from Detlef Bosau of "Wed, 14 Sep 2005 15:52:13 +0200." <43282B0D.9010303@web.de> Message-ID: i dont think i disagree with 98% of what you say... In missive <43282B0D.9010303 at web.de>, Detlef Bosau typed: >>The problem with proprietary code is that I cannot validate it. I cannot >> read the code. I have to "believe" it. you can validate a simulation. you dont have to have the code - >>I basically don't believe that making thinks more complicated would be = >>more helpful. I am not suggesting making it more complex - i am suggesting that there is a level of competence that in systems that require programming rather than script hacking, is more in evidence. >>In my opinion, the main issue is discipline and proper maintenance. I agree (and lloyd made this point too ) - the open source communities that are succesful and continuing in quality have moderation. what would be nice is if papers submitted using open source, submitted the code for audit AS WELL, before the paper could be accepted. (and before the code could be rolled into a distribution) - only if both paper and code are ok, is either paper or code accepted. in the medical world when papers on clinical trials are submitted the clinical trial itself (and data) are audited. this is a Good Thing. the other stuff people do with NS should be kept in the classroom imho btw, i've given up coding- i find it too painful on my hands. j. From keshav at uwaterloo.ca Wed Sep 14 08:27:49 2005 From: keshav at uwaterloo.ca (S. Keshav) Date: Wed, 14 Sep 2005 11:27:49 -0400 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: Message-ID: Detlef, Since you mentioned my web site, I will save others the effort in wading through it to post the single relevant sentence: "The goal of simulation is intuition, not numbers," R.W. Hamming. I was taught this by Sam Morgan at Bell Labs, who heard it from the horse's mouth. In terms of simulator validation, I can tell you how I validated REAL when I first wrote it in 1988 (BTW, this was not my idea: I was only carrying out Scott Shenker's instructions): I wrote the same simulation using two packages -- CSIM and NEST (which eventually became REAL). Then, I compared every packet transmission and reception at the time granularity of one microsecond. If there was a difference, I found and fixed any bugs. This allowed me to find several bugs in both simulators. Sam Morgan did not trust REAL, and he spent a few months comparing REAL results with queueing theoretic results for M/M/1 and M/D/1 queues. (Thankfully, he did not find any bugs.) I wonder if any other simulators have been compared using this straightforward technique. My two cents: Simulation results that do not include * an analysis of parameter stability, i.e. the length of time you need to run the simulations before the metrics achieve their steady state value, and * both means and standard deviations (or error bars) are just plain bogus. I was surprised to find that of the 44 'good' papers I taught last year, only ONE had results standard deviations. All the rest that had simulation resuts showed a single data value. Imagine what the situation is for 'not so good' papers! keshav From alokdube at hotpop.com Wed Sep 14 08:35:43 2005 From: alokdube at hotpop.com (Alok) Date: Wed, 14 Sep 2005 21:05:43 +0530 Subject: [e2e] google-to-google References: Message-ID: <03d001c5b942$09431ae0$ab0218ac@rs.riverstonenet.com> > one problem - if there are too many end points, we need to put the > earth from all those holes somewhere, so google needs to buy some > space research outfit (how much is the European Space Agency or > Chinese or russians compared with Nasa or Northrop, these days?). > > > no wait, one more optimisation: put the google systems at the _center_ > rather than round the edges - halves the RTT. and probably could > survive an asteroid impact properly then too. > ring of googles :-)......................... From detlef.bosau at web.de Wed Sep 14 09:09:12 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 14 Sep 2005 18:09:12 +0200 Subject: [e2e] Is sanity in NS2? References: <20050914141706.9E62F77A720@guns.icir.org> Message-ID: <43284B28.24BD9D31@web.de> Mark Allman wrote: > > > The _serious_ issue behind this anecdote is: Who has ever validated > > NS2 code? > > Hang on a minute here. I largely agree with Lloyd and Jon. But, let's > backup for a moment. Two notes: > > * The core ns2 developers have, in fact, built validation tests into ^^^^ I think, that?s a clue here. You talk about core developers, perhaps we can even identify something like the "ns2 core". So that we can distinguish the stable "core" and individual add ons written for individual projects. With respect to my orignial question: It would be helpful to have the flow contro mechanisms using the AWND in the "stable code". At least I think so. I don?t know whether others share this opinion. In general, I don?t criticize the NS2. I criticize how the NS2 is often used, at least among some colleagues und departments I know myself. I know a lot of people who use "NS2" as a kind of buzzword while having _no_ idea, what they are talking about. Myself, I got absolutely no assistance here and I had to learn how to use the NS from reading the documentation (which necessarily cannot be complete in a "living program") and the source code. Perhaps, there could be an easier way. I don?t know. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From touch at ISI.EDU Wed Sep 14 09:25:50 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 14 Sep 2005 09:25:50 -0700 Subject: [e2e] (no subject) In-Reply-To: References: Message-ID: <43284F0E.8070901@isi.edu> Speaking as end2end-interest list admin: Fan Ye wrote: > Jon, > > This is the first time I ever post on e2e list, although I've subscribed > to it several years. > > I'm really astonished to see your technical discussion on ns drifting, or > "accidentally dropping", onto some language attacking an ethnic group China, far as I know, is a country, at least as used in the context below. That said, it's still inappropriate on this list, as per below. > (see below quoted text). You may not have the intention, but what you > wrote seems to imply that all these guys are clueless chinese students who > > dont know a better way to plagiarize. > > >>(I have no idea where they are really from - are they using such >>addresses because they are afraid their university will catch them >>plagiarising, > > ^^^^^^^^^^^^^^^^ > >>or are they blocked in china?) and they do more harm than good. > > ^^^^^^ > > I'm very, very upset to see this kind of language, not to mention at a > least expected place, a technical discussion list. On that we agree. Folkes, please follow basic mailing list etiquitte (and ACM and IEEE codes of conduct) when posting to this list, and avoid ad-hominems, ad-ethnicicsms, ad-racisms, and ad-anythingelse-isms except ad-technicalisms ;-) Joe (list admin) -------------- 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/20050914/287877ad/signature.bin From touch at ISI.EDU Wed Sep 14 09:28:44 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 14 Sep 2005 09:28:44 -0700 Subject: [e2e] google-to-google In-Reply-To: References: Message-ID: <43284FBC.1020008@isi.edu> Jon Crowcroft wrote: > So google are buying dark fiber. why? > > There can only be one reason: > google will stop searching the web, and then indexing it. They will > host all the web on their machines (plenty of space). > (see article in the excellent technical trade press journal the > onion). > > So whats the dark fiber for? > Well you link up all the google clusters directly - no routers, just a > full mesh between google.countrycode > > Now, if it was me, I would go one step further. A well known result > from Physics #101 is that if you drop a ball down > a frictionless straightline tunnel between any two points > on the surface of a ball, it will take the same time to traverse and > just come to a stop at the other side. Nit - minimum paths on the suface of a ball are geodesics. The curve you're looking for is a hyperbolic cosine, a.k.a. a catenary. But... > For an object of the radius and > mass of Earth, this is around 56 minutes. So we connect all the > google clusters on the earth by straightline tunnels and provide a > _transport_ service between these points (both undermining airlines, > trains, but not short hall journeys, but certainyl solving global > warming largely). You then run fiber, or even line of sight laser > links down these tunnels too, giving minium RTT (and still no routers, > no DWDM switches, multiplexors or whatever). Catenaries are paths of least time only for masses under a force (e.g., gravity, centrifuge). Straight lines (at least straight in space-time) are minimums for light. ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050914/4a8d5d49/signature.bin From ammar at cc.gatech.edu Wed Sep 14 11:01:58 2005 From: ammar at cc.gatech.edu (Mostafa Ammar) Date: Wed, 14 Sep 2005 14:01:58 -0400 (EDT) Subject: [e2e] Is sanity in NS2? In-Reply-To: from "Detlef Bosau" at Sep 14, 2005 04:59:44 PM Message-ID: <200509141801.j8EI1wgm003878@ibis.cc.gatech.edu> A few months ago I gave a Keynote presentation at the Annual Simulation Symposium in San Diego that is very relevant to this discussion. The talk was entitled "Why we STILL don't know how to simulate networks" You can find an html version of the talk at http://www.cc.gatech.edu/~ammar/presentations/ANSS (If you want the words that go along with these slides, I will be giving an updated version of this talk at the MASCOTS conference in Atlanta in a couple of weeks.) Mostafa ================================================================= Mostafa Ammar Phone:(404)894-3292 Regents' Professor Fax: (404)385-0332 College of Computing E-mail: ammar at cc.gatech.edu Georgia Institute of Technology Atlanta, GA 30332 WWW:http://www.cc.gatech.edu/fac/Mostafa.Ammar ================================================================= From marc.herbert at free.fr Wed Sep 14 11:04:59 2005 From: marc.herbert at free.fr (Marc Herbert) Date: Wed, 14 Sep 2005 20:04:59 +0200 (CEST) Subject: [e2e] (no subject) In-Reply-To: References: Message-ID: On Wed, 14 Sep 2005, Fan Ye wrote: > I'm really astonished to see your technical discussion on ns drifting, or > "accidentally dropping", onto some language attacking an ethnic group > (see below quoted text). You may not have the intention, but what you > wrote seems to imply that all these guys are clueless chinese students who > dont know a better way to plagiarize. I really wonder how many people felt it like this. > > (I have no idea where they are really from - are they using such > > addresses because they are afraid their university will catch them > > plagiarising, > ^^^^^^^^^^^^^^^^ > > or are they blocked in china?) and they do more harm than good. > ^^^^^^ > > I'm very, very upset to see this kind of language, not to mention at a > least expected place, a technical discussion list. Well, if you are reading this list since several years, you probably noticed it's not "purely" technical, probably because there is no such thing in this field. Of course I agree with you that we are still way off-topic right now. > [...] > > To check the validity of your claim that these guys (at least most) are > from china, I did a quick sampling on ns-users 2005 Aug archieve. At the > end is a sorted list of those who used yahoo addresses. Of these 31 guys, > only 4 have chinese names. I can reasonably say that nearly 90% of them > are NOT from china. > > So how did you find out > 1) they're plagiarizing > 2) they're from china? I suggest you carefully (scientifically?) read every word/sign of Jon, in order, and not only the ones that tease you/support your thesis. The whole sentence you are basing your analysis on was between parentheses, which quite clearly demonstrated IMHO the lack of conviction, importance and exhaustivity of the enclosed conjectures. But probably the main interpretation mistake you make is skipping the "or" link word between "plagiarising" and "China": they quite clearly had no relation to each other! According to my understanding, the only visible reason Jon spoke of China was because he was looking for an example of a well-known and developed country where censorship still exists. All this is of course totally off-topic but I felt the need for at least one public third-party interpretation of Jon's words, answering your (quite severe I think) accusation. Hopefully there won't be many concurrent other answers. I won't complain if the editors filter this message out of course. From touch at ISI.EDU Wed Sep 14 12:01:02 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 14 Sep 2005 12:01:02 -0700 Subject: [e2e] (no subject) In-Reply-To: References: Message-ID: <4328736E.3070103@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc Herbert wrote: > On Wed, 14 Sep 2005, Fan Ye wrote: > > >>I'm really astonished to see your technical discussion on ns drifting, or >>"accidentally dropping", onto some language attacking an ethnic group >>(see below quoted text). You may not have the intention, but what you >>wrote seems to imply that all these guys are clueless chinese students who >>dont know a better way to plagiarize. > > > I really wonder how many people felt it like this. Again, speaking as list admin: The original statement of Jon's was: - --------------------------- some people (typically hard put upon PhD students either strongly self motivated and sef-disciplined) managed to do some useful things, but an awful lot are those hotmail/yahoo email folks you allude to, (I have no idea where they are really from - are they using such addresses because they are afraid their university will catch them plagiarising, or are they blocked in china?) and they do more harm than good. - --------------------------- This is a fairly clear attack that the there is a correlation between hotmail/yahoo addresses and those who do harm, and those who get such addresses because they're in China and otherwise blocked. >>>(I have no idea where they are really from - are they using such >>>addresses because they are afraid their university will catch them >>>plagiarising, >> >>^^^^^^^^^^^^^^^^ >> >>>or are they blocked in china?) and they do more harm than good. >> >> ^^^^^^ >> >>I'm very, very upset to see this kind of language, not to mention at a >>least expected place, a technical discussion list. > > Well, if you are reading this list since several years, you probably > noticed it's not "purely" technical, probably because there is no such > thing in this field. > > Of course I agree with you that we are still way off-topic right now. Although the definition of 'technical' on this list is somewhat vague, the definition of appropriate behaviour should not be. We have not stated a list policy on this, but we have in the past tended to emulate the ACM and IEEE Codes of Conduct on such issues. On the current point, see section 1.4 of the ACM, and item 8 of the IEEE code of ethics on this point. >>[...] >> >>To check the validity of your claim that these guys (at least most) are >>from china, I did a quick sampling on ns-users 2005 Aug archieve. At the >>end is a sorted list of those who used yahoo addresses. Of these 31 guys, >>only 4 have chinese names. I can reasonably say that nearly 90% of them >>are NOT from china. >> >>So how did you find out >>1) they're plagiarizing >>2) they're from china? > > I suggest you carefully (scientifically?) read every word/sign of Jon, > in order, and not only the ones that tease you/support your thesis. > > The whole sentence you are basing your analysis on was between > parentheses, which quite clearly demonstrated IMHO the lack of > conviction, importance and exhaustivity of the enclosed conjectures. > > But probably the main interpretation mistake you make is skipping the > "or" link word between "plagiarising" and "China": they quite clearly > had no relation to each other! The whole sentence, IMO, is an epithet against groups of people, some of which are identified by country, who do "more harm than good". While not as strong as accusations of plagiarism (which is, by my read of Jon's comments, a separate issue), let me be clear that it is ALSO **unacceptable**. > According to my understanding, the only visible reason Jon spoke of > China was because he was looking for an example of a well-known and > developed country where censorship still exists. While his post, IMO, was probably trying to say that the reason a group of people would get hotmail/yahoo addresses, it *also* asserts that this group is doing more harm than good, again. > All this is of course totally off-topic but I felt the need for at > least one public third-party interpretation of Jon's words, answering > your (quite severe I think) accusation. Hopefully there won't be many > concurrent other answers. I won't complain if the editors filter this > message out of course. I won't, but I would prefer if we could just agree NOT to use China as an example of anything other than a country ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKHNuE5f5cImnZrsRAkjkAKCFhoeTuLI5nPwpeEURchio/KLJEQCbBlgj J4ZDtwXnSL/H7vy7t2FC2dc= =+v19 -----END PGP SIGNATURE----- From mallman at icir.org Wed Sep 14 12:58:33 2005 From: mallman at icir.org (Mark Allman) Date: Wed, 14 Sep 2005 15:58:33 -0400 Subject: [e2e] Is sanity in NS2? In-Reply-To: Message-ID: <20050914195833.CFD21355A69@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20050914/fc21ef74/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050914/fc21ef74/attachment.bin From alessandro.vivas at gmail.com Wed Sep 14 13:30:52 2005 From: alessandro.vivas at gmail.com (Alessandro Vivas) Date: Wed, 14 Sep 2005 17:30:52 -0300 Subject: [e2e] (no subject) In-Reply-To: References: Message-ID: Jon, I dont agree with your message. About yahoo mail and hotmail address isnt true. I live in Brazil and many universities dont have have mail accounts for all students. Im a phd student and I use gmail account because my university dont provide e-mail account for me.. only this. So, please dont use examples with countries like when you talk about China. Bye, Alessandro Vivas Andrade On 9/14/05, Fan Ye wrote: > > Jon, > > This is the first time I ever post on e2e list, although I've subscribed > to it several years. > > I'm really astonished to see your technical discussion on ns drifting, or > "accidentally dropping", onto some language attacking an ethnic group > (see below quoted text). You may not have the intention, but what you > wrote seems to imply that all these guys are clueless chinese students who > > dont know a better way to plagiarize. > > > (I have no idea where they are really from - are they using such > > addresses because they are afraid their university will catch them > > plagiarising, > ^^^^^^^^^^^^^^^^ > > or are they blocked in china?) and they do more harm than good. > ^^^^^^ > > I'm very, very upset to see this kind of language, not to mention at a > least expected place, a technical discussion list. > > I have little clue about why these people use hotmail or yahoo address > either. My guess (from my own, limited experience 6+ years ago), is that > many schools in china simply do not provide an email address to every > student, or the habit of Internet users in china differs from here a lot, > people (including graduate students) simply use one email address for > everything, they consider this a convenience. I've got emails from such > students as well, and they asked valid, technical questions. I didnt have > the chance to check out their publication, but I would have a hard time to > > believe they are just poor plagiarizers without a better means to conceal > identity. > > To check the validity of your claim that these guys (at least most) are > from china, I did a quick sampling on ns-users 2005 Aug archieve. At the > end is a sorted list of those who used yahoo addresses. Of these 31 guys, > only 4 have chinese names. I can reasonably say that nearly 90% of them > are NOT from china. > > So how did you find out > 1) they're plagiarizing > 2) they're from china? > > Fan > > __________________________________________________________________ > > From: aashaikh_pk at yahoo.com (ayaz shaikh) > From: aashaikh_pk at yahoo.com (ayaz shaikh) > From: ahmedbelhoul2 at yahoo.com (Ahmed Belhoul) > From: alexandreadames at yahoo.com.br > (=?iso-8859-1?q?Alexandre=20=FFffffc1dames=20Alves=20Pontes?=) > From: alexandreadames at yahoo.com.br > (=?iso-8859-1?q?Alexandre=20=FFffffc1dames=20Alves=20Pontes?=) > From: altaf8031 at yahoo.com (altaf hussain) > From: altaf8031 at yahoo.com (Altaf Hussain) > From: anrew791 at yahoo.com (andrew lloyd) > From: anrew791 at yahoo.com (andrew lloyd) > From: anrew791 at yahoo.com (andrew lloyd) > From: anrew791 at yahoo.com (andrew lloyd) > From: anrew791 at yahoo.com (andrew lloyd) > From: bijuissac at yahoo.com (Biju Issac) > From: bijuissac at yahoo.com (Biju Issac) > From: born2bewild200 at yahoo.com (Just Me) > From: busybee032002 at yahoo.com (sarah Guo) > From: coolns2 at yahoo.com (cherie) > From: coolns2 at yahoo.com (cherie) > From: ebenezer_a at yahoo.com (Ebenezer) > From: ehsan_ataie59 at yahoo.com (Ehsan Ataie) > From: ess_hs at yahoo.com (essam abuosamra) > From: ess_hs at yahoo.com (essam abuosamra) > From: gasyed2003 at yahoo.com (Ghalib Asadullah) > From: jagadish_kranti at yahoo.com (jagadish kranti) > From: jn_lavina at yahoo.com (Lavina Jain) > From: joysmilelol at yahoo.com (joy smilelol) > From: joysmilelol at yahoo.com (joy smilelol) > From: joysmilelol at yahoo.com (joy smilelol) > From: joysmilelol at yahoo.com (joy smilelol) > From: mansoor_jafry at yahoo.com (mansoor) > From: milismrc at yahoo.com (Marico DS) > From: mrhuangzhihong at yahoo.com.cn (=?gb2312?q?=D6=B2=BA=EA=20=BB=C6?=) > From: nazir_fawad at yahoo.com (Fawad Nazir) > From: nazir_fawad at yahoo.com (Fawad Nazir) > From: nazir_fawad at yahoo.com (Fawad Nazir) > From: nazir_fawad at yahoo.com (Fawad Nazir) > From: nazir_fawad at yahoo.com (Fawad Nazir) > From: nittingarg_iiitmg at yahoo.com (nittin garg) > From: rajagopal_452 at yahoo.com (Raja Sombhotla) > From: rana_aa at yahoo.com (rana abu nafisa) > From: raneem31 at yahoo.com (Rana) > From: raneem31 at yahoo.com (Rana Alhalimi) > From: reddymythili29 at yahoo.com (enugala mythili) > From: romdoul2002 at yahoo.com (TAING Nguon) > From: sheng_jin2003 at yahoo.com.cn (Sheng Jin) > From: shicheng969 at yahoo.com.cn (shicheng) > From: sumanth_smiles at yahoo.com (Sumanth Sarma, > Hallegiri) > From: zarkonovicic at yahoo.com (zarko novicic) > From: zillurcse at yahoo.com (zillur rahman) > From: zillurcse at yahoo.com (zillur rahman) > > end2end-interest-bounces at postel.org wrote on 09/14/2005 02:41:27 AM: > > > Lloyd, > > > > this is so on the money in pretty much every comment that I really > > have to support it. > > > > The story of NS is as > > the story of IP, but sadly, not as > > the story of O. > > > > I think the open source/commons implication is part of the problem, but > also > > the success disasster that NS became is partly because they made it too > easy > > (analogous to socket programming) > > so anyone who could wield a bit of tcl or modify an existing bit of > C++, > > thought they could build an interesting new simulation, and didnt > > have to acquire > > any disciple to do so - some people (typically hard put upon PhD > > students either > > strongly self motivated and sef-disciplined) managed to do some > > useful things, but > > an awful lot are those hotmail/yahoo email folks you allude to, > > (I have no idea where they are really from - are they using such > > addresses because they are afraid their university will catch them > > plagiarising, > > or are they blocked in china?) and they do more harm than good. > > > > anecdote - about 6-7 years ago we went through a lot of papers on > tcp/aqm that > > had used ns (on the order of 100 papers) and tried to find the ns > > code to see if > > we could reproduce the results - around 50% of the papers appeared > > to be either bogus (when you > > got th code it didnt work with the alleged version of ns) or appeard > > to have graphs generated > > from a single run of ns (thre first one). quite a few were based o > > na (short lived) bug in the > > congestion control code in ns, (EPFL and others confirmed this bug - > > i cannot remember the exact detail, > > but it meant that the otcl and c++ variables weren't bound, so if > > you varied one, the other one didnt - > > this meant that the results for cwnd were basically random - papers > > were publised on this too). > > > > before ns, there was XSim, and real and the other descendants of the > > MIT simulator, which had a similar series of > > problems, although were sufficiently hard to use that most people > > ended up doing pretty much clean 100% > > rewrites of the relevant part of the code for their thesis work, and > ended up > > i) understanding it > > ii) validating it > > iii) getting lots of meaningful results out > > iv) abandoning it completely upon graduating... > > > > > > Your comments about opnet also apply to matlab and other propietary > > and quite good (or very good, respectively) > > tools, that are supported so long as the relevant supervisrs ask for > > funds - they are relatively expensive for > > UK university budgets so are typically default-off - which is > > ludicrous really given the time it can save a student > > and supervisor and quality improvement in results.... > > > > we attempted to do an NS re-write in java (jns and jvs) which worked > > pretty well and several folks picked up on it, > > but exactly the same thing started to happen to us (at UCL) so I > > abandoned the program of work (though others > > picked up on it and it is on sourceforge i believe (not due to us) > > but i dont know how active it is - > > > > one specific thing that attempted to do was to make it "proper > > programming" to use the simulator, > > so the tecchnical bar was set a bit higher than just throwing some > > modified tcl at something and hoping... > > so trying to counter the point i made above by setting an implict > > "qualifying exam" to drive jns - > > but i think its evidence that at least in the case of educational > > software, open source may not be a good idea... > > supporting your point again. > > > > agree with your points on support mail lists etc too > > > > in fact i think this is the nearly first time i agree 100% with > > what you wrote! > > > > cheers > > jon > > p.s. another anecdote - the person who re-wrote pim at cisco did > > work on multicast in ns for his phd. > > yes, he found the same problems. so did others. i wish i'd told them > > to write their own simulator. > > mea culpa. > > > > > > > > In missive > ac.uk >, Lloyd Wood typed: > > > > >>Detlef, > > >> > > >>There is an ns-developers list, with a much higher signal-to-noise > > >>ratio, and moderation of posts from non-subscribers by Tom Henderson. > > >>But that list is focused on fixing bugs in behaviour in ns (with a > > >>current emphasis from Lacage on rewriting the 802.11 code while > making > > >>all other ns programmers look silly), rather than explaining observed > > >>behaviour of ns without reference to code. The pending move to > > >>sourceforge should make more lists and tools available. > > >> > > >>The contact link at the bottom of various ns webpages like e.g.: > > >>http://www.isi.edu/nsnam/ns/ > > >>is _still_ the ns-users list address, which is irresponsible, since > it > > >>encourages questions without participation or knowledge of context of > > >>the list -- and the after-the-fact autofaq that gets mailed out > > >>doesn't seem to help. This can be considered an example of either > open > > >>source trying to externalise its support costs, or the tragedy of the > > >>commons in action. > > >> > > >>These days, everybody is using ns, presumably because it's free, > which > > >>arguably is of benefit towards students and their universities. (I > > >>wouldn't want to be a student trying to use Opnet and have the > > >>license expire because academics who don't use Opnet are bickering > > >>about which budget payment for the next year's license should come > out > > >>of. Or be considering going part-time as a PhD student and realising > > >>you'd then being exposed to license and server access worries. Or > > >>discovering there's been an Opnet upgrade and the user interface has > > >>changed entirely. Again. In some very important respects, ns gives > PhD > > >>students slightly more control over their destinies.) > > >> > > >>I spent a couple of years in the late 90s answering mail on the > > >>ns-users list; I was the first in my university to use ns, so got to > > >>grips with it very very slowly, while others who followed me got on > > >>far faster, since there was some local help for installation etc., > and > > >>once over those hurdles they actually knew how to program. (as a > > >>strategy this worked -- I received enough help from others that I > > >>could figure out how to create some trivial solvable problems using > > >>ns, write them up, and graduate. But it's risky and not for > everyone.) > > >> > > >>In answering questions on ns (while also asking unanswered questions > > >>more of the form 'these documented commands don't work and ns > crashes! > > >>Why?' -- ns multicast is a complete trainwreck, PIM-SM never worked > > >>for me), I have now left myself open to years and years of questions > > >>from yahoo/hotmail-using students who have trouble stringing coherent > > >>sentences together. I imagine it's much the same for anyone else who > > >>has contributed to ns, and shudder to think how much mail e.g. Floyd > > >>or Heidemann must get on a daily basis. This discourages experienced > > >>participation in the ns-users mailing list; after graduation I > > >>realised I had to unsubscribe for my own sanity. > > >> > > >>Yes, a moderated ns-users list would be a good thing, but it would be > > >>a full-time job, and there's no ns-related charitable foundation. > > >>(Although sourceforge can accept paypal donations, so there could be > a > > >>way of channelling money... hmmm. What's the business case? What's > > >>the selling point for donations?) > > >> > > >>But complaining about ns misses the point. You may as well complain > > >>about why universities don't teach you practical programming 'here's > a > > >>ten-year-old codebase and here's how to figure out how it works' > > >>skills. Universities just expect you pick everything up by osmosis; > > >>hey, get students to spend enough time in a room with computers, and > > >>maybe they'll learn to control them. The principle works with > > >>libraries, books and reading, right? > > >> > > >>Universities are effectively trying to outsource their support > > >>costs, too, in an increasingly short-term world. > > >> > > >>L. > > >> > > >>recommends http://polaris.gseis.ucla.edu/pagre/network.html > > >> > > >> > > >>On Tue, 13 Sep 2005, Detlef Bosau wrote: > > >> > > >>> Please don=B4t wonder when I ask this here. > > >>> > > >>> I placed this question (dynamic AWND) yesterday into the ns-users > list, > > >>> after having subscribed to this list again after a break of about > two > > >>> years. > > >>> > > >>> I think, I=B4m going to unsubscribe again. The ns-users list is > simply > > >>> useless. One of the most important facts in using mailing lists is > that > > >>> after the third question like "Urgent!!!!!!!! I lost my > shoes!!!!!!", > > >>> "Urgent!!!!! Need help!!!!! I=B4m going to take an exam!!!! Help > me!!!!= > > >>!" > > >>> Or "I cannot install the ns2, there are much of this funny files > ending > > >>> with .cc, what=B4s hat?", "Where is the ns2 documentation? There > are mu= > > >>ch > > >>> of that strange .h files, but they are apparently no _help_ files" > etc. > > >>> etc. etc., any user who has in fact an idea of what the ns2 is or > what > > >>> programming is all about will simply unsubscribe. In addition, it > is > > >>> simply not possible to follow this lare amount of mails there. > > >>> > > >>> Perhaps, one could think about a ns-users list with a better > > >>> administration. At least questions like: "which linux must i > install > > >>> on my nt?" or "will nt work in mac when i install my ns in linux?" > > >>> or similar should be made to disappear. It=B4s not only annoying > but > > >>> simply impossible to pick out that one useful post of the hundred > > >>> posts each day that way. > > >>> > > >>> >From my own observation, I=B4ve seen that there are universities > the > > >>> students of which boast with large ns2 knowlege - however in fact, > ther= > > >>e > > >>> is none. > > >>> And there is a clear reason for this: There is no introduction into > > the > > >>> ns2, no lectures, no ns2 users group etc. etc. at these > universities. > > >>> > > >>> In nearly every village in Germany you have a Linux Users Group. > > >>> > > >>> I don=B4t know how this is in Stuttgart but in larger and more > importan= > > >>t > > >>> villages like Markl/Inn or Oberammergau you surely find one ;-) > > >>> > > >>> So, if there is some guy having problems with Linux, he can ask > there > > >>> and will perhaps get assistance. In addition, one can arrange some > kind > > >>> of kknowledge transfer and education there. > > >>> > > >>> Please excuse me, when I=B4m upset on this one. The ns2 is a useful > > too= > > >>l. > > >>> It is very common and it=B4s, in general, a real good work. > > >>> (It can be seen, however, that many programmers contributed to this > > wor= > > >>k > > >>> and that not all of them are equally skilled. But that=B4s > > >>> life.) It would be a pity, when a useful and helpful program with > many > > >>> men years of work in it and much excellent knowledge therein > > >>> will perhaps become less attractive in the long run, because there > is n= > > >>o > > >>> useful venue to discuss ns2 matters. > > >>> > > >>> >From what I=B4ve seen in this one single day, I=B4m about to > suggest t= > > >>o > > >>> close the ns-users list and to start a new discussion venue from > > >>> scratch. > > >>> I don=B4t believe that ns-users can be salvaged. > > >>> > > >>> Detlef > > >>> > > >>> -- > > >>> Detlef Bosau > > >>> Galileistrasse 30 > > >>> 70565 Stuttgart > > >>> Mail: detlef.bosau at web.de > > >>> Web: http://www.detlef-bosau.de > > >>> Mobile: +49 172 681 9937 > > >> > > >> > > > > cheers > > > > jon > > > > > -- Alessandro Vivas Andrade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050914/f0f6827a/attachment-0001.html From thomas.r.henderson at boeing.com Wed Sep 14 14:05:30 2005 From: thomas.r.henderson at boeing.com (Henderson, Thomas R) Date: Wed, 14 Sep 2005 14:05:30 -0700 Subject: [e2e] Is sanity in NS2? Message-ID: <77F357662F8BFA4CA7074B0410171B6D512CC5@XCH-NW-5V1.nw.nos.boeing.com> I've refrained from jumping into this thread till now, but I'd like to inject the following: i) your points on the various deficiencies in ns, the mailing list SNR, documentation, etc. are well taken, and I agree ii) a group is forming to organize a new development community to fix these things There is a mailing list at http://www.isi.edu/nsnam/ns/ns-dev-list.html where future directions for ns are being discussed. You shouldn't see any HELP!!! in the subject lines (list is now moderated). The discussions about next steps should pick up more steam after the impending next maintenance release of ns. I invite those people who care about ns to participate in the discussion there and subsequent development/testing. Tom From rja at extremenetworks.com Wed Sep 14 14:33:13 2005 From: rja at extremenetworks.com (RJ Atkinson) Date: Wed, 14 Sep 2005 17:33:13 -0400 Subject: [e2e] Is sanity in NS2? In-Reply-To: <20050914195833.CFD21355A69@lawyers.icir.org> References: <20050914195833.CFD21355A69@lawyers.icir.org> Message-ID: <4DA92271-BCFD-4FC1-99F8-8FC60ED37C5E@extremenetworks.com> On Sep 14, 2005, at 15:58, Mark Allman wrote: > Nobody said it was perfect. But, to assert that there is nothing done > in this area of validation or regression or quality control or > whatever > you want to call it is just wrong, IMHO. That is all I was trying to > say. I think a large part of the issue is that many of the "externally contributed" NS models have had little or no credible validation, unlike the solid models done by some others (e.g. Floyd). This is then compounded by those ns users who don't validate their particular simulation scenario before believing its results. Unfortunately, submitted papers that both use unvalidated models and use them in an unvalidated scenario are all too common. Even more scary to me, some authors who submit papers to IEEE periodicals don't seem to understand what validation means when the reviewer asks them to edit the paper to discuss how the simulation model and scenario were validated so the reader can have some basis for believing the paper. > Researchers are responsible for ensuring that their experiments > are sound. Doesn't matter if you're using opnet or ns2 or two > Solaris boxes and a Cisco router or a pencil and paper. Quite so. Unfortunately, this reviewer sees a lot more poorly designed simulations being written up and submitted to periodicals than poorly designed laboratory experiments (or, for that matter, papers with conclusions based on incorrect maths). I think the root problem here is that many universities are encouraging students to run simulations without teaching students about how to use simulation properly and without sufficient supervision that the simulation was used properly. This is unfortunate. I'm not sure what is available in the line of standard textbooks, but if one doesn't yet exist maybe there would be room for someone to write up a textbook on when and how to simulate communications systems -- or maybe even a text on good experimental design more generally. Yours, Ran From dga+ at cs.cmu.edu Wed Sep 14 14:54:59 2005 From: dga+ at cs.cmu.edu (David Andersen) Date: Wed, 14 Sep 2005 17:54:59 -0400 Subject: [e2e] (no subject) In-Reply-To: References: Message-ID: On Sep 14, 2005, at 4:30 PM, Alessandro Vivas wrote: > Jon, > > I dont agree with your message. About yahoo mail and hotmail > address isnt true. I live in Brazil and many universities dont have > have mail accounts for all students. Im a phd student and I use > gmail account because my university dont provide e-mail account for > me.. only this. So, please dont use examples with countries like > when you talk about China. I shouldn't jump in on this thread, but to try to inject a little bit of CS: This is a problem of reputation management between un-introduced parties on the Internet. And it's a serious one. As a well known networking researcher, Jon is probably subjected to a constant stream of "random" emails. \footnote{When I was at MIT, we were subject to a constant stream of in-person visits from crackpots who believed they'd broken RSA and wanted to talk to crypto experts, people who'd figured out the grand unified theory, ... } As a well known networking resource, end-to-end is subject to a fairly constant stream of emails that -- from a high level read of the email -- sound for all the world like they're asking for the solution to a homework problem. I hit delete on an enormous number of threads on e2e, particularly lately. How do I decide which threads to actually read? a) The subject line b) Who initiated it and is participating in it (No, I'm not going to say what features influence deletion or reading). When an email comes in from random_student at cs.well_known.edu, I have a few bits of information about them. They're more likely to be active in my research area. They're more likely to have some background to ensure that their question isn't going to be yet- another tarpit discussion. On the other hand, when email comes from terminator_sex_god at yahoo.com, the bits of information are a little different. john_q_public at gmail.com gets binned in the intermediate category: gmail users are frequently more technically savvy, no offense intended to Yahoo mail users, but it's still a relatively anonymous address. I do know quite a few researchers who use gmail.com for their primary email, though -- not including the vast numbers at Google labs. :) If you want the situation to be better, give me a nice distributed email reputation system that I can use to rate the "bozo-factor" of incoming email. That way I can stop using my often incorrect domain- based heuristics, and instead look at the mail and see "ahh, Crowcroft vouches for Foo who vouches for Bar who vouches for dude at yahoo.com. Guess I'll read the mail." I'll let people return to drilling tunnels through the earth, -Dave (I'm sure I just lost several points on the email credibility scale for contributing to this thread...) > > > Bye, > > Alessandro Vivas Andrade > > > On 9/14/05, Fan Ye wrote: Jon, > > This is the first time I ever post on e2e list, although I've > subscribed > to it several years. > > I'm really astonished to see your technical discussion on ns > drifting, or > "accidentally dropping", onto some language attacking an ethnic group > (see below quoted text). You may not have the intention, but what you > wrote seems to imply that all these guys are clueless chinese > students who > > dont know a better way to plagiarize. > > > (I have no idea where they are really from - are they using such > > addresses because they are afraid their university will catch them > > plagiarising, > ^^^^^^^^^^^^^^^^ > > or are they blocked in china?) and they do more harm than good. > ^^^^^^ > > I'm very, very upset to see this kind of language, not to mention at a > least expected place, a technical discussion list. > > I have little clue about why these people use hotmail or yahoo address > either. My guess (from my own, limited experience 6+ years ago), is > that > many schools in china simply do not provide an email address to every > student, or the habit of Internet users in china differs from here > a lot, > people (including graduate students) simply use one email address for > everything, they consider this a convenience. I've got emails from > such > students as well, and they asked valid, technical questions. I > didnt have > the chance to check out their publication, but I would have a hard > time to > > believe they are just poor plagiarizers without a better means to > conceal > identity. > From rik at rikwade.com Wed Sep 14 15:25:47 2005 From: rik at rikwade.com (Rik Wade) Date: Thu, 15 Sep 2005 10:25:47 +1200 (NZST) Subject: [e2e] Is sanity in NS2? In-Reply-To: <43283AE0.550595CE@web.de> References: <43283AE0.550595CE@web.de> Message-ID: <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> On Thu, September 15, 2005 02:59, Detlef Bosau wrote: > The best, and basically the only _real_, validation is to compare > simulation results with reality. And we all know how accurate and RFC-compliant real-world protocol implementations are. I've worked in a few large ISP/telcos and cannot begin to describe the pain caused by broken (whether intentionally misbehaving, or just buggy) protocol implementations at all layers from 2 to 7. Sometimes these bugs are the result of "performance tweaks" by the vendor, otherwise they are just the result of poor software engineering. So the question is, should a simulation try to simulate "reality" (whatever that is), or "standards" (we know what those are). Simulating the standards and then comparing the results with reality may be an interesting exercise in certain contexts, but we shouldn't kid ourselves that it's a reflection of real Internet performance. Simulating the standards in order to assess the performance of NewProtocolX or TCPRenoTweakY is fine, however, and the core NS developers have put in a lot of work to enable self validation that supports precisely this type of simulation. My simulation work began with Keshav's REAL and migrated to NS with a bit of X-Kernel thrown in for good measure. It did provide some confidence that the algorithms I had implemented in REAL gave very similar results when executed in NS (I didn't get that far in X-Kernel unfortunately). Without venturing down the path of detailed mathematical modelling, I felt confident in saying that the combination of simulator validation, and results from multiple environments, provided "acceptably accurate" results. Having run several hundred simulations of certain models and protocol implementations in each environment, I knew that it was repeatable. There is, however, this conflict of simulating reality and simulating basic algorithms and models. Once an implementation has been made and tested in a simulated environment, the next step is to attempt to test its performance with "real traffic" and something approximating a "live environment" (which is why the idea of X-Kernel is nice). Having created a clinical, deterministic, environment, we then want to add elements of chaos and uncertainty in order to really test how our model performs when the unexpected occurs. In my mind, this is where the value of simulation decreases and real kernel implementation should be considered. Is the current approach of simulation in these environments really the best way of engineering protocols for an Internet where standards compliance is often not in the host's interest? On the subject of NS support, is there a project/community Wiki? A Wiki would enable people to find and contribute FAQs quite easily as well as their own code along with links to the relevant papers, raw data etc. If one doesn't exist and the NS team don't have time, I'm happy to set one up under an appropriate domain name. -- rik From yogesh.swami at nokia.com Wed Sep 14 15:29:31 2005 From: yogesh.swami at nokia.com (Yogesh Prem Swami) Date: Wed, 14 Sep 2005 17:29:31 -0500 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: References: Message-ID: <4328A44B.7040700@nokia.com> I have a somewhat general question about simulations. My question is that is there any scientific reason why simulations should be able to predict the behavior of a real packet transmission phenomena? Unless you make the assumption that packet transmission/interaction is a non-chaotic phenomenon (chaotic, as used in physics), there is no reason to believe why a simulation would be able to model real world events. In other words, how did the networking community come to the conclusion that the error between a simulation results and real world packet transmission would be bounded, if someone ran the simulations long enough? Also, stability of mean and variance only signifies that the system (simulator) has a saddle point, but nothing more. (Although, I do agree, that this is the very least a researcher can do.) To give an analogy, take weather prediction for example. Accurately predicting weather is often hard, because the "weather" is fundamentally a chaotic event that can not be easily simulated. If packet transmissions are also like weather, then there is no reason why simulations and real world implementation of protocols will have any similarity in their behavior. Unless someone shows me a proof that packet transmissions fall within the non-chaotic region, I will have a hard time accepting or advocating the use of NS-2 or any other simulation tool. Thanks Yogesh ext S. Keshav wrote: > Detlef, > Since you mentioned my web site, I will save others the effort in wading > through it to post the single relevant sentence: "The goal of simulation is > intuition, not numbers," R.W. Hamming. I was taught this by Sam Morgan at > Bell Labs, who heard it from the horse's mouth. > > In terms of simulator validation, I can tell you how I validated REAL when I > first wrote it in 1988 (BTW, this was not my idea: I was only carrying out > Scott Shenker's instructions): I wrote the same simulation using two > packages -- CSIM and NEST (which eventually became REAL). Then, I compared > every packet transmission and reception at the time granularity of one > microsecond. If there was a difference, I found and fixed any bugs. This > allowed me to find several bugs in both simulators. > > Sam Morgan did not trust REAL, and he spent a few months comparing REAL > results with queueing theoretic results for M/M/1 and M/D/1 queues. > (Thankfully, he did not find any bugs.) I wonder if any other simulators > have been compared using this straightforward technique. > > My two cents: > > Simulation results that do not include > > * an analysis of parameter stability, i.e. the length of time you need to > run the simulations before the metrics achieve their steady state value, and > > * both means and standard deviations (or error bars) > > are just plain bogus. > > I was surprised to find that of the 44 'good' papers I taught last year, > only ONE had results standard deviations. All the rest that had simulation > resuts showed a single data value. Imagine what the situation is for 'not so > good' papers! > > keshav > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 479 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050914/41113573/signature.bin From falk at ISI.EDU Wed Sep 14 16:27:56 2005 From: falk at ISI.EDU (Aaron Falk) Date: Wed, 14 Sep 2005 16:27:56 -0700 Subject: [e2e] Impending publication: draft-iab-link-indications-03.txt (fwd) Message-ID: <4A57615A82917D32B1DBDE48@new.isi.edu> ------------ Forwarded Message ------------ Date: Wednesday, September 14, 2005 4:16 PM -0400 From: Leslie Daigle To: IETF Announcement list Cc: iab at ietf.org Subject: Impending publication: draft-iab-link-indications-03.txt The IAB is ready to ask the RFC-Editor to publish Architectural Implications of Link Indications draft-iab-link-indications-03.txt as an Informational RFC. A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document provides an overview of the role of link indications within the Internet Architecture, as well as considerations for their use, in order to preserve network robustness and performance. The IAB solicits comments by October 11, 2005. Please send comments to the IAB (iab at iab.org), or to ietf at ietf.org. The document can be found at http://www.ietf.org/internet-drafts/draft-iab-link-indications-03.txt From the Abstract: This document describes the role of link indications within the Internet Architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues and provides examples of appropriate and inappropriate uses of link layer indications. Leslie Daigle, For the IAB. ---------- End Forwarded Message ---------- From garmitage at swin.edu.au Wed Sep 14 21:33:57 2005 From: garmitage at swin.edu.au (grenville armitage) Date: Thu, 15 Sep 2005 14:33:57 +1000 Subject: [e2e] (no subject) In-Reply-To: References: Message-ID: <4328F9B5.30406@swin.edu.au> Fer cryin' out loud, people. Reading this list for a few years and being unable to parse Jon's emails seems mutually exclusive. But let's try, shall we? Jon wrote: > but > an awful lot are those hotmail/yahoo email folks you allude to, > (I have no idea where they are really from - are they using such > addresses because they are afraid their university will catch them plagiarising, > or are they blocked in china?) and they do more harm than good. So, the context is "those hotmail/yahoo email folks you allude to". Who is "you"? Llloyd. His preceding line: "I have now left myself open to years and years of questions from yahoo/hotmail-using students who have trouble stringing coherent sentences together." No references to ethnicity or geography so far. Moving on, Jon's word "(I have no idea where they are really from" suggest a parenthetical aside that isn't trying to be scientific or complete. " - are they using such ...plagiarising, or are they blocked in china." Curiously, the hypothesis preceding "or" should seem entirely reasonable for _any_ academic whose received the type of emails to which Lloyd and Jon refer. And that's also entirely independent of ethnicity or geography. Finally the hypothesis after "or" suggest the use of "such addresses" to bypass censorship or primary email accounts located within a particular country. I'm surprised that anyone should be held to task for alluding to a correlation between censorship and China. Unless Jon confesses to intending to imply Chinese students plagiarise, I believe _that_ characterisation of Jon's email is tenuous at best and should be withdrawn. gja From Jon.Crowcroft at cl.cam.ac.uk Wed Sep 14 22:24:00 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 15 Sep 2005 06:24:00 +0100 Subject: [e2e] (no subject) In-Reply-To: Message from grenville armitage of "Thu, 15 Sep 2005 14:33:57 +1000." <4328F9B5.30406@swin.edu.au> Message-ID: thanks you have my meaning straight. In missive <4328F9B5.30406 at swin.edu.au>, grenville armitage typed: >> >>Fer cryin' out loud, people. >> >>Reading this list for a few years and being unable to parse Jon's emails >>seems mutually exclusive. But let's try, shall we? >> >>Jon wrote: >> >>> but >>> an awful lot are those hotmail/yahoo email folks you allude to, >>> (I have no idea where they are really from - are they using such >>> addresses because they are afraid their university will catch them plagiarising, >>> or are they blocked in china?) and they do more harm than good. >> >>So, the context is "those hotmail/yahoo email folks you allude to". Who >>is "you"? Llloyd. His preceding line: "I have now left myself open to years and >>years of questions from yahoo/hotmail-using students who have trouble stringing >>coherent sentences together." No references to ethnicity or geography so far. >> >>Moving on, Jon's word "(I have no idea where they are really from" suggest a >>parenthetical aside that isn't trying to be scientific or complete. >> >>" - are they using such ...plagiarising, or are they blocked in china." >> >>Curiously, the hypothesis preceding "or" should seem entirely reasonable for >>_any_ academic whose received the type of emails to which Lloyd and Jon refer. >>And that's also entirely independent of ethnicity or geography. >> >>Finally the hypothesis after "or" suggest the use of "such addresses" to bypass >>censorship or primary email accounts located within a particular country. >>I'm surprised that anyone should be held to task for alluding to a correlation >>between censorship and China. >> >>Unless Jon confesses to intending to imply Chinese students plagiarise, I believe >>_that_ characterisation of Jon's email is tenuous at best and should be withdrawn. >> >>gja >> cheers jon From touch at ISI.EDU Wed Sep 14 23:13:40 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 14 Sep 2005 23:13:40 -0700 Subject: [e2e] (no subject) In-Reply-To: <4328736E.3070103@isi.edu> References: <4328736E.3070103@isi.edu> Message-ID: <43291114.5070609@isi.edu> All, Let me please clarify some things, again as list admin: a) *IMO* Jon's note does NOT correlate plagiarism with a nationality b) *IMO* Jon's note _can be interpreted_ as correlating a nationality with doing more harm than good. i) I do NOT believe that is the best interpretation of what he posted, but... ii) I DO believe it is one possible interpretation This sort of issue is in the eye of the reader, not the author, and I use that perspective when addressing these issues. I hope that clarifies my position as list admin, and why it would be useful to consider that perspective when posting as well. Thanks, Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050914/2356c01f/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Wed Sep 14 23:22:26 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 15 Sep 2005 07:22:26 +0100 Subject: [e2e] (no subject) In-Reply-To: Message from Joe Touch of "Wed, 14 Sep 2005 12:01:02 PDT." <4328736E.3070103@isi.edu> Message-ID: I am not going to be taught politcal correctness by the USA. however I will point out that the use of brackets and the word OR was deliberate choice of language and the ACM probably has several SIGs that can define it nicely. thanks to Marc, David and Grenville for interpreting it as I meant it. i agreee, we should conduct ourselves properly, and that includes not accusing people of things before pausing for consideration whether they intended what they are accused of. back to google and ns... has anyone got a simulation model of google that has been validated?:) j. In missive <4328736E.3070103 at isi.edu>, Joe Touch typed: >>The original statement of Jon's was: >> >>- --------------------------- >>some people (typically hard put upon PhD students either >>strongly self motivated and sef-disciplined) managed to do some useful >>things, but an awful lot are those hotmail/yahoo email folks you allude >>to, (I have no idea where they are really from - are they using such >>addresses because they are afraid their university will catch them >>plagiarising, or are they blocked in china?) and they do more harm than >>good. >>- --------------------------- >> >>This is a fairly clear attack that the there is a correlation between >>hotmail/yahoo addresses and those who do harm, and those who get such >>addresses because they're in China and otherwise blocked. >> >>>>>(I have no idea where they are really from - are they using such >>>>>addresses because they are afraid their university will catch them >>>>>plagiarising, >>>> >>>>^^^^^^^^^^^^^^^^ >>>> >>>>>or are they blocked in china?) and they do more harm than good. >>>> >>>> ^^^^^^ >>>> >>>>I'm very, very upset to see this kind of language, not to mention at a >>>>least expected place, a technical discussion list. >>> >>> Well, if you are reading this list since several years, you probably >>> noticed it's not "purely" technical, probably because there is no such >>> thing in this field. >>> >>> Of course I agree with you that we are still way off-topic right now. >> >>Although the definition of 'technical' on this list is somewhat vague, >>the definition of appropriate behaviour should not be. We have not >>stated a list policy on this, but we have in the past tended to emulate >>the ACM and IEEE Codes of Conduct on such issues. >> >>On the current point, see section 1.4 of the ACM, and item 8 of the IEEE >>code of ethics on this point. >> >>>>[...] >>>> >>>>To check the validity of your claim that these guys (at least most) are >>>>from china, I did a quick sampling on ns-users 2005 Aug archieve. At the >>>>end is a sorted list of those who used yahoo addresses. Of these 31 guys, >>>>only 4 have chinese names. I can reasonably say that nearly 90% of them >>>>are NOT from china. >>>> >>>>So how did you find out >>>>1) they're plagiarizing >>>>2) they're from china? >>> >>> I suggest you carefully (scientifically?) read every word/sign of Jon, >>> in order, and not only the ones that tease you/support your thesis. >>> >>> The whole sentence you are basing your analysis on was between >>> parentheses, which quite clearly demonstrated IMHO the lack of >>> conviction, importance and exhaustivity of the enclosed conjectures. >>> >>> But probably the main interpretation mistake you make is skipping the >>> "or" link word between "plagiarising" and "China": they quite clearly >>> had no relation to each other! >> >>The whole sentence, IMO, is an epithet against groups of people, some of >>which are identified by country, who do "more harm than good". While not >>as strong as accusations of plagiarism (which is, by my read of Jon's >>comments, a separate issue), let me be clear that it is ALSO >>**unacceptable**. >> >>> According to my understanding, the only visible reason Jon spoke of >>> China was because he was looking for an example of a well-known and >>> developed country where censorship still exists. >> >>While his post, IMO, was probably trying to say that the reason a group >>of people would get hotmail/yahoo addresses, it *also* asserts that this >>group is doing more harm than good, again. >> >>> All this is of course totally off-topic but I felt the need for at >>> least one public third-party interpretation of Jon's words, answering >>> your (quite severe I think) accusation. Hopefully there won't be many >>> concurrent other answers. I won't complain if the editors filter this >>> message out of course. >> >>I won't, but I would prefer if we could just agree NOT to use China as >>an example of anything other than a country ;-) >> >>Joe >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.2.4 (MingW32) >>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >> >>iD8DBQFDKHNuE5f5cImnZrsRAkjkAKCFhoeTuLI5nPwpeEURchio/KLJEQCbBlgj >>J4ZDtwXnSL/H7vy7t2FC2dc= >>=+v19 >>-----END PGP SIGNATURE----- cheers jon From dpsmiles at MIT.EDU Thu Sep 15 00:44:24 2005 From: dpsmiles at MIT.EDU (Durga Prasad Pandey) Date: Thu, 15 Sep 2005 03:44:24 -0400 Subject: [e2e] (no subject) In-Reply-To: <43291114.5070609@isi.edu> References: <4328736E.3070103@isi.edu> <43291114.5070609@isi.edu> Message-ID: <041CDA38-9676-4CC3-8DB0-D928DE2F6D4F@mit.edu> I really wonder why Jon's email is being interpreted in an offensive light. Its obvious to me(and I believe to the rest 90+% members of e2e as well) that he meant no harm. Whats the point of taking umbrage at an interpretation that clearly was not intended? Durga From dpreed at reed.com Thu Sep 15 03:16:02 2005 From: dpreed at reed.com (David P. Reed) Date: Thu, 15 Sep 2005 06:16:02 -0400 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: <4328A44B.7040700@nokia.com> References: <4328A44B.7040700@nokia.com> Message-ID: <432949E2.2010602@reed.com> Yogesh Prem Swami wrote: >I have a somewhat general question about simulations. My question is >that is there any scientific reason why simulations should be able to >predict the behavior of a real packet transmission phenomena? Unless you >make the assumption that packet transmission/interaction is a >non-chaotic phenomenon (chaotic, as used in physics), there is no reason >to believe why a simulation would be able to model real world events. > > This is a crucial question. Far too often, when forced to settle for simulations, we convince students that improving the behavior in simulations is the proper goal of network science. Of course it isn't. But simulation is incredibly important for a variety of reasons. First, simulations provide much more efficient experimental environments. It's very hard to construct repeatable experiments in vivo (so to speak) and in many cases the most important in vivo environments are inaccessible to the researchers who have the time and insight to explore the range of possibilities. Second, simulations provide a key way to express our understanding of reality. A scientific theory *is* a simulation itself - Newton's Laws or Maxwell's equations are nothing more than a simulation program in a mathematical programming language for simulating experiential reality. We validate theories by testing key executions of those programs on our "math computers" against measured experiments. But simulations don't prove anything. Even close matches of simulation runs against real experiments don't prove that the simulation code is "correct". Doing good work with simulation is no different than doing good work in symbolic mathematical analysis. Bad simulations are probably equally common as bad foundations in formal analysis of systems - the assumption of Poisson arrival in queueing theory analyses, or the assumption of gaussian noise in information theory channel analyses, or the assumption that physical systems are linear or near-equilibrium. The solution to these problems is to understand simulation tools at least as well as we understand the mathematical foundations of Analysis (the branch of mathematics that is used to express models and formalisms symbolically), and ALSO to understand the limits of modeling. From detlef.bosau at web.de Thu Sep 15 04:12:43 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 15 Sep 2005 13:12:43 +0200 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 References: <4328A44B.7040700@nokia.com> Message-ID: <4329572B.8080103@web.de> This directly relates to my own research problem and I?m glad about this question. Our whole discussion yesterday was about how we simulate, how we prevent botchers from altering the ns, and we can continue it to why we use the ns, why not opnet, why not glomosim etc. etc. etc. At least, I prefer an open source program because I can read the source and see, what is simulated. _Your_ question is: Is there an evidence that there is some, if loose, correlation or similarity bewtween the simulation in the c-code and reality. And it does not matter here whether we do simulation or emulation or what *mulation ever. The core is a simulation and we must make sure that this matches reality. Let me illustrate my own question. Let?s draw a network. FH-------(the Internet)------PEP/PS----(some mobile wireless wide area network)----Mobile. What I would like to know is: When the PEP does connection splitting (I-TCP, Bakre and Badrinath, I think 1994 or so), should he do dumb spoofing, i.e. ACK TCP packets as they arrive, or should he do Path Tail Emulation? So, we have basically two issues here. First: How does I-TCP control the sender? I does so via TCP flow control. In the paper by Bakre and Badrinath, I-TCP was evaluated with a prototypical implementation. Just to say that. The NS does not implement TCP flow control. That?s what my AWND question was about. Second: How do we simulate the mobile network? And _that?s_ the 1 million dollar question here, because this makes the difference whether a reviewer will recognize is own idea of mobile networks here ("Brillant!, Excellent work! Strong Accept! Best Paper Award!"), whether he does not believe in simulation anyway ("Full of Shit!", "Awkward", "Strong Reject") or whether there is something in between. Let me sharpen this: _This_ part of the simulation / evaluation is the very point, where results can be faked. That caused my aggravaion about the AP-TCP paper from Lindemann?s department, which I simply don?t buy. And even more: One can easily fool oneself here. And I often did. Unfortunately, and that?s why I have to use a simulation here, I have neither and UMTS testbed not an industrial partner which lets me test something in his testbed, of course under non disclosure and I cannot access the code at the PEP ;-) In addition: What?s reality? Is the one irreproducible observation in one single experiment more convincing than the one simulation? I don?t think so. So _either_ we have _reproducible_ experiments (which is not easy in wireless networks) or we have convincing simulations (which is not easy as well). So, the ideal way is a proper rationale. Is there a convincing analytical model for wireless channels? Is it moreover practically useful? I mean: For _practical_ questions? (Pollaczeck-Chinchin?s Theorem....;-)) And: Is this validated in experiments? O.k. Now we end up in the theory, how we should validate a theory. And because I?m a computer scientist and neither Plato nor Sir Karl Popper I won?t continue this. I must leave this to experts. For me, there is no alternative to use a simulation which is based upon a proper idea of the behaviour of the path from PEP to the mobile. Honestly, I must admit: I?m totally helpless there. I did not yet see even _one_ _single_ publication with a complete description what even _happens_ here and how this affects a packet flow from PEP to MH. So, the AWND problem is simple programming here. But the model for the mobile network will make the difference whether my work is a waste of time or whether it?s useful. And I would never rely on commercial programs here, where I can?t see the source and have no idea what happens. Perhaps you could arrange that I can make real measurements in a testbed of Nokia? This would be much more convincing than any simulation. Once again: _This_ is the trapdoor where "results" are often faked. Perhaps, I personally will start with a description, hat happens on the wireless channel and what affects the packet transportation. Only to get the "big picture", what happens in general and what must be studied. However, we need data for this. E.g. roaming. How long does it typially take? What?s the typcial duration of a short time disconnection here? E.g.: Delay spikes. Are they a relevant problem? Thierry Klein gave one reason for dely spikes: The algorithm used for opportunistic scheduling. Can this be improved? Thierry argued in this direction. What about Voice, QoS / Packet, Best Effort scheduling? What about Interleaving? All these are generic techniques, independent from GPRS or UMTS, which may affect the transport latency from PEP to the Mobile. I will have to study this in simulations. But first of all, I have to understand what I have to simulate .... And it must be similar to reality ..... Detlef Yogesh Prem Swami wrote: > I have a somewhat general question about simulations. My question is > that is there any scientific reason why simulations should be able to > predict the behavior of a real packet transmission phenomena? Unless you > make the assumption that packet transmission/interaction is a > non-chaotic phenomenon (chaotic, as used in physics), there is no reason > to believe why a simulation would be able to model real world events. > > In other words, how did the networking community come to the conclusion > that the error between a simulation results and real world packet > transmission would be bounded, if someone ran the simulations long > enough? Also, stability of mean and variance only signifies that the > system (simulator) has a saddle point, but nothing more. (Although, I do > agree, that this is the very least a researcher can do.) > > To give an analogy, take weather prediction for example. Accurately > predicting weather is often hard, because the "weather" is fundamentally > a chaotic event that can not be easily simulated. If packet > transmissions are also like weather, then there is no reason why > simulations and real world implementation of protocols will have any > similarity in their behavior. > > Unless someone shows me a proof that packet transmissions fall within > the non-chaotic region, I will have a hard time accepting or advocating > the use of NS-2 or any other simulation tool. > > Thanks > Yogesh > > ext S. Keshav wrote: > -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From erik.nordstrom at it.uu.se Thu Sep 15 04:47:32 2005 From: erik.nordstrom at it.uu.se (=?ISO-8859-15?Q?Erik_Nordstr=F6m?=) Date: Thu, 15 Sep 2005 13:47:32 +0200 Subject: [e2e] Is sanity in NS2? In-Reply-To: <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> Message-ID: <43295F54.8000007@it.uu.se> Having been an e2e reader for some time (but infrequent poster) I think I can contribute something to this thread. Rik Wade wrote: >On Thu, September 15, 2005 02:59, Detlef Bosau wrote: > > > >>The best, and basically the only _real_, validation is to compare >>simulation results with reality. >> >> I totally agree with the statement above. Comparison to reality is the only way to do validation. >And we all know how accurate and RFC-compliant real-world protocol >implementations are. I've worked in a few large ISP/telcos and cannot > > Reality consists of the world around us, and as far as I know it is not defined by protocol implementations that run in operating systems. Reality is what simulators should simulate, for example radio propagation, not some invented artifact. Having some experience from implementing two ad hoc routing protocols, I can say that my primary usage of simulators such as ns is for prototyping and testing. It is very convenient to test the logic of your protocol implementation in a simulated environment because running around, for example, in a corridor trying to set up multi-hop routes with laptops is very tedious. I think we should realise that this is one of the main applications of tools such as simulators. We should stop using ns-2 for generating last minute results for those mandatory (but seldom useful) graphs at the end of our research paper. The other thing you can use simulators for is to achieve scalability. Tests that are simply too large and complex to conduct in reality are a clear application for simulation. However, if an experiment can be run on a smaller scale on real hardware, I see no excuse to use a simulator other than simply as a tool for debugging and development. That brings me to another point. Why do people abstract away more than necessary in simulators? Why can't ns for example use real packet headers and treat packets in the way a real OS does it? If people claim the reason is for efficiency I can point out that the current way ns deals with packets and headers is not exactly optimal. If ns would implement or mimic real API:s (e.g., berkeley sockets) to the extent possible, without sacrificing too much performance and scalability, it would be much easier to develop protocol code that can run both in reality and simulation. That way validation with reality is so much easier and trust in the code (that it does the right thing) would increase tremendously. For my own implementations, I have gone to great lengths to make sure that my code runs both in reality and in ns-2 (without emulation layers or similar). This has made it possible to deploy the same code in real testbeds and has allowed us to run real experiments and simulations in parallel. This way we have discovered many false assumptions made in other research that rely solely on simulations. It is also possible to do trace based simulation instead of using the de-facto standard ns-2 randomly generated scenarios that have little resemblance to reality. I think simulators are heavily over-utilized in our reasearch field, simply because we are geeks that are too lazy to do real experiments. I think we should put our efforts in developing good methodologies for conducting repeatable real world experiments instead. Simulation should only be used where and when it can be a complement. Erik Nordstr?m From jg at freedesktop.org Thu Sep 15 06:31:00 2005 From: jg at freedesktop.org (Jim Gettys) Date: Thu, 15 Sep 2005 09:31:00 -0400 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: <432949E2.2010602@reed.com> References: <4328A44B.7040700@nokia.com> <432949E2.2010602@reed.com> Message-ID: <1126791061.8486.19.camel@localhost.localdomain> On Thu, 2005-09-15 at 06:16 -0400, David P. Reed wrote: > First, simulations provide much more efficient experimental > environments. It's very hard to construct repeatable experiments in > vivo (so to speak) and in many cases the most important in vivo > environments are inaccessible to the researchers who have the time and > insight to explore the range of possibilities. > Having once been crazy enough to perform such an experiment (in Vivo testing of HTTP/1.1 across the continent on the live internet), and also to have used some simulated behavior for the same experiment (using nistnet to provide controlled latencies and bandwidths in a controlled experimental setup), I can attest to the fact that the experiment on the real network is about 10 times as hard as the controlled experiment. Getting repeatable results on the real network (that we could actually believe) took a couple months of tweaking and analysis, and uncovered behavior that we had not expected (and needed to understand), and would not have seen in the controlled experimental environment. It also uncovered quite a few bugs in various vendor's TCP of the era. Arguably, the in vivo results were 10 times as valuable and convincing as the simulated results, and allowed us to believe simulated results without much question in the other environments that we had not tested "live". At the end we ended up with great confidence our numbers were not taken from thin air, but reflected reality. - Jim From eblanton at cs.ohiou.edu Thu Sep 15 07:27:07 2005 From: eblanton at cs.ohiou.edu (Ethan Blanton) Date: Thu, 15 Sep 2005 09:27:07 -0500 Subject: [e2e] (no subject) In-Reply-To: References: Message-ID: <20050915142707.GE11795@colt.internal> David Andersen spake unto us the following wisdom: > If you want the situation to be better, give me a nice distributed > email reputation system that I can use to rate the "bozo-factor" of > incoming email. That way I can stop using my often incorrect domain- > based heuristics, and instead look at the mail and see "ahh, > Crowcroft vouches for Foo who vouches for Bar who vouches for > dude at yahoo.com. Guess I'll read the mail." This is an interesting assertion, on several levels. Mark Allman, Vern Paxson, and I recently wrote a paper on making just such assertions about Internet hosts: Mark Allman, Ethan Blanton, Vern Paxson. An Architecture for Developing Behavioral History. The Workshop on Steps to Reducing Unwanted Traffic in the Internet, July 2005. http://www.cs.purdue.edu/homes/eblanton/publications/history-sruti05.ps There are a lot of parallels to the kinds of statements you want to make about email users, and the people you want to allow to make those statements. Interestingly, while the paper focuses on negative reports (statements that a host has been observed doing something "bad"), it seems (to me) like an email reputation system should focus on positive reports; the judgement "terminator_sex_god at yahoo.com is a fool" may seem too harsh, but the judgement "john.q.public at gmail.com contributed something interesting" is pretty mild. In fact, one might even envision that such statements witness not the general behavior of an address, but specific bouts of cluefulness. The decision of whether or not to tie assertions to identity is also interesting ... the host reputation system outlined in the paper is based on largely anonymous reports (with the option of manually confirming identities for the purpose of making local policies), with the reputation of particular reporting keys being locally determined without information as to the actual reporting entity. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050915/ba8d7382/attachment.bin From detlef.bosau at web.de Thu Sep 15 08:29:54 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 15 Sep 2005 17:29:54 +0200 Subject: [e2e] Is sanity in NS2? References: <20050914195833.CFD21355A69@lawyers.icir.org> <4DA92271-BCFD-4FC1-99F8-8FC60ED37C5E@extremenetworks.com> Message-ID: <43299372.7060408@web.de> RJ Atkinson wrote: > > On Sep 14, 2005, at 15:58, Mark Allman wrote: > >> Nobody said it was perfect. But, to assert that there is nothing done >> in this area of validation or regression or quality control or whatever >> you want to call it is just wrong, IMHO. That is all I was trying to >> say. > > > I think a large part of the issue is that many of the "externally > contributed" NS models have had little or no credible validation, > unlike the solid models done by some others (e.g. Floyd). This is This what I wanted to call "core" yesterday: The stable part (perhaps the _major_ part) in the NS in contrast to many hacks which are not validated and even not known to the public. E.g. my PTE stuff. Nobody in the community ever read it. No one can say whether results using this code are certain or not. And one remark to the validation runs in the NS. As far as I see, their purpose ist not primarily to validate the modules but the compilation. It is validated whether the compiled and installed NS yields the expected results for a huge number of tests. > then compounded by those ns users who don't validate their particular > simulation scenario before believing its results. > > Unfortunately, submitted papers that both use unvalidated models > and use them in an unvalidated scenario are all too common. Even And, again refering to my own work, it?s hardly possible to do this in some other way. Of course we could discuss whether I first write my code, then ask someone (btw: whom?) whether I may contribute the code, then wait for some people to approve it and then, when I get older, loosing my hair, many years from know (The Beatles) I perhaps get the chance to have a paper published. > more scary to me, some authors who submit papers to IEEE periodicals > don't seem to understand what validation means when the reviewer > asks them to edit the paper to discuss how the simulation model > and scenario were validated so the reader can have some basis > for believing the paper. > And this is something you have to learn and where you need assistance. That?s why I complain that nobody teached me there. I know this is annoying to many of you. However, it is somewhat unfortunate to do this all from scratch and the only feedback you have is the one rejected paper every year. Personally, I have only a rough idea, how I could validate my own code. I can describe the PTE algorithm. I can run a number of test scenarios. I can compare the output in the logfile with the intended behaviour of the algorithm. So, I could say: Every scenario yields the correct result. But is this sufficient? Unfortunately, the typical attitude is that: If the paper is accepted, your teacher was correct in his orders he has given to you and you followed them corectly. If the paper was rejected, your teacher was .....to you and you did not follow them correctly. I have no teacher, so the former does not apply. Hoewever: I still do not fully undertand the standards, by which a paper is accepted or rejected. >> Researchers are responsible for ensuring that their experiments >> are sound. Doesn't matter if you're using opnet or ns2 or two >> Solaris boxes and a Cisco router or a pencil and paper. > > > Quite so. Unfortunately, this reviewer sees a lot more poorly > designed simulations being written up and submitted to periodicals > than poorly designed laboratory experiments (or, for that matter, > papers with conclusions based on incorrect maths). > > I think the root problem here is that many universities > are encouraging students to run simulations without teaching > students about how to use simulation properly and without > sufficient supervision that the simulation was used properly. > This is unfortunate. And this is exactly what I complained about. Moreover, it?s an inacceptalbe waste of time and money. How long does it take for a gifted student to get _really_ familiar with the NS and the basics of simulations? At the risk that I have to ask my provider for additional disk space for my mailbox and that I will have learned at least two hundered new swearwords by the end of this day: I don?t believe that even an excellent student will really _understand_ what he is doning in less than one year. Assumed, the student is engaged in the NS _full_ _time_. I do know some PhD students engaged in "projects" (this are these funny things to make your department "visible", in real life, it?s called "advertising") the major part of their time. And even with the best effort, they don?t achieve useful simulations. They achieve pure botchery. And they can?t even help it because the day has only 24 hours. Yesterday we talked about Tcl here. I did not fully understand the arguments in favour of Tcl yet. However, I?m not fully convinced that the mixture of Tcl, OTcl, Tclcl and C++ is really that good idea here. Even this mixture is extremely error prone (I once asked a colleague who was thought to be a brillant expert for the simple reason, why a Trace/Deque is Trace/Deque and he smattered a lot of bullshit but _NO_ _ONE_ could explain me what I already guessed that time, that for the split object the initialization code for a Trace object is executed only for the reason of the notation "Trace/Deque". This appears plausible. But I have looked for this in numerous documents for nearly a year to make it sure, not full time of course, otherwise I could have read the whole Tcl interpreter). It is extremely difficult to understand. And it?s a nuisance to debug. I spent many hours in the debugger to get problems in the C code fixed and it?s always nasty when you have to step over a "tcl.evaf()" and have to treat it as a black box. Particularly when you run in problems with dangling pointers or null pointer exceptions or something similar. Perhpas, I don?t have the right intuition for the big picture here, but for me the NS is a toolbox, a framework. And if I had a faster computer and not have to wait hours for the link run, I would appreciate doing the whole thing in C++. Perhaps, I?m not an experienced programmer, but I?m not convinced of having the need for an embedded language. (And I?m old fashioned as well, I strongly prefer C++ over Java, but this is my personal attitude. One single reason: Java does not have pointers. And I don?t know a language, where a similar depth of knowledge and experience with pointers is required as in Java, only to give yourself the illusion you would not use pointers. In consequence, I?ve never seen that much null pointer exceptions and pointer errors as in Java elsewhere. We should not avoid pointers, if we can?t, but learn to use them.) When I said, it takes a year to understand the ns, at least nine month of this is spent for understanding the mixed language stuff. And the bindings. And the slit objects. And what is initialized where and when. Other people make a baby in this time. So, finally a student often simply wastes a year only to understand the ns. And this should be drastically shortened because no one has the time and the money for that. The ns itself is basically a framework and other frameworks can be understood in a shorter time too. The important difference to other frameworks is that in the ns, you are often required to work at the framework itself. It is not really possible to take the C++ framework as a black box and do some Tcl scripting. In fact, I would prefer to do that little Tcl sripting I have done in C++ as well. Who complained recently, his students did forget the binding? God in Heaven! If we did not do this mixed language stuff, we would not have these pitfalls! I think, this is simply cumbersome and nasty. > > I'm not sure what is available in the line of standard textbooks, > but if one doesn't yet exist maybe there would be room for someone > to write up a textbook on when and how to simulate communications > systems -- or maybe even a text on good experimental design > more generally. > > Yours, > > Ran > -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Thu Sep 15 11:00:01 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 15 Sep 2005 20:00:01 +0200 Subject: [e2e] (no subject) References: Message-ID: <4329B6A1.6060101@web.de> David Andersen wrote: > On Sep 14, 2005, at 4:30 PM, Alessandro Vivas wrote: > >> Jon, >> >> I dont agree with your message. About yahoo mail and hotmail address >> isnt true. I live in Brazil and many universities dont have have mail >> accounts for all students. Im a phd student and I use gmail account >> because my university dont provide e-mail account for me.. only this. >> So, please dont use examples with countries like when you talk about >> China. > > > > I shouldn't jump in on this thread, but to try to inject a little bit > of CS: Me neither. And we all would better stop this endless discussion. I?m not a judge to say who said something wrong here or who didn?t. Jon?s posting was misunderstood, Fan Ye felt insulted here. As stated countless times here, the reactions were overexaggerated. I myself often say things in a harsh way and a way which can be misunderstood. And when I think of some off list communications during the last days, I wonder that I - and my peers as well - are still alive. Basically, to the best of my knowlege, even the english speaking world has adopted an appropriate german word for it: Kindergarten. Did someone die because of these posts? Have these posts caused a war? Did some company declare bankruptcy? Are any people suffering from an illness as a consequence of these posts? If not: Here in Germany we would say, Jon and Fan Ye should have a Bier (sp!) together and make peace. Even if there is no real war. If we had simply ignored these two posts, this would have caused less harm than this endless discussion. We should get a live and drop our onversensitivity. Next time, we sue people in the bus for an unfriendly look... > > This is a problem of reputation management between un-introduced > parties on the Internet. And it's a serious one. As a well known Reputation management. Surely, you have some slides from a well known Reputation Management Consulting Agency here. Which one should we choose? The Boston Consulting Group? McKinsey? Anderson Consulting? Ernst & Young? I suffered years of my life from the double standards behaviour in some department wherer reputation was all, the private person was nothing. Every word, every behaviour was weighted against the "reputation". Even the papers had to improve the "reputation". No comment on the scientific quality. Does this matter? No. If only the "reputation" is perfect. I hate it. Admittedly, I hate it. Jon is right: We shall conduct ourselves. But for me: I?m Detlef. And who talks to me, talks to Detlef. And although I?m in general a friendly guy, I sometimes can be somewhat "difficult". And if you talk to me for more than half an hour, you know that. So, I will conduct myself, and you must take me as I am, there is no other Detlef Bosau. And surely, the same holds true for Jon and Fan Ye and all the outhers. > networking researcher, Jon is probably subjected to a constant stream > of "random" emails. \footnote{When I was at MIT, we were subject to a All of us are. As I said in another post, I?m unemployed. So I?m not suffering from too much mail here. One nasty person at our employment exchange boasted: "Do you know, how much e-mail I receive?" So what. That?s not my problem. One must be in a need to say it to talk about this. This person cried hysterically: "I get 80 emails a day!". O.k, some people receive 80 emails an hour. We should base a social ranking upon this. The more email we receive, the better is our reputation ;-) > constant stream of in-person visits from crackpots who believed they'd > broken RSA and wanted to talk to crypto experts, people who'd figured > out the grand unified theory, ... } As a well known networking I deeply feel with you. > resource, end-to-end is subject to a fairly constant stream of emails > that -- from a high level read of the email -- sound for all the world > like they're asking for the solution to a homework problem. Is that the way you think of me? No? You ask, why I think this? I can tell you: > I hit delete on an enormous number of threads on e2e, particularly > lately. How do I decide which threads to actually read? > > a) The subject line > b) Who initiated it and is participating in it > > (No, I'm not going to say what features influence deletion or reading). > > When an email comes in from random_student at cs.well_known.edu, I have a > few bits of information about them. They're more likely to be active > in my research area. They're more likely to have some background to > ensure that their question isn't going to be yet- another tarpit > discussion. Fine! So, if i were the great Detlef.Bosau at cs.cmu.edu, I would be a member or student of the great Carneghie Mellon University, perhaps of higher rank than you and you have to bow before me and so you would read my post. Otherwise you drop me :-( My apologies to the list, if someone found this not acceptable. It took me years even to have a homepage. And when I read this post, I?m about to cancel it. I like people who talk _to_ me. I don?t like people who talk _about_ me. And I don?t want to suffer from prejudice. So, on my homepage you will not find neither my CV nor a photograph. (In fact, you find a mess, there is a lot to be added.) However, much persons here even talk to a nobody "detlef.bosau at web.de". And I?m thankful about that, because I?m allowed to learn and people even talk to a nobody. And I?m _deeply_ impressed when I see _who_ talks to me. However, I try to treat everyone the same whay. And whem someone prefers to have the address Bull.Shit.2005 at yahoo.com, I certainly find this somewhat strange, but this is _my_ problem. And when one offers me a GUT, even then I can stay polite. Perhaps, there is one mail among thousand with a hidden nugget in it. > > On the other hand, when email comes from terminator_sex_god at yahoo.com, > the bits of information are a little different. john_q_public at gmail.com which is simlar to mine... > gets binned in the intermediate category: gmail users are frequently Merciful! Really merciful! > more technically savvy, no offense intended to Yahoo mail users, but > it's still a relatively anonymous address. I do know quite a few > researchers who use gmail.com for their primary email, though -- not > including the vast numbers at Google labs. :) > > If you want the situation to be better, give me a nice distributed > email reputation system that I can use to rate the "bozo-factor" of It?s even more merciful, that you don?t call ith teh "bosau-factor". BTW: I don?t believe in "reputation systems". It?s a buzzword. Not more. And a bad one too. I?m angry about your attidute, frankly spoken. What you say here is nothing else that what Jon was accuesed for. However, you say it in a more elaborated way. I worked for years at a customer?s help desk. (Do you still talk to me? A "hotline guy"? Do you have the same word in English?) > incoming email. That way I can stop using my often incorrect domain- > based heuristics, and instead look at the mail and see "ahh, Crowcroft > vouches for Foo who vouches for Bar who vouches for dude at yahoo.com. > Guess I'll read the mail." > And when I?m not that lucky that a "name" vouches for me, I?m worthless. Thank you. This not only sounds arrogant, it _is_ arrogant. Seems, as if you believe in vouchers, name dropping and other kinds of prejudice. What do you think about judging a person for his contribution? > I'll let people return to drilling tunnels through the earth, > > -Dave > (I'm sure I just lost several points on the email credibility scale > for contributing to this thread...) Surely. Perhaps it destroys your reputation ;-) Frankly spoken: At least, I know some of your prejudices now. So, if you don?t receive an email from me, it?s not because your lack of reputation, an insufficient number of doctoral degrees or because you were "only" assistant professor and no tenure. (I don?t know, I did not look at your homepage, intendedly not. I want to write totally unbiased here.) It?s, frankly spoken, because from this post you appear to me as a quite arrogant person. And that you are a victim of the "world wide reputation system". 2+2 = 4. And not 5. And this does not change even if the guy who said that were the biggest a**h*le of all times In science, we look at the results. And wie should not look at the person. (Admittedly, I _have_ difficulties here myself. And when I try to get a job in Germany at the age of 42 and the copmpanies don?t hire german inhabitants, particularly no half dead perons, but younger, mostly asian competitors which currently overwhelm our country, this is anything but a comfortable situation. With respect to Jon?s post, I therefore did not see the potential insult therein but thought by myself: "Wonderful! Finally someone to tell the truth!". Perhaps you will hate me for that. But I only want to be understood. Perhaps this is wrong. But that?s the attitude of a 42 years old computer scientist who hunts a job for about two years now and sees well situated asian IT guyes the whole day each time he leaves his appartment. And you don?t read my posts, not because I don?t have a chinese name, I have none, but because I?m not from a Gig.Name.University at Edu.Land. It?s exaclty what Fan Ye complained about.) Finally: I tried to express this as politely as I could. If, however, I offended someone, perhaps due to my bad english, I apologize. Originally, I did not want to contribute to this thread because I think it would cause unnecessary harm. Nothing happend - and we should not make this "nothing" _happen_ without any need to do so. However, I felt offended by your post. And BTW: Perhaps, next time, when I should ever contribute to a conference which is not double blind, I consider to apply for a yahoo-Account :-) detlef.bosau at yahoo.com :-) > > >> >> >> Bye, >> >> Alessandro Vivas Andrade >> >> >> On 9/14/05, Fan Ye wrote: Jon, >> >> This is the first time I ever post on e2e list, although I've subscribed >> to it several years. >> >> I'm really astonished to see your technical discussion on ns >> drifting, or >> "accidentally dropping", onto some language attacking an ethnic group >> (see below quoted text). You may not have the intention, but what you >> wrote seems to imply that all these guys are clueless chinese >> students who >> >> dont know a better way to plagiarize. >> >> > (I have no idea where they are really from - are they using such >> > addresses because they are afraid their university will catch them >> > plagiarising, >> ^^^^^^^^^^^^^^^^ >> > or are they blocked in china?) and they do more harm than good. >> ^^^^^^ >> >> I'm very, very upset to see this kind of language, not to mention at a >> least expected place, a technical discussion list. >> >> I have little clue about why these people use hotmail or yahoo address >> either. My guess (from my own, limited experience 6+ years ago), is that >> many schools in china simply do not provide an email address to every >> student, or the habit of Internet users in china differs from here a >> lot, >> people (including graduate students) simply use one email address for >> everything, they consider this a convenience. I've got emails from such >> students as well, and they asked valid, technical questions. I didnt >> have >> the chance to check out their publication, but I would have a hard >> time to >> >> believe they are just poor plagiarizers without a better means to >> conceal >> identity. >> -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From nichols at mountainfog.com Thu Sep 15 11:27:19 2005 From: nichols at mountainfog.com (Kathleen Nichols) Date: Thu, 15 Sep 2005 11:27:19 -0700 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: <432949E2.2010602@reed.com> References: <4328A44B.7040700@nokia.com> <432949E2.2010602@reed.com> Message-ID: <4329BD07.8050701@mountainfog.com> I'm feeling a curmudgeonly rant coming on. David Reed gives some excellent perspective on the use of simulation. In my experience, it's the "perspective" that seems to be out of order in much of the research use of simulation. From the start, I've cast a suspicious eye at the results of my own simulations, not to mention others. The most egregious problem seems to be claiming internet-wide peformance improvements based on very limited simulations. (Jon Crowcroft gave me the chance to rant on this at the Decides BoF at the Oslo IETF in 1999 in the diffserv context.) Making sweeping changes in widely deployed internet protocols on the basis of simple simulation, or even simple lab experiments just seems like a bad idea. On the other hand, simulation can be excellent for understanding the dynamics of smaller scale interactions. Years ago while working at the Bell Labs That Was, I was working on a visual simulator and modeled a colleague's distributed computer network. The visuals beautifully showed a deadlock. I told him not to worry, my simulator was still being developed. 3 weeks later he told me that they'd found the deadlock in the lab. Okay, sometimes simulation works. When working at my very first start up, I simulated TCP interactions with a cable data system and found some problems in the protocol. This seems another nice use of simulation - to explore inter-layer interactions before everything gets built and deployed. Went through all the channels to explain how this needed to be fixed. The engineer writing the code decided not to implement the change. When a problem showed up in the beta roll-out, it was obvious the change hadn't been implemented. Over the years, I've used simulations to learn various cool things about how things interact and get some insight. It never occured to me to recommend new protocols for the internet on the basis of a simulation though. The first time I used ns (before ns-2), I was persuaded to do so by Van Jacobson who told me that ns's event sorting was very efficient and that the TCP code was very good. I found out that events were stored in a linked list (I think the statute of limitations on my complaining about this is about up, though) and the TCP implementation did not have the three way handshake nor did it shut down connections properly. On the other hand, it took me less time to fix this stuff and get a useful set of simulations than the amount of time I'd put into trying to model MAC layer-TCP interactions in Opnet. When I picked up ns-2 the first time, I found the "full TCP" code was full of bugs and the oTcL/C++ interaction made it much harder to code your own models. So, I think I'm supporting Detlef and those who say it's important to read through the models and to know what you are modeling and to know what the goals of your simulation are. I'm sort of looking for something without the baggage of ns-2 these days. Has anyone used Omnet++? Perspective is a good thing to have in life. Especially when it comes to the use of simulation. I'm not sure we can expect the average grad student to have such perspective, but it seems like it might reasonably be expected of those who advise graduate students. respectfully, Kathie Nichols From riley at ece.gatech.edu Thu Sep 15 12:45:55 2005 From: riley at ece.gatech.edu (George Riley) Date: Thu, 15 Sep 2005 15:45:55 -0400 Subject: [e2e] Is sanity in NS2? Message-ID: <30131a341525ca75ecb3eef3f56a722d@ece.gatech.edu> I've restrained from replying until now, but must jump in. Yogesh Prem Swami wrote: > I have a somewhat general question about simulations. My question is > that is there any scientific reason why simulations should be able to > predict the behavior of a real packet transmission phenomena? Unless > you > make the assumption that packet transmission/interaction is a > non-chaotic phenomenon (chaotic, as used in physics), there is no > reason > to believe why a simulation would be able to model real world events. What chaotic behavior are you talking about? The behavior of a TCP endpoint is completely deterministic. Given a set of data demands on a TCP connection, and a given network topology with no competing flows, the endpoint will do exactly the same thing every single time. The behavior of a router with a fixed size DropTail queue and a fixed set of links will behave exactly the same way every time, given an arrival pattern of packets. Both of the above statements are ignoring small variations in interrupt response times and process scheduling at the systems in question, but these variations are small and can be ignored without affecting measured results. The job of the simulator is to recreate these deterministic and well known behaviors, without having to construct a real network. A high-quality simulator, such as ns2 or GTNetS does exactly this. A competent programmer can read the RFC's describing what the TCP endpoint is supposed to do, and implement a model that does exactly that. BTW, if you haven't seen the Georgia Tech Network SImulator (GTNetS), it might be worth a quick look. Google for GTNetS and check it out from our CVS repository. The above statements are bit tongue-in-cheek of course, because we all agree that networks are in fact chaotic. But where does this chaotic behavior come from? It comes from unknown and unpredictable behavior of the end-system applications and users. Again, any good simulator can model this as well, as both ns2 and GTNetS can do. The randomness is due to randomness in the data demand at endpoints, ignoring intentional randomness is certain AQM methods such as RED. But again, the job of the simulator is NOT to intentionally produce chaotic behavior in a network, but rather to predict what that network would do, given a set of (possibly random) inputs. I claim that a good simulation tool can and does do exactly that. Simulation is not supposed to be a replacement for actual in-vitro experimentation, but must be used in cases where such experiments are not possible. Consider Sally's recent work on TCP Quick-Start. The Quick-Start implementation requires support from routers, to react to and modify a new options field in the TCP header. Is Sally supposed to somehow get access to Cisco IOS source code and modify it to support the new header? Of course not. Is she supposed to get access to Linux source code (easily done) and hack it to support the new option (not so easily done)? Again of course not. She uses a simulation tool that she is quite comfortable with, and constructs both router behavior and end-system behavior as she imagines it will be implemented in the future, and demonstrates the differences in performance using Quick-Start. In this case, clearly a field experiment is not possible. The criticism that simulation tools, such as ns2, are responsible for a plethora of poor quality networking research is just bogus. The simulator is a tool who's job it is to predict what a given network will do under a given set of conditions. The researcher is responsible for deciding what is a reasonable set of conditions to be used to study a given problem. ns2 and GTNetS and the other simulation tools will uphold their end of the bargain, it is the researcher's responsibility to uphold their end. George ------------------------------------------------------------------------ -------------------- George F. Riley, Assistant Professor The School of Electrical and Computer Engineering at Georgia Tech Atlanta, GA 30332-0250 (404)-894-4767 E-Mail: riley at ece.gatech.edu ECE3090 Web Page: http://users.ece.gatech.edu/~riley/ece3090/ ECE6110 Web Page: http://users.ece.gatech.edu/~riley/ece6110/ From s.malik at tuhh.de Thu Sep 15 14:22:52 2005 From: s.malik at tuhh.de (sireen malik) Date: Thu, 15 Sep 2005 23:22:52 +0200 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: <4329BD07.8050701@mountainfog.com> References: <4328A44B.7040700@nokia.com> <432949E2.2010602@reed.com> <4329BD07.8050701@mountainfog.com> Message-ID: <4329E62C.7070103@tuhh.de> Kathleen Nichols wrote: >Perspective is a good thing to have in life. Especially when it comes >to the use of simulation. I'm not sure we can expect the average >grad student to have such perspective, but it seems like it might >reasonably be expected of those who advise graduate students. > > Exactly. We learn to walk before we learn to run before we learn to ... become Carl Lewis! So when I started work, I wanted to use NS2. No special reason.. just Google! My seniors convinced me that NS2 is not a good idea etc. etc. . so they had written a TCP library for the Ptolemy simulator. Because all my love for NS2 was based on a simple Google search, it was easy for them to convince me, anyways. By now, we have Web, Voice, Video and P2P simulations running over Ptolemy. Is our code bug free? No. It has its own share, however, the in-house knowledge about the implementation has made the debugging work relatively easy for us. The important thing is that our tutor picks up the crap results very quickly. I think it was largely his feedback which has kept the code constantly improving. In fact, after some experience on the topic, I can pick up "strange" results too... and hope that with years I improve can upon my ability. Perspective is important. -- Sireen From yogesh.swami at nokia.com Thu Sep 15 14:35:19 2005 From: yogesh.swami at nokia.com (Yogesh Prem Swami) Date: Thu, 15 Sep 2005 16:35:19 -0500 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: <4329BD07.8050701@mountainfog.com> References: <4328A44B.7040700@nokia.com><432949E2.2010602@reed.com> <4329BD07.8050701@mountainfog.com> Message-ID: <4329E917.8050301@nokia.com> I tend to agree with your's and Prof. Reed's comments. My question was not so much about usefulness, but more about realism (but I myself messed up that question in the last paragraph of the e-mail :-)). When ever we run simulations, we tend to ignore parameters or events that we believe will be insignificant to the end result. So for example, when running TCP performance tests, we ignore how the ARP cache works. We *assume* that these "small perturbations" in the system would only result in small perturbations in the final outcome. And this might be true on a small scale (whatever small scale means). However, as the scale increases, it might no longer be true that small perturbations will lead to only small perturbations in the outcome (I'm speculating, not suggesting). In the worst case, it might turn out that simulations require infinite precision to realistically simulate the system. So even if we build highly sophisticated simulators, it might not be possible with out finite precision machines to get extremely meaning results. This also means that people who are using simulators must know (or guess) what external parameters they need to include in their simulations and what the scale of their simulations should be. Unfortunately, I have found that trying to guess these external parameters is often non-trivial. All this might seem like unnecessary jargon to people who just want to write some papers using NS-2, so thanks for bearing with me. Thanks Yogesh ext Kathleen Nichols wrote: > I'm feeling a curmudgeonly rant coming on. > > David Reed gives some excellent perspective on the use of simulation. In > my experience, it's the "perspective" that seems to be out of order in > much of the research use of simulation. From the start, I've cast a > suspicious eye at the results of my own simulations, not to mention > others. The most egregious problem seems to be claiming internet-wide > peformance improvements based on very limited simulations. (Jon > Crowcroft gave me the chance to rant on this at the Decides BoF at > the Oslo IETF in 1999 in the diffserv context.) Making sweeping changes > in widely deployed internet protocols on the basis of simple simulation, > or even simple lab experiments just seems like a bad idea. > > On the other hand, simulation can be excellent for understanding the > dynamics of smaller scale interactions. Years ago while working at > the Bell Labs That Was, I was working on a visual simulator and > modeled a colleague's distributed computer network. The visuals > beautifully showed a deadlock. I told him not to worry, my simulator > was still being developed. 3 weeks later he told me that they'd > found the deadlock in the lab. Okay, sometimes simulation works. > When working at my very first start up, I simulated TCP interactions > with a cable data system and found some problems in the protocol. > This seems another nice use of simulation - to explore inter-layer > interactions before everything gets built and deployed. > Went through all the channels to explain how this needed to be fixed. > The engineer writing the code decided not to implement the change. > When a problem showed up in the beta roll-out, it was obvious the > change hadn't been implemented. Over the years, I've used simulations > to learn various cool things about how things interact and get > some insight. It never occured to me to recommend new protocols > for the internet on the basis of a simulation though. > > The first time I used ns (before ns-2), I was persuaded to do so by > Van Jacobson who told me that ns's event sorting was very efficient > and that the TCP code was very good. I found out that events were > stored in a linked list (I think the statute of limitations on my > complaining about this is about up, though) and the TCP implementation > did not have the three way handshake nor did it shut down connections > properly. On the other hand, it took me less time to fix this stuff and > get a useful set of simulations than the amount of time I'd put into > trying to model MAC layer-TCP interactions in Opnet. When I picked up > ns-2 the first time, I found the "full TCP" code was full of bugs and > the oTcL/C++ interaction made it much harder to code your own models. > So, I think I'm supporting Detlef and those who say it's important to > read through the models and to know what you are modeling and to know > what the goals of your simulation are. I'm sort of looking for something > without the baggage of ns-2 these days. Has anyone used Omnet++? > > Perspective is a good thing to have in life. Especially when it comes > to the use of simulation. I'm not sure we can expect the average > grad student to have such perspective, but it seems like it might > reasonably be expected of those who advise graduate students. > > respectfully, > Kathie Nichols -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 479 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050915/1d920980/signature.bin From s.malik at tuhh.de Thu Sep 15 16:15:34 2005 From: s.malik at tuhh.de (sireen malik) Date: Fri, 16 Sep 2005 01:15:34 +0200 Subject: [e2e] (no subject) is now An-email-war-in-the-making subject In-Reply-To: <4329B6A1.6060101@web.de> References: <4329B6A1.6060101@web.de> Message-ID: <432A0096.2060303@tuhh.de> Detlef Bosau wrote: > > ..............and when I try to get a job in Germany at the age of 42 > and the copmpanies don?t hire german inhabitants, particularly no half > dead perons, but younger, mostly asian competitors which currently > overwhelm our country, this is anything but a comfortable > situation.............but that?s the attitude of a 42 years old > computer scientist who hunts a job for about two years now and sees > well situated asian IT guyes the whole day each time he leaves his > appartment. I bow to your scientific genius, and promise to you on the behalf of all the Asians in Germany that we, the well situated Asian IT guys, will try our best to make your situation in Germany more comfortable. We also solemnly pledge to stay inside our rat-holes when ever you leave your apartment in future - rather we will go to the neighboring city, to not disturb your seeing pleasure. May all the saints (including the blessed Roger Moore) be with the rest of your wonderful scientific years. -- Sireen Malik Hamburg, Germany From detlef.bosau at web.de Thu Sep 15 16:55:24 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 16 Sep 2005 01:55:24 +0200 Subject: [e2e] Is sanity in NS2? References: <30131a341525ca75ecb3eef3f56a722d@ece.gatech.edu> Message-ID: <432A09EC.27795A8D@web.de> George Riley wrote: > > I've restrained from replying until now, but must jump in. > > Yogesh Prem Swami wrote: > > I have a somewhat general question about simulations. My question is > > that is there any scientific reason why simulations should be able to > > predict the behavior of a real packet transmission phenomena? Unless > > you > > make the assumption that packet transmission/interaction is a > > non-chaotic phenomenon (chaotic, as used in physics), there is no > > reason > > to believe why a simulation would be able to model real world events. > > What chaotic behavior are you talking about? The behavior of a TCP > endpoint is completely deterministic. Given a set of data demands on It?s great :-) I?ve heard countless times, sometimes enriched with an arrogant "as we all know": "The Internet is self similar." Not that I?ve heard a proper definition for self similarity each time. And typically, self similarity, long range dependency and chaotic behaviour are mentioned together. I don?t have any knowledge about this, but I?m always curious when I read this. > a TCP connection, and a given network topology with no competing > flows, the endpoint will do exactly the > same thing every single time. The behavior of a router with a fixed > size > DropTail queue and a fixed set of links will behave exactly the same way > every time, given an arrival pattern of packets. Both of the above > statements > are ignoring small variations in interrupt response times and process > scheduling > at the systems in question, but these variations are small and can be > ignored > without affecting measured results. George, did you by some chance read my remark that the NS2 is for networks what Google is to reality? Did you _count_ the number of assumptions you made? I absolutely agree with you: If we made the network to behave exactly like the NS2, the NS2 would yield a perfect network simulation. However, we make quite a few abstractions here. And of course, many of them are justified. However, many are questionable. Perhaps, it?s time to refer to my favourite paper here once more :-) @article{martin, journal = " IEEE/ACM TRANSACTIONS ON NETWORKING", volume ="11", number = "3", month = "June", year = "2003", title = "Delay--Based Congestion Avoidance for TCP", author = "Jim Martin and Arne Nilsson and Injong Rhee", } One important point made by the authors is, that they simply _failed_ to reproduce the behaviour on L2 as it was measured in real networks. I did not follow the details, but I think they replaced the link model by something which reproduced the pracitcally measured observation. This perfectly corresponds to Kathies statement, that it is difficult to extrapolate from the typical "mini scenarios" used in the NS (Dumbbell, Dumbbell++, Dumbbell light...) and perhaps some funny WWW simulations with even 1000 nodes in it to the global Internet. Moreover, I?m interested in mobile wide area wireless networks like UMTS or GPRS. And at least the _physical_ constraints in a radio channel can hardly be reproduced. And I?m looking eagerly for appropriate models. However, basically the whole thing very much depends on what you want to simulate. So to say: An answer is hardly better than its question. Some of my beloved reviewers told me to make the scenario more complex, to add cross traffics etc. etc. etc. Why? Of course, I have to "simulate all scenrios, Mr. Bosau, it?s a matter of industry". The number of scenarios in the Internet is infinite. So, the old saying becomes true: More is less. And the art of simulation is the art of abstraction and simplification. I?m convinced that a proper posed question can be answered well with a proper chosen scenario. However, even in my PTE work, I don?t want to simulate "the Internet". I look for answers for very special questions. However, I do abstraction and simplification here. I found David Reed?s remark helpful here. Newton?s Principia as the "apple simulation". Sounds funny. But it?s the basic modeling approach taken in physics! And we know, that the Principia is an abstraction. As such, it does not explain "the world", but it sheds light on a number of basic questions. > > The job of the simulator is to recreate these deterministic and well > known > behaviors, without having to construct a real network. A high-quality Well known? Again, I?m dealing with wireless networks. From what I have read during the last five years, the only well known fact we know about mobile wireless networks is that we hardly know anything! And the situation is not better in wirebound networks. Take for example Keshav?s paper on the Ethernet capture effect. Do we find this in the NS? I don?t know, I only ask. So, what we recreate and simulate _is_ already an abstraction. And as such, it is justified. Abstraction and simplification is not a bad thing per se. Although the Principia is an abstraction and simplification it was sufficient to land a man on the moon and return him safely to the earth. The art is to do the _right_ abstraction and the _right_ simplification here. Sometimes, I see the other way round. Particularly some Emulation people tend to reproduce the network as closely as possible. Frankly: I don?t expect that we ever will achieve this goal. And I don?t see a sense in it. The best emulation of reality is _reality_. But the way to _understand_ reality is the art of abstraction and simplification. And the continuous dialog between simplification and reality: Can we make proper forecasts? Do our extrapolations hold in reality? That?s the way we judge our abstractions. > simulator, such as ns2 or GTNetS does exactly this. A competent > programmer > can read the RFC's describing what the TCP endpoint is supposed to do, > and implement a model that does exactly that. BTW, if you haven't seen > the Georgia Tech Network SImulator (GTNetS), it might be worth a quick > look. Google for GTNetS and check it out from our CVS repository. Question (Before I download it and compile it here): How do you simulate a mobile wireless network? How do you abstract, e.g., GPRS? What I?ve seen so far in NS2 is no abstraction but the attempt to simulate each clamp and every cable. Can I rely upon your GPRS simulation in that way, that your simulator properly _predicts_ a behaviour for TCP which can be reproduced in _reality_? > > The above statements are bit tongue-in-cheek of course, because we all > agree that networks are in fact chaotic. But where does this chaotic "As we all konw." Do we know it? Or do we agree upon it? Or can you give a _rationale_, why we expect this? One of my teachers at the Technical University Braunschweig / Germany told me that for asserted "randomness" it?s always important to know, where the randomness stems from. > behavior come from? It comes from unknown and unpredictable behavior > of the end-system applications and users. Again, any good simulator can Really? In random distributions we often observe asymptotic behaviour. (Law of Large Numbers, CLT, Chebyshev?s inequality etc. etc. etc.) So, even if we cannot predict the results from some individual experiment we can do statistics. Why do networks behave different here? Or: Do they? I don?t know. But e.g. Sireen Malik argued using the CLT some few weeks ago. > model this as well, as both ns2 and GTNetS can do. The randomness It?s not the simulator, which does this. It?s our _model_. Our _abstraction_. When I played around with some latencies here during the past few weeks, I wrote a little C program for that. And I can imagine writing some small program for certain purposes when I want to avoid the overhead of NS2. It?s not the simulator. It?s the _model_. Concerning the TCP agents etc., it?s quite simple to implement them properly. Take the RFCs and do the work. And it?s easy to compare your simulated TCP with "reality", at least as it is intended: Compare the code with the RFCs. But how do we simulate a wireless channel? How do we simulate a user?s behaviour? The _simulator_ will do, if the researcher?s _model_ will do. The hammer will do - if the _carpenter_ does his work properly. It?s somewhat similar to the old debate whether we should use C++ or C# or Java or ADA.... Good programming depends primarily on the programmer. Not on the language. A language may have its advantages and I strongly prefer C++ over FOTRAN IV. However, it?s a weak argument as I?m a bad programmer. I know people who do "emulation" and think it?s worthwile to emulate 64 nodes or 640 nodes or 64000 nodes. And when I attend their talks, I see slides, hear endless debates about engineering. But I don?t hear anything about abstraction, reduction, simplification. The strength in Newton?s principia is the simplification and abstraction. _That?s_ what makes science different from engineering. David Reed is absolutely correct here. What is the difference between modelling a network with a discrete event simulator and numerically solve a systems n-dimensional differential equation using a Runge-Kutta algorithm? It?s exactly the same. And the implementation is enginieering. But it?s _science_ to get the correct equations. And simplifactin _is_ an art. I think, it was Michelangelo who said it?s not the problem to build a statue. The statue is already there. It?s the problem to take away the superfluous material. To remove the _right_ amount of marble from the _right_ place. So for GPRS and UMTS, we should leve out these dozens of classes for each clamp and each cable and all this unnecessary trash. The art is to leave the unnecessary things and to keep the correct abstraction and simplification. And then put it into your prefered simulator and it will certainly do. Like a Runge-Kutta algorithm which runs on an IBM machine as well as on an HP machine or a SUN. If you do this correctly, you can leave out nearly the whole world and keep an apple. And you will land a man on the moon and will return him safely to the earth. > is due to randomness in the data demand at endpoints, ignoring > intentional randomness is certain AQM methods such as RED. > But again, the job of the simulator is NOT to intentionally produce > chaotic behavior in a network, but rather to predict what that network > would do, given a set of (possibly random) inputs. I claim that a good > simulation tool can and does do exactly that. I don?t agree here. I absolutely don?t agree. The job of the simulator is to execute my model, as the job of the computer is to execute my program. The _problem_ is to build the correct model The problem is not to build a simulator or to implement the algorithms. Anyone could do this. And as we discussed during the past days, there are numerous simulators around. Yesterday we learned from this wounderful slideset that there has been one in FORTRAN in the 60s. Your input is the model. And if your model of, e.g., chaotic behaviour is correct, your results will be. And if your model is wrong, the results will be. So basically, it?s a model based prediction. Like a predictor corrector approach used in numerics ;-) With the only difference, that our models are the predictor - and reality is the corrector. And it?s one of the aims in science to make corrections as small as possible in the long run. In physics, in weather forecast, in network *mulation. Of course, your simulator is part of the model. Or in other terms: It makes a choice for a certain class of models. E.g. the ns2 is a discrete event simulator. So you model your network behaviour as a sequence of events happening on discrete points in time. And there is no concurrency in it. And we always can put the events in a certain order and get the correct results. It?s again similar to solving differential equations. Perhaps one of our older colleagues can tell us how differnential equations were solved on analogous machinery. This was _continuous_. Whereas todays numerics is _discrete_. It?s perfectly the same. Even in the ns2 it?s obvious: In Tcl, you plumb together your "model" (which of course only represents the topology and a number of scheduled events) and afterwards, the simulator runs, executes, the so defined model. This is exactly the same approach as in simulated annealing and all the thermodynmaic approaches. I don?t think it changed very much during the last centuries. We only are lucky today to have the machinery to do the calculations. But the idea is the same as with the iron ring which is heated until it is white heat on the one half and it?s still cold on the other. Afterwards it?s covered with earth and now we observe what happens. AFAIK, this Gedankenexperiment is due to Jean-Baptiste Fourier and was the motivation for his mathematical work on the Fourier Transform. Now, we have the discrete Fourier Transform, which is to my knowledge due to Kutta (or Runge? I always mix them up) in K?nigsberg in the 1920s. The principle is all the same. Today we heat up the ring in TCL, define the temperature, the radius, the temperature gradient of the material etc. etc. etc. And then we start the simulator, i.e. we cover the ring with earth and observe what happens. Why is this important? What is the lesson learned here? The lesson is: Your results depend on the _model_. Not on your simulator. As for the ring, the simulator is only the blacksmith. In some sense, you will exactly get out what you put in. And in that sense, a simulator is the perfect garbage in garbage out system. The same as any computing machinery. (As long as your simulator is correct, of course.) Once again for the ns2: Did you ever have a glance at the contents of the different directories there? Did you ever observe how many agents and algorithms we have - and how few delay models? And for the nodes, they typically do not model any delay at all. So, we have a pletora of algorithms and protocols there. But what about our _network_ _MODELS_? And what about our traffic models? And what about our user models? And have the contributed mobility models ever been checked against reality? But as I said: That?s not an ns2 problem. It?s the problem of the models. And perhaps, we simply set the wrong focus here. When I deal with 3G networks, my main interest is a proper model of the transport system between Base Station and Mobile. Not the TCP algorithms. My Goodness, one deals with packets, the other one with bytes etc. etc. etc. This is possible, I buy that. But what about the _link_???? Simply compare the length of delay.cc and tcp-full.cc and you see why I question the focus here. (It?s about a factor 12. Guess, what?s more complex.) > > Simulation is not supposed to be a replacement for actual in-vitro > experimentation, but must be used in cases where such experiments > are not possible. Consider Sally's recent work on TCP Quick-Start. Absolutely. > The Quick-Start implementation requires support from routers, to > react to and modify a new options field in the TCP header. Is Sally > supposed to somehow get access to Cisco IOS source code and modify > it to support the new header? Of course not. Is she supposed to get Why "of course not"? Excuse me, but are we doing science or looking for excuses? If the algorithm is to be tested on real routers, Cisco could implement it on an experimental IOS and run it in a testbed. Period. I?ve worked with poorly tested algorithms in reality and I tell you, I wouldn?t buy it if it?s not properly tested. The ns2 model of routers is a rough estimation. We do not (at least to my knowledge from version 2.26) processing times, no memory access times etc. etc. etc. I worked as a support guy for years. Amongst others in a company which built computing machinery for midrange data base systems. There, it was quite simple: When the customer requested a system which served 5000 clients and the customer wanted a real life test, the customer _got_ his real life test. I was responsible for a large customer?s network some years and when I would have brought such an excuse, and we had experienced the _least_ difficulty, the customer would have killed me! It?s of course not Sally?s problem. She can?t help it. But it?s a general problem and we must accept that networks are used in vital systems these days and this is reflected in the user?s claims. > access to Linux source code (easily done) and hack it to support > the new option (not so easily done)? Again of course not. She uses Are we talking about Linux? Or are we talking about IOS? Herer in Stuttgart, some guys assert, Linux is more "real" than the NS2. This is pure nonsense! Linux is Linux, NS2 is NS2 and reality is reality. And these three are different by nature. So we have to decide what we are talking about. You can play around with Linux if you want so use it at the next Linux installation party. But if you plan to use an algorithm with IOS on Cisco routers, you have to validate it in a testbed with IOS and Cisco routers. I think, there should be no debate on it. This is simply a proper engineering attitude. And for Cisco, it?s the reason why at least one company I know refused to buy these systems, because they had great difficulties with ISDN which was not tested properly. And when software "shortcomings" cause a loss of, just to say a number, 1 Million USD a year for a company, I honestly tell you: The company was absolutely _not_ amused! > a simulation tool that she is quite comfortable with, and constructs > both router behavior and end-system behavior as she imagines it will > be implemented in the future, and demonstrates the differences in > performance using Quick-Start. In this case, clearly a field experiment > is not possible. It?s again a matter of modeling. And the model must allow to extrapolate the result for a large number of routers. If not: I assure you, the customer _INSISTS_ in a field experiment and I do understand this. I think, we must accept the limitations of simulations. And basically: These are limitations in our models. Once again: The apple was sufficient to land a man..... So, of course, we have to check our models against reality. This might be quite abstract models. At the KiVS there was a talk given by Matthias Scheidegger from the University of Bern, Switzerland, Department of Torsten Braun, who discussed exactly that. Building a _model_ for a certain portin of the Internet and put it into the NS2. It?s trivial to put this into the NS2. The _problem_ is to build the models. > > The criticism that simulation tools, such as ns2, are responsible for a > plethora of poor quality networking research is just bogus. The I agree here :-) And it?s clear, why I do so :-) > simulator > is a tool who's job it is to predict what a given network will do under > a > given set of conditions. The researcher is responsible for deciding > what > is a reasonable set of conditions to be used to study a given problem. Not only. The researcher is responsible for the correct _model_. And in my estimation we put to much emphasis into algorithms and implementations and far too less emphasis into correct models. And this is not only making a scenario great and complex but to keep the important thins and leave out the unimportant ones. Once again: The art of simulation is the art of abstraction, reduction and simplification. > ns2 and GTNetS and the other simulation tools will uphold their end of > the bargain, it is the researcher's responsibility to uphold their end. This is correct. But I disagree with your focus. The simulator does not simulate a network. Neither does an emulator emulate a network. All this machinery runs models and such is Garbage In Garbage Out by nature. The real _art_ is to build the correct models. To find the correct abstractions, to find the correct simplifications and reductions. Anything else is routine engineering and well understood for decades. Detlef. > > George > > ------------------------------------------------------------------------ > -------------------- > George F. Riley, Assistant Professor > The School of Electrical and Computer Engineering at Georgia Tech > Atlanta, GA 30332-0250 > (404)-894-4767 > E-Mail: riley at ece.gatech.edu > > ECE3090 Web Page: http://users.ece.gatech.edu/~riley/ece3090/ > ECE6110 Web Page: http://users.ece.gatech.edu/~riley/ece6110/ -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From dpreed at reed.com Fri Sep 16 00:47:56 2005 From: dpreed at reed.com (David P. Reed) Date: Fri, 16 Sep 2005 03:47:56 -0400 Subject: [e2e] Reputation systems In-Reply-To: <20050915142707.GE11795@colt.internal> References: <20050915142707.GE11795@colt.internal> Message-ID: <432A78AC.8030807@reed.com> Just a thought. Most countries have libel and slander laws and suchlike, and those laws include specific precedents and means to recover damages for harm to "reputation". If you choose to use the metaphoric notion of reputation for a system that blocks connectivity among people and their agents, and even more, to embody it in a quantifiable and economically measurable technology, you almost certainly will entangle the system with existing precedent and law. I've had in passing the thought of investing in a startup whose business model will be based on litigating disputes regarding reputation systems. Sounds like easy money, especially via picking the pockets of engineers and business investors who don't think carefully through the complex social implications of trying to enforce their preference architectures on others. While I have better things to do, there are lots of litigious types who may see this as a profitable activity or one that embodies and escalates vigilantism... Nuance is important here - there is a legal difference between not vouching for someone or something and vouching against someone or something. From mallman at icir.org Fri Sep 16 06:00:08 2005 From: mallman at icir.org (Mark Allman) Date: Fri, 16 Sep 2005 09:00:08 -0400 Subject: [e2e] Reputation systems In-Reply-To: <432A78AC.8030807@reed.com> Message-ID: <20050916130008.83E6D356486@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20050916/3a6d61d6/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050916/3a6d61d6/attachment.bin From braden at ISI.EDU Fri Sep 16 09:15:39 2005 From: braden at ISI.EDU (Bob Braden) Date: Fri, 16 Sep 2005 09:15:39 -0700 Subject: [e2e] The purpose of the end2end-interest list Message-ID: <5.2.1.1.2.20050916091133.01ebabe0@boreas.isi.edu> AHOY!!! I would like to remind people that the purpose of this mailing list is discussion of research issues related to the Internet architecture, present and future, as well as specific issues at the transport layer and above and, in some cases, (e.g., IP multicast) at the Internet layer. Bob Braden From floyd at icir.org Fri Sep 16 10:05:59 2005 From: floyd at icir.org (Sally Floyd) Date: Fri, 16 Sep 2005 10:05:59 -0700 Subject: [e2e] Is sanity in NS2? Message-ID: <200509161706.j8GH5xwv046179@cougar.icir.org> Ran - >Unfortunately, submitted papers that both use unvalidated models >and use them in an unvalidated scenario are all too common. The newly-created Transport Modeling Research Group (TMRG) is working towards creating Best Current Practice sets of simulation and testbed scenarios for the evaluation of congestion control mechanisms. These are not intended to be complete benchmarks, but just "you should have tested with these scenarios also". Towards that end, two documents have been written so far, "Metrics for the Evaluation of Congestion Control Mechanisms" and "Tools for the Evaluation of Simulation and Testbed Scenarios". http://www.icir.org/tmrg/ Any feedback and contributions would be welcome, on the tmrg mailing list. Abstracts are below, for those who are interested. Many thanks. - Sally Metrics for the Evaluation of Congestion Control Mechanisms: This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. This document is intended to be the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols. Tools for the Evaluation of Simulation and Testbed Scenarios: This document describes tools for the evaluation of simulation and testbed scenarios used in research on Internet congestion control mechanisms. We believe that research in congestion control mechanisms has been seriously hampered by the lack of good models underpinning analysis, simulation, and testbed experiments, and that tools for the evaluation of simulation and testbed scenarios can help in the construction of better scenarios, based on better underlying models. One use of the tools described in this document is in comparing key characteristics of test scenarios with known characteristics from the diverse and ever-changing real world. Tools characterizing the aggregate traffic on a link include the distribution of per-packet round-trip times, the distribution of packet sequence numbers, and the like. Tools characterizing end-to- end paths include drop rates as a function of packet size and of burst size, the synchronization ratio between two end-to-end TCP flows, and the like. For each characteristic, we describe what aspects of the scenario determine this characteristic, how the characteristic can affect the results of simulations and experiments for the evaluation of congestion control mechanisms, and what is known about this characteristic in the real world. We also explain why the use of such tools can add considerable power to our understanding and evaluation of simulation and testbed scenarios. From jordan.auge at rd.francetelecom.com Mon Sep 19 08:39:49 2005 From: jordan.auge at rd.francetelecom.com (Jordan =?iso-8859-1?q?Aug=E9?=) Date: Mon, 19 Sep 2005 17:39:49 +0200 Subject: [e2e] Fwd: Re: Is sanity in NS2? In-Reply-To: <432ED965.6090300@rd.francetelecom.com> References: <200509190934.48049.jordan.auge@rd.francetelecom.com> <432ED965.6090300@rd.francetelecom.com> Message-ID: <200509191739.49950.jordan.auge@rd.francetelecom.com> Je m'acharnais sur le papier Eurongi du coup je n'ai m?me pas pris le temps de jeter un oeil aux papiers... Effectivement si c'est le cas ca pourrait ?tre int?ressant de lui soumettre nos id?es. J'essaie de lire les papiers d'ici demain. jordan > Int?ressant. > J'ai rapidement jet? un coup d'oeil aux 2 drafts. Dans les paragraphes > "Methodology", il n'y a aucune mention de mod?le de trafic dynamique (? > part une mention du "multiplexage statistique" dans le doc. sur les > m?triques, et l? ce nest pas clair ce que ?a sous entend). > On devrait poster quelque chose ? la redoutable Sally Floyd! > > sara > > Jordan Aug? a ?crit : > >Salut, > > > >Je ne sais pas si tu re?ois les mails de la liste e2e. A tout hasard je te > >forwarde ce mail de S. Floyd pour info. > > > >jordan > > > >---- > > > >>Unfortunately, submitted papers that both use unvalidated models > >>and use them in an unvalidated scenario are all too common. > > > >The newly-created Transport Modeling Research Group (TMRG) is working > >towards creating Best Current Practice sets of simulation and testbed > >scenarios for the evaluation of congestion control mechanisms. > >These are not intended to be complete benchmarks, but just "you > >should have tested with these scenarios also". Towards that end, > >two documents have been written so far, "Metrics for the Evaluation > >of Congestion Control Mechanisms" and "Tools for the Evaluation of > >Simulation and Testbed Scenarios". > > > >http://www.icir.org/tmrg/ > > > >Any feedback and contributions would be welcome, on the tmrg mailing > >list. Abstracts are below, for those who are interested. > > > >Many thanks. > > > >- Sally > > > >Metrics for the Evaluation of Congestion Control Mechanisms: > > > > This document discusses the metrics to be considered in an > > evaluation of new or modified congestion control mechanisms for the > > Internet. This document is intended to be the first in a series of > > documents aimed at improving the models that we use in the > > evaluation of transport protocols. > > > > > >Tools for the Evaluation of Simulation and Testbed Scenarios: > > > > This document describes tools for the evaluation of simulation and > > testbed scenarios used in research on Internet congestion control > > mechanisms. We believe that research in congestion control > > mechanisms has been seriously hampered by the lack of good models > > underpinning analysis, simulation, and testbed experiments, and that > > tools for the evaluation of simulation and testbed scenarios can > > help in the construction of better scenarios, based on better > > underlying models. One use of the tools described in this document > > is in comparing key characteristics of test scenarios with known > > characteristics from the diverse and ever-changing real world. > > Tools characterizing the aggregate traffic on a link include the > > distribution of per-packet round-trip times, the distribution of > > packet sequence numbers, and the like. Tools characterizing end-to- > > end paths include drop rates as a function of packet size and of > > burst size, the synchronization ratio between two end-to-end TCP > > flows, and the like. For each characteristic, we describe what > > aspects of the scenario determine this characteristic, how the > > characteristic can affect the results of simulations and experiments > > for the evaluation of congestion control mechanisms, and what is > > known about this characteristic in the real world. We also explain > > why the use of such tools can add considerable power to our > > understanding and evaluation of simulation and testbed scenarios. -- Jordan Aug? T?l?phone 01 45 29 59 55 France T?l?com Division R&D - CORE/CPN (pi?ce 005 Bat. B) 38-40, rue du G?n?ral Leclerc - 92794 Issy les Moulineaux Cedex 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050919/83783c2b/attachment.bin From jordan.auge at rd.francetelecom.com Mon Sep 19 08:56:24 2005 From: jordan.auge at rd.francetelecom.com (Jordan =?iso-8859-1?q?Aug=E9?=) Date: Mon, 19 Sep 2005 17:56:24 +0200 Subject: [e2e] Fwd: Re: Is sanity in NS2? In-Reply-To: <200509191739.49950.jordan.auge@rd.francetelecom.com> References: <200509190934.48049.jordan.auge@rd.francetelecom.com> <432ED965.6 090300@rd.francetelecom.com> <200509191739.49950.jordan.auge@rd.francetelecom.com> Message-ID: <200509191756.24819.jordan.auge@rd.francetelecom.com> Hi, Sorry for my previous post, please consider ignoring it. My email client had wrong when setting the reply address... jordan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050919/76c7ef0d/attachment.bin From jtk at northwestern.edu Mon Sep 19 09:58:50 2005 From: jtk at northwestern.edu (John Kristoff) Date: Mon, 19 Sep 2005 11:58:50 -0500 Subject: [e2e] Is RED dead? Message-ID: <20050919165850.62936136C82@aharp.ittns.northwestern.edu> Intuitively I've felt RED was a reasonable and worthwhile AQM mechanism for some time. I've even witnessed some success in using it some time back: as have others. I've come to another situation where I could again enable it, but for completely different reasons and for potentially much loftier goals. I've recently been told by a trusted and clueful colleague that RED is a "compromised concept" and a "dead horse". That surprised me a bit and I've been trying to understand why. I've been reading and reviewing as much of the recent research and implementation reports I can find. It seems there has been a significant withering of interest in RED since about 2001 so there seems to be some truth in my friend's sentiments. Though I'm not convinced it is completely compromised. I realize the problem of tuning RED parameters and I believe most implementations have not embraced later enhancements to the basic algorithm. So I am looking for second opinions on the utility of RED generally and also practically from the operators that I know frequent this list. For the former group, is RED (or something like it) no longer required for the Internet, contrary to to RFC 2309? For the operational people, I know congestion may not be an operational problem for you, but for those that might have congestion on tail circuits to customers or in years past, were there other operational problems with enabling RED? John From randy at psg.com Mon Sep 19 11:25:27 2005 From: randy at psg.com (Randy Bush) Date: Mon, 19 Sep 2005 08:25:27 -1000 Subject: [e2e] Is RED dead? References: <20050919165850.62936136C82@aharp.ittns.northwestern.edu> Message-ID: <17199.663.737847.284956@roam.psg.com> wred is used in real network deployments, though not as widely as it likely should be. randy From doug.leith at nuim.ie Tue Sep 20 05:59:14 2005 From: doug.leith at nuim.ie (Douglas Leith) Date: Tue, 20 Sep 2005 13:59:14 +0100 Subject: [e2e] HTCP available in Linux 2.6.13 Message-ID: <9452BCDA-0533-4BF2-82E1-9866961CE205@nuim.ie> Just a short note to let people know that the H-TCP changes to TCP for high bandwidth-delay product paths are now included as part of the latest Linux 2.6.13 kernel release (functionaility is controlled via sysctl's). Doug Hamilton Institute www.hamilton.ie From doug.leith at nuim.ie Tue Sep 20 08:39:44 2005 From: doug.leith at nuim.ie (Douglas Leith) Date: Tue, 20 Sep 2005 16:39:44 +0100 Subject: [e2e] HTCP available in Linux 2.6.13 Message-ID: <2C651F25-9164-4603-86B9-D7EADD920B93@nuim.ie> Just a short note to let people know that the H-TCP changes to TCP for high bandwidth-delay product paths are now included as part of the latest Linux 2.6.13 kernel release (functionaility is controlled via sysctl's). Doug Hamilton Institute www.hamilton.ie From bless at tm.uka.de Wed Sep 21 03:05:39 2005 From: bless at tm.uka.de (Roland Bless) Date: Wed, 21 Sep 2005 12:05:39 +0200 Subject: [e2e] Is sanity in NS2? In-Reply-To: <43295F54.8000007@it.uu.se> References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> <43295F54.8000007@it.uu.se> Message-ID: <43313073.8040009@tm.uka.de> Hi, Erik Nordstr?m wrote: > I totally agree with the statement above. Comparison to reality is the > only way to do validation. Yes, that's why we ported a real FreeBSD TCP/IP stack into the OMNeT++ simulator. And guess what: it works very well. See http://www.omnetpp.org/article.php?story=20050702071848785 for more information. Background: Some years ago I started to look for simulators and found ns-2. However, at this time it was even so complex to understand that I turned to a (IMHO much) better alternative: OMNeT++ (http://www.omnetpp.org/). It is open source and free for academic use. It is written in C++, very well-structured and easy to learn (comes with a comprehensive and easily readable documentation). It is also more generic than NS and offers a better scalability. Furthermore, you don't have to program in OTcl, which I also found as an obstacle to learn ns-2. Some people mentioned to rewrite ns-2 to from scratch. I disagree. People should have a look at OMNeT++ and give it a try... A disadvantage of OMNeT++ is, however, that it has far less models available compared to NS-2. The existing TCP implementations seemed to be bogus at this time, and, getting all bugs out of a full-featured TCP implementation is really not easy. Therefore, we decided to use an existing TCP implementation in order to integrate it into the simulator. (There is also a WSC paper how this were actually done: http://doc.tm.uka.de/2004/bless-doll-omnettcp-wsc2004.pdf) > That brings me to another point. Why do people abstract away more than > necessary in simulators? Why can't ns for example use real packet > headers and treat packets in the way a real OS does it? If people claim > the reason is for efficiency I can point out that the current way ns > deals with packets and headers is not exactly optimal. If ns would > implement or mimic real API:s (e.g., berkeley sockets) to the extent > possible, without sacrificing too much performance and scalability, it > would be much easier to develop protocol code that can run both in > reality and simulation. That way validation with reality is so much > easier and trust in the code (that it does the right thing) would > increase tremendously. Yes, that's what OppBSD can do... > For my own implementations, I have gone to great lengths to make sure > that my code runs both in reality and in ns-2 (without emulation layers > or similar). This has made it possible to deploy the same code in real > testbeds and has allowed us to run real experiments and simulations in > parallel. This way we have discovered many false assumptions made in > other research that rely solely on simulations. It is also possible to > do trace based simulation instead of using the de-facto standard ns-2 > randomly generated scenarios that have little resemblance to reality. > > I think simulators are heavily over-utilized in our reasearch field, > simply because we are geeks that are too lazy to do real experiments. I > think we should put our efforts in developing good methodologies for > conducting repeatable real world experiments instead. Simulation should > only be used where and when it can be a complement. Hmm, I think that it is still necessary to do simulations, especially if you want to analyze scalability issues in scenarios with several thousand nodes (which I use in OMNeT++). Validation of the implemented protocols is however important and the hard part of it. Regards, Roland From bless at tm.uka.de Wed Sep 21 03:19:35 2005 From: bless at tm.uka.de (Roland Bless) Date: Wed, 21 Sep 2005 12:19:35 +0200 Subject: [e2e] end2end-interest Digest, Vol 19, Issue 11 In-Reply-To: <4329BD07.8050701@mountainfog.com> References: <4328A44B.7040700@nokia.com> <432949E2.2010602@reed.com> <4329BD07.8050701@mountainfog.com> Message-ID: <433133B7.3040004@tm.uka.de> Hi Kathie, Kathleen Nichols wrote: > ns-2 the first time, I found the "full TCP" code was full of bugs and > the oTcL/C++ interaction made it much harder to code your own models. > So, I think I'm supporting Detlef and those who say it's important to > read through the models and to know what you are modeling and to know > what the goals of your simulation are. I'm sort of looking for something > without the baggage of ns-2 these days. Has anyone used Omnet++? Yes, I use OMNeT++ since several years extensively. And it doesn't have all the baggage of ns-2, it is extremely efficient and even supports good random number generators like the Mersenne Twister out of the box... The simulator code is very well documented and really nice. Thus, it is extremly easy to understand and learn. However, it doesn't have so many protocol models like ns-2, but the contributing community is still growing. I actually simulated networks with "real" AS topologies (extracted from BGP routing tables) up to 11000 ASs. And as I already mentioned in my other posting: if you're interested in a relatively bug-free TCP implementation, you could try to use OppBSD which provides a TCP/IP stack from FreeBSD 4.9 in OMNeT++ (http://www.omnetpp.org/article.php?story=20050702071848785). Best regards, Roland From detlef.bosau at web.de Wed Sep 21 03:55:32 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 21 Sep 2005 12:55:32 +0200 Subject: [e2e] Is sanity in NS2? References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> <43295F54.8000007@it.uu.se> <43313073.8040009@tm.uka.de> Message-ID: <43313C24.71735B71@web.de> Roland Bless wrote: > > Hi, > > Erik Nordstr?m wrote: > > I totally agree with the statement above. Comparison to reality is the > > only way to do validation. > > Yes, that's why we ported a real FreeBSD TCP/IP stack into the OMNeT++ > simulator. And guess what: it works very well. I believe that. Let?s look what you have now: You hava an OMNET++ simulator with a BSD stack. And hopefully, you get a paper from that, good luck! However, you replaced one simulation by another. Did you by chance read my reply on George?s post at the end of last week? IIRC, I?ve written there, that?s no problem to implement TCP into a simulator. And btw: I don?t want to discuss whether Linux is reality or BSD (of course, BSD is considered the reference implementation), I personally have great respects for _standards_. So, a TCP implementation should always be done RFC conformant. BTW: IIRC, a great deal of the NS2 implementation of TCP was done by Sally herself. So, the person who wrote the standards and the person who proposed TCP/Reno and the person who wrote the code were identical. That?s great! Why did you write a new implementation? And this is the normal situation. When I worked with TCP/Snnop, I compared Hari Balakrishnan?s code for BSD and the NS2 more or less line by line. And believe me: Despite the parts where the NS2 and BSD are that different that different coding is _required_, I think the same problem arises in OMNET++, the code is identical. Great! However, my point was not to discuss TCP implementations. This is implementation work. I?m interested in the behaviour of wireless networks. So, in NS2 terminology: Forget about the NS2 except one only class/source file: delay.h and delay.cc. Anything else I?m willing to buy, _this_ one, I _don?t_ . And that?s the only justification to discuss this here, because this list is not concerned with implementation details of network simulators. However, it?s concerned with architectural issues in TCP, and therefore the question whether a wireless link raises architectural issues by it?s nature is stronly on topic. So, the discussion is: How do we simulate a wireless link? And the only way to validate a model for that is to compare a model with reality. (Advantages and disadvantages of simulators) Some few weeks ago, I thought about whether delay spreading could alleviate a delay spike or not. Result: It can. So, I needed a "simulator". O.k. The C++ program was about 100 lines long. Of course, they are situations where the whole overhead of a simulator is not necessary and I can do the implementation work myself. However, this raises another question we talked about last week: Who will ever believe me? Jon argued, that first the code should be made available, then we may publish the papers. From this point of view, the ns2 is basically a commonly accepted and commonly used simulator which is pretty well known to the vast majority of researchers in this area. Even more, you will find that a lot of source code was contributed by the authors of the original papers and PhD theses. This is one of the particular strength of he ns2. > > Hmm, I think that it is still necessary to do simulations, especially > if you want to analyze scalability issues in scenarios with several > thousand nodes (which I use in OMNeT++). > > Validation of the implemented protocols is however important and > the hard part of it. What do you want to validate here? Do you want to validate that the protocols are logically correct? This is one point. Admittedly, I don?t know whether a network simulator is the right tool for this or whether you would better use tools for temporal logic or something like that. If you are interested in the behaviour of TCP in wireless networks, how bursty the traffic will be, how often delay spikes will happen, my primary focus is the link model and the delay model. And I would be lucky to talk about that to colleagues. Perhaps, there is a particular mailing list dealing with this issue, I would appreciate any hint. Also, I appreciate some offlist discussions here because it?s not the core interest of this mailing linst. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Wed Sep 21 10:54:59 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 21 Sep 2005 19:54:59 +0200 Subject: [e2e] Is sanity in NS2? References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> <43295F54.8000007@it.uu.se> <43313073.8040009@tm.uka.de> <43313C24.71735B71@web.de> <4331621D.7040300@tm.uka.de> Message-ID: <43319E73.B14E52FB@web.de> Roland Bless wrote: > > Detlef Bosau wrote: > > > Let?s look what you have now: You hava an OMNET++ simulator with a BSD > > stack. > > And hopefully, you get a paper from that, good luck! > > > > However, you replaced one simulation by another. Did you by chance read > > my reply on George?s post at the end of last week? > > It was rather lengthy, but I surely agree on the fact that > you must decide up to which degree of abstraction you want to > model your problem. If you don't care about TCP > dynamics/behavior/performance etc, then you probably don't need > to simulate TCP below your protocol. That?s not my point. I?m "thinking" on L2 most of my time, so TCP is not below me, it?s above me :-) Let me give you just one example. TCP is sensitive against delay spikes. And there are quite a few papers who claim delay spikes are often. Some others say: delay spikes are rare. So: Do delay spikes occur? Do spurious timeouts occur? Honestly: I don?t know. I can do simulations - and I?m afraid I would fool myself. I?m eager to know: Do spurious timeouts happen? And how often do they happen? And both I want to know about reality. > > The simulator is indeed only a tool to run the model, but as in > reality: a good, high quality tool makes life easier. Absolutely. All I wanted to say is: There are much simulators around. So basically we know how to write a discrete event simulator. The problem is the lack of validated models. Years ago, someone asked me: What is special in wireless networks? Why must they be treated different from wirebound ones? The longer I think about it, it becomes clear to me: The first question is: _Do_ wireless networks differ from wirebound ones? Must we really treat them different to wirebound ones? In all simulations, I?ve seen so far, the discussion was: Question: Are wireless networks different? Assumption: Wireless networks are different. Bla Bla Bla Reusult: Wireless networks are different! Proof by repeated assertion. You can do this with any simulator you want, even with paper and pencil. I?ve _never_ seen a comparison "model vs. reality". Perhaps, there is one. However, I did not see one yet. Sometimes, I even think: TCP works just fine and has no problems with wireless networks. > > > IIRC, I?ve written there, that?s no problem to implement TCP into a > > simulator. And btw: I don?t want to discuss whether Linux is reality or > > It doubt that, since it's really a lot of effort to get it right. > That depends upon the part of reality you talk about. Implementing or building a construction from standards was first done, let me think, by Imhotep, IIRC ;-) Validating a theory is a different story. It?s not a theory to implement TCP. It?s reading, understanding and obeying standards. And it has been done dozens of time before. So, the question is: What is the theory we want to validate? And how is this achieved? It?s exactly the same as Heinrich Hertz provided an experimantel proof for electromagnetic waves, the existence of which is follows from Maxwell?s equations. It?s exactly the same as the theory of the "Ether", which was experimantally falsified by Michelson and Morley. > > BSD (of course, BSD is considered the reference implementation), I > > personally have great respects for _standards_. So, a TCP implementation > > should always be done > > RFC conformant. > > Yes, but besides the fact that it's even not easy to determine which > RFCs are relevant (cf. This is a problem. And when you talk to engineers not coming from CS, they often propose to fix that. Propper standards are an outcome of propper engineering. > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-04.txt), > currently the IETF doesn't define conformance tests (which is ok for > me). So especially, if you want to analyze TCP performance, you need a > very detailed TCP model and you have to test nearly every particular > externally visible TCP behavior (like response to different loss > sequences etc.). This would mean to run and evaluate many test > scenarios, which would be different from running interoperability and > functional tests only. O.k. Which scenarios to you choose? (All, of course. However, the number is infinite.) And what is your TCP model? A numerical one (Padhye, Mathis....)? A reference implementation? This can be compared to reality. If you choose a simulator: How do you simulate the links? How do you simulate the routers? Recently, Keshav posted a list of delays experienced by a TCP packet. The ns2 simulates two of them. Serialization delay and propagation delay. Anything else is neglected. If you, e.g., consider a network with a huge number of nodes, can you neglect the processing time for a packet at a router with a routing table consisting of 20.000 lines? Perhaps, you want to compare greedy routing with MPLS and its consequences on TCP throughput. So, the processing time and its model is the place where you can inject the desired result. Who may judge whether you simply fooled yourself or intendedly produced fraudulent artifacts? Let?s make the situation more complicated. Researcher A uses OMNET++, researcher B uses ns2. The results contradict. Which simulator is closer to reality? > > > BTW: IIRC, a great deal of the NS2 implementation of TCP was done by > > Sally herself. So, the person who wrote the standards and the person > > who proposed TCP/Reno and the person who wrote the code were identical. > > That?s great! Why did you write a new implementation? > > And this is the normal situation. When I worked with TCP/Snnop, I > > compared Hari Balakrishnan?s code for BSD and the NS2 more or less line > > by line. > > And believe me: Despite the parts where the NS2 and BSD are that > > different that different coding is _required_, I think the same problem > > arises > > in OMNET++, the code is identical. Great! > > I don't get that point. You asked for propper implementations of TCP. So, the easiest way is to use existing ones. That?s all I wanted to say :-) In your last post you told us, that an actual TCP stack conforming to BSD was added to OMNET++. That?s wonderful! Its like German industry: "Hi World! We built a car! And it?s running!" Chinese Anwer: > > > However, my point was not to discuss TCP implementations. This is > > implementation work. I?m interested in the behaviour of wireless > > networks. > > Yep, but if you want to look at TCP performance aspects in wireless > networks, a quite detailed TCP model is necessary. Thus you need Excuse me, I don?t follow. If you want to build a TCP throughput modell, you must understand TCP performance aspects in wireless networks. Otherwise, you would not have a solid basis to build a model. Perhaps, we should make clear what?s the model and what?s the implementation? For me, anything what happens in a TCP agent in ns2 is implementation. > a heavily tested implementation (I don't doubt that the ns-2 TCP > implementation is quite good and widely used). > > > details of network simulators. However, it?s concerned with > > architectural issues in TCP, and therefore the question whether a > > wireless > > link raises architectural issues by it?s nature is stronly on topic. > > I don't know exactly what you're interested in, but I think there has > been a lot of research in this area (output like RFC 3522, 4015 etc.) I know :-) Question: Is Eifel necessary? Or does TCP over 3G networks works just fine without any Eifel? IIRC the "hiccup" tool was part of the ns2. Does reality suffer from hiccups as well? Let me put it in extremely sharp words: Are spurious timeouts an artifical phenomenon to base a number of PhD theses upon? Or has it ever been proven to be a real, existing and relevant problem? Or in terms of models: Does the hiccup tool model a wireless link correctly? Or is it pure phantasy? I don?t know! And I?m not comfortable with that. From my own attitude, I would request experiments. When "hiccup" is the proposed model, then we must do _experiments_. If it is necessary to compare that model against 1000.000 GPRS flows observed in a period of time of, say, one year, we have to do so. I spent a lot of my time working together with civil engineers. When they proposed a model for the behaviour of steel, a PhD thesis could simply consists of a five years work of putting 20.000 specimens into a testing machine and to validate - or to falsify - the model. If it was necessary to do experiments with 20.000 specimens and all these specimens had to be prepared by handwork - this was done! _That?s_ why you can cross a bridge without being afraid it will crash during the next minute. As a student worker, I had to write programs for measurements done at a bridge, where a fully loaded train was put on the bridge and taken away and put on the bridge again and than left the bridge half way and than drove back and so on. Civil engineers have very sophisticated models. And FEM calculations. Done on large computers. But when it comes to reality, a fully loaded train is driven on a bridge and driven away etc. and the bevaviour of the bridge is measured in reality. And from that, the models are validated - or falsified. > > So, the discussion is: How do we simulate a wireless link? And the only > > way to validate a model for that is to compare a model with reality. > > That depends on what you want to look at. So if you model not > every detail, but the important ones that you're interested in, > then that might be ok. However, like with mathematical models, > you must know what simplifications are reasonable and will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Exactly that?s the question. And that?s why modeling should be done bottom up. Then any step in abstraction is done with a solid basis. And is, _of_ _course_, validated in experiments. Eventually, you can abstract the behaviour of a whole AS or comparable complex structure in a model as it is done e.g. in the group of Torsten Braun. However, these models must be valid. E.g. the processing time at a router is often considered neglectible. However, how much times neglectible is still neglectible? In ns2, I don?t see a user model or application model. We don?t model (it?s neglectible...) how long it will take for a PDA to acknowledge a TCP datagram. Is this neglectible in a network with 10.000 PDA? I don?t know! In my original post, I asked for flow control in ns2. If OMNET++ would provide this, it could be interesting. However, when flow control and dynamic AWND is left out in ns2, the reason is quite obvious: When I want to model the amount of memory available at the receiver stack, I need an application model which models when data is read from the stack. Thus, the simplification may seem unjustified. However, it?s a consequence from the lack of a propper and validated application/user model. The implmentation of TCP flow control is one story. Providing a user model is a different one. And once again, you can inject the desired results here. > likely not affect the qualitative outcome etc. the same is true > for reasoning used traffic patterns etc. Absolutely. Engineering science is mostly concerned with this question. > > > Of course, they are situations where the whole overhead of a simulator > > is not necessary and I can do the implementation work myself. > > However, this raises another question we talked about last week: Who > > will ever believe me? Jon argued, that first the code should > > be made available, then we may publish the papers. From this point of > > The paper should describe all necessary details about the model and > assumptions as requested in the paper from Pawlikowski et al. about > credibility of simulations: > On Credibility of Simulation Studies of Telecommunication Networks, > IEEE Communications Magazine, January 2002, pp. 132--139 It?s interesting what Pawlikowski says there (page 9 of 15): "However, if this is a scientific activity, then one should follow the scientific method. ... This method says that any scientific activity should be based on controlled and independently repeatable experiments..." At least, this does not necessarily hold for a simulation. Although a simulation with the same parameter set is of course repeatable, the so done experiments are not. In fact, you would repeat an error as often as you run the simulation. > > > view, the ns2 is basically a commonly accepted and commonly used > > simulator which is pretty well known to the vast majority of researchers > > in this area. Even more, you will find that a lot of source code > > was contributed by the authors of the original papers and PhD theses. > > This is one of the particular strength of he ns2. > > Yep, agreed, and that was once a main motivation to have ns-2, right? > Its usability is however not always acceptable. That?s correct. However, one motivation for me to use the ns-2 is that I know the relevant parts of the ns2 pretty well now and therefore, I know what I?m doing. (At least I have a rough about idea...) I don?t know whether a simulator will ever be _easy_ to use. I had a glance at the OMNET page this afternoon and OMNET comes with a number of nice screenshots. I personally would appreaciate a toolbox like the ns2, if only the mixed language part could be dropped and anything would be done solely in C++. However, this is not my first interest. At first, I must define _what_ will be simulated and _why_. And I think that?s the most important point. When I use a simulator, I will read (and hopefully understand) large parts of the source anyway. It?s the best documentation ever. (If only the error list in the documentation would be as actual as in the source....) > > > > > > > No, I don't use simulation for prooving protocol correctness. > Simulations are usually good to investigate the qualitative > behavior of a system under variation of certain parameters. Which again rises the question: Which parameters are neglectible, which are relevant? And once again, we have lots of opportunities to inject our results here :-) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From bless at tm.uka.de Wed Sep 21 06:37:33 2005 From: bless at tm.uka.de (Roland Bless) Date: Wed, 21 Sep 2005 15:37:33 +0200 Subject: [e2e] Is sanity in NS2? In-Reply-To: <43313C24.71735B71@web.de> References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> <43295F54.8000007@it.uu.se> <43313073.8040009@tm.uka.de> <43313C24.71735B71@web.de> Message-ID: <4331621D.7040300@tm.uka.de> Detlef Bosau wrote: > Let?s look what you have now: You hava an OMNET++ simulator with a BSD > stack. > And hopefully, you get a paper from that, good luck! > > However, you replaced one simulation by another. Did you by chance read > my reply on George?s post at the end of last week? It was rather lengthy, but I surely agree on the fact that you must decide up to which degree of abstraction you want to model your problem. If you don't care about TCP dynamics/behavior/performance etc, then you probably don't need to simulate TCP below your protocol. The simulator is indeed only a tool to run the model, but as in reality: a good, high quality tool makes life easier. > IIRC, I?ve written there, that?s no problem to implement TCP into a > simulator. And btw: I don?t want to discuss whether Linux is reality or It doubt that, since it's really a lot of effort to get it right. > BSD (of course, BSD is considered the reference implementation), I > personally have great respects for _standards_. So, a TCP implementation > should always be done > RFC conformant. Yes, but besides the fact that it's even not easy to determine which RFCs are relevant (cf. http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-04.txt), currently the IETF doesn't define conformance tests (which is ok for me). So especially, if you want to analyze TCP performance, you need a very detailed TCP model and you have to test nearly every particular externally visible TCP behavior (like response to different loss sequences etc.). This would mean to run and evaluate many test scenarios, which would be different from running interoperability and functional tests only. > BTW: IIRC, a great deal of the NS2 implementation of TCP was done by > Sally herself. So, the person who wrote the standards and the person > who proposed TCP/Reno and the person who wrote the code were identical. > That?s great! Why did you write a new implementation? > And this is the normal situation. When I worked with TCP/Snnop, I > compared Hari Balakrishnan?s code for BSD and the NS2 more or less line > by line. > And believe me: Despite the parts where the NS2 and BSD are that > different that different coding is _required_, I think the same problem > arises > in OMNET++, the code is identical. Great! I don't get that point. > However, my point was not to discuss TCP implementations. This is > implementation work. I?m interested in the behaviour of wireless > networks. Yep, but if you want to look at TCP performance aspects in wireless networks, a quite detailed TCP model is necessary. Thus you need a heavily tested implementation (I don't doubt that the ns-2 TCP implementation is quite good and widely used). > details of network simulators. However, it?s concerned with > architectural issues in TCP, and therefore the question whether a > wireless > link raises architectural issues by it?s nature is stronly on topic. I don't know exactly what you're interested in, but I think there has been a lot of research in this area (output like RFC 3522, 4015 etc.) > So, the discussion is: How do we simulate a wireless link? And the only > way to validate a model for that is to compare a model with reality. That depends on what you want to look at. So if you model not every detail, but the important ones that you're interested in, then that might be ok. However, like with mathematical models, you must know what simplifications are reasonable and will likely not affect the qualitative outcome etc. the same is true for reasoning used traffic patterns etc. > Of course, they are situations where the whole overhead of a simulator > is not necessary and I can do the implementation work myself. > However, this raises another question we talked about last week: Who > will ever believe me? Jon argued, that first the code should > be made available, then we may publish the papers. From this point of The paper should describe all necessary details about the model and assumptions as requested in the paper from Pawlikowski et al. about credibility of simulations: On Credibility of Simulation Studies of Telecommunication Networks, IEEE Communications Magazine, January 2002, pp. 132--139 > view, the ns2 is basically a commonly accepted and commonly used > simulator which is pretty well known to the vast majority of researchers > in this area. Even more, you will find that a lot of source code > was contributed by the authors of the original papers and PhD theses. > This is one of the particular strength of he ns2. Yep, agreed, and that was once a main motivation to have ns-2, right? Its usability is however not always acceptable. >>Hmm, I think that it is still necessary to do simulations, especially >>if you want to analyze scalability issues in scenarios with several >>thousand nodes (which I use in OMNeT++). >> >>Validation of the implemented protocols is however important and >>the hard part of it. > > > What do you want to validate here? Do you want to validate that the > protocols are logically correct? This is one point. Admittedly, Yes. The protocol should behave like it was specified. But the other point is: if you're interested in performance/scalability etc. then you need a quite detailed model. > I don?t know whether a network simulator is the right tool for this or > whether you would better use tools for temporal logic or something like > that. No, I don't use simulation for prooving protocol correctness. Simulations are usually good to investigate the qualitative behavior of a system under variation of certain parameters. Regards, Roland From X.Zhou at ewi.tudelft.nl Thu Sep 22 01:05:18 2005 From: X.Zhou at ewi.tudelft.nl (X.Zhou@ewi.tudelft.nl) Date: Thu, 22 Sep 2005 10:05:18 +0200 Subject: [e2e] question about the iLBC (VoIP) Message-ID: To examine the quality of VoIP, E-Model is often used. The output of the E-model is a transmission ration factor R: R=R0-Is-Id-Ie+A, where R0 represents the basic signal-to-noise ration, Is represents the impairments occurring simultaneously with the voice signal, Id represents the impairments caused by delay, and Ie represents the impairments caused by codecs. Is there any publication gives the Ie value for the codec iLBC? Regards, Xiaoming Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050922/72240388/attachment.html From gianluca.iannaccone at intel.com Thu Sep 22 06:29:47 2005 From: gianluca.iannaccone at intel.com (Iannaccone, Gianluca) Date: Thu, 22 Sep 2005 14:29:47 +0100 Subject: [e2e] JSAC Sampling the Internet: deadline approaching Message-ID: <101EBE844CE72E4F8F72686631823B2B0360A220@swsmsx404> This is a reminder that the submission deadline for the IEEE JSAC Special Issue on "Sampling the Internet: Techniques and Applications" is rapidly approaching (October 1st). The call for papers can be found at http://www.argreenhouse.com/society/J-SAC/Calls/sampling_internet.html Submission can be done online at the following website: http://como.intel-research.net/jsac Submission must be in PDF. You may use the JSAC submission style (see http://www.argreenhouse.com/society/J-SAC/Guidelines/info.html) or the JSAC camera ready style (IEEE Transactions style, two column, single spaced, 10pt font, 13 pages max including figures and tables). Please forward this email to your colleagues and students working on related topics. We look forward to your submission. Guest Editors Chadi Barakat Gianluca Iannaccone Jim Kurose Darryl Veitch From bless at tm.uka.de Thu Sep 22 06:57:55 2005 From: bless at tm.uka.de (Roland Bless) Date: Thu, 22 Sep 2005 15:57:55 +0200 Subject: [e2e] Is sanity in NS2? In-Reply-To: <43319E73.B14E52FB@web.de> References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> <43295F54.8000007@it.uu.se> <43313073.8040009@tm.uka.de> <43313C24.71735B71@web.de> <4331621D.7040300@tm.uka.de> <43319E73.B14E52FB@web.de> Message-ID: <4332B863.9090402@tm.uka.de> Detlef Bosau wrote: > In my original post, I asked for flow control in ns2. If OMNET++ would > provide this, it could be interesting. However, when > flow control and dynamic AWND is left out in ns2, the reason is quite > obvious: When I want to model the amount of memory > available at the receiver stack, I need an application model which > models when data is read from the stack. The OppBSD implementation mimics the normal socket interface (actually the real socket functions are called in the FreeBSD part of the code). I don't think that we excluded the flow control stuff from the FreeBSD TCP implementation. :-) Therefore, OppBSD should offer flow control and all the other stuff that a real OS TCP implementation has. That's exactly one advantage of porting a real implementation (naturally also including any implementation bugs therein). > Thus, the simplification may seem unjustified. However, it?s a > consequence from the lack of a propper and validated application/user > model. Go and have a look at the stuff. OppBSD comes with some example scenarios. Regards, Roland From rmg at it.uu.se Fri Sep 23 07:38:17 2005 From: rmg at it.uu.se (Richard Gold) Date: Fri, 23 Sep 2005 16:38:17 +0200 Subject: [e2e] Is sanity in NS2? In-Reply-To: <43313073.8040009@tm.uka.de> References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> <43295F54.8000007@it.uu.se> <43313073.8040009@tm.uka.de> Message-ID: <43341359.7090201@it.uu.se> Roland Bless wrote: > Yes, that's why we ported a real FreeBSD TCP/IP stack into the OMNeT++ > simulator. And guess what: it works very well. > See http://www.omnetpp.org/article.php?story=20050702071848785 > for more information. It's great to see work like this being done. Thank you for releasing your work to the community. However, I wonder how well this release will be supported. Is there a development team, someone responsible for maintenance and bugfixes, updating it for recent OS/tools, a roadmap for the future? Getting a simulator out the door is extremely important, but it's also critical what happens to it after it is released. If there is no community around it, then it will just be abandoned. I have heard good things about SSFNet, for example, but the latest release was Jan 2004 and as far as I can tell there is no-one continuing this work. I hope that I am just mis-informed. Rightly or not, this severely discourages me from using the simulator. This is the one thing that ns2 has going for it: it's still actively maintained and probably will be in the future too. Whether or not this is a good thing is left as an exercise to the reader... This is, of course, an extremely difficult issue to solve. Can we make it part of the networking research community program to build and maintain a good toolkit for doing research? Cheers, Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3196 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050923/96e26e7f/smime.bin From hoenech at informatik.uni-tuebingen.de Fri Sep 23 09:00:22 2005 From: hoenech at informatik.uni-tuebingen.de (Christian Hoene) Date: Fri, 23 Sep 2005 18:00:22 +0200 Subject: [e2e] question about the iLBC (VoIP) In-Reply-To: <003101c5bf6a$fe4b1820$02a70286@acerxpj7zt8mo5> Message-ID: <20050923155955.D9B5013D@mx3.informatik.uni-tuebingen.de> Dear Xiaoming Zhou, you can calculate the Ie values from MOS values using the procedure given in ITU P.830 and P.833: 1. iLBC MOS values for different packet loss rates are available from GlobalIPsound or http://www.ilbcfreeware.org/. 2. Use the conversation formular given in ITU G.107 or in http://www.tkn.tu-berlin.de/publications/papers/MOS_R2.pdf to calculate the R factor. 3. Subtract the R factors from the R0 value (93.2) to get the Id values. Best regards, Christian Hoene _____ From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of X.Zhou at ewi.tudelft.nl Sent: Donnerstag, 22. September 2005 10:05 To: end2end-interest at postel.org Subject: [e2e] question about the iLBC (VoIP) To examine the quality of VoIP, E-Model is often used. The output of the E-model is a transmission ration factor R: R=R0-Is-Id-Ie+A, where R0 represents the basic signal-to-noise ration, Is represents the impairments occurring simultaneously with the voice signal, Id represents the impairments caused by delay, and Ie represents the impairments caused by codecs. Is there any publication gives the Ie value for the codec iLBC? Regards, Xiaoming Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050923/2f0cb886/attachment.html From bless at tm.uka.de Fri Sep 23 09:11:46 2005 From: bless at tm.uka.de (Roland Bless) Date: Fri, 23 Sep 2005 18:11:46 +0200 Subject: [e2e] Is sanity in NS2? In-Reply-To: <43341359.7090201@it.uu.se> References: <43283AE0.550595CE@web.de> <39465.134.159.99.8.1126736747.squirrel@www.rikwade.com> <43295F54.8000007@it.uu.se> <43313073.8040009@tm.uka.de> <43341359.7090201@it.uu.se> Message-ID: <43342942.9030303@tm.uka.de> Hi Richard, Richard Gold wrote: > It's great to see work like this being done. Thank you for releasing > your work to the community. However, I wonder how well this release will The work started also as a first proof of concept: Is it possible to integrate a nearly unmodified version of an existing real OS network stack implementation into a simulator? > be supported. Is there a development team, someone responsible for > maintenance and bugfixes, updating it for recent OS/tools, a roadmap for > the future? Getting a simulator out the door is extremely important, but Good point. We must differentiate between OMNeT++ (the simulation kernel itself) and OppBSD. OppBSD was the outcome of a master thesis and is currently not a big project by itself, so we do not have dedicated resources assigned to it. However, I supervise a student who is upgrading it to FreeBSD 5.3 and who should integrate IPv6 and Mobile IPv6. So we do have some kind of a roadmap. If you found bugs, we are happy to include your fixes into our public accessible subversion repository. :-) But we do not have a dedicated support team... > it's also critical what happens to it after it is released. If there is > no community around it, then it will just be abandoned. I have heard Yep. > good things about SSFNet, for example, but the latest release was Jan > 2004 and as far as I can tell there is no-one continuing this work. I > hope that I am just mis-informed. Rightly or not, this severely > discourages me from using the simulator. This is the one thing that ns2 > has going for it: it's still actively maintained and probably will be in > the future too. Whether or not this is a good thing is left as an > exercise to the reader... As speaking for the simulation kernel OMNeT++: there is active support and development for OMNeT++ since several years by its main author Andras Varga. He is very responsive if there are problems/bugs or feature requests. However, because he is really eager to improve his simulator, he is working 100% of the time for it. In order to prevent starving to death, Andras provides the commercial variant OMNEST. OMNeT++ comes with an academic public license (see http://www.omnetpp.org/external/license.php) and it is open source, which is really important if you suspect that there is a bug in the simulator and you want to fix it immediately. There are several models under construction in the OMNeT++ community. In this respect it is possibly comparable to ns-2: some models are easy to use and written well, others should better be rewritten from scratch. But it's really the same for all simulators: how far can you trust the model and its implementation? So usually you have to validate it, and, in this respect: the larger the community the better. > This is, of course, an extremely difficult issue to solve. Can we make > it part of the networking research community program to build and > maintain a good toolkit for doing research? This was really a purpose of ns, right? (http://www.isi.edu/~johnh/PAPERS/Bajaj99a.html) However, depending on what you are simulating, there are possibly better and slimmer alternatives to ns-2. Regards, Roland From yschoi at gmail.com Mon Sep 26 00:32:07 2005 From: yschoi at gmail.com (cys) Date: Mon, 26 Sep 2005 16:32:07 +0900 Subject: [e2e] What happen "after slow start" Message-ID: <5a8ce9ca05092600321a5bd623@mail.gmail.com> For high-speed networks, setting initial ssthresh high can be desirable. Suppose, TCP connection just started And, the saturation point(or steady state): cwnd=100 ssthresh : a large value. During slow start, if current cwnd=99, TCP doesn't experience packet loss. but next rtt, cwnd =198 and 98 packets will be dropped. as far as i know, RTO and 3Dup. Ack are the only ways to detect packet loss. if we use Reno, multiple packet losses from a window of data will results in rtx timer expire. Thus, TCP enters slow start again. But many documents and TCP tutorials only shows following case. "Slow start-> pkt loss -> Fast retransmit&Recovery-> congestion avoidance " not "Slow start-> pkt loss -> rtx timer expire-> slow start" I think the latter case will happen more frequenlty than the former case. Are there any special treatment for packet loss during slow start? -- cys From Jon.Crowcroft at cl.cam.ac.uk Mon Sep 26 01:39:45 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 26 Sep 2005 09:39:45 +0100 Subject: [e2e] What happen "after slow start" Message-ID: There's a big fast link we want to get reasonable utilisation on. The reaso nthere's a big fast link is either 1/ its there for a special reason - it goes between two uber-physics labs and we dont really care what people do with it - why run tcp? 2/ its there as part of the internet and was provisioned for some reason - probably, if it is a public part of the internet, then if it has a lot of capacity, but is a hop on any reasonable set of possible end-to-end routes, it is expected to carry a lot of flows. The distribution of access link speeds in the world is not clear, but assuming its drawn from some sort of obvious statistical distribution, with lots of 56kbps->1Mbps DSL, and slightly less 1-nMbps VDSL/Cable, and less 10Mbps->Gbps ethernet and so on and that for any given backbone link they are equally likely to have connections sourced from any and all of these, then it is not reasonable to _in the absence of other special knowledge_ modify the behaviour of a distributed resource allocation algorithm what type of special knowledge could we have (aside from pre-cognition and telepathy)? (note that case 1/ above is also a type of special knowledge - topological restriction on access to the bottleneck). well, we might know about time-of-day traffic variation and take advantage of that. we might have some sort of _oracle_ that we can consult about the distribution of mice/elephant TCP connections currently on the link, which might allow us to set TCP slow start parameters slightly more cleverly. We might do something radical - what could that be? well, if everyone modifies slow start, in the absence of special knowledge, bad things may happen - but if a few modify it, then they may get an unfair advantage. But since people keep asking, when we do not have a magic oracle, is there somethign we could do that would be a way to get high utilsiation when the bottleneck link is in fact under-utilisaed, and to avoid the awfully long bogus adventure that TCP has to engage upon to eventually fulfll the pipe-dream? here's a strawman proposal:- apply the good old fashioned ethernet randomness+contention back/off strategy to the slow start itself: step 1 - host looks in a cache of destinations (in the host routing table) to find a last logged magic number (corresponds to last estimate of number of other folks using the bottleneck on that route) step 2 - throw a dice with that many sides - step 3 - if this host's number comes up, we get to blast away with a big initial send window and a go-faster increase function..., otherwise behave normally Then there's two possible extreme outcomes: a) the net was in use - we cause quite a bit of loss in the first RTT, but of course, (especialy if the net is runnign virtual queues and small buffers, as per damon wischik/nick mckeown et al work) this will settle down to normal behaviour real soon b) the net was idle, and we will fill it ok and not haev to wait ages. over some large number of connection attempts like this, I reckon this is also fair what is needed in the routers in terms of state to improve this hack? well if the router logged in the IGP and EGP the number of connections current on each hop, then this could be a simple value delivered at the edge of any net as a service (or we could have a TCP option to record "someone-elses-point-of-view" (for those who have seen the hitchikers guide to the galazy, you know what i mean) in general, if you see someone elses point of view, when everyone is in the same boat, then you have basically got a good handle on how to behave sociably. anyhow, this is not seriously a proposition, but i think there might be two possible directions to go from here. j. p.s. index I get from vladivostok telephone directory. From Black_David at emc.com Mon Sep 26 06:35:18 2005 From: Black_David at emc.com (Black_David@emc.com) Date: Mon, 26 Sep 2005 09:35:18 -0400 Subject: [e2e] What happen "after slow start" Message-ID: Jon, > There's a big fast link we want to get reasonable utilisation on. > The reaso nthere's a big fast link is either > 1/ its there for a special reason - it goes between two > uber-physics labs and we dont really care what people do > with it - why run tcp? a) Because nothing out there is perfect, and TCP is very good at dealing with little things that go awry when you least expect them. b) Because TCP provides an end-to-end check on whether the link is still behaving as provisioned, although this entails endpoint cluefulness in knowing what to look for and how to make sense of it. > 2/ its there as part of the internet and was provisioned for > some reason - probably, if it is a public part of the > internet, then if it has a lot of capacity, but is a hop on > any reasonable set of possible end-to-end routes, > it is expected to carry a lot of flows. The distribution of > access link speeds in the world is not clear, but > assuming its drawn from some sort of obvious statistical > distribution, with lots of 56kbps->1Mbps DSL, and slightly > less 1-nMbps VDSL/Cable, and less 10Mbps->Gbps ethernet and > so on and that for any given backbone link they are > equally likely to have connections sourced from any and all > of these, then it is not reasonable to > _in the absence of other special knowledge_ > modify the behaviour of a distributed resource allocation algorithm IMHO, what this overlooks is that there is a range of situations between 1 and 2. What's needed is a way for flows that can use high bandwidth to use it when it's available without stomping on "ordinary" flows. There's been no lack of research in this area, to the point that an IRTF RG was announced at IETF in Paris for the express purpose of sorting through all the research ideas and figuring out which one(s) to get serious about. I don't see that group on the IRTF's list of RGs on their web site yet ... > what type of special knowledge could we have (aside from > pre-cognition and telepathy)? > (note that case 1/ above is also a type of special knowledge > - topological restriction on access to the > bottleneck). > > well, we might know about time-of-day traffic variation and > take advantage of that. we might have some sort of > _oracle_ that we can consult about the distribution of > mice/elephant TCP connections currently on the link, which > might allow us to set TCP slow start parameters slightly more > cleverly. We might do something radical - what could > that be? > > well, if everyone modifies slow start, in the absence of > special knowledge, bad things may happen - but if a few > modify it, then they may get an unfair advantage. But since > people keep asking, when we do not have a magic oracle, > is there somethign we could do that would be a way to get > high utilsiation when the bottleneck link is in fact > under-utilisaed, and to avoid the awfully long bogus > adventure that TCP has to engage upon to eventually fulfll the > pipe-dream? > > here's a strawman proposal:- apply the good old fashioned > ethernet randomness+contention back/off strategy > to the slow start itself: > > step 1 - host looks in a cache of destinations (in the host > routing table) > to find a last logged magic number (corresponds to last estimate of > number of other folks using the bottleneck on that route) > > step 2 - throw a dice with that many sides - > > step 3 - if this host's number comes up, we get to blast away > with a big initial send window and a go-faster increase > function..., otherwise behave normally > > Then there's two possible extreme outcomes: > > a) the net was in use - we cause quite a bit of loss in the > first RTT, but of course, (especialy if the net is > runnign virtual queues and small buffers, as per damon > wischik/nick mckeown et al work) > this will settle down to normal behaviour real soon > b) the net was idle, and we will fill it ok and not haev to wait ages. > > over some large number of connection attempts like this, I > reckon this is also fair > > what is needed in the routers in terms of state to improve > this hack? well if the router logged in the IGP and EGP > the number of connections current on each hop, then this > could be a simple value delivered at the edge of any net > as a service (or we could have a TCP option to record > "someone-elses-point-of-view" > (for those who have seen the hitchikers guide to the galazy, > you know what i mean) > in general, if you see someone elses point of view, when > everyone is in the same boat, then you have basically got > a good handle on how to behave sociably. > > anyhow, this is not seriously a proposition, but i think > there might be two possible directions to go from here. Also see draft-ietf-tsvwg-quickstart-01.txt (-02 should be coming out shortly, but it won't change the basic idea of using an IP option to shadow TTL) for a somewhat less random, but similar router-centric approach. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david at emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From mallman at icir.org Mon Sep 26 07:25:34 2005 From: mallman at icir.org (Mark Allman) Date: Mon, 26 Sep 2005 10:25:34 -0400 Subject: [e2e] What happen "after slow start" In-Reply-To: <5a8ce9ca05092600321a5bd623@mail.gmail.com> Message-ID: <20050926142534.F11FC77AA1F@guns.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20050926/f9ae07eb/attachment.ksh -------------- 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/20050926/f9ae07eb/attachment.bin From touch at ISI.EDU Tue Sep 27 16:12:40 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 27 Sep 2005 16:12:40 -0700 Subject: [e2e] What happen "after slow start" In-Reply-To: References: Message-ID: <4339D1E8.80005@isi.edu> Jon Crowcroft wrote: ... > what type of special knowledge could we have (aside from > pre-cognition and telepathy)? (note that case 1/ above is also a type > of special knowledge - topological restriction on access to the > bottleneck). well, we might know about time-of-day traffic variation > and take advantage of that. we might have some sort of _oracle_ that > we can consult about the distribution of mice/elephant TCP > connections currently on the link, which might allow us to set TCP > slow start parameters slightly more cleverly. We might do something > radical - what could that be? > > well, if everyone modifies slow start, in the absence of special > knowledge, bad things may happen - but if a few modify it, then they > may get an unfair advantage. But since people keep asking, when we do > not have a magic oracle, is there somethign we could do that would be > a way to get high utilsiation when the bottleneck link is in fact > under-utilisaed, and to avoid the awfully long bogus adventure that > TCP has to engage upon to eventually fulfll the pipe-dream? > > here's a strawman proposal:- apply the good old fashioned ethernet > randomness+contention back/off strategy to the slow start itself: > > step 1 - host looks in a cache of destinations (in the host routing table) > to find a last logged magic number (corresponds to last estimate of > number of other folks using the bottleneck on that route) > > step 2 - throw a dice with that many sides - > > step 3 - if this host's number comes up, we get to blast away with a > big initial send window and a go-faster increase function..., > otherwise behave normally FYI, we have a small DARPA project here at ISI looking at that, called "Adaptive Learning Networks", which is a kind of "smart RFC2140", i.e., it: Assumes: 1) TCP does a good job converging on TCB state over time, but a lousy job of guessing initial conditions 2) TCP experiences stable stable net over the connection, and stable offered load Does the following: 1) records TCB end-of-connection state, as well as 'kitchen sink' data (weather, endpoint loc, etc.) 2) trains an adaptive learning module on the state data (TCB state:kitchen sink state) 3) sets TCBs of new connections based on predictive lookup (i.e., lookup kitchen sink state and retrieve expected TCB state) This *could* to bad things over the long term. As you point out below, there are ways to mitigate this: a) roll a dice to decide when to do it b) if predictions turn out to be bad, adjust the predictor c) remember that even a long-idle TCP connection will do some of this anyway, so it just makes new TCPs look a little like they were persistent > Then there's two possible extreme outcomes: > > a) the net was in use - we cause quite a bit of loss in the first > RTT, but of course, (especialy if the net is runnign virtual queues > and small buffers, as per damon wischik/nick mckeown et al work) this > will settle down to normal behaviour real soon > > b) the net was idle, and we will fill it ok and not haev to wait ages. > > over some large number of connection attempts like this, I reckon > this is also fair > > what is needed in the routers in terms of state to improve this hack? I'm not sure it requires the participation of routers; we're doing measurements to see if it just works anyway. FYI. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050927/caefef22/signature.bin From keshav at uwaterloo.ca Wed Sep 28 12:22:03 2005 From: keshav at uwaterloo.ca (S. Keshav) Date: Wed, 28 Sep 2005 15:22:03 -0400 Subject: [e2e] TCP 'fast start' In-Reply-To: Message-ID: Hi, The idea of using environmental variables to optimize TCP start goes back a while. It is particularly useful for short transfers that complete before they reach the 'steady-state'. My students and I worked on this in 1999. We used Shared Passive Network Discovery, proposed by Seshan, Stemm, and Katz to discover connection parameters from a cluster of users to a popular destination, say, Yahoo, and used this information to choose initial TCP parameters. Though we only did simulations, our results looked pretty decent, so maybe Joe, you can actually implement our work :-) For more details, please see: Y. Zhang, L. Qiu, and S. Keshav, "Speeding Up Short Data Transfers: Theory, Architecture Support, and Simulation Results," Proc. NOSSDAV 2000, Chapel Hill, NC, June 2000. http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/00/tcpspand_nossdav0 0.pdf regards keshav From Jon.Crowcroft at cl.cam.ac.uk Wed Sep 28 14:44:44 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 28 Sep 2005 22:44:44 +0100 Subject: [e2e] TCP 'fast start' In-Reply-To: Message from "S. Keshav" of "Wed, 28 Sep 2005 15:22:03 EDT." Message-ID: two more ideas 1/ in rcp (or xcp) you have 1 rtt before you knwow what values to use for the rate on the conenction. most applications go through a whole huge pre-amble of lookups of various kinds (ARPs, DNS, route etc etc) - and various people have proposed nonce/capability too, to prevent DoS - if the routers _advertise_ links with the number of connections or N_hat in RCP terms) then this could be cached near the edges of the net, and used for initial rate selection - if we are already considfering cranking the route update frequency up to many times per second, so that we can do resilience and fast failober fast enough to mask link outages from VOIP, then it would be easy to add this to OSPF (and to some state stuff per route's bottleneck per AS for BGP) and then we could have zero RTT convergence on an initial rate 2/ alternative, if every hos embarking on a new TCP connection, as well as slow statre and congestion avoidance, has a small applet alongside which looks up the route (either by speaking to a nearest OSPF and/or BGP speaker, or else by traceroute), then it has a unique mapping from route to _multicast_ address, then hosts could multicast their TCPCB - this would be done i) once per RTT and ii) only if the other seen TCPCB parameters (e.g. cwnd and rtt or computed rate) differed a lot actually, you'd use a trick very much like RTCP timer reconsiderations to set when you send an update... so then, insteads o having to deploy router modifications to do XCP or RCP or similar ideas, you could just have a daemon (right now) on any end system, and as long as you had multicast, at relatively low cost, you would get to see the set of other TCPCBs - this would let you chose rates when routes changed or whan lots of flows stopped and started, much more quickly... of course, someone would have to emable multicast, but it seems to me that this is potentially more likely than someone deploying XCP capable routrrs jsut a tad:) (3/ I had thought about using PGM for unicast, but thats probably really barking mad) my 3 eurocents... In missive , "S. Keshav" typed: >>Hi, >> The idea of using environmental variables to optimize TCP start goes >>back a while. It is particularly useful for short transfers that complete >>before they reach the 'steady-state'. My students and I worked on this in >>1999. We used Shared Passive Network Discovery, proposed by Seshan, Stemm, >>and Katz to discover connection parameters from a cluster of users to a >>popular destination, say, Yahoo, and used this information to choose initial >>TCP parameters. Though we only did simulations, our results looked pretty >>decent, so maybe Joe, you can actually implement our work :-) >> >>For more details, please see: >> >> Y. Zhang, L. Qiu, and S. Keshav, "Speeding Up Short Data Transfers: Theory, >>Architecture Support, and Simulation Results," Proc. NOSSDAV 2000, Chapel >>Hill, NC, June 2000. >> >>http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/00/tcpspand_nossdav0 >>0.pdf >> >>regards >> >>keshav >> >> cheers jon From demir at kou.edu.tr Tue Sep 27 10:05:07 2005 From: demir at kou.edu.tr (Alper Kamil Demir) Date: Tue, 27 Sep 2005 20:05:07 +0300 Subject: [e2e] A Question on the TCP handoff Message-ID: <92E20BAD-53D2-4A8F-A1C1-62E4C21D7DB0@mimectl> I have a question on the TCP handoff. Let's assume that there is an actual TCP connection between host-1 (H1) and Host-A (HA). Meantime, host-2 and Host-A (HA) establishes a warm-up connection to be handovered. Is it ever possible to replace the actual connection with the warm-up connection let's say that because H1 moves? (is this against to the end-to-end semantics of TCP?) If so, what mechanisms could be used to achieve the handoff? (i.e. TCP stack modifications, socket layer modifications, middleware on top of TCP, etc...) I appreciate your answers. Alper K. Demir Kocaeli University, Turkey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050927/ce3ca5f4/attachment.html From touch at ISI.EDU Wed Sep 28 16:19:41 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 28 Sep 2005 16:19:41 -0700 Subject: [e2e] TCP 'fast start' In-Reply-To: References: Message-ID: <433B250D.5020103@isi.edu> S. Keshav wrote: > Hi, > The idea of using environmental variables to optimize TCP start goes > back a while. It is particularly useful for short transfers that complete > before they reach the 'steady-state'. My students and I worked on this in > 1999. We used Shared Passive Network Discovery, proposed by Seshan, Stemm, > and Katz to discover connection parameters from a cluster of users to a > popular destination, say, Yahoo, and used this information to choose initial > TCP parameters. Though we only did simulations, our results looked pretty > decent, so maybe Joe, you can actually implement our work :-) Sharing the state among a set of hosts with similar paths was proposed in RFC2140 (1997), and some tests based on an implementation were published in CCR early in 2000: L. Eggert, J. Heidemann, J. Touch, "Effects of Ensemble-TCP," ACM CCR, Jan. 2000, pp. 15-29. This of course is close to what you did in the NOSSDAV paper, as was cited therein already. The primary difference (AFAICT - I did a very quick read) is that 2140 shared state among a set, and your work used state from other nearby connections (that aren't necessarily 'shared' explicitly) to infer network conditions. Both of which may be useful, but aren't what ALN does. ALN uses a lot of external parameters that have nothing per se to do with networking, e.g., whether it's a national holiday in the country of one of the endpoints, time of day, etc., and reusing it - perhaps a long time later, if past experience accuratly predicts patterns of repetition. I.e., if 3pm on the Wednesday before Thanksgiving in the USA in previous years was an idle network time (whereas it wouldn't be most other Wednesdays in general), then this Wed before Thanksgiving at 3pm we might reuse that information. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050928/5183fff9/signature.bin From weixl at caltech.edu Wed Sep 28 16:47:50 2005 From: weixl at caltech.edu (Xiaoliang (David) Wei) Date: Wed, 28 Sep 2005 16:47:50 -0700 Subject: [e2e] A Question on the TCP handoff References: <92E20BAD-53D2-4A8F-A1C1-62E4C21D7DB0@mimectl> Message-ID: <018f01c5c487$099117e0$f5f2010a@seashadow> Can this tool do what you want: TCP Connection Passing ? see: http://tcpcp.sourceforge.net/ -David Xiaoliang (David) Wei Graduate Student in CS at Caltech http://www.davidwei.org ==================================================== ----- Original Message ----- From: Alper Kamil Demir To: end2end-interest at postel.org Sent: Tuesday, September 27, 2005 10:05 AM Subject: [e2e] A Question on the TCP handoff I have a question on the TCP handoff. Let's assume that there is an actual TCP connection between host-1 (H1) and Host-A (HA). Meantime, host-2 and Host-A (HA) establishes a warm-up connection to be handovered. Is it ever possible to replace the actual connection with the warm-up connection let's say that because H1 moves? (is this against to the end-to-end semantics of TCP?) If so, what mechanisms could be used to achieve the handoff? (i.e. TCP stack modifications, socket layer modifications, middleware on top of TCP, etc...) I appreciate your answers. Alper K. Demir Kocaeli University, Turkey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050928/494800e3/attachment.html From kelsayed at gmail.com Wed Sep 28 23:56:13 2005 From: kelsayed at gmail.com (Khaled Elsayed) Date: Thu, 29 Sep 2005 08:56:13 +0200 Subject: [e2e] TCP 'fast start' In-Reply-To: <433B250D.5020103@isi.edu> References: <433B250D.5020103@isi.edu> Message-ID: <433B900D.7010205@gmail.com> Hi All, I think all these effort to enhance TCP are great. However, it seems that TCP has become too old and inefficient for many cases (wireless, short connections, ultra-high speed, etc). Isn't it time that the research community should think about keeping TCP interface (sockets) but come up with a more efficient universal protocol or am I just too optimistic/unrealistic? Khaled From posch at tkn.tu-berlin.de Thu Sep 29 03:47:41 2005 From: posch at tkn.tu-berlin.de (Tobias Poschwatta) Date: Thu, 29 Sep 2005 12:47:41 +0200 Subject: [e2e] TCP 'fast start' In-Reply-To: References: Message-ID: <20050929104741.GA14535@tkn.tu-berlin.de> Hi, some more recent work to this point: the EFCM common congestion controller developed in our group. See Michael Savoric, Holger Karl, Morten Schlaeger, Tobias Poschwatta, and Adam Wolisz, "Analysis and performance evaluation of the EFCM common congestion controller for TCP connections", Computer Networks, vol. 49, no. 2, pp. 269-294, October 2005, to appear The complete results are available in the dissertation of Michael Savoric: http://edocs.tu-berlin.de/diss/2004/savoric_michael.htm Tobias On Wed, Sep 28, 2005 at 03:22:03PM -0400, S. Keshav wrote: > Hi, > The idea of using environmental variables to optimize TCP start goes > back a while. It is particularly useful for short transfers that complete > before they reach the 'steady-state'. My students and I worked on this in > 1999. We used Shared Passive Network Discovery, proposed by Seshan, Stemm, > and Katz to discover connection parameters from a cluster of users to a > popular destination, say, Yahoo, and used this information to choose initial > TCP parameters. Though we only did simulations, our results looked pretty > decent, so maybe Joe, you can actually implement our work :-) > > For more details, please see: > > Y. Zhang, L. Qiu, and S. Keshav, "Speeding Up Short Data Transfers: Theory, > Architecture Support, and Simulation Results," Proc. NOSSDAV 2000, Chapel > Hill, NC, June 2000. > > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/00/tcpspand_nossdav0 > 0.pdf > > regards > > keshav > > -- Tobias Poschwatta posch at tkn.tu-berlin.de Tel: ++49 30 314-23826 Technische Universitaet Berlin, Telecommunication Networks Group (TKN) Sekr. FT 5, Einsteinufer 25, 10587 Berlin, Germany From baruch at ev-en.org Thu Sep 29 05:38:05 2005 From: baruch at ev-en.org (Baruch Even) Date: Thu, 29 Sep 2005 13:38:05 +0100 Subject: [e2e] TCP 'fast start' In-Reply-To: <433B900D.7010205@gmail.com> References: <433B250D.5020103@isi.edu> <433B900D.7010205@gmail.com> Message-ID: <433BE02D.80706@ev-en.org> Khaled Elsayed wrote: > Hi All, > > I think all these effort to enhance TCP are great. However, it seems > that TCP has become too old and inefficient for many cases (wireless, > short connections, ultra-high speed, etc). > > Isn't it time that the research community should think about keeping TCP > interface (sockets) but come up with a more efficient universal protocol > or am I just too optimistic/unrealistic? Isn't that what XCP and RCP are? Note that it doesn't mean the work will be adopted in the real world. It takes a lot more work to get a new protocol adapted due to the buy-in you need to get from so many parties who will always point at someone else as the starting point for adoption. The trick would be designing something new from the group up but with an upgrade path that doesn't require buy-in from everyone initially. Baruch From dpreed at reed.com Thu Sep 29 07:07:26 2005 From: dpreed at reed.com (David P. Reed) Date: Thu, 29 Sep 2005 10:07:26 -0400 Subject: [e2e] TCP 'fast start' In-Reply-To: <433B900D.7010205@gmail.com> References: <433B250D.5020103@isi.edu> <433B900D.7010205@gmail.com> Message-ID: <433BF51E.6040503@reed.com> Khaled Elsayed wrote: > I think all these effort to enhance TCP are great. However, it seems > that TCP has become too old and inefficient for many cases (wireless, > short connections, ultra-high speed, etc). Read the original TCP papers and so forth. TCP was never "efficient" nor was it intended to be. It was intended to be *interoperable*. It was an *overlay* network. It still achieves those goals far better than an "efficient" protocol (especially since efficiency seems to come at a cost - specialization, brittle response outside a narrow set of operating points, etc.). That doesn't mean that TCP achieves its goals fully - but if you focus on goals it never had (like "efficiency") as your critique, you will end up with SNA (which was FAR more bit-efficient than TCP ever was, but failed to be useful in a broad context) or SS7 and the Bell System 3 kHz highly-optimized billing machine - also far more "efficient" than TCP but only in a narrow domain. > > Isn't it time that the research community should think about keeping > TCP interface (sockets) but come up with a more efficient universal > protocol or am I just too optimistic/unrealistic? The research community should be exploring a wide range of things. Resilience and adaptability is far more important than "efficiency" . Far too many in the research community are focused on a narrow set of metrics, invented by academics, for academics, merely because they are quantitative. They are the "drag racing" community, who focus on top-fuel funny cars (perhaps that's too US centric?). We need more researchers focused on how the cars fit into the human ecology of communications, in particular some ought to be thinking about inventing better metrics for things like adaptability and resilience, which are far more relevant systems properties. Can anyone tell me a defensible measure of adaptability that has been used to rank network performance in the real world? From touch at ISI.EDU Thu Sep 29 12:48:35 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 29 Sep 2005 12:48:35 -0700 Subject: [e2e] FYI: A Proposed IETF BoF on Diff-Serv Control Plane Message-ID: <433C4513.9080906@isi.edu> Posted at the request of Bob Braden: ---- A Proposed IETF BoF on Diff-Serv Control Plane --------------------------------------------------------------- We've been working toward a possible IETF BoF on diffserv control plane elements to be under the Operations and Management Area. Our in-progress Background and Goals for the BoF: It's been some time since the Diffserv forwarding path elements were standardized. At that time, the approach was to get the mechanisms deployed in routers so that approaches to service creation and control plane could be attempted. Before closing, the Diffserv WG defined the concept of Per-Domain Behaviors (PDBs) in RFC 3086, but left the approach to controling PDBs open. Now Diffserv forwarding elements are available in most routers and are in use to create services in some networks. A variety of approaches are being used for control and management of Diffserv but there appears to be some commonality. A possible path for IETF work is to enumerate and classify the common elements and to work toward some best common practices. Additionally, it may be useful to present specifications for a range of diffserv control plane elements using common interfaces. The major issues to deploying Diffserv-based services are primarily operational. The deployment must be cost-effective, be secured against vulnerabilities and not become a vehicle for denial of service attacks. Standardization should result in existing toolsets being either expanded to cover more needed functionality or to interact with other tools. A standardization effort should cover how to secure the architecture to mitigate vulnerabilities. Standards for a control plane QoS agent for routers may be useful. A desired outcome of IETF efforts is to make multiple products available to network operators, obviating the time and personnel expense of individual solutions. The end goal is to enable more services, both for network customers and for control of the network, without taxing personnel. The starting point for a BoF is to look at what's out there, determine if there is indeed some uniformity of approach useful as a starting point, and determine what's missing. The intial focus would be the intradomain control plane moving to interdomain or AS under same provider and finally to interprovider or interoperator. ------------------------------------------------------------------ The entire in-progress proposal for the BoF can be viewed at www.pollere.com under Resources, then Current Work. If you are interested in helping to further shape the proposal, please sign up for the email list dcpel at ietf.org through www1.ietf.org/mailman/listinfo/dcpel and comment on the list. thanks, Kathie Nichols Scott Bradner -------------- 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/20050929/eef37911/signature.bin From demir at kou.edu.tr Thu Sep 29 11:06:19 2005 From: demir at kou.edu.tr (Alper Kamil Demir) Date: Thu, 29 Sep 2005 21:06:19 +0300 Subject: [e2e] A Question on the TCP handoff In-Reply-To: <018f01c5c487$099117e0$f5f2010a@seashadow> References: <92E20BAD-53D2-4A8F-A1C1-62E4C21D7DB0@mimectl>, <018f01c5c487$099117e0$f5f2010a@seashadow> Message-ID: <251995AB-69FA-49F9-8E51-585028CDAC49@mimectl> David, Thank you very much for the reply. However, I think tcpcp will not solve the problem because tcpcp is useful to migrate tcp connection from place to place (correct me if I am wrong). What I want to achieve is to replace the warm-up connection with an already established actual connection (so that replaced new connection both does have the same previous flow control of actual connection and doesn't go into slow start process by having congestion control state of warm-up). Alper K. Demir Kocaeli University, Turkey From: Xiaoliang (David) Wei Sent: Thu 9/29/2005 2:47 AM To: Alper Kamil Demir; end2end-interest at postel.org Subject: Re: [e2e] A Question on the TCP handoff Can this tool do what you want: TCP Connection Passing ? see: http://tcpcp.sourceforge.net/ -David Xiaoliang (David) Wei Graduate Student in CS at Caltech http://www.davidwei.org/ ==================================================== ----- Original Message ----- From: Alper Kamil Demir To: end2end-interest at postel.org Sent: Tuesday, September 27, 2005 10:05 AM Subject: [e2e] A Question on the TCP handoff I have a question on the TCP handoff. Let's assume that there is an actual TCP connection between host-1 (H1) and Host-A (HA). Meantime, host-2 and Host-A (HA) establishes a warm-up connection to be handovered. Is it ever possible to replace the actual connection with the warm-up connection let's say that because H1 moves? (is this against to the end-to-end semantics of TCP?) If so, what mechanisms could be used to achieve the handoff? (i.e. TCP stack modifications, socket layer modifications, middleware on top of TCP, etc...) I appreciate your answers. Alper K. Demir Kocaeli University, Turkey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050929/47364fe6/attachment.html From jshen_cad at yahoo.com.cn Fri Sep 30 01:26:24 2005 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Fri, 30 Sep 2005 16:26:24 +0800 (CST) Subject: [e2e] Is RED dead? In-Reply-To: <17199.663.737847.284956@roam.psg.com> Message-ID: <20050930082625.76395.qmail@web15402.mail.cnb.yahoo.com> I've talked with some one before who said wred is deployed in ISP network edge, but he is just from a network equipment manufacturer. To me, (W)RED seems good to provide a method avoiding congestion. But, how could those traffic be dropped according to traffic management requirement ? how to avoid to focusing those "honest" TCP implementations? Jing --- Randy Bush дµÀ: > wred is used in real network deployments, though not > as widely > as it likely should be. > > randy > > Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' ___________________________________________________________ ÑÅ»¢ÓÊÏ䳬ǿÔöÖµ·þÎñ£­2G³¬´ó¿Õ¼ä¡¢pop3ÊÕÐÅ¡¢ÎÞÏÞÁ¿ÓʼþÌáÐÑ http://cn.mail.yahoo.com From meena_selvam at yahoo.com Fri Sep 30 06:27:58 2005 From: meena_selvam at yahoo.com (MEENA SELVAM) Date: Fri, 30 Sep 2005 06:27:58 -0700 (PDT) Subject: [e2e] how do i program sockets for scalability - any good link? Message-ID: <20050930132759.56213.qmail@web30412.mail.mud.yahoo.com> I understand we can use different threads to handle each client connection. If thousands of clients are involved , how do I ensure performance? Is ther any good link that indicates a design with multiple worker queues holding the socket descriptors etc. meena __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From puddinghead_wilson007 at yahoo.co.uk Fri Sep 30 09:45:17 2005 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Fri, 30 Sep 2005 17:45:17 +0100 (BST) Subject: [e2e] Is RED dead? In-Reply-To: <20050930082625.76395.qmail@web15402.mail.cnb.yahoo.com> Message-ID: <20050930164517.98303.qmail@web25408.mail.ukl.yahoo.com> how does it matter in case of congestion/queue if i drop at a central node or an edge node? is the queue size sufficient to hold a window? -danke! --- Jing Shen wrote: > I've talked with some one before who said wred is > deployed in ISP network edge, but he is just from a > network equipment manufacturer. > > To me, (W)RED seems good to provide a method > avoiding > congestion. But, how could those traffic be dropped > according to traffic management requirement ? how to > avoid to focusing those "honest" TCP > implementations? > > Jing > > > --- Randy Bush ????: > > > wred is used in real network deployments, though > not > > as widely > > as it likely should be. > > > > randy > > > > > > > Jing Shen > > Data Communication Center > HangZhou TeleCom > HangZhou ZJ 310027 > P.R.China > > ' spamcontrol ' > > > > ___________________________________________________________ > > ??????????????????????2G??????????pop3???????????????????? > > http://cn.mail.yahoo.com > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From faber at ISI.EDU Fri Sep 30 11:31:10 2005 From: faber at ISI.EDU (Ted Faber) Date: Fri, 30 Sep 2005 11:31:10 -0700 Subject: [e2e] TCP 'fast start' In-Reply-To: <433B900D.7010205@gmail.com> References: <433B250D.5020103@isi.edu> <433B900D.7010205@gmail.com> Message-ID: <20050930183110.GO999@pun.isi.edu> On Thu, Sep 29, 2005 at 08:56:13AM +0200, Khaled Elsayed wrote: > Isn't it time that the research community should think about keeping TCP > interface (sockets) but come up with a more efficient universal protocol > or am I just too optimistic/unrealistic? Research communities rarely write protocols. The place to plug your new protocol in is very clear. Keep us up to date on your progress. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050930/8d7e734a/attachment.bin From ikob at koganei.wide.ad.jp Fri Sep 30 19:38:06 2005 From: ikob at koganei.wide.ad.jp (Katsushi Kobayashi) Date: Sat, 1 Oct 2005 11:38:06 +0900 Subject: [e2e] PFLDnet2006 ready for online submissiion Message-ID: <977204EA-CC63-45A5-858A-9AFCA81DAF46@koganei.wide.ad.jp> We would like to remind PFLDnet2006 CFP and inform online submission page is open. Call For Papers =============== Fourth International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet2006) February 2-3, 2006 Nara, Japan - An ancient capital city older than Kyoto ------------------------------------------------------------------------ http://www.hpcc.jp/pfldnet2006/ ------------------------------------------------------------------------ Fast long-distance networks (i.e., networks operating at 622 Mbit/s, 2.5 Gbit/s, or 10 Gbit/s, soon will be 40 Gbit/s, and spanning several countries or states) are now becoming commonplace. Increasing numbers of researchers now routinely transfer between 10 GB and multi-TB datasets over gigabit networks. Application domains for such massive transfers include data-intensive Grids (e.g., in Particle Physics, Earth Observation, Bio Informatics, and Radio Astronomy), database mirroring for Web sites (e.g., in e-commerce), and push-based Web cache updates. Although the connectivity infrastructure is now in place, or will soon be, the transport and application protocols available to date are proving inadequate for fast transfer of large volumes of data over such networks. Current versions of TCP cannot fully exploit the network capacity. For instance, recovery time from a congestion event grows at a super-linear rate, and can easily exceed 10 minutes in very high bandwidth-delay product networks. It also requires a large congestion window for high throughput, consuming valuable system resources. A number of research teams have begun investigating advanced protocols for domain-specific and general applications. The International Workshop on Protocols for Fast Long-Distance Networks in CERN (http://datatag.web.cern.ch/datatag/pfldnet2003/), in Argonne (http://www-didc.lbl.gov/PFLDnet2004/), and in Lyon (http://www.ens-lyon.fr/LIP/RESO/pfldnet2005/) were very successful in bringing together many researchers from all over the world including North America, Europe and Asia who are working on these problems. This workshop will continue this tradition, and provide a perfect setting for researchers in this area to exchange ideas and experience. This single-track workshop will provide researchers and technologists with a focused, highly interactive opportunity to present, discuss and exchange experience on leading research, development and future directions in high performance transport and application protocols (TCP, UDP, HTTP, FTP, etc.) over fast long-distance networks. In order to facilitate discussions, attendance will be limited to 60 participants. Please register early to ensure your participation. Depending on the number of people who register, we may need to restrict the number of people from a given organization to allow for a broader representation of the research community. Registration will open late 2005. Call For Papers --------------- Participants wishing to present a paper should upload a four- pages extended abstract to http://www.hpcc.jp/pfldnet2006/ by October 14 2005. Authors whose abstracts are selected for presentation will have the option to submit a full paper, to be published on the PFLDnet 2006 web site and in the PFLDnet 2006 proceedings. Scope ----- The PFLDnet2006 workshop will focus on research issues and challenges as well as lessons learned from experience. Topics of interest include and are not limited to: - Protocol issues in fast long-distance networks - Enhancements of TCP and its variants - Novel data transport protocols designed for new application services - Transport over optical networks - RDMA over WANs - Shaping on TCP and UDP traffic - QoS and scalability issues - Parallel transfers and multistreaming - Multicast over fast long-distance networks - Modeling and simulation-based results - Experiments on real networks and actual measurements - Protocol benchmarking - Protocol implementation and hardware issues (PCs, NICs, TOEs, routers, switches, etc.) - Data replications and striping - Requirements and experience from bandwidth demanding applications - Bulk-data transfer applications both TCP and non-TCP based - Transport service for Grids Important Dates --------------- Extended Abstract Submission Deadline: October 14 Acceptance Notification: December 2 Final Paper Submission: January 20 Workshop: February 2-3 Committees ---------- Co-Chairs: Richard Hughes-Jones (Univ. Manchester - UK) Kei Hiraki (Univ. of Tokyo - JP) Jason Leigh (UIC - USA) Steering Committee: Pascale Vicat-Blanc Primet (INRIA - FR) Tomohiro Kudoh (AIST - JP) Katsushi Kobayashi (NICT - JP) Technical Program Committee : Brian L Tierney (LBL - USA) R. Les Cottrell (SLAC - USA) Bill Allcock (ANL - USA) Eitan Altman (INRIA - FR) Richard Carlson (Internet2 - USA) Sally Floyd (ICIR - USA) Pascale Vicat-Blanc Primet (INRIA - FR) Tomohiro Kudoh (AIST - JP) Douglas Leith (Hamilton Institute - IR) Steven Low (CALTECH - USA) Medy Sanadidi (UCLA - USA) Robin Tasker (CCLRC - UK) Hideyuki Shimonishi (NEC - JP) Kenjiro Cho (IIJ - JP) Injong Rhee (NCSU - USA) Andrew Chien (UCSD - USA) Aaron Falk (ISI - USA) Saverio Mascolo (Politecnico di Bari - IT) Katsushi Kobayashi (NICT - JP) Local Organization Committee: Noritoshi Demizu (NICT - JP) Sponsors: --------- NICT, JAPAN TBD. Contact: pfldnet2006-la at hpcc.jp