From: Geoff Voelker To: cse222@cs.ucsd.edu Subject: TCP: streams vs. packets Date: Tue, 30 Jan 2001 21:35:23 -0800 (PST) I think it was last Thursday when someone asked about TCP acking bytes vs. packets, which reflects TCP being stream-based (bytes) vs. packet-based (packets) (although the issues are not necessarily one in the same). Below is a discussion thread that I saved for posterity back in 1997. The first message poses the question of why TCP was designed to be stream based instead of packet based. [This discussion is for your interest only, delete it if it holds no interest to you.] I think that there are a couple of interesting things that fall out of this discussion, though. One is that a seemingly simple question can generate answers all over the map. Another is that there are answers from the people who designed the protocol (can't get any more of a direct source than that). A third is that the question turns out to be surprisingly deep -- the issues for stream vs. packet are subtle and have significant implications on protocol implementation as well as application behavior/implementation. Lastly, it shows that different people have different approaches and convictions about network and protocol design -- another reminder that the Internet today is just one answer/approach. FYI, The list "end2end-interest" is a discussion forum for end2end Internet issues. -geoff ------- start of forwarded message (RFC 934 encapsulation) ------- >From majordom@ISI.EDU Mon Aug 25 16:13:37 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "25" "August" "1997" "15:42:54" "-0700" "Mohan Parthasarathy" "Mohan.Parthasarathy@eng.sun.com" nil "5" "stream/packet" "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id QAA06974; Mon, 25 Aug 1997 16:13:35 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 25 Aug 1997 15:48:17 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 25 Aug 1997 15:48:15 -0700 Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA13379 for ; Mon, 25 Aug 1997 15:48:14 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA15582 for ; Mon, 25 Aug 1997 15:47:43 -0700 Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id PAA06011; Mon, 25 Aug 1997 15:47:40 -0700 Received: from ahiri.eng.sun.com (ahiri [129.146.82.177]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA07066 for ; Mon, 25 Aug 1997 15:47:42 -0700 (PDT) Received: by ahiri.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05465; Mon, 25 Aug 1997 15:42:54 -0700 Message-Id: <199708252242.PAA05465@ahiri.eng.sun.com> X-Sun-Charset: US-ASCII Precedence: bulk From: Mohan.Parthasarathy@eng.sun.com (Mohan Parthasarathy) Sender: owner-end2end-interest@ISI.EDU To: end2end-interest@ISI.EDU Subject: stream/packet Date: Mon, 25 Aug 1997 15:42:54 -0700 Why is TCP stream based rather than packet based ? What were the criteria in chosing one over the other ? Thanks - -mohan >From majordom@ISI.EDU Mon Aug 25 16:37:04 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "25" "August" "1997" "16:14:16" "-0700" "Greg Minshall" "minshall@ipsilon.com" nil "16" "Re: stream/packet " "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id QAA08167; Mon, 25 Aug 1997 16:37:03 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 25 Aug 1997 16:14:51 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 25 Aug 1997 16:14:47 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA14909 for ; Mon, 25 Aug 1997 16:14:46 -0700 (PDT) Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id QAA07601; Mon, 25 Aug 1997 16:14:16 -0700 Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id QAA02261; Mon, 25 Aug 1997 16:14:17 -0700 Message-Id: <199708252314.QAA02261@red.ipsilon.com> X-Mailer: exmh version 1.6.9 8/22/96 In-Reply-To: Your message of "Mon, 25 Aug 1997 15:42:54 PDT." <199708252242.PAA05465@ahiri.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk From: Greg Minshall Sender: owner-end2end-interest@ISI.EDU To: Mohan.Parthasarathy@eng.sun.com (Mohan Parthasarathy) Cc: end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Mon, 25 Aug 1997 16:14:16 -0700 Mohan, There are probably lots of reasons, and others will pitch in with them. However, three trivial reasons that occur to me are: 1. Ability to treat SYN and FIN as "data", thus allowing them to be retransmitted, acknowledged, etc. 2. If the path MTU shrinks with unacknowledged data in-flight, it gets tricky to figure out how to map "old packet sequence numbers" to "new packet sequence numbers". 3. Ability to send bytes [n .. n+m] in one packet, then retransmit as [n .. n+m+p]. Greg Minshall >From majordom@ISI.EDU Mon Aug 25 16:45:23 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" "25" "August" "1997" "16:17:21" "PDT" "braden@isi.edu" "braden@isi.edu" nil "36" "Re: stream/packet" "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id QAA08623; Mon, 25 Aug 1997 16:45:22 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 25 Aug 1997 16:19:08 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 25 Aug 1997 16:19:01 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA15639 for ; Mon, 25 Aug 1997 16:18:59 -0700 (PDT) Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 25 Aug 1997 16:15:45 -0700 Posted-Date: Mon, 25 Aug 97 16:17:21 PDT Message-Id: <9708252317.AA29172@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-6) id ; Mon, 25 Aug 97 16:17:21 PDT Precedence: bulk From: braden@ISI.EDU Sender: owner-end2end-interest@ISI.EDU To: end2end-interest@ISI.EDU, Mohan.Parthasarathy@eng.sun.com Subject: Re: stream/packet Date: Mon, 25 Aug 97 16:17:21 PDT *> From majordom@ISI.EDU Mon Aug 25 16:09:37 1997 *> Date: Mon, 25 Aug 1997 15:42:54 -0700 *> From: Mohan.Parthasarathy@eng.sun.com (Mohan Parthasarathy) *> To: end2end-interest@ISI.EDU *> Subject: stream/packet *> X-Sun-Charset: US-ASCII *> Sender: owner-end2end-interest@ISI.EDU *> Precedence: bulk *> Content-Length: 122 *> X-Lines: 5 *> *> Why is TCP stream based rather than packet based ? What *> were the criteria in chosing one over the other ? *> *> Thanks *> -mohan *> Oh, boy! Off the top of my head: (1) Because the ARPANET NCP protocol was stream based. (In 1972, I asked Steve Crocker "Why is NCP stream based"? His answer, roughly was, "That's a very interesting question") (2) Because Computer Scientists are reductionist, and streams are logically simpler than sequences of blocks. [A stream is a sequence of blocks of length 1 byte. There is no number as simple as 1, except maybe 0, and blocks of length 0 are not interesting.] Bob Braden >From majordom@ISI.EDU Tue Aug 26 15:08:17 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Tue" "26" "August" "1997" "14:56:19" "-0700" "Mohan Parthasarathy" "Mohan.Parthasarathy@eng.sun.com" nil "81" "Re: stream/packet" "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id PAA10796; Tue, 26 Aug 1997 15:08:16 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 26 Aug 1997 15:01:52 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 26 Aug 1997 15:01:49 -0700 Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA02530 for ; Tue, 26 Aug 1997 15:01:48 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA03600; Tue, 26 Aug 1997 15:01:17 -0700 Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id PAA08838; Tue, 26 Aug 1997 15:01:10 -0700 Received: from ahiri.eng.sun.com (ahiri [129.146.82.177]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA14824; Tue, 26 Aug 1997 15:01:08 -0700 (PDT) Received: by ahiri.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA06802; Tue, 26 Aug 1997 14:56:19 -0700 Message-Id: <199708262156.OAA06802@ahiri.eng.sun.com> X-Sun-Charset: US-ASCII Precedence: bulk From: Mohan.Parthasarathy@eng.sun.com (Mohan Parthasarathy) Sender: owner-end2end-interest@ISI.EDU To: rimcfar@afterlife.ncsc.mil Cc: end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Tue, 26 Aug 1997 14:56:19 -0700 It is interesting that such an issue has decided how TCP would be implemented. Initially I was wondering whether performance etc would be the real evaluating criteria for such major decisions. None of the books really mentions this point. As an afterthought, one could justify that streams based TCP is better. But still i have not seen any detailed analysis on these topics. Thanks - -mohan > From rimcfar@afterlife.ncsc.mil Tue Aug 26 12:54:47 1997 > From: "Ray I. McFarland Jr." > Date: Tue, 26 Aug 1997 15:58:21 -0400 > To: end2end-interest@isi.edu, Mohan.Parthasarathy@Eng, braden@isi.edu > Subject: Re: stream/packet > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-MD5: uZzzjjN0mp5OMLWSaJkBZg== > > I refer you to the original TCP paper written by Cerf and Kahn, in Jul 74 Trans > on Communications (I believe - or the Journal on Selected Comms) from IEEE > Communications Society. > > The original design did not have an IP associated with it. We only broke that > out as a separate protocol a few years later. The original design and TCP header > used sequence numbers for bytes, so that at a gateway (what today have become > known as routers) a message from an network permitting a larger bloc size to a > network with smaller block size could be fragmented into a number of smaller > blocks (packet integrity across network boundaries neither existed, nor was > assumed) at any arbitrary byte boundary. The byte sequence numbers in the TCP > header were accordingly adjusted, so the fragments could be correctly > reassembled at the final destination. > > Ray > > > > > From majordom@isi.edu Mon Aug 25 19:51:15 1997 > > Date: Mon, 25 Aug 97 16:17:21 PDT > > From: braden@isi.edu > > To: end2end-interest@isi.edu, Mohan.Parthasarathy@eng.sun.com > > Subject: Re: stream/packet > > > > > > *> From majordom@ISI.EDU Mon Aug 25 16:09:37 1997 > > *> Date: Mon, 25 Aug 1997 15:42:54 -0700 > > *> From: Mohan.Parthasarathy@eng.sun.com (Mohan Parthasarathy) > > *> To: end2end-interest@ISI.EDU > > *> Subject: stream/packet > > *> X-Sun-Charset: US-ASCII > > *> Sender: owner-end2end-interest@ISI.EDU > > *> Precedence: bulk > > *> Content-Length: 122 > > *> X-Lines: 5 > > *> > > *> Why is TCP stream based rather than packet based ? What > > *> were the criteria in chosing one over the other ? > > *> > > *> Thanks > > *> -mohan > > *> > > > > Oh, boy! > > > > Off the top of my head: > > > > (1) Because the ARPANET NCP protocol was stream based. > > > > (In 1972, I asked Steve Crocker "Why is NCP stream based"? > > His answer, roughly was, "That's a very interesting question") > > > > (2) Because Computer Scientists are reductionist, and streams are > > logically simpler than sequences of blocks. > > > > [A stream is a sequence of blocks of length 1 byte. There > > is no number as simple as 1, except maybe 0, and blocks of > > length 0 are not interesting.] > > > > Bob Braden > >From majordom@ISI.EDU Tue Aug 26 16:37:53 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Tue" "26" "August" "1997" "16:22:57" "-0700" "Craig Partridge" "craig@aland.bbn.com" nil "43" "Re: stream/packet " "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id QAA16288; Tue, 26 Aug 1997 16:37:53 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 26 Aug 1997 16:24:29 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 26 Aug 1997 16:24:27 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA14559 for ; Tue, 26 Aug 1997 16:24:24 -0700 (PDT) Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id QAA13204; Tue, 26 Aug 1997 16:22:58 -0700 (PDT) Message-Id: <199708262322.QAA13204@aland.bbn.com> In-Reply-To: Your message of Tue, 26 Aug 97 15:58:14 -0700. <199708262258.PAA06845@ahiri.eng.sun.com> Precedence: bulk From: Craig Partridge Sender: owner-end2end-interest@ISI.EDU To: Mohan.Parthasarathy@eng.sun.com (Mohan Parthasarathy) Cc: end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Tue, 26 Aug 97 16:22:57 -0700 It is interesting that such an issue has decided how TCP would be implemented. Initially I was wondering whether performance etc would be the real evaluating criteria for such major decisions. None of the books really mentions this point. As an afterthought, one could justify that streams based TCP is better. But still i have not seen any detailed analysis on these topics. Well, some of us on this list have experimented with RDP -- an alternative transport protocol that one can think of as similar to TCP but in which each user segement is a distinct packet on the wire. My conclusions from research with RDP were that record boundaries had some nice features but some nasty features that generally outweighed the nice features. The nice features were: * Your packets could be safely delivered out of order. * The segment boundaries sometimes made application parsing of inbound data easier. * Segment boundaries made the sequence handling code a lot easier (one sequence number per packet is nice!). The unfortunate features were: * The application had to be much more intimately involved in choosing segment sizes. A dumb application could easly launch many tinygrams, or moby-grams that were always fragmented. * Retransmission was less efficient -- if you had an adjacent small packet and large packet lost, you had to send two packets to recover, not one. There are probably other features/demerits I've forgotten. Deep down in my stack, there's a plan to take my 1987 RDP code and update it to modern standards (RTT estimation, large windows, etc) and see how it runs, just for fun. Craig >From majordom@ISI.EDU Tue Aug 26 16:50:18 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Tue" "26" "August" "1997" "19:44:41" "-0400" "Ray I. McFarland, Jr." "rimcfar@afterlife.ncsc.mil" nil "41" "Re: stream/packet" "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id QAA17100; Tue, 26 Aug 1997 16:50:18 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 26 Aug 1997 16:41:05 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 26 Aug 1997 16:41:03 -0700 Received: from afterlife.ncsc.mil (afterlife.ncsc.mil [144.51.1.1]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA13469 for ; Tue, 26 Aug 1997 16:41:03 -0700 (PDT) Received: from utopia (utopia [144.51.1.17]) by afterlife.ncsc.mil (8.8.6/8.6.6) with SMTP id TAA04690; Tue, 26 Aug 1997 19:40:29 -0400 (EDT) Received: by utopia (SMI-8.6) id TAA05311; Tue, 26 Aug 1997 19:44:41 -0400 Message-Id: <199708262344.TAA05311@utopia> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: IYQeVbPOnq3M7wIYEyMfrQ== Precedence: bulk From: "Ray I. McFarland Jr." Sender: owner-end2end-interest@ISI.EDU To: Mohan.Parthasarathy@eng.sun.com Cc: end2end-interest@ISI.EDU, rimcfar@afterlife.ncsc.mil Subject: Re: stream/packet Date: Tue, 26 Aug 1997 19:44:41 -0400 Initial emphasis was very heavy on just getting something to even work across multiple data networks. [This was a FIRST remember.] Performance was a distant concern, in part because bandwidth was then the limiting factor (64 kb/s data under voice on the POTS trunks of ARPAnet). There are/were a number of "histerical" artifacts that were carried forward. I think most folks at that time believed some "developmental rework" would occur to 'clean up' some of the incomplete changes that there wasn't time for (then), as in, 'we'll get back to clean that up .... ' WRONG! The success of the original stuff (unmodified) exceeded all expectations! (Probably the understatement of the year.) Which is one reason the IP address field problem erupted very early on. It was originally sized for a research community. [For 'histerical' examples, ask anyone from the old TCP Committee about how the "TCP Pseudo-header" came to be; or the infamous "rubber EOL" story!!! (You'll have to read the original paper, or the early Internet research notes, to find out what an EOL was :-) Oh the tales that could be told! ;-)] Rqy > From Mohan.Parthasarathy@eng.Sun.COM Tue Aug 26 19:04:10 1997 > Date: Tue, 26 Aug 1997 15:58:14 -0700 > From: Mohan.Parthasarathy@eng.Sun.COM (Mohan Parthasarathy) > To: rimcfar@afterlife.ncsc.mil > Subject: Re: stream/packet > Cc: end2end-interest@isi.edu > > It is interesting that such an issue has decided how TCP > would be implemented. Initially I was wondering whether > performance etc would be the real evaluating criteria > for such major decisions. None of the books really > mentions this point. As an afterthought, one could justify > that streams based TCP is better. But still i have not > seen any detailed analysis on these topics. > > Thanks > -mohan > > >From majordom@ISI.EDU Wed Aug 27 08:05:53 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Wed" "27" "August" "1997" "10:48:37" "-0400" "Simon Spero" "ses@tipper.oit.unc.edu" nil "22" "Re: stream/packet" "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id IAA16970; Wed, 27 Aug 1997 08:05:53 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Wed, 27 Aug 1997 07:48:18 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Wed, 27 Aug 1997 07:48:17 -0700 Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA13756 for ; Wed, 27 Aug 1997 07:48:16 -0700 (PDT) Received: from mossflower.oit.unc.edu (mossflower.oit.unc.edu [152.2.22.120]) by tipper.oit.unc.edu (8.6.12/8.6.10) with ESMTP id KAA06490; Wed, 27 Aug 1997 10:49:18 -0400 Message-Id: <34043E45.5F5F080F@tipper.oit.unc.edu> X-Mailer: Mozilla 4.01 [en] (Win95; I) Mime-Version: 1.0 X-Priority: 3 (Normal) References: <199708262344.TAA05311@utopia> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk From: Simon Spero Sender: owner-end2end-interest@ISI.EDU To: "Ray I. McFarland Jr." Cc: Mohan.Parthasarathy@eng.sun.com, end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Wed, 27 Aug 1997 10:48:37 -0400 Ray I. McFarland Jr. wrote: > [For 'histerical' examples, ask anyone from the old TCP Committee > about how the > "TCP Pseudo-header" came to be; or the infamous "rubber EOL" story!!! > (You'll have to read the original paper, or the early Internet > research > notes, to find out what an EOL was :-) Oh the tales that could be > told! ;-)] Is this the Rubber Baby Buffer Bumpers incident? Simon // anyway, if you want packets, just stick in a mini session layer... - -- Now available - The Freddy Hayek Kayak | "Pass me another elf Paddle Your Own Canoe! Be Rowed To Surfdom! | Sergeant- this one's >From The Taco Institute for Dyslexic Libertarians | split" >From majordom@ISI.EDU Sat Aug 30 00:43:24 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Sat" "30" "August" "1997" "02:36:31" "-0400" "John Day" "day@bbn.com" nil "151" "Re: stream/packet" "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id AAA20188; Sat, 30 Aug 1997 00:43:23 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 29 Aug 1997 23:48:01 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 29 Aug 1997 23:48:00 -0700 Received: from zafu.bbn.com (ZAFU.BBN.COM [192.1.50.38]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA12285 for ; Fri, 29 Aug 1997 23:47:59 -0700 (PDT) Received: from [128.89.30.21] (ARA21.BBN.COM [128.89.30.21]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id CAA17591; Sat, 30 Aug 1997 02:48:26 -0400 (EDT) Message-Id: In-Reply-To: <199708262322.QAA13204@aland.bbn.com> References: Your message of Tue, 26 Aug 97 15:58:14 -0700. <199708262258.PAA06845@ahiri.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk From: John Day Sender: owner-end2end-interest@ISI.EDU To: Craig Partridge , Mohan Parthasarathy Cc: end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Sat, 30 Aug 1997 02:36:31 -0400 Mohan, I have been out of touch for a few days and just picked up on this thread. I must say that Ray has it more right about why stream vs packet. It had very little to do with the more sophisticated arguments being offered. One clarification though. NCP was not really stream. It delivered messages that were 1 to 8 packets. You did have two knobs on the flow control, one in messages and one in bytes. And I am not sure we ever really learned how to use that. But it did let the record hosts deal with records and the stream hosts deal with bytes. Even after there was IP and it was no longer necessary there were many arguments for getting rid of it. The prevalant excuse was that there were devices that required very fine granularity flow control. Something about wireless sensors in the DMZ to detect Viet Cong, remember the MacNamara Line, no it was probably way before your time. (Remember it was a DoD project.) But there were other ways of getting the same effect. Frankly, I think Vint was just infatuated with what a neat way it was to do sequencing that he didn't want to get rid of it. ;-) Also, in 1976, Vint lost an argument with the UK and French to make TCP an international transport protocol (this was in INWG IFIP WG6) to the CYCLADES TS protocol which was then the direct precursor to TP4. After that sequence vs packet pretty much became the distinguishing feature of TCP over other contenders. The preference for stream is based on the prevalent view of operating system IPC at the time, primarily represented by Multics and also reflected in Tenex. (Many of the people designing the protocols at that time were OS jocks, not comm jocks. In fact, being a comm jock meant "phone" company or at best "data comm", which was distinctly not what we were doing. ;-) At that time, record meant fixed length record and was represented by IBM OS/360 which didn't really have any IPC. (If I remember right, Braden used building an NCP as an excuse to build an IPC system for OS/360. Sorry Bob, didn't mean to let it out that you were an old 360 hacker. ;-) Please don't hold it against him, guys, it didn't really traumatize him too much! But remember, stream vs packet is completely independent of the choice of octet vs packet sequencing, although we probably didn't recognize that at the time. The first is an interface property; the latter a protocol property. One could just as easily have a protocol that had a record-oriented interface and octet sequencing as a stream interface and packet sequencing. Personally, I have gone back and forth on this several times. My natural inclination is to prefer stream with packet sequencing. (Probably, still over-reacting to the association of record with old mainframes!) But if you consider it not so much as RECORD, but transport should maintain the integrity of what it was given, i.e. if the transport user gives you a lump and you break it up to send it, you should deliver the lump as he gave it to you; it shouldn't be the user's problem that YOU had to break it up, I am forced to admit that this form of "record" does make a certain amount of sense. So, I guess, I do not favor records in the sense of fixed, but maintaining the integrity of what you were given. As to the comment, that maintaining record boundaries is a lot of overhead I would disagree. All you need to record boundaries is set a bit in the header of the last packet. > >My conclusions from research with RDP were that record boundaries had >some nice features but some nasty features that generally outweighed the >nice features. > >The nice features were: > > * Your packets could be safely delivered out of order. Not sure what you mean here Craig, are you assuming packet boundaries are record boundaries? TCP packets can be delivered out of order safely, you just can't hand them to the application until you fill all the holes. > > * The segment boundaries sometimes made application parsing of inbound > data easier. Again, it is necessary to keep segment boundaries distinct from the record boundaries. BTW, I hear a lot of people are using the Urgent pointer to mark record boundaries. > > * Segment boundaries made the sequence handling code a lot easier > (one sequence number per packet is nice!). This is the big win. The fact that TCP re-transmissions do not have to be on the same byte boundaries as the original packets makes the re-assembly code *really* complex. (I don't know, but have always suspect that there are alot of TCP implementations out there that DO assume that retransmissions start on the same sequence number as the original message.) What Craig fails to mention is the other benefit is that you consume much less sequence number space. On high speed links, one of the performance limiting factors of TCP is you can run out of sequence number space and have to stop while the other side catches up. 32 bits of packet sequence number space goes a heck of alot further than 32 bits of octet sequence number space. I believe there were some calculations back in the mid-80s that showed that you couldn't keep a satellite channel full with 32 bits of octet space. > >The unfortunate features were: > > * The application had to be much more intimately involved in choosing > segment sizes. A dumb application could easly launch many tinygrams, > or moby-grams that were always fragmented. No, this is a problem of not keeping record and packet boundaries distinct. And not allowing multiple user lumps (Interface packets?) to be put into a single PDU. > > * Retransmission was less efficient -- if you had an adjacent small packet > and large packet lost, you had to send two packets to recover, not one. I can't believe this is a really overwhelming effect. Almost regardless of what "max packet size" you pick this is going to happen for some applications regardless of whether the interface is record or stream. > >There are probably other features/demerits I've forgotten. > Now for the real heresey. There is probably a much better example of packet transport than RDP in TP4. There are a lot of implementations. If I remember there are even some papers that compared performance of the two and found TP4 faster. Basically this is what you would expect since the header size is much smaller once data transfer starts and the reassembly code is simpler. One other property we found last summer was that it could be implemented in far less space than TCP. (We were able to get TP4 in about 10 - 15K of code. I doubt you could get TCP in anything close to that without violating the spec.) Most of the reason was that the structure of the protocol (and primarily the packet orientation) allowed some simplifying assumptions that reduced functionality and code size without violating the protocol. (A good application of "be generous in what you accept and conservative in what you generate.") I looked at TCP and you couldn't make the same assumptions without violating the protocol. If you look at the various performance improvements proposed for TCP implementations by Clark and others. They all fall into two categories: They are either equally applicable to protocols like TP4 or they make TCP more like protocols like TP4. I have to disagree with Craig, if we had to do it again I would do packet over octet sequencing and record over stream at the interface (using the lump definition of record I described above). Oddly enough, all of the TCP applications are record oriented except Telnet and it should be. >Deep down in my stack, there's a plan to take my 1987 RDP code and update >it to modern standards (RTT estimation, large windows, etc) and see how >it runs, just for fun. > I know this is religous subject for a lot of people, so just let me conclude that regardless of how I would do it over, we are pretty much stuck with a stream interface and octet sequencing. So you may as well ignore everything I said and go back to the reasons you thought we did it to begin with they are more likely to convince the newcomers that we knew what we were doing all the time! Take care, John Day >From majordom@ISI.EDU Sat Aug 30 00:43:28 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Sat" "30" "August" "1997" "02:38:23" "-0400" "John Day" "day@bbn.com" nil "20" "Re: stream/packet" "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id AAA20202; Sat, 30 Aug 1997 00:43:27 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 29 Aug 1997 23:47:56 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 29 Aug 1997 23:47:54 -0700 Received: from zafu.bbn.com (ZAFU.BBN.COM [192.1.50.38]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA12279 for ; Fri, 29 Aug 1997 23:47:53 -0700 (PDT) Received: from [128.89.30.21] (ARA21.BBN.COM [128.89.30.21]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id CAA17586; Sat, 30 Aug 1997 02:48:20 -0400 (EDT) Message-Id: In-Reply-To: <34043E45.5F5F080F@tipper.oit.unc.edu> References: <199708262344.TAA05311@utopia> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk From: John Day Sender: owner-end2end-interest@ISI.EDU To: Simon Spero , "Ray I. McFarland Jr." Cc: Mohan.Parthasarathy@eng.sun.com, end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Sat, 30 Aug 1997 02:38:23 -0400 At 10:48 -0400 08/27/97, Simon Spero wrote: >Ray I. McFarland Jr. wrote: > >> [For 'histerical' examples, ask anyone from the old TCP Committee >> about how the >> "TCP Pseudo-header" came to be; or the infamous "rubber EOL" story!!! >> (You'll have to read the original paper, or the early Internet >> research >> notes, to find out what an EOL was :-) Oh the tales that could be >> told! ;-)] > >Is this the Rubber Baby Buffer Bumpers incident? > >Simon // anyway, if you want packets, just stick in a mini session >layer... > Packet or not to packet has nothing to do with a Session Layer. In fact, there is no such thing as a Session Layer. >From majordom@ISI.EDU Sat Aug 30 23:43:26 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Sat" "30" "August" "1997" "22:46:05" "-0700" "Michael Greenwald" "michaelg@dsg.stanford.edu" nil "49" "Re: stream/packet " "^From:" nil nil "8" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id XAA20765; Sat, 30 Aug 1997 23:43:25 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Sat, 30 Aug 1997 22:48:10 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Sat, 30 Aug 1997 22:48:08 -0700 Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.10]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id WAA03240 for ; Sat, 30 Aug 1997 22:48:08 -0700 (PDT) Received: from DSG.Stanford.EDU (Knife.DSG.Stanford.EDU [171.64.79.87]) by Pescadero.DSG.Stanford.EDU (8.7.4/8.6.9) with ESMTP id WAA25247; Sat, 30 Aug 1997 22:46:06 -0700 Message-Id: <199708310546.WAA25247@Pescadero.DSG.Stanford.EDU> In-Reply-To: Your message of "Sat, 30 Aug 1997 02:36:31 EDT." Precedence: bulk From: Michael Greenwald Sender: owner-end2end-interest@ISI.EDU To: John Day Cc: Craig Partridge , Mohan Parthasarathy , end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Sat, 30 Aug 1997 22:46:05 -0700 Date: Sat, 30 Aug 1997 02:36:31 -0400 From: John Day The preference for stream is based on the prevalent view of operating system IPC at the time, primarily represented by Multics I might be misunderstanding your point, but how was Multics IPC primarily stream oriented? (Actually, I should probably ask the simpler question: "What do you mean by Multics IPC?" and then I can probably figure out what you meant by "stream"). As to the comment, that maintaining record boundaries is a lot of overhead I would disagree. All you need to record boundaries is set a bit in the header of the last packet. You need to preserve *all* these bits. That's the bug with using EOL or Urgent in TCP to record packet boundaries --- you only get the last boundary. > > * Your packets could be safely delivered out of order. Not sure what you mean here Craig, are you assuming packet boundaries are record boundaries? I assume he was referring to end2end, e.g. the Application Level Framing paper by Clark and Tennenhouse (SIGCOMM somewhere between 90-93). What Craig fails to mention is the other benefit is that you consume much less sequence number space. On high speed links, one of the performance limiting factors of TCP is you can run out of sequence number space ... That's why there's a window scaling option now. Now for the real heresey. There is probably a much better example of packet transport than RDP in TP4. Also, what about XNS (I'm at home on a slow-link so can't look this up): didn't it have a record-oriented reliable (stream?) protocol (Was it called Courier? Or am I mixing up names here?)? One other property we found last summer was that it could be implemented in far less space than TCP. (We were able to get TP4 in about 10 - 15K of code. I doubt you could get TCP in anything close to that without violating the spec.) I believe that Dave Clark's implementation of TCP for the Alto (circa 1980) was smaller than that. If I'm misremembering I hope someone corrects me. >From majordom@ISI.EDU Tue Sep 2 09:43:36 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Tue" " 2" "September" "1997" "09:29:55" "-0700" "Craig Partridge" "craig@aland.bbn.com" nil "54" "Re: stream/packet " "^From:" nil nil "9" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id JAA17880; Tue, 2 Sep 1997 09:43:35 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 09:33:27 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 09:33:26 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA16131 for ; Tue, 2 Sep 1997 09:33:25 -0700 (PDT) Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id JAA18173; Tue, 2 Sep 1997 09:29:56 -0700 (PDT) Message-Id: <199709021629.JAA18173@aland.bbn.com> In-Reply-To: Your message of Sat, 30 Aug 97 02:36:31 -0400. Precedence: bulk From: Craig Partridge Sender: owner-end2end-interest@ISI.EDU To: John Day Cc: end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Tue, 02 Sep 97 09:29:55 -0700 > * Your packets could be safely delivered out of order. Not sure what you mean here Craig, are you assuming packet boundaries are record boundaries? TCP packets can be delivered out of order safely, you just can't hand them to the application until you fill all the holes. That's the point -- in RDP you could hand them up to the application (assuming the application said it was willing to take stuff out of order). It reduced the impact of losses, because rather than waiting for the missing piece and then handing the application a window's worth of data all at once, the application could work on what it had received. > > * Segment boundaries made the sequence handling code a lot easier > (one sequence number per packet is nice!). This is the big win. The fact that TCP re-transmissions do not have to be on the same byte boundaries as the original packets makes the re-assembly code *really* complex. (I don't know, but have always suspect that there are alot of TCP implementations out there that DO assume that retransmissions start on the same sequence number as the original message.) What Craig fails to mention is the other benefit is that you consume much less sequence number space. That's because when I sat down and did the comparison, the difference was small enough not to fuss about. It gives you a factor of 10 or so (given that at high speed TCP consumes its data space at the rate of about 1024 bytes per segment). So RDP with a 32-bit sequence space needs the same fixes that TCP got. On high speed links, one of the performance limiting factors of TCP is you can run out of sequence number space and have to stop while the other side catches up. 32 bits of packet sequence number space goes a heck of alot further than 32 bits of octet sequence number space. I believe there were some calculations back in the mid-80s that showed that you couldn't keep a satellite channel full with 32 bits of octet space. >The unfortunate features were: > > * The application had to be much more intimately involved in choosing > segment sizes. A dumb application could easly launch many tinygrams, > or moby-grams that were always fragmented. No, this is a problem of not keeping record and packet boundaries distinct. And not allowing multiple user lumps (Interface packets?) to be put into a single PDU. You're right -- but the question is where's the complexity of tracking multiple records in a segment pay off vs. where does it hurt? Craig >From majordom@ISI.EDU Tue Sep 2 15:57:57 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Tue" " 2" "September" "1997" "18:32:00" "-0400" "Simon Spero" "ses@tipper.oit.unc.edu" nil "19" "Re: stream/packet" "^From:" nil nil "9" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id PAA20629; Tue, 2 Sep 1997 15:57:56 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 15:32:09 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 15:32:08 -0700 Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id PAA05492 for ; Tue, 2 Sep 1997 15:32:07 -0700 (PDT) Received: from mossflower.oit.unc.edu (mossflower.oit.unc.edu [152.2.22.120]) by tipper.oit.unc.edu (8.6.12/8.6.10) with ESMTP id SAA16329; Tue, 2 Sep 1997 18:31:36 -0400 Message-Id: <340C93E0.44F06DE@tipper.oit.unc.edu> X-Mailer: Mozilla 4.01 [en] (Win95; I) Mime-Version: 1.0 X-Priority: 3 (Normal) References: <199708262344.TAA05311@utopia> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk From: Simon Spero Sender: owner-end2end-interest@ISI.EDU To: John Day Cc: "Ray I. McFarland Jr." , Mohan.Parthasarathy@eng.sun.com, end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Tue, 02 Sep 1997 18:32:00 -0400 John Day wrote: > Packet or not to packet has nothing to do with a Session Layer. > > In fact, there is no such thing as a Session Layer. Au Contraire - the purpose of a Session Layer is to do perform those tasks which in should have been performed by the transport layer, but aren't. Simon // beware the Telcotubbies - -- Now available - The Freddy Hayek Kayak | "Pass me another elf Paddle Your Own Canoe! Be Rowed To Surfdom! | Sergeant- this one's >From The Taco Institute for Dyslexic Libertarians | split" >From majordom@ISI.EDU Tue Sep 2 16:55:45 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Tue" " 2" "September" "1997" "16:27:13" "-0700" "touch@isi.edu" "touch@isi.edu" nil "30" "Re: stream/packet" "^From:" nil nil "9" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id QAA01184; Tue, 2 Sep 1997 16:55:45 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 16:27:22 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 16:27:16 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA08400 for ; Tue, 2 Sep 1997 16:27:15 -0700 (PDT) Received: from rum.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 16:27:14 -0700 Posted-Date: Tue, 2 Sep 1997 16:27:13 -0700 Message-Id: <199709022327.QAA12269@rum.isi.edu> Received: by rum.isi.edu (SMI-8.6/4.0.3-6) id ; Tue, 2 Sep 1997 16:27:13 -0700 X-Sun-Charset: US-ASCII X-Auto-Sig-Adder-By: faber@isi.edu Precedence: bulk From: touch@ISI.EDU Sender: owner-end2end-interest@ISI.EDU To: day@bbn.com, ses@tipper.oit.unc.edu Cc: rimcfar@afterlife.ncsc.mil, Mohan.Parthasarathy@eng.sun.com, end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Tue, 2 Sep 1997 16:27:13 -0700 > From majordom@ISI.EDU Tue Sep 2 15:54:18 1997 > Date: Tue, 02 Sep 1997 18:32:00 -0400 > From: Simon Spero > To: John Day > Cc: "Ray I. McFarland Jr." , > Mohan.Parthasarathy@eng.sun.com, end2end-interest@ISI.EDU > Subject: Re: stream/packet > > John Day wrote: > > > Packet or not to packet has nothing to do with a Session Layer. > > > > In fact, there is no such thing as a Session Layer. > > Au Contraire - the purpose of a Session Layer is to do perform those > tasks which in should have been performed by the transport layer, but > aren't. Simon, By extension, then transport performs tasks that should have been done by the link layer? The end-to-enders (of e2e argument) might not agree... :-) Joe - ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ >From majordom@ISI.EDU Tue Sep 2 18:17:14 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Tue" " 2" "September" "1997" "20:56:28" "-0400" "Simon Spero" "ses@tipper.oit.unc.edu" nil "44" "Re: stream/packet" "^From:" nil nil "9" nil nil nil nil] nil) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id SAA11344; Tue, 2 Sep 1997 18:17:13 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 17:55:15 -0700 Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Tue, 2 Sep 1997 17:55:13 -0700 Received: from akbash.oit.unc.edu (akbash.oit.unc.edu [152.2.22.11]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA13492; Tue, 2 Sep 1997 17:55:12 -0700 (PDT) Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by akbash.oit.unc.edu (8.8.5/8.8.5) with SMTP id UAA02062; Tue, 2 Sep 1997 20:55:07 -0400 (EDT) In-Reply-To: <199709022327.QAA12269@rum.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk From: Simon Spero Sender: owner-end2end-interest@ISI.EDU To: touch@ISI.EDU Cc: day@bbn.com, rimcfar@afterlife.ncsc.mil, Mohan.Parthasarathy@eng.sun.com, end2end-interest@ISI.EDU Subject: Re: stream/packet Date: Tue, 2 Sep 1997 20:56:28 -0400 (EDT) On Tue, 2 Sep 1997 touch@ISI.EDU wrote: > > Au Contraire - the purpose of a Session Layer is to do perform those > > tasks which in should have been performed by the transport layer, but > > aren't. > > By extension, then transport performs tasks that should have been done > by the link layer? "ATM - It's not just a link layer, it's an... er... umm... actually it is just a link layer - sorry about that." The session layer in OSI was really there just to provide graceful release, which is the transport layer's job. Session layers over TCP are useful when you need for message boundaries and lightweight connections (i.e. connections which fate share and can state share congestion windows, and send/receive buffers). However, this functionality is better placed in the transport layer with T/TCP and shared TCBs. Session layer is the Spackle of end-to-end networking. Simon // beware the Telcotubbies p.s. I had an interesting thought the other day whilst lying in the bath reading an article about one of those big class-action lawsuits. Since it is a blatantly negligent to release a product which sends data without using a congestion control mechanism, would be possible to bring the class-action lawsuits against those companies producing streaming media with no congestion back off? A few multi-million dollar judgments could be even more effective than RED... I wonder if I should send this onto Cyberia. - ----- Now available - The Freddy Hayek Kayak | "Pass me another elf Paddle Your Own Canoe! Be Rowed To Surfdom! | Sergeant- this one's >From The Taco Institute for Dyslexic Libertarians | split" ------- end -------