From goutham_s1 at yahoo.com Wed Dec 1 08:24:51 2004 From: goutham_s1 at yahoo.com (Goutham S Mohan) Date: Wed Dec 1 08:26:35 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? Message-ID: <20041201162451.16833.qmail@web52810.mail.yahoo.com> I have a TCP client which does a HTTP-POST to IIS 5.0 / 6.0. When the webserver completes sending data, it does an active close and moves into the FIN_WAIT_2. By this time, the client is still reading the data from the socket buffer. After a timeout, IIS is sends a RST to the client TCP. This stops the client from reading the data from the buffer. read() errors out with a ECONNRESET. My question is, "Why does the Windows TCP stack send an RST when in FIN_WAIT_2 ? Is this an intended behaviour ?" Just thought I will attach the TCP dump of the communication: tcpdump: listening on lan0 17:44:38.866196 forti.58705 > mustangrr.http: S 3780990706:3780990706(0) win 32768 (DF) 17:44:38.867048 mustangrr.http > forti.58705: S 1452070376:1452070376(0) ack 3780990707 win 17520 (DF) 17:44:38.867336 forti.58705 > mustangrr.http: P 1:163(162) ack 1 win 32768 (DF) 17:44:38.867508 forti.58705 > mustangrr.http: P 163:204(41) ack 1 win 32768 (DF) 17:44:38.867547 forti.58705 > mustangrr.http: P 204:262(58) ack 1 win 32768 (DF) 17:44:38.867572 forti.58705 > mustangrr.http: P 262:303(41) ack 1 win 32768 (DF) 17:44:38.868047 forti.58705 > mustangrr.http: P 303:357(54) ack 1 win 32768 (DF) 17:44:38.868071 forti.58705 > mustangrr.http: P 357:398(41) ack 1 win 32768 (DF) 17:44:38.868097 forti.58705 > mustangrr.http: P 398:457(59) ack 1 win 32768 (DF) 17:44:38.868123 forti.58705 > mustangrr.http: P 457:498(41) ack 1 win 32768 (DF) 17:44:38.868156 forti.58705 > mustangrr.http: P 498:623(125) ack 1 win 32768 (DF) 17:44:38.868188 forti.58705 > mustangrr.http: P 623:664(41) ack 1 win 32768 (DF) 17:44:38.868214 forti.58705 > mustangrr.http: P 664:718(54) ack 1 win 32768 (DF) 17:44:38.868244 forti.58705 > mustangrr.http: P 718:761(43) ack 1 win 32768 (DF) 17:44:38.868275 forti.58705 > mustangrr.http: P 761:762(1) ack 1 win 32768 (DF) 17:44:38.869140 mustangrr.http > forti.58705: . ack 204 win 17317 (DF) 17:44:38.869166 mustangrr.http > forti.58705: . ack 303 win 17218 (DF) 17:44:38.869228 mustangrr.http > forti.58705: . ack 398 win 17123 (DF) 17:44:38.869296 mustangrr.http > forti.58705: . ack 498 win 17023 (DF) 17:44:38.872038 mustangrr.http > forti.58705: . ack 664 win 16857 (DF) 17:44:38.872061 mustangrr.http > forti.58705: . ack 761 win 16760 (DF) 17:44:38.887618 mustangrr.http > forti.58705: P 1:228(227) ack 762 win 16759 (DF) 17:44:38.888503 mustangrr.http > forti.58705: FP 228:780(552) ack 762 win 16759 (DF) 17:44:38.888537 forti.58705 > mustangrr.http: . ack 781 win 32768 (DF) 17:44:38.888559 mustangrr.http > forti.58705: R 1452071157:1452071157(0) win 0 (DF) 17:44:38.888884 mustangrr.http > forti.58705: R 1452071157:1452071157(0) win 0 12431 packets received by filter 0 packets dropped by kernel I could not figure out why on earth Windows TCP sends an RST, but however it was a simple fix for me in my application. The client now sends Keep-Alives so that, the web svr which by definition does a active close will not do so. This allows my client to keep the connection alive and do the active close when its done with its job. I did post this into Microsoft IIS newsgroups, it wasn’t of any use. Found a similar article posted in 2003 :- http://www.postel.org/pipermail/end2end-interest/2003-January/002599.html Regards, Goutham S Mohan --------------------------- Software Engineer, Hewlett Packard [Global Delivery India Center] --------------------------------- Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041201/50bf0d85/attachment.html From craig at aland.bbn.com Wed Dec 1 10:15:36 2004 From: craig at aland.bbn.com (Craig Partridge) Date: Wed Dec 1 10:15:50 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: Your message of "Wed, 01 Dec 2004 08:24:51 PST." <20041201162451.16833.qmail@web52810.mail.yahoo.com> Message-ID: <20041201181536.0F01C1B2@aland.bbn.com> >My question is, "Why does the Windows TCP stack send an RST when in FIN_WAIT_2 > ? Is this an intended behaviour ?" > Apparently Windows TCP sends a RST to end certain TCP connections rather than have to hang around in TIME WAIT. It is not the intended behavior. Craig From jshen_cad at yahoo.com.cn Thu Dec 2 01:46:05 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Thu Dec 2 01:47:56 2004 Subject: [e2e] Number of Routes and network stability Message-ID: <20041202094605.47235.qmail@web15408.mail.cnb.yahoo.com> Hi, Some vendors recommended that number of routers within one OSPF area should not exceed 50, some others recommended number of routes within one area should not exceed 3000. To my understanding, OSPF stability is directly related to link stability, radius of an OSPF area and OSPF implementation( router hardware, methodology of link status processing). But, is there any research done on this topic? or how are those recommendation derived ? thanks Jing Shen _________________________________________________________ Do You Yahoo!? ×¢²áÊÀ½çÒ»Á÷Æ·ÖʵÄÑÅ»¢Ãâ·ÑµçÓÊ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/ From goutham_s1 at yahoo.com Thu Dec 2 05:12:18 2004 From: goutham_s1 at yahoo.com (Goutham S Mohan) Date: Thu Dec 2 05:13:58 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041201181536.0F01C1B2@aland.bbn.com> Message-ID: <20041202131218.49560.qmail@web52802.mail.yahoo.com> Alex (not sure if I can reveal your address here) pointed me to a RFC by Sally Floyd against using RST this way. Below is the link for the same, it cleared a lot of dangling issues for me. http://www.ietf.org/rfc/rfc3360.txt Regards, Goutham S Mohan --------------------------- Software Engineer, Hewlett Packard [Global Delivery India Center] __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041202/da5323e5/attachment.html From touch at ISI.EDU Thu Dec 2 06:58:44 2004 From: touch at ISI.EDU (Joe Touch) Date: Thu Dec 2 07:00:51 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041201181536.0F01C1B2@aland.bbn.com> References: <20041201181536.0F01C1B2@aland.bbn.com> Message-ID: <41AF2DA4.9060004@isi.edu> Craig Partridge wrote: >>My question is, "Why does the Windows TCP stack send an RST when in FIN_WAIT_2 > > > ? Is this an intended behaviour ?" > > Apparently Windows TCP sends a RST to end certain TCP connections rather > than have to hang around in TIME WAIT. It is not the intended behavior. > > Craig This issue was described in: R. Braden, "TIME-WAIT Assassination Hazards in TCP," RFC-1337, USC/Information Sciences Institute (May 1992). Using RSTs in a beneficial way to avoid TIME_WAITs was described in the following paper, but requires that the sender of RSTs go into TIME_WAIT (to compensate for the receiver leaving TIME_WAIT): "The TIME-WAIT state in TCP and Its Effect on Busy Servers," Theodore Faber, Joe Touch, and Wei Yue, Proc. Infocom '99, pp. 1573-1583. http://www.isi.edu/touch/pubs/infocomm99/ IMO, sending a RST when connected should require that side to go into TIME_WAIT, regardless of the reason for the RST. This was never required, though. 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/20041202/8ec03b4f/signature.bin From cannara at attglobal.net Thu Dec 2 09:21:25 2004 From: cannara at attglobal.net (Cannara) Date: Thu Dec 2 09:19:52 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? References: <20041202131218.49560.qmail@web52802.mail.yahoo.com> Message-ID: <41AF4F15.9748546@attglobal.net> No problem, Goutham, glad you found it. Alex From Jon.Crowcroft at cl.cam.ac.uk Sun Dec 5 08:31:01 2004 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun Dec 5 08:32:30 2004 Subject: [e2e] Satellite Date Rates In-Reply-To: Message from Lloyd Wood of "Sun, 05 Dec 2004 15:17:57 GMT." Message-ID: um, i misse a bit of the context on this, so this comment may be awry w.r.t the satellite data rate discussion, but as regards general efficiency of rateless codes, methinks you need to re-read about luby codes/tornado/turbo and in general rateless codes where you dont need a priori knowledge of the channel error characteristcs to choose the code etc...the overhead is nothing like the level you assert here... yes, you are right that people have started looking at FEC in P2P e.g. upcoming Infocom 2005 paper C. Gkantsidis, P. Rodriguez, "Network Coding for Large Scale Content Distribution", IEEE INFOCOM 2005, Miami. March 2005. (Also available as Microsoft Research Technical Report (MSR-TR-2004-80). [pdf]. at: http://www.rodriguezrodriguez.com/files/My_Research.html a tutorial about the ideas... http://research.microsoft.com/~pachou/pubs/ChouWJ04.ppt but the reasons are to reduce channel inefficiency...i..e reduce greedyness....also, it seems to me that the idea that a p2p system is far _less_ greedy than a system that encourages repeated download from the "master" site such as iTunes or other classical 70s server based technlogies...but thats a whole other debate... In missive , Llo yd Wood typed: >>On Mon, 29 Nov 2004, David P. Reed wrote: >> >>> Actually, Lloyd, I was proposing something based on the simplest, most >>> basic digital fountain idea. >>> >>> If you remember Luby's original papers, the basic idea is that the >>> digital fountain stream is an infinite sequence of packets that encodes >>> a source file that is N packets long, such that if you receive ANY >>> subset of N packets correctly, you can reconstruct the original file. >>> I.e., it's pretty close to the information theoretic efficiency of the >>> packet-at-a-time channel. You may also remember that the first N >>> packets of the fountain are just those of the source file, while >>> subsequent packets are combinations of the preceding frames. >> >>Thus, after N+2 packets are sent, redundantly sending every symbol >>(original and resend) you have achieved a rate of N/N+2, or 1/2. And >>from then on, with further packets, you are down to rate 1/3, then >>1/4... as your infinite sequence continues. This is called 'rateless' >>because it holds to no defined rate to attempt to get the packet >>across. And obviously, as the infinite series continues (because you >>often can't be sure when the receiver has all it needs), the >>efficiency of the channel drops towards zero. >> >>[..] >>> This is analogous to an adaptive FEC, and becomes one, but based on a >>> somewhat different theory and loss model, and with a quite different >>> optimization goal >> >>One where tending towards zero efficiency is somehow seen as tending >>towards maximum theoretical throughput. >> >>Really, it's no coincidence that erasure codes have found a home in >>greedy P2P applications, whose concepts of channel efficiency is >>somewhat fuzzy at best, but where the redundancy of encoding can best >>be exploited by multiple hosts. actually, i dont think its fair to say the concept of channel efficieny is fuzzy - it is well defined - the place you look for this definition is (again) in radio nets, for example look at definitions of info-capacity of a channel by Gupta&Kumar - the info theoretical limits explored in that work are for multiple "hosts" so carry over nicely to P2P...(or the internet in general...) cheers jon From dpreed at reed.com Sun Dec 5 09:04:38 2004 From: dpreed at reed.com (David P. Reed) Date: Sun Dec 5 09:06:28 2004 Subject: [e2e] Satellite Date Rates In-Reply-To: References: <200411252000.iAPK04t07955@boreas.isi.edu> <32870.137.73.8.107.1101416020.squirrel@137.73.8.107> <3582.195.92.67.78.1101461274.squirrel@195.92.67.78> <41A767CC.4050209@reed.com> <41A79999.1010201@reed.com> <41ABF0D2.60907@reed.com> Message-ID: <41B33FA6.90903@reed.com> Lloyd Wood wrote: > One where tending towards zero efficiency is somehow seen as tending > >towards maximum theoretical throughput. > > > If your goal is to minimize end-to-end task delay in a bursty channel, you may not be able to simultaneously maximize throughput. They trade off against each other in most real situations. The network owner always wants max utilization of his resource, the end user typically wants his requests delivered and done quickly. End-users are usually willing to pay for some underutilization, if it helps them get their work done faster. Unfortunately, most network designers ignore what users want, and focus on unrealistic targets like maximizing resource utilization (maximizing the measure they have, like the drunk looking for his keys under the lamppost). Often they are abetted by those who own and operate the network resources, esp. when they are in a monopoly position so they don't have to care too much about satisfying customers. In a competitive, non-monopoly environment, this is often ameliorated and corrected by users switching to more enlightened carriers focused on measures that correlate to profitability as a whole. >Really, it's no coincidence that erasure codes have found a home in >greedy P2P applications, whose concepts of channel efficiency is >somewhat fuzzy at best, but where the redundancy of encoding can best >be exploited by multiple hosts. > > There you go again - with moral judgement of design intent. :-) In this case, I don't understand why you associate "greed" specifically with P2P. There's enough greed to go around, independent of design. All those guys with high-speed internet are greedy users of the core Internet - compared to the poor sots with dialup lines they suck up more than their fair share... P2P applications can be non-greedy, and the use of intelligent joint coding schemes is one way they try to reduce their total load on the network through cooperation (a non-greedy choice, perhaps even altruistic?). A greedy P2P application would not care about joint coding or cooperative sharing of the resource. My main point here is that the best global operating point of the system is not achieved when the satellite pipe is full. -------------- next part -------------- A non-text attachment was scrubbed... Name: dpreed.vcf Type: text/x-vcard Size: 113 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041205/873992e1/dpreed.vcf From skaniyar at hotmail.com Sun Dec 5 11:59:45 2004 From: skaniyar at hotmail.com (sanjay kaniyar) Date: Sun Dec 5 12:02:00 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? Message-ID: In this case, Windows TCP is not sending the RST on its own from FIN_WAIT_2 - IIS must have closed the connection. Thanks, Sanjay From faber at ISI.EDU Mon Dec 6 08:29:58 2004 From: faber at ISI.EDU (Ted Faber) Date: Mon Dec 6 08:32:12 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: References: Message-ID: <20041206162958.GA87675@pun.isi.edu> On Sun, Dec 05, 2004 at 11:59:45AM -0800, sanjay kaniyar wrote: > In this case, Windows TCP is not sending the RST on its own from FIN_WAIT_2 > - IIS must have closed the connection. The close is what put the connection into FIN_WAIT_1, and getting an ACK after close put it into FIN_WAIT_2. IIS can't close it again. I hope. -- 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/20041206/cb9a5476/attachment.bin From perfgeek at mac.com Mon Dec 6 12:48:04 2004 From: perfgeek at mac.com (Rick Jones) Date: Mon Dec 6 12:50:09 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041206162958.GA87675@pun.isi.edu> References: <20041206162958.GA87675@pun.isi.edu> Message-ID: <4519725.1102366084720.JavaMail.perfgeek@mac.com> On Monday, December 06, 2004, at 09:18AM, Ted Faber wrote: >On Sun, Dec 05, 2004 at 11:59:45AM -0800, sanjay kaniyar wrote: >> In this case, Windows TCP is not sending the RST on its own from FIN_WAIT_2 >> - IIS must have closed the connection. > >The close is what put the connection into FIN_WAIT_1, and getting an ACK >after close put it into FIN_WAIT_2. IIS can't close it again. I hope. Isn't there is a chance, however small, that IIS called shutdown() or its WSA equivalent before calling close() or its WSA equivalent? I have seen that on a stack nearer and dearer to my heart, customers insist on a timeout to kill FIN_WAIT_2 connections - above and beyond the existing (in that stack anyway) mechanism that starts keepalive probes after an interval in a detached state. That timer is arbitrary. Perhaps Windows has one as well. Is there progress afoot to update the TCP specs with a standardized mechanism to deal with the possibility of infinite time in FIN_WAIT_2? rick jones From braden at ISI.EDU Mon Dec 6 14:44:37 2004 From: braden at ISI.EDU (Bob Braden) Date: Mon Dec 6 14:46:19 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? Message-ID: <200412062244.OAA17927@gra.isi.edu> *> *> Is there progress afoot to update the TCP specs with a standardized mechanism to deal with the possibility of infinite time in FIN_WAIT_2? *> *> rick jones *> Half-open connections are a feature of TCP. You may not like the feature (successive generation of Unix kernel builders have hated it) but it is a feature. Bob Braden From perfgeek at mac.com Mon Dec 6 15:13:09 2004 From: perfgeek at mac.com (Rick Jones) Date: Mon Dec 6 15:14:07 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <200412062244.OAA17927@gra.isi.edu> References: <200412062244.OAA17927@gra.isi.edu> Message-ID: <14749046.1102374789092.JavaMail.perfgeek@mac.com> On Monday, December 06, 2004, at 02:46PM, Bob Braden wrote: > *> > *> Is there progress afoot to update the TCP specs with a standardized mechanism to deal with the possibility of infinite time in FIN_WAIT_2? > *> > *> rick jones > *> > >Half-open connections are a feature of TCP. You may not like the >feature (successive generation of Unix kernel builders have hated it) >but it is a feature. I don't hate it at all, my ire has been directed at the folks doing the arbitrary timers. I just think that all those arbitrary timers and other stack-by-stack junk could go away if there were a spec for the _right_ way to deal with the possibility of a perpetual FIN_WAIT_2 when the remote just drops off the face of the net. rick jones >Bob Braden > > From ggm at apnic.net Mon Dec 6 15:33:36 2004 From: ggm at apnic.net (George Michaelson) Date: Mon Dec 6 15:35:09 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <14749046.1102374789092.JavaMail.perfgeek@mac.com> References: <200412062244.OAA17927@gra.isi.edu> <14749046.1102374789092.JavaMail.perfgeek@mac.com> Message-ID: <20041207093336.72804e09@garlic.apnic.net> On Mon, 06 Dec 2004 15:13:09 -0800 Rick Jones wrote: > >On Monday, December 06, 2004, at 02:46PM, Bob Braden >wrote: > >> *> >> *> Is there progress afoot to update the TCP specs with a standardized >mechanism to deal with the possibility of infinite time in FIN_WAIT_2?> >*> > *> rick jones >> *> >> >>Half-open connections are a feature of TCP. You may not like the >>feature (successive generation of Unix kernel builders have hated it) >>but it is a feature. > > >I don't hate it at all, my ire has been directed at the folks doing the >arbitrary timers. I just think that all those arbitrary timers and other >stack-by-stack junk could go away if there were a spec for the _right_ way >to deal with the possibility of a perpetual FIN_WAIT_2 when the remote >just drops off the face of the net. What mechanism are you proposing short of telepathy? Remember, the other end isn't there. Anything which breaks out of the specific TCP session is an invitation to a DoS threat or worse. Reboot has worked since time immemorial. There are also well known kdb hacks to force the state over (for SunOS at least, but in principle other OS) The Arbitrary timers are about applying a local policy. In the absense of connected state or a trusted path to inform each other the session is never coming back, its ad-hoc or its worse. -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton Phone: +61 7 3858 3150 | QLD 4064 Australia Fax: +61 7 3858 3199 | http://www.apnic.net From perfgeek at mac.com Mon Dec 6 18:04:32 2004 From: perfgeek at mac.com (rick jones) Date: Mon Dec 6 18:06:30 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041207093336.72804e09@garlic.apnic.net> References: <200412062244.OAA17927@gra.isi.edu> <14749046.1102374789092.JavaMail.perfgeek@mac.com> <20041207093336.72804e09@garlic.apnic.net> Message-ID: <563E5FEC-47F4-11D9-9E49-000393765F60@mac.com> > What mechanism are you proposing short of telepathy? Remember, the > other > end isn't there. Anything which breaks out of the specific TCP session > is > an invitation to a DoS threat or worse. I was thinking of keepalive probes. Treat retransmissions of the keepalive probes as if they were retransmissions of data segments and use the existing R2 timer or whatever to decide when enough is enough. I will confess to not being quite sure by what you mean by "anything which breaks of of the specific TCP session" to know if you would include keepalive probes in that category. > Reboot has worked since time immemorial. Did you forget a smiley there? > There are also well known kdb hacks to force the state over (for SunOS > at least, but in principle other OS) Indeed, in HP-UX there is the ndd tcp_discon kludge - neither it, nor debugger hacks are things one wants to suggest to say a bank. rick jones there is no rest for the wicked, yet the virtuous have no pillows From skaniyar at hotmail.com Mon Dec 6 21:50:02 2004 From: skaniyar at hotmail.com (sanjay kaniyar) Date: Mon Dec 6 21:52:06 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041206162958.GA87675@pun.isi.edu> Message-ID: Winsock API has subtle semantics, I am not totally sure but something like this could result in the observed trace: - IIS does send - does Shutdown(SD_SEND) -> data and FIN go out. - setsockopt(Linger = OFF) - closesocket -> RST goes out. But I don't want to spread speculation - I got someone here at Microsoft to run a test which does the following with IIS 6.0: - client establishes a connection, sends a get request - server sends a response and closes the connection -> Data and FIN go out - FIN gets acked. So, I would think there is something specific to the setup. If Goutham can send the details (and the test application if possible), we can take a closer look. Thanks, Sanjay -----Original Message----- From: Ted Faber [mailto:faber@ISI.EDU] Sent: Monday, December 06, 2004 8:30 AM To: sanjay kaniyar Cc: end2end-interest@postel.org Subject: Re: [e2e] Is this a bug with Windows TCP Stack ? On Sun, Dec 05, 2004 at 11:59:45AM -0800, sanjay kaniyar wrote: > In this case, Windows TCP is not sending the RST on its own from FIN_WAIT_2 > - IIS must have closed the connection. The close is what put the connection into FIN_WAIT_1, and getting an ACK after close put it into FIN_WAIT_2. IIS can't close it again. I hope. -- 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 From goutham_s1 at yahoo.com Tue Dec 7 05:49:58 2004 From: goutham_s1 at yahoo.com (Goutham S Mohan) Date: Tue Dec 7 05:52:12 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: Message-ID: <20041207134958.53669.qmail@web52805.mail.yahoo.com> > I got > someone here at Microsoft to > run a test which does the following with IIS 6.0: > > - client establishes a connection, sends a get > request > - server sends a response and closes the connection > -> Data and FIN go out > - FIN gets acked. > > > So, I would think there is something specific to the > setup. If Goutham can > send the details (and the test application if > possible), we can take a > closer look. I am not allowed to share the application itself, but will try to send a sample application by tomorrow. Also now since you say that the server is not sending the RST, I see another variable in the equation. In my case, the client runs on HPUX. I have tried the same with the client on solaris / aix and found the same behaviour. (ie rst being sent). Regards, Goutham S Mohan --------------------------- Software Engineer, Hewlett Packard [Global Delivery India Center] __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From touch at ISI.EDU Tue Dec 7 08:04:33 2004 From: touch at ISI.EDU (Joe Touch) Date: Tue Dec 7 08:06:37 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: References: Message-ID: <41B5D491.8070402@isi.edu> sanjay kaniyar wrote: > Winsock API has subtle semantics, I am not totally sure but something like > this could result in the observed trace: > > - IIS does send > - does Shutdown(SD_SEND) -> data and FIN go out. > - setsockopt(Linger = OFF) > - closesocket -> RST goes out. Why RST here? RST should be associated with an abort call. Closes that don't involve errors should not cause RSTs. The issue, IMO, is 'what is the _error_ here_'? Lingering state is not an error. 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/20041207/54b3078c/signature.bin From lij at scs.howard.edu Tue Dec 7 21:30:21 2004 From: lij at scs.howard.edu (Li, Jiang (Leo)) Date: Wed Dec 8 09:52:22 2004 Subject: [e2e] Call for Papers: Special Session on Delay Tolerant Networks and Applications in ICWN'05 Message-ID: <41B6916D.105@scs.howard.edu> *Please accept our apology if you accept this CFP in duplicates.* Also Call for Reviewers. Please see the information at the bottom. The following information is also available at http://pluto.scs.howard.edu/icwn05_dtn/ ================================================================= Special Session on DISRUPTION TOLERANT NETWORKS AND APPLICATIONS ICWN '05 CALL FOR PAPERS IMCSE '05 In conjunction with the International Conference on Wireless Networks (ICWN). ICWN is part of the International Multiconference in Computer Science and Computer Engineering to be held June 27-30, 2005 in Las Vegas, NV.. Session Overview Disruption tolerant networks (DTN) are the kind of networks that lack continuous connectivity. A DTN is often found when the nodes have very limited communication range, are highly mobile, or are under extreme environments. Several examples are as follows: * A network of PDA?s using Bluetooth where for some reasons (e.g. mobility, power limit) one PDA is not always able to communicate with any others. * An inter-planet satellite communication network where satellites may only communicate with each other several times a day. * A sensor network where sensors are not powerful enough to submit data to a collecting server. * A military field communication network where nodes (e.g. tanks, soldier communication equipments) are subject to being destroyed. The characteristics of DTNs are very different from the traditional computer networks (e.g. the Internet) in that the latter have some well-known assumptions: 1) continuous connectivity, 2) very low packet loss rate, and 3) reasonably low propagation delay and queueing delay. DTNs do not satisfy all of the assumptions, and sometimes none. Wireless ad hoc networks bear some similarities with some types of DTNs since some parts of them may actually form an ad hoc network. However, wireless ad hoc networks still have those assumptions. In consequence, the existing protocols will not be able to handle the data transmission in DTNs. New protocols and algorithms need to be developed. Within the overall category of DTN, there are actually several different types of DTN due to their different characteristics. For instance, in the example DTNs above, the first example is dramatically different from the second one. The satellite trajectories are predictable while the movement of a person may be random. Therefore, for different types of DTNs, different solutions may need to be proposed. Under some situations, DTNs may not yield satisfying performance due to the limitation of environments. However, a good algorithm should be able to decide whether certain conditions can satisfy certain criteria, and if they do, form paths to allow ?smooth? data transmission. This session will provide a platform for discussion of various algorithms, their performance, and the applications that utilize DTNs. The session will serve as a forum for scientists, leading experts, technical professionals, and users involved in research and application development of DTN. They will gather together to discuss the benefits, challenges, risks, and applications of DTN. At the same time this session is an attempt to bring together those organizations involved in topics of DTN. Paper Submissions Authors are invited to submit papers describing in detail the original contribution on the various current issues involved with social computing. Each submission should be a maximum of 7-pages in the IEEE Proceedings format , including a 100 word abstract, and a cover page listing the name, affiliation, complete address, telephone, e-mail, and facsimile information for the corresponding author. Contributions will be reviewed by at least three reviewers from both Program Committee and external reviewers for originality, significance, clarity, soundness, relevance and technical contents on basis of papers. Electronic submission of papers is strongly encouraged (pdf, postscript, or MS Word). Authors can submit their papers via email to lij@scs.howard.edu or blegand@scs.howard.edu. Deadline for submission is Feb. 16, 2005. If electronic submission is not possible, the paper can be submitted via regular mail to : Dr. Jiang Li, or Dr. L. Burge III Department of Systems and Computer Science B36-A Mackey Bldg. Howard University Washington, DC 20059, USA The Proceedings will be published by CSREA Press (ISBN) in hardcopy/book. The proceedings will be available at the conference. In addition to the hardcopy, it is also planned to publish the papers on a CD. All conference proceedings published by CSREA Press are considered for inclusion in major database indexes that are designed to provide easy access to the current literature of the sciences (database examples: ISI Thomson Scientific, IEE INSPEC, ...). A special issue of the International Journal of Wireless and Mobile Computing (IJWMC) is being planned consisting of selected papers from ICWN (not just this special session). ? Papers due: Feb. 16, 2005 ? Notification of Acceptance: March 21, 2005 ? Camera-Ready Paper Due: April 20, 2005 For more information, send an email to one of two session organizers, L. Burge: blegand@scs.howard.edu, or Jiang Li: lij@scs.howard.edu Topics of Interest include, but not limited to the following: ? Routing Algorithms ? Packet Storage and Forwarding ? Congestion and Flow Control ? Interoperability of Proprietary Networking Protocols ? Security ? Middleware Technology ? Application of DTN ? Performance and Modeling ? Simulation Call for Reviewers: The Special Session is in need of reviewers that are knowledgeable in the field.We plan to send a list of abstracts to each reviewer to select some papers to review. If you are willing to review some number of papers, (preferably between two and four, but any number will do!), please send a note to lij@scs.howard.edu or blegand@scs.howard.edu. The deadline for reviewers is early January 31, 2005. -- Jiang (Leo) Li, Assistant Professor Department of Systems and Computer Science Howard University, Washington, DC 202-865-0056 From skaniyar at hotmail.com Wed Dec 8 11:32:43 2004 From: skaniyar at hotmail.com (sanjay kaniyar) Date: Wed Dec 8 11:34:14 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <41B5D491.8070402@isi.edu> Message-ID: RST is sent out because the application does not care about the connection anymore. For instance, say an application sent data, issued a Shutdown() to close the connection gracefully - it waits for a duration of its choice but the disconnect does not complete and it wants to abort the connection. The Close() enables the application do exactly that. But, this instance may be completely unrelated - let's see what Gouthatm's test does. Thanks, Sanjay -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Tuesday, December 07, 2004 8:05 AM To: sanjay kaniyar Cc: 'Ted Faber'; end2end-interest@postel.org Subject: Re: [e2e] Is this a bug with Windows TCP Stack ? sanjay kaniyar wrote: > Winsock API has subtle semantics, I am not totally sure but something like > this could result in the observed trace: > > - IIS does send > - does Shutdown(SD_SEND) -> data and FIN go out. > - setsockopt(Linger = OFF) > - closesocket -> RST goes out. Why RST here? RST should be associated with an abort call. Closes that don't involve errors should not cause RSTs. The issue, IMO, is 'what is the _error_ here_'? Lingering state is not an error. Joe From touch at ISI.EDU Wed Dec 8 21:16:13 2004 From: touch at ISI.EDU (Joe Touch) Date: Wed Dec 8 21:18:51 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: References: Message-ID: <41B7DF9D.4030605@isi.edu> sanjay kaniyar wrote: > RST is sent out because the application does not care about the connection > anymore. "not care" is not an error. RST is supposed to go out only for a transport protocol error or an application ABORT. Abort doesn't carry the 'I don't care' semantics; it's deliberate blowing away of state, and should be used with caution, IMO. > For instance, say an application sent data, issued a Shutdown() to > close the connection gracefully - it waits for a duration of its choice but > the disconnect does not complete and it wants to abort the connection. The > Close() enables the application do exactly that. Why does it need to abort the connection? If the disconnect doesn't complete, the CLOSE should resend the FIN. If the FIN arrives and a RST is sent in response, so be it, but that's what would happen - not the other way around. Besides, disconnect only means "I have nothing more to send" - closes are half-closes, not full, in TCP. If what you wanted was "close both ends", you are better off picking (or designing) another protocol, rather than abusing TCP. Joe > But, this instance may be completely unrelated - let's see what Gouthatm's > test does. > > Thanks, > Sanjay > > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Tuesday, December 07, 2004 8:05 AM > To: sanjay kaniyar > Cc: 'Ted Faber'; end2end-interest@postel.org > Subject: Re: [e2e] Is this a bug with Windows TCP Stack ? > > > > sanjay kaniyar wrote: > >>Winsock API has subtle semantics, I am not totally sure but something like >>this could result in the observed trace: >> >>- IIS does send >>- does Shutdown(SD_SEND) -> data and FIN go out. >>- setsockopt(Linger = OFF) >>- closesocket -> RST goes out. > > > Why RST here? RST should be associated with an abort call. Closes that > don't involve errors should not cause RSTs. > > The issue, IMO, is 'what is the _error_ here_'? Lingering state is not > an error. > > 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/20041208/1473ff38/signature.bin From mcguire at cs.utexas.edu Fri Dec 10 14:40:51 2004 From: mcguire at cs.utexas.edu (Tommy Marcus McGuire) Date: Fri Dec 10 14:42:49 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <41B7DF9D.4030605@isi.edu> References: <41B7DF9D.4030605@isi.edu> Message-ID: <20041210224051.GA13537@davit.cs.utexas.edu> I've seen comments about shutdown() like Sanjay's before, and either I don't understand the comments, or the use of shutdown(). I've only used shutdown() to close half of the two-way connection, either to indicate that I'm not writing anything more on it (Which will result in an end-of-file condition when the FIN gets to the receiver.) or to indicate that my end is not going to be reading anything (Which is rare; I'm not sure what would happen if the other end of the connection tried to write to it. A RST maybe?). If I don't care about the connection at all, I call close() and forget about it. If the other side wants to write to the connection, it will get a RST, but that's not my problem. If the other side is still reading, it will get the FIN. The TCP stack on the local machine should handle the wait states just fine. What I've seen (and interpret Sanjay's comments below to mean) is advice to use shutdown() (for both halves of the connection) and then close(), which doesn't make sense---the close() should report a local error since the shutdown has already done everything the close would do. Is a close() on a previously-shutdown() connection supposed to generate a RST? If so, why? Like Joe said, there's no error here. On Wed, Dec 08, 2004 at 09:16:13PM -0800, Joe Touch wrote: > sanjay kaniyar wrote: > >RST is sent out because the application does not care about the connection > >anymore. > > "not care" is not an error. > > RST is supposed to go out only for a transport protocol error or an > application ABORT. Abort doesn't carry the 'I don't care' semantics; > it's deliberate blowing away of state, and should be used with caution, IMO. > > >For instance, say an application sent data, issued a Shutdown() to > >close the connection gracefully - it waits for a duration of its choice but > >the disconnect does not complete and it wants to abort the connection. The > >Close() enables the application do exactly that. > > Why does it need to abort the connection? If the disconnect doesn't > complete, the CLOSE should resend the FIN. If the FIN arrives and a RST > is sent in response, so be it, but that's what would happen - not the > other way around. > > Besides, disconnect only means "I have nothing more to send" - closes > are half-closes, not full, in TCP. If what you wanted was "close both > ends", you are better off picking (or designing) another protocol, > rather than abusing TCP. -- Tommy McGuire From skaniyar at hotmail.com Sun Dec 12 17:30:09 2004 From: skaniyar at hotmail.com (sanjay kaniyar) Date: Sun Dec 12 17:32:23 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041210224051.GA13537@davit.cs.utexas.edu> Message-ID: Tommy, A Shutdown(SD_SEND) followed by a Close() results in a RST only when there is unacknowledged data or FIN on the connection in that direction. Otherwise, a Close() just releases the local system resources for that connection. The semantics of Windows sockets implementation for Shutdown() is detailed at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/shutdown_2.asp Most of it is similar to what you described below. Thanks, Sanjay >From: Tommy Marcus McGuire >To: end2end-interest@postel.org >Subject: Re: [e2e] Is this a bug with Windows TCP Stack ? >Date: Fri, 10 Dec 2004 16:40:51 -0600 > >I've seen comments about shutdown() like Sanjay's before, and either I >don't understand the comments, or the use of shutdown(). > >I've only used shutdown() to close half of the two-way connection, >either to indicate that I'm not writing anything more on it (Which will >result in an end-of-file condition when the FIN gets to the receiver.) >or to indicate that my end is not going to be reading anything (Which is >rare; I'm not sure what would happen if the other end of the connection >tried to write to it. A RST maybe?). > >If I don't care about the connection at all, I call close() and forget >about it. If the other side wants to write to the connection, it will >get a RST, but that's not my problem. If the other side is still >reading, it will get the FIN. The TCP stack on the local machine should >handle the wait states just fine. > >What I've seen (and interpret Sanjay's comments below to mean) is advice >to use shutdown() (for both halves of the connection) and then close(), >which doesn't make sense---the close() should report a local error >since the shutdown has already done everything the close would do. Is >a close() on a previously-shutdown() connection supposed to generate a >RST? If so, why? Like Joe said, there's no error here. > >On Wed, Dec 08, 2004 at 09:16:13PM -0800, Joe Touch wrote: > > sanjay kaniyar wrote: > > >RST is sent out because the application does not care about the >connection > > >anymore. > > > > "not care" is not an error. > > > > RST is supposed to go out only for a transport protocol error or an > > application ABORT. Abort doesn't carry the 'I don't care' semantics; > > it's deliberate blowing away of state, and should be used with caution, >IMO. > > > > >For instance, say an application sent data, issued a Shutdown() to > > >close the connection gracefully - it waits for a duration of its choice >but > > >the disconnect does not complete and it wants to abort the connection. >The > > >Close() enables the application do exactly that. > > > > Why does it need to abort the connection? If the disconnect doesn't > > complete, the CLOSE should resend the FIN. If the FIN arrives and a RST > > is sent in response, so be it, but that's what would happen - not the > > other way around. > > > > Besides, disconnect only means "I have nothing more to send" - closes > > are half-closes, not full, in TCP. If what you wanted was "close both > > ends", you are better off picking (or designing) another protocol, > > rather than abusing TCP. > > >-- >Tommy McGuire From sommerfeld at orchard.arlington.ma.us Mon Dec 13 06:55:05 2004 From: sommerfeld at orchard.arlington.ma.us (Bill Sommerfeld) Date: Mon Dec 13 06:56:24 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041210224051.GA13537@davit.cs.utexas.edu> References: <41B7DF9D.4030605@isi.edu> <20041210224051.GA13537@davit.cs.utexas.edu> Message-ID: <1102949704.1094.1573.camel@unknown.hamachi.org> On Fri, 2004-12-10 at 17:40, Tommy Marcus McGuire wrote: > What I've seen (and interpret Sanjay's comments below to mean) is advice > to use shutdown() (for both halves of the connection) and then close(), > which doesn't make sense---the close() should report a local error > since the shutdown has already done everything the close would do. Not quite. In the systems I'm familiar with (not windows), shutdown() will not free up the file descriptor even if you shut down both directions. So a close() will succeed -- but at that point it has only local effect (allowing the reuse of the file descriptor table slot within that process). two other points: 1) on many systems, sockets can be shared between processes; a close() means that *this* process is done with the socket, but others may still keep it open; however, "shutdown" is a declaration that *all* users of the descriptor are done sending/receiving. 2) It may also be the case -- I haven't checked yet -- that some of the getsockopt() calls will still return sensible data after a shutdown. - Bill From alokdube at hotpop.com Sat Dec 18 14:29:57 2004 From: alokdube at hotpop.com (Alok) Date: Sat Dec 18 14:30:40 2004 Subject: [e2e] theory behind staistical multiplexing Message-ID: <00ba01c4e551$1c4397c0$50f7c3d8@rs.riverstonenet.com> Hi, What would be a good reference to the mathematical work behind "stastical multiplexing". For example, does it assume a model M/G/1, M/M/infinity etc? -thanks Alok From Steven.Berson at aero.org Sat Dec 18 15:02:51 2004 From: Steven.Berson at aero.org (Steven Berson) Date: Sat Dec 18 15:06:45 2004 Subject: [e2e] theory behind staistical multiplexing In-Reply-To: <00ba01c4e551$1c4397c0$50f7c3d8@rs.riverstonenet.com> References: <00ba01c4e551$1c4397c0$50f7c3d8@rs.riverstonenet.com> Message-ID: <41C4B71B.8080605@aero.org> I think of the law of large numbers as being the basis for statistical multiplexing. Any good probability book (e.g. Feller, Ross) will have good coverage of the law of large numbers. The law of large numbers is far more general than specific queueing models. Steve Alok wrote: >Hi, > >What would be a good reference to the mathematical work behind "stastical >multiplexing". > >For example, does it assume a model M/G/1, M/M/infinity etc? > >-thanks >Alok > > > > From alokdube at hotpop.com Sat Dec 18 21:46:32 2004 From: alokdube at hotpop.com (Alok) Date: Sat Dec 18 21:48:47 2004 Subject: [e2e] theory behind staistical multiplexing References: <00ba01c4e551$1c4397c0$50f7c3d8@rs.riverstonenet.com> <41C4B71B.8080605@aero.org> Message-ID: <000801c4e58e$191accc0$0200a8c0@rs.riverstonenet.com> Hi, my question was specific to queueing theories, not the bases of probability. -thanks Alok ----- Original Message ----- From: "Steven Berson" To: "Alok" Cc: Sent: Saturday, December 18, 2004 3:02 PM Subject: Re: [e2e] theory behind staistical multiplexing > I think of the law of large numbers as being the basis for statistical > multiplexing. Any good probability book (e.g. Feller, Ross) will have > good coverage of the law of large numbers. > > The law of large numbers is far more general than specific queueing models. > > Steve > > Alok wrote: > > >Hi, > > > >What would be a good reference to the mathematical work behind "stastical > >multiplexing". > > > >For example, does it assume a model M/G/1, M/M/infinity etc? > > > >-thanks > >Alok > > > > > > > > > > From Jon.Crowcroft at cl.cam.ac.uk Sun Dec 19 02:46:04 2004 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun Dec 19 02:49:11 2004 Subject: [e2e] theory behind staistical multiplexing In-Reply-To: Message from Steven Berson of "Sat, 18 Dec 2004 15:02:51 PST." <41C4B71B.8080605@aero.org> Message-ID: I agree about this, but its the statistics of the sources that make stat muxing make sense - depends on timescales, but at least 2 characteristics are the session arrivals and the packet arrivals within session (this is sort of circular definition, since if there was no stat muxing gain, then we might not talk about packets at all - i guess as a computer scientist though one might talk about the symbols of an alphabet - very old networks used byte/character/octet as the unit of the net - - newer systems use packets which correspond to convenient size units for computers (disk block size, page size, delta in a change to screen, or multimedia sample size) ? so if you have a set of CBR flows that are relatively long lived (e.g. a lot of TV and radio stations, or a lot of voice/video calls with legacy CODECs) then the stat mux "gain" is typically small to zero but if you have a set of VBR flows that may also be short lived then you have periods of silence during which resources on a path between one source and destination can be shared by another source and/or destination so thats to do with the temporal characteristics of the sessions. now you can also think about spatial characteristcs of traffic overal (i.e. the overal sparsity or denseity of the source/destination set at any time) you could have very short lived CBR flows too (then it depends on the spatial layout of the sources and destinations, and the economics of link versus switches, what sort of concentration you get in your net therefore what the stat muxing gain on the loinger haul links is) I dont know a single reference that discusses this - the best stuff is probably in books on network design - the problem with these is that most are donkey's years old, so dont have in stuff about modern flow characteristics (e.g. TCP source model, like Padhye or other, and RTP/VOIP source models) nor about the traffic matrix (e.g. the stuff in various papers out of sprint and at&t research in last few years..) or about the network topology (which is not _designed_ per se: in the Internet today, once one gets past a single AS, since the way the inter-domain topology has evolved is an economic/natural process, and therefore the way the trafficmatrix and the topology interact, and the way the source model and aggregation/stat muxing work on inter-domain paths is an altogether not fully understood thing, no not at all.... I guess I like Keshav's book on an Engineering approach to networking, as capturing some of this stuff about as well as you can, but that is getting on a bit - I dont know of an accessible book (there's walrand and other folks, but they are for math folk really...) In missive <41C4B71B.8080605@aero.org>, Steven Berson typed: >>I think of the law of large numbers as being the basis for statistical >>multiplexing. Any good probability book (e.g. Feller, Ross) will have >>good coverage of the law of large numbers. >> >>The law of large numbers is far more general than specific queueing models. >> >>Steve >> >>Alok wrote: >> >>>Hi, >>> >>>What would be a good reference to the mathematical work behind "stastical >>>multiplexing". >>> >>>For example, does it assume a model M/G/1, M/M/infinity etc? >>> >>>-thanks >>>Alok >>> >>> >>> >>> >> cheers jon From ymjiang at ieee.org Sun Dec 19 03:31:58 2004 From: ymjiang at ieee.org (Yuming Jiang) Date: Sun Dec 19 03:32:50 2004 Subject: [e2e] theory behind staistical multiplexing In-Reply-To: <000801c4e58e$191accc0$0200a8c0@rs.riverstonenet.com> References: <00ba01c4e551$1c4397c0$50f7c3d8@rs.riverstonenet.com> <41C4B71B.8080605@aero.org> <000801c4e58e$191accc0$0200a8c0@rs.riverstonenet.com> Message-ID: <41C566AE.30101@ieee.org> Hi Alok, The following book may be a good reference to this: James Roberts, Ugo Mocci and Jorma Virtamo (Eds.), "Broadband Network Teletraffic: Performance Evaluation and Design of Broadband Multiservice Networks - Final Report of Action COST 242", Springer-Verlag, 1996. Regards, Yuming Jiang http://www.q2s.ntnu.no/~jiang/ Alok wrote: > Hi, > > my question was specific to queueing theories, not the bases of probability. > > -thanks > Alok > > ----- Original Message ----- > From: "Steven Berson" > To: "Alok" > Cc: > Sent: Saturday, December 18, 2004 3:02 PM > Subject: Re: [e2e] theory behind staistical multiplexing > > > >>I think of the law of large numbers as being the basis for statistical >>multiplexing. Any good probability book (e.g. Feller, Ross) will have >>good coverage of the law of large numbers. >> >>The law of large numbers is far more general than specific queueing > > models. > >>Steve >> >>Alok wrote: >> >> >>>Hi, >>> >>>What would be a good reference to the mathematical work behind "stastical >>>multiplexing". >>> >>>For example, does it assume a model M/G/1, M/M/infinity etc? >>> >>>-thanks >>>Alok >>> >>> >>> >>> >> >> > > From skaniyar at hotmail.com Mon Dec 27 17:33:52 2004 From: skaniyar at hotmail.com (sanjay kaniyar) Date: Mon Dec 27 17:35:03 2004 Subject: [e2e] Is this a bug with Windows TCP Stack ? In-Reply-To: <20041210224051.GA13537@davit.cs.utexas.edu> Message-ID: Goutham - have you had a chance to find a test that you can share with us? Thanks, Sanjay -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org] On Behalf Of Tommy Marcus McGuire Sent: Friday, December 10, 2004 2:41 PM To: end2end-interest@postel.org Subject: Re: [e2e] Is this a bug with Windows TCP Stack ? I've seen comments about shutdown() like Sanjay's before, and either I don't understand the comments, or the use of shutdown(). I've only used shutdown() to close half of the two-way connection, either to indicate that I'm not writing anything more on it (Which will result in an end-of-file condition when the FIN gets to the receiver.) or to indicate that my end is not going to be reading anything (Which is rare; I'm not sure what would happen if the other end of the connection tried to write to it. A RST maybe?). If I don't care about the connection at all, I call close() and forget about it. If the other side wants to write to the connection, it will get a RST, but that's not my problem. If the other side is still reading, it will get the FIN. The TCP stack on the local machine should handle the wait states just fine. What I've seen (and interpret Sanjay's comments below to mean) is advice to use shutdown() (for both halves of the connection) and then close(), which doesn't make sense---the close() should report a local error since the shutdown has already done everything the close would do. Is a close() on a previously-shutdown() connection supposed to generate a RST? If so, why? Like Joe said, there's no error here. On Wed, Dec 08, 2004 at 09:16:13PM -0800, Joe Touch wrote: > sanjay kaniyar wrote: > >RST is sent out because the application does not care about the connection > >anymore. > > "not care" is not an error. > > RST is supposed to go out only for a transport protocol error or an > application ABORT. Abort doesn't carry the 'I don't care' semantics; > it's deliberate blowing away of state, and should be used with caution, IMO. > > >For instance, say an application sent data, issued a Shutdown() to > >close the connection gracefully - it waits for a duration of its choice but > >the disconnect does not complete and it wants to abort the connection. The > >Close() enables the application do exactly that. > > Why does it need to abort the connection? If the disconnect doesn't > complete, the CLOSE should resend the FIN. If the FIN arrives and a RST > is sent in response, so be it, but that's what would happen - not the > other way around. > > Besides, disconnect only means "I have nothing more to send" - closes > are half-closes, not full, in TCP. If what you wanted was "close both > ends", you are better off picking (or designing) another protocol, > rather than abusing TCP. -- Tommy McGuire From dedinski at fmi.uni-passau.de Wed Dec 22 06:56:37 2004 From: dedinski at fmi.uni-passau.de (ivan dedinski) Date: Thu Dec 30 08:26:02 2004 Subject: [e2e] Call for Paper IWQoS 2005 In-Reply-To: <41C83762.3050905@fmi.uni-passau.de> References: <41C83762.3050905@fmi.uni-passau.de> Message-ID: Dear Madam, Dear Sir, [sincere apologies for possible multiple copies of this message] we are pleased to inform you that the *Thirteenth International Workshop on Quality of Service (IWQoS 2005)* * *will be held in the University of Pasau, Germany, on June 21-23, 2005 Call for papers (full version pdf-file: see appendix) IWQoS has emerged as the prime annual event on Quality-of-Service (QoS)-related research and technologies. Building on the successes of previous workshops, the objective of the workshop is to bring together researchers, developers, and practitioners working in this area to discuss recent and innovative results, and identify future directions and challenges. IWQoS has a long standing tradition of being highly interactive while maintaining highest standards of competitiveness and excellence. This characteristic will be re-emphasized by intercepting the regular paper sessions with stimulating discussion events about controversial and cutting edge topics. The program will include the following highlights: * Key Note by Industrial Speaker * A Panel on "Self-Organization and QoS" by David Hutchison, Lancaster Univ, U.K. * A Position Paper Session on "The Impact of QoS: Where Industry meets Academia" by Francois Le Faucheur, Cicso Systems France and Georgios Karagiannis, Twente Univ., The Netherlands. * A Works in Progress Session focusing on emerging research * Key Note and Invited Paper by Randy Katz, UC Berkeley, U.S.A. * Industrial Exhibition and Demonstration of Tools and Methods related to Quality of Communication by Jan de Meer, Institute for High-performance Microelectronics GmbH, Frankfurt (Oder), Germany The panel and the short paper sessions will be highly interactive and leave much time and space for the audience to get involved. The position and short papers will go through the general reviewing process but the papers must specifically be submitted to fit the track. Short versions of regular technical papers will not be accepted here. It is rather encouraged to submit work that is either stimulating with a long term vision or that points to immediate relevance with need for controversial debate to address the foremost experts at the venue. Technical Program Quality of Service principles can be applied to a large number of domains. Our goal is to broaden the areas that QoS research can be pulled from by recognizing the multi-disciplinary aspect to much of the research. In addition to the traditional areas, the call for papers does solicit, but is not limited to, papers in such areas as: * QoS in mobile/wireless environments, Sensor networks, 4G (IP for 3G) * QoS in overlays and peer-to-peer networks * QoS in GRID environments * SLA: end-to-end QoS, QoS in large scale, heterogeneous environments * QoS-aware software components: QoS for Web Services * QoS and self-organizing systems * New frontiers of QoS * QoS measurement versus control * QoS adaptation versus resource reservation * Hidden QoS issues, have we just learned to ignore QoS problems? * QoS in context aware systems (also related to mobility) * User perception/user interfaces for QoS * QoS and distributed systems * QoS and middleware * Fault tolerance and QoS * QoS in ad hoc networks * Economics and QoS * Security, trust and QoS * QoS in the home and everywhere * QoS and new media * QoS and haptics , virtual environments * QoS in buisiness processes, workflows IWQoS aims to allow rapid dissemination of research results and to provide fast turnaround. The deadline for papers is therefore as close to the conference as the publishers allow. The workshop is a single-track forum spanning two and a half days. It values both theoretical contributions and practical experience. Web Site: http://www.fmi.uni-passau.de/iwqos Best Student Paper Award Award will be given at the conference to the best student paper, whose first author is a current student. Paper Submission IWQoS invites submission of manuscripts that present original research results, and that have not been previously published or currently under review by another conference or journal. Any previous or simultaneous publication of related material should be explicitly noted in the submission. Submissions should be full-length papers that are no longer than 20 double-spaced single-column pages with font sizes of 11 or larger, including all figures and references, and must include an abstract of 100 -- 150 words. All papers must be submitted in either Postscript or the Adobe PDF format, and no other formats are accepted by the paper submission web site. Submissions will be judged on originality, significance, interest, clarity, relevance, and correctness. At least one of the authors of each accepted paper must present the paper at IWQoS 2004. The paper submission can be done here . Short Position Papers for Industry Session and Works in Progress We solicit submissions of short papers for the two sessions outlined above. The short papers are limited to three single-spaced pages. Accepted papers will be presented in a 15-minute time period, and will be included in the conference proceedings. Important Dates: * Paper abstract deadline: February 16th , 2005, 11:59pm CET * Full paper submission deadline: February 22th , 2005, 11:59pm CET * Short paper submission deadline: March 7th, 2005, 11:59pm CET * Notification of acceptance: March 24th , 2005 * Camera-ready papers due: April 8, 2005 * Hotel reservation cut-off date: May 19th , 2005 * Early registration deadline: April 8th, 2005 * Workshop dates: June 21-23 , 2005 * Workshop reception and welcome party: June 20th, 2005 Organizational Objectives Among strong industrial and academic support the 13th IWQoS is supported by the three organizing institutions: * University of Passau, Germany * HP Laboratories Palo Alto, California USA * IHP Institute on Microelectronics GmbH, Brandenburg Germany The University of Passau will host the all conference activities; it provides excellent conference support for up to 1,000 participants. Features of university support include: * Support desk in the conference area with professional team to handle technical and logistical issues. * Lecture room with 180 seats, video projector, internet access * WLAN connection * Reserved lunch area on the Inn river banks * Exhibition space *Program Chairs: *Hermann De Meer University of Passau Passau, Germany mail: demeer@fmi.uni-passau.de Nina Bhatti Hewlett Packard Laboratories Palo Alto, California USA email: nina.bhatti@hp.com -------------- next part -------------- A non-text attachment was scrubbed... Name: cfp.pdf Type: application/pdf Size: 149152 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041222/94a079f4/cfp-0001.pdf