Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id KAA21565 for tcplw-list@sdiv; Tue, 6 Feb 1996 10:32:40 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id KAA21560 for ; Tue, 6 Feb 1996 10:32:38 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id KAA16700 for ; Tue, 6 Feb 1996 10:32:38 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id KAA12316 for ; Tue, 6 Feb 1996 10:32:11 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA23730 for tcplw@cray.com; Tue, 6 Feb 1996 14:22:19 +0100 From: Luigi Rizzo Message-Id: <199602061322.OAA23730@labinfo.iet.unipi.it> Subject: Conservative behaviours To: tcplw@cray.com Date: Tue, 6 Feb 1996 14:22:19 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2402 Many comments on my previous messages (thanks to those who responded, BTW) insist on the need of being conservative in the estimation of RTTs (and in general, in the generation of traffic, which is the ultimate reason for being conservative). I completely agree, and actually I would like to have a more strict control on this. It is the sender which might constitute a danger for the network, so we should force this one, not the receiver, to have a strictly controlled and conservative behaviour. The other party should only have the minimum possible trust. In the case of RTT estimates: we trust the other party for not acknowledging data which have not been received yet, so we know that the RTT measure reflects at least the propagation delays plus the effect of queueing at intermediate nodes. But how do we know what is their ack generation policy ? Some might send immediate ACKs, e.g. in the case of short packets, or when there are pending data in the other direction. Some might implement RFC122 and ack every other segment, so the RTT is the propagation delay plus the interarrival time. Some might use delayed ack, so the RTT might be up to .5 sec larger than the real one. Etcetera. We cannot prohibit any of the above behaviours, they are all legal and in many cases there are good reasons to use them. And we cannot tell which one is being used. The conclusion is that even if we ask the other party to have a conservative behaviour, then we cannot trust it and we have to apply additional safety factors. This leads to a general lack of clarity of the mechanisms, some loss of control on the actual safety factors that are being used, and possibly leads to exceedingly large estimates. In my opinion, it would be cleaner (and possibly easier and more efficient) to just ask the receiver to help us in determining the real propagation delay. Don't ask it to be conservative, as we cannot trust it anyways. Conservative behaviour can (and must) be enforced by the sender. Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA07325 for tcplw-list@sdiv; Tue, 6 Feb 1996 09:36:08 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA07316 for ; Tue, 6 Feb 1996 09:36:06 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id JAA14008 for ; Tue, 6 Feb 1996 09:36:06 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA02398 for ; Tue, 6 Feb 1996 09:29:03 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA23739 for tcplw@cray.com; Tue, 6 Feb 1996 14:31:23 +0100 From: Luigi Rizzo Message-Id: <199602061331.OAA23739@labinfo.iet.unipi.it> Subject: Re: Thoughts about RFC1323 timestamps To: tcplw@cray.com Date: Tue, 6 Feb 1996 14:31:23 +0100 (MET) In-Reply-To: <9602052038.AA27934@poplar029> from "David Borman" at Feb 5, 96 02:38:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2770 Thanks to the people who sent comments on the message and allowed me to find a mistake in my proposal. Following suggestions from David Borman and Matt Mathis, I have changed slightly my proposal on which timestamp to echo: now it should read as follows: keep rule #1 (don't update TSrecent with out-of-sequence segments) and #2 (don't use dup acks for RTT estimates) but use the timestamp echo reply field in dup acks to carry the timestamp of the last received segment, if this is more recent than ts_recent. What was wrong in my original email was the word "_always_" instead of "in dup acks" here. In BSD 4.4, it can be implemented by the following code tcp_out(struct tcpcb *tp, struct tcpopt* to) { u_long tmp=tp->ts_recent; if ((to->to_flag & TOF_TS) && !(tp->t_flags & TF_DELACK) && TSTMP_LT(tmp, to->to_tsval)) tp->ts_recent=to->to_tsval; (void) tcp_output(tp); tp->ts_recent=tmp; } and by replacing calls to tcp_output(tp) with tcp_out(tp, &to) from within tcp_input(). [Actually, some calls to tcp_output() can remain untouched because you know that the test would fail.] The only scenario where my code produces different RTT measurements from the current one is when: * incoming packets are lost or reordered, and * the last valid ack (say for packet #1) gets lost or reordered; As an example: incoming packets: #0 #1 #3 #2 ACK/TSecr, current code #0,TS#0 #1,TS#1 #1,TS#1 #3,TS#2 ACK/TSecr, new code #0,TS#0 #1,TS#1 #1,TS#3 #3,TS#2 (lost) ^^^^ The sender interprets the dup ack for #3 as a non dup ack, and uses the timestamp to update the RTT estimate. With the new code, the TSecr contains TS#3 instead of TS#1. To me, this seems acceptable because: * it is only triggered by the combination of two hopefully unlikely events; * the new sample for the RTT that comes out is not shorter than the real round trip time for the segment, so it is not an underestimate of the RTT, just a value which is close to the real one; * a shorter-than-usual sample does not necessarily reduce the RTO, because it might increase RTTVAR which has a large weight in the computation of the RTO; * current practice already considers dup acks to carry unreliable (exceedingly large) TSecr, and discards them. Does this look reasonable now ? Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id DAA26349 for tcplw-list@sdiv; Tue, 6 Feb 1996 03:28:11 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id DAA26339 for ; Tue, 6 Feb 1996 03:28:10 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id DAA00749 for ; Tue, 6 Feb 1996 03:28:10 -0600 Received: from pepper.cs.ucdavis.edu (pepper.cs.ucdavis.edu [128.120.56.123]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id DAA21717 for ; Tue, 6 Feb 1996 03:28:09 -0600 Received: by pepper.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA18518; Tue, 6 Feb 96 01:19:00 PST Date: Tue, 6 Feb 96 01:19:00 PST From: infocom@cs.ucdavis.edu (Biswanath Mukherjee) Message-Id: <9602060919.AA18518@pepper.cs.ucdavis.edu> To: infocom@cs.ucdavis.edu Subject: Infocom96 Conference Program (We apologize if you are receiving multiple copies of this message since our mailing list is constructed from multiple different sources.) ========================================================================= Announcing... IEEE Infocom '96 ---- Networking the Next Generation ==================================================== Information about Infocom96, the Fifteenth Annual Joint Conference of the IEEE Computer and Communications Societies, is now available through the World Wide Web at http://www.research.att.com/~hgs/infocom96 Here are a few highlights: * Abstracts of all 176 accepted papers are now available on the web. * Conference Location: HOTEL NIKKO. SAN FRANCISCO, California, USA * Conference Dates: Tutorials: March 24-25, 1996 Conference: March 26-28, 1996 * Early (Discounted) Registration Deadline: February 23, 1996. * 44 Technical Sessions (in 4 parallel tracks), where 176 papers will be presented on the most recent advances in all aspects of networking, including multimedia, wireless, optical, multicasting, ATM, network management, queueing networks, network security, and system software. * Six tutorials by leading experts on the following topics: -- Wireless Communication Networks by Don Cox, Stanford University -- Image and Video Compression by Avideh Zakhor, UC Berkeley -- Optical Networking by Rajiv Ramaswami, IBM -- High-Speed Networks: From Ethernet to ATM by Pravin Varaiya, UC Berkeley -- Broadband Networking: Models and Techniques for Control, Design and Management by Debasis Mitra, AT&T Bell Laboratories -- Multimedia Conferencing over the Internet by Van Jacobson, LBL * Six panels on the challenges and promises of future networks: -- Wireless Multimedia Networks: Issues, Challenges and Directions -- Inter-operability in Multi-vendor ATM Networks -- How Much Synchronization is Needed for Multimedia Communication? -- Can High-Speed Wide-Area Networks be Effectively Controlled? -- Simulation Modeling of High Speed Networks: State of the Art and Challenges -- The Economics of the Internet * Keynote Speaker: Arno Penzias, AT&T Bell Laboratories * Plenary Session--Hamid Ahmadi, IBM, "Wireless and Mobile Networking - the Enterprise Perspective" * Hard copies of the Advance Program have been mailed to all IEEE Computer and Communications Society Members, as well as to all corresponding authors of Infocom96 submissions. For further information, please write to "infocom@cs.ucdavis.edu". Biswanath Mukherjee Technical Program Chair, IEEE INFOCOM '96 University of California Department of Computer Science Davis, California 95616, USA Email: infocom@cs.ucdavis.edu (for all correspondence re: Infocom '96) Telephone: +1-916-752-4826 Fax: +1-916-752-4767 Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id OAA05619 for tcplw-list@sdiv; Mon, 5 Feb 1996 14:38:37 -0600 Received: from poplar029 (dab@poplar029 [128.162.139.29]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with SMTP id OAA05613; Mon, 5 Feb 1996 14:38:35 -0600 From: David Borman Received: by poplar029 (5.x/btd-b3) id AA27934; Mon, 5 Feb 1996 14:38:33 -0600 Message-Id: <9602052038.AA27934@poplar029> Date: Mon, 5 Feb 1996 14:38:33 -0600 To: luigi@labinfo.iet.unipi.it Subject: Re: Thoughts about RFC1323 timestamps Cc: mathis@zippy.psc.edu, tcplw@cray.com > From: Luigi Rizzo > Subject: Re: Thoughts about RFC1323 timestamps > Date: Mon, 5 Feb 1996 19:20:50 +0100 (MET) > > > The problem is that you don't know whether the out-of-sequence segment > > is due to a lost packet, or just packet reordering. If you receive > > packet #1 and delay the ack, and then get #3 & #2, you want the TSecr > > in the dup-ack sent in response to #3 arriving out of order to be the TS > > from #1, and then when you get #2, you want the TSecr to be from #2, > > even though it acks #2-#3. With your change, the ack in response to > > Exactly what I meant to do. I am sure I did not explain it clearly, but > the following should work: ... Ok, it's a bad example. Let me fix that. On an idle connection, two packets are received out of sequence, #2, #1. When the ack is sent for #2, currently TSrecent is not updated, it stays at TS#0 (the previous packet). Then when #1 is acked, TSrecent is updated with TS#1, and when the other side computes the RTT it includes the reordering of the packets. With your change, when #2 arrives on the quiet connection, TSrecent is updated with TS#2 and sent in the ack. Then when #1 arrives, its TSecr is older than TSrecent, so the ack for #1-#2 that gets sent has TSecr#2, not TSecr#1, and the RTT estimate does *not* include the reordering of the packets. Look at the example in RFC1323, pages 16-17. This is the one that your proposed change breaks. I just can't agree with something when it is so easy to come up with a scenario where it produces the wrong RTT measurement. -David Borman, dab@cray.com Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id MAA11482 for tcplw-list@sdiv; Mon, 5 Feb 1996 12:20:59 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id MAA11474; Mon, 5 Feb 1996 12:20:57 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id MAA01207; Mon, 5 Feb 1996 12:20:56 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id MAA05635; Mon, 5 Feb 1996 12:20:28 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA21650; Mon, 5 Feb 1996 19:20:51 +0100 From: Luigi Rizzo Message-Id: <199602051820.TAA21650@labinfo.iet.unipi.it> Subject: Re: Thoughts about RFC1323 timestamps To: dab@cray.com (David Borman) Date: Mon, 5 Feb 1996 19:20:50 +0100 (MET) Cc: mathis@zippy.psc.edu, tcplw@cray.com In-Reply-To: <9602051717.AA27700@poplar029> from "David Borman" at Feb 5, 96 11:17:01 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3403 > The problem is that you don't know whether the out-of-sequence segment > is due to a lost packet, or just packet reordering. If you receive > packet #1 and delay the ack, and then get #3 & #2, you want the TSecr > in the dup-ack sent in response to #3 arriving out of order to be the TS > from #1, and then when you get #2, you want the TSecr to be from #2, > even though it acks #2-#3. With your change, the ack in response to Exactly what I meant to do. I am sure I did not explain it clearly, but the following should work: When you get #3, even if it is out-of-sequence, there is a DELACK pending: so you know that you are not sending a dup ack, and use the timestamp from #1 (in TSrecent). TSrecent is not changed because #3 is not in sequence. When you get #2, it advances the ack pointer, so you also advance TSrecent, and use this as the TSecr. > #3 would have the TS from #3, and the ack in response to #2 would have > the TS from #3. In this scenario, the computed RTT from both ACKs > will be underestimated. see above. > > One can object that the last valid ack is lost, and one subsequent > > dup ack is not recognized as a dup thus causing the RTT to be > > updated. > > The whole point of doing RTT measurement is to have an accurate > RTT value so you can avoid spurious retransmissions. With that > in mind, if there is the possibility of error, it is better to > err on the side of a value that is too large than a value that > is too small. agreed. But note that a smaller RTT does not necessarily mean a smaller RTO: the smaller RTT might actually cause an increase in RTTVAR, and since RTO = SRTT + 4RTTVAR, this might even be more conservative than current code. > > But as shown in Braden's message of April 93, the RTT > > derived from these dups can have very large errors, and this is > > the reason why he recommends not to use them to update the RTT. > > In examples where the last valid ack is lost, the subsequent > dup ack will not be wildly inaccurate, just slightly inflated. > The cases of very large errors have to do with packets arriving > after the connection has been idle for some period of time. In general, if T is the interval between subsequent segments, delayed acks are delayed by DT=min(T, tcp_fasttimo). Subsequent dup acks just reflect the time since the last in-sequence segment, plus, possibly, a DT. The nth dup ack has an error of about nT+DT. Which one you get depends on how many segments have been lost, etc. Now, I believe that the error (and its sign) will be irrelevant until it is comparable with the actual RTT, the granularity of timers, and the minimum RTO (2 seconds now). It might become important as these values becomes much smaller, but my feeling is that the minimum RTO will always be forced to be much larger than any reasonable error in the estimate of RTT for sufficiently fast networks. For slow networks, where you get less than a few packets per second, the overestimate might really become too large. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id LAA22737 for tcplw-list@sdiv; Mon, 5 Feb 1996 11:17:24 -0600 Received: from poplar029 (dab@poplar029 [128.162.139.29]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with SMTP id LAA22726; Mon, 5 Feb 1996 11:17:22 -0600 From: David Borman Received: by poplar029 (5.x/btd-b3) id AA27700; Mon, 5 Feb 1996 11:17:20 -0600 Message-Id: <9602051717.AA27700@poplar029> Date: Mon, 5 Feb 1996 11:17:20 -0600 To: luigi@labinfo.iet.unipi.it Subject: Re: Thoughts about RFC1323 timestamps Cc: mathis@zippy.psc.edu, tcplw@cray.com > From tcplw-relay@cray.com Sun Feb 4 17:04 CST 1996 > From: Luigi Rizzo > Subject: Re: Thoughts about RFC1323 timestamps > To: mathis@zippy.psc.edu (Matt Mathis) > Date: Sun, 4 Feb 1996 23:56:51 +0100 (MET) > Cc: tcplw@cray.com, mathis@zippy.psc.edu > X-Mailer: ELM [version 2.4 PL23] > Content-Length: 1836 > > > You are forgetting the most important constraint on the timers. It is > > absolutely critical that the timers are sufficiently conservative where the > > probability of of spurious retransmissions is infinitesimal. Otherwise there > > Probably I was not completely clear: I did not mean to modify the > TSecr sent for in-sequence segments, but only the value for > out-of-sequence segments which cause dup acks to be sent immediately. > The RFC specifies that these values should not be used to update > the RTT estimates (and personally I have no interest in this, > although note that after a lost segment you might have a long period > of time where you cannot update the RTT). The problem is that you don't know whether the out-of-sequence segment is due to a lost packet, or just packet reordering. If you receive packet #1 and delay the ack, and then get #3 & #2, you want the TSecr in the dup-ack sent in response to #3 arriving out of order to be the TS from #1, and then when you get #2, you want the TSecr to be from #2, even though it acks #2-#3. With your change, the ack in response to #3 would have the TS from #3, and the ack in response to #2 would have the TS from #3. In this scenario, the computed RTT from both ACKs will be underestimated. > One can object that the last valid ack is lost, and one subsequent > dup ack is not recognized as a dup thus causing the RTT to be > updated. The whole point of doing RTT measurement is to have an accurate RTT value so you can avoid spurious retransmissions. With that in mind, if there is the possibility of error, it is better to err on the side of a value that is too large than a value that is too small. > But as shown in Braden's message of April 93, the RTT > derived from these dups can have very large errors, and this is > the reason why he recommends not to use them to update the RTT. In examples where the last valid ack is lost, the subsequent dup ack will not be wildly inaccurate, just slightly inflated. The cases of very large errors have to do with packets arriving after the connection has been idle for some period of time. -David Borman, dab@cray.com Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id QAA24727 for tcplw-list@sdiv; Sun, 4 Feb 1996 16:57:47 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id QAA24723 for ; Sun, 4 Feb 1996 16:57:46 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id QAA27950 for ; Sun, 4 Feb 1996 16:57:46 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id QAA20137 for ; Sun, 4 Feb 1996 16:57:44 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA19392; Sun, 4 Feb 1996 23:56:51 +0100 From: Luigi Rizzo Message-Id: <199602042256.XAA19392@labinfo.iet.unipi.it> Subject: Re: Thoughts about RFC1323 timestamps To: mathis@zippy.psc.edu (Matt Mathis) Date: Sun, 4 Feb 1996 23:56:51 +0100 (MET) Cc: tcplw@cray.com, mathis@zippy.psc.edu In-Reply-To: <9602041626.AA29989@mailer.psc.edu> from "Matt Mathis" at Feb 4, 96 11:26:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1836 > You are forgetting the most important constraint on the timers. It is > absolutely critical that the timers are sufficiently conservative where the > probability of of spurious retransmissions is infinitesimal. Otherwise there Probably I was not completely clear: I did not mean to modify the TSecr sent for in-sequence segments, but only the value for out-of-sequence segments which cause dup acks to be sent immediately. The RFC specifies that these values should not be used to update the RTT estimates (and personally I have no interest in this, although note that after a lost segment you might have a long period of time where you cannot update the RTT). One can object that the last valid ack is lost, and one subsequent dup ack is not recognized as a dup thus causing the RTT to be updated. But as shown in Braden's message of April 93, the RTT derived from these dups can have very large errors, and this is the reason why he recommends not to use them to update the RTT. Current code is more conservative than what I propose, but it is also less representative of the actual RTT. Moreover, one must weight the difference with the effects of smoothed means, the frequency of such events (hopefully low) and, especially, the unavoidable roundings in the computation which give a minimum retransmit time which is usually quite large. I cannot imagine that my proposal could increase spurios retransmissions significantly. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id KAA10364 for tcplw-list@sdiv; Sun, 4 Feb 1996 10:27:12 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id KAA10359 for ; Sun, 4 Feb 1996 10:27:11 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id KAA22290 for ; Sun, 4 Feb 1996 10:27:10 -0600 Received: from mailer.psc.edu (mailer.psc.edu [128.182.62.100]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id KAA09923 for ; Sun, 4 Feb 1996 10:27:01 -0600 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA29989; Sun, 4 Feb 1996 11:26:29 -0500 Message-Id: <9602041626.AA29989@mailer.psc.edu> To: Luigi Rizzo Cc: tcplw@cray.com, mathis@zippy.psc.edu Subject: Re: Thoughts about RFC1323 timestamps In-Reply-To: Your message of "Sun, 04 Feb 1996 10:14:25 +0100." <199602040914.KAA18702@labinfo.iet.unipi.it> Date: Sun, 04 Feb 1996 11:26:29 -0500 From: "Matt Mathis" You are forgetting the most important constraint on the timers. It is absolutely critical that the timers are sufficiently conservative where the probability of of spurious retransmissions is infinitesimal. Otherwise there is a danger of massive wasted BW, due to timers triggering needless retransmissions. This was part of the congestive collapse that clobbered the entire Internet in 1987-1988 and lead Van Jacobson to explore congestion issues in his landmark paper. The problem is that the receivers delayed ACK algorithm MUST never trigger the senders retransmit timer. Thus when the receiver is doing delayed ACK, the receiver must use the timestamp from the OLDEST ``omitted'' ACK, such that the senders RTT estimate includes the receiver's delayed ACK timer. (BTW, this wording suggests a simpler algorithm than specified by the RFC.) But note that even this is not good enough. Here is a pathological situation that we have been mulling over. Consider the following topology where "-" is an ethernet and "=" is T3. The letters refer to ``hubs'' which include routers, fast metropolitan connectivity and hosts. The hub detail is not shown: H1----H2====H3==========WC=============EC============EU 1ms 1ms 40mS 30ms 30ms (one way delay) (this is 3 sites in Hawaii, and a path across the US to Europe) Assume that there is a TCP connection ``A'' carrying traffic from a host at H1 to a host at H3, which is not bottlenecked by the network. e.g. it is limited by a disk drive, etc. Also that it is using the existing timer algorithm but with 1mS granularity. I believe that this means that it's retransmit timer (mean+4 dev) would be at most about 50 mS. Also assume that the queues at all hubs are correctly provisioned for the 200 mS worst case roundtrip time. Now suppose a new, network limited connection ``B'' starts between H2 and EU. At the end of its slowstart it will create a 200mS queue on the link from H2 to H3. This queue will cause the RTT for connection ``A'' to change from 4 mS to 204mS. Since connection A's retransmit timer is 50 mS, it will do at least two spurious retransmissions. Not a serious in this case, but suppose you replace connection ``A'' with 500 telnets..... This is not easy to fix because the essential problem is that the small connections have no way to observe the huge nominally unused queue at H2 until some other connection fills it. I believe that the only ``fix'' is to mandate a floor on the retransmit timer - say 1 second. (1 second is a small integer times the correct queue time for the vast majority of todays Internet. This would allow H2 to have internal hops.) Note that this eliminates the usefulness using accurate RTTM to implement the retransmit timer. Note that the old code, with 500mS ticks and RTT rounding effectively had a floor of 2 seconds. --MM-- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id DAA12441 for tcplw-list@sdiv; Sun, 4 Feb 1996 03:14:41 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id DAA12437 for ; Sun, 4 Feb 1996 03:14:40 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id DAA17417 for ; Sun, 4 Feb 1996 03:14:39 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id DAA26689 for ; Sun, 4 Feb 1996 03:14:29 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA18702 for tcplw@cray.com; Sun, 4 Feb 1996 10:14:26 +0100 From: Luigi Rizzo Message-Id: <199602040914.KAA18702@labinfo.iet.unipi.it> Subject: Thoughts about RFC1323 timestamps To: tcplw@cray.com Date: Sun, 4 Feb 1996 10:14:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2408 I was recently thinking about TCP timestamps. RFC1323, and, especially, subsequents updates by R.Braden [1] specify that: #1 (2) If: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. (TS.Recent is the value sent as the timestamp echo reply in the next ack. It is also used to discard old segments. In BSD4.4 it is the ts_recent field in the tcpcb). Also: #2 "A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window." (this rule is necessary to avoid possibly large errors on the estimate of the RTT when segments are lost, see [1]). As a consequence, the timestamp echo reply value (TSecr) in acks to out-of-sequence segments is completely ignored. I'd like to keep rule #1 and #2, but use the timestamp echo reply field to carry _always_ the timestamp of the last received segment, if this is more recent than ts_recent. For in-sequence segments, this is exactly what already happens; for out-of-sequence segments, rule #2 specifies that the field should be ignored so it should not matter what is really sent. Note that the value to put in TSecr is readily available from the incoming segment, and does not need to be stored in the tcp control block as it is going out in an immediate ACK. The change I suggest has two advantages: the sender has a more accurate value for the RTT, which can possibly be used to update the estimates (thus overriding rule #2; but I have not investigated on this). Also, the sender can use this info to determine which segments have been received at the remote side. Anything wrong in my reasoning ? I have been running a FreeBSD kernel with this modification for a few days and have not seen difficulties in TCP connections with other systems. Luigi [1] R.Braden, email message to the tcplw mailing list, april 1993 ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA26810 for tcplw-list@sdiv; Fri, 26 Jan 1996 09:25:46 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA26801 for ; Fri, 26 Jan 1996 09:25:44 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id JAA02089 for ; Fri, 26 Jan 1996 09:25:44 -0600 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id JAA00592 for ; Fri, 26 Jan 1996 09:25:43 -0600 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id ac11461; 26 Jan 96 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@cnri.reston.va.us cc: tcplw@cray.com From: Internet-Drafts@cnri.reston.va.us Reply-to: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-tcplw-sack-00.txt Date: Fri, 26 Jan 96 09:37:13 -0500 Sender: cclark@cnri.reston.va.us Message-ID: <9601260937.ac11461@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Large Windows Working Group of the IETF. Title : TCP Selective Acknowledgement Options Author(s) : M. Mathis, J. Mahdavi, S. Floyd, A. Romanow Filename : draft-ietf-tcplw-sack-00.txt Pages : 9 Date : 01/25/1996 TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgements, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received. A Selective Acknowledgement (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments. This draft proposes an implementation of SACK and discusses its performance and related issues. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcplw-sack-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-tcplw-sack-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-tcplw-sack-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960125142334.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-tcplw-sack-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcplw-sack-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960125142334.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id KAA05902 for tcplw-list@sdiv; Thu, 25 Jan 1996 10:26:07 -0600 Received: from poplar029 (dab@poplar029 [128.162.139.29]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with SMTP id KAA05897 for ; Thu, 25 Jan 1996 10:26:06 -0600 From: David Borman Received: by poplar029 (5.x/btd-b3) id AA12500; Thu, 25 Jan 1996 10:26:01 -0600 Message-Id: <9601251626.AA12500@poplar029> Date: Thu, 25 Jan 1996 10:26:01 -0600 To: tcplw@cray.com Subject: L.A. IETF FYI: A slot for TCPLW has been scheduled for the Los Angeles IETF meeting. At this point, the only agenda item is discussion of the SACK option. -David Borman, dab@cray.com > From mbeaulie@CNRI.Reston.VA.US Wed Jan 24 14:51 CST 1996 > Mime-Version: 1.0 > Date: Wed, 24 Jan 1996 15:47:54 -0500 > To: dab@cray.com > From: Marcia Beaulieu > Subject: LOS ANGELES IETF: TCPLW > Cc: mankin@isi.edu > Content-Length: 154 > > TCPLW has 1 session scheduled as follows: > > Thursday, March 7 - 9:00-11:30am (opposite applmib, http, mobileip) > > Marcia > IETF Meeting Coordinator Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id VAA24755 for tcplw-list@sdiv; Tue, 23 Jan 1996 21:47:42 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id VAA24751 for ; Tue, 23 Jan 1996 21:47:41 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id VAA23328 for ; Tue, 23 Jan 1996 21:47:40 -0600 Received: from mailer.psc.edu (mailer.psc.edu [128.182.62.100]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id VAA29998 for ; Tue, 23 Jan 1996 21:47:39 -0600 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA13092; Tue, 23 Jan 1996 22:47:25 -0500 Message-Id: <9601240347.AA13092@mailer.psc.edu> To: fab@fab.md.interlink.com (Fred Bohle) Cc: tcplw@cray.com Subject: Re: SACK options draft In-Reply-To: Your message of "Tue, 23 Jan 1996 15:45:01 +0500." <9601232045.AA15220@fab.md.interlink.com> Date: Tue, 23 Jan 1996 22:47:24 -0500 From: "Matt Mathis" > I still do not see a description of retransmission based on >processing SACKs. There was much discussion on the list, and in the >papers referred to, but none is in your draft. Nor will you find any description of any retransmission strategy in any IETF standards documents. "Reno", "Tahoe" and their supporting algorithms are only documented in research papers, public presentations, the code itself, and recently in books. There are a number of reasons for this, which I don't fully appreciate myself. For one thing the research community has never been convinced that the problems are "solved". Each new vintage of TCP is just one notch better than prior vintages. Furthermore, once the tradition is established, it becomes very difficult to escape. To formally specify SACK retransmission requires formal specifications of the constituent algorithms: congestion avoidance, congestion control, slow-start, fast recovery, fast retransmit, delayed ACK, tcprexmtthresh, etc. They don't exist as standards, and if we tried to cast them into standards language, we would find all sorts of quibbles with details. There is also the problem of specifying a "standard behavior" without specifying a "standard implementation". I am not a lawyer, but I understand that over specifying standards in immaterial ways leads to big legal problems with procurement contracts and anti-trust law. There is actually huge latitude in how a "correct" sender might behave. Many different behaviors are be consistent with the I-D, current congestion control practices, and would be equally safe in the Internet. I am comfortable with the data receiver behavior as specified in the draft and that it is "easy" to construct a reasonable data sender. I expect that we will still be discovering nuances to implementing an optimal sender for several years to come. We (Jamshid and I) have a paper in draft that explores some of the issues. --MM-- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id SAA13605 for tcplw-list@sdiv; Tue, 23 Jan 1996 18:47:56 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id SAA13596 for ; Tue, 23 Jan 1996 18:47:54 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id SAA17664 for ; Tue, 23 Jan 1996 18:47:54 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id SAA11034 for ; Tue, 23 Jan 1996 18:47:51 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id BAA08632; Wed, 24 Jan 1996 01:45:12 +0100 From: Luigi Rizzo Message-Id: <199601240045.BAA08632@labinfo.iet.unipi.it> Subject: Re: SACK options draft To: floyd@ee.lbl.gov (Sally Floyd) Date: Wed, 24 Jan 1996 01:45:12 +0100 (MET) Cc: fab@fab.md.interlink.com, tcplw@cray.com In-Reply-To: <199601232307.PAA17454@owl.ee.lbl.gov> from "Sally Floyd" at Jan 23, 96 03:07:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3001 Sally Floyd said: > My own position is that the internet draft outlining the SACK option > should not include detailed specifications for the sender's > retransmission policy: > > ... I wrote the following before reading Sally's message, but now I am even more convinced: I believe that trying to address too many subjects can only reduce the consensus on the Internet-draft and delay its approval. Probably everybody agrees that SACKs are a useful mechanism, as they know by experience how things work without them. Everybody equally agrees on the basic principles upon which the internet protocols are based: robustness, non-aggressive use of the network, etc. Other subjects, such as how to best exploit SACKs, interaction with the congestion control and retransmission strategies, etc. are less widely accepted, mostly because of lack of direct experience. Also, the draft is not completely convincing on these subjects. [and possibly was not even meant to, see Sally's comment above] I think that we need quickly some agreement on _the format_ of SACK options, so that people can start to implement them and make experience. The proposal in Sec.1-3 looks perfectly reasonable, and I have not seen any opposition to it in the emails to this list. Just address this subject in the Internet draft, and briefly mention the general principles that should be followed by implementations. Other issues can be debated, experimented and agreed upon at a later time. [as a matter of fact, the title of the draft only mentions SACK _options_, not the whole mechanism which also include the retransmission strategy and the congestion control algorithms. It is the abstract which refers to a _mechanism_] This said, a comment on Section 8 (although I think that the draft should only include Sec.1-3 and part of Sec.4): 8. Data Receiver Reneging "* The first SACK block MUST reflect the newest segment. Even if the newest segment is going to be discarded and the receiver has already discarded adjacent segments, the first SACK block MUST report, at a minimum, the left and right edges of the newest segment. The objective should be to make the sender understand that previously SACKed data have been discarded. The behaviour indicated above is at the very least misleading, as it looks to the sender as if the segment had been SACKed. If we don't want a different option to specify this, we should at least say something different, e.g. swap the left and right edges of a block to mean that the specified block is _not_ present at the receiver. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id RAA09022 for tcplw-list@sdiv; Tue, 23 Jan 1996 17:40:32 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id RAA09015 for ; Tue, 23 Jan 1996 17:40:31 -0600 From: braden@isi.edu Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id RAA16141 for ; Tue, 23 Jan 1996 17:40:31 -0600 Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id RAA03125 for ; Tue, 23 Jan 1996 17:40:29 -0600 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 23 Jan 1996 15:40:28 -0800 Date: Tue, 23 Jan 96 15:40:34 PST Posted-Date: Tue, 23 Jan 96 15:40:34 PST Message-Id: <9601232340.AA14469@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-4) id ; Tue, 23 Jan 96 15:40:34 PST To: fab@fab.md.interlink.com, floyd@ee.lbl.gov Subject: Re: SACK options draft Cc: tcplw@cray.com *> *> (4) Before the internet-draft can progress further along the standards *> track, there will have to be reference implementations of SACK, with full *> discussion of the retransmission policies in those implementations. *> Thus, there are plenty of avenues for exploring all of the ramifications *> of retransmission strategies. So, while the issue of retransmission *> policies clearly has to be discussed further, with clear and detailed *> reference implementations illustrating good retransmission strategies, *> it does not seem to me that this must or should be in the internet *> draft that defines the SACK option. *> Sally, Why should we publish a standard for SACK before we can tell people exactly how to use it? Is it wise to do that? Bob Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id RAA03659 for tcplw-list@sdiv; Tue, 23 Jan 1996 17:08:09 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id RAA03655 for ; Tue, 23 Jan 1996 17:08:08 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id RAA15262 for ; Tue, 23 Jan 1996 17:08:07 -0600 Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [128.3.112.35]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id RAA28547 for ; Tue, 23 Jan 1996 17:08:06 -0600 Received: by owl.ee.lbl.gov (8.7.1/1.43r) id PAA17454; Tue, 23 Jan 1996 15:07:42 -0800 (PST) Message-Id: <199601232307.PAA17454@owl.ee.lbl.gov> To: fab@fab.md.interlink.com (Fred Bohle) cc: tcplw@cray.com Subject: Re: SACK options draft Date: Tue, 23 Jan 1996 15:07:41 PST From: Sally Floyd Fred - > I still do not see a description of retransmission based on >processing SACKs. There was much discussion on the list, and in the >papers referred to, but none is in your draft. > > So, someone could do everything mentioned in the draft, and >still do no good for improving thruput. > > The papers "TCP and Successive Fast Retransmits" (Floyd), >and "Comparisons of Tahoe, Reno, and Sack TCP" (Fall, Floyd), do describe problems with SACKs and possible solutions. We should >reach agreement on retransmission strategy and put it in the draft. My own position is that the internet draft outlining the SACK option should not include detailed specifications for the sender's retransmission policy: (1) There are no interoperability requirements; it is not required, for interoperability, that different implementations use the exact same retransmission algorithms. (2) There are requirements that the SACK option not give license for the implementation of congestion control algorithms that damage the rest of the Internet; this is addressed by the very general discussion of the congestion control issues in Section 5.1. (3) There are requirements that the SACK option not introduce deadlocks; this is addressed in the sections dealing with the retransmission response to retransmit timers. (4) Before the internet-draft can progress further along the standards track, there will have to be reference implementations of SACK, with full discussion of the retransmission policies in those implementations. Thus, there are plenty of avenues for exploring all of the ramifications of retransmission strategies. So, while the issue of retransmission policies clearly has to be discussed further, with clear and detailed reference implementations illustrating good retransmission strategies, it does not seem to me that this must or should be in the internet draft that defines the SACK option. (5) Many of the retransmission strategies of current TCP implementations (e.g., Fast Retransmit, Fast Recovery) are addressed only in passing, if at all, in IETF standards documents so far (e.g., RFC 1122, RFC 1323). It would be problematic to attempt to standardize the extension of the Fast Retransmit and Fast Recovery algorithms to selective acknowledgements, when the algorithms themselves have not been standardized for non-SACK TCP. - Sally Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id PAA11630 for tcplw-list@sdiv; Tue, 23 Jan 1996 15:31:45 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id PAA11626 for ; Tue, 23 Jan 1996 15:31:44 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id PAA11511 for ; Tue, 23 Jan 1996 15:31:44 -0600 Received: from mailer.psc.edu (mailer.psc.edu [128.182.62.100]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id PAA29363 for ; Tue, 23 Jan 1996 15:31:42 -0600 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA06421; Tue, 23 Jan 1996 16:31:39 -0500 Message-Id: <9601232131.AA06421@mailer.psc.edu> To: tcplw@cray.com Cc: mathis@zippy.psc.edu Subject: Re: SACK options draft Date: Tue, 23 Jan 1996 16:31:38 -0500 From: "Matt Mathis" I was planing to assemble a short presentation on SACK reneging for the IETF, but I decided to send my comments to the list instead. Before I begin, let me say that I was in the non-advisory camp when I started, but converted along the way. There are two implications to making SACK advisory. First, that the data sender MUST NOT discard data until it is ACKed (by the advancing acknowledgement number in the header). This is a good idea purely from a robustness point of view because it protects TCP from deadlock in the presence of unexpected events, such as might be caused by bugs. As long as the sender still holds the data, there is an opportunity to recover. The second implication is that there must be some mechanism to tell the data sender when to disregard prior SACK information. Again the choice was made for robustness reasons: When things go wrong, TCP can always time out and start over. On this point, it would not surprise me if future field experience leads to some other equally robust but more efficient mechanism to discard prior SACK information (An earlier iteration SACK draft had one possible mechanism). The currently language is maximally conservative about robustness at the expense of some possible theoretical increase in performance. However, that said, I don't expect reneging to be an important part of the protocol. Although the data senders behavior is mandatory, I don't expect anybody to implement a data receiver that deliberately renegs any time soon (although the sender's behavior will be invoked a number of more or less normal cases). The (future) problem which might be usefully addressed by deliberate receiver reneging is one that I refer to as the "autotune problem". At a site like PSC (a supercomputing center) this is the next most significant TCP performance limit, after the lack of SACK. Speaking VERY speculatively now: Consider a large timesharing system, with several hundred users. Our largest TCP pipe has about a 2 MB delay bandwidth product (US coast-to-coast at OC-3). Most users have 60 kB or smaller pipes. The supercomputers can not affort to reserve 2MB of buffer space for every connection. And I really don't what to train users (or applications) about how decide if additional buffer space might help, and to ask for it manually. As a result the system wide default is a compromise, and nearly every connection is miss-tuned in the sense that it has either too much or too little reserved buffer space. Autotuning would be fairly easy to implement in the data sender. The sender knows the history of cwnd and ssthresh, and has reasonable things to do if requests for additional buffer space are denied. (There are just a few lurking subtleties). Autotuning the receiver is much trickier: It has no direct way to observe the congestion window (although there are some indirect ways). This means that the receiver can not easily tell if the sender is controlled by the receiver's advertized window or the senders congestion window. Furthermore, in the typical state the receiver doesn't use much buffer space at all: it takes the received segment hands it to the application. It doesn't need to buffer any data unless the connection is in recovery or the application is slower than the network. It is attractive to entirely avoid the receiver side autotuning problem by making the receiver unconditionally advertize some large window (say %50 of the free buffer pool). This is fine as long as no more than a few connections are in recovery at any given time. (Some applications have other reasons to limit the window, but they don't need autotuning.) However, a pathological condition arises when the network bounces down for a fraction of one round trip time. This sort of event potentially causes every connection to go into recovery at the same time. There must be a mechanism to avoid a system wide deadlock on buffer memory contention. The simplest way to do this is to support reneging both the receiver's window and SACK blocks. This should not be a frequent occurrence, so efficiency is secondary. So in conclusion, the current SACK draft is designed to be robust in the presence of unexpected behavior, while opening the door for future research. --MM-- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id PAA10540 for tcplw-list@sdiv; Tue, 23 Jan 1996 15:27:12 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id PAA10533 for ; Tue, 23 Jan 1996 15:27:11 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id PAA11324 for ; Tue, 23 Jan 1996 15:27:10 -0600 Received: from fab.md.interlink.com (fab.md.interlink.com [138.42.32.80]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id PAA28249 for ; Tue, 23 Jan 1996 15:26:55 -0600 Received: by fab.md.interlink.com (5.0/SMI-SVR4) id AA15220; Tue, 23 Jan 1996 15:45:01 +0500 Date: Tue, 23 Jan 1996 15:45:01 +0500 From: fab@fab.md.interlink.com (Fred Bohle) Message-Id: <9601232045.AA15220@fab.md.interlink.com> To: allyn@caribe-86.Eng.Sun.COM Subject: Re: SACK options draft Cc: tcplw@cray.com X-Sun-Charset: US-ASCII content-length: 0 Allyn, > Enclosed is a revised draft of the TCP Selective Acknowledgement Option > document. It is also being submitted as an internet draft. > > > We have made several changes in reply to comments. > Changes: > - Some rewriting in response to requests for clarification. > - A new sentence that the SACK-Permitted Option MUST NOT be sent on > non-SYN segments. > - Some changes to the paragraph at the end of Section 5 about > data sender behavior after a retransmit timer expires. > - Editing changes to the last paragraph in Section 6 about possible > reductions of the number of available SACK blocks. > I still do not see a description of retransmission based on processing SACKs. There was much discussion on the list, and in the papers referred to, but none is in your draft. So, someone could do everything mentioned in the draft, and still do no good for improving thruput. The papers "TCP and Successive Fast Retransmits" (Floyd), and "Comparisons of Tahoe, Reno, and Sack TCP" (Fall, Floyd), do describe problems with SACKs and possible solutions. We should reach agreement on retransmission strategy and put it in the draft. Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@interlink.com Interlink Computer Sciences AT&T : 410-992-7750 9250 Rumsey Road, Suite 200 Home : 410-643-6720 Columbia, MD 21045-1946 ------------------------------------------------------------------------ Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA25056 for tcplw-list@sdiv; Tue, 23 Jan 1996 13:55:04 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA25052 for ; Tue, 23 Jan 1996 13:55:02 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA07617 for ; Tue, 23 Jan 1996 13:55:02 -0600 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id NAA11883 for ; Tue, 23 Jan 1996 13:54:57 -0600 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id LAA19631; Tue, 23 Jan 1996 11:53:55 -0800 Received: from caribe-86.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) id AB03253; Tue, 23 Jan 1996 11:53:50 -0800 Received: from offshore.eng.sun.com (offshore [129.146.86.134]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id LAA19594; Tue, 23 Jan 1996 11:53:12 -0800 (PST) Received: by offshore.eng.sun.com (5.x/SMI-SVR4) id AA12378; Tue, 23 Jan 1996 11:51:32 -0800 Date: Tue, 23 Jan 1996 11:51:32 -0800 From: allyn@caribe-86.Eng.Sun.COM (Allyn Romanow) Message-Id: <9601231951.AA12378@offshore.eng.sun.com> To: tcplw@cray.com Subject: SACK options draft Cc: e2e@isi.edu X-Sun-Charset: US-ASCII Enclosed is a revised draft of the TCP Selective Acknowledgement Option document. It is also being submitted as an internet draft. We have made several changes in reply to comments. Changes: - Some rewriting in response to requests for clarification. - A new sentence that the SACK-Permitted Option MUST NOT be sent on non-SYN segments. - Some changes to the paragraph at the end of Section 5 about data sender behavior after a retransmit timer expires. - Editing changes to the last paragraph in Section 6 about possible reductions of the number of available SACK blocks. ----------------------------------------------------------------- Internet Engineering Task Force TCPLW WG INTERNET-DRAFT Mathis/Mahdavi/Floyd/Romanow Draft-ietf-tcplw-sack-00.txt PSC/LBL/Sun TCP Selective Acknowledgement Options This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgements, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received. A Selective Acknowledgement (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments. This draft proposes an implementation of SACK and discusses its performance and related issues. Acknowledgements: Much of the text in this document is taken directly from RFC1072 ``TCP Extensions for Long-Delay Paths'' by Bob Braden and Van Jacobson. The authors would like to thank Kevin Fall (LBNL), Christian Huitema (Inria), Van Jacobson (LBNL), Greg Miller (MITRE), Greg Minshall (Ipsilon), Lixia Zhang (XEROX PARC and UCLA), and others for their review and constructive comments. 1. Introduction Multiple packet losses from a window of data can have a catastrophic effect on TCP throughput. TCP [Postel81] uses a cumulative acknowledgment scheme in which received segments that are not at the left edge of the receive window are not acknowledged. This forces the sender to either wait a roundtrip time to find out about each lost packet, or to unnecessarily retransmit segments which have been correctly received [Fall95]. With the cumulative acknowledgment scheme, multiple dropped segments generally cause TCP to lose its ACK-based clock, reducing overall throughput. Selective Acknowledgment (SACK) is a strategy which corrects this behavior in the face of multiple dropped segments. With selective acknowledgments, the data receiver can inform the sender about all segments that have arrived successfully, so the sender need retransmit only the segments that have actually been lost. Several transport protocols, including NETBLT [Clark87], XTP [Strayer92], RDP [Velten84], NADIR [Huitema81], and VMTP [Cheriton88] have used selective acknowledgement. There is some empirical evidence in favor of selective acknowledgments -- simple experiments with RDP have shown that disabling the selective acknowledgment facility greatly increases the number of retransmitted segments over a lossy, high-delay Internet path [Partridge87]. A recent simulation study by Kevin Fall and Sally Floyd [Fall95], demonstrates the strength of TCP with SACK over the non-SACK Tahoe and Reno TCP implementations. RFC1072 [VJ88] describes one possible implementation of SACK options for TCP. Unfortunately, it has never been deployed in the Internet, as there was disagreement about how SACK options should be used in conjunction with the TCP window shift option (initially described RFC1072 and revised in Jacobson92). We propose slight modifications to the SACK options as proposed in RFC1072. Specifically, sending a selective acknowledgment for the most recently received data reduces the need for long SACK options [Keshav94, Mathis95]. In addition, the SACK option now carries full 32 bit sequence numbers. These two modifications represent the only changes to the proposal in RFC1072. They make SACK easier to implement and address concerns about robustness. The selective acknowledgment extension uses two TCP options. The first is an enabling option, "SACK-permitted", which may be sent in a SYN segment to indicate that the SACK option can be used once the connection is established. The other is the SACK option itself, which may be sent over an established connection once permission has been given by SACK-permitted. The SACK option is to be included in a segment sent from a TCP that is receiving data to the TCP that is sending that data; we will refer to these TCP's as the data receiver and the data sender, respectively. We will consider a particular simplex data flow; any data flowing in the reverse direction over the same connection can be treated independently. 2. SACK-Permitted Option This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) the SACK option once the connection has opened. It MUST NOT be sent on non-SYN segments. TCP Sack-Permitted Option: Kind: 4 +---------+---------+ | Kind=4 | Length=2| +---------+---------+ [We need to formally decide (in the BOF?) if we are going to reuse option numbers.] 3. SACK Option Format The SACK option is to be used to convey extended acknowledgment information from the receiver to the sender over an established TCP connection. TCP SACK Option: Kind: 5 Length: Variable +--------+--------+ | Kind=5 | Length | +--------+--------+--------+--------+ | Left Edge of 1st Block | +--------+--------+--------+--------+ | Right Edge of 1st Block | +--------+--------+--------+--------+ | | / . . . / | | +--------+--------+--------+--------+ | Left Edge of nth Block | +--------+--------+--------+--------+ | Right Edge of nth Block | +--------+--------+--------+--------+ The SACK option is to be sent by a data receiver to inform the data sender of non-contiguous blocks of data that have been received and queued. The data receiver awaits the receipt of data (perhaps by means of retransmissions) to fill the gaps in sequence space between received blocks. When missing segments are received, the data receiver acknowledges the data normally by advancing the left window edge in the Acknowledgment Number field of the TCP header. The SACK option does not change the meaning of the Acknowledgment Number field. The SACK option provides additional information which the data transmitter can use to optimize retransmissions. The TCP data receiver includes the SACK option in an acknowledgment segment whenever it has data that is queued and unacknowledged. The SACK option may be sent only when the TCP has received the SACK-permitted option in the SYN segment for that connection. This option contains a list of some of the blocks of contiguous sequence space occupied by data that has been received and queued within the window. Each contiguous block of data queued at the data receiver is defined in the SACK option by two 32-bit unsigned integers in network byte order: * Left Edge of Block This is the first sequence number of this block. * Right Edge of Block This is the sequence number immediately following the last sequence number of this block. Each block represents received bytes of data that are contiguous and isolated; that is, the bytes just below the block, (Left Edge of Block - 1), and just above the block, (Right Edge of Block), have not been received. A SACK option that specifies n blocks will have a length of 8*n+2 bytes, so the 40 bytes available for TCP options can specify a maximum of 4 blocks. It is expected that SACK will often be used in conjunction with the Timestamp option used for RTTM [Jacobson92], which takes an additional 10 bytes (plus two bytes of padding); thus a maximum of 3 SACK blocks will be allowed in this case. The SACK option is advisory, in that, while it notifies the data sender that the data receiver has received the indicated segments, the data receiver is permitted to later discard data which have been reported in a SACK option. A detailed discussion of the advisory nature of the SACK option appears below, following the discussion of the normal case. 4. Generating SACK Options: Data Receiver Behavior If the data receiver has received a SACK-Permitted option on the SYN for this connection, the data receiver MAY elect to generate SACK options as described below. If the data receiver generates SACK options under any circumstance, it SHOULD generate them under all permitted circumstances. If the data receiver has not received a SACK-Permitted option for a given connection, it MUST NOT send SACK options on that connection. If sent at all, SACK options SHOULD be included in all ACKs which do not ACK the highest sequence number in the data receiver's queue. In this situation the network has lost or mis-ordered data, such that the receiver holds non-contiguous data in its queue. RFC 1122, Section 4.2.2.21, discusses the reasons for the receiver to send ACKs in response to additional segments received in this state. The receiver SHOULD send an ACK for every valid segment that arrives containing new data, and each of these "duplicate" ACKs SHOULD bear a SACK option. If the data receiver chooses to send a SACK option, the following rules apply: * The first SACK block (i.e., the one immediately following the kind and length fields in the option) MUST specify the contiguous block of data containing the segment which triggered this ACK, unless that segment advanced the Acknowledgment Number field in the header. This assures that the ACK with the SACK option reflects the most recent state change at the data receiver. * The data receiver SHOULD include as many distinct SACK blocks as possible in the SACK option. Note that the maximum available option space may not be sufficient to report all blocks present in the receiver's queue. * The SACK option SHOULD be filled out by repeating the most recently reported SACK blocks (based on first SACK blocks in previous SACK options) that are not subsets of a SACK block already included in the SACK option being constructed. This assures that in normal operation every SACK block is repeated several times. (At least three times for large-window TCP implementations [RFC1323]). It is very important that the SACK option always reports the block containing the most recently received segment, because this provides the sender with the most up-to-date information about the state of the network and the data receiver's queue. 5. Interpreting the SACK Option and Retransmission Strategy: Data Sender Behavior When receiving an ACK containing a SACK option, the data sender SHOULD record the selective acknowledgement for future reference. The data sender is assumed to have a retransmission queue that contains the segments that have been transmitted but not yet acknowledged, in sequence-number order. If the data sender performs re-packetization before retransmission, the block boundaries in a SACK option that it receives may not fall on boundaries of segments in the retransmission queue; however, this does not pose a serious difficulty for the sender. One possible implementation of the sender's behavior is as follows. Let us suppose that for each segment in the retransmission queue there is a (new) flag bit "SACKed", to be used to indicate that this particular segment has been reported in a SACK option. When an acknowledgment segment arrives containing a SACK option, the data sender will turn on the SACKed bits for segments that have been selectively acknowledged. More specifically, for each block in the SACK option, the data sender will turn on the SACKed flags for all segments in the retransmission queue that are wholly contained within that block. This requires straightforward sequence number comparisons. After the SACKed bit is turned on (as the result of processing a received SACK option), the data sender will skip that segment during any later retransmission. Any segment that has the SACKed bit turned off and is less than the highest SACKed segment is available for retransmission. After a retransmit timeout the data sender SHOULD turn off all of the SACKed bits. The data sender MUST retransmit the segment at the left edge of the window after a retransmit timeout, whether or not the SACKed bit is on for that segment. A segment will not be dequeued and its buffer freed until the left window edge is advanced over it. 5.1 Congestion Control Issues This document does not attempt to specify in detail the congestion control algorithms for implementations of TCP with SACK. However, the congestion control algorithms present in the de facto standard TCP implementations MUST be preserved [Stevens94]. In particular, to preserve robustness in the presence of packets reordered by the network, recovery is not triggered by a single ACK reporting out-of-order packets at the receiver. Further, during recovery the data sender limits the number of segments sent in response to each ACK. Existing implementations limit the data sender to sending one segment during Reno-style fast recovery, or to two segments during slow-start [Jacobson88]. Other aspects of congestion control, such as reducing the congestion window in response to congestion, must similarly be preserved. The use of time-outs as a fall-back mechanism for detecting dropped packets is unchanged by the SACK option. Because the data receiver is allowed to discard SACKed data, when a retransmit timeout occurs the data sender MUST ignore prior SACK information in determining which data to retransmit. Future research into congestion control algorithms may take advantage of the additional information provided by SACK. One such area for future research concerns modifications to TCP for a wireless or satellite environment where packet loss is not necessarily an indication of congestion. 6. Efficiency and Worst Case Behavior If the return path carrying ACKs and SACK options were lossless, one block per SACK option packet would always be sufficient. Every segment arriving while the data receiver holds discontinuous data would cause the data receiver to send an ACK with a SACK option containing the one altered block in the receiver's queue. The data sender is thus able to construct a precise replica of the receiver's queue by taking the union of all the first SACK blocks. Since the return path is not lossless, the SACK option is defined to include more than one SACK block in a single packet. The redundant blocks in the SACK option packet increase the robustness of SACK delivery in the presence of lost ACKs. For a receiver that is also using the time stamp option [Jacobson92], the SACK option has room to include three SACK blocks. Thus each SACK block will generally be repeated at least three times, in three successive ACK packets. However, if all of the ACK packets reporting a particular SACK block are dropped, then the sender might assume that the data in that SACK block has not been received, and unnecessarily retransmit those segments. The deployment of other TCP options may reduce the number of available SACK blocks to 2 or even to 1. This will reduce the redundancy of SACK delivery in the presence of lost ACKs. Even so, the exposure of TCP SACK in regard to the unnecessary retransmission of packets is strictly less than the exposure of current implementations of TCP. The worst-case conditions necessary for the sender to needlessly retransmit data is discussed in more detail in a separate document [Floyd96]. 7. SACK Option Examples The follow examples attempt to demonstrate the proper behavior of SACK generation by the data receiver. Assume the left window edge is 5000 and that the data transmitter sends a burst of 8 segments, each containing 500 data bytes. Case 1: The first 4 segments are received but the last 4 are dropped. The data receiver will return a normal TCP ACK segment acknowledging sequence number 7000, with no SACK option. Case 2: The first segment is dropped but the remaining 7 are received. Upon receiving each of the last seven packets, the data receiver will return a TCP ACK segment that acknowledges sequence number 5000 and contains a SACK option specifying one block of queued data: Triggering ACK Left Edge Right Edge Segment 5000 (lost) 5500 5000 5500 6000 6000 5000 5500 6500 6500 5000 5500 7000 7000 5000 5500 7500 7500 5000 5500 8000 8000 5000 5500 8500 8500 5000 5500 9000 Case 3: The 2nd, 4th, 6th, and 8th (last) segments are dropped. The data receiver ACKs the first packet normally. The third, fifth, and seventh packets trigger SACK options as follows: Triggering ACK First Block 2nd Block 3rd Block Segment Left Right Left Right Left Right Edge Edge Edge Edge Edge Edge 5000 5500 5500 (lost) 6000 5500 6000 6500 6500 (lost) 7000 5500 7000 7500 6000 6500 7500 (lost) 8000 5500 8000 8500 7000 7500 6000 6500 8500 (lost) Suppose at this point, the 4th packet is received out of order. (This could either be because the data was badly misordered in the network, or because the 2nd packet was retransmitted and lost). At this point the data receiver has only two SACK blocks to report. The data receiver replies with the following Selective Acknowledgement: Triggering ACK First Block 2nd Block 3rd Block Segment Left Right Left Right Left Right Edge Edge Edge Edge Edge Edge 6500 5500 6000 7500 8000 8500 Suppose at this point, the 2nd segment is received. The data receiver then replies with the following Selective Acknowledgement: Triggering ACK First Block 2nd Block 3rd Block Segment Left Right Left Right Left Right Edge Edge Edge Edge Edge Edge 5500 7500 8000 8500 8. Data Receiver Reneging Note that the data receiver is permitted to discard data in its queue that has not been acknowledged to the data sender, even if the data has already been reported in a SACK option. Such discarding of SACKed packets is discouraged, but may be used if the receiver runs out of buffer space. The data receiver MAY elect not to keep data which it has reported in a SACK option. In this case, the receiver SACK generation is additionally qualified: * The first SACK block MUST reflect the newest segment. Even if the newest segment is going to be discarded and the receiver has already discarded adjacent segments, the first SACK block MUST report, at a minimum, the left and right edges of the newest segment. * Except for the newest segment, all SACK blocks MUST NOT report any old data which is no longer actually held by the receiver. Since the data receiver may later discard data reported in a SACK option, the sender MUST NOT discard data before it is acknowledged by the Acknowledgment Number field in the TCP header. 9. Security Considerations: This document neither strengthens nor weakens TCP's current security properties. 10. Support Matt Mathis and Jamshid Mahdavi are supported by the National Science Foundation Grant No. NCR-9415552. Sally Floyd is supported by the Director, Office of Energy Research, Scientific Computing Staff, of the U.S. Department of Energy under Contract No. DE-AC03-76F00098. Allyn Romanow is supported by Sun Microsystems. 11. REFERENCES [Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, Stanford University, February 1988. [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT, March 1987. [Fall95] Fall, K. and Floyd, S., "Comparisons of Tahoe, Reno, and Sack TCP", ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z, December 1995. [Floyd96] Floyd, S., "Issues of TCP with SACK", ftp://ftp.ee.lbl.gov/papers/issues_sa.ps.Z, January 1996. [Huitema81] Huitema, C., and Valet, I., An Experiment on High Speed File Transfer using Satellite Links, 7th Data Communication Symposium, Mexico, October 1981. [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", to be presented at SIGCOMM '88, Stanford, CA., August 1988. [Jacobson92] Jacobson, V., Braden, R., and Borman, D., TCP Extensions for High Performance, RFC 1323, May 1992. [Keshav94] Keshav, presentation to the Internet End-to-End Research Group, November 1994. [Mathis95] Mathis, M., and Mahdavi, J., TCP Forward Acknowledgement Option, presentation to the Internet End-to-End Research Group, June 1995. [Partridge87] Partridge, C., "Private Communication", February 1987. [Postel81] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994. [Strayer92] Strayer, T., Dempsey, B., and Weaver, A., XTP -- the xpress transfer protocol. Addison-Wesley Publishing Company, 1992. [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data Protocol", RFC 908, BBN, July 1984. Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id LAA09356 for tcplw-list@sdiv; Mon, 22 Jan 1996 11:32:03 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id LAA09337 for ; Mon, 22 Jan 1996 11:32:01 -0600 From: braden@isi.edu Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id LAA08416 for ; Mon, 22 Jan 1996 11:31:57 -0600 Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id LAA15831 for ; Mon, 22 Jan 1996 11:31:56 -0600 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 22 Jan 1996 09:31:41 -0800 Date: Mon, 22 Jan 96 09:31:46 PST Posted-Date: Mon, 22 Jan 96 09:31:46 PST Message-Id: <9601221731.AA12990@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-4) id ; Mon, 22 Jan 96 09:31:46 PST To: end2end-interest@isi.edu, tcplw@cray.com Subject: TTCP BOF at LA IETF meeting Cc: rstevens@noao.edu, sandy@tis.com Folks, A couple of years ago, under NSF funding I worked out a set of extensions to TCP to do efficient transaction processing. In brief, the good news is that it can be made to work (though not trivially), and it does all the things you expect of a transaction transport protocol. The bad news is that it is pretty complicated. Depending upon your viewpoint, there may be some other bad news, too; as Sandy Murphy pointed out to me, applications should beware of taking too seriously the "at most once" guarantee of T/TCP or any other transaction transport protocol. Recently I have been getting feelers about T/TCP from a diverse set of people. For example, the CPDP folks are planning to do TCP/IP-based ATM [the banking kind of ATM] passcode validation across cellular digital radio, and find (surprise!) that the overhead of doing a transaction using normal TCP is costing them cents (which adds up to a lot of dollars). T/TCP has been suggested as the answer to the Web performance problem. Through no fault of mine, T/TCP is distributed as part of the FreeBSD distribution. Finally, Rich Stevens has suggested to me that there ought to be an IETF standardization effort on T/TCP. It seems timely to introduce this topic into the IETF. Therefore, I have set up a BOF at the LA iETF meeting to introduce T/TCP. I will talk about the protocol for an hour or so, and answer questions to the best of my ability. Then the group can discuss the appropriateness of a WG. TTCP BOF - Thursday, March 7 - 1:00-3:00pm (opposite entmib) Bob Braden Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id EAA21344 for tcplw-list@sdiv; Sat, 20 Jan 1996 04:21:43 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id EAA21340 for ; Sat, 20 Jan 1996 04:21:41 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id EAA14145 for ; Sat, 20 Jan 1996 04:21:41 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id EAA14657 for ; Sat, 20 Jan 1996 04:21:30 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA02361; Sat, 20 Jan 1996 11:18:53 +0100 From: Luigi Rizzo Message-Id: <199601201018.LAA02361@labinfo.iet.unipi.it> Subject: Re: internet-draft for SACK To: gmiller@gateway.mitre.org (Greg Miller) Date: Sat, 20 Jan 1996 11:18:53 +0100 (MET) Cc: tcplw@cray.com In-Reply-To: <199601182046.PAA03328@kayak.mitre.org> from "Greg Miller" at Jan 18, 96 03:46:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1790 > In sect. 8, the example is given that the data-receiver could discard > SACKed segments if it runs out of buffer space. It seems to me that > this could happen only if the data-receiver lies about its buffer > space in its window advertisement. The point that there are let's say it does overbooking of its buffer space. > Also, if the data-receiver discards SACKed segments it essentially > guarantees that those segments will not be retransmitted until a > timeout occurs. In this case, using SACK can actually degrade > performance. So, it seems that discarding SACKed segments should be > strongly discouraged. It'd be much safer just not to send a SACK when > in doubt than to send one and renege. It's not easy to decide not to send a SACK when a segment arrives. And, in any case, this is not as bad as it looks. The decision of discarding an out-of-sequence segment is likely to be taken when the segment is getting old, the receiver is running out of buffers, and more important data are coming in (e.g. in-sequence segments for this or other connections). If I were writing such code, I would at least wait for a reasonable time before declaring a segment too old and discarding it in favour of another one. What worries me more (because I cannot clearly see the implications on performance) is discarding SACK info at the sender side after a single retransmission timeout. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id OAA17012 for tcplw-list@sdiv; Thu, 18 Jan 1996 14:47:04 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id OAA17008 for ; Thu, 18 Jan 1996 14:47:03 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id OAA04656 for ; Thu, 18 Jan 1996 14:47:02 -0600 Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id OAA19533 for ; Thu, 18 Jan 1996 14:47:01 -0600 Received: from kayak.mitre.org (kayak.mitre.org [128.29.31.94]) by gateway.mitre.org (8.7.2/8.7.2) with ESMTP id PAA19338 for ; Thu, 18 Jan 1996 15:47:00 -0500 (EST) Received: from localhost (gmiller@localhost) by kayak.mitre.org (8.7.2/8.7.2) with SMTP id PAA03328 for ; Thu, 18 Jan 1996 15:46:57 -0500 (EST) Message-Id: <199601182046.PAA03328@kayak.mitre.org> X-Authentication-Warning: kayak.mitre.org: gmiller owned process doing -bs X-Authentication-Warning: kayak.mitre.org: Host gmiller@localhost didn't use HELO protocol To: tcplw@cray.com Subject: Re: internet-draft for SACK Date: Thu, 18 Jan 96 15:46:56 -0500 From: Greg Miller I have a few comments after reading the SACK draft. They're minor, but I think they might help with clarity. In sect. 1, the claim is made that "Selective Acknowledgment (SACK) is a strategy which corrects this behavior and restores full throughput in the face of multiple dropped segments." While it's true that SACK can improve throughput performance, I find the term "full throughput" misleading since TCP intentionally reduces its throughput by decreasing its congestion window whenever losses are experienced. In sect. 1, the following sentence appears in the description of the proposed modifications to RFC 1072. "In addition, sequence numbers are now 32 bits." It might be better to say something like "In addition, SACK block delimiters are now 32 bits." since sequence numbers have ALWAYS been 32 bits. :-) I'm sure it's true, but it's never said explicitly that the SACK-permitted option can be sent ONLY in a SYN segment. In sect. 3, the phrase "fully-received data" is used. I know what is meant, but a few more words might be helpful to clarify. In sect. 5, the "RESEND" flag is introduced, but its use is never described. Also, as Luigi pointed out, it is not clear what triggers retransmission of the unSACKed segments that lie between the left window edge and the highest SACKed segment. I assume that since this is left unspecified, TCP's current mechanisms will be relied upon for retransmission. Since a timeout clears the SACK information, retransmission of unSACKed segments must be caused by receipt of (3) duplicate ACKs? In sect. 8, the example is given that the data-receiver could discard SACKed segments if it runs out of buffer space. It seems to me that this could happen only if the data-receiver lies about its buffer space in its window advertisement. The point that there are circumstances under which the data-receiver may discard SACKed segments is valid, but perhaps there is a better example of such a case. Also, if the data-receiver discards SACKed segments it essentially guarantees that those segments will not be retransmitted until a timeout occurs. In this case, using SACK can actually degrade performance. So, it seems that discarding SACKed segments should be strongly discouraged. It'd be much safer just not to send a SACK when in doubt than to send one and renege. Greg ---- Gregory J. Miller Networking and Communications Engineering The MITRE Corporation 7525 Colshire Drive/McLean, VA 22102 gmiller@gateway.mitre.org Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id MAA01325 for tcplw-list@sdiv; Thu, 18 Jan 1996 12:31:14 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id MAA01321 for ; Thu, 18 Jan 1996 12:31:13 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id MAA29092 for ; Thu, 18 Jan 1996 12:31:12 -0600 Received: from frenzy.cray.com (frenzy-eth.cray.com [128.162.96.91]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id MAA26329 for ; Thu, 18 Jan 1996 12:31:12 -0600 Received: by frenzy.cray.com id AA24591; 4.1/CRI-5.6; Thu, 18 Jan 96 12:32:09 CST Date: Thu, 18 Jan 96 12:32:09 CST From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9601181832.AA24591@frenzy.cray.com> To: crawdad@FNAL.Gov, tcplw@cray.com Subject: Re: Two questions from a non-subscriber Matt, > 1. Is there an archive for tcplw? Yes. Try "telnet berserkly.cray.com 23000" > 2. When a host is capable of doing timestamp echo should it send an > MSS option in its SYN packets with a lower value than the usual > (interface MTU-40), perhaps MTU-52? Or is it up to the sender of > data to include less data when sending TCP options? > _________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab > PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A You still fill in the MSS option with "MTU - 40". It is the responsibilty of the sender that is adding TCP options to decrement the amount of TCP data accordingly. It has to, because it doesn't know if MSS is "MTU - 40", or "MTU - 52", so it has to take the conservative approach and assume "MTU - 40", and then adjust for the TCP options that it adds. There is more detailed information about this in the archives. -David Borman, dab@cray.com Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id MAA29777 for tcplw-list@sdiv; Thu, 18 Jan 1996 12:15:13 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id MAA29774 for ; Thu, 18 Jan 1996 12:15:12 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id MAA27379 for ; Thu, 18 Jan 1996 12:15:11 -0600 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id MAA23962 for ; Thu, 18 Jan 1996 12:15:10 -0600 Received: from munin.fnal.gov ("port 3233"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I05LQN1XM6000734@FNAL.FNAL.GOV> for tcplw@cray.com; Thu, 18 Jan 1996 12:15:01 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA02653; Thu, 18 Jan 1996 12:15:00 -0600 (CST) Date: Thu, 18 Jan 1996 12:15:00 -0600 From: Matt Crawford Subject: Two questions from a non-subscriber Sender: crawdad@munin.fnal.gov To: tcplw@cray.com Message-id: <9601181815.AA02653@munin.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{; Tue, 16 Jan 1996 15:57:52 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id PAA00652 for ; Tue, 16 Jan 1996 15:57:52 -0600 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id PAA16943 for ; Tue, 16 Jan 1996 15:57:50 -0600 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id NAA20724; Tue, 16 Jan 1996 13:56:23 -0800 Received: from caribe.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA04708; Tue, 16 Jan 1996 13:56:21 -0800 Received: from kandinsky by caribe.eng.sun.com (5.x/SMI-SVR4) id AA10817; Tue, 16 Jan 1996 13:55:44 -0800 Date: Tue, 16 Jan 1996 14:01:31 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: Re: Fast retransmit in Solaris 2.x To: Fred Bohle Cc: tcplw@cray.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Solaris 2 does indeed support fast rexmit, plus lots of other modern TCP/IP > > features... > > > Bob Gilligan > > SunSoft Internet Engineering Group > > Bob, > How about window scaling and timestamps? > > Fred Bohle > Interlink Computer Sciences > fab@interlink.com That was context of the orignal message. There is a prototype implementation of the TCP large window extensions for Solaris 2 currently being tested. It is available at ftp://playground.sun.com/pub/tcp-lfn. Bob. Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA09421 for tcplw-list@sdiv; Tue, 16 Jan 1996 13:29:38 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA09408 for ; Tue, 16 Jan 1996 13:29:37 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA24309 for ; Tue, 16 Jan 1996 13:29:36 -0600 Received: from fab.md.interlink.com (fab.md.interlink.com [138.42.32.80]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id NAA20504 for ; Tue, 16 Jan 1996 13:29:34 -0600 Received: by fab.md.interlink.com (5.0/SMI-SVR4) id AA13733; Tue, 16 Jan 1996 14:32:14 +0500 Date: Tue, 16 Jan 1996 14:32:14 +0500 From: fab@fab.md.interlink.com (Fred Bohle) Message-Id: <9601161932.AA13733@fab.md.interlink.com> To: Bob.Gilligan@Eng.Sun.COM Subject: Re: Fast retransmit in Solaris 2.x Cc: tcplw@cray.com X-Sun-Charset: US-ASCII content-length: 254 > Solaris 2 does indeed support fast rexmit, plus lots of other modern TCP/IP > features... > > Bob Gilligan > SunSoft Internet Engineering Group Bob, How about window scaling and timestamps? Fred Bohle Interlink Computer Sciences fab@interlink.com Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA06870 for tcplw-list@sdiv; Tue, 16 Jan 1996 13:17:31 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA06863 for ; Tue, 16 Jan 1996 13:17:30 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA23869 for ; Tue, 16 Jan 1996 13:17:29 -0600 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id NAA18218 for ; Tue, 16 Jan 1996 13:17:28 -0600 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id LAA01274; Tue, 16 Jan 1996 11:16:05 -0800 Received: from caribe.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA10800; Tue, 16 Jan 1996 11:16:02 -0800 Received: from kandinsky by caribe.eng.sun.com (5.x/SMI-SVR4) id AA04732; Tue, 16 Jan 1996 11:15:26 -0800 Date: Tue, 16 Jan 1996 11:21:08 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: Re: Fast retransmit in Solaris 2.x To: Zeppenfeldt@eumetsat.de Cc: tcplw@cray.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > One feature outside RFC1323, the fast retransmit/recovery algorithm > . . . > What is now the situation for Solaris 2.x. Do they have it or not ? Solaris 2 does indeed support fast rexmit, plus lots of other modern TCP/IP features (e.g. IP multicast, path MTU discovery, router discovery, multiple default routes, logical interfaces, etc.). Bob Gilligan SunSoft Internet Engineering Group Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id LAA13346 for tcplw-list@sdiv; Tue, 16 Jan 1996 11:17:42 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id LAA13342 for ; Tue, 16 Jan 1996 11:17:41 -0600 From: braden@isi.edu Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id LAA14176 for ; Tue, 16 Jan 1996 11:17:40 -0600 Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id LAA25952 for ; Tue, 16 Jan 1996 11:17:32 -0600 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 16 Jan 1996 09:17:20 -0800 Date: Tue, 16 Jan 96 09:17:24 PST Posted-Date: Tue, 16 Jan 96 09:17:24 PST Message-Id: <9601161717.AA05429@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-4) id ; Tue, 16 Jan 96 09:17:24 PST To: tcplw@cray.com ----- Unsent message follows ----- Date: Tue, 16 Jan 96 09:04:14 PST From: braden Posted-Date: Tue, 16 Jan 96 09:04:14 PST Received-Date: Tue, 16 Jan 96 09:04:14 PST Message-Id: <9601161704.AA05411@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-4) id ; Tue, 16 Jan 96 09:04:14 PST To: minutes@cnri.reston.va.us Subject: Minutes of tcpfix BOF in Dallas Cc: tcplw, end2end-interest, mankin, karn@qualcomm.com, ianh@spider.co.uk Dallas IETF Proceedings Transport Service Area tcpfix BOF Minutes of tcpfix BOF Reported by: Bob Braden/USC Information Sciences Institute Summary This BOF was convened to discuss various issues that have arisen in the specification of the current generation TCP protocol. Agenda -- Monday 4 December: o RSTs Considered Harmful: Ian Heavens o ACK Processing Rules: Phil Karn o Congestion Control Algorithms: Sally Floyd o Selective Acknowledgments SACK: Sally Floyd FACK: Jamshid Madhavi RSTs Considered Harmful Ian Heavens reported on his work on the possibility of unreliable TCP data delivery when a RST segment is used instead of a FIN handshake to terminate a connection. The basic problem is that terminating a connection using RST avoids TIME-WAIT state, which is needed to protect against old duplicates. His Internet Draft draft-heavens-problems-rsts-01.txt contains many explicit examples of the faulty sequences that can occur as a result. To solve this problem, Heavens is proposing a change to the TCP state diagram to provide an acknowledgment for RSTs that terminate connections; he notes that the resulting state diagram is exactly analogous to the non-conservative close of TP4. This threat to reliable delivery due to RST's is in addition to the "TIME-WAIT assassination" problem noted by Bob Braden in RFC-1337. ACK Processing Rules Phil Karn discussed how an ambiguity in the RFC-793 specification of ACK processing could (and did) lead to a TCP implementation that fails during certain cases of continuous full-duplex data transmission. When one side closes its window and the other probes with an ACK, if ACKs sent by the probing end are rejected as unacceptable by the end with the closed window then data transmission in the other direction ceases. Karn's proposed solution is to change the acceptability test for segment sequence numbers so that the ACK field of an incoming segment is processed even when SEG.SEQ is not RCV.NXT, provided that RCV.NXT <= SEG.SEQ < RCV.NXT + Max window size. The result is that out-of-window ACKs will still be dropped, but ACKs that are out of sequence but within the window will be processed normally. Congestion Control Algorithms Sally Floyd reported on a bug fix for Tahoe and Reno fast retransmit code, documented in the short paper: ftp://ftp.ee.lbl.gov/papers/ fastretrans.ps. Floyd also called attention to the LBL network simulator, a new version of which is now available. See http://www-nrg.ee.lbl.gov/ns/. Van Jacobson has previosly-unpublished version of the TCP congestion algorithms that closes the congestion window when the sender has not sent data for more than a round-trip time. A note about this will be reachable from the http://www-nrg.ee.lbl.gov/ directory. Selective Acknowledgments Sally Floyd briefly discussed comparisons of the performance of Tahoe and Reno TCP with TCP augmented with Selective Acknowledgments (SACK). The work is discussed in ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. Simulations of SACK have shown that it effectively repairs a serious defect of Reno TCP: transmission must often wait for a retransmit timeout when multiple packets are dropped from one window of data. During the earlier discussions of SACK in the tcplw Working Group, there was concern that the TCP header has room for only three SACK blocks in its option field. Floyd and Fall have found that under the conditions they have tested, three is sufficient. Jamshid Mahdavi described work on a SACK-variant algorithm called FACK ("Forward Acknowledgment") that he and Matt Mathis have developed. FACK essentially uses a single SACK block, but it sends the block containing the most-recently-received segment. Simulations have shown this works very well, and that FACK is easier than SACK to implement with the TCP Large Windows extensions (RFC1323). Conceptually, it decouples congestion management from data recovery. Conclusions and Actions The group agreed on the following actions from this meeting. 1. Ian Heavens will revise his Internet Draft to clarify and brevity, with the intention that the RST handshake will move towards the standards track. 2. The ambiguity and fix suggested by Phil Karn should be documented. 3. The tcplw (TCP Large Windows) should proceed with SACK. ----- End Included Message ----- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id IAA16251 for tcplw-list@sdiv; Mon, 15 Jan 1996 08:19:25 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id IAA16247 for ; Mon, 15 Jan 1996 08:19:24 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id IAA03001 for ; Mon, 15 Jan 1996 08:19:23 -0600 Received: from noao.edu (noao.edu [140.252.1.54]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id IAA18043 for ; Mon, 15 Jan 1996 08:19:23 -0600 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G104) id AA07288; Mon, 15 Jan 96 07:19:12 MST; for tcplw@cray.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA16063; Mon, 15 Jan 96 07:19:11 MST; for tcplw@cray.com Message-Id: <9601151419.AA16063@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Mon, 15 Jan 1996 07:19:10 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Zeppenfeldt@eumetsat.de, tcplw@cray.com Subject: Re: Fast retransmit in Solaris 2.x [In your message of Jan 12, 5:40pm you write:] > > Stevens writes that TCP/IP implementations that are "Berkeley derived > implementations......" do implement this [Stevens, TCP/IP Ill. V1 p.309]. > > He also writes that Solaris is neither SunOS 4.1.x or SVR4 related. What is > now the situation for Solaris 2.x. Do they have it or not ? Although I've never seen the Solaris TCP/IP source code, note on p. 534 of Volume 1 that one of the Solaris 2.x ndd parameters is tcp_dupack_fast_retransmit: the number of consecutive duplicate ACKs to trigger the fast retransmit algorithm (which defaults to 3). So I'd say it does support it. Rich Stevens Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id CAA00946 for tcplw-list@sdiv; Mon, 15 Jan 1996 02:52:28 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id CAA00941 for ; Mon, 15 Jan 1996 02:52:27 -0600 From: Zeppenfeldt@eumetsat.de Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id CAA26032 for ; Mon, 15 Jan 1996 02:52:26 -0600 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id CAA06144 for ; Mon, 15 Jan 1996 02:52:20 -0600 Received: from iprouter.eumetsat.de by relay.xlink.net id <17270-0@relay.xlink.net>; Mon, 15 Jan 1996 09:51:51 +0000 Received: from iprouter.eumetsat.de by iprouter.eumetsat.de id aa08249; 15 Jan 96 9:47 MEZ Received: from Eumetsat-Message_Server by eumetsat.de with WordPerfect_Office; Mon, 15 Jan 1996 09:51:35 +0100 Message-Id: X-Mailer: WordPerfect Office 4.0 Date: Fri, 12 Jan 1996 17:40:53 +0100 To: tcplw@cray.com Subject: Fast retransmit in Solaris 2.x We would like to setup some testing in future between Solaris 2.x systems with a RFC1323 patch/TCP-LFN for testing 4Mbps TCP sessions with a satellite simulator. One feature outside RFC1323, the fast retransmit/recovery algorithm , I see never mentioned in the TCPLW archived articles although we have the feeling that our current TCP sessions over satellite only work because of this. Stevens writes that TCP/IP implementations that are "Berkeley derived implementations......" do implement this [Stevens, TCP/IP Ill. V1 p.309]. He also writes that Solaris is neither SunOS 4.1.x or SVR4 related. What is now the situation for Solaris 2.x. Do they have it or not ? Thanks in advance, Frank =========================================================== ========================= Frank Zeppenfeldt Zeppenfeldt@eumetsat.de tel: +49 6151 807596 fax: +49 6151 807304 EUMETSAT Am Kavalleriesand 31 64295 Darmstadt Germany =========================================================== ========================= Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id PAA28812 for tcplw-list@sdiv; Fri, 12 Jan 1996 15:01:50 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id PAA28808 for ; Fri, 12 Jan 1996 15:01:49 -0600 From: oq95@aguirre.ing.unifi.it Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id PAA28199 for ; Fri, 12 Jan 1996 15:01:49 -0600 Received: from INGFI1.ING.UNIFI.IT (ingfi1.ing.unifi.it [150.217.10.2]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id PAA25482 for ; Fri, 12 Jan 1996 15:01:44 -0600 Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Wed, 10 Jan 1996 19:45:06 +0200 (MET) Received: from ozon180.ing.unifi.it by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA03418; Wed, 10 Jan 96 16:38:34 +0100 Received: by ozon180.ing.unifi.it (5.0/SMI-SVR4) id AA02607; Wed, 10 Jan 1996 16:37:38 +0100 Date: Wed, 10 Jan 1996 16:37:38 +0100 Message-Id: <9601101537.AA02607@ozon180.ing.unifi.it> To: selist@aguirre.ing.unifi.it Subject: Second IEEE International Conference on Engineering of Complex Computer Systems Cc: pnesi@aguirre.ing.unifi.it X-Sun-Charset: US-ASCII Content-Length: 6015 Call for Papers ICECCS' 96 Second IEEE International Conference on Engineering of Complex Computer Systems Held jointly with 6th CSESAW, 4th IEEE RTAW Montreal, Quebec, Canada, October 21-25, 1996 Sponsored by: IEEE Computer Society, (IEEE Technical Segment Committee on Engineering of Complex Computer Systems) ----------------------------------------------------------------------------- ICECCS'96 General Chair Alexander Stoyenko New Jersey Institute of Technology alex@vulcan.njit.edu CSESAW'96 Chair N.D. Hoang Naval Surface Warfare Center Dahlgren Division IEEE RTAW'96 Chair Ling Guan, University of Sydney Jose Salinas, Naval Undersea Warfare Center Jacques Skubich, INSA Lyons PC Co-Chairs (The Americas) Rick Honendorf, Ontario Hydro Kelvin Nilsen, Iowa State University PC Co-Chairs (Europe & Africa) Bernd Kramer, Fern Universitat, Hagen Kevin Ryon, University of Limerick PC Co-Chair (Asia/Oceania) Yoshiaki Kakuda, Osaka University Industrial/Exhibits Chair Thomas Bihari AMT Systems Engineering, Inc. teb@amt.columbus.oh.us Tutorials Chair Neville Dean, Anglia Polytechnic University Local Arrangements Chair John Harauz, Ontario Hydro Publicity Chair Michael Hinchey New Jersey Institute of Technology Mike.Hinchey@cl.cam.ac.uk ----------------------------------------------------------------------------- Program Committee: T. Ae V. Alagar S. Andler R. Bettati T. Bihari J. Bowen S. Chakravarthy S. Chodrow M. Colnaric L. da F. Costa K. Davis H. Dean P. Devanbu M. Eshaghian B. Furht J. Gaffney D. Gillies H. Gommaa P. Gopinath L. Guan J. Harauz W. Halang H.-L. Hausen M. Hinchey N. D. Hoang R. Hohendorf S. Howell J. Jehuda Y. Kakuda A. Kavensky B. Kramer P. Laplante K. Man T. Marlowe J. McDermid R. Milovanovic P. Moretto L. Motus P. Nesi K. Nilsen R. Nord D. Parnas M. Pezze P. Poon V. Prasanna J. de La Puente T. Risch K. Ryon J. Salinas R. Scherl N. Schneidewind J. J. Schwarz J. Skubich A. Stoyenko N. Suri H. Toetenel G. Tsai J. Vasell J. Voas P. Voldner S. White J. Zalewski ----------------------------------------------------------------------------- Description: IEEE Computer Society's Second International Conference on the Engineering of Complex Computer Systems (ICECCS'96) is to be held in Montreal, Quebec, Canada, in October 1996, jointly with the 6th Complex Systems Engineering Synthesis and Assessment Technology Workshop (CSESAW'96) and the 4th IEEE Workshop on Real-Time Applications (RTAW`96). Scope: Complex computer systems are becoming common in many sectors, such as manufacturing, communications, defense, transportation, aerospace, hazardous environments, energy, and health care. These systems frequently include distributed, heterogeneous networks, and are driven by requirements on performance, real-time behavior, fault tolerance, security, adaptability, development time and cost, long life concerns, and other areas. Such requirements frequently conflict, and satisfaction of these requirements requires managing the tradeoffs among them during system development and throughout the entire system life. The goal of this conference is to bring together industrial, academic, and government experts from these various disciplines, to determine how the disciplines' problems and solution techniques interact within the whole system. Researchers, practitioners, tool developers and users, and technology transition experts are all welcome. Long-term research, near-term complex system requirements and promising tools, and existing complex systems and commercially available tools will be examined on a level playing field. Tracks/Mini-Tracks/Sessions: A number of tracks/mini-tracks are anticipated, chaired by PC members, as follows: * AI and Intelligent Systems (P. Devanbu, R. Scherl) * Architectures, Tools, Environments and Languages (S. Chodrow,T. J. Marlowe, J. Vasell) * Complex Database Systems and Data Management (S. Andler, S. Chakravarthy) * Dependable Real-Time Systems (J. J. Schwarz, N. Suri) * Formal Methods (P. Nesi, H. Toetenel, G. Tsai) * Heterogeneous Computing (M. Eshaghian) * Software Engineering, Re-engineering, Re-use (M. Hinchey, J. McDermid) * Standards (W. Halang, P. Voldner) * Systems Engineering (T. Bihari, R. Milovanovic, P. Poon) * Virtual Reality, Multimedia, Real-Time Imaging (L. da F. Costa, B. Furht, P. Laplante) Submissions: Both long (under 5000 words) and short (under 2500 words) submissions are welcome, including presentations of complete work, summaries of work in progress, position statements, exhibit proposals, tutorial proposals. A submission may address any combination of research, technology or applications within the ECCS area. Prospective participants are encouraged to contact and discuss their possible submissions with appropriate Chairs. All submissions should be made, in eight copies, by April 15th, 1996 to: Alexander Stoyenko Real-Time Computing Laboratory Department of Computer and Information Science New Jersey Institute of Technology University Heights Newark, New Jersey 07102 USA alex@vulcan.njit.edu +1-201-596-3366 (office) +1-201-596-5777 (fax) Suggestions and questions concerning exhibits of research prototypes and commercially available tools and technology should be directed to: Thomas Bihari AMT Systems Engineering 1218 Kinnear Road Columbus, Ohio 43212 USA teb@amt.columbus.oh.us +1-614-486-7741 (office) +1-614-486-9459 (fax) Authors will be notified by July 15, 1996. ----------------------------------------------------------------------------- ICECCS'96 is generously supported by: ONR, Naval Surface Warfare Center, Honeywell, and Real-Time Computing Laboratory at NJIT. ----------------------------------------------------------------------------- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA22601 for tcplw-list@sdiv; Fri, 12 Jan 1996 13:31:38 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA22597 for ; Fri, 12 Jan 1996 13:31:37 -0600 From: oq95@aguirre.ing.unifi.it Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA24840 for ; Fri, 12 Jan 1996 13:31:36 -0600 Received: from INGFI1.ING.UNIFI.IT (ingfi1.ing.unifi.it [150.217.10.2]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id NAA10477 for ; Fri, 12 Jan 1996 13:29:58 -0600 Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Wed, 10 Jan 1996 19:42:48 +0200 (MET) Received: from ozon180.ing.unifi.it by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA03682; Wed, 10 Jan 96 16:51:41 +0100 Errors-To: oq95@aguirre.ing.unifi.it Received: by ozon180.ing.unifi.it (5.0/SMI-SVR4) id AA02622; Wed, 10 Jan 1996 16:46:14 +0100 Date: Wed, 10 Jan 1996 16:46:14 +0100 Message-Id: <9601101546.AA02622@ozon180.ing.unifi.it> Errors-To: oq95@aguirre.ing.unifi.it To: selist@aguirre.ing.unifi.it Subject: Second IEEE International Conference on Engineering of Complex Computer Systems Cc: nesi@aguirre.ing.unifi.it X-Sun-Charset: US-ASCII Reply-To: oq95@aguirre.ing.unifi.it Errors-To: oq95@aguirre.ing.unifi.it Content-Length: 6015 Call for Papers ICECCS' 96 Second IEEE International Conference on Engineering of Complex Computer Systems Held jointly with 6th CSESAW, 4th IEEE RTAW Montreal, Quebec, Canada, October 21-25, 1996 Sponsored by: IEEE Computer Society, (IEEE Technical Segment Committee on Engineering of Complex Computer Systems) ----------------------------------------------------------------------------- ICECCS'96 General Chair Alexander Stoyenko New Jersey Institute of Technology alex@vulcan.njit.edu CSESAW'96 Chair N.D. Hoang Naval Surface Warfare Center Dahlgren Division IEEE RTAW'96 Chair Ling Guan, University of Sydney Jose Salinas, Naval Undersea Warfare Center Jacques Skubich, INSA Lyons PC Co-Chairs (The Americas) Rick Honendorf, Ontario Hydro Kelvin Nilsen, Iowa State University PC Co-Chairs (Europe & Africa) Bernd Kramer, Fern Universitat, Hagen Kevin Ryon, University of Limerick PC Co-Chair (Asia/Oceania) Yoshiaki Kakuda, Osaka University Industrial/Exhibits Chair Thomas Bihari AMT Systems Engineering, Inc. teb@amt.columbus.oh.us Tutorials Chair Neville Dean, Anglia Polytechnic University Local Arrangements Chair John Harauz, Ontario Hydro Publicity Chair Michael Hinchey New Jersey Institute of Technology Mike.Hinchey@cl.cam.ac.uk ----------------------------------------------------------------------------- Program Committee: T. Ae V. Alagar S. Andler R. Bettati T. Bihari J. Bowen S. Chakravarthy S. Chodrow M. Colnaric L. da F. Costa K. Davis H. Dean P. Devanbu M. Eshaghian B. Furht J. Gaffney D. Gillies H. Gommaa P. Gopinath L. Guan J. Harauz W. Halang H.-L. Hausen M. Hinchey N. D. Hoang R. Hohendorf S. Howell J. Jehuda Y. Kakuda A. Kavensky B. Kramer P. Laplante K. Man T. Marlowe J. McDermid R. Milovanovic P. Moretto L. Motus P. Nesi K. Nilsen R. Nord D. Parnas M. Pezze P. Poon V. Prasanna J. de La Puente T. Risch K. Ryon J. Salinas R. Scherl N. Schneidewind J. J. Schwarz J. Skubich A. Stoyenko N. Suri H. Toetenel G. Tsai J. Vasell J. Voas P. Voldner S. White J. Zalewski ----------------------------------------------------------------------------- Description: IEEE Computer Society's Second International Conference on the Engineering of Complex Computer Systems (ICECCS'96) is to be held in Montreal, Quebec, Canada, in October 1996, jointly with the 6th Complex Systems Engineering Synthesis and Assessment Technology Workshop (CSESAW'96) and the 4th IEEE Workshop on Real-Time Applications (RTAW`96). Scope: Complex computer systems are becoming common in many sectors, such as manufacturing, communications, defense, transportation, aerospace, hazardous environments, energy, and health care. These systems frequently include distributed, heterogeneous networks, and are driven by requirements on performance, real-time behavior, fault tolerance, security, adaptability, development time and cost, long life concerns, and other areas. Such requirements frequently conflict, and satisfaction of these requirements requires managing the tradeoffs among them during system development and throughout the entire system life. The goal of this conference is to bring together industrial, academic, and government experts from these various disciplines, to determine how the disciplines' problems and solution techniques interact within the whole system. Researchers, practitioners, tool developers and users, and technology transition experts are all welcome. Long-term research, near-term complex system requirements and promising tools, and existing complex systems and commercially available tools will be examined on a level playing field. Tracks/Mini-Tracks/Sessions: A number of tracks/mini-tracks are anticipated, chaired by PC members, as follows: * AI and Intelligent Systems (P. Devanbu, R. Scherl) * Architectures, Tools, Environments and Languages (S. Chodrow,T. J. Marlowe, J. Vasell) * Complex Database Systems and Data Management (S. Andler, S. Chakravarthy) * Dependable Real-Time Systems (J. J. Schwarz, N. Suri) * Formal Methods (P. Nesi, H. Toetenel, G. Tsai) * Heterogeneous Computing (M. Eshaghian) * Software Engineering, Re-engineering, Re-use (M. Hinchey, J. McDermid) * Standards (W. Halang, P. Voldner) * Systems Engineering (T. Bihari, R. Milovanovic, P. Poon) * Virtual Reality, Multimedia, Real-Time Imaging (L. da F. Costa, B. Furht, P. Laplante) Submissions: Both long (under 5000 words) and short (under 2500 words) submissions are welcome, including presentations of complete work, summaries of work in progress, position statements, exhibit proposals, tutorial proposals. A submission may address any combination of research, technology or applications within the ECCS area. Prospective participants are encouraged to contact and discuss their possible submissions with appropriate Chairs. All submissions should be made, in eight copies, by April 15th, 1996 to: Alexander Stoyenko Real-Time Computing Laboratory Department of Computer and Information Science New Jersey Institute of Technology University Heights Newark, New Jersey 07102 USA alex@vulcan.njit.edu +1-201-596-3366 (office) +1-201-596-5777 (fax) Suggestions and questions concerning exhibits of research prototypes and commercially available tools and technology should be directed to: Thomas Bihari AMT Systems Engineering 1218 Kinnear Road Columbus, Ohio 43212 USA teb@amt.columbus.oh.us +1-614-486-7741 (office) +1-614-486-9459 (fax) Authors will be notified by July 15, 1996. ----------------------------------------------------------------------------- ICECCS'96 is generously supported by: ONR, Naval Surface Warfare Center, Honeywell, and Real-Time Computing Laboratory at NJIT. ----------------------------------------------------------------------------- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id MAA15225 for tcplw-list@sdiv; Fri, 12 Jan 1996 12:20:12 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id MAA15221 for ; Fri, 12 Jan 1996 12:20:11 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id MAA21564 for ; Fri, 12 Jan 1996 12:20:10 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id MAA28961 for ; Fri, 12 Jan 1996 12:19:59 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA04311; Fri, 12 Jan 1996 17:57:07 +0100 From: Luigi Rizzo Message-Id: <199601121657.RAA04311@labinfo.iet.unipi.it> Subject: Re: Cheap SACKs To: mahdavi@psc.edu Date: Fri, 12 Jan 1996 17:57:07 +0100 (MET) Cc: tcplw@cray.com, mathis@zippy.psc.edu, floyd@ee.lbl.gov, allyn@Eng.Sun.COM In-Reply-To: <199601121502.KAA10085@sabre.psc.edu> from "Jamshid Mahdavi" at Jan 12, 96 10:02:05 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2018 > > A note on a possibly imprecise but cheap implementation of SACKs, > > which I will call TSACK as a shorthand for Timestamp-SACK. > > > > The idea is to use RFC1323 timestamps (whose meaning is already > > overloaded, being used for PAWS) to convey info on both the timestamp > > of a segment *and* the identity of the segment being acknowledged. > > I'll note that Phil Karn also suggested this idea to me at the last Thank you very much for the reference. I did not know of Karn's suggestion (and I did not mean to claim any paternity, only to receive feedback). Unfortunately, for me (and I guess most people living outside the USA) the participation to IETF or other meetings is very expensive and it is also hard to justify travel expenses which are not motivated by the presentation of a paper. The only way for me to keep up with current ideas is to use the newsgroups or the mailing lists. This at times may cause me to post "obvious" or "already said" things, I hope this does not disturb people too much. > IETF. I believe that the additional information which can be encoded > in the SACK option format currently proposed make it well worth the > overhead of creating an additional option. I fully agree on this. What I believe, though, is that a "backward compatible" (with RFC1323) implementation gives many more chances to experiment the effectiveness of SACK and congestion control protocols in the field rather than limiting to simulations. Not to mention the benefits for the network itself, which would experience improved performance by just upgrading some "popular" ftp/http servers. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA07221 for tcplw-list@sdiv; Fri, 12 Jan 1996 09:04:58 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA07204 for ; Fri, 12 Jan 1996 09:04:57 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id JAA10486 for ; Fri, 12 Jan 1996 09:04:56 -0600 Received: from sabre.psc.edu (sabre.psc.edu [128.182.61.159]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA19923 for ; Fri, 12 Jan 1996 09:04:55 -0600 Received: (from mahdavi@localhost) by sabre.psc.edu (940816.SGI.8.6.9/8.6.12) id KAA10085; Fri, 12 Jan 1996 10:02:24 -0500 Date: Fri, 12 Jan 1996 10:02:24 -0500 Message-Id: <199601121502.KAA10085@sabre.psc.edu> From: Jamshid Mahdavi To: Luigi Rizzo CC: tcplw@cray.com, mathis@zippy.psc.edu, floyd@ee.lbl.gov, allyn@Eng.Sun.COM In-reply-to: Luigi Rizzo's message of Thu, 11 Jan 1996 18:18:20 +0100 (MET) Subject: Re: Cheap SACKs Reply-to: mahdavi@psc.edu References: <199601111718.SAA02355@labinfo.iet.unipi.it> > From: Luigi Rizzo > Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo), mathis@zippy.psc.edu, > mahdavi@psc.edu, floyd@ee.lbl.gov, allyn@eng.sun.com > Date: Thu, 11 Jan 1996 18:18:20 +0100 (MET) > X-From-Line: tcplw-relay@cray.com Thu Jan 11 22:03:44 1996 > X-Mailer: ELM [version 2.4 PL23] > Content-Type: text > X-Content-Length: 2503 > Lines: 58 > Xref: sabre.psc.edu tcp.tcplw:12 > > A note on a possibly imprecise but cheap implementation of SACKs, > which I will call TSACK as a shorthand for Timestamp-SACK. > > The idea is to use RFC1323 timestamps (whose meaning is already > overloaded, being used for PAWS) to convey info on both the timestamp > of a segment *and* the identity of the segment being acknowledged. I'll note that Phil Karn also suggested this idea to me at the last IETF. I believe that the additional information which can be encoded in the SACK option format currently proposed make it well worth the overhead of creating an additional option. --Jamshid Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id CAA06750 for tcplw-list@sdiv; Fri, 12 Jan 1996 02:29:42 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id CAA06746 for ; Fri, 12 Jan 1996 02:29:41 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id CAA27908 for ; Fri, 12 Jan 1996 02:29:40 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id CAA22182 for ; Fri, 12 Jan 1996 02:27:45 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA03675; Fri, 12 Jan 1996 09:24:45 +0100 From: Luigi Rizzo Message-Id: <199601120824.JAA03675@labinfo.iet.unipi.it> Subject: Re: Cheap SACKs To: mathis@zippy.psc.edu (Matt Mathis) Date: Fri, 12 Jan 1996 09:24:44 +0100 (MET) Cc: tcplw@cray.com, mathis@zippy.psc.edu, mahdavi@psc.edu, floyd@ee.lbl.gov, allyn@Eng.Sun.COM In-Reply-To: <9601120428.AA05570@mailer.psc.edu> from "Matt Mathis" at Jan 11, 96 11:27:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3221 > An easier way to do this is keep per segment state (including a time stamp, > retransmit flags, and all sorts of goop) in an array and to put the array > index in part of the time stamp option. The remaining bits can be used to > keep a recycle counters such that you can detect old values. That is more or less what I had in mind. > This idea has been around for a while (I don't claim credit for it). > > This (and your scheme) has similar properties to some of the algorithms under > investigation by Keschav: He has a paper in draft for sigcomm'96. During > recovery you can not distinguish between lost ACKs and lost segments so both > cause retransmissions. Lost ACKs are guaranteed to cause duplicate data at > the receiver. not more than in current TCP implementations, i.e. a lost ack can be overridden by a newer one. > Another potential issue is that during non-recovery phases, the rules for how > to select which timestamp to echo assume that they contain times. In some RFC1323 only claims the receiver treats the timestamp as simply a monotone- increasing serial number, without any necessary connection to its clock. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number. and that can be easily achieved. What is a bit harder (read: memory consuming) is to keep status info for all the outstanding segments that you can have. > ---------------------------------------------------------------- > Here is a proposition to think about. Suppose our goal is to make TCP the > sole bulk data transport protocol for usage in *all* environments. if we want this I believe we should add an "UNRELIABLE" option for use in those situations where retransmissions are less acceptable than data losses. > What would it take to make TCP work for a Saturn probe? Here are the rules: > (Somebody at NASA can cons up more realistic numbers) > RTT = 5 hours > Downlink is T1 (1.5 Mb/s) > Uplink is 9.6 kb/s > You are allowed to discard TCPs self-clocking, VJ congestion control, etc. > But you must fix SACK to implement reliable transport. > > (i.e the link layer tells you when to transmit a packet, but does not tell you > which packet.) > > Note that Delay*BW is about 4 GBytes which is a million 4 KByte packets. (And > more than 31 bits of sequence space!) > > None of the schemes mentioned comes even close to the right order-of-magnitude > to make this work. > > NASA side steps the issue by doing reliable delivery in the link layer.... > thus making TCP pointless in this environment. does this mean that they keep 4GB (on the ground station, I hope!) and 21MB (on the probe) of queued data, or they use a heavily redundant encoding of the data so that retransmissions are in practice unnecessary ? Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id WAA20267 for tcplw-list@sdiv; Thu, 11 Jan 1996 22:28:32 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id WAA20263 for ; Thu, 11 Jan 1996 22:28:31 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id WAA20892 for ; Thu, 11 Jan 1996 22:28:30 -0600 Received: from mailer.psc.edu (mailer.psc.edu [128.182.62.100]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id WAA19227 for ; Thu, 11 Jan 1996 22:28:29 -0600 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA05570; Thu, 11 Jan 1996 23:28:19 -0500 Message-Id: <9601120428.AA05570@mailer.psc.edu> To: Luigi Rizzo Cc: tcplw@cray.com, mathis@zippy.psc.edu, mahdavi@psc.edu, floyd@ee.lbl.gov, allyn@Eng.Sun.COM Subject: Re: Cheap SACKs In-Reply-To: Your message of "Thu, 11 Jan 1996 18:18:20 +0100." <199601111718.SAA02355@labinfo.iet.unipi.it> Date: Thu, 11 Jan 1996 23:28:17 -0500 From: "Matt Mathis" An easier way to do this is keep per segment state (including a time stamp, retransmit flags, and all sorts of goop) in an array and to put the array index in part of the time stamp option. The remaining bits can be used to keep a recycle counters such that you can detect old values. This idea has been around for a while (I don't claim credit for it). This (and your scheme) has similar properties to some of the algorithms under investigation by Keschav: He has a paper in draft for sigcomm'96. During recovery you can not distinguish between lost ACKs and lost segments so both cause retransmissions. Lost ACKs are guaranteed to cause duplicate data at the receiver. Another potential issue is that during non-recovery phases, the rules for how to select which timestamp to echo assume that they contain times. In some situations you send the timestamp from the oldest previously unACKed segment, in others you send it from the newest. The biggest advantage to this scheme is that the data receiver code is already deployed. ---------------------------------------------------------------- Here is a proposition to think about. Suppose our goal is to make TCP the sole bulk data transport protocol for usage in *all* environments. What would it take to make TCP work for a Saturn probe? Here are the rules: (Somebody at NASA can cons up more realistic numbers) RTT = 5 hours Downlink is T1 (1.5 Mb/s) Uplink is 9.6 kb/s You are allowed to discard TCPs self-clocking, VJ congestion control, etc. But you must fix SACK to implement reliable transport. (i.e the link layer tells you when to transmit a packet, but does not tell you which packet.) Note that Delay*BW is about 4 GBytes which is a million 4 KByte packets. (And more than 31 bits of sequence space!) None of the schemes mentioned comes even close to the right order-of-magnitude to make this work. NASA side steps the issue by doing reliable delivery in the link layer.... thus making TCP pointless in this environment. --MM-- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id VAA17897 for tcplw-list@sdiv; Thu, 11 Jan 1996 21:00:46 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id VAA17893 for ; Thu, 11 Jan 1996 21:00:45 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id VAA19626 for ; Thu, 11 Jan 1996 21:00:44 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id VAA08054 for ; Thu, 11 Jan 1996 21:00:39 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA02355; Thu, 11 Jan 1996 18:18:21 +0100 From: Luigi Rizzo Message-Id: <199601111718.SAA02355@labinfo.iet.unipi.it> Subject: Cheap SACKs To: tcplw@cray.com Date: Thu, 11 Jan 1996 18:18:20 +0100 (MET) Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo), mathis@zippy.psc.edu, mahdavi@psc.edu, floyd@ee.lbl.gov, allyn@Eng.Sun.COM X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2503 A note on a possibly imprecise but cheap implementation of SACKs, which I will call TSACK as a shorthand for Timestamp-SACK. The idea is to use RFC1323 timestamps (whose meaning is already overloaded, being used for PAWS) to convey info on both the timestamp of a segment *and* the identity of the segment being acknowledged. This should be possible because timestamps and PAWS can probably work even using much less than 32 bits [I am not giving full details here, but am quite confident that this is possible]. In this case, the remaining bits can be used to hold (either directly, or via a conversion table) the identity of the TCP segment being acknowledged. Apart from the PAWS test (and the timestamp can be build so as to make it pass the test), the timestamp value is simply copied by the receiving side into the ACK, so that the timestamp can be used as a TSACK. This way of operating have pros and cons. CONS: + the solution is not "conceptually clean", because the meaning of timestamps is overloaded (although their use for PAWS is also an overloading). + using some bits for the sequence number might make PAWS less robust (but there is a lot of tolerance on this) + TSACKs are less precise than SACKs, because they do not not carry full sequence number or segment length (but this info could be reconstructed at the sender). + not all segments have a chance to be TSACKed (but those received out of sequence should). + anything I have forgotten ? PROS: + only requires changes to the sender side of TCP. + any receiving TCP implementing RFC1323 will be able to produce TSACKs, thus giving the sender a better picture of the reassembly queue at the receiver. + the data structures used to implement TSACKs can be reused for a full implementation of SACKs I believe the PROS are very significant, especially because they would allow interoperability with a large number of systems and would give chances to test SACKs (and the associated congestion control and retransmission policies) on the field in a variety of situations. Comments are solicited and welcome. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id TAA05055 for tcplw-list@sdiv; Fri, 5 Jan 1996 19:59:59 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id TAA05051 for ; Fri, 5 Jan 1996 19:59:58 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id TAA02596 for ; Fri, 5 Jan 1996 19:59:58 -0600 Received: from ell.ee.lbl.gov (ell.ee.lbl.gov [128.3.112.145]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id TAA20674 for ; Fri, 5 Jan 1996 19:59:57 -0600 Received: by ell.ee.lbl.gov (8.7.1/1.43r) id RAA27471; Fri, 5 Jan 1996 17:59:47 -0800 (PST) Message-Id: <199601060159.RAA27471@ell.ee.lbl.gov> To: Luigi Rizzo cc: tcplw@cray.com Subject: Re: internet-draft for SACK Date: Fri, 05 Jan 96 17:59:46 PST From: Sally Floyd Luigi - >(btw, [Floyd96] "Issues of TCP with SACK" is missing on the server >as of this morning) Sorry, I just moved the first rough draft of that document to that server (ftp://ftp.ee.lbl.gov/papers/issues_sa.ps). - Sally Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id TAA03761 for tcplw-list@sdiv; Fri, 5 Jan 1996 19:23:42 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id TAA03757 for ; Fri, 5 Jan 1996 19:23:41 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id TAA02181 for ; Fri, 5 Jan 1996 19:23:40 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id TAA16440 for ; Fri, 5 Jan 1996 19:23:36 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id CAA28033; Sat, 6 Jan 1996 02:24:46 +0100 From: Luigi Rizzo Message-Id: <199601060124.CAA28033@labinfo.iet.unipi.it> Subject: Re: internet-draft for SACK To: mathis@zippy.psc.edu, tcplw@cray.com, mahdavi@psc.edu, floyd@ee.lbl.gov, allyn@Eng.Sun.COM Date: Sat, 6 Jan 1996 02:24:46 +0100 (MET) Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3649 A few comments on the Internet draft: [Sec.4] The number of times a segment is SACKed is heavily dependant on the size of the block it belongs, its position in the block, *and* the number of SACK blocks that can be put in a single option. There are many cases in which less than three SACKs are generated for a given segment. But the fact that a SACK for a given segment is not generated or received at the transmitter has only a minor impact on performance. The real problem occurs when no new ACKs or SACKs arrive within a retransmission timeout: in this case we "lose the clock" and performance decays dramatically. In this respect, having a sufficiently large window (even during "congestion" situations), is more important than the number of SACKs that can fit in the option field. [Sec.5] there is some confusion in the text. Are the "RESEND" and "ACKed" bits the same ? Also, it would probably better to call them "SACKed" bits, in order to avoid confusion with standard TCP acks. [end of Sec.3; end of Sec.5; Sec.5.1; beginning of Sec.8] allowing the receiver to throw away SACKed segments at any time and without notice is a bit too permissive. I expect this to happen only in very special cases. Nevertheless, the draft assumes this as the default behaviour, and uses a retransmit timeout to expire SACKed bits in the transmitter. In order to leave this possibility open, why don't use an explicit option, "Sorry-all-previously-SACKed-segments-have-been-disposed" ? [Sec.5 and 5.1] It is not clear at all when a transmitter should start resending un(S)acked segments between the left window edge and the highest (S)acked segment. The following possibilities come to mind: (1) immediately after the last segment (within the receive window) This might be cause unnecessary retransmission for segments which are received out of sequence. (2) after a retransmit timeout (RTO seconds). This cannot work if, as specified in Sec.5, a retransmit timeout also clears all ACKed bits. Also, this prevents the connection from being kept active all the time. (3) RTO seconds after the un(S)acked segment has been transmitted. This is probably the most reasonable choice. We set a "soft" timeout for *each* segment, with the only purpose of triggering the retransmission of that specific segment. It does not clear the ACKed bits and is not considered as a retransmission timeout. If the window is sufficiently large, this approach is like (1), but guarantees enough time for out-of-sequence segments to be received and SACKed. If the window is small, this approach is just marginally better than (2). From the implementation point of view, each segment in the transmit queue must be stored together with its timestamp. After the last segment has been sent, a "soft" timeout is scheduled for the earliest-sent unacked segment (this is not necessarily the segment with the lowest sequence number, as segments can be retransmitted and their timestamp is advanced). The timeout is cleared or advanced as SACK and ACK arrive. For the segment with the highest sequence number a 'hard' retransmission timeout is scheduled, with all the usual side effects. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id TAA03581 for tcplw-list@sdiv; Fri, 5 Jan 1996 19:19:04 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id TAA03576 for ; Fri, 5 Jan 1996 19:19:03 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id TAA02122 for ; Fri, 5 Jan 1996 19:19:03 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id TAA15857 for ; Fri, 5 Jan 1996 19:18:59 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id CAA28015; Sat, 6 Jan 1996 02:20:04 +0100 From: Luigi Rizzo Message-Id: <199601060120.CAA28015@labinfo.iet.unipi.it> Subject: Re: internet-draft for SACK To: braden@isi.edu (Bob Braden) Date: Sat, 6 Jan 1996 02:20:04 +0100 (MET) Cc: braden@isi.edu, mathis@zippy.psc.edu, tcplw@cray.com In-Reply-To: <199601052025.AA27533@zephyr.isi.edu> from "Bob Braden" at Jan 5, 96 12:25:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2860 Bob Braden said: > *> From luigi@labinfo.iet.unipi.it Fri Jan 5 12:13:02 1996 ... > *> > *> About last month I proposed to this list a more compact encoding > *> of SACKs, which should work reasonably well even with limited option > *> space. So the problem of '1' vs. 'some' SACKs should not be an issue. > *> > > Luigi, > > The effect of compact SACK encoding was thoroughly discussed in the > tcplw working group, and all agreed that it would be a undesirable > to have less than the full length seq and length fields (If any > tcplw member would like to dispute my memory here, please speak up!). My proposal was to: - scan through the list of received segments to find the GCD of the lengths of holes and blocks of data (the first hole and the last block are dealt with in a special way); - send the following data in a SACK option: FIRST-HOLE, LAST-BLOCK, GCD, and a bitmap representing the status of intermediate blocks. If you omit the GCD and the bitmap, you have the same info as in a single SACK of the recently posted Internet draft. The GCD and the bitmap can be helpful if we want to stuff more info in the option. However, the problem is not how compactly you encode the SACK option, but how this option interacts with the congestion control. This is not completely clear to me, nor it is very clearly specified in the recent draft. > As I recall, the issue had to do with (1) bad, or at least questionable, > interactions with congestion control if you omit information; > (2) unwillingness to design a mechanism that only works when > all data segments are the same size; (3) conceptual cleanliness and > (4) implementation simplicity. (1) See above. (2) I understand the perplexity, but how realistic is a different situation in which SACKs can make a difference ? (3,4) obviously cannot comment on these two. > *> What is new in this Internet draft is the concept that very few > *> SACKs suffice in avoiding deadlocks (which is essentially what > *> happens when we have to wait the expiration of a timeout to restart). > *> > > Just a protest about terminology; as I usually see the term used, > deadlocks cannot be "essentially"; they either are, or they aren't. > Waiting for a retransmission timeout may be bad on throughput, but it > is not a deadlock. Right. (we would have a deadlock if we didn't have the timeout. of course, we would have a deadlock if we didn't have ACKs...) Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id OAA05990 for tcplw-list@sdiv; Fri, 5 Jan 1996 14:27:25 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id OAA05985 for ; Fri, 5 Jan 1996 14:27:24 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id OAA22459 for ; Fri, 5 Jan 1996 14:27:23 -0600 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id OAA01052 for ; Fri, 5 Jan 1996 14:27:21 -0600 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Fri, 5 Jan 1996 12:25:43 -0800 Date: Fri, 5 Jan 1996 12:25:43 -0800 From: braden@isi.edu (Bob Braden) Message-Id: <199601052025.AA27533@zephyr.isi.edu> To: braden@isi.edu, luigi@labinfo.iet.unipi.it Subject: Re: internet-draft for SACK Cc: mathis@zippy.psc.edu, tcplw@cray.com *> From luigi@labinfo.iet.unipi.it Fri Jan 5 12:13:02 1996 *> From: Luigi Rizzo *> Subject: Re: internet-draft for SACK *> To: braden@ISI.EDU (Bob Braden) *> Date: Fri, 5 Jan 1996 21:15:01 +0100 (MET) *> Cc: mathis@zippy.psc.edu, braden@ISI.EDU, tcplw@cray.com *> In-Reply-To: <199601051904.AA23618@zephyr.isi.edu> from "Bob Braden" at Jan 5, 96 11:03:55 am *> X-Mailer: ELM [version 2.4 PL23] *> Content-Type *> : *> text *> *> Content-Length: 1753 *> X-Lines: 36 *> *> Apparently the list is alive again... *> > *> > To augment my previous message: *> > *> > My theory of SACK is that the only good numbers for SACK slots are "1" *> > and "infinity"; I never liked or trusted the number "3". Your scheme *> > has shown a way to make things work pretty well (for some value of *> > "pretty" {?)) with only one SACK slot. Therefore, you should *> > be not be disturbed that other uses of the option space reduce the *> > number of allowed SACK slots to 2 or even 1, right? *> > *> > Bob *> *> About last month I proposed to this list a more compact encoding *> of SACKs, which should work reasonably well even with limited option *> space. So the problem of '1' vs. 'some' SACKs should not be an issue. *> Luigi, The effect of compact SACK encoding was thoroughly discussed in the tcplw working group, and all agreed that it would be a undesirable to have less than the full length seq and length fields (If any tcplw member would like to dispute my memory here, please speak up!). As I recall, the issue had to do with (1) bad, or at least questionable, interactions with congestion control if you omit information; (2) unwillingness to design a mechanism that only works when all data segments are the same size; (3) conceptual cleanliness and (4) implementation simplicity. *> What is new in this Internet draft is the concept that very few *> SACKs suffice in avoiding deadlocks (which is essentially what *> happens when we have to wait the expiration of a timeout to restart). *> Just a protest about terminology; as I usually see the term used, deadlocks cannot be "essentially"; they either are, or they aren't. Waiting for a retransmission timeout may be bad on throughput, but it is not a deadlock. *> I am reading carefully the RFC draft and the referenced papers *> (btw, [Floyd96] "Issues of TCP with SACK" is missing on the server *> as of this morning) to understand how this is proved. I am curious *> to see if the assumption is true even with the large loss rates *> (30% and more) that we (from some sites in Italy and Europe) are *> experiencing on overseas connections. [Fall95] seems to deal with *> a completely different setting, so the results may or may not apply. *> I think some would suggest that no retransmission mechanism will work satisfactorily with 30% loss rates. Bob Braden *> Luigi *> ==================================================================== *> Luigi Rizzo Dip. di Ingegneria dell'Informazione *> email: luigi@iet.unipi.it Universita' di Pisa *> tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) *> fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ *> ==================================================================== *> Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id OAA04217 for tcplw-list@sdiv; Fri, 5 Jan 1996 14:14:30 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id OAA04214 for ; Fri, 5 Jan 1996 14:14:28 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id OAA21974 for ; Fri, 5 Jan 1996 14:14:28 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id OAA28488 for ; Fri, 5 Jan 1996 14:14:26 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id VAA27427; Fri, 5 Jan 1996 21:15:01 +0100 From: Luigi Rizzo Message-Id: <199601052015.VAA27427@labinfo.iet.unipi.it> Subject: Re: internet-draft for SACK To: braden@isi.edu (Bob Braden) Date: Fri, 5 Jan 1996 21:15:01 +0100 (MET) Cc: mathis@zippy.psc.edu, braden@isi.edu, tcplw@cray.com In-Reply-To: <199601051904.AA23618@zephyr.isi.edu> from "Bob Braden" at Jan 5, 96 11:03:55 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1753 Apparently the list is alive again... > > To augment my previous message: > > My theory of SACK is that the only good numbers for SACK slots are "1" > and "infinity"; I never liked or trusted the number "3". Your scheme > has shown a way to make things work pretty well (for some value of > "pretty" {?)) with only one SACK slot. Therefore, you should > be not be disturbed that other uses of the option space reduce the > number of allowed SACK slots to 2 or even 1, right? > > Bob About last month I proposed to this list a more compact encoding of SACKs, which should work reasonably well even with limited option space. So the problem of '1' vs. 'some' SACKs should not be an issue. What is new in this Internet draft is the concept that very few SACKs suffice in avoiding deadlocks (which is essentially what happens when we have to wait the expiration of a timeout to restart). I am reading carefully the RFC draft and the referenced papers (btw, [Floyd96] "Issues of TCP with SACK" is missing on the server as of this morning) to understand how this is proved. I am curious to see if the assumption is true even with the large loss rates (30% and more) that we (from some sites in Italy and Europe) are experiencing on overseas connections. [Fall95] seems to deal with a completely different setting, so the results may or may not apply. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA28907 for tcplw-list@sdiv; Fri, 5 Jan 1996 13:31:21 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA28902 for ; Fri, 5 Jan 1996 13:31:19 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA19902 for ; Fri, 5 Jan 1996 13:31:19 -0600 Received: from mailer.psc.edu (mailer.psc.edu [128.182.62.100]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id NAA20416 for ; Fri, 5 Jan 1996 13:31:17 -0600 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA12271; Fri, 5 Jan 1996 14:31:06 -0500 Message-Id: <9601051931.AA12271@mailer.psc.edu> To: braden@isi.edu (Bob Braden) Cc: mathis@zippy.psc.edu, tcplw@cray.com Subject: Re: internet-draft for SACK In-Reply-To: Your message of "Fri, 05 Jan 1996 10:41:26 PST." <199601051841.AA22653@zephyr.isi.edu> Date: Fri, 05 Jan 1996 14:31:03 -0500 From: "Matt Mathis" >I think timestamps are always a good idea. (Van tells me so :-)). Yes, once TCP is using timestamps for RTT estimation as well as well as PAWS, it would be kind of strange to keep the old code for T/TCP. However this reminds me of an interesting situation that somebody encountered here. I haven't fully diagnosed it and I am not %100 sure that this is not just an implementation bug: We have observed that some new systems attempt to do MTU discovery and large window TCP on ALL connections by default. These systems interact very badly with VJ compressed slip. In particular the presence of TCP options suppresses the compression (actually in at least one case breaks it outright but this is clearly an implementation bug). Furthermore there does not seem to be a way for existing TCPs to decide not to use timestamps once they have been started, even after it has been discovered that the maximum cwnd is only a few kB. As a result telnet keystrokes require a whopping 53 bytes + framing each (Please, no ATM or IPv6 digression.) Perhaps PAWS shouldn't be turned on until cwnd reaches some threshold? Perhaps there should be a way to stop timestamps when they are not useful? >Therefore, you should >be not be disturbed that other uses of the option space reduce the >number of allowed SACK slots to 2 or even 1, right? Yes, and the text should make this point clearer, possibly citing T/TCP as an example. Thanks, --MM-- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA26095 for tcplw-list@sdiv; Fri, 5 Jan 1996 13:05:35 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA26090 for ; Fri, 5 Jan 1996 13:05:34 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA17871 for ; Fri, 5 Jan 1996 13:05:33 -0600 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id NAA15118 for ; Fri, 5 Jan 1996 13:05:32 -0600 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Fri, 5 Jan 1996 11:04:14 -0800 Date: Fri, 5 Jan 1996 11:04:14 -0800 From: braden@isi.edu (Bob Braden) Message-Id: <199601051904.AA23618@zephyr.isi.edu> To: mathis@zippy.psc.edu, braden@isi.edu Subject: Re: internet-draft for SACK Cc: tcplw@cray.com To augment my previous message: My theory of SACK is that the only good numbers for SACK slots are "1" and "infinity"; I never liked or trusted the number "3". Your scheme has shown a way to make things work pretty well (for some value of "pretty" {?)) with only one SACK slot. Therefore, you should be not be disturbed that other uses of the option space reduce the number of allowed SACK slots to 2 or even 1, right? Bob Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id MAA23945 for tcplw-list@sdiv; Fri, 5 Jan 1996 12:42:46 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id MAA23940 for ; Fri, 5 Jan 1996 12:42:45 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id MAA15927 for ; Fri, 5 Jan 1996 12:42:44 -0600 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id MAA10418 for ; Fri, 5 Jan 1996 12:42:43 -0600 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Fri, 5 Jan 1996 10:41:26 -0800 Date: Fri, 5 Jan 1996 10:41:26 -0800 From: braden@isi.edu (Bob Braden) Message-Id: <199601051841.AA22653@zephyr.isi.edu> To: mathis@zippy.psc.edu Subject: Re: internet-draft for SACK Cc: tcplw@cray.com *> From tcplw-relay@cray.com Fri Jan 5 10:38:16 1996 *> To: Andras Olah *> Cc: tcplw@cray.com *> Subject: Re: internet-draft for SACK *> In-Reply-To: Your message of "Fri, 05 Jan 1996 09:28:05 +0100." *> <20916.820830485@curie.cs.utwente.nl> *> Date: Fri, 05 Jan 1996 13:34:21 -0500 *> From: "Matt Mathis" *> Content-Length: 229 *> X-Lines: 8 *> *> Interesting point. *> *> Do you see people using a large window version of T/TCP? *> *> Normally I'd expect not to be using the timestamp options while doing *> transactions. How plausable are situations where both might be needed? *> *> --MM-- *> Matt, I think timestamps are always a good idea. (Van tells me so :-)). The essential feature of T/TCP is that it allows a "transaction" of arbitrary size, making a smooth transition from optimal single-packet exchanges to normal TCP streaming behavior. That means you always want to include a timestamp, I think. Bob Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id MAA23085 for tcplw-list@sdiv; Fri, 5 Jan 1996 12:34:31 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id MAA23082 for ; Fri, 5 Jan 1996 12:34:30 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id MAA15292 for ; Fri, 5 Jan 1996 12:34:30 -0600 Received: from mailer.psc.edu (mailer.psc.edu [128.182.62.100]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id MAA08806 for ; Fri, 5 Jan 1996 12:34:27 -0600 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA10923; Fri, 5 Jan 1996 13:34:23 -0500 Message-Id: <9601051834.AA10923@mailer.psc.edu> To: Andras Olah Cc: tcplw@cray.com Subject: Re: internet-draft for SACK In-Reply-To: Your message of "Fri, 05 Jan 1996 09:28:05 +0100." <20916.820830485@curie.cs.utwente.nl> Date: Fri, 05 Jan 1996 13:34:21 -0500 From: "Matt Mathis" Interesting point. Do you see people using a large window version of T/TCP? Normally I'd expect not to be using the timestamp options while doing transactions. How plausable are situations where both might be needed? --MM-- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id CAA06035 for tcplw-list@sdiv; Fri, 5 Jan 1996 02:28:16 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id CAA06031 for ; Fri, 5 Jan 1996 02:28:15 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id CAA22696 for ; Fri, 5 Jan 1996 02:28:14 -0600 Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id CAA05821 for ; Fri, 5 Jan 1996 02:28:12 -0600 Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelayMX-SVR4_1.2/RBINF) id JAA27054; Fri, 5 Jan 1996 09:28:09 +0100 Received: from curie.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id JAA27309; Fri, 5 Jan 1996 09:28:05 +0100 Received: from localhost by curie.cs.utwente.nl (SMI-8.6/SMI-SVR4) id JAA20917; Fri, 5 Jan 1996 09:28:06 +0100 To: tcplw@cray.com Subject: Re: internet-draft for SACK In-reply-to: Your message of "Thu, 04 Jan 1996 15:57:58 PST." <9601042357.AA00451@offshore.eng.sun.com> Date: Fri, 05 Jan 1996 09:28:05 +0100 Message-ID: <20916.820830485@curie.cs.utwente.nl> From: Andras Olah On Thu, 04 Jan 1996 15:57:58 PST, Allyn Romanow wrote: > A SACK option that specifies n blocks will have a length of > 8*n+2 bytes, so the 40 bytes available for TCP options can > specify a maximum of 4 blocks. It is expected that SACK will > often be used in conjunction with the Timestamp option used for > RTTM [Jacobson92], which takes an additional 10 bytes (plus two > bytes of padding); thus a maximum of 3 SACK blocks will be > allowed in this case. I've got only a minor comment related to the use of options. In my opinion the possible presence of T/TCP should be considered in the cited paragraph. T/TCP [RFC1644] also uses options on non-SYN segments, 8 bytes with padding for alignment. Thus there's only 20 bytes left for SACK in this case. Although RFC1644 is an experimental RFC, I've heard from Rich Stevens that he's working on to put T/TCP onto the standards track and there are at least three implementations of T/TCP. Andras Olah Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id SAA07912 for tcplw-list@sdiv; Thu, 4 Jan 1996 18:01:50 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id SAA07907 for ; Thu, 4 Jan 1996 18:01:49 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id SAA07762 for ; Thu, 4 Jan 1996 18:01:48 -0600 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id SAA26232 for ; Thu, 4 Jan 1996 18:01:47 -0600 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id QAA27780; Thu, 4 Jan 1996 16:00:45 -0800 Received: from caribe.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA19561; Thu, 4 Jan 1996 16:00:40 -0800 Received: from offshore.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA29856; Thu, 4 Jan 1996 16:00:08 -0800 Received: by offshore.eng.sun.com (5.x/SMI-SVR4) id AA00451; Thu, 4 Jan 1996 15:57:58 -0800 Date: Thu, 4 Jan 1996 15:57:58 -0800 From: allyn@caribe-86.Eng.Sun.COM (Allyn Romanow) Message-Id: <9601042357.AA00451@offshore.eng.sun.com> To: tcplw@cray.com Subject: internet-draft for SACK X-Sun-Charset: US-ASCII Here is a first version of a proposed internet-draft on the TCP Selective Acknowledgement Options. Adding SACK (selective acknowledgement) to TCP was discussed at both the TCP Short-Term Problems BOF and at the Open Transport Area Directorate Meeting at the Dallas IETF. We are sending this early version to the mailing list for feedback. Our intention is to submit it as an internet-draft fairly soon, to produce reference implementations, and to consider the status at a BOF at the next IETF. Our goal is to move this to RFC status as quickly as possible. This document is also available from ftp://ftp.ee.lbl.gov/papers/sackIDv1.0.txt. - Allyn and Sally INTERNET-DRAFT TCP Selective Acknowledgement Option Matthew B. Mathis Mathis@psc.edu Jamshid Mahdavi Mahdavi@psc.edu Sally Floyd floyd@ee.lbl.gov Allyn Romanow allyn@eng.sun.com Version: 1.0, Thu Jan 4 14:48:16 PST 1996 This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgements, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received. A Selective Acknowledgement (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments. This draft proposes an implementation of SACK and discusses its performance and related issues. Acknowledgements: Much of the text in this document is taken directly from RFC1072 ``TCP Extensions for Long-Delay Paths'' by Bob Braden and Van Jacobson. The authors would like to thank Kevin Fall (LBNL), Christian Huitema (Inria), Van Jacobson (LBNL), Greg Minshall (Ipsilon), and Lixia Zhang (XEROX PARC and UCLA) for their review and constructive comments. 1. Introduction Multiple packet losses from a window of data can have a catastrophic effect on TCP throughput. TCP [Postel81] uses a cumulative acknowledgment scheme in which received segments that are not at the left edge of the receive window are not acknowledged. This forces the sender to either wait a roundtrip time to find out about each lost packet, or to unnecessarily retransmit segments which have been correctly received [Fall95]. With the cumulative acknowledgment scheme, multiple dropped segments generally cause TCP to lose its ACK-based clock, reducing overall throughput. Selective Acknowledgment (SACK) is a strategy which corrects this behavior and restores full throughput in the face of multiple dropped segments. With selective acknowledgments, the data receiver can inform the sender about all segments that have arrived successfully, so the sender need retransmit only the segments that have actually been lost. Several transport protocols, including NETBLT [Clark87], XTP [Strayer92], RDP [Velten84], NADIR [Huitema81], and VMTP [Cheriton88] have used selective acknowledgement. There is some empirical evidence in favor of selective acknowledgments -- simple experiments with RDP have shown that disabling the selective acknowledgment facility greatly increases the number of retransmitted segments over a lossy, high-delay Internet path [Partridge87]. A recent simulation study by Kevin Fall and Sally Floyd [Fall95], demonstrates the strength of TCP with SACK over the non-SACK Tahoe and Reno TCP implementations. RFC1072 [VJ88] describes one possible implementation of SACK options for TCP. Unfortunately, it has never been deployed in the Internet, as there was disagreement about how SACK options should be used in conjunction with the TCP window shift option (initially described RFC1072 and revised in Jacobson92). We propose slight modifications to the SACK options as proposed in RFC1072. Specifically, sending a selective acknowledgment for the most recently received data reduces the need for long SACK options [Keshav94, Mathis95]. In addition, sequence numbers are now 32 bits. These two modifications represent the only changes to the proposal in RFC1072. They make SACK easier to implement and address concerns about robustness. The selective acknowledgment extension uses two TCP options. The first is an enabling option, "SACK-permitted", which may be sent in a SYN segment to indicate that the SACK option can be used once the connection is established. The other is the SACK option itself, which may be sent over an established connection once permission has been given by SACK-permitted. The SACK option is to be included in a segment sent from a TCP that is receiving data to the TCP that is sending that data; we will refer to these TCP's as the data receiver and the data sender, respectively. We will consider a particular simplex data flow; any data flowing in the reverse direction over the same connection can be treated independently. 2. SACK-Permitted Option This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) the SACK option once the connection has opened. TCP Sack-Permitted Option: Kind: 4 +---------+---------+ | Kind=4 | Length=2| +---------+---------+ [We need to formally decide (in the BOF?) if we are going to reuse option numbers.] 3. SACK Option Format The SACK option is to be used to convey extended acknowledgment information from the receiver to the sender over an established TCP connection. TCP SACK Option: Kind: 5 Length: Variable +--------+--------+ | Kind=5 | Length | +--------+--------+--------+--------+ | Left Edge of 1st Block | +--------+--------+--------+--------+ | Right Edge of 1st Block | +--------+--------+--------+--------+ | | / . . . / | | +--------+--------+--------+--------+ | Left Edge of nth Block | +--------+--------+--------+--------+ | Right Edge of nth Block | +--------+--------+--------+--------+ The SACK option is to be sent by a data receiver to inform the data sender of non-contiguous blocks of data that have been received and queued. The data receiver awaits the receipt of data (perhaps by means of retransmissions) to fill the gaps in sequence space between received blocks. When missing segments are received, the data receiver acknowledges the data normally by advancing the left window edge in the Acknowledgment Number field of the TCP header. The SACK option does not change the meaning of the Acknowledgment Number field, whose value will still specify the left window edge, i.e., one byte beyond the last sequence number of fully-received data. The SACK option provides additional information which the data transmitter can use to optimize retransmissions. The TCP data receiver includes the SACK option in an acknowledgment segment whenever it has data that is queued and unacknowledged. The SACK option may be sent only when the TCP has received the SACK-permitted option in the SYN segment for that connection. This option contains a list of some of the blocks of contiguous sequence space occupied by data that has been received and queued within the window. Each contiguous block of data queued at the data receiver is defined in the SACK option by two 32-bit unsigned integers in network byte order: * Left Edge of Block This is the first sequence number of this block. * Right Edge of Block This is the sequence number immediately following the last sequence number of this block. Each block represents received bytes of data that are contiguous and isolated; that is, the bytes just below the block, (Left Edge of Block - 1), and just above the block, (Right Edge of Block), have not been received. A SACK option that specifies n blocks will have a length of 8*n+2 bytes, so the 40 bytes available for TCP options can specify a maximum of 4 blocks. It is expected that SACK will often be used in conjunction with the Timestamp option used for RTTM [Jacobson92], which takes an additional 10 bytes (plus two bytes of padding); thus a maximum of 3 SACK blocks will be allowed in this case. The SACK option is advisory, in that, while it notifies the data sender that the data receiver has received the indicated segments, the data receiver is permitted to later discard data which have been reported in a SACK option. A detailed discussion of the advisory nature of the SACK option appears below, following the discussion of the normal case. 4. Generating SACK Options: Data Receiver Behavior If the data receiver has received a SACK-Permitted option on the SYN for this connection, the data receiver MAY elect to generate SACK options as described below. If the data receiver generates SACK options under any circumstance, it SHOULD generate them under all permitted circumstances. If the data receiver has not received a SACK-Permitted option for a given connection, it MUST NOT send SACK options on that connection. If sent at all, SACK options SHOULD be included in all ACKs which do not ACK the highest sequence number in the data receiver's queue. In this situation the network has lost or mis-ordered data, such that the receiver holds non-contiguous data in its queue. RFC 1122, Section 4.2.2.21, discusses the reasons for the receiver to send ACKs in response to additional segments received in this state. The receiver SHOULD send an ACK for every valid segment that arrives containing new data, and each of these "duplicate" ACKs SHOULD bear a SACK option. If the data receiver chooses to send a SACK option, the following rules apply: * The first SACK block (i.e., the one immediately following the kind and length fields in the option) MUST specify the contiguous block of data containing the segment which triggered this ACK, unless that segment advanced the Acknowledgment Number field in the header. This assures that the ACK with the SACK option reflects the most recent state change at the data receiver. * The data receiver SHOULD include as many distinct SACK blocks as possible in the SACK option. Note that the maximum available option space may not be sufficient to report all blocks present in the receiver's queue. * The SACK option SHOULD be filled out by repeating the most recently reported SACK blocks (based on first SACK blocks in previous SACK options) that are not subsets of a SACK block already included in the SACK option being constructed. This assures that in normal operation every SACK block is repeated several times. (At least three times for large-window TCP implementations [RFC1323]). It is very important that the SACK option always reports the block containing the most recently received segment, because this provides the sender with the most up-to-date information about the state of the network and the data receiver's queue. 5. Interpreting the SACK Option and Retransmission Strategy: Data Sender Behavior When receiving an ACK containing a SACK option, the data sender SHOULD record the selective acknowledgement for future reference. The data sender is assumed to have a retransmission queue that contains the segments that have been transmitted but not yet acknowledged, in sequence-number order. If the data sender performs re-packetization before retransmission, the block boundaries in a SACK option that it receives may not fall on boundaries of segments in the retransmission queue; however, this does not pose a serious difficulty for the sender. One possible implementation of the sender's behavior is as follows. Let us suppose that for each segment in the retransmission queue there is a (new) flag bit "RESEND", to be used to indicate that this particular segment is on the list to be retransmitted. When a segment is first transmitted, it will be entered into the retransmission queue with its RESEND bit off. When an acknowledgment segment arrives containing a SACK option, the data sender will turn on the ACK'd bits for segments that have been selectively acknowledged. More specifically, for each block in the SACK option, the data sender will turn on the ACK'ed flags for all segments in the retransmission queue that are wholly contained within that block. This requires straightforward sequence number comparisons. After the ACKed bit is turned on (as the result of processing a received SACK option), the data sender will skip that segment during any later retransmission. Any segment that has the ACKed bit turned off and is less than the highest ACKed segment is available for retransmission. However, after a retransmit timeout all of the ACKed bits are turned off. A segment will not be dequeued and its buffer freed until the left window edge is advanced over it. 5.1 Congestion Control Issues This document does not attempt to specify in detail the congestion control algorithms for implementations of TCP with SACK. However, the congestion control algorithms present in the de facto standard TCP implementations MUST be preserved [Stevens94]. In particular, to preserve robustness in the presence of packets reordered by the network, recovery is not triggered by a single ACK reporting out-of-order packets at the receiver. Further, during recovery the data sender limits the number of segments sent in response to each ACK. Existing implementations limit the data sender to sending one segment during Reno-style fast recovery, or to two segments during slow-start [Jacobson88]. Other aspects of congestion control, such as reducing the congestion window in response to congestion, must similarly be preserved. The use of time-outs as a fall-back mechanism for detecting dropped packets is unchanged by the SACK option. Because the data receiver is allowed to discard SACKed data, when a retransmit timeout occurs the data sender MUST ignore prior SACK information in determining which data to retransmit. Future research into congestion control algorithms may take advantage of the additional information provided by SACK. One such area for future research concerns modifications to TCP for a wireless or satellite environment where packet loss is not necessarily an indication of congestion. 6. Efficiency and Worst Case Behavior If the return path carrying ACKs and SACK options were lossless, one block per SACK option packet would always be sufficient. Every segment arriving while the data receiver holds discontinuous data would cause the data receiver to send an ACK with a SACK option containing the one altered block in the receiver's queue. The data sender is thus able to construct a precise replica of the receiver's queue by taking the union of all the first SACK blocks. However, since the return path is not lossless, the SACK option is defined to include more than one SACK block in a single packet. The redundant blocks in the SACK option packet increase the robustness of SACK delivery in the presence of lost ACKs. For a receiver that is also using the time stamp option [Jacobson92], the SACK option has room to include three SACK blocks. Thus each SACK block will generally be repeated at least three times, in three successive ACK packets. However, if all of the ACK packets reporting a particular SACK block are dropped, then the sender might assume that the data in that SACK block has not been received, and unnecessarily retransmit those segments. The worst-case conditions necessary for the sender to needlessly retransmit data is discussed in more detail in a separate document [Floyd96]. As is shown in that paper, the exposure of TCP with SACK in regard to the unnecessary retransmission of packets is strictly less than the exposure of current implementations of TCP. In current implementations of TCP, the sender can unnecessarily retransmit packets whenever multiple packets dropped from a single window of data are followed by a slow-start. In contrast, as is shown in [Floyd96], the simplest condition that can cause duplicated (needlessly retransmitted) data sent to the receiver for TCP with SACK requires a sender congestion size of 11 packets and a precise (and therefore rather improbable) sequence of 4 lost data packets and 3 lost ACKs for that window of data. 7. SACK Option Examples The follow examples attempt to demonstrate the proper behavior of SACK generation by the data receiver. Assume the left window edge is 5000 and that the data transmitter sends a burst of 8 segments, each containing 500 data bytes. Case 1: The first 4 segments are received but the last 4 are dropped. The data receiver will return a normal TCP ACK segment acknowledging sequence number 7000, with no SACK option. Case 2: The first segment is dropped but the remaining 7 are received. Upon receiving each of the last seven packets, the data receiver will return a TCP ACK segment that acknowledges sequence number 5000 and contains a SACK option specifying one block of queued data: Triggering ACK Left Edge Right Edge Segment 5000 (lost) 5500 5000 5500 6000 6000 5000 5500 6500 6500 5000 5500 7000 7000 5000 5500 7500 7500 5000 5500 8000 8000 5000 5500 8500 8500 5000 5500 9000 Case 3: The 2nd, 4th, 6th, and 8th (last) segments are dropped. The data receiver ACKs the first packet normally. The third, fifth, and seventh packets trigger SACK options as follows: Triggering ACK First Block 2nd Block 3rd Block Segment Left Right Left Right Left Right Edge Edge Edge Edge Edge Edge 5000 5500 5500 (lost) 6000 5500 6000 6500 6500 (lost) 7000 5500 7000 7500 6000 6500 7500 (lost) 8000 5500 8000 8500 7000 7500 6000 6500 8500 (lost) Suppose at this point, the 4th packet is received out of order. (This could either be because the data was badly misordered in the network, or because the 2nd packet was retransmitted and lost). At this point the data receiver has only two SACK blocks to report. The data receiver replies with the following Selective Acknowledgement: Triggering ACK First Block 2nd Block 3rd Block Segment Left Right Left Right Left Right Edge Edge Edge Edge Edge Edge 6500 5500 6000 7500 8000 8500 Suppose at this point, the 2nd segment is received. The data receiver then replies with the following Selective Acknowledgement: Triggering ACK First Block 2nd Block 3rd Block Segment Left Right Left Right Left Right Edge Edge Edge Edge Edge Edge 5500 7500 8000 8500 8. Data Receiver Reneging Note that the data receiver is permitted to discard data in its queue that has not been acknowledged to the data sender, even if the data has already been reported in a SACK option. Such discarding of SACKed packets is discouraged, but may be used if the receiver runs out of buffer space. The data receiver MAY elect not to keep data which it has reported in a SACK option. In this case, the receiver SACK generation is additionally qualified: * The first SACK block MUST reflect the newest segment. Even if the newest segment is going to be discarded and the receiver has already discarded adjacent segments, the first SACK block MUST report, at a minimum, the left and right edges of the newest segment. * Except for the newest segment, all SACK blocks MUST NOT report any old data which is no longer actually held by the receiver. Since the data receiver may later discard data reported in a SACK option, the sender MUST NOT discard data before it is acknowledged by the Acknowledgment Number field in the TCP header. 9. Security Considerations: This document neither strengthens nor weakens TCP's current security properties. 10. Support Matt Mathis and Jamshid Mahdavi are supported by the National Science Foundation Grant No. NCR-9415552. Sally Floyd is supported by the Director, Office of Energy Research, Scientific Computing Staff, of the U.S. Department of Energy under Contract No. DE-AC03-76F00098. Allyn Romanow is supported by Sun Microsystems. 11. REFERENCES [Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, Stanford University, February 1988. [Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT, March 1987. [Fall95] Fall, K. and Floyd, S., "Comparisons of Tahoe, Reno, and Sack TCP", ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z, December 1995. [Floyd96] Floyd, S., "Issues of TCP with SACK", ftp://ftp.ee.lbl.gov/papers/issues_sa.ps.Z, January 1996. [Huitema81] Huitema, C., and Valet, I., An Experiment on High Speed File Transfer using Satellite Links, 7th Data Communication Symposium, Mexico, October 1981. [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", to be presented at SIGCOMM '88, Stanford, CA., August 1988. [Jacobson92] Jacobson, V., Braden, R., and Borman, D., TCP Extensions for High Performance, RFC 1323, May 1992. [Keshav94] Keshav, presentation to the Internet End-to-End Research Group, November 1994. [Mathis95] Mathis, M., and Mahdavi, J., TCP Forward Acknowledgement Option, presentation to the Internet End-to-End Research Group, June 1995. [Partridge87] Partridge, C., "Private Communication", February 1987. [Postel81] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994. [Strayer92] Strayer, T., Dempsey, B., and Weaver, A., XTP -- the xpress transfer protocol. Addison-Wesley Publishing Company, 1992. [Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data Protocol", RFC 908, BBN, July 1984. Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA13055 for tcplw-list@sdiv; Mon, 18 Dec 1995 13:30:15 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA13045 for ; Mon, 18 Dec 1995 13:30:14 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA02278 for ; Mon, 18 Dec 1995 13:30:12 -0600 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id NAA07479 for ; Mon, 18 Dec 1995 13:30:04 -0600 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA03062; Mon, 18 Dec 1995 20:27:05 +0100 From: Luigi Rizzo Message-Id: <199512181927.UAA03062@labinfo.iet.unipi.it> Subject: Selective Acknowledgements... (fwd) To: tcplw@cray.com Date: Mon, 18 Dec 1995 20:27:05 +0100 (MET) Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5585 Hi, Jamshid Mahdavi pointed me to this group where (among others) discussions on SACKs are being done. I have browsed in the archives of the "tcplw@cray.com" mailing list, and I believe I am not replicating anything. Thus I enclose my original posting (which was sent almost three weeks ago to comp.protocols.tcpip, slightly edited after browsing on the archives of the mailing list) and Jamshid suggestions. ----- A proposal for a compact encoding of selective acks ----- Date: Fri, 1 Dec 1995 14:02:03 +0100 (MET) From: Luigi Rizzo To: hackers@FreeBSD.ORG Subject: A proposal for selective acks [In the following I assume that the reader has read the section of RFC1072 dealing with selective ACKS (which is a nice reading, as most papers from Van Jacobson).] The proposal for SACKs by Van Jacobson [RFC1072] is very clear and detailed about a possible implementation, to the point that one wonders why they haven't been actually included in RFC1323 and implemented. A possible explaination is that the SACK option, as specified in RFC1072, might suffer from the limited amount of space available for TCP options. This only enables to selectively ack a limited number of out-of-sequence segments, thus reducing the effectiveness of the mechanism. The problem comes from the need of passing both the relative origin and the size of each segment, totalling 4 bytes [or more] per segment. However, consider the typical case in which SACKs would be useful, i.e. the transfer of large blocks of data. In these conditions, the sender should mostly send maximum-sized segments. Now look at the reassembly queue at the receiving station: starting from the first unacked byte, we have a sequence of holes (H) and segments (S), starting with a hole and ending with a segment, as below. HHH SSSS HH SS HH SS HHHH SSSS HH SSS What I expect to see (have not verified, though) is a sequence of Holes-Segments whose size is generally a multiple of the MSS in use for the connection. The only exceptions could possibly be first hole (because of some odd-length communication before the large block of data begins), and the last segment (which may contain less than an MSS because no more data are available). If the above is true, a SACK option could comprise the following fields: h1 the size of the first hole. The hole starts at the point indicated by the ACK field in the header. [alternatively, this could be the sequence number of the first segment in the reassembly queue] s1 the size of the last segment. ss the GCD of all the remaining blocks of segments/holes. This should usually represent the MSS in use. [Simple simulations showed that as the size of the string increases the chances of "ss" being larger than 1 segment becomes negligible] b[] a bitmap indicating which segments (of size ss) are present or not after the first hole lb the number of elements in the bitmap b[]. Actually, only 3 bits are needed for lb because the option length could be used to derive the size of b[] in bytes. Following the description of the SACK option in RFC1072, we could represent h1, s1, ss as 16-bit integers, and use 2 bytes for option kind+len. This would leave up to (40-8)=32 bytes for b[]+lb, i.e. room for over 250 segments. Even if some room is taken by other options (e.g. timestamps), there is still sufficient room to deal with large windows [20 bytes=160 segments]. Note that only ones in b[] are meaningful: these SACKs, as RFC1072 ones, are cumulative. Thus so the receiver can send multiple SACK with different values for h1, to deal with the following situations: * the send window is very large, and the bitmap is not large enough; * for some reason (the sender changes to a new MSS which is prime wrt the previous one; or the sender is sending very small segments, etc.) ss becomes very small. * there is a high loss rate even on SACKs, so we need to send several of them to be sure that at least one goes through. SACK segments are valuable in that can save a lot of traffic. * lots of segments arrive out of order, so we need to update the SACKs. As a matter of fact, h1 could be thought of as a "skip" field, thus it might be necessary to encode it with a larger number of bits, say 32. But this is not a real problem as the encoding of the SACKs is reasonably compact. Maybe the data in b[] can be compressed further, especially if the losses are not very large (in this case runs of '1' could be encoded efficiently, as in FAX documents). If the losses become large, though, I suspect that there is little chance for compression. ------------------- end of original message ----------------------- Jamshid Mahdavi suggests that the IETF is currently considering a new proposal for SACK, but the details that he supplied do not allow me to understand in which framework they are supposed to work. I started looking at the problem due to the bad connectivity problems we are having (losses in the 30-60% and more) with overseas connections, and would like a SACK mechanism that works even in this [somewhat depressing] scenario. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id RAA24884 for tcplw-list@sdiv; Mon, 20 Nov 1995 17:20:33 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id RAA24860; Mon, 20 Nov 1995 17:20:30 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id RAA15593; Mon, 20 Nov 1995 17:20:30 -0600 Received: from melon.jaist.ac.jp (melon.jaist.ac.jp [150.65.1.6]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id RAA05051; Mon, 20 Nov 1995 17:20:25 -0600 Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Tue, 21 Nov 1995 08:08:54 +0900 Received: from milkyway.ctr.columbia.edu (milkyway.ctr.columbia.edu [128.59.68.51]) by sirius.ctr.columbia.edu (8.7.1/8.6.4.287) with SMTP id SAA06860; Mon, 20 Nov 1995 18:08:43 -0500 (EST) From: aurel@ctr.columbia.edu (Aurel A. Lazar) Received: (aurel@localhost) by milkyway.ctr.columbia.edu (8.6.10/8.6.4.788743) id SAA05195; Mon, 20 Nov 1995 18:08:06 -0500 Date: Mon, 20 Nov 1995 18:08:06 -0500 Message-Id: <199511202308.SAA05195@milkyway.ctr.columbia.edu> To: nossdav96-announce@jaist.ac.jp Subject: xbind software available in alpha release Cc: aurel@ctr.columbia.edu I would like to let you know that the xbind software is available for experimental evaluation (alpha release). Currently, we have completed a prototype implementation of our open signalling architecture in our laboratory and are undergoing trials with other sites on NYNET, an ATM Network operating in New York State and Massachusetts. Our software runs on SunOS, Solaris and HP-UX as well as on the FORE ASX100/200 series of switches. Multimedia devices currently supported include Sunvideo and Parallax Graphics video cards, Sun Sparc, SGI and HP native audio devices. We have also implemented a prototype Video and CD quality Audio conferencing services as part of the current xbind release. Work is currently ongoing to port the system to the NEC 5 series ATM switches and to the AIX (DSOM) and Windows NT operating systems. All the information you need for downloading the software can be found in http://www.ctr.columbia.edu/comet/xbind/xbind.html. Aurel Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id NAA12267 for tcplw-list@sdiv; Mon, 20 Nov 1995 13:23:18 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id NAA12261; Mon, 20 Nov 1995 13:23:17 -0600 From: cbramwell@intellibyte.com Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id NAA04250; Mon, 20 Nov 1995 13:23:16 -0600 Received: from melon.jaist.ac.jp (melon.jaist.ac.jp [150.65.1.6]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id NAA18916; Mon, 20 Nov 1995 13:23:10 -0600 Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Tue, 21 Nov 1995 04:07:49 +0900 Received: from thegate.intellibyte.com (intellibyte.north.net [198.52.33.78]) by uunorth.north.net (8.6.11/8.6.9) with SMTP id PAA06573; Mon, 20 Nov 1995 15:02:23 -0500 Received: from cjblap by thegate.intellibyte.com id aa01259; 20 Nov 95 13:11 EST X-Mailer: SuperTCP for Windows Version 4.00 R2 (Mailer Version 1.02) Message-ID: <30B0D328-00000001@cjblap.intellibyte.com> Date: Mon, 20 Nov 1995 13:12:37 cst Subject: NOSDAV Mailing list To: nossdav96-announce@jaist.ac.jp Cc: tatsuo@jaist.ac.jp MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII To whom it may concern. I received your address from tdcl@spiderman.bu.edu I am currently on the distribution list for NOSSDAV. I would very much like to remain on the e-mailing list, however, my email address has changed from HINWOOD@oise.on.ca to: cbramwell@intellibyte.com Could you please either make the change on the distribution list, or tell me whom I should contact. Thanking you in advance for your attention to this detail. (Please acknowledge the receipt of this message) --------------------------------------------------------------------- from: cbramwell@intellibyte.com Cameron Bramwell Intellibyte Inc. 330 Bay Street, Suite 1600 Toronto, Ontario, Canada M5H 2S8 Voice 416-368-7817 Ex#28 FAX 416-368-4617 ----------------------------------------------------------------------- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id MAA27151 for tcplw-list@sdiv; Mon, 20 Nov 1995 12:01:01 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id MAA27144; Mon, 20 Nov 1995 12:01:00 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id MAA28820; Mon, 20 Nov 1995 12:00:59 -0600 Received: from melon.jaist.ac.jp (melon.jaist.ac.jp [150.65.1.6]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id MAA02974; Mon, 20 Nov 1995 12:00:53 -0600 Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Tue, 21 Nov 1995 02:44:52 +0900 Received: from eurecom.cica.fr by chenas.inria.fr (5.65c8d/92.02.29) via EUnet-France id AA27548; Mon, 20 Nov 1995 18:44:35 +0100 (MET) Received: from rosa.cica.fr by eurecom.cica.fr (4.1/SMI-4.0) id AA06910; Mon, 20 Nov 95 18:44:43 +0100 Message-Id: <9511201744.AA06910@eurecom.cica.fr> Organization: Eurecom, Sophia-Antipolis, France Date: Mon, 20 Nov 95 18:44:43 +0100 From: Biersack Ernst To: nossdav96-announce@jaist.ac.jp Subject: Call for Paper: Euromicro 1996 Cc: erbi@eurecom.fr 22nd Euromicro Conference Beyond 2000: Hardware and Software Design Strategies Prague September 2-5, 1996 Call for Papers Euromicro conferences have been established to bring together people from business, industry,research, government and academia who are interested in problems related to microelectronics and computing. The Euromicro 96 Conference will attract researchers in four major fields. Each field constitutes a separate track for specialists. Programme This year the conference contains a new track - Telecommunications and Multimedia. The introduction of this track reflects the growing interest and importance of the subject.The Conference will have two main activities: Keynote speeches by outstanding experts Scientific and open forum sessions, which will report on significant developments in the tracks of the conference. Social events will be organized, offering opportunities to meet other delegates from all over the world. Scope Authors are invited to submit original contributions as full papers or extended summaries on recent applications, developments and research associated with microelectronics, computer hardware and software. Where experimental results have not been obtained in full, this must be stated and, if accepted, up-to-date results must be included in the final version of the paper. Regular Papers Papers submitted to the Euromicro 96 Conference will be organized in the following four tracks. 1. Computer Architecture and Design Automation Track coordinator: Anna Antola, Italy Topics: Processor architectures Instruction sets Memory architectures Co-processors and arithmetic devices ASIC and custom ICs DSP and computer vision architectures Microsystems technologies and architectures Timing analysis and performance evaluation Fault tolerant systems HW description languages and formal methods HW/SW codesign High level synthesis Estimation and evaluation techniques Fault modelling and testing Design for testability 2. Software Engineering Track coordinator: Konrad Kloeckner, Germany Topics: Requirements capture and analysis Formal specification and design Database systems and techniques Knowledge based systems Information storage and retrieval Prototyping systems Automated software development Methodologies for large scale software development Software testing and debugging Software reuse Real-time systems Quality control Software metrics Validation and verification 3. High Performance Computing Track coordinator: Stephen Winter, UK Topics: Formal models of parallelism Distributed operating systems Massively parallel systems Multiprocessors Parallel and distributed architectures Performance engineering Load balancing strategies Parallel application modelling Parallel cooperation models Parallel discrete-event simulation Parallel Software engineering Fault tolerance Performance modelling and evaluation Tools and techniques for parallel systems development Parallel neural networks 4. Multimedia and Telecommunications Track coordinator: Isabelle Demeure, France Topics: Network and operating system support for multimedia applications Capture and management of audio and visual information Storage technologies and techniques for multimedia applications Protocols for high speed networks Formal specification of protocols Multimedia architectures Formal specification of multimedia applications Specification and management of QoS constraints Multimedia services Network and service management Paradigms and tools for multimedia applications Applications (teleworking, teleconferencing, groupware, interactive television, video-on-demand, world wide web) Short Contributions In addition to regular papers, Euromicro 96 will feature short contribution, dedicated to: Brief up-to-date reports on ongoing research projects.Innovative applications in the fields of microelectronics and computer technology, including information systems, signal processing, communications and control systems.Technical reports from industry on new products, featuring breakthroughs or relevant technology in the area.Technical progress and final reports.It is the intention that short contribution papers will be scheduled in each of the main conference sessions. Submission of regular papers Authors should submit six copies of a full paper or an extended summary to the Programme Chairperson before January 31st, 1996. They will be notified of acceptance by March 31st, 1996. Final version of papers in camera-ready forms must be received by May 15th, 1996.A submission should be accompanied by a covering front sheet containing the author name(s), affiliations(s), mailing and e-mail addresses, phone and fax numbers, Conference track and topic to which it is addressed, and up to six keywords. A brief statement emphasising those points which make the paper different from work published earlier, or elsewhere, will assist the referees in making their decisions. In order that anonymous reviewing can be carried out, the paper and its title page should not contain the name(s) of the author(s) or their affiliation(s). The six copies of the submitted paper should be accompanied by the following signed statement: Neither this paper nor any version close to it has been or is being offered elsewhere for publication. If accepted, the paper will be made available in camera-ready forms by May 15th, 1996, and it will be personally presented at the Euromicro 96 Conference by the author or one of the co-authors. The Conference proceedings will be published by IEEE/CS and will be available for the Conference. Papers exceeding 8 pages will be charged Dfl. 100,-- per page in excess. Submission of short contributions Authors should submit four copies of a full paper or an extended summary to the Short Contribution Chairperson before May 31st, 1996. They will be notified of acceptance by July 14th, 1996. A submission should be limited to 10 pages (for a full paper) and to 3 pages (for an extended summary). It should be accompanied by a covering front sheet containing the author name(s), affiliation(s), mailing address, e-mail address, telephone and fax numbers, and up to three keywords. A brief statement emphasizing those points which make the contribution different from work published earlier, or elsewhere, will assist the referees in making their decisions.In order that anonymous reviewing can be carried out, the contri bution and its title page should not contain the name(s) of the author(s) or their affiliation(s).The four copies of the submitted contribution should be accompanied by the following signed statement: If accepted, this short contribution will be made available in its final format at the Euromicro 96 Conference, and will be personally presented at the Euromicro 96 Conference by the author or one of the co-authors.Accepted contributions, personally presented at the conference by the author or one of the co-authors, will be published in the Euromicro Journal, as extended summary or full paper depending on their final quality. Programme Committee Peter Milligan, United Kingdom (Chairman) K. Kuchcinski, Sweden (Deputy Chairman) A. Antola, Italy E. Biersack, France Z. Blazek, Czech Republic B. Chapman, Austria G. Ciccarella, Italy G. Chroust, Austria I. Demeure, France F. Distante, Italy I. Erenyi, Hungary K. Fazekas, Hungary E. Fernandes, Brazil K. Grosspietsch, Germany A. Gonzalez, Spain K. Judmann, Austria P. Kacsuk, Hungary J. Karjalainen, Finland K. Kloeckner, Germany K. Kock, Germany G. Leon, Spain E. Luque, Spain L. Mezzalira, Italy J. Molgaard, Denmark A. Nunez, Spain P. Paolini, Italy A. Pawlak, Germany M. Perkowski, USA E. Pissaloux, France A. Postula, Australia E. von Puttkamer, Germany B. Robic, Slovenia J. Rugelj, Slovenia C. Ruland, Germany P. Sage, United Kingdom M. Sami, Italy N. Scarabottolo, Italy H. Schumny, Germany R. Stefanelli, Italy J-B. Stefani, France M. Taylor, United Kingdom J. Tiberghien, Belgium F. Tirado, Spain S. Tohme, France A. Tyrrell, United Kingdom F. Vajda, Hungary M. Valero, Spain K. Waldschmidt, Germany S. Winter, United Kingdom E. Zapata, Spain H. Zima, Austria Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id AAA16842 for tcplw-list@sdiv; Mon, 20 Nov 1995 00:23:49 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id AAA16830; Mon, 20 Nov 1995 00:23:40 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/craymail-smart) with ESMTP id AAA10722; Mon, 20 Nov 1995 00:23:40 -0600 Received: from melon.jaist.ac.jp (melon.jaist.ac.jp [150.65.1.6]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id AAA08518; Mon, 20 Nov 1995 00:23:19 -0600 Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Mon, 20 Nov 1995 14:07:53 +0900 Message-Id: <199511200507.OAA15032@melon.jaist.ac.jp> To: nossdav96-announce@jaist.ac.jp Subject: Call for Paper: NOSSDAV'96 Date: Mon, 20 Nov 1995 14:07:50 JST From: Tatsuo Nakajima The following is a Call for Papers for NOSSDAV'96(International Workshop on Network and Operating Systems Support for Digital Audio and Video). Please distribute it as widely as possible to your colleagues and encourage them to submit papers by the deadline (Jan 5, 1996). More detailed information can be available from http://www.sfc.wide.ad.jp/nossdav96/ Tatsuo Nakajima, Publicity Chair NOSSDAV'96. Japan Advanced Institute of Science and Technology --------------------------------------------------- Call-for-Papers The 6th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 96) URL: http://www.sfc.wide.ad.jp/nossdav96/ April 23 - 26, 1996 Shonan Village International Conference Center, Zushi, Japan Objectives The 6th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 96) is the international workshop among active researchers and practitioners who are building innovative multimedia systems, networks and applications. While we will focus on the state of the art technology in networking and operating system support for multimedia systems, we will also seek for practitioners' papers from a variety of area, including media toolkit, mobile communications, VR, real-time systems, software agents, digital library, and distributed computing systems. It is also intended to provide extensive discussion periods during the workshop to discuss the important issues which may require future research. Relevant topics for the workshop include: High-speed/ATM networks Multimedia-oriented desk, local and wide area networks Workstation and PDA architectures for multimedia Multimedia network interfaces Cell-based system architectures Mobile systems for multimeida Communication protocols for multimedia Multicast protocols and media scaling Micro-kernel and OS support for real-time communications Resource management and reservation in the OS and network End-to-end admission control Quality of service and synchronization frameworks Multimedia storage, server, and I/O architectures Distributed multimedia systems APIs and CM programming abstractions for multimedia TV set-top device communication VOD system architecture Software agents for multimedia systems VR systems Submissions Two types of submissions are solicited: position papers and research papers. For the purpose of paper review, position papers are restricted to three single-spaced ASCII pages. Research papers are restricted to an extended abstract no longer than five formatted postscript pages. Papers should be electronically mailed to nossdav96@sfc.keio.ac.jp. Only if electronic submission is impossible, papers may be sent to the following e-mail address. Prof. Hideyuki Tokuda Keio University, 5322 Endoh, Fujisawa, Japan 252 Phone: +81-466-47-5000 (wait for 2 sec. then 3129) Fax: +81-466-47-0835 E-mail: hxt@sfc.keio.ac.jp The proceedings of the workshop will be published by Springer-Verlag and the best papers will be forwarded to selected journals for publication. Important Dates Submission Deadline 1/5/96 Acceptance Notification 2/12/96 Final Paper Due 3/18/96 Workshop: 4/23/96-4/26/96 Program Chair: Hideyuki Tokuda, Keio University/Carnegie Mellon University Program Committee: Domenico Ferrari, University of California, Berkeley Simon Gibbs, Univ. of Geneva, Switzerland Riccardo Gusella, HP Labs Ralf Herrtwich, IBM Creative Multimedia Studios Jung-kook Hong, IBM, Japan Andy Hopper, Olivetti & University of Cambridge Kevin Jeffay, University of North Carolina at Chapel Hill Jim Kurose, University of Massachusetts at Amherst Aurel Lazar, Columbia University T.D.C. Little, Boston University Derek McAuley, Cambridge University Duane Northcutt, Sun Microsystems Laboratories Guru Parulkar, Washington University Steve Pink, Swedish Institute of Computer Science Radu Popescu-Zeletin, GMD-FOKUS Ragunathan Rajkumar, Carnegie Mellon University P. Venkat Rangan, University of California, San Diego Jon Rosenberg, Bell Communications Research Doug Shepherd, Lancaster University Cormac Sreenan, AT&T Bell Laboratories Jean-Bernard Stefani, France Telecom/CNET Jay Strosnider, Carnegie Mellon University Daniel Swinehart, Xerox PARC Jon Walpole, Oregon Graduate Institute of Science & Technology Hiroshi Yasuda, NTT, Japan Publicity Chair Tatsuo Nakajima, JAIST, Japan Publishing Chair Shuich Oikawa, Keio University, Japan Local Arrangement Chair and Finance Chair Akira Nambu, NTT, Japan Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id KAA23397 for tcplw-list@sdiv; Fri, 3 Nov 1995 10:45:59 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id KAA23388 for ; Fri, 3 Nov 1995 10:45:58 -0600 From: braden@isi.edu Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id KAA27566 for ; Fri, 3 Nov 1995 10:45:57 -0600 Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id KAA05428 for ; Fri, 3 Nov 1995 10:45:56 -0600 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Fri, 3 Nov 1995 08:40:09 -0800 Date: Fri, 3 Nov 1995 08:42:13 -0800 Posted-Date: Fri, 3 Nov 1995 08:42:13 -0800 Message-Id: <199511031642.AA03649@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Nov 1995 08:42:13 -0800 To: tcplw@cray.com, broggi@verdi.eng.unipr.it Subject: Re: Final CFP: Real-Time Imaging J. *> From tcplw-request@cray.com Thu Nov 2 19:54:41 1995 *> Date: Fri, 3 Nov 95 04:49:15 +0100 *> From: broggi@verdi.eng.unipr.it (Alberto Broggi) *> To: tcplw@cray.com *> Subject: Final CFP: Real-Time Imaging J. *> Content-Length: 3953 *> X-Lines: 89 *> *> *> Dear colleague: *> this reminder has been automatically sent to different mailing *> lists; should you receive multiple copies of it, please excuse. *> Mr. Buoggi, Actually, there is *no* excuse for random and wanton distribution of notices to many irrelevant mailing lists. I deeply resent having to deal with this junk in my already bulging mailbox; it is the moral equivalent of the massive junk mail I receive through US mail each day. Your laziness in not figuring out how to target your mail is exceeded only by your bad Internet manners in sending automatically sending these messages. Does anyone have an email address for Academic Press? Perhaps we should tell THEM what we think... Bob Braden Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA09865 for tcplw-list@sdiv; Fri, 3 Nov 1995 09:44:30 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA09858 for ; Fri, 3 Nov 1995 09:44:29 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA24465 for ; Fri, 3 Nov 1995 09:44:28 -0600 Received: from snowball.ucd.ie (snowball.ucd.ie [137.43.4.78]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA20755 for ; Fri, 3 Nov 1995 09:44:23 -0600 Received: from cspc45.ucd.ie (cspc45.ucd.ie [137.43.4.86]) by snowball.ucd.ie (8.6.12/8.6.10) with SMTP id NAA31702; Fri, 3 Nov 1995 13:59:47 GMT Message-Id: <199511031359.NAA31702@snowball.ucd.ie> Comments: Authenticated sender is From: "Niall Downey" Organization: Dept. Computer Science, UCD, IRL. To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING" Date: Fri, 3 Nov 1995 12:52:09 +0000 Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE Reply-to: apatel@ccvax.ucd.ie CC: ahmed@net-cs.ucd.ie Priority: normal X-mailer: Pegasus Mail for Windows (v2.10) CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING ====================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA09788 for tcplw-list@sdiv; Fri, 3 Nov 1995 09:44:01 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA09784 for ; Fri, 3 Nov 1995 09:44:00 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA24447 for ; Fri, 3 Nov 1995 09:43:59 -0600 Received: from snowball.ucd.ie (snowball.ucd.ie [137.43.4.78]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA20689 for ; Fri, 3 Nov 1995 09:43:57 -0600 Received: from cspc45.ucd.ie (cspc45.ucd.ie [137.43.4.86]) by snowball.ucd.ie (8.6.12/8.6.10) with SMTP id OAA31744; Fri, 3 Nov 1995 14:03:25 GMT Message-Id: <199511031403.OAA31744@snowball.ucd.ie> Comments: Authenticated sender is From: "Niall Downey" Organization: Dept. Computer Science, UCD, IRL. To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING" Date: Fri, 3 Nov 1995 15:05:14 +0000 X-Total-Enclosures: 1 X-Enclosure-Info: DOS,"ap.txt",,,,Text Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE Reply-to: apatel@ccvax.ucd.ie Priority: normal X-mailer: Pegasus Mail for Windows (v2.10) CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING -------------- Enclosure number 1 ---------------- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA09718 for tcplw-list@sdiv; Fri, 3 Nov 1995 09:43:17 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA09714 for ; Fri, 3 Nov 1995 09:43:16 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA24437 for ; Fri, 3 Nov 1995 09:43:16 -0600 Received: from snowball.ucd.ie (snowball.ucd.ie [137.43.4.78]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA20472 for ; Fri, 3 Nov 1995 09:43:14 -0600 Received: from cspc45.ucd.ie (cspc45.ucd.ie [137.43.4.86]) by snowball.ucd.ie (8.6.12/8.6.10) with SMTP id OAA31720; Fri, 3 Nov 1995 14:01:50 GMT Message-Id: <199511031401.OAA31720@snowball.ucd.ie> Comments: Authenticated sender is From: "Niall Downey" Organization: Dept. Computer Science, UCD, IRL. To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING" Date: Fri, 3 Nov 1995 12:52:09 +0000 Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE Reply-to: apatel@ccvax.ucd.ie CC: ahmed@net-cs.ucd.ie Priority: normal X-mailer: Pegasus Mail for Windows (v2.10) CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING ====================================================================== Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA07064 for tcplw-list@sdiv; Fri, 3 Nov 1995 09:30:16 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA07049 for ; Fri, 3 Nov 1995 09:30:15 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA23813 for ; Fri, 3 Nov 1995 09:30:13 -0600 Received: from snowball.ucd.ie (snowball.ucd.ie [137.43.4.78]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA18063 for ; Fri, 3 Nov 1995 09:30:11 -0600 Received: from cspc45.ucd.ie (cspc45.ucd.ie [137.43.4.86]) by snowball.ucd.ie (8.6.12/8.6.10) with SMTP id OAA31731; Fri, 3 Nov 1995 14:02:04 GMT Message-Id: <199511031402.OAA31731@snowball.ucd.ie> Comments: Authenticated sender is From: "Niall Downey" Organization: Dept. Computer Science, UCD, IRL. To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING" Date: Fri, 3 Nov 1995 15:03:41 +0000 X-Total-Enclosures: 1 X-Enclosure-Info: DOS,"ap.txt",,,,Text Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE Reply-to: apatel@ccvax.ucd.ie Priority: normal X-mailer: Pegasus Mail for Windows (v2.10) CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING -------------- Enclosure number 1 ---------------- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA06321 for tcplw-list@sdiv; Fri, 3 Nov 1995 09:27:55 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA06309 for ; Fri, 3 Nov 1995 09:27:54 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA23717 for ; Fri, 3 Nov 1995 09:27:53 -0600 Received: from snowball.ucd.ie (snowball.ucd.ie [137.43.4.78]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA17429 for ; Fri, 3 Nov 1995 09:27:49 -0600 Received: from cspc45.ucd.ie (cspc45.ucd.ie [137.43.4.86]) by snowball.ucd.ie (8.6.12/8.6.10) with SMTP id OAA31765; Fri, 3 Nov 1995 14:04:08 GMT Message-Id: <199511031404.OAA31765@snowball.ucd.ie> Comments: Authenticated sender is From: "Niall Downey" Organization: Dept. Computer Science, UCD, IRL. To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING" Date: Fri, 3 Nov 1995 15:05:59 +0000 X-Total-Enclosures: 1 X-Enclosure-Info: DOS,"ap.txt",,,,Text Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE Reply-to: apatel@ccvax.ucd.ie Priority: normal X-mailer: Pegasus Mail for Windows (v2.10) CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING -------------- Enclosure number 1 ---------------- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA06205 for tcplw-list@sdiv; Fri, 3 Nov 1995 09:27:32 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA06200 for ; Fri, 3 Nov 1995 09:27:31 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA23693 for ; Fri, 3 Nov 1995 09:27:30 -0600 Received: from snowball.ucd.ie (snowball.ucd.ie [137.43.4.78]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA17381 for ; Fri, 3 Nov 1995 09:27:28 -0600 Received: from cspc45.ucd.ie (cspc45.ucd.ie [137.43.4.86]) by snowball.ucd.ie (8.6.12/8.6.10) with SMTP id OAA31749; Fri, 3 Nov 1995 14:03:32 GMT Message-Id: <199511031403.OAA31749@snowball.ucd.ie> Comments: Authenticated sender is From: "Niall Downey" Organization: Dept. Computer Science, UCD, IRL. To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING" Date: Fri, 3 Nov 1995 15:05:15 +0000 X-Total-Enclosures: 1 X-Enclosure-Info: DOS,"ap.txt",,,,Text Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE Reply-to: apatel@ccvax.ucd.ie Priority: normal X-mailer: Pegasus Mail for Windows (v2.10) CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING -------------- Enclosure number 1 ---------------- Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id JAA05629 for tcplw-list@sdiv; Fri, 3 Nov 1995 09:24:20 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id JAA05620 for ; Fri, 3 Nov 1995 09:24:19 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA23410 for ; Fri, 3 Nov 1995 09:24:17 -0600 Received: from snowball.ucd.ie (snowball.ucd.ie [137.43.4.78]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id JAA16374 for ; Fri, 3 Nov 1995 09:24:12 -0600 Received: from cspc45.ucd.ie (cspc45.ucd.ie [137.43.4.86]) by snowball.ucd.ie (8.6.12/8.6.10) with SMTP id OAA31726; Fri, 3 Nov 1995 14:01:56 GMT Message-Id: <199511031401.OAA31726@snowball.ucd.ie> Comments: Authenticated sender is From: "Niall Downey" Organization: Dept. Computer Science, UCD, IRL. To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING" Date: Fri, 3 Nov 1995 15:01:37 +0000 Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE Reply-to: apatel@ccvax.ucd.ie Priority: normal X-mailer: Pegasus Mail for Windows (v2.10) CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id VAA09665 for tcplw-list@sdiv; Thu, 2 Nov 1995 21:49:55 -0600 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id VAA09661 for ; Thu, 2 Nov 1995 21:49:54 -0600 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id VAA08291 for ; Thu, 2 Nov 1995 21:49:54 -0600 Received: from dectcp.cineca.it (dectcp.cineca.it [130.186.1.53]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id VAA06365 for ; Thu, 2 Nov 1995 21:49:50 -0600 Received: by dectcp.cineca.it (5.57/Ultrix3.0-C) id AA28651; Fri, 3 Nov 95 04:49:46 +0100 Received: by CE.UniPR.IT (4.1/SMI-4.1) id AA24421; Fri, 3 Nov 95 04:49:15 +0100 Date: Fri, 3 Nov 95 04:49:15 +0100 From: broggi@verdi.eng.unipr.it (Alberto Broggi) Message-Id: <9511030349.AA24421@CE.UniPR.IT> To: tcplw@cray.com Subject: Final CFP: Real-Time Imaging J. Dear colleague: this reminder has been automatically sent to different mailing lists; should you receive multiple copies of it, please excuse. ============================================================================== CALL FOR PAPERS JOURNAL OF REAL-TIME IMAGING Academic Press Special Issue on Special-Purpose Architectures for Real-Time Imaging Nowadays, a number of different problems are solved through image processing techniques (e.g. industrial inspection, robot guidance, unmanned vehicles,..., to cite only a few examples). The problem of processing images in real-time has been generally addressed and solved through the use of high-performance computer systems, developed ad-hoc to meet the specific requirements of the applications. Serial or parallel architectures have been enhanced through the addition of various bus systems, interprocessor communication networks, and other features explicitly designed to face the hard constraints imposed by real-time processing, such as I/O (data acquisition and output), data communications among processors (in multi-processor systems),... A number of different special-purpose architectures for image analysis have been proposed and developed, but seldom the presentation focuses on the discussion of both the hard real-time requirements (applications) and the hardware solutions which have been chosen (computer architectures). The TOPICS of this Special Issue include, but are not limited to: * Design of application-specific VLSI architectures; * Performance analysis and comparison among different architectural solutions; * Hardware mapping of parallel algorithms; * VLSI architectures for HDTV and image compression; * Hardware support for multimedia systems; * Vision-based real-time robot and vehicle navigation; * Massively parallel architectures for low-level vision; * Hardware neural solutions; * Experience on highly demanding vision applications. Prospective authors are encouraged to submit papers with a strong emphasis on the match between the application requirements and the chosen architectural solutions, detailing the ad-hoc hardware enhancements. Papers should describe systems which have been designed for a specific target application or which have proved to be particularly suited for a given task. MANUSCRIPT SUBMISSION: * Authors should send 5 copies of their full paper (about 15 double-spaced pages) to: Alberto BROGGI Dip. di Ingegneria dell'Informazione Viale delle Scienze University of Parma I-43100 Parma, Italy indicating their full postal address and e-mail address. Electronic or fax submissions will *NOT* be considered. * The closing date for submission is *DECEMBER 10th, 1995*. * Publication is tentatively expected to take place in MID 1996. * The final call-for-papers and up-to-date information can be obtained via WWW at: http://WWW.CE.UniPR.IT/rti-final Accepted manuscripts will need to comply with all author guidelines of Journal of Real-Time Imaging, available upon request from broggi@CE.UniPR.IT or from jrti@rtlab12.njit.edu. GUEST EDITORS: Alberto BROGGI Francesco GREGORETTI Dip. di Ingegneria dell'Informazione Dip. di Elettronica Viale delle Scienze Corso Duca degli Abruzzi University of Parma Polytechnic of Turin I-43100 Parma, Italy I-10129 Turin, Italy Phone: +39-521-905707 Phone: +39-11-5644081 Fax: +39-521-905723 Fax: +39-11-5644099 E-Mail: broggi@CE.UniPR.IT E-Mail: gregor@PoliTO.IT Received: (from daemon@localhost) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) id IAA03186 for tcplw-list@sdiv; Tue, 26 Sep 1995 08:35:29 -0500 Received: from t2.cray.com (root@t2 [128.162.19.5]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id IAA03179 for ; Tue, 26 Sep 1995 08:35:28 -0500 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id IAA18016 for ; Tue, 26 Sep 1995 08:35:27 -0500 Received: from btmplq.god.bel.alcatel.be (gatekeeper.alcatel.be [138.203.244.2]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.5) with ESMTP id IAA14639 for ; Tue, 26 Sep 1995 08:35:09 -0500 Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id NAA24759 for ; Tue, 26 Sep 1995 13:32:07 +0100 Received: from btmpjg.god.bel.alcatel.be(138.203.144.75) by btmplq via smap (V1.3) id sma024735; Tue Sep 26 14:31:45 1995 Received: from btmpbv.rc.bel.alcatel.be (btmpbv.rc.bel.alcatel.be [138.203.64.253]) by btmpjg (8.6.5/8.6.5) with ESMTP id NAA15359 for ; Tue, 26 Sep 1995 13:30:21 +0100 Received: (root@localhost) by btmpbv.rc.bel.alcatel.be (8.6.11/8.6.5) id NAA07669 for cn3_exploder; Tue, 26 Sep 1995 13:12:11 +0100 Date: Tue, 26 Sep 1995 13:12:11 +0100 From: Sysadmin D Message-Id: <199509261212.NAA07669@btmpbv.rc.bel.alcatel.be> To: cn3_exploder@btmpbv.rc.bel.alcatel.be Subject: test (you can delete this mail) testing mailing list ... Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA23003; Wed, 6 Sep 1995 09:34:40 -0500 Received: from t2.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA22984; Wed, 6 Sep 1995 09:34:38 -0500 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id JAA10959 for ; Wed, 6 Sep 1995 09:34:37 -0500 Received: from arch.umsl.edu (arch.cs.umsl.edu [134.124.30.125]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.5) with SMTP id JAA06324 for ; Wed, 6 Sep 1995 09:34:06 -0500 Received: from mayura by arch.umsl.edu (5.4R3.10/5.40/1.0) id AA04245; Wed, 6 Sep 1995 09:34:03 -0500 Received: by mayura.cs.umsl.edu (5.0/SMI-SVR4) id AA21736; Wed, 6 Sep 1995 09:23:22 -0500 From: rajiv@mayura.cs.umsl.edu (Rajiv Mehrotra) Message-Id: <9509061423.AA21736@mayura.cs.umsl.edu> Subject: no subject (file transmission) To: tcplw@cray.com Date: Wed, 6 Sep 1995 09:23:21 -0045 (GMT-0:45) Content-Type: text content-length: 89229 *************************************************************************** ACM MULTIMEDIA'95 November 4-9, 1995 Hyatt Regency (Embarcadero) San Francisco, CA THE THIRD ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION Sponsored by the ACM SIG Multimedia, SIGCHI, SIGGRAPH, SIGMIS, SIGBIO, SIGCOMM, SIGIR and SIGOIS In cooperation with ACM SIGAPP, SIGCAPH, SIGMOD and SIGOPS ADVANCE PROGRAM *************************************************************************** CONFERENCE COMMITTEE: General Chair: Bob Allen, Bellcore Program Chair: Polle Zellweger, Xerox PARC Treasurer: Marc Brown, DEC Systems Research Center Exhibits: Brent Hailpern, IBM T.J. Watson Research Center Publicity: Rajiv Mehrotra, University of Missouri, St. Louis CDROM: Isabel Cruz, Tufts University Workshops: Ephraim Glinert, Rensselaer Polytechnic Institute Electronic Information: Hui Zhang, Carnegie Mellon University Tutorials: Sorel Reisman, California State University, Fullerton Demonstrations: Tom Little, Boston University Proceedings: Rachelle Heller, George Washington University Videos: Ralph Hill, Bellcore Gil Cruz, Andersen Consulting Networking: Gary Paxinos, Metrolink, Inc. Audio/Visual: Rodney Fuller, Claremont Graduate School Local Arrangements: Mark H. Butler, University of California, Berkeley Panels: Fillia Makedon, Dartmouth College John Buford, University of Massachusetts-Lowell Student Volunteers: Hans-Peter Dommel, University of California, Santa Cruz European Liaison: Costantino Thanos, Consiglio Nazionale delle Ricerche Asian/Pacific Liaison: T.L. Kunii, University of Aizu Industrial Liaison: Warren Jonen, University of Alabama, Birmingham =============== WELCOME TO ACM MULTIMEDIA'95 The Multimedia Revolution is well underway. Just how far we have come is clearly shown by the range and quality of the presentations in this ACM Multimedia'95 Conference. The current work, however, is just pointing the way to new horizons. Indeed, the technical advances reported in this conference are likely some of the best indications of where the field is going and where progress will be made. The heart of this conference is the technical papers. Multimedia is a multi-disciplinary field, and the technical presentations reflect this diversity, ranging from underlying technologies to applications and issues, and from theory to practice. We believe that development of the field of multimedia is greatly facilitated by rigorous standards of evaluation. For the 202 submitted papers approximately 800 reviews were obtained and the technical paper committee spent two days evaluating all these reviews. It is very satisfying to see that a foundation has been established for the highest standards of technical excellence. The technical papers have a broad broad international scope. Over one-third of the submissions were from outside the US. In addition, the submittals were split 75-25 between universities and corporate laboratories. We are enthusiastic about the conference Plenaries. In the Opening Plenary, Clifford Stoll will critique the state of multimedia in Silicon Snake Oil: What is multimedia offering? For the Closing Plenary, Carol Peters of daVinci Time & Space will describe the interaction between artists and multimedia developers in Follow the Artists. The conference also has an outstanding collection of other venues, including Panels, Tutorials, Workshops, Exhibits, Videos, and Demonstrations. The Demonstrations Program deserves special note. On Wednesday, one track of the conference will be devoted to formal presentations of specially selected Featured Demonstrations. Multimedia can substantially improve communication between information providers and consumers by making it more effective and more engaging. Thus, multimedia will have a profound the impact on many areas of human activity. We certainly hope that this technology will be used for the improvement of society. In many cases it will be. However, it is not certain that all of the the impact will be positive. For instance, some important educational institutions such as libraries and museums and even schools will have to adapt. We have structured the conference to encourage discussion of these issues. Conference participants will include researchers, implementors, practitioners, educators, artists, and more. We invite you to take this opportunity to join in active conversation within this multimedia matrix. See and hear advances and issues both inside and out of your particular subfield(s) as you renew old acquaintances and make new ones. Plan now to join us in San Francisco in November for this exciting multimedia event. Bob Allen, General Chair Polle Zellweger, Program Chair ================= STUDENT VOLUNTEER PROGRAM ACM Multimedia'95 will provide an international forum for many aspects of multimedia technology. The student volunteer program is an opportunity for students to associate with experts in these fields. In return for their services, student volunteers will receive the following: * A student volunteer must work 8 hours to be eligible to attend the conference at no charge. * A student volunteer must work 8 more hours to be eligible to attend a tutorial. (16 hours of work = conference + a tutorial) * Tutorials will be offered on first-come, first-served basis, provided space is available. * The student volunteers will receive course materials of the tutorials they attend. * They may participate in the activities of the tutorial to the extent that their work duties allow. * Requests will be honored on a first-come, first-served basis. * The conference cannot pay for student lodging and travel. Interested graduate and undergraduate students are requested to contact student volunteer co-ordinator for more details. Hans-Peter Dommel Baskin Center for Computer Sciences/Engineering Univ. of California, Santa Cruz Applied Sciences 350, CA 95064 Phone: +1-408+459-4458 Fax: +1-408-459-4829 ================ CONFERENCE-AT-A-GLANCE Sunday NOVEMBER 5 7:00 AM - 4:00 PM Registration FULL-DAY COURSES 9:00 AM - 5:30 PM SA1 - Introduction to HyTime SA2 - Graphic Design for User Interfaces of Multimedia and Online Products or Services HALF-DAY MORNING COURSES 9:00 AM - 12:30 PM SA3 - Introduction to Multimedia Computing and Systems SA4 - Systematic Design of Multimedia Applications SA6 - An Introduction to Broadcasting for the Multimedia Professional 12:30 PM - 2:00 PM Lunch Break HALF-DAY AFTERNOON COURSES 2:00 PM - 5:30 PM SP1 - Understanding Distributed Multimedia Applications - The Architecture, Components, and End User Benefits SP2 - Structural Issues in Multimedia Design SP3 - How to Read and Evaluate a Multimedia Application SP4 - Multimedia Technology in the Broadcasting Industry SP5 - Cost Justification Issues in Multimedia Project Development Monday NOVEMBER 6 7:00 AM - 4:00 PM Registration FULL-DAY COURSES 9:00 AM - 5:30 PM MA1 - Information Highway: A Construction Survey MA2 - Desktop Animation HALF-DAY MORNING COURSES 9:00 AM - 120:30 PM MA3 - Background for Digital Libraries: Information Retrieval and Hypertext MA4 - Packet Video: Video over IP and ATM Networks MA5 - Real-Time Scheduling Technology for Continuous Multimedia Applications MA6 - Designing University Courses in Interactive Multimedia 12:30 PM - 2:00 PM Lunch Break HALF-DAY AFTERNOON COURSES 2:00 PM - 5:30 PM MP1 - Writing Interactive Multimedia: Creative and Critical Strategies MP2 - Background for Digital Libraries: Information Retrieval and Hypertext MP3 - Image and Video Compression Standards: Algorithms and Architectures MP4 - Resource Management in Distributed Video Server Environments MP5 - MHEG: An ISO Standard for Multimedia and Hypermedia Information Delivery Tuesday November 7 7:00 AM - 4:00 PM Registration 8:45 AM - 10:30 AM 1. Conference Opening and Plenary Plenary Title: Silicon Snake Oil: What Multimedia is Offering? Speaker: Clifford Stoll 11:00 AM - 12:30 PM 2A. Papers: Video Indexing and Retrieval 2B. Papers: Supporting Collaboration Environments 2P. Panel: The Information Superhighway: Electronic Democracy or Electronic Tranquilizer? 12:30 PM - 2:00 PM Lunch Break 2:00 PM - 3:30 PM 3A. Papers: Cyber Communities 3B. Papers: Multimedia Storage Servers 3P. Panel: Curriculum, Education and Training about Multimedia 4:00 PM - 5:30 PM 4A. Papers: Authoring Flexible Documents 4B. Papers: Video Processing 4P. Panel: Multimedia on a Shoestring: Low Bandwidth Implementations 6:30 PM - 9:00 PM Off-site conference reception, Yerba Buena Gardens Wednesday November 8 7:00 AM - 4:00 PM Registration 9:00 AM - 10:30 AM 5A. Papers: Speech and Audio Interfaces 5D. Demonstrations: Networked Video 5P. Panel: Personal Narrative Spaces 11:00 AM - 12:30 PM 6A. Papers: Multimedia Network Tools 6B. Demonstrations: Video-Centric Information Systems 6P. Panel: Multimedia and the Web 12:30 PM - 2:00 PM Lunch Break 2:00 PM - 3:30 PM 7A. Papers: Video and Image Collections 7B. Demonstrations: Enabling Hardware and Software 7P. Panel: Multimedia, Museums and Cultural Learning 4:00 PM - 5:30 PM 8A. Papers: Multimedia Networking 8B. Demonstrations: Video Indexing 8P. Panel: Multimedia and Education: Magic, Myth or Miracle Cure? 7:00 PM - 10:00 PM Interactive Demonstrations Thursday November 9 7:00 AM - 4:00 PM Registration 9:00 AM - 10:30 AM 9A. Papers: Video in Hypermedia 9B. Papers: Synchronization... it's about Time 9P. Panel: What's that Character Doing in your Interface? 11:00 AM - 12:30 PM 10A. Papers: LEARNing with MultiMedia 10B. Papers: Media Encoding 10P. Panel: Broadband Data Services to the Home 12:30 PM - 2:00 PM Lunch Break 2:00 PM - 3:00 PM 11. Award Papers 3:30 PM - 5:15 PM 12. Plenary and Closing Plenary Title: Follow the Artists Speaker: Carol Peters ================ OPENING PLENARY SPEAKER Clifford Stoll is the bestselling author of "The Cuckoo's Egg", the story of how he tracked and eventually caught a German spy ring operating over the Internet. Involved with computer networks since their inception, Cliff is widely known both online and off -- as astronomer, computer security expert, and network maven. Despite this, Cliff admits to being "deeply ambivalent" about the information highway. CLOSING PLENARY SPEAKER Carol Peters is the Chairman and CEO of daVinci Time & Space. daVinci Time & Space is the creator and enabler of a new form of interactive entertainment programming -- a Time & Space=81. This unique invention harnesses the power of networked multimedia PCs or TV settop boxes and sets the standard for next-generation entertainment programming. Backed by Oak Investment Partners, Greylock Limited Partnership, and Venrock Associates, daVinci Time & Space opened in 1993 and today has approximately 25 employees located at our office in San Mateo, California. daVinci Time & Space has produced an interactive television Pilot and has begun production on a networked PC/CD-ROM Time & Space. Prior to founding daVinci Time & Space, Carol spent four years at Silicon Graphics (SGI) where, as director of engineering, she led the project team that created the Iris Indigo workstation. Following the Indigo product ship, Carol became the director of marketing for SGI emerging markets. Before joining SGI, Carol capped a 16-year career with Digital Equipment Corporation (DEC) as the engineering manager of DEC's first RISC-based workstation, the DECStation 3100. Carol is a graduate of Harvard University with a BS in Architectural Science. =============== COURSES On behalf of this year's Course Selection Committee, I am pleased to be able to provide an outstanding selection of topical and informative courses for attendees of ACM Multimedi'95. The Committee sought to provide a slate of courses to appeal to every conference attendee. This year's schedule of courses represents a broad range of topics that constitute most of the "elements" of multimedia. In addition to the topics themselves, the courses in this year's schedule have been designed for a broad range of needs, - for those people interested in learning about new topics at an introductory level, to those needing advanced, state-of-the-art information within their own field of expertise. We have also tried to build the schedule to allow attendees to take an introductory course first, and a second or more advanced version afterwards. I urge everyone attending the conference to examine the course list carefully, and to get the most out of ACM Multimedia'95 by attending at least one course. Sorel Reisman Courses Chair ================== Sunday, November 5 Full-Day Courses Course Title: Introduction to HyTime Reference Number: SA1 Course Duration: Full Day Course Level: Basic Abstract Hypermedia/Time-based Structuring Language (HyTime) is an ISO standard for hypermedia documentation. It is an extension of Standard Generalized Markup Language (SGML) that encodes the hypermedia structure of a document. HyTime and SGML enable the use and development of hypermedia documents in an open and integrated environment. As such, authors are free to construct documents according to models that fit their particular needs. Although the resulting documents will follow many different models, they will use the same language for defining their underlying structure. Thus, each document will be readily integratable with documents of other models. Further, the structures shaping these documents can be defined in a manner that is independent of their eventual processing and presentation. This facilitates their application to many different, and possibly unanticipated, presentation situations. Organizer: Lloyd Rutledge received his B.S. degree from the University of Massachusetts at Amherst in 1987 and his Master of Science degree in Computer Science from the University of Massachusetts Lowell in 1993. He is currently at UMass Lowell researching his doctoral thesis on the processing of HyTime. He has also served on the HyTime development committee, published several articles on HyTime, and presented HyTime tutorials at several international conferences, including ACM Multimedia 94. ========= Course Title: Graphic Design for User Interfaces of Multimedia and Online Products or Services Reference Number: SA2 Course Duration: Full Day Course Level : Intermediate Abstract This tutorial will provide proven concepts and techniques for effective, information-oriented design of user interfaces. Many visual examples, including detailed case studies, will provide concrete examples and practical guidelines for use of color, symbolism, layout, organization of content, metaphorical references, navigational strategies, and information visualization. The following items will be addressed: What is a user interface? Metaphors, Mental model, Navigation, Appearance, Interaction,Data visualization. Designing for multiple cultures, ages, genders, nationalities, User interface design process. Issues will be discussed in terms of the following Case studies: American Airlines SABRE Online Travel Information Network, DTIC: Golden Gate Online Tutorial for Database Searching, Oracle Online Mentor: CBT GUI Design Standards, Prodigy Corporate GUI Design Standards, and Random House New Media CD-ROM Titles Organizer: Aaron Marcus is a leading designer of user interfaces, multimedia, and online services. His career in computer graphics and graphic design spans 25 years, and his firm Aaron Marcus and Associates, Inc., in Emeryville, California, has helped design award-winning products for 13 years. Mr. Marcus has written or co-written four books, including Graphic Design for Electronic Documents and User Interfaces, and The Cross-GUI Handbook. He has presented tutorials around the world at major conferences and corporate sites since 1980. =========== Sunday, November 5 Morning Courses Course Title: Introduction to Multimedia Computing and Systems Reference Number: SA3 Course Duration: Half Day Course Level: Basic Abstract There have been many new technical results in the development of large scale multimedia computing and communications systems. This course provides an introductory survey of both practice and research of multimedia computing and systems, including media and synchronization fundamentals, system architecture, middleware, OS support, continuous media file systems, GUI support, and network architectures. This course is recommended as a prerequisite to more advanced tutorials and the conference program. This course is an updated version of similar courses presented at ACM Multimedia 94, IEEE Multimedia Computing 94, and to other audiences. Organizer: Dr. John Buford is Assoc. Prof. of Computer Science at the University of Massachusetts Lowell. He is co-founder and director of the Distributed Multimedia Systems Lab, which has been active since 1990. He is contributing editor of the book Multimedia Systems, chair of X3L3.3 Hypermedia/ Multimedia Information Coding, and US head of delegation to ISO MHEG. He has twenty five published papers, is on the editorial board for J. Multimedia Tools and Applications, and is a program committee member for various multimedia conferences. ============ Course Title: Systematic Design of Multimedia Applications Reference Number: SA4 Course Duration: Half Day Course Level: Intermediate Abstract The course is intended for designers of multimedia applications and for users who need to develop their own applications. Designing a multimedia application requires a description of the nature of the "atomic pieces" of information; how the pieces are organized into "consumable" objects how the objects are interrelated; and how they can be grouped and accessed, to describe the application's behavior when the user will interact with it. This course will provide, a design methodology, a design model and a development environment correlated to the design methodology to accomplish these goals The course will present and discuss the following topics: * overall organization of a multimedia application and what design is about * the structuring of multimedia applications: concepts and design primitives * the dynamics of multimedia applications: concepts and design primitives * modularization of multimedia applications * how to reuse "pieces" of multimedia applications * common errors in the design of multimedia applications * the development cycle * the development environment and tools Organizer: Paolo Paolini is Full Professor at University of Lecce (Italy) and Technical Director of the Hypermedia Laboratory at Politecnico di Milano. He has a Master and Ph.D. in Computer Science from the University of California at Los Angeles (UCLA). He has been active in data base modeling and systems, programming languages, distributed data bases, data bases views, hypermedia modeling and authoring, multimedia application development tools. He has been technical responsible of various European research projects in the above fields, five of them within the program ESPRIT. He served as General Chair of the ACM international conference on Hypertext and Hypermedia in 1992 (ECHT'92). He has been member of the Program Committee of various editions of VLDB, ACM ECHT, and ACM HT conferences, and is currently Associate Editor of ACM Transactions on Information Systems (TOIS). Lecturer: Franca Garzotto - Hypermedia Laboratory - Politecnico Di Milano ======= Course Title: Image and Video Databases Reference Number: SA5 Course Duration: Half Day Course Level: Intermediate Abstract While earlier information systems were based on alphanumeric information, there is now an increasing tendency to include image, video, and other forms of data . The virtue of a database system lies in its ability to efficiently retrieve the correct piece of information. Alphanumeric keys are used for organizing and retrieving appropriate piece of information in databases. What would happen if the basic data format is not alphanumeric but is an image, a video sequence, or some other signal? This tutorial will be organized in the three sections- i) basic Issues, ii) review, and iii) detailed examples to address the following related issues. Images and other non-alphanumeric objects can neither be decomposed into well-defined records, nor can they be manipulated based upon any universally invariant criterion. By what principles can the images be organized? How are image-based queries specified? How can the concept of index keys be extended to image-based (as opposed to text-based) entities? These issues will be addressed for data that is in the form of video, speech or other sounds, or any other signal. Organizer: Ramesh Jain is a Professor of Electrical and Computer Engineering, and Computer Science and Engineering at University of California at San Diego. His research interests are in multimedia information systems, image databases, machine vision, and intelligent systems. He is the founding chairman of Virage, a San Diego based company developing systems for Visual Information Retrieval. Ramesh is a Fellow of IEEE, AAAI, and Society of Photo-Optical Instrumentation Engineers, and member of ACM, Pattern Recognition Society, Cognitive Science Society, Optical Society of America, and Society of Manufacturing Engineers. Currently, he is the Editor-in-Chief of IEEE Multimedia, and is on the editorial boards of several journals. =========== Course Title: An Introduction to Broadcasting for the Multimedia Professional Reference Number: SA6 Course Duration: Half Day Course Level: Basic Abstract One of the largest markets for multimedia technology is the broadcasting industry. Understanding the broadcasting process is essential to meeting the broadcaster's needs. This tutorial will introduce the radio and television broadcasting process with an eye towards problem areas and multimedia solutions. We will follow various audio programs, including news, commercials, and music, from creation through selection, in and out of the studio, and from transmitter to receiver. We will illustrate the integration of people, equipment, and technologies that brings the radio program to your receiver. Then, we'll follow the production of television programs, both live and recorded, as they make their way through the broadcast chain. Finally, we'll explore the economics of broadcasting to better understand costs, savings, and income. Organizer: Charles Owen, in over a decade of experience in the broadcasting industry, has held positions varying from Chief Engineer of a radio group to Vice President of Clark and Associates, Ltd., a broadcast equipment manufacturer. He served as project leader for many large development projects in digital audio, digital video, and large facility automation. He is currently Administrator of the Dartmouth Experimental Visualization Laboratory, a Dartmouth Presidential Fellow, and a Ph.D. candidate in computer science where he is researching information retrieval in multimedia. =============== Sunday, November 5 Afternoon Courses Course Title: Understanding Distributed Multimedia Applications - The Architecture, Components, and End User Benefits Reference Number: SP1 Course Duration: Half Day Course Level: Basic Abstract This course will address, explain, and analyze four major categories of multimedia applications: i) real-time multimedia ( including video conferencing , remote lectures , telemedicine ...), ii) on-line interactive multimedia (covering teleshopping, addressable advertisement, teletraining, movies-on-demand), iii) multimedia enabling of traditional IT systems ( TP , DB , Office Systems), and iv) stand alone multimedia ( PCs /Mac with CD-drives and various titles). In each category, discussion will focus on the features, the architectural components, trends and issues related to such matters as server design, network and bandwidth requirements, protocols and standards such as MPEG MHEG HTML SGML PREMO HyTime. Examples of systems running or pilots under implementation around the world will be given to illustrate the concepts. Finally, for each application, the course will address, from a user perspective, the expected benefits of multimedia and explore how multimedia can transform our day to lives. Organizer: N. Naffah has a Ph.D. in computer science from University of Paris and a telecom engineering degree from ENST . He has done research on computer networks and office automation at INRIA France . At Bull , he is Vice President for Multimedia business . N. Naffah is a member of the ACM , and IEEE . ========= Course Title: Structural Issues in Multimedia Design Reference Number: SP2 Course Duration: Half Day Course Level: Basic Abstract Designing end-user multimedia applications involves working with the structure of content: transforming content from linear to non-linear forms by creating interactive structures and designing representations of content. This course focuses on the structural issues involved in designing and developing a range of multimedia applications, from those with simple structures (branching, elaboration, and index) to those with complex structures (interactive narratives and essays), and on the kinds of content representations, or macrostructures, that work with different kinds of structures, content, and media. Organizer: Linn Marks is currently working on a digital library involving video-on-demand from a remote, large-scale server at IBM's T.J. Watson Research Center. She began her research in multimedia design at MIT's Project Athena in 1989. The focus of her work is the development of a framework for designing interactive discourse structures and new media interface elements, or multimedia macrostructures. She has presented tutorials on multimedia design at several conferences (see the World Wide Web Virtual SIGCHI Conference at http://drucker.cgs.edu/chivas/) and is co-editor of the ACM CHI'95 Electronic Proceedings. ========== Course Title: How to Read and Evaluate a Multimedia Application Reference Number: SP3 Course Duration: Half Day Course Level: Intermediate Abstract This course is intended for publishers, developers and "consumers" of multimedia applications, as well as for researchers interested in evaluation techniques of multimedia applications. The course will present and discuss the following topics: * general evaluation techniques, as they apply to multimedia applications * what design-oriented evaluation is about * concepts and terms for analyzing a multimedia application * design-oriented evaluation criteria * how to evaluate the main design features of an application: the procedural steps in evaluating a multimedia application The course will mainly proceed through examples, therefore more than 10 multimedia applications will be examined. Applications will be either commercial CD-ROM's, or research prototypes, or WWW applications. Some of the applications will probably be well known to some of the attendees; the promise is to discover, through design-oriented evaluation, some (hopefully) unexpected findings about them. Organizer: Franca Garzotto is Research Associate at the Department of Electronics and Information, Politecnico di Milano, where she presently serves as Managing Director of the Hypermedia Laboratory. She has a Degree in Mathematics from the University of Padova (Italy) and a Ph.D. in Computer Science from Politecnico di Milano. She has being active in data base systems, conceptual modeling of documents, hypermedia modeling and authoring, multimedia evaluation. She has been involved in various ESPRIT research projects in the above fields. She has been tutorial chair of ECHT'90 and ECHT'92, and member of the program committee of the conferences ACM HT'91, ACM HT'93, ACM ECHT'92, ACM ECHT'94, ACM Multimedia'95, ICHIM'95, and ACM HT'96. She has been Program Chair of the International Workshop on Hypermedia Design held in Montpellier - France in June 1995, and is co-chair of the Workshop on "Evaluation Methods and Quality Criteria for Multimedia Applications" to be held in conjunction with ACM Multimedia'95. Lecturer: Paolo Paolini, University Lecce And Hypermedia Laboratory - Politecnico di Milano. ======== Course Title: Multimedia Technology in the Broadcasting Industry Reference Number: SP4 Course Duration: Half Day Course Level: Intermediate Abstract The broadcasting industry invented the terms "media" and "multimedia" and is applying new multimedia technologies to air chains at a frantic pace. Advances such as program automation, non-linear editing, disk storage systems, and computer graphics have seen major commercial application in radio and television. This tutorial will detail the broadcasting process with emphasis on the technologies in use and proposed. We'll follow signals from production to reception, examining the elements of the chain, their use by operators and facility automation, and how they function as a system. The course will also examine new trends in broadcasting including cable television and radio, direct broadcast satellite, subcarrier data services, and bidirectional communications. Organizer: Charles Owen, in over a decade of experience in the broadcasting industry, has held positions varying from Chief Engineer of a radio group to Vice President of Clark and Associates, Ltd., a broadcast equipment manufacturer. He served as project leader for many large development projects in digital audio, digital video, and large facility automation. He is currently Administrator of the Dartmouth Experimental Visualization Laboratory, a Dartmouth Presidential Fellow, and a Ph.D. candidate in computer science where he is researching information retrieval in multimedia. ===================== Course Title: Cost Justification Issues in Multimedia Project Development Reference Number: SP5 Course Duration: Half Day Course Level: Intermediate Abstract Because of significant program development issues, multimedia development projects often require the same kind of cost justification that has historically been necessary for the efficient development of computer graphics-based applications. A manager of a multimedia development project must understand project related budget issues, including return-of-investment (ROI), in order to deliver truly successful systems. This tutorial will provide cost-justification models for such multimedia projects. A description of the history of computer graphics application development since the mid 1960s will be presented as a comparative base for multimedia application development. Typical costing models, including ROI analyses, for the development of CAD/CAM, slide-making, engineering, and science visualization systems will be presented. Multimedia today has many characteristics similar to computer graphics of 20 years ago, but because of its relative immaturity as an industry and because of its broad application range it is still difficult to develop costing models for multimedia. Tutorial attendees will acquire an understanding of key cost-justification issues necessary to develop innovative multimedia applications. Organizer Giorgio Valle is Professor of Computer Aided Design at Universita' di Milano, Italy. A computer graphics pioneer, he is currently working on Chiamabus Crema, an experimental, multimedia-based van-pooling system. Dr. Valle's interest is in the field of relational databases and his work on interactive cable television was instrumental in establishing the EUROGRAPHICS Association. For several terms he has served as Chairman of the ACM Italian Chapter. ======================= Monday, November 6 Full Day Courses Course Title: Information Highway: A Construction Survey Reference Number: MA1 Course Duration: Full Day Course Level : Intermediate Abstract This course is for anyone interested in understanding, using, or deploying exciting new broadband multimedia technology and services. Attendees will gain a thorough understanding of the end-to-end view and of the key elements of the "information highway" including: broadband services, interactive TV, and the Internet. The course covers system infrastructure, components, and tools. The emphasis is on system design issues and implications for clients, servers, and large-scale multimedia-enabled networks. Sample topics include: the WWW, interactive TV, video on demand, home banking, home automation, multimedia and compression, operating system support, application support, authoring tools, MM networks, training, education, information services, production of multimedia documents, multimedia tools, hypermedia systems, and regulation, copyrights, and security. Organizer: Milan Milenkovic is a system architect in IBM's Interactive Broadband Services group within the Network Application Systems Division. Prior to joining IBM, he was in academia where he performed research and taught courses on operating systems, computer architecture, and distributed computing. Dr. Milenkovic's publications include papers, monograph, a college text "Operating Systems: Concepts and Design" (McGraw-Hill, 1992) and a co-edited tutorial "A Guided Tour of Multimedia Systems and Applications" (IEEE, 1995.) ========== Course Title: Desktop Animation Reference Number: MA2 Course Duration: Full Day Course Level: Basic Abstract In this course attendees will learn the what, why and how of desktop animation. They will see what they can produce with the equipment they have. The tutorial will cover the full range of animation from the simple to the complex, but the emphasis will be on learning the basic skills and jargon necessary to get started in this exciting field. All concepts and terms are fully explained and in most cases, demonstrated by images and animations. The medium is part of the message. The course itself is a an effective demonstration of how to use animations in presentations. Over 40 animations and 5 video segments are embedded in this exciting and fast moving tutorial. Organizer: Darryl Freedman is president of VIVA Associates, a multimedia teaching and consulting firm. He has taught, consulted and lectured worldwide in telecommunications and multimedia for more than seven years. His seminars in the field of telecommunications and multimedia have been presented in the United States, Canada, Japan, Korea, the People's Republic of China and at major multimedia conferences. Darryl Freedman has a master's degree in electrical engineering from the Polytechnic University of New York. He is currently a regular contributor to The Carolina Computer News, on the advisory board for The School of Communications Arts, an instructor for computer animation at the Institute of Academic Technology and a member of the IEEE. ======== Monday, November 6 Morning Courses Course Title: Background for Digital Libraries: Information Retrieval And Hypertext Reference Number: MA3 Course Duration: Half Day Course Level: Basic Abstract This course will provide an introduction to information retrieval (IR) and hypertext (HT), which will act as a background for the afternoon course Research Issues and Design Issues for Digital Libraries as well as work in: content-based retrieval, hypermedia, networked information, educational courseware, and related technologies. Topics that will be addressed include the problems, models, design issues, current systems and research interests in the fields of IR and HT. Course attendees will learn how to navigate and reuse the WWW-based courseware on IR and HT and Multimedia available from Virginia Tech as well as to appreciate the power of the KMS hypertext system. They will be able to ask and discuss questions with the current and past SIG chairs of SIGIR and SIGLINK, respectively, and to talk with them about techniques and implementation considerations regarding building IR and HT systems and information collections. They will learn where to find out more about concerns regarding human-computer interaction as well as algorithms. Organizer: Edward A. Fox is Professor of Computer Science and Associate Director for Research at the Computing Center, Virginia Tech. He has been PI on over 40 grants and now directs "Interactive Learning with a Digital Library in Computer Science." He has helped prepare one videotape documentary, three CD-ROMs, and over 100 book chapters or journal or conference papers. He is Chair of the ACM SIG on Information Retrieval and founder of the ACM Multimedia Conferences series. Lecturer: Robert Akscyn, President of Knowledge Systems. ========= Course Title: Packet Video: Video over IP and ATM Networks Reference Number: MA4 Course Duration: Half Day Course Level: Intermediate Abstract The purpose of this course is to explain the principles of real-time video coding and transfer across ATM and IP networks. We will follow the video signal from the camera across the network to the monitor and step through all the functions needed along the way. Coding, application layer framing, rate-control, and resource allocation will be explained, as well as handling of loss, errors, and delay variations on the receiver side. Course topics will include; the use of real-time video in multimedia , applications, variable-rate and constant-rate coding, modeling and characterization of variable bit-rate , video sources, resource allocation, handling of jitter and loss, perceptual quality of service, and related research issues. Organizer: Gunnar Karlsson holds a MS from Chalmers University of Technology and a Ph.D. from Columbia University. His thesis was on video coding for packet-switched networks. Dr. Karlsson is a researcher at the Swedish Institute of Computer Science (SICS), and is on the faculty of the Royal Institute of Technology. Prior to joining SICS in 1992, he worked three years at the IBM Zurich Research Laboratory. He has been the first project leader of the Stockholm Gigabit Network. ============ Course Title: Real-Time Scheduling Technology for Continuous Multimedia Applications Reference Number: MA5 Course Duration: Half Day Course Level: Intermediate Abstract Real-time scheduling is critical for multimedia systems to meet the timing constraints of individual media streams, optimize system performance across concurrent streams as a whole, and support graceful performance degradation in case of resource contention. This course presents design principles and state-of-the-art techniques for scheduling system entities (thread, I/O processes, etc.) over system resources (CPU, disk I/O, etc.) for execution of continuous multimedia applications. The course is intended for researchers and practitioners who want to capture recent research results and new research challenges in this area, get insights into real-time scheduling fundamentals, and/or discuss system implementation techniques and existing obstacles in using off-the-shelf operating systems and hardware platforms. A multimedia data management system prototype will be used to demonstrate the effects of many of the real-time scheduling and real-time software methodologies presented in this course. Organizer: Dr. Jim Huang is a principal research scientist at Honeywell Technology Center and has recently been doing research and development on multimedia systems, real-time systems, real-time database systems, and multidatabase systems for industrial process control and military applications. He is an adjunct faculty of the University of Minnesota and the University of St. Thomas. He co-chaired the IEEE Real-Time Applications Workshop'94 and served on several program committees of real-time and multimedia systems conferences. =========== Course Title: Designing University Courses in Interactive Multimedia Reference Number: MA6 Course Duration: Half Day Course Level: Intermediate Abstract This course is a must for anyone who is thinking of incorporating multimedia into their curriculum or their business. Although this course will be Mac based, the concepts can be applied to any platform. Sample software and examples of student portfolios will be presented on the Mac. Examples of assignments and class handouts will be included. Based on a successful model of courses in interactive multimedia, this course is designed to address the questions: 1. Is there a corpus of material that can be identified and presented to students in an academic setting? 2. What requirements should be in place for students taking a first multimedia course? 3. How can that corpus - if it exists - be ordered into a meaningful program? 4. What requirements should be in place for students pursuing such a program? 5. How does that material relate to, or augment, current undergraduate and graduate programs in computer science? 6. How can the team nature of "real world" interactive multimedia projects be accommodated in a computer science class to allow students of various backgrounds to participate? 7. What types of laboratory environments need to be created? Organizer: Dr. Kieffer is an assistant professor of computer science in the Computer Science Department, School of Mathematics, Science and Technology, at Eastern Washington University. Dr. Kieffer's research interests are in the area of computer literacy, educational uses of computers and interactive multimedia. She is a member of the Association for the Advancement of Computing in Education (AACE), Northwest Council for Computer Education (NCEE), IEEE and ACM, and the SIGs on Computer Science Education (SIGCSE) and Computer Uses in Education (SIGCUE). Lecturer: Rachelle Heller, Department of Electrical Engineering and Computer Science, The George Washington University, Washington DC 20052. ========== Monday, November 6 Afternoon Courses Course Title: Writing Interactive Multimedia: Creative and Critical Strategies Reference Number: MP1 Course Duration: Half Day Course Level: Basic Abstract In this tutorial, participants will help formulate some basic principles for writing for the interactive, multimedia environment. This course will 1) attempt to describe interactive multimedia as a medium similar to and yet distinct from film, television, or print; 2) explain roles and challenges for the writer; and 3) introduce creative and critical ways to approach the medium through examples and group exercises. The course is geared to those with previous writing experience who are new to multimedia and those with multimedia experience who have little formal training in writing. Organizer: Martin Schecter taught composition, creative writing, and cultural studies as an assistant professor of English at Drake University from 1992 - 1994. Previously, he worked as a senior medical writer in Princeton, NJ. He has his M.F.A. in fiction writing from the University of Arizona and has published short fiction, essays, criticism and a novel. He currently manages an educational CD-ROM project and is at work on a textbook on fiction writing. ========== Course Title: Background for Digital Libraries: Information Retrieval and Hypertext Reference Number: MP2 Course Duration: Half Day Course Level: Intermediate Abstract This course will focus on the popular emerging field of Digital Libraries (DLs) and for people new to this field will be based upon issues presented in the preparatory morning course, "Background for Digital Libraries: Information Retrieval and Hypertext." Those who are at an intermediate level, should have some background in information retrieval, hypertext, hypermedia, or library or information science. Attendees at an advanced level will be interested in the perspective of the co-organizers, who led editing of the April 1995 CACM issue on DLs. Attendees will learn about a number of important DL projects, and be prepared to help design and implement future DLs. They should understand the main research issues regarding DLs, and know where to obtain guidance on the key technologies involved. They will learn about the results of May, October and November 1995 workshops about DLs, as well as others dating back to 1991. They will see demonstrations regarding ACM's digital library and learn about progress in scaling up the KMS system to support very large DLs. Organizer: Edward A. Fox is Professor of Computer Science and Associate Director for Research at the Computing Center, Virginia Tech. He has been PI on over 40 grants and now directs "Interactive Learning with a Digital Library in Computer Science." He has helped prepare one videotape documentary, three CD-ROMs, and over 100 book chapters or journal or conference papers. He is Chair of the ACM SIG on Information Retrieval and founder of the ACM Multimedia Conferences series. Lecturer: Robert Akscyn, President of Knowledge Systems. ============= Course Title: Image and Video Compression Standards: Algorithms and Architectures Reference Number: MP3 Course Duration: half day Course Level: Basic Abstract Compression is one of the core technologies in video teleconferencing, digital television, and a number of multimedia applications. This tutorial provides an introductory overview of the principles of image and video compression standards and their hardware implementation. The tutorial will be in two parts. The first part reviews the key principles in image compression and acquaints the audience with transform coding, motion estimation and compensation, and entropy coding. In this part, an overview of the JPEG, MPEG and H.261 image and video compression standards will be presented. A short overview of the MPEG audio and Dolby AC-3 algorithms will also be presented. The second part of the tutorial presents an overview of the latest hardware implementations in custom and programmable video processors. Organizer: Konstantinos Konstantinides received his Ph.D. degree in electrical engineering from the University of California, Los Angeles, in 1985. He is currently a member of the technical staff at Hewlett-Packard Laboratories, in Palo Alto where he is involved in various research projects in digital signal and image processing and compression. He is a Senior member of the IEEE and a member of the IEEE Technical Committee on the design and implementation of digital signal processors. Lecturer: Vasudev Bhaskaran, Hewlett-Packard Laboratories, MS 3U, PO Box 10490 Palo Alto, CA 94303. ============= Course Title: Resource Management in Distributed Video Server Environments Reference Number: MP4 Course Duration: Half Day Course Level: Intermediate Abstract This tutorial, which is for both practitioners and researchers, provides an overview of resource management in a distributed video server cluster consisting of many interconnected processing and storage nodes. The goal is to provide casual participants with an overview of video server design issues as well as to provide sophisticated designers with new and timely information about this rapidly evolving area. Practitioners will learn practical and new algorithms and design principles. Researchers will additionally benefit from a broad overview of this area. Case studies will be presented that will be of interest to both groups. An extensive bibliography of recent work will also be provided. Organizer: Dr. Asit Dan is a Research Staff Member at the IBM Watson Research Center working on the design and development of distributed video server architectures. He has authored several papers and holds many patents in this area. His earlier work on databases received an ACM Dissertation award and is published by the MIT Press. Lecturer: Dr. Dinkar Sitaram, IBM Research Division, H4-A04, PO Box 704, Yorktown Heights, NY 10598 ============== Course Title: MHEG: An ISO Standard for Multimedia and Hypermedia Information Delivery Reference Number: MP5 Course Duration: Half Day Course Level: Advanced Abstract MHEG is ISO 13522, a specification for platform-independent delivery of interactive multimedia and hyper- media content in networked environments. MHEG is near standardization, and has close ties with the MPEG-2 Transport Stream and MPEG-2 DSM-CC which are expected to be widely used in set-top box and other consumer entertainment devices. MHEG also includes a platform-independent specification for scriptware application delivery. This tutorial provides an in-depth discussion of MHEG part 1 (object interchange) and part 3 (scriptware interchange). We also present details of implementation issues for MHEG engines, and recommendations for supporting MHEG in authoring environments. Organizer: Dr. John Buford is Assoc. Prof. of Computer Science at the University of Massachusetts Lowell. He is co-founder and director the Distributed Multimedia Systems Lab, which has been active since 1990. He is contributing editor of the book Multimedia Systems, chair of X3L3.3 Hypermedia/Multimedia Information Coding, and US head of delegation to ISO MHEG. He has 25 published papers, is on the editorial board for J. Multimedia Tools and Applications, and is a program committee member for various multimedia conferences. ================= WORKSHOPS ACM Multimedia'95 is proud to be hosting a number of full-day, in-depth workshops on topics of great current interest to the members of the multimedia research community. Although participation in a workshop is by invitation only, most still have slots available. So if you see one to which you think you could make a contribution, don't hesitate to contact the organizer for more information. Please note that all workshop attendees are expected to register for the conference, and must in addition pay a workshop fee of $50 which will be collected by the organizer. Take advantage of this unique opportunity to get the most out of ACM Multimedia'95! Ephraim P. Glinert Workshops Chair ==================== Saturday, November 4 W1 Full Day Effective Abstractions in Multimedia Layout, Presentation and Interaction Organizers: Isabel Cruz, Tufts University Joseph Marks, Mitsubishi Electric Research Laboratories Kent Wittenburg, Bell Communications Research This workshop is concerned with abstract representations and methods for structuring of multimedia/hypermedia documents and interactions. We will focus on concepts and techniques that are useful for organizing heterogeneous information from the perspective of both end-user delivery and authoring. Problems to be discussed include spatial layout for visual presentation; temporal layout for presentation using animation and audio; determination of page content, linking structure and index structure for hypermedia documents; filtering, generalization, and customization of information in multimedia/hypermedia applications; and synergistic combination of media. More information may be found on the World Wide Web at http://www.cs.tufts.edu/~isabel/mmws.html. Contact Person: Dr. Kent Wittenburg Bellcore, Rm. MRE 2A-347 445 South Street Morristown, NJ 07962 E-mail: kentw@bellcore.com Phone: +1-201-829-4382 Fax: +1-201-829-5981 =========== Saturday, November 4 W2 Full Day Integrating Audio and Visual Media Organizer: Meera Blattner, University of California at Davis and Lawrence Livermore National Laboratory Non-speech audio, speech, video, and graphics are the output media of multimedia interfaces. For historical reasons, audio and visual media have not been integrated well in the human-computer interface, although these modalities are integrated in our real world experience. Can we build a systematic foundation for understanding the interpretation of information in both the auditory and visual domains together? To what other disciplines can we turn to learn how to design good multimedia interfaces? What examples do we have now of good integration in the auditory and visual domains? Do we attempt to mimic the real world, or should we strive to use media in new ways (for example, to use sound to replace touch)? Contact Person: Professor Meera M. Blattner, L-540 Lawrence Livermore National Laboratory P. O. Box 808 Livermore, CA 94550 E-mail: blattner@llnl.gov Phone: +1-510-422-3503 Fax: +1-510-423-4139 =========== Saturday, November 4 W3 Full Day Evaluation Methods and Quality Criteria for Multimedia Applications Organizers: Franca Garzotto, Politecnico di Milano Manfred Thuering, BIFOA / University of Cologne To support effective evaluation of multimedia applications and product development, it is necessary to first define what must be evaluated, what constitute reasonable quality criteria, which metrics are suitable for measuring them, which evaluation procedures should be applied, and which existing standards can be employed. These issues will be discussed during the workshop by people from diverse backgrounds (researchers, application developers, multimedia publishers, distributors, and product managers), so that all may come away with a better understanding of evaluation criteria, quality assessment, and methods for systematic testing. Contact Person: Dr. Franca Garzotto Hypermedia Laboratory Dept. of Electronics and Information Politecnico di Milano Piazza Leonardo da Vinci 32 I-20133 Milano, Italy E-mail: garzotto@elet.polimi.it Phone: +39-2-23993520 Fax: +39-2-23993411 =========== Saturday, November 4 W4 Full Day NSF Research on Digital Libraries Organizer: Edward Fox, Virginia Tech The goal of this workshop is to produce a set of recommendations to the R&D community regarding high impact topics crucial for digital libraries. We will focus on three issues: the desirability of holding a ``competition'' similar to the TREC (Text REtrieval Conference) or MUC (Message Understanding) events; identification of research crucial to the success of digital libraries and which is not now supported; and possible mechanisms for sharing - perhaps through some type of clearing house - tools, collections and other results, so that small research teams can more easily build upon the findings of others and so contribute. The workshop will lead to a report that will be disseminated widely on paper as well as electronically. Community response to recommendations in the report should lead to participation of more research teams that will as a result make additional contributions to this important NII area. Contact Person: Professor Edward A. Fox Dept. of Computer Science 562 McBryde Hall Virginia Tech Blacksburg, VA 24061 E-mail: fox@vt.edu Phone: +1-703-231-5113 Fax: +1-703-231-6075 ======================= Friday, November 10 W5 Full Day Adaptive Multimedia Technologies for People with Disabilities Organizers: Shi-Kuo Chang, University of Pittsburgh Ephraim Glinert, Rensselaer Polytechnic Institute As multimedia interfaces become ubiquitous, there is a danger that the requirement of using all the senses may deny additional communities access to information. In this workshop we will explore and define the future technologies needed to support multiple media choices that are selectable on several levels, so that the most appropriate media can be provided to each user. Topics discussed will include: use of multimedia in teaching and researching sign languages; virtual reality environments for people with disabilities; adapting GUIs for blind users; nonvisual representations for information; storage standards for sophisticated closed captioning and descriptive accompanying audio. The workshop is scheduled to immediately follow the conference, so that late-breaking developments can be addressed in the discussions. Attendees will be selected to include a mixture of experts on multimedia, experts in helping people with disabilities, and scientists with disabilities. Contact Person: Professor Shi-Kuo Chang Dept. of Computer Science University of Pittsburgh Pittsburgh, PA 15260 E-mail: chang@cs.pitt.edu Phone: +1-708-679-3135 thru August 31, then +1-412-624-8423 Fax: +1-708-679-3166 thru August 31, then +1-412-624-8465 =========== Friday, November 10 W6 Full Day Intellectual Property Rights Management in the Electronic Information Society: A European Initiative in the ESPRIT Programme Organizer: Costantino Thanos, Consiglio Nazionale delle Ricerche, Pisa The objective of this workshop is to present the most promising results of a number of related research projects conducted by the European ESPRIT program during the past 5 years, and which together defined a generic model for the management in an electronic society of intellectual property rights and copyright issues. Four discussion areas, each to be introduced by an expert in the field, are planned: information technology industries; publishing; museums; and libraries. Topics to be covered will include: overview of the various projects; the CITED model; technologies and implementations; the publisher- university relationship; numeric TV broadcasting; CD-ROM publishing; critical issues for educational and library systems; fee collecting and licensing agencies; multimedia authoring; requirements for standardization and infrastructure. We will conclude with an open discussion on the impact of this work on the business community. Contact Person: Dr. Costantino Thanos Istituto di Elaborazione dell'Informazione Consiglio Nazionale delle Ricerche Via S. Maria 46 I-56126 Pisa, Italy E-mail: thanos@iei.pi.cnr.it Phone: +39-50-593492 Fax: +39-50-554342 ============= Friday, November 10 W7 Full Day Multimedia Database Management Systems Organizers: Bruce Berra, Syracuse University Kingsley Nwosu, AT&T Bhavani Thuraisingham, MITRE Corporation This workshop will investigate issues in designing and developing M-DBMSs. A M-DBMS which supports distributed applications should integrate the two technologies of distributed/heterogeneous databases and multimedia data management. This integration is one of the greatest challenges faced by information systems researchers and developers, and will be the main focus of this workshop. Topics to be discussed include the following: data models; storage structures; system, schema and functional architectures; retrieval and update algorithms; metadata management for multimedia databases. Attendees will be chosen to include a mixture of people from the database and multimedia information systems communities. Contact Person: Dr. Bhavani Thuraisingham The MITRE Corporation, K329 Burlington Road Bedford, MA 01730 E-mail: thura@mitre.org Phone: +1-617-271-8873 Fax: +1-617-271-2352 ================= TECHNICAL PROGRAM Tuesday, November 7 8:45 AM - 10:30 AM 1. Opening and Plenary Opening Plenary: Silicon Snake Oil: What Multimedia is Offering Speaker: Clifford Stoll 11:00 AM - 12:30 PM 2A. Papers: Video Indexing and Retrieval Video parsing, retrieval and browsing: An integrated and content-based solution H.J. Zhang, C.Y. Low, S.W. Smoliar and D. Zhong, National University of Singapore An intuitive and efficient access interface to real-time incoming video based on automatic indexing Yukinobu Taniguchi, Akihito Akutsu, Yoshinobu Tonomura and Hiroshi Hamada, NTT Human Interface Laboratories, Japan Automatic content-based retrieval of broadcast news M. G. Brown, J. T. Foote, G. J. F. Jones, K. Sparck Jones and S. J. Young, Olivetti Research Limited and Cambridge University, UK 2B. Papers: Supporting Collaboration Environments Dealing with timing variability in the playback of interactive session recordings Nelson R. Manohar and Atul Prakash, University of Michigan Multimedia application sharing in a heterogeneous environment Klaus H. Wolf, Konrad Froitzheim and Peter Schulthess, University of Ulm, Germany Automating envisionment of virtual meeting room histories Allen Ginsberg and Sid Ahuja, AT&T Bell Laboratories 2P. Panel: The Information Superhighway: Electronic Democracy or Electronic Tranquilizer? Chair: Barbara Simons, IBM Almaden Events are moving so rapidly with respect to the Information Superhighway or National Information Infrastructure (NII) that it's almost impossible to write an abstract dealing with policy issues several months in advance of an event. Laws are being proposed (as of this writing, the Exon Amendment has been incorporated into the Telecommunications Bill, but the final vote has not yet been taken), books are being written by authors with very diverse views such as Clifford Stoll and Nicholas Negroponte, large sums of money are being invested, and major pronouncements are being made. Yet the terms of the discussions tend to be vague. How does the Internet relate to this yet-to-be-defined NII? Who will have access and to what? How will it be used? What are the potential abuses and how will we be protected from them? This panel will discuss current policy issues and concerns. We hope to have considerable input from the audience. 2:00 PM - 3:30 PM 3A. Papers: Cyber Communities The Jupiter audio/video architecture: secure multimedia in network places Pavel Curtis, Michael Dixon, Ron Frederick and David A. Nichols, Xerox PARC Low disturbance audio for awareness and privacy in media space applications Ian Smith and Scott E. Hudson, Georgia Institute of Technology Visual Who: Animating the affinities and activities of an electronic community Judith S. Donath, MIT Media Lab 3B. Papers: Multimedia Storage Servers Disk farms vs. storage hierarchies for video service Ann L. Chervenak, David A. Patterson and Randy H. Katz, Georgia Institute of Technology and University of California, Berkeley Using rotational mirrored declustering for replica placement in a disk-array-based video server Ming-Syan Chen, Hui-I Hsiao, Chung-Sheng Li and Philip S. Yu, IBM T.J. Watson Research Center Efficient support for scan operations in video servers Prashant J. Shenoy and Harrick M. Vin, University of Texas at Austin 3P. Panel: Curriculum, Education and Training about Multimedia Chair: Ed Fox, Virginia Polytechnic Institute and State University There is a growing demand for people with knowledge and skills in the areas of multimedia information, systems, and technology. Universities are just beginning to help in this regard, and a curriculum effort by SIGMM may be in order to provide guidance and support. This panel will lead a discussion with the audience regarding when and how to develop such a curriculum, dealing with issues such as: * At what level should courses be offered (senior, graduate, ...); * Should such courses be taught by CS, Arts, Communications, or other disciplines --- or by interdisciplinary teams? * What are the needs of industry --- research, development --- that should be concentrated upon? * What courseware, toolkits, demonstrations, online resources, textbooks, projects, etc. can assist with education? 4:00 PM - 5:30 PM 4A. Papers: Authoring Flexible Documents Multimedia documents with elastic time Michelle Y. Kim and Junehwa Song, IBM T.J. Watson Research Center Commands as media: design and implementation of a command stream Jonathan L. Herlocker and Joseph A. Konstan, University of Minnesota Control layer primitives for the layered multimedia data model Michael J. Wynblatt and Gary Schloss, SUNY at Stony Brook 4B. Papers: Video Processing A resolution independent video language Jonathan Swartz and Brian C. Smith, Cornell University A robust method for detecting cuts and dissolves in video sequences Kevin Mai, Justin Miller and Ramin Zabih, Cornell University An architecture for multiple perspective interactive video Patrick H. Kelly, Arun Katkere, Don Y. Kuramura, Saied Moezzi, Shankar Chatterjee and Ramesh Jain, University of California, San Diego 4P. Panel: Multimedia on a Shoestring: Low Bandwidth Implementations Chair: John Danskin, Dartmouth College If Multimedia is to accessible to the masses, it will have to work across slow networks like the standard telephone system. We are also seeing a tremendous increase in wireless (cellular modem) applications, especially for personal digital assistants. These machines present a tremendous new market for the multimedia community, but the network bandwidth problems associated with these machines are severe. We will discuss problems, solutions and approaches associated with implementing multimedia applications over low bandwidth network connections such as cellular modems and phone lines. 6:30 PM - 9:00 PM Off-site conference reception, Yerba Buena Gardens Wednesday, November 8 9:00 AM - 10:30 AM 5A. Papers: Speech and Audio Interfaces Surfing the Web by voice Charles T. Hemphill and Philip R. Thrift, Texas Instruments Hearing Aid: Adding verbal hints to a learning interface Elizabeth Stoehr and Henry Lieberman, MIT Media Lab Query by humming: Musical information retrieval in an audio database Asif Ghias, Jonathan Logan, David Chamberlin and Brian C. Smith, Cornell University 5D. Demonstrations: Networked Video MBONE VCR - A video conference recorder for the MBONE Wieland Holfelder, ICSI A distributed real-time MPEG audio video player Shanwei Cen and Jonathan Walpole, Oregon Graduate Institute 5P. Panel: Personal Narrative Spaces Chair: Sha Xin Wei, Stanford University Emerging multimedia technologies have blurred the lines between classically distinct categories of theater and narrative: stage-spaces in which humans and artifacts interact, and spaces of symbols like a page of text or a digital video to be interpreted by an observer. This panel brings together practitioners to take stock of the state of the art and point out some exciting lines of work in the field of interactive media. What will we face do when we freely inter-mix computational artifacts with human agents in our living, writing or performance spaces? How will we make sense of such hybrid spaces and how will we share these interpretations? These questions are intimately tied with techno-scientific issues as well as literary and social issues. How should media models evolve to meet the needs of these personal narrative spaces? What are some design limitations of our tools or frameworks? What are some potential functions that inhabitants, browsers, composers, and architects can tap in emerging frameworks? What are some worthy challenges for researchers and developers interested in interactive multimedia? 11:00 AM - 12:30 PM 6A. Papers: Multimedia Network Tools Managing real-time services in multimedia networks using dynamic visualization and high-level controls Mun Choon Chan, Giovanni Pacifici and Rolf Stadler, Columbia University An application level video gateway Elan Amir, Steven McCanne and Hui Zhang, University of California, Berkeley and Carnegie Mellon University Multimedia traffic analysis using CHITRA95 Marc Abrams, Stephen Williams, Ghaleb Abdulla, Shashin Patel, Randy Ribler and Edward A. Fox, Virginia Polytechnic Institute and State University 6D. Demonstrations: Video-centric Information Systems GUARDIAN: A knowledge-based home health-care system for children with leukemia Michelle Y. Kim, IBM T.J. Watson Research Center CITYQUILT: A navigable movie Tirtza Even 6P. Panel: Multimedia and the Web Chair: Allan Kuchinsky, Hewlett Packard While the perceived benefits networked multimedia are significant, there are also considerable challenges to bringing this vision to fruition in the mass market. At this point, it seems plausible that the web will evolve as a primary delivery vehicle for multimedia. However, there are a number of obstacles to this evolution for the Web. One formidable problem is that we are trying to blend a number of different authoring paradigms, communities, and traditions, many of which are conflicting. There are many fundamental inconsistencies, for example, between the document-centric paradigm of HTML and the presentation-centric paradigm of multimedia authoring tools such as Director. This panel explores differing perspectives on the merging of multimedia and the Web. The goal is to determine the most plausible approaches for blending the interactivity of the CD-ROM environment with the networked, interlinked nature of the Web. 2:00 PM - 3:30 PM 7A. Papers: Video and Image Collections Integrated video archive tools Rune Hjelsvold, Stein Langorgen, Roger Midtstraum and Olav Sandsta, Norwegian Institute of Technology, Norway Automatic recognition of film genres Stephan Fischer, Rainer Lienhart and Wolfgang Effelsberg, University of Mannheim, Germany An integrated color-spatial approach to content-based image retrieval Wynne Hsu, T.S. Chua and H.K. Pung, National University of Singapore 7D. Demonstrations: Enabling Hardware and Software Montage multipoint audio and video S.R. Ahuja and R.D. Gaglianello, AT&T Bell Laboratories The programmers' playground demo T. Paul McCartney, Kenneth J. Goldman and Bala Swaminathan, Washington University 7P. Panel: Museums, Multimedia, and Cultural Learning Co-Chairs: Ranjit Makkuni, Xerox PARC and Mike Sipusik, UC Berkeley Museums provide people with a rich setting for cultural learning. Museums are the repositories of artifacts from diverse cultures. However, we should not forget that these artifacts are located in-situ a cultural practice, and need to be seen in their original cultural context where interrelations between form, process, myth, symbol, philosophy, ritual and celebration get articulated. Modern multimedia systems in museums have begun to address the issues of "re-contextualising" the cultural artifact in its original context. Members of the panel will show examples of cultural learning systems, and the design challenges of re-contextualisation. Panelists consist of designers of learning systems, education researchers, museum administrators. 4:00 PM - 5:30 PM 8A. Papers: Multimedia Networking Fast lossy Internet image transmission Geoffrey M. Davis and John M. Danskin, Dartmouth College A reliable dissemination protocol for interactive collaborative applications Rajendra Yavatkar, James Griffioen and Madhu Sudan, University of Kentucky A generalized admissions control strategy for heterogeneous, distributed multimedia systems Saurav Chatterjee and Jay Strosnider, Carnegie Mellon University 8A. Demonstrations: Video Indexing Automating the creation of a digital video library Michael A. Smith and Michael Christel, Carnegie Mellon University A video parsing, indexing, and retrieval system H.J. Zhang, J.H. Wu, and C.Y. Low, National University of Singapore 8P. Panel: Multimedia and Education: Magic, Myth or Miracle Cure? Chair: Rachelle Heller, George Washington University The media has latched onto the use of multimedia in education. This panel will attempt to question the issues beyond the hype - is it an appropriate atmosphere in which to offer educational experiences or does it reinforce the 30 second sound byte mentality, what is it about multimedia that makes it a tool for all learners or is it a superficial educational environment? Is it just for kids or will all learners benefit from using multimedia? These and other questions will be addressed by this lively panel of theorists and practitioners. 7:00 PM - 10:00 PM Interactive Demonstrations Thursday, November 9 9:00 AM - 10:30 AM 9A. Papers: Video in Hypermedia ConText: Towards the evolving documentary Glorianna Davenport and Michael Murtaugh, MIT Media Lab Surfing the movie space: advanced navigation in movie-only hypermedia Joerg Geissler, GMD-IPSI, Germany Automated authoring of hypermedia documents of video programs Behzad Shahraray and David C. Gibbon, AT&T Bell Laboratories 9B. Papers: Synchronization... it's about Time Scheduling MPEG-compressed video streams with firm deadline constraints Ching-Chih Han and Kang G. Shin, University of Michigan Low-level multimedia synchronization algorithms on broadband networks Miguel Correia and Paulo Pinto, INESC and IST, Portugal Coordinating heterogeneous time-based media between independent applications Scott Flinn and Kellogg S. Booth, University of British Columbia, Canada 9P. Panel: What's that Character doing in your Interface? Chair: Abbe Don, Abbe Don Interactive Inc. Until recently, the discussion of the use of characters in the interface centered on the old question to anthropomorphize or not to anthropomorphize the interface. With the appearance of Microsoft's "social interface" in the form of Bob and his pals, with Fujitsu's use of avatars in their online service "Habitat," and with millions of people representing themselves daily in various contexts on the Internet, the old discussion centering on the wonders or pitfalls of anthropomorphism seems moot. Instead, many multimedia designers, producers, and software engineers find themselves accepting the use of characters in the interface and are now grappling with a more difficult set of issues regarding implementation. These questions include: * What is the most appropriate representation for a particular application or audience? * Why are some characters accepted while others are dismissed as "too cute?" * How do you match back-end functionality with the promises of the front-end representation? * What tools are needed to enable users to create their own characters or agents? * If a character acts autonomously, how do you explain the action to the user? * Can characters be truly adaptive to users' needs? * Can characters be truly adaptive within a story or entertainment context? * Can characters and 'bots be used effectively on the World Wide Web? 11:00 AM - 12:30 PM 10A. Papers: LEARNing with MultiMedia The PsyCLE Project: educational multimedia for conceptual understanding Nick Hammond, Jean McKendree, Will Reader, Annie Trapp and Peter Scott, University of York and University of Sheffield, UK pianoFORTE: A system for piano education beyond notation literacy Stephen W. Smoliar, John A. Waterworth and Peter R. Kellock, National University of Singapore and Umea University, Sweden eMMaC: Knowledge-based color critiquing support for novice multimedia authors Kumiyo Nakakoji, Brent N. Reeves, Atsushi Aoki, Hironobu Suzuki and Kazunori Mizushima, MITI, Japan; Software Research Associates, Inc. and University of Colorado 10B. Papers: Media Encoding Model-based motion estimation for synthetic animations Maneesh Agrawala, Andrew C. Beers and Navin Chaddha, Stanford University Inner-block operations on compressed images Bo Shen and Ishwar K. Sethi, Wayne State University Direct manipulation of MPEG compressed digital audio M. Alexander Broadhead and Charles B. Owen, Dartmouth College 10P. Panel: Broadband Data Services to the Home Chair: Gita Gopal, HP Laboratories The ubiquitous deployment of broadband access architectures to the home, coupled with an access-bandwidth technology discontinuity in the form of high-speed cable modems, will cause an explosion in broadband interactive data services to the home. The panel speakers will discuss services enabled by cable modems, the service software that is needed to provide these services, and the differences between this environment and other candidates for the NII including Video-On-Demand, and the Internet. 2:00 PM - 3:00 PM 11. Award Papers Best Student Paper: vic: A flexible framework for packet video Steven McCanne and Van Jacobson, University of California, Berkeley Best Paper: A confederation of tools for capturing and accessing collaborative activity Scott Minneman, Steve Harrison, Bill Janssen, Gordon Kurtenbach, Thomas Moran, Ian Smith and Bill van Melle, Xerox PARC 3:30 PM - 5:15 PM 12. Plenary and Closing Closing Plenary: Follow the Artists Speaker: Carol Peters, daVinci Time & Space High speed computing, multimedia capabilities, high speed networks, and authoring tools are the technical enablers of a new design language that will express new forms of entertainment, education, and information. This design language will allow visual, sound, and literary artists to speak through the new technology. To learn how to speak the language, the artists must start their lessons now. As partners to the artists, the technologists must learn how to listen to, follow, and create mechanisms for the artists. Thus will technologists discover how to specify and make accessible the new design language. Thus will the artists speak and invent. Technologists in service to artists will allow the new art forms to speak through the technology. ============================== DEMONSTRATIONS PROGRAM: The demonstration program will feature novel research prototypes that demonstrate the latest advancements in multimedia computing and communications technologies. Demonstrations will be presented in two different formats. Featured Demonstrations will be shown during conference sessions on Wednesday. The Featured Demonstrations and other Interactive Demonstrations will be available during the Wednesday evening Demonstration Session. The demonstrations will be exhibited at regular intervals by their creators. Time will also be provided for personal interaction with the systems. -------------------------------------------------------- Interactive Demonstrations: 7:00 pm -- 10:00 pm The multimedia forum kiosk and Narli Christopher M. Hoadley, Sherry Hsi, and Benjamin Berman, University of California at Berkeley Collaborative multimedia in SHASTRA Chandrajit Bajaj and S. Cutchin, Purdue University Automatic recognition of film genres Wolfgang Effelsberg, Stephan Fischer, and Rainer Lienhart, University of Mannheim HEIDI-II: A testbed for interactive multimedia delivery and communication Max Ott, G. Michelitsch, and J. Hearn, C&C Research Labs, NEC USA An object-oriented model for the semantic interpretation of multimedia data Rob Adams, James Griffioen, and Raj Yavatkar, University of Kentucky Managing real-time services in multimedia networks using dynamic visualization a nd high-level controls G. Pacifici, M.C. Chan, and Rolf Stadler, Columbia University =================== VIDEO PROGRAM AND CONFERENCE VIDEOTAPE A collection of videotapes demonstrating multimedia systems and ideas has been selected based on technical content and relevance to the conference themes. These videotapes have been assembled into the conference videotape, which will be presented during the conference in the demonstrations area and over the television system in the conference hotel. In addition, the videotape will be available for purchase at the conference. The conference videotape is an important component of the conference because it allows you to see a range multimedia systems in action. =================== EXHIBITS PROGRAM ACM Multimedia'95 is vital for the entire spectrum of progressive executives, managers, investors, researchers, designers/developers, technical staff, software engineers, educators, and artists working in any and all aspects of state-of-the-art multimedia research, development, and production -- the individuals who choose the products and technologies to be used in every major university and industrial research setting. More than one-half of Multimedia attendees recommend, specify, or approve purchases of the products and services represented. Businesses have a unique opportunity to reach these individuals through the Multimedia '95 exhibits program. Cost of space for Exhibitors in Exhibit Hall is $15.00 per square foot. Minimum space requirement is 80 square feet (8' x 10'). Exhibitors receive one complimentary full registration per company. Cost of space for Publishers in Publishers' Row is $12.00 per square foot. Sales of all types re restricted to Publishers' Row. Sponsorships and advertising are available to Exhibitors only. Exhibit Days are November 7 and 8, Tuesday and Wednesday. For further details contact: Don Collier DC Expositions, Inc. 555 Republic Drive, Suite 316, Plano, TX 75074 Phone: +1-214-423-4286 Fax: +1-214-423-4323 E-mail: dcexpo@aol.com ================== CONFERENCE RECEPTION The ACM Multimedia'95 Committee cordially invites you to a welcome reception on Tuesday, November 7th at the Center for the Arts Forum located at the Yerba Buena Gardens, 401 Mission Street, 6:30 PM to 9:00 PM. Come meet and greet your colleagues and catch up on the latest technology or just enjoy the beautiful Gardens that Yerba Buena is noted for. Refer to http://www.hia.com/hia/yerbabuena/ca-home.html for more information on Yerba Buena Gardens. We look forward to seeing you there. ================== CONFERENCE REGISTRATION Early registration date and cancellation date: October 8, 1995 Conference registration: EARLY LATE ----- ---- ACM members: $385 $455 non-members: 485 555 students: 125 195 Single Tutorial: EARLY LATE ----- ---- ACM members: $240 $265 non-members: 285 310 Multiple Tutorial: EARLY LATE ----- ---- ACM members: $185 $205 non-members: 220 240 For registration information, contact ACM Multimedia'95 Danieli & O'Keefe Associates, Inc 490 Boston Post Road Sudbury, MA 01776 Tel: +1-508-443-3330 x1230 or +1-800-524-1851 x1230 Fax: +1-508-443-4715 Completed registration forms must be mailed or faxed with payment in US dollars to: ACM Multimedia'95 Danieli & O'Keefe Associates, Inc 490 Boston Post Road Sudbury, MA 01776 Fax: +1-508-443-4715 Payment may be made by check or the following credit cards: AMEX, MC, Visa ================== GENERAL INFORMATION For an up-to-date information about the ACM Multimedia'95, refer to the World Wide Web page: http://acm.org/MM95/ or contact Judy Osteller ACM 1515 Broadway New York, NY 10036 Phone: +1-212-626-0605 Fax: +1-212-302-5826 E-mail: osteller@acm.org =================== HOTEL RESERVATIONS The host hotel for ACM Multimedia'95 is: The Hyatt Regency San Francisco 5 Embarcadero Center San Francisco, CA 94111 +1-415-788-1234 +1-800-233-1234 Room Rates: Single: $145.00 Double: $167.00 Business Plan Single: $162.00 Business Plan Double: $182.00 Triple Rooms: $187.00 Quad Rooms: $207.00 You must mention Multimedia'95 to receive the special conference rate. It is recommended that you make your reservations before October 8, 1995. Guests of the Hyatt Regency San Francisco have use of the in-hotel fitness center with aerobic equipment, as well as a waterfront path for walking and jogging. =========== AIRPORT TRANSPORTATION The Hyatt Regency is about 20 minutes from the airport. Taxi service costs approximately $30.00. SFO Airporter shuttles leave the airport every 10-20 minutes with service to the Hyatt at a cost of $8.00 one way; $14.00 round trip. For further information on the SFO Airporter, call +1-415-495-8404. ================== AIR TRANSPORTATION United Airlines serves San Francisco with both national and international flights. Special rates are available to conference participants flying between November 2 and November 12, 1995. These rates include a 5% discount on any United, United Express or United Shuttle published fare in the US and Canada or a l0% discount on business class or like fares. All tickets must be purchased a minimum of 7 days in advance. Reservations and schedule information may be obtained by calling the United Meetings Desk at +1-800-521-4041. Please refer to special meeting ID Code: 589KA. The meeting desk hours are Monday through Sunday, 7:00 A.M. to 10:00 P.M. Eastern Time. =================== CAR RENTAL DISCOUNTS United is also offering car rental discounts of 10% through AVIS and ALAMO. You may make reservations by using the United Meeting Desk number at +1-800-521-4041 and referring to Meeting ID Code: 589KA. AVIS has a rental office located at the Hyatt Regency San Francisco, headquarters for ACM Multimedia'95. ================ PROGRAM COMMITTEE Program Chair Polle T. Zellweger, Xerox PARC Associate Chairs David P. Anderson, Sonic Solutions, USA Florian Brody, Institute of Advanced Communications, Austria Art Center College of Design, USA Dick C.A. Bulterman, CWI, Netherlands Edward A. Fox, Virginia Tech, USA Forouzan Golshani, Arizona State University, USA Ralf Guido Herrtwich, IBM Eurocoordination Multimedia, France Hiroshi Ishii, NTT Human Interface Laboratories, Japan Thomas D.C. Little, Boston University, USA Wendy Mackay, Rank Xerox Research Centre, Cambridge, UK Vicki de Mey, Apple Computer, USA A. Desai Narasimhalu, National University of Singapore Jonathan Rosenberg, c|net, USA Eve M. Schooler, California Institute of Technology, USA Brian Smith, Cornell University, USA William Tetzlaff, IBM Yorktown, USA Harrick Vin, University of Texas at Austin, USA Abel Weinrib, Intel, USA Nicole Yankelovich, Sun Microsystems Laboratories, USA Members David Boyer, Bellcore, USA M. Cecelia Buchanan, Washington State University, USA John Buford, University of Massachusetts, Lowell, USA Tom Calvert, Simon Fraser University, Canada Shih-Fu Chang, Columbia University, USA Gino Cheng, USC, USA Tzi-cker Chiueh, SUNY Stony Brook, USA Jon Crowcroft, UCL, UK Asit Dan, IBM Yorktown, USA Roger Dannenberg, CMU, USA Glorianna Davenport, MIT Media Lab, USA Jim Foley, Georgia Tech, USA Mark E. Frisse, Washington University, USA J.J. Garcia-Luna, UC Santa Cruz, USA Franca Garzotto, Politecnico di Milano, Italy Arif Ghafoor, Purdue, USA Arding Hsu, Siemens Corporate Research, USA Ramesh Jain, UC San Diego, USA Kevin Jeffay, University of North Carolina, USA Randy Kaplan, Educational Testing Service, USA Randy Katz, UC Berkeley, USA Aurel A. Lazar, Columbia University, USA Bryan Lyles, Xerox PARC, USA Mark Manasse, DEC SRC, USA Hermann Maurer, Graz University of Technology, Austria Derek McAuley, Cambridge University, UK Bernard Merialdo, Institut EURECOM, France Beth Mynatt, Georgia Tech, USA Roy Rada, University of Liverpool, UK P. Venkat Rangan, UC San Diego, USA David Redell, DEC SRC, USA Norbert Streitz, GMD-IPSI, Germany Dan Swinehart, Xerox PARC, USA David Tennenhouse, MIT, USA Laura Teodosio, BAM! Software, Inc., USA Michael Zyda, Naval Postgraduate School, USA Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA14249; Tue, 5 Sep 1995 18:31:02 -0500 Received: from t2.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA14244; Tue, 5 Sep 1995 18:31:01 -0500 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by t2.cray.com (8.6.12/CRI-smart-8-2.4) with ESMTP id SAA21852 for ; Tue, 5 Sep 1995 18:31:00 -0500 Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.5) with SMTP id SAA10636 for ; Tue, 5 Sep 1995 18:30:56 -0500 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 5 Sep 1995 18:30:22 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 5 Sep 1995 16:39:07 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 5 Sep 1995 16:38:00 -0400 Date: Tue, 5 Sep 1995 16:38:00 -0400 X400-Originator: /dd.id=1683277/g=bhumip/i=b/s=khasnabish/@bnr.ca To: :;@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.956:05.08.95.20.39.07] X400-Content-Type: P2-1984 (2) Content-Identifier: CFP (textFile... From: "bhumip (b.) khasnabish" Sender: "bhumip (b.) khasnabish" Message-Id: <"23133 Tue Sep 5 16:40:06 1995"@bnr.ca> Subject: CFP (textFile): Workshop on Enterprise Networking (in ICC-96) X-Bulletin: potential contributors content-length: 4595 the workshop will be held either on june 23 or june 27, (more likely) 1996 will let u know once it is finalized Thanx >------------------------------------------------------------------------ -o-----------------------------------------------------o- | EEEEEEEE N N W W " 9999999 666666 | | E N N N W W 99 99 66 | | EEEEE N N N W W W == 9999999 66666666 | | E N N N W W W W 99 66 66 | | EEEEEEEE N N W W 99999 66666666 | -o-----------------------------------------------------o- FIRST INTERNATIONAL IEEE WORKSHOP ON ENTERPRISE NETWORKING in Conjunction with ICC/SUPERCOMM '96, June 23-27, Dallas, Tx, USA =================================================================================== CALL FOR PARTICIPATION =================================================================================== This is the first International workshop on Enterprise Networking (EN) sponsored by the IEEE Communications Society's Technical Committee on Enterprise Networking. It attempts to bring together the EN service providers, corporate network managers, technicians, and operation personnel in informal environment, so that they can exchange their ideas and view points with peers and experts standing on the same platform. The goal is to bridge the gap across: (i) Enterprise-wide business drivers and (ii) Technology-driven solutions and enablers. Attendees will be benefitted by EXCHANGING their ideas on future directions of ENs in an informal environment with the professionals in varieties of areas (e.g., service providers, implementors) of ENs. They will also be able to SHARPEN their competitive edge by actively participating in the presentations and interacting with the internationally recognized experts on ENs. The purposes of this single-track one-day workshop are to: (1) Present the current view of the researchers, vendors, implementors, computing and telecommunications service providers, operators, and users. (2) Provide the attendees with the future directions of growth of the ENs. For example, how the standardization and interoperability issues can be resolved, how the emerging technologies like ATM, PCS, full-duplex LAN services, etc. can be exploited to help the evolution of the ENs, and (3) Show how the integration and interplays of ENs with the Internets and the information superhighways are going to create a really open universe, and how the billing and security issues can be handled in such scenarios. (4) Explore the principles and problems underlying the design, deployment, management and operations of ENs. Presentations are being planned in the following FOUR themes, and hence papers covering these areas are explicitly solicited and will be given preference: o Experience with and Current Challenges of the ENs o Future Directions of Growth of the ENs, o Integration of ENs with Emerging Technologies/Services, o Outsourcing the Operations, Management and Design of ENs. Please submit FOUR copies of summary (maximum 15 double-spaced pages excluding figures) of technical contribution mentioning the target theme to the organizing chair at the following address. Bhumip Khasnabish Lab. 5, Mail Stop: 262, Bell-Northern Research Ltd. 3500 Carling Avenue, P. O. Box: 3511, Station C Ottawa, Ontario, Canada, K1Y 4H7. Tel: +1 613 763 2698 Fax: +1 613 763 2626 Internet: bhumip@bnr.ca All contributions will be peer-reviewed and the accepted ones will be published in the proceedings of the workshop. Attendance to this workshop may be limited to 150 participants with preference given to those who 'submitted' or 'have accepted' contribution(s) to this workshop. The schedule (almost final) for this workshop is as follows: Deadline for Submission: ............. 15-th September, 1995. Acceptance Notification: ............. 1st January, 1996. Presentation Materials (10 pages) Due: 1st March, 1996. PROGRAM COMMITTEE: Chair: Bhumip Khasnabish (BNR, Canada) ComSoc Co-Ordinator: Tom Stevenson (IEEE ComSoc HQ) Committee Members: Majid Ahmadi (U of Windsor, Canada) Salah Aidarous (BNR, Canada) Robert S. Braudy (DMW Group, USA) Bob Fike (RNF Systems, USA) David Kirsch (SunNetworks, USA) Ken Lutz (BellCore, USA) Branislav Meandzija (MetaAccess, USA) Totumo Murase (NEC, Japan) Toshihiro Sikama (Mitsubishi, Japan) Karen Seo (BBN, USA) Douglas N. Zuckerman (AT&T, USA) Steven Weinstein (NEC, USA) Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA15437; Thu, 17 Aug 1995 09:02:30 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA15429; Thu, 17 Aug 1995 09:02:28 -0500 Received: from kddfuji.lab.kdd.co.jp (root@kddfuji.lab.kdd.co.jp [192.26.91.15]) by timbuk.cray.com (8.6.12/CRI-8-1.16) with ESMTP id JAA07832 for ; Thu, 17 Aug 1995 09:02:22 -0500 Received: from kddnews.nes.lab.kdd.co.jp by kddfuji.lab.kdd.co.jp (8.6.12+2.4W/KDDLAB-2.0MX) id XAA18730; Thu, 17 Aug 1995 23:02:20 +0900 Received: from localhost by kddnews.nes.lab.kdd.co.jp (8.6.12+2.4W/KDD-1.00MX) id XAA00609; Thu, 17 Aug 1995 23:02:04 +0900 Message-Id: <199508171402.XAA00609@kddnews.nes.lab.kdd.co.jp> To: tcplw@cray.com Subject: Please send me a reference in RFC1323 Date: Thu, 17 Aug 95 23:02:04 +0900 From: Tohru Asami content-length: 608 Hello. I'm rather new in this field. The main aim that I decided to join tcplw is to get the following reference described in RFC1323. [Jacobson90c] Jacobson, V., "Modified TCP congestion avoidance algorithm", Message to end2end-interest mailing list, April 1990. If you have a copy of this message, would you forward it to me? Thanks in advance. Regards, -- Tohru Asami: Network Engineering Support Group, KDD R&D Labs. 2-1-15 Ohara Kamifukuoka-shi, Saitama 356, Japan Phone: +81 492 78 7890, FAX: 7510, E-Mail: tru@lab.kdd.co.jp KDD = an international telecommunication company in Japan Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA26581; Tue, 1 Aug 1995 18:12:44 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA26576; Tue, 1 Aug 1995 18:12:43 -0500 Received: from arapaho.cse.ucsc.edu (arapaho.cse.ucsc.edu [128.114.7.12]) by timbuk.cray.com (8.6.12/CRI-8-1.16) with ESMTP id SAA21341 for ; Tue, 1 Aug 1995 18:12:42 -0500 Received: (from pang@localhost) by arapaho.cse.ucsc.edu (8.6.10/8.6.9) id QAA20791 for tcplw@cray.com; Tue, 1 Aug 1995 16:12:40 -0700 Date: Tue, 1 Aug 1995 16:12:40 -0700 From: Alex Pang Message-Id: <199508012312.QAA20791@arapaho.cse.ucsc.edu> To: tcplw@cray.com Subject: IEEE Visualization'95 content-length: 2362 IEEE Visualization 95 Sponsored by IEEE Computer Society Technical Committee on Computer Graphics In Cooperation with ACM/SIGGRAPH October 29 - November 3, 1995 Atlanta Airport Hilton and Towers Atlanta, Georgia +-------------------------------------------------------------------------+ | Get complete, up-to-date listings of program information from | | URL: http://www.gatech.edu/vis95.html, | | http://davinci.informatik.uni-kl.de/Vis95 (active late July) | | FTP server: ftp.erc.msstate.edu, directory vis95, or | | vis95.informatik.uni-kl.de, directory info, or | | contact: Bill Ribarsky, Georgia Institute of Technology, 404.894.6148, | | bill.ribarsky@oit.gatech.edu | +-------------------------------------------------------------------------+ Welcome to IEEE Visualization 95 The sixth annual IEEE Visualization conference will have the strongest and most varied technical program ever. This year we will extend our focus to all aspects of data and information visualization with applications ranging across scientific, medical, engineering, business, and entertainment fields. For the first time, we will have 3 Symposia (Parallel Rendering, Information Visualization, and Biomedical Visualization). In addition you will have your pick of a full slate of tutorials on Sunday, Monday, and Tuesday. The technical program on Wednesday will begin with a Keynote Address and Panel, followed by concurrent sessions of papers, panels, and case studies presenting the latest issues, research, and applications in visualization. Demonstrations of visualization products, tools, and applications will begin mid-day on Wednesday and continue through Thursday afternoon. Birds of a Feather sessions are scheduled on several days throughout the conference. We encourage you to join us in Atlanta the week of October 30 - November 3, 1995 for IEEE Visualization 95. You will have a unique opportunity to confer with researchers, developers, and your colleagues. Dont miss this conference, or you will miss the most effective compilation of significant topics in visualization this year. Bill Ribarsky, Georgia Institute of Technology Nahum Gershon, The MITRE Corporation IEEE Visualization 95 Conference Co-Chairs Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA08720; Tue, 1 Aug 1995 11:29:24 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA08714; Tue, 1 Aug 1995 11:29:23 -0500 Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by timbuk.cray.com (8.6.12/CRI-8-1.16) with SMTP id LAA29504 for ; Tue, 1 Aug 1995 11:29:16 -0500 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Aug 1995 10:50:41 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Aug 1995 10:26:32 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Aug 1995 10:25:00 -0400 Date: Tue, 1 Aug 1995 10:25:00 -0400 X400-Originator: /dd.id=1683277/g=bhumip/i=b/s=khasnabish/@bnr.ca To: :;@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.051:01.07.95.14.26.32] X400-Content-Type: P2-1984 (2) Content-Identifier: CFP (textFile... From: "bhumip (b.) khasnabish" Sender: "bhumip (b.) khasnabish" Message-Id: <"13280 Tue Aug 1 10:27:38 1995"@bnr.ca> Subject: CFP (textFile): Workshop on Enterprise Networking (in ICC-96) X-Bulletin: potential contributors content-length: 4579 the workshop will be held either on june 23 or june 27, 1996 will let u know once it is finalized Thanx >------------------------------------------------------------------------ -o-----------------------------------------------------o- | EEEEEEEE N N W W " 9999999 666666 | | E N N N W W 99 99 66 | | EEEEE N N N W W W == 9999999 66666666 | | E N N N W W W W 99 66 66 | | EEEEEEEE N N W W 99999 66666666 | -o-----------------------------------------------------o- FIRST INTERNATIONAL IEEE WORKSHOP ON ENTERPRISE NETWORKING in Conjunction with ICC/SUPERCOMM '96, June 23-27, Dallas, Tx, USA =================================================================================== CALL FOR PARTICIPATION =================================================================================== This is the first International workshop on Enterprise Networking (EN) sponsored by the IEEE Communications Society's Technical Committee on Enterprise Networking. It attempts to bring together the EN service providers, corporate network managers, technicians, and operation personnel in informal environment, so that they can exchange their ideas and view points with peers and experts standing on the same platform. The goal is to bridge the gap across: (i) Enterprise-wide business drivers and (ii) Technology-driven solutions and enablers. Attendees will be benefitted by EXCHANGING their ideas on future directions of ENs in an informal environment with the professionals in varieties of areas (e.g., service providers, implementors) of ENs. They will also be able to SHARPEN their competitive edge by actively participating in the presentations and interacting with the internationally recognized experts on ENs. The purposes of this single-track one-day workshop are to: (1) Present the current view of the researchers, vendors, implementors, computing and telecommunications service providers, operators, and users. (2) Provide the attendees with the future directions of growth of the ENs. For example, how the standardization and interoperability issues can be resolved, how the emerging technologies like ATM, PCS, full-duplex LAN services, etc. can be exploited to help the evolution of the ENs, and (3) Show how the integration and interplays of ENs with the Internets and the information superhighways are going to create a really open universe, and how the billing and security issues can be handled in such scenarios. (4) Explore the principles and problems underlying the design, deployment, management and operations of ENs. Presentations are being planned in the following FOUR themes, and hence papers covering these areas are explicitly solicited and will be given preference: o Experience with and Current Challenges of the ENs o Future Directions of Growth of the ENs, o Integration of ENs with Emerging Technologies/Services, o Outsourcing the Operations, Management and Design of ENs. Please submit FOUR copies of summary (maximum 15 double-spaced pages excluding figures) of technical contribution mentioning the target theme to the organizing chair at the following address. Bhumip Khasnabish Lab. 5, Mail Stop: 262, Bell-Northern Research Ltd. 3500 Carling Avenue, P. O. Box: 3511, Station C Ottawa, Ontario, Canada, K1Y 4H7. Tel: +1 613 763 2698 Fax: +1 613 763 2626 Internet: bhumip@bnr.ca All contributions will be peer-reviewed and the accepted ones will be published in the proceedings of the workshop. Attendance to this workshop may be limited to 150 participants with preference given to those who 'submitted' or 'have accepted' contribution(s) to this workshop. The schedule (almost final) for this workshop is as follows: Deadline for Submission: ............. 15-th September, 1995. Acceptance Notification: ............. 1st January, 1996. Presentation Materials (10 pages) Due: 1st March, 1996. PROGRAM COMMITTEE: Chair: Bhumip Khasnabish (BNR, Canada) ComSoc Co-Ordinator: Tom Stevenson (IEEE ComSoc HQ) Committee Members: Majid Ahmadi (U of Windsor, Canada) Salah Aidarous (BNR, Canada) Robert S. Braudy (DMW Group, USA) Bob Fike (RNF Systems, USA) David Kirsch (SunNetworks, USA) Ken Lutz (BellCore, USA) Branislav Meandzija (MetaAccess, USA) Totumo Murase (NEC, Japan) Toshihiro Sikama (Mitsubishi, Japan) Karen Seo (BBN, USA) Douglas N. Zuckerman (AT&T, USA) Steven Weinstein (NEC, USA) Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA29661; Thu, 22 Jun 1995 04:38:20 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA29656; Thu, 22 Jun 1995 04:38:18 -0500 Received: from zebra.cosy.sbg.ac.at (zebra.cosy.sbg.ac.at [141.201.2.25]) by timbuk.cray.com (8.6.11/CRI-gw-8-1.6) with ESMTP id EAA12109 for ; Thu, 22 Jun 1995 04:38:13 -0500 Received: from dodo.cosy.sbg.ac.at (dodo.cosy.sbg.ac.at [141.201.2.47]) by zebra.cosy.sbg.ac.at (8.6.11/8.6.11) with SMTP id LAA08182 for ; Thu, 22 Jun 1995 11:30:45 +0200 From: Thomas Auer Received: by dodo.cosy.sbg.ac.at; (5.65/1.1.8.2/09Feb95-0304PM) id AA09045; Thu, 22 Jun 1995 11:37:55 +0200 Date: Thu, 22 Jun 1995 11:37:55 +0200 Message-Id: <9506220937.AA09045@dodo.cosy.sbg.ac.at> To: tcplw@cray.com Subject: CFP: PROMS 95 content-length: 7502 Dear Sir, this mail includes the call for papers of the PROMS 95 workshop for multimedia systems which will be held at Salzburg University. If you have any questions, please feel free to contact me. If this mail is of no interest for you, please apologize the inconvenience. best regards, Thomas Auer -- * Thomas Auer | Think where man's glory most begins and ends. * * tom@cosy.sbg.ac.at | And say my glory was I had such friends. * * Univ. of Salzburg, | William Butler Yeats * * AUSTRIA | http://www.cosy.sbg.ac.at/~tom/tom.html * _______________________________________________________________________ begin of CFP _______________________________________________________________________ PROMS '95 Second Workshop on Protocols for Multimedia Systems "Mozart on Multimedia Highways" Salzburg, Austria October 9-12, 1995 An international workshop organized by University of Salzburg and TechnoZ-Fachhochschule, Austria sponsored by TechnoZ GmbH Salzburg, Sony Salzburg, Austria Siemens Wien, Austria http://www.cosy.sbg.ac.at/proms/ CALL FOR PAPERS OBJECTIVE ********* The 2nd Workshop on Protocols for Multimedia Systems (PROMS' 95) is intended to contribute to scientific, strategical and practical cooperation between research institutes and industrial companies with emphasis on multimedia protocols and intelligent management tools for (super)highways. The motto "Mozart on multimedia highways" is not only to remember of the great musician born in Salzburg, the host city of PROMS 95, but also to focus on the NEW sound of this workshop: Are the (super)highways today intelligent enough for the transmission of the "Magic Flute"? The PROMS' 95 objectives: - To present, address and discuss research, project lines and achievements on protocols and intelligent management tools for multimedia applications with emphasis on their usage on network (super)highways. - To focus on scientific contributions, standardization and practical results in the area of multimedia protocols and their adaptation to ATM, satellite and mobile networks, as well as in the area of intelligent network management, policy based and intelligent routing, traffic prediction, security and protocol accounting - To emphasize on practical integration of the research on modelling, simulation, performance analysis of multimedia protocols and intelligent networking techniques for efficient multimedia application networking in the various forms of today existing and future information (super)highways - To demonstrate and evaluate efficiency of multimedia applications ("Multimedia live") using new protocol functions and intelligent networking tools considering end user criteria and requirements for Costs, Quality of Service, Network Access, Routing Policy, Security, Application Interface, and System Integrity. PROGRAM COMMITTEE ***************** Horst D. Clausen (Uni Salzburg, Austria) N. Georganas (Uni Ottawa, Canada) Bezalel Gavish (Vanderbilt Uni, USA) M.S. Obaidat (City Uni of New York, USA) Shi-Kuo Chang (Uni Pittsburgh, USA) C. Bormann (Uni Bremen, Germany) Son T. Vuong (British Columbia, Canada) B. Atwood (Concordia, Canada) Jun-ichi Mizusawa (NTT, Japan) O. Spaniol (RWTH Aachen, Germany) A. Seneviratne (University of Technology, Australia) H. Kruse (Ohio Uni, USA) E. Biersack (EUROCOM, France) I. Miloucheva (ATS, Germany) A. Schill (TU Dresden, Germany) M. Kaul (GMD, Germany) R.A.Butler (Robert Gordon Uni, UK) PROGRAM CHAIR ************* Prof. Dr. habil. Ulrich Hofmann (Uni Salzburg, Austria) SCOPE ***** Research contributions, standardization and practical experience with design, implementation, integration, interworking and management of multimedia protocols and applications on the information (super)highways: - Media specific and QoS considerations in design and implementation of communication protocols - Application, media and protocol integration: Synchronization of media streams, orchestration of functional units, - Multiparty and group communication protocols and applications, Multicast networking and routing, group management - Network access and management functionality: accounting, security, authentication, privacy, intelligent and policy based routing - Mobile networking and routing, multimedia communication architectures for mobile networks, management of mobile networks - Performance analysis of multimedia applications and protocols: modeling, simulation, and control theoretical approach - Accounting and costs of communication services - Optimization of protocol and application performance for different network QoS provision (i.e. high delay paths) - Protocol and application adaptation to ATM QoS and Adaptation Layers, protocol performance over ATM - Protocols and applications for satellite networks and gateways, Protocol performance over satellite, including hybrid satellite/terrestrial networks, and satellite applications - Multimedia applications and IP/IPnG interworking - Multimedia applications on the (super)higways: video-on-demand, virtual community, teleworking, teleteaching - Resource reservation and multimedia traffic engineering - Implementation of multimedia protocols and applications: integration of media storage and communication mechanisms, operating system and high performance issues, efficient interfacing - Techniques for specification of multimedia protocols and application, methods for real-time test and analysis of implementations, SUBMISSION ********** - Please send your papers in postscript form. via email: proms-submission@cosy.sbg.ac.at via anonymous ftp: ftp.cosy.sbg.ac.at /pub/proms via mail: PROMS 95 Institut fuer Computerwissenschaften z.Hd. Prof. Ulrich Hofmann Jakob-Haringer-Str. 2 A-5020 Salzburg, AUSTRIA - Submissions must include abstract and keywords. IMPORTANT DATES *************** Submissions due: Aug. 20, 1995 Author notification: Sept. 1, 1995 We will appreciate also later submissions if they are significant for PROMS 95. For extended information about organization, keynote speaker, demonstration, venue, registration and .... Mozart please refer to: Proms on the WWW or contact: Prof. Ulrich Hofmann uho@cosy.sbg.ac.at Dr. Ilka Miloucheva ilka@prz.tu-berlin.de WELCOME TO SALZBURG ******************* Summer Art Festival, Mozart, Trapp-family, Mountains, Lakes, Saltmines, Palaces and Gardens, Mirabell and Hellbrunn - these are some words which are inherently connected with the city of Salzburg. Attention for the guests of Salzburg-a "Schnuerlregen"(a special kind of rain), mixed with the "Little Night Music" over the rooftops ... Especially for our PROMS 95 guests: - Different kinds of demos with multimedia and multicast protocols, satellite/ATM interconnection, transathlantic demos, - Multimedia Welcome at the "High Tech" Sony factury in Salzburg - 4 PROMS 95 Days for workshopping at Salzburg University and TechnoZ Research - "Sound of Music" Tour .... Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA20524; Fri, 9 Jun 1995 06:22:58 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA20519; Fri, 9 Jun 1995 06:22:56 -0500 Received: from dectcp.cineca.it (dectcp.cineca.it [130.186.1.53]) by timbuk.cray.com (8.6.11/CRI-gw-8-1.6) with SMTP id GAA27546 for ; Fri, 9 Jun 1995 06:22:42 -0500 Received: by dectcp.cineca.it (5.57/Ultrix3.0-C) id AA09287; Fri, 9 Jun 95 13:22:30 +0200 Received: by CE.UniPR.IT (4.1/SMI-4.1) id AA28255; Fri, 9 Jun 95 13:22:39 +0200 Date: Fri, 9 Jun 95 13:22:39 +0200 From: broggi@verdi.eng.unipr.it (Alberto Broggi) Message-Id: <9506091122.AA28255@CE.UniPR.IT> To: tcplw@cray.com Subject: CALL FOR PAPERS content-length: 4054 Dear colleague: This message was sent to some different mailing-lists: should you receive multiple copies of this call-for-papers, please accept my apologies. If you are interested in it, consider submitting papers as well as redistributing it and, if you maintain a list of call-for-papers, also advertising it. Other info may be accessed in: http://WWW.CE.UniPR.IT/rti Best regards, Alberto Broggi ============================================================================== CALL FOR PAPERS JOURNAL OF REAL-TIME IMAGING Academic Press Special Issue on Special-Purpose Architectures for Real-Time Imaging Nowadays, a number of different problems are solved through image processing techniques (e.g. industrial inspection, robot guidance, unmanned vehicles,..., to cite only a few examples). The problem of processing images in real-time has been generally addressed and solved through the use of high-performance computer systems, developed ad-hoc to meet the specific requirements of the applications. Serial or parallel architectures have been enhanced through the addition of various bus systems, interprocessor communication networks, and other features explicitly designed to face the hard constraints imposed by real-time processing, such as I/O (data acquisition and output), data communications among processors (in multi-processor systems),... A number of different special-purpose architectures for image analysis have been proposed and developed, but seldom the presentation focuses on the discussion of both the hard real-time requirements (applications) and the hardware solutions which have been chosen (computer architectures). The TOPICS of this Special Issue include, but are not limited to: * Design of application-specific VLSI architectures; * Performance analysis and comparison among different architectural solutions; * Hardware mapping of parallel algorithms; * VLSI architectures for HDTV and image compression; * Hardware support for multimedia systems; * Vision-based real-time robot and vehicle navigation; * Massively parallel architectures for low-level vision; * Hardware neural solutions; * Experience on highly demanding vision applications. Prospective authors are encouraged to submit papers with a strong emphasis on the match between the application requirements and the chosen architectural solutions, detailing the ad-hoc hardware enhancements. Papers should describe systems which have been designed for a specific target application or which have proved to be particularly suited for a given task. MANUSCRIPT SUBMISSION: * Authors should send 5 copies of their full paper (about 15 double-spaced pages) to Alberto Broggi (whose address is indicated below). * The closing date for submission is December 10th, 1995. * Publication is tentatively expected to take place in mid 1996. Accepted manuscripts will need to comply with all author guidelines of Journal of Real-Time Imaging, available upon request from the guest editors or from jrti@rtlab12.njit.edu. GUEST EDITORS: Alberto BROGGI Francesco GREGORETTI Dip. di Ingegneria dell'Informazione Dip. di Elettronica Viale delle Scienze Corso Duca degli Abruzzi University of Parma Polytechnic of Turin I-43100 Parma, Italy I-10129 Turin, Italy Phone: +39-521-905707 Phone: +39-11-5644081 Fax: +39-521-905723 Fax: +39-11-5644099 E-Mail: broggi@CE.UniPR.IT E-Mail: gregor@PoliTO.IT An up-to-date electronic version of this call for papers and related information can be obtained via anonymous FTP from the host CE.UniPR.IT in the directory /rti or via World Wide Web at: http://WWW.CE.UniPR.IT/rti. Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA20563; Wed, 7 Jun 1995 11:22:00 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA20194; Wed, 7 Jun 1995 11:19:33 -0500 Received: from deacon (deacon.cogsci.ed.ac.uk [129.215.144.7]) by timbuk.cray.com (8.6.11/CRI-gw-8-1.4) with ESMTP id KAA03816 for ; Wed, 7 Jun 1995 10:36:21 -0500 Received: from ossian.cogsci.ed.ac.uk (ossian.cogsci.ed.ac.uk [129.215.110.21]) by deacon (8.6.10/8.6.9) with ESMTP id QAA12387; Wed, 7 Jun 1995 16:01:10 +0100 From: John Lee (EdCaad) Received: (john@localhost) by ossian.cogsci.ed.ac.uk (8.6.10/8.6.9) id PAA02924; Wed, 7 Jun 1995 15:53:34 +0100 Date: Wed, 7 Jun 1995 15:53:34 +0100 Message-Id: <199506071453.PAA02924@ossian.cogsci.ed.ac.uk> To: ag-exp-l%ndsuvm1.BITNET@forsythe.Stanford.EDU, agosta@sumex-aim.stanford.edu, ai-ed@sun.com, ai-medicine@medmail.Stanford.EDU, ai-nat@adfa.oz.au, ai-stats@watstat.uwaterloo.ca, aisb@cogs.sussex.ac.uk, announcements.chi@xerox.com, arl@arl1.wustl.edu, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, bcs-hci-request@mailbase.ac.uk, ccrc@dworkin.wustl.edu, cellular@dfv.rwth-aachen.de, cip@bbn.com, cnom@maestro.bellcore.com, cogsci@cogsci.ed.ac.uk, cybsys-l@bingvmb.cc.binghamton.edu Subject: FINAL announcement: IMMI-1 content-length: 1421 IMMI-1 First International Workshop on Intelligence and Multimodality in Intelligent Interfaces Thursday 13th July -- Friday 14th July 1995 Human Communication Research Centre and EdCAAD Research Unit University of Edinburgh, Scotland, UK Registration is still available for a limited number of discussants to join the IMMI-1 Workshop. Participants with experience of practical applications in this area, especially in an industrial context, are particularly encouraged. The Workshop will be held in Edinburgh City Chambers. Further information, including registration forms, details of accommodation, and the complete Workshop Programme, may be found at http://www.cogsci.ed.ac.uk/~john/IMMI/ or by enquiry to John Lee at HCRC (address below). Apologies to those who receive this FINAL announcement more than once. IMMI-1 is supported by the British HCI Group, AAAI, ACL Sigmedia and BT. --------------------------------------------------------------------------- John R. Lee EdCAAD and Human Communication Research Centre Dept. of Architecture University of Edinburgh University of Edinburgh 2 Buccleuch Place 20 Chambers Street Edinburgh EH8 9LW Edinburgh EH1 1JZ Scotland, UK. Scotland, UK. Tel: +44 131 650 2335/7 Tel: +44 131 650 4420 Fax: +44 131 667 0141 Fax: +44 131 667 4587 Email: J.Lee@ed.ac.uk --------------------------------------------------------------------------- Received: by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA12260; Fri, 2 Jun 1995 16:34:16 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.x/CRI-5.15.b.orgabbr Sdiv) id AA12254; Fri, 2 Jun 1995 16:34:13 -0500 Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by timbuk.cray.com (8.6.11/CRI-gw-8-1.4) with SMTP id QAA07829 for ; Fri, 2 Jun 1995 16:34:10 -0500 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 16:02:52 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 15:58:45 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 15:58:00 -0400 Date: Fri, 2 Jun 1995 15:58:00 -0400 X400-Originator: /dd.id=1683277/g=bhumip/i=b/s=khasnabish/@bnr.ca To: :;@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.958:02.05.95.19.58.45] X400-Content-Type: P2-1984 (2) Content-Identifier: CFP - Worksho... From: "bhumip (b.) khasnabish" Sender: "bhumip (b.) khasnabish" Message-Id: <"20029 Fri Jun 2 15:59:27 1995"@bnr.ca> Subject: CFP - Workshop on Enterprise Networking X-Bulletin: friends interested in Enterprise Networking content-length: 6249 Dear Friends and Colleagues: Attached herewith is the CFP of the 1st IEEE international workshop on Enterprise Networking. I would appreciate if you could kindly post it in your organization and/or circulate it among your peers, colleagues, students and friens who could be interested in Enterprise Networking. Thank you all in advance. (you may receive this CFP more than once if your internet address appears in multiple news group or exploder lists; sorry about this) Bhumip. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ============================================================= -o-----------------------------------------------------o- | EEEEEEEE N N W W " 9999999 666666 | | E N N N W W 99 99 66 | | EEEEE N N N W W W == 9999999 66666666 | | E N N N W W W W 99 66 66 | | EEEEEEEE N N W W 99999 66666666 | -o-----------------------------------------------------o- FIRST INTERNATIONAL IEEE WORKSHOP ON ENTERPRISE NETWORKING in Conjunction with ICC/SUPERCOMM '96 Dallas, Tx, USA ========================================================= CALL FOR PARTICIPATION ========================================================= This is the first International workshop on Enterprise Networking (EN) sponsored by the IEEE Communications Society's Technical Committee on Enterprise Networking. It attempts to bring together the EN service providers, corporate network managers, technicians, and operation personnel in informal environment, so that they can exchange their ideas and view points with peers and experts standing on the same platform. The goal is to bridge the gap across: (i) Enterprise-wide business drivers and (ii) Technology-driven solutions and enablers. Attendees will be benefitted by EXCHANGING their ideas on future directions of ENs in an informal environment with the professionals in varieties of areas (e.g., service providers, implementors) of ENs. They will also be able to SHARPEN their competitive edge by actively participating in the presentations and interacting with the internationally recognized experts on ENs. The purposes of this single-track one-day workshop are to: (1) Present the current view of the researchers, vendors, implementors, computing and telecommunications service providers, operators, and users. (2) Provide the attendees with the future directions of growth of the ENs. For example, how the standardization and interoperability issues can be resolved, how the emerging technologies like ATM, PCS, full-duplex LAN services, etc. can be exploited to help the evolution of the ENs, and (3) Show how the integration and interplays of ENs with the Internets and the information superhighways are going to create a really open universe, and how the billing and security issues can be handled in such scenarios. (4) Explore the principles and problems underlying the design, deployment, management and operations of ENs. Presentations are being planned in the following FOUR themes, and hence papers covering these areas are explicitly solicited and will be given preference: o Experience with and Current Challenges of the ENs o Future Directions of Growth of the ENs, o Integration of ENs with Emerging Technologies/Services, o Outsourcing the Operations, Management and Design of ENs. Please submit FOUR copies of summary (maximum 15 double-spaced pages excluding figures) of technical contribution mentioning the target theme to the organizing chair at the following address. Bhumip Khasnabish Lab. 5, Mail Stop: 262 Bell-Northern Research Ltd. 3500 Carling Avenue P. O. Box: 3511, Station C Ottawa, Ontario, Canada, K1Y 4H7. Tel: +1 613 763 2698 Fax: +1 613 763 2626 Internet: bhumip@bnr.ca All contributions will be peer-reviewed and the accepted ones will be published in the proceedings of the workshop. Attendance to this workshop may be limited to 150 participants with preference given to those who 'submitted' or 'have accepted' contribution(s) to this workshop. The schedule (almost final) for this workshop is as follows: Deadline for Submission: ............. 15-th September, 1995. Acceptance Notification: ............. 1st January, 1996. Presentation Materials (10 pages) Due: 1st March, 1996. PROGRAM COMMITTEE: ------------------- Program Chair: ............... Bhumip Khasnabish (BNR, Canada) Internet:bhumip@bnr.ca ComSoc Co-Ordinator: ..................... Tom Stevenson (IEEE ComSoc HQ) Internet:t.stevenson@ieee.org Committee Members: ................... Majid Ahmadi (U of Windsor, Canada) Internet:ahmadi@engn.uwindsor.ca Salah Aidarous (BNR, Canada) Internet:aidarous@bnr.ca Robert S. Braudy (DMW Group, USA) Internet:braudyb@aol.com Bob Fike (RNF Systems, USA) Internet:rlfike@aol.com David Kirsch (SunNetworks, USA) Internet:david.kirsch@east.sun.com Ken Lutz (BellCore, USA) kjl@bellcore.com Branislav Meandzija (MetaAccess, USA) Internet:meandzij@ucsbuxa.ucsb.edu Totumo Murase (NEC, Japan) Internet:murase@nwk.cl.nec.co.jp Toshihiro Sikama (Mitsubishi, Japan) Internet:sikama@hat.hon.melco.co.jp Karen Seo (BBN, USA) Internet:kseo@bbn.com Douglas N. Zuckerman (AT&T, USA) Internet:w2xd@mrspock.mt.att.com Steven Weinstein (NEC, USA) Internet:sbw@ccrl.nj.nec.com =================================================================== Thank you very much, With all the best wishes and regards, o---------------------------------------o |Dr. Bhumip Khasnabish, | |Lab. 5, Mail Stop: 262, | |Bell-Northern Research Ltd., | |3500 Carling Avenue, | |P. O. Box: 3511, Station C, | |Ottawa, Ontario, Canada, K1Y 4H7. | |.......................................| |Tel: +1 613 763 2698 | |Fax: +1 613 763 2626 | |Home: +1 613 596 6948 | |Email: bhumip@bnr.ca | o---------------------------------------o Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA02752; Mon, 3 Apr 1995 04:23:19 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA02744; Mon, 3 Apr 1995 04:23:17 -0500 Received: from interport.net (interport.net [199.184.165.1]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with ESMTP id EAA29946 for ; Mon, 3 Apr 1995 04:23:16 -0500 Received: from [204.74.3.214] (artist1.port.net [204.74.3.214]) by interport.net (8.6.10/8.6.10) with SMTP id FAA04643; Mon, 3 Apr 1995 05:11:46 -0400 Date: Mon, 3 Apr 1995 05:11:46 -0400 Message-Id: <199504030911.FAA04643@interport.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: (Recipient list suppressed) From: artist1@interport.net (David Blair) Subject: WAXWEB 2.0: INTERACTIVE 3D CINEMA ON THE WORLD WIDE WEB Content-Length: 9688 ********** FOR RELEASE ON APRIL 3, 1995 ************* WAXWEB 2.0: INTERACTIVE 3D CINEMA ON THE WORLD WIDE WEB CONTACT: DAVID BLAIR email: artist1@interport.net WAXWEB 2.0, THE FIRST INTERACTIVE FEATURE FILM ON THE WORLD WIDE WEB, IMPLEMENTS A DYNAMIC VERSION OF VRML, THE NEW GRAPHICS INDUSTRY STANDARD FOR VIRTUAL REALITY ON THE INTERNET, TO DELIVER REALTIME 3D NARRATIVE "VISUALIZATION" OVER THE EXISTING INTERNET BACKBONE. The WWW address for Waxweb 2.0 is http://bug.village.virginia.edu With a VRML browser: http://bug.village.virginia.edu/vrml WHAT IS WAXWEB 2.0? Created by DAVID BLAIR, Waxweb 2.0 is: The first interactive, intercommunicative FEATURE FILM on the WORLD WIDE WEB (Variety, 2.16.95). The first NETWORK-DISTRIBUTED narrative to offer REAL-TIME 3-D NAVIGATION through a story. The first LARGE-SCALE, DYNAMIC implementation of the VIRTUAL REALITY MODELING LANGUAGE (VRML), the 3-D METAFILE format for the INTERNET endorsed TODAY (4.3.94) by Silicon Graphics, TGS, Netscape, Digital, NEC, and many others. Waxweb is a project of the Brown University Graphics Laboratory, headed by Andries VanDam, with Tom Meyer serving as the technical director of the project. Based on David Blair's electronic feature film "WAX or the discovery of television among the bees" (85:00, 1991, distributed by FIRST RUN FEATURES), Waxweb is the LARGEST hypermedia narrative document on the World Wide Web. "WAX" itself was the first feature film sent over the Internet ("Historic First", Markoff, NYTimes, 4.93). In May, Waxweb 2.0 will become a CROSS-PLATFORM, NETWORK SYNCHRONIZED CD-ROM available from First Run Features. Available for Mac/Windows/Unix, it will run as a standalone on non-networked computers, and in synchronization with the Web site, for those who wish to publicly ADD TO THE STORY. Waxweb 2.0 Online contains: 3000 Web pages with approx. 25,000 hyperlinks; 85 minutes of digital video (the entire feature film); 5000 color stills; soundtrack in English, French, German, Japanese. Plus: MORE THAN 250 3-D VRML SCENES, FILLED WITH THOUSANDS OF HYPERLINKED PARTS. Every part of every object in the virtual world is an active button, triggering access to other 3D scenes, to the movie, to pictures, or to hypertext. WAXWEB IS DYNAMIC: Network users of Waxweb 2.0 can add to the narrative with their own immediate, publicly visible hypermedia: hypertext, pictures, audio, video, and hyperlinked VRML. In addition, all VRML objects in the network Waxweb database have their attached hyperlinks changed ON THE FLY, dependent on user interaction. In the near future, custom scenes dynamically recombining internal and user-added objects will allow the synthetic creation of a DYNAMIC, 3-D INTERSTORY on the network. WHAT IS THE VIRTUAL REALITY MODELING LANGUAGE? VRML 1.0 (VIRTUAL REALITY MODELING LANGUAGE, 10.94) was the result of a grassroots, Internet-wide effort, initiated by Mark Pesce, to define the standard for a 3-D metafile format which would allow DISTRIBUTED VIRTUAL REALITY over the existing Internet. VRML allows users of World-Wide Web browsers to view and interact with computer generated 3D models, scenes and virtual "worlds". The most distinctive attribute of VRML is that 3-D VRML objects can have hyperlinks attached to their different parts. Users can move around 3-D VRML scenes, clicking objects or parts of objects, to either "travel" to new 3-D scenes, or load other types of data (from hypertext to video) into their World Wide Web browser (e.g Netscape, Mosaic). ENDORSEMENT for VRML as the 3D graphics metafile standard for the Internet was announced TODAY (4.3.94) by Silicon Graphics, Netscape, Digital, Template Graphics (TGS), NEC, and many other companies. Viewers based upon the established 3D graphics standards OpenGL and Open Inventor will be available in 30 days from TGS for the SGI, Sun, IBM, Windows 3.1,and Windows NT systems, with support for Apple and HP 9000 platforms by summer. Netscape Communications has announced support of the VRML standard and outlined plans to integrate the new VRML products from Silicon Graphics and TGS into the upcoming release of Netscape 1.1. Viewers based on Rendermorphics from Microsoft will be also available from the Community Community within 30 days. VRML ON WAXWEB 2.0 Users can enter the 3-D VRML world from a great many places in the 2D text/picture WAXWEB 2.0 WWW document, which is served from the Institute for Advanced Technology in the Humanities at the University of Virginia. Text links or picture buttons on the flat page can take the reader to a 3-D scene. Once "in" the VRML world, users press 3D hyperlinks to travel through that world, or to automatically change the page on their electronic "book" (the Web browser), or even cause a part of the feature-length movie to play. This is the "third" interface to Waxweb, which is meant to be readable (hypertext), visual (all 5000 pictures are buttons, allowing visual navigation), and flyable (VRML). HOW WAXWEB 2.0 IS UNIQUE: Waxweb is an Internet-based, distributed, interactive and intercommunicative 3-D narrative environment. Waxweb uses MOO technology to dynamically serve hyperlinked 3D VRML objects/scenes. What's a MOO? MOO's are network-based tools for computer supported collaborative work (and play), which allow realtime intercommunication in an multi-room virtual space, as well as the sharing of network information resources... they are text-based virtual realities. By combining VRML with MOO technology on the WORLD WIDE WEB, WAXWEB 2.0 allows 3D narrative content to be shared, examined, added to, and reconfigured. Waxweb's implementation of dynamic VRML gives it the ability to efficiently serve VRML from the MOO, and dynamically auto-assemble objects/scenes and auto-insert hyperlinks (URL's) dependent on user interaction. This allows flexibility in the use of the existing large 3D database, and in addition will let users easily add to that 3D world. WAXWEB 2.0: TOWARDS A PRACTICAL, GLOBALLY DISTRIBUTED, INTERCOMMUNICATIVE, SCALABLE, FINANCIALLY INDEPENDENT HYPER-NARRATIVE SERVER The facts: on Feb. 18th, Digicash was implemented in the MOO (Waxweb is the first Digicash MOO). On the same day Waxweb also became a Sesame server, capable of handling Ubique's Web client for the Sun platform (and soon PC), the first publicly available system for realtime chat through a Web client. Media mirroring has also been established with Sunsite at UNC, and Internationale Stadt in Berlin. Visitors to Waxweb from Germany receive text, VRML, and control information from the Waxweb server in Virginia, but are pointed to Internationale Stadt for pictures, audio, and video. These three experimental implementations point to a practical, globally distributed, intercommunicative, scalable hyper-narrative server, based on an open system, and capable of being financially self-sufficient. THE PRINCIPALS: David Blair is an electronic cinemamaker based in New York City. He is currently at work on a second feature, set in the US and Japan. He is the author of both the film and the WWW versions of Wax. Tom Meyer is a virtual reality specialist in the Brown University Graphics Laboratory. He has written the MOO/WWW/VRML code. Suzanne Hader has provided coding for much of the user interface, and also contributed some graphic elements. Dave Klaphaak has assisted Tom and Suzanne. Florence Ormezzano executed many of the 3-D models for the film version of WAX. Anna Youseffi digitized the stills and MPEG video. Melynda Barnhardt executed some linking and checking for the hypertext. Additional written material in a separate section of Waxweb has been contributed by invited authors. Waxweb is an official project of the Brown Graphics Lab, headed by Andries VanDam. Waxweb has been made possible by networked associate fellow status generously extended to the members of the Waxweb project by IATH, the Institute for Advanced Technology in the Humanities at the University of Virginia, headed by John Unsworth. Waxweb has received partial funding from the New York State Council for the Arts, with both finishing fund and distribution grants, the latter administered by the Experimental Television Center, Owego, NY. ============================== WAXWEB 2.0 IS UNIQUE BECAUSE: First Film Multicast on the Internet (NYTimes) First Feature-Length Interactive Film on the World Wide Web (Variety) First Large Scale Implementation of VRML First Dynamic VRML server (WWW/VRML/MOO ) First Web-Synchronized Cross-Platform CDROM First Large Scale WWW/MOO server First Digicash MOO First Internet Videoserver Project to utilize Media Mirroring (additional information available on all the above) QUOTE from David Blair: "VRML is the beginning of a public virtual reality cinema... one that leverages existing content and distribution to bring VR across an open system to the entire world. It is extraordinarily exciting to work in this now generally-accepted, and soon-to-be extended standard... one that links top and bottom-end computers, 3-D and 2-D data, and scalable connectivity, clearly pointing to our practical future as media-multicasters thriving in an international network 3-space." -------------- Waxweb 2.0 is an experiment toward the production of David Blair's second electronic feature (now in pre-production) ********** FOR RELEASE ON APRIL 3, 1995 ************* ************************************* David Blair artist1@interport.net -------- Waxweb 2.0: regular access: http://bug.village.virginia.edu VRML (3D) access: http://bug.village.virginia.edu/vrml MOO access: telnet to: bug.village.virginia.edu 7777 Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05708; Mon, 27 Mar 1995 20:26:08 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05690; Mon, 27 Mar 1995 20:26:05 -0600 Received: from N3.SP.CS.CMU.EDU (N3.SP.CS.CMU.EDU [128.2.222.83]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id UAA02644 for ; Mon, 27 Mar 1995 20:25:29 -0600 From: Hui.Zhang@N3.SP.CS.CMU.EDU Message-Id: <199503280225.UAA02644@timbuk.cray.com> Date: Mon, 27 Mar 95 21:16:11 EST To: tcplw@cray.com Subject: ACM Multimedia'95 Paper Submission Extension: April 10 Content-Length: 842 Due to the large number of requests, we have decided to extend the Multimedia'95 paper submission deadline until APRIL 10, 1995 AT 5:00 PM PDT. All papers MUST BE RECEIVED by this time. In order to allow sufficient time for our rigorous review process, this deadline is firm; NO EXCEPTIONS WILL BE MADE. We are announcing this extension widely to be fair to all submitters, who may wish to take the extra time to improve their submissions. Re-submission will be permitted, but the accompanying Paper Submission Cover Sheet must clearly identify the title and authors of the earlier version of the submission. Authors should consult the WWW at http://acm.org/MM95/ or send email to mm95@parc.xerox.com for paper submission guidelines and cover sheet forms. Please forward this message to friends, colleagues, or other interested parties. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03285; Wed, 22 Mar 1995 11:06:22 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03278; Wed, 22 Mar 1995 11:06:21 -0600 Received: from N3.SP.CS.CMU.EDU (N3.SP.CS.CMU.EDU [128.2.222.83]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id LAA19958 for ; Wed, 22 Mar 1995 11:05:43 -0600 From: Hui.Zhang@N3.SP.CS.CMU.EDU Message-Id: <199503221705.LAA19958@timbuk.cray.com> Date: Wed, 22 Mar 95 11:58:07 EST To: tcplw@cray.com Subject: CFP: ACM Multimedia'95 Content-Length: 421 ACM Multimedia '95 Nov 5-9 San Francisco, CA Technical Papers, Videos, Workshops, Tutorials, Panels, Demonstration, and Exhibit. The March 31, 1995 submission deadline is fast approaching. Please consult the WWW at http://acm.org/MM95/ (with an "/" at the end) for updated paper submission guidelines, which now reflect recently-received feedback from Multimedia'94. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA17192; Sun, 12 Mar 1995 22:51:17 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA17187; Sun, 12 Mar 1995 22:51:15 -0600 Received: from dynamo.ecn.purdue.edu (dynamo.ecn.purdue.edu [128.46.128.1]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with ESMTP id WAA23195 for ; Sun, 12 Mar 1995 22:51:13 -0600 Received: from dynamo.ecn.purdue.edu (ghafoor@localhost) by dynamo.ecn.purdue.edu (8.6.10/3.5davy) id XAA24006; Sun, 12 Mar 1995 23:51:11 -0500 Message-Id: <199503130451.XAA24006@dynamo.ecn.purdue.edu> Date: Sun, 12 Mar 1995 23:51:11 -0500 From: Arif Ghafoor Content-Type: text Content-Length: 3048 Apparently-To: tcplw@cray.com CALL FOR PAPERS The IEEE Journal on Selected Areas in Communications announces a forthcoming issue on Distributed Multimedia Systems and Technology Advances in high-speed networking and storage technologies and increasing demand for timely distribution of multimedia information have resulted in a tremendous interest in variety of services which will be available in the future Distributed Multimedia Information Systems (DMIS). Most of these services will use some form of pre-orchestrated stored objects, e.g., video-on-demand, digital libraries, virtual reality, education/training, CAD/CAM, etc. The pre-orchestrated nature of the information poses number of challenges in management of distributed data, temporal synchronization in a distributed environment, maintaining desired quality of transmission, desigining appropriate switching and network control, interoprtability of distributed multimedia sources, operating system support for DMIS etc. In this issue of JSAC, we address the networking, distribution and management issues arising in future DMISs. Topics of interest include (but are not limited to): - - Multimedia Networking - - Performance Considerations for Real-Time Multimedia Protocols - - Quality of Service for Networked Multimedia Applications - - Multimedia Services over the Internet and Broadband Networks - - Spatial/Temporal Models for Distributed Multimedia Information - - Operating System Supports for Distributed Multimedia Environments - - Distributed Multimedia Data Management - - Interoperability Issues among Distributed Multimedia Systems - - Binding Techniques for Multimedia Traffic - - Management and Control of Multimedia Services - - Architectures and Standards for Multimedia Communications - - Experimental Systems Authors should follow the IEEE JSAC manuscript format. Only original manuscripts will be considered. A manuscript identical to, or largely based on, a conference paper must be so identified. Prospective authors are requested to submit five (5) copies of their manuscript to one of the guest editors listed below. Submission Deadline: May 1, 1995 Acceptance Notification: October 1, 1995 Final Papers: February 1, 1996 Publication: 3rd Quarter 1996 Guest Editors: Arif Ghafoor School of Electrical Engineering, Purdue University, West Lafayette, IN 47907, U.S.A. e-mail: ghafoor@ecn.purdue.edu Tel: (317) 494-0638 Fax: (317) 494-6440 Ralf G. Herrtwich, IBM Creative Multimedia Studios Vangerowstrasse 18, D-69115 Heidelberg, Germany email: rgh@vnet.ibm.com Tel: +49 (6221) 59-4218 Fax: +49 (6221) 59-3400 Aurel A. Lazar Department of Electrical Engineering and Center for Telecommunication Research, Columbia University, New York, NY, 10027-6699, USA e-mail: aurel@ctr.columbia.edu Tel: (212) 662-3864 Fax: (212) 316-9068 Ian M Leslie Computer Laboratory University of Cambridge email Ian.Leslie@cl.cam.ac.uk Tel: +44 223 334658 Fax: +44 223 334678 Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11976; Mon, 27 Feb 1995 10:09:16 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11964; Mon, 27 Feb 1995 10:09:14 -0600 Received: from N3.SP.CS.CMU.EDU (N3.SP.CS.CMU.EDU [128.2.222.83]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id KAA24827 for ; Mon, 27 Feb 1995 10:09:12 -0600 From: Hui.Zhang@N3.SP.CS.CMU.EDU Message-Id: <199502271609.KAA24827@timbuk.cray.com> Date: Mon, 27 Feb 95 10:54:30 EST To: tcplw@cray.com Subject: CFP: ACM Multimedia'95 Content-Length: 232 ACM Multimedia '95 Nov 5-9 San Francisco, CA Technical Papers, Videos, Workshops, Tutorials, Panels, Demo Deadline March 31, 1995 For more information: http://acm.org/MM95/ Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08468; Tue, 14 Feb 1995 16:54:50 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08460; Tue, 14 Feb 1995 16:54:43 -0600 Received: from rpi.edu (rpi.edu [128.113.1.7]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id QAA02618 for ; Tue, 14 Feb 1995 16:54:41 -0600 Received: from ecse.rpi.edu by rpi.edu (4.1/SMHUB41); id AA11683; Tue, 14 Feb 95 17:25:34 EST for tcplw@cray.com Received: by ecse.rpi.edu (4.1/HUB10); id AA11836; Tue, 14 Feb 95 17:25:31 EST for jenniw@rpi.edu Date: Tue, 14 Feb 1995 17:25:29 -0500 (EST) From: Ken Vastola To: tccc@cs.umass.edu, cellular@dfv.rwth-aachen.de, perform@tay1.dec.com, end2end-interest@isi.edu, ietf@isi.edu, rem-conf@es.net, announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, cip@bbn.com, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@acm.org, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca Cc: "William C. Jennings" Subject: Faculty Position at RPI Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 3167 Folks, Below is an ad for a faculty position which has just become available in my department at RPI. This position is at the assistant professor level. Please forward it to appropriate PhD students and also to individuals who received their doctorates over the last few years who may be interested. Thank you. Ken Vastola _____________________________________________________________________________ Professor Kenneth S. Vastola vastola@ecse.rpi.edu Electrical, Computer and Systems Engineering Dept. Rensselaer Polytechnic Institute Troy, New York 12180-3590 http://networks.ecse.rpi.edu/~vastola/ _____________________________________________________________________________ Rensselaer Polytechnic Institute The Department of Electrical, Computer and Systems Engineering invites applications for a tenure-track faculty position at the Assistant Professor level. The specific area of interest is Computer Engineering with emphasis on computer communication networks and/or distributed computing systems. We are seeking someone who can work effectively with existing strengths in optical and high-speed integrated networks, multimedia networking, image and video processing, and parallel and distributed systems. This new faculty position is part of a major Engineering Renaissance at Rensselaer initiative designed to position Rensselaer for technological leadership in the 21st century. The ECSE Department is the largest academic unit at Rensselaer, with 35 faculty and 250 graduate students. There are also close links between ECSE and the Department of Computer Science. ECSE is seeking to add top quality faculty who bring innovative approaches to modern areas of research and who can effectively participate in a campus-wide educational initiative in Interactive Learning. ECSE has major programs in multimedia communications and signal processing; robotics, intelligent control and manufacturing; integrated electronics and electronics manufacturing; and energy systems. Excellent opportunities exist for faculty to participate in interdisciplinary research centers, including the Center for Image Processing Research, the Center for Integrated Electronics and Electronics Manufacturing, the New York State Center for Advanced Technology in Automation, Manufacturing and Robotics, and the Scientific Computation Research Center. New faculty are will receive special career start-up arrangements including summer support, equipment, graduate student support and reduced teaching loads to encourage the development of successful research programs. Applications and/or requests for further information should be directed to: Dr. William C. Jennings Department Head Electrical, Computer and Systems Engineering Rensselaer Polytechnic Institute Troy, NY, 12180-3590. Dr. Jennings may be reached by phone at (518) 276-6316 or electronically at jennings@ecse.rpi.edu. Rensselaer is an affirmative action/equal opportunity employer and specifically encourages applications from women and minorities. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA27972; Fri, 10 Feb 1995 12:41:33 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA27966; Fri, 10 Feb 1995 12:41:32 -0600 Received: from framsparc.ocf.llnl.gov (framsparc.ocf.llnl.gov [134.9.50.133]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id MAA18942 for ; Fri, 10 Feb 1995 12:41:30 -0600 Received: by framsparc.ocf.llnl.gov (4.1/SMI-4.0) id AA25555; Fri, 10 Feb 95 10:41:21 PST From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Message-Id: <9502101841.AA25555@framsparc.ocf.llnl.gov> Subject: Re: WANTED: Solaris implementation of RFC-1323 To: karl@kira.gmd.de (Karl Jonas) Date: Fri, 10 Feb 1995 10:41:19 -0800 (PST) Cc: tcplw@cray.com In-Reply-To: <9502100842.ZM11443@kira> from "Karl Jonas" at Feb 10, 95 08:42:53 am X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 474 Karl, >has RFC-1323 been implemented on SOLARIS 2 ? I have heard rumour that Sun was going to add the RFC 1323 mods to Solaris. You might drop Peter Haas a line. He's at the Regional Computing Center at the University of Stuttgart, and has been actively involved in work with TCP and HIPPI under Solaris. He's more than likely to have details on such an implementation. regards, mb -- Mark Boolootian booloo@llnl.gov +1 510 423 1948 Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08638; Fri, 10 Feb 1995 05:23:07 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08633; Fri, 10 Feb 1995 05:23:06 -0600 Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id FAA24222 for ; Fri, 10 Feb 1995 05:21:47 -0600 Received: from by campino.informatik.rwth-aachen.de (4.1/campino-6) id AB12926; Fri, 10 Feb 95 12:21:26 +0100 Received: from IKARUS/TEMPQ by i4.informatik.rwth-aachen.de (Mercury 1.20); 10 Feb 95 12:23:00 Received: from TEMPQ by IKARUS (Mercury 1.20); 10 Feb 95 10:49:00 To: tcplw@cray.com From: "Claudia Popien" Organization: Informatik IV - RWTH Aachen Date: 10 Feb 1995 10:49:58 GMT+1 Subject: CfP: ICDP96 (Germany) Priority: normal X-Mailer: Pegasus Mail/Mac v2.02 Message-Id: <152AFD50D15@i4.informatik.rwth-aachen.de> Content-Length: 5466 __________________________________________________________________________ ANNOUNCEMENT AND CALL FOR PAPERS ICDP '96: IFIP/IEEE INTERNATIONAL CONFERENCE ON DISTRIBUTED PLATFORMS Client/Server and Beyond: DCE, CORBA, ODP & Advanced Distributed Applications __________________________________________________________________________ Dresden, Germany February 27 - March 1, 1996 __________________________________________________________________________ In continuation of International Workshop on OSF DCE, Karlsruhe, Germany, 1993 Organized by IFIP IEEE Comm. Society Gesellschaft fuer Informatik Dresden Univ. of Techn. Aachen Univ. of Technology OBJECTIVES AND SCOPE Client/Server applications are of increasing importance in industry, and have been enhanced with advanced distributed object-oriented techniques, dedicated tool support and both multimedia and mobil computing extensions. Such solutions are a significant step towards a global distributed processing model. Recent responses to this trend are standardized platforms and models including the Distributed Computing Environment (DCE) of the Open Software Foundation (OSF), Open Distributed Processing (ODP) and the Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG). ICDP'96 will be a major forum for distributed systems researchers, network developers, service providers, application designers and end users for discussing the latest research and development results with respect to these platforms. Topics of particular interest include, but are not limited to: o Experiences with distributed applications and standardized platforms (DCE, CORBA, ODP, ONC+, ANSAware and others) o Distributed platforms in advanced development and research projects o Network Services (directory, security, file management etc.) o Distributed application management o Objects in distributed environments o Trading concepts and open markets of distributed services o Quality of service in distributed applications o Applications of mobile communication systems STRUCTURE OF THE CONFERENCE - Technical Stream: Latest research results will be presented. - Industrial Stream: Industrial developments and trends will be discussed. - Demonstration Stream: Exhibition around distributed processing. Original full papers (max. 15 pages) will belong to the Technical Stream. Furthermore, you are invited to submit extended abstracts focusing on practical work for both the Industrial Stream and the Demonstration Stream (max. 5 pages). Accepted papers will be published in the international conference proceedings by Chapman & Hall. All submissions must be sent online (postscript) to the following email-address: ICDP96@ibc.inf.tu-dresden.de IMPORTANT DATES: Deadline for Submission: June 15, 1995 Notification of Acceptance: September 15, 1995 Camera ready papers: October 15, 1995 Tutorials (one day): February 27, 1996 Conference (three days): February 28 - March 1, 1996 Location: Dresden has become famous above all as city of the arts and is only a two hours drive from Berlin to the north and Prague to the south. Major attractions are the Semper Opera, the baroque Zwinger, the art collections (Gruenes Gewoelbe, Gemaeldegalerie) and the Frauenkirche that is currently being rebuilt. The surrounding countryside also provides many opportunities for sightseeing including Pillnitz castle, the china manufacture in Meissen and Saxon Switzerland. For further information please contact the program chairs: Prof. Dr. Alexander Schill Prof. Dr. Otto Spaniol/Claudia Popien Dresden Univ. of Technology RWTH Aachen Dept. of Computer Science Computer Science IV D-01062 Dresden D-52056 Aachen GERMANY GERMANY WWW: http://www.inf.tu-dresden.de/TU/Informatik/IBDR/lsrn/ICDP96 e-mail: ICDP96@ibc.inf.tu-dresden.de FAX: +49 / 351 / 4575 335 PROGRAMME COMMITTEE: S.A. Aidarous, BNR, Ottawa (Canada) M. Bever, IBM ENC Heidelberg (Germany) P. Dasgupta, Arizona State Univ. (USA) J. Dilley, HP Cupertino (USA) R.L. Fike, RNF Systems (USA) A. Gaylord, Univ. Massachussetts (USA) K. Geihs, Univ. Frankfurt (Germany) A. Herbert, ANSA (UK) L. Heuser, DEC CEC, Karlsruhe (Germany) J. Janacek, TU Prague (Czech Republic) F. Kamoun, C.N. de l'Informatique (Tunisia) J. Kiho, Univ. Tartu (Estonia) D. Lin, IBM Austin (USA) P. Linington, Univ. Kent (UK) O. Martikainen, Telecom (Finland) F. Miralles, SNI Munich (Germany) B. Pehrson, Swedish Institute of Computer Science, Kista (Sweden) R. Posch, TU Graz (Austria) P. Radford, Logica (UK) K. Raymond, Univ. Brisbane (Australia) D. Ruddock, Bellcore, New Jersey (USA) H. Rudin, IBM (Switzerland) G. Schuermann, GMD FOKUS (Germany) R. Soley, OMG (USA) L. Svobodova, IBM (Switzerland) R. Torbergsen, SINTEF RUNIT, Trondheim (Norway) W. Tuvell, OSF Cambridge (USA) __________________________________________________________________ Claudia Popien Tel.: +49 241 8021440 RWTH Aachen, Informatik IV FAX: +49 241 8888220 Ahornstr. 55 e-mail: D-52056 Aachen GERMANY popien@informatik.rwth-aachen.de __________________________________________________________________ Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA23826; Fri, 10 Feb 1995 01:43:03 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA23821; Fri, 10 Feb 1995 01:43:01 -0600 Received: from gmdzi.gmd.de (gmdzi.gmd.de [129.26.8.90]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id BAA06706 for ; Fri, 10 Feb 1995 01:42:59 -0600 Received: from kira.gmd.de (kira) by gmdzi.gmd.de with SMTP id AA08708 (5.65c8/IDA-1.4.4 for ); Fri, 10 Feb 1995 08:42:55 +0100 Received: by kira.gmd.de id AA11445 (5.67b/IDA-1.5 for tcplw@cray.com); Fri, 10 Feb 1995 08:42:54 +0100 From: karl@kira.gmd.de (Karl Jonas) Message-Id: <9502100842.ZM11443@kira> Date: Fri, 10 Feb 1995 08:42:53 +0100 X-Mailer: Z-Mail (3.2.0 06sep94) To: tcplw@cray.com Subject: WANTED: Solaris implementation of RFC-1323 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 511 Hallo all, has RFC-1323 been implemented on SOLARIS 2 ? Thanks, Karl -- ----------------------------------------------------- Karl Jonas German National Research Center for Computer Science Multimedia Applications in Telecooperation GMD MAT http://mats.gmd.de/karl Schloss Birlinghoven Tel: +49 2241 14-2137 Postfach 13 16 Fax: +49 2241 14-2449 D-53731 Sankt Augustin EMail: karl.jonas@gmd.de ----------------------------------------------------- Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05200; Wed, 8 Feb 1995 09:02:05 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05192; Wed, 8 Feb 1995 09:02:04 -0600 Received: from gmdzi.gmd.de (gmdzi.gmd.de [129.26.8.90]) by timbuk.cray.com (8.6.9/CRI-fence-1.3) with SMTP id JAA14111 for ; Wed, 8 Feb 1995 09:02:01 -0600 Received: from kira.gmd.de (kira) by gmdzi.gmd.de with SMTP id AA03154 (5.65c8/IDA-1.4.4 for ); Wed, 8 Feb 1995 16:01:54 +0100 Received: by kira.gmd.de id AA09990 (5.67b/IDA-1.5 for tcplw@cray.com); Wed, 8 Feb 1995 16:01:27 +0100 Date: Wed, 8 Feb 1995 16:01:27 +0100 From: Karl Jonas Message-Id: <199502081501.AA09990@kira.gmd.de> Apparently-To: tcplw@cray.com Content-Length: 1 Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11708; Fri, 3 Feb 1995 06:42:00 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11694; Fri, 3 Feb 1995 06:41:53 -0600 Received: from monet.caad.ed.ac.uk (monet.caad.ed.ac.uk [129.215.100.6]) by timbuk.cray.com (8.6.9/CRI-fence-1.3) with ESMTP id GAA05085 for ; Fri, 3 Feb 1995 06:41:49 -0600 Received: (from john@localhost) by monet.caad.ed.ac.uk (8.6.9/8.6.9) id KAA23258; Fri, 3 Feb 1995 10:54:07 GMT Date: Fri, 3 Feb 1995 10:54:07 GMT From: John Lee Message-Id: <199502031054.KAA23258@monet.caad.ed.ac.uk> To: IE-list@cs.ucl.ac.uk, ag-exp-l%ndsuvm1.BITNET@forsythe.Stanford.EDU, agosta@sumex-aim.stanford.edu, ai-ed@sun.com, ai-medicine@medmail.Stanford.EDU, ai-nat@adfa.oz.au, ai-stats@watstat.uwaterloo.ca, aisb@cogs.sussex.ac.uk, announcements.chi@xerox.com, arl@arl1.wustl.edu, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, ccrc@dworkin.wustl.edu, cellular@dfv.rwth-aachen.de, cip@bbn.com, cnom@maestro.bellcore.com, cogsci@cogsci.ed.ac.uk, cybsys-l@bingvmb.cc.binghamton.edu, diagrams@cs.swarthmore.edu, elsnet-list@cogsci.edinburgh.ac.uk, end2end-interest@ISI.EDU, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, fj-ai@etl.go.jp, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, ietf@ISI.EDU, ikbsbb@inf.rl.ac.uk, iplpdn@cnri.reston.va.us, ircpeople@cogsci.ed.ac.uk, kdd@gte.com, met-ai@comp.vuw.ac.nz, mmws@caad.ed.ac.uk, perform@tay1.dec.com, rem-conf@es.net, schulzrinne@fokus.gmd.de, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@acm.org, tccc@cs.umass.edu, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca Subject: FINAL reminder: IMMI-1 Workshop Content-Length: 960 There is STILL TIME to submit an extended abstract to IMMI-1; the First International Workshop on Intelligence and Multimodality in Multimedia Interfaces, Edinburgh, July 13-14, 1995. For details see the (recently updated) Web information at -- http://www.cogsci.ed.ac.uk/~john/IMMI_call/index.html -- or email to the address below. Thanks again to all those who have already indicated their intention to submit abstracts. John. --------------------------------------------------------------------------- John R. Lee EdCAAD and Human Communication Research Centre Dept. of Architecture University of Edinburgh University of Edinburgh 2 Buccleuch Place 20 Chambers Street Edinburgh EH8 9LW Edinburgh EH1 1JZ Scotland, UK. Scotland, UK. Tel: +44 131 650 2335/7 Tel: +44 131 650 4420 Fax: +44 131 667 0141 Fax: +44 131 667 4587 Email: J.Lee@ed.ac.uk --------------------------------------------------------------------------- Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26064; Fri, 27 Jan 1995 15:16:17 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26046; Fri, 27 Jan 1995 15:16:07 -0600 Received: from ns.gte.com (ns.gte.com [132.197.8.9]) by timbuk.cray.com (8.6.9/CRI-fence-1.3) with SMTP id PAA27405 for ; Fri, 27 Jan 1995 15:15:57 -0600 Received: from colossus.gte.com by ns.gte.com (5.65c/IDA-1.4.4) id AA28418; Fri, 27 Jan 1995 15:06:19 -0500 Received: by colossus.gte.com (AIX 3.2/UCB 5.64/4.03) id AA19935; Fri, 27 Jan 1995 15:05:19 -0500 Message-Id: <9501272005.AA19935@colossus.gte.com> From: "James P.G. Sterbenz" To: atm@bbn.com, end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.EDU, g-troup@dworkin.wustl.edu, ccrc@dworkin.wustl.edu, arl@arl1.wustl.edu, rem-conf-request@es.net, tcplw@cray.com, tccc@cs.umass.edu, announcements.chi@Xerox.com, simon@cui.unige.ch, sound@acm.org, sigmedia@bellcore.com, icad-request@santafe.edu, cip@bbn.com, iplpdn@cnri.reston.va.us, sip-request@catarina.usc.edu, smds@cnri.reston.va.us, s-comput%tcsvm.bitnet@cunyvm.cuny.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@Xerox.com, sig11@roses.stanford.edu, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca Cc: "James P.G. Sterbenz" Subject: CFP: Gigabit Networking Workshop GBN'95 at INFOCOM'95 Organization: GTE Telecommunications Research Laboratory Date: Fri, 27 Jan 95 15:05:17 -0500 Sender: jpgs@gte.com Content-Length: 4423 [NOTE: contrary to some INFOCOM info the abstract submit deadline is 1 March] GIGABIT NETWORKING WORKSHOP GBN'95 - Call for Participation 2 April 1995 - Boston, Massachusetts, USA Sponsored by the IEEE ComSoc Technical Committee on Gigabit Networking in conjunction with INFOCOM'95 PURPOSE AND FORMAT The purpose of this workshop is to provide a forum for presenting and discussing very recent work in gigabit networking and publishing it in a timely manner. The workshop will consist of short presentations and discussions of current work in high bandwidth networking, as well as longer discussion sessions. The workshop will take place from 8:30 AM until 3:00 PM with lunch provided. There will be an open business meeting of the Technical Committee on Gigabit Networking following the workshop at 3:00 PM. The workshop will consist of a number of short informal presentations and discussion on current research and implementation, hot topics, position statements, and controversial issues relating to high bandwidth networking. End-to-end issues including transport and higher layer protocols, host and network interface architecture, operating systems, emerging applications, deployment and management of large networks, economic and regulatory issues, security and privacy, and other societal impacts will be of particular interest. A one-page abstract of the presentation is due on 1 March 1995; all reasonable proposals will be considered (and possibly some controversial ones). The length of the presentations will be limited to 10 or 15 minutes each, with the number of presentation foils strictly limited. Presentations will appear in the online proceedings of the workshop, under URL http://info.gte.com/ieee-tcgn/conference/gbn95 or by FTP from ftp.gte.com/pub/ieee-tcgn/conference/gbn95/. Selected abstracts of the presentations will appear in _IEEE Network Magazine_ (tentatively May 1995), and presenters may be invited to submit papers to a special issue of the _Journal of High Speed Networks_ (JHSN). There will blocks of time reserved for interactive discussion sessions. Suggestions for topics will be taken in advance (email to giga@tele.pitt.edu and Cc: to jpgs@ieee.org), but will also be welcome at the workshop. Controversial topics and outrageous viewpoints are encouraged. A summary of the workshop discussions will appear in _IEEE Network Magazine_. SUBMISSION The submission deadline for the one-page abstract is 1 March 1995. Submission should be in plain text by email to the program chair at jpgs@ieee.org; please include the text "GBN'95 Submission" in the Subject: field. All submissions will be quickly acknowledged; the lack of an acknowledgment indicates that the author should contact the program chair to confirm the receipt of the proposal. Notification of accepted presentations will be made by 10 March 1995, and all accepted presenters are expected to register in advance for the workshop. At the time of the workshop, an electronic version of the presentation foils will be due for inclusion in the online proceedings. Submission in postscript and/or HTML is encouraged; if these formats are not possible, plain text will be accepted. REGISTRATION Registration for the workshop will be handled as part of INFOCOM'95 registration; information is available on the WWW http://www.research.att.com/~hgs/infocom95/program.html by anonymous FTP gaia.cs.umass.edu/pub/hgschulz/infocom95/progam.txt email request to infocom95@fokus.gmd.de Additional copies of the GBN'95 CFP are available on the WWW http://info.gte.com/ieee-tcgn/conference/gbn95/cfp.html by anonymous FTP ftp.gte.com/pub/ieee-tcgn/conference/gbn95/cfp.txt email request to jpgs@ieee.org The home page for the TCGN is URL http://info.gte.com/ieee-tcgn, and has additional information. PROGRAM CHAIR PROGRAM COMMITTEE James P. G. Sterbenz Nim Cheung, Bellcore GTE Telecom. Research Laboratory Dave Feldmeier, Bellcore 40 Sylvan Road MS-61, Bryan Lyles, Xerox PARC Waltham, MA 02254 USA Ira Richer, MITRE +1 617 466 2786 Dick Skillen, Northern Telecom jpgs@ieee.org Richard A. Thompson, Univ. of Pittsburgh http://info.gte.com/jpgs Shukri Wakid, NIST Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA28854; Thu, 19 Jan 1995 20:54:34 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA28849; Thu, 19 Jan 1995 20:54:31 -0600 Received: from lloyd.com (root@harry.lloyd.com [158.222.1.6]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id UAA22250 for ; Thu, 19 Jan 1995 20:54:30 -0600 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.29.1 #4) id m0rV9TA-0006IQC; Thu, 19 Jan 95 18:53 PST Message-Id: X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jan 1995 18:53:00 -0800 To: Sandy McCrady , announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, ccrc@dworkin.wustl.edu, cellular@dfv.rwth-aachen.de, cip@bbn.com, cnom@maestro.bellcore.com, end2end-interest@isi.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, Henning Schulzrinne , hipparch@sophia.inria.fr, icad-request@santafe.edu, ietf@isi.edu, iplpdn@CNRI.Reston.VA.US, perform@tay1.dec.com, rem-conf@es.net, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@CNRI.Reston.VA.US, sound@acm.org, tccc@cs.umass.edu, tcplw@cray.com, "tf-mm@i4serv.informatik.rwth-aa" , uist.chi@xerox.com, xtp-relay@cs.concordia.ca From: brian@lloyd.com (Brian Lloyd) Subject: Re: RE- client/server image sof Content-Length: 1225 At 9:11 1/19/95 +0000, Sandy McCrady wrote: > Reply to: RE: client/server image software > >Anyone know any good client/server (UNIX) existing software or something that >could easily be modified that does image/rastor/TIF manipulation (view/zoom, >pan, move around on the screen, print). Need some sort of button/menu control >so it can talk on the back end to a pgm that talks to an ORACLE data base. >(Windows should be MOTIF and maybe use DCE/Encina.) > >Any good ideas? Try xv. We run it on our Suns under generic X11R5. It can accept a number of image formats in and it generates a bunch out, including postscript for driving laser printers. It lets you crop, scale, change aspect ratio (stretch), modify color maps, modify intensity and chroma transfer functions, etc. I use it to generate false color images and do image enhancement. It was especially useful in processing lunar terminator images from Clementine. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Dr, Suite 102 http://www.lloyd.com Cameron Park, CA 95682 (916) 676-1147 - voice (916) 676-3442 - fax Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA27334; Thu, 19 Jan 1995 20:16:21 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA27329; Thu, 19 Jan 1995 20:16:20 -0600 Received: from N3.SP.CS.CMU.EDU (N3.SP.CS.CMU.EDU [128.2.222.83]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id UAA19175 for ; Thu, 19 Jan 1995 20:16:18 -0600 From: Hui.Zhang@N3.SP.CS.CMU.EDU Message-Id: <199501200216.UAA19175@timbuk.cray.com> Date: Thu, 19 Jan 95 21:00:30 EST To: tcplw@CRAY.COM Subject: CFP: ACM Multimedia'95 Content-Length: 8210 *************************************************************************** ACM MULTIMEDIA'95 November 5-9, 1995 Hyatt Regency (Embarcadero) San Francisco, CA THE THIRD ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION Sponsored by the ACM SIG Multimedia, SIGCHI, SIGGRAPH, SIGBIT, SIGBIO, SIGCOMM, SIGIR and SIGOIS In cooperation with ACM SIGAPP, SIGCAPH, SIGMOD and SIGOPS PRELIMINARY CALL FOR PARTICIPATION *************************************************************************** Multimedia can substantially improve communication between information providers and consumers by making it more effective and more engaging. ACM Multimedia'95 will provide an international forum for papers, panels, videos, demonstrations, courses, workshops, and exhibits focusing on all aspects of this multi-disciplinary field: from underlying technologies to applications and issues, and from theory to practice. We invite your participation. Topics include, but are not limited to: applications in education, entertainment, government, medicine, etc.; collaboration environments; databases; digital libraries; distributed systems; documents and authoring; hardware and architectures; image, video and audio compression techniques; information retrieval; interactive television; media integration and synchronization; networking and communication; operating system extensions; programming paradigms and environments; standards and legal issues; storage and I/O architectures; tools; user interfaces; and virtual reality. Papers ------ Technical papers on completed or in-progress research, innovative applications, or experience with multimedia systems are solicited. Submissions must use a typeface no smaller than 10 point, double sided if possible, and be no longer than 12 pages including figures, tables, and references. Where applicable, prototype demonstrations or videotape presentations are encouraged to supplement the talks. Submit complete papers to: Polle Zellweger, Program Chair. Outstanding papers on different areas of multimedia will be given awards. Papers with a student as the primary author will enter a student paper award competition. A cover letter must identify the paper as a candidate for the student paper competition. Selected papers will be forwarded to ACM/Springer-Verlag Multimedia Systems, Communications of the ACM, IEEE/ACM Transactions on Networking, or ACM Transactions on Information Systems. Panels ------ Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Proposals should be limited to 2 pages, plus a biography of at most one paragraph for each participant. Submit panel proposals to: Fillia Makedon, Panels Chair. Videos ------ Videos of innovative multimedia technology should be 5-8 minutes long, in NTSC format, and accompanied by one copy of a 1-2 page description of the material shown in the video. Submit videos to: Gil Cruz, Videos Chair. Demonstrations -------------- We solicit demonstrations of working systems in technical and artistic categories. Submissions (at most 2 pages) should include a description of the exhibit, demo requirements, a biography, and a single VHS NTSC video. Submit demonstrations to: Tom Little, Demonstrations Chair. Courses ------- There will be a series of 1/2-day tutorial courses, focused on issues relevant to researchers and/or practitioners of multimedia technology. Proposals (at most 5 pages) should include a description of the subject matter and brief biographical sketches of the instructors. Evaluation of proposals will be based on expertise and experience of instructors, relevance of subject matter, and the use of multimedia technology in the presentation. Submit tutorial proposals to: Sorel Reisman, Tutorials Chair. Workshops --------- Workshops preceding the conference will allow participants to exchange ideas on a topic. Workshop results and issues will be integrated into the main body of the conference. Submit workshop proposals to: Ephraim Glinert, Workshops Chair. Exhibits -------- ACM Multimedia'95 offers a unique opportunity for vendors and publishers to exhibit and demonstrate multimedia products. For more information, contact Don Collier, Exhibition Manager. ============= IMPORTANT SUBMISSION INFORMATION -------------------------------- Authors should consult the World Wide Wed at http://acm.org/MM95/ for a more detailed submission guidelines and up-to-date information about ACM Multimedia'95. Authors of accepted submissions will be required to submit both a camera- ready copy of the manuscript for the printed proceedings and an electronic copy for the CD ROM proceedings. Authors must assign copyright to ACM as a condition of publishing their work in the proceedings. An author who embeds an object, such as an art image, copyrighted by a third party is expected to obtain that party's permission to include the object with the understanding that the entire work may be distributed as a unity to ACM members and others. IMPORTANT DATES --------------- Six copies of all submissions due: March 31, 1995. Notification of acceptance: June 30, 1995. Submissions in final form due: August 11, 1995. CONFERENCE COMMITTEE -------------------- General Chair: R.B. Allen, Bellcore Networking: G. Paxinos, Metro Link Proceedings: S. Heller, GWU Electronic Information: H. Zhang, CMU Electronic Publishing: R. Phillips, LANL Publicity: R. Mehrotra, UM-St. Louis Treasurer: M. Brown, DEC European Liaison: C. Thanos, Consiglio Nazionale delle Ricerche (Pisa) Steering Committee Co-Chairs: S. Bulick, US WEST A. Kuchinsky, Hewlett Packard PROGRAM CHAIR: Polle Zellweger Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 USA mm95@parc.xerox.com Phone: +1-415-812-4426 PANELS CHAIR: Fillia Makedon Dept. of Math and Computer Sci. Dartmouth College 6211 Sudikoff Laboratory, Room 109 Hanover, NH 03755-3510 USA makedon@kinsman.dartmouth.edu Phone: +1-603-646-3048. VIDEOS CHAIR: Gil Cruz, R. Hill MRE-2B280 Bellcore 445 South Street Morristown, NJ 07960 USA {gil,rdh}@bellcore.com Phone: +1-201-829-5212 DEMONSTRATIONS CHAIR: Tom Little Dept. of Elec. and Computer Engr. Boston University 44 Cummington St. Boston, MA 02215 USA tdcl@spiderman.bu.edu Phone: +1-617-353-9877 TUTORIALS CHAIR: Sorel Reisman Dept. of Management Science/Information Systems California State University Fullerton, CA 92634 USA sreisman@ccvax.fullerton.edu Phone: +1-714-773-3325 WORKSHOPS CHAIR: Ephraim Glinert Dept. of Computer Science R. P. I. Troy, NY 12180 USA glinert@cs.rpi.edu Phone: +1-518-276-2657 EXHIBITS CHAIR: Brent Hailpern IBM T.J. Watson Res. Ctr. 30 Sawmill River Roada Hawthorne, NY 10532 USA bth@watson.ibm.com Phone: +1-914-784-6821 EXHIBITOR INFORMATION: Don Collier DC Expositions, Inc. 555 Republic Drive, Suite #316 Plano, TX 75074 USA dcexpo@aol.com Phone +1-214-423-4286 PROGRAM COMMITTEE ----------------- Program Chair: P. Zellweger, Xerox PARC, USA AssociateChairs: D.P. Anderson, Sonic Solutions, USA F. Brody, Inst. of Adv. Comm., Austria D.C.A. Bulterman, CWI, Netherlands E.A. Fox, Virginia Tech, USA F. Golshani, Arizona State Univ., USA R.G. Herrtwich, IBM Eurocoord., France H. Ishii, NTT, Japan T.D.C. Little, Boston Univ., USA W. Mackay, Rank Xerox Res. Centre, UK V. deMey, Apple Computer, USA A.D. Narasimhalu, National Univ. of Singapore J. Rosenberg, Bellcore, USA E. Schooler, Caltech, USA B. Smith, Cornell Univ., USA H. Vin, Univ. of Texas, Austin, USA A. Weinrib,Intel Architecture Labs, USA N. Yankelovich,Sun Microsystems, USA GENERALINFORMATION: http://acm.org/MM95/ +1-201-829-4315 REGISTRATIONINFORMATION: +1-508-443-3330 x1230 +1-800-524-1851 x1230 *************************************************************************** 1995 ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION *************************************************************************** Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26139; Thu, 19 Jan 1995 19:53:10 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26133; Thu, 19 Jan 1995 19:53:08 -0600 Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id TAA16810 for ; Thu, 19 Jan 1995 19:53:00 -0600 Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA12875; Thu, 19 Jan 1995 17:52:50 -0800 Received: by hplabsz.hpl.hp.com (1.37.109.14/15.5+ECS 3.3+HPL1.1) id AA042386703; Thu, 19 Jan 1995 17:51:43 -0800 From: Ted Laliotis Message-Id: <199501200151.AA042386703@hplabsz.hpl.hp.com> Subject: Information Superhighway Conference To: rem-conf@es.net, atm@bbn.com, end2end-interest@venera.isi.edu, f-troup@sl.cis.upenn.edu, g-troup@dworkin.wustl.edu, ccrc@dworkin.wustl.edu, arl@arl1.wustl.edu, tcplw@cray.com, announcements.chi@xerox.com, sound@acm.org, sigmedia@bellcore.com, icad@santafe.edu, cip@bbn.com, iplpdn@cnri.reston.va.us, smds@cnri.reston.va.us, s-comput%tcsvm.BITNET@uunet.uu.net, ir-l%uccvma.bitnet@cunyvm.cuny.edu, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, sig11@roses.stanford.edu Date: Thu, 19 Jan 95 17:51:43 PST Cc: laliotis@hplabsz.hpl.hp.com Mailer: Elm [revision: 70.85.2.1] Content-Length: 14732 *******Please post to other groups that may be interested****** TECHNOLOGIES for the SUPERHIGHWAY IEEE COMPCON 95 To be held in San Francisco, March 5-9 at the Stanford Court Hotel. COMPCON '95 is the premier professional conference on Information Superhighway Technologies and applications. It is sponsored by the IEEE Computer Society. There are no exhibits. This is a no-nonsense technical conference for computer science and engineering professionals who are interested to share and learn more about the rapidly growing Information Superhighway business. Besides three days of 90 technical sessions, there are 9 tutorials in relevant subjects. ------------------------------ For Advanced Program (printed copy after Jan 20) e-mail: egrimes@aol.com FAX: 408 973 1325 URL for World Wide Web access: http://www.hal.com/compcon To Register for the conference: e-mail: COMPCON95@lbl.gov FAX: 510 422 2495, Tel: 510 422 2199 Mail: Compcon 95 c/o Dave Hunt, L-130 LLNL, PO Box 808, Livermore, CA 94550 Conference Fees (3 days): Early* On-site IEEE Member $ 325 $ 375 Non-Member $ 425 $ 475 Student $ 50 $ 50 *Early registration cut off: Feb. 21 One-day $175 (Members), $250 (non-members), Tutorials (these cost extra) Full day tutorials same as conference fees 1/2 day tutorials (half above fee) Speakers, committee members, session chairs can all use the lower member prices, whether an IEEE member or not. .pa ============ Master Compcon 1995 plan with papers, sessions and Tutorials ============ Theme: TECHNOLOGIES for the SUPERHIGHWAY MONDAY March 6, 1995 Plenary speakers: Professor Dave Farber, Moore Professor of Telecommunications, University of Pensylvania "Glass Tunnels Connecting Broadband Islands - The GII" Jim Clark, Chairman and CEO, Netscape Communications Corp. "Internet = Electronic Commerce, Now!" Monday, Track 1 World Wide Web Topics, W. W. Wilcke, HAL 1. The WWW as a Platform Independent Interface to High Performance Computing, David Robertson and Bill Johnston, Lawrence Berkeley Laboratory 2. WWW Network Traffic Patterns, Jeffrey Sedayao, Intel 3. A Powerful Wide-Area Client, Tak W. Yan, Stanford Univ, and Juergen Annevelink, HP Electronic Commerce on the Internet, D. Gifford, Open Market Inc, and MIT 1. Netbill: An Electronic Commerce System Optimized for Network Delivered Information and Services, Marvin Sirbu and J. Doug Tygar, Carnegie Mellon University 2. Payment Switches for Open Networks, by D. Gifford, A. Payne, L. Stewart, and W. Treese, Open Market, Inc. 3. Payment services for open networks, B. Clifford Neuman, University of Southern California Business on Networks, Fred Strange, LLNL and FSTC 1. Doing Business of the Information Highway: The nine steps to conduct business on the info. highway. F, Strange, LLNL 2. CommerceNet: Spontaneous Electronic Commerce on the Internet Allan M. Schiffman and Jay M. Tenenbaum, EIT 3. Ordering, Distributing and Receipt: Order Processing & Management at IBM, Don Willenborg, IBM 4. Billing, Payment/Settlement, Accounting & Ancillary Services: Netaccount, Deepak Gupte, Nations Bank .pa Monday, Track 2 Is it time to pay attention? Information Highway Trials in the Bay Area, W. J. Lennon, LLNL 1. Wavelength Division Multiplexing Wide Area Network trial: The National Transparent Optical Network Consortium, W. J. Lennon, Lawrence Livermore National Lab 2. Wavelength Division Multiplexing in Local Area Network: Stanford's Starnet, Leonid Kazovsky, Stanford University 3. ATM services Trial: BAGnet and other CalREN supported projects William Johnston, Lawrence Berkeley Lab Distance Learning Technologies, Tom Wilkins, HP 1. Distance Learning on the Desk Top, Pat Portway, Applied Business Telecommunications 2. Distance Learning in Higher Education, Dr. Carla Lane 3. Distance learning the community/corporate connection, Tom Wilkins, HP Satellite Superhighways, Ted Laliotis, HP 1. Superhighway to the home via DBS delivery, Peter Hampton, Primestar Partners 2. Low Earth Orbit (LEO) applications on the horizon, James Stuart, Teledesic 3. Role of satellites in NII and GII, Lawrence P. Seidman, Hughes 4. Gigabit Satellites in Distributed Supercomputing for Global Research, Larry Bergman, JPL .pa Monday, Track 3 Alpha 21164 Microprocessor and Systems, Dileep Bhandarkar, DEC 1. The Organization of the Alpha 21164 Microprocessor Pete Bannon and Jim Keller, Digital Equipment Corporation 2. World's Fastest Workstation, John Zurawski, John Murray, Paul Lemmon. Digital Equipment Corp 3. 21164 based High Performance Multiprocessor Server D.M.Fenwick, D.J.Foley, S.R.VanDoren, Digital Equipment Corporation First generation PowerPC SMP systems, Kimming So, IBM 1. IBM RS/6000 Commercial SMP Systems, James O. Nicholson, IBM 2. AIX Operating System Support for Symmetric Multiprocessing Jack C. O'Quin, Ronald S. Clark and Thomas V. Weaver, IBM 3. The performance and performance methodology for a PowerPC SMP system Bret R. Olszewski, IBM, Jean-Jacques Guillemaud, Groupe Bull Inc PA-RISC: Application-Driven Innovation, Ruby Lee, HP 1. Advanced Performance Features of the 64-bit PA-8000 Doug Hunt, et al , HP, Fort Collins 2. New MP Hardware Architecture for Commercial and Technical Environments, Loren Staley, et al , HP Roseville 3. A Highly Scalable System Utilizing up to 128 PA-RISC Processors Tony Brewer, et al, Convex Computer .pa TUESDAY, March 7, 1995 Plenary speakers: Steve Schramm, VP Engineering, General Magic, "Agents that Travel" Andy Lippman, Associate director, MIT Media Lab, "Distributed Media Bank" Tuesday, Track 4 Information Hosting Services, G. Lidor, Bell Labs, AT&T 1. PersonaLink Agent-based Messaging and Information Services Paul S. R. Chisholm, AT&T 2. InfoSleuth: Networked Exploitation of Information using Semantic Agents, Darrell Woelk and Christine Tomlinson, MCC 3. Enhancing Lotus Notes for Carrier Grade Hosting, Paul Cummings, Lotus Development Corp. Mobile Internet Applications (based on PDAs), Joel Bartlett, DEC 1. Experience with a Wireless World Wide Web Client, Joel F. Bartlett, DEC 2. Enabling PDA's with Wireless Communications, Rick Lane, Motorola 3. Video on Demand in Wireless Communication, E. Tsern, Stanford Univ Infopad, A. Baum, Apple 1. The Infopad Project: Providing Portable Multimedia Access to the Information Highway, Bob Brodersen or Jan Rabaey UC Berkeley 2. Infopad: A Low Power, Wireless Multimedia Terminal, Sam Sheng, UC Berkeley 3. Infonet: Network Infrastructure and Software for Mobile Information Access, My Le, UC Berkeley 4. User Interface and Applications in the Infopad Environment, Andy Burstein or Eric Brewer, UC Berkeley .pa Tuesday, Track 5 Advanced Media Enhancement Technologies. R. Lee, HP 1. An Object-Based Architecture for a Digital Compression Camera, John Beck, et al, HP Chelmsford 2. Realtime MPEG Video via Software Decompression on PA-RISC Processors, Ruby Lee, et al, HP Cupertino 3. Color Recovery: Millions of Colors from an 8-bit Graphics Device, Anthony Barkans, HP Fort Collins Interactive TV, R. Williams, IBM 1. Set-top boxes and applications, Lee Colby, HP 2. Oracle media server and its applications, Andy Laursen, Mark Porter and Jeffrey Olkin, Oracle 3. Video on Demand: Hong Kong trial, R. Haskin and F. Stein, IBM Storage Hierarchy in Multimedia Systems, M. Kienzle, IBM 1. Buffering and Caching in Large-Scale Video Servers, Asit Dan, Dan Dias, Rajat Mukherjee, Christos Polyzois, Dinkar Sitaram, Renu Tewari, IBM 2. Using Tertiary Storage in Video-on-Demand Servers Martin Kienzle, Asit Dan, Dinkar Sitaram, and William Tetzlaff, IBM 3. Server Preroll RPC for Client/Server Multimedia M.Baugher, G.Flurry, J.Wilkinson, IBM 4. Elements of scalable video servers, W. Tetzlaff, IBM and R. Flynn, Polytechnic University. .pa Tuesday, Track 6 HAL Computer Systems, Wen Li, HAL 1. Architectural Overview of HAL Systems, Winfried W. Wilcke, HAL 2. The CPU Microarchitecture, Niteen Patkar, HAL 3. Cache and Memory Management Microarchitecture, Chien Chen and Dave Lyon and David Chang, HAL PowerPC Processors, S. Peter Song, IBM and Nasr Ullah, Motorola 1. A PowerPC Microprocessor for the Low Power Computing Market, Deene Ogden, Belli Kuttanna, Albert J. Loper, Soummya Mallick and Michael Putrino, IBM 2. The PowerPC 620 Microprocessor: A High Performance Superscalar RISC Microprocessor, David Levitan, Thomas L. Thomas, Motorola and Paul Tu, IBM 3. A Pipelined, Weakly-Ordered Bus for Multi-Processing Systems Michael Allen and Kurt Lewchuk, Motorola Power PC software and Systems, N. Ullah, Motorola, M. NguyenPhu, IBM 1. The PowerPC Architecture: 64-bit Power with 32-bit Compatibility C. Ray Peng, Motorola, Tom Petersen and Ron Clark, IBM 2. The PowerPC 620 in Distributed Computing, Michael P. Taborn, John K. Yuan, David C. Lee, and Albert Tsay, IBM 3. Developing Windows NT Applications for the PowerPC, Howard C. Thamm, Motorola 4. Using the PowerPC Microprocessor for Power-Managed Systems (by IBM), Keith Braithwaite, IBM .pa Social Hour: TOP OF THE MARK, MARK HOPKINS HOTEL, 5:30 - 7:30 Note: The TOP OF THE MARK is a restaurant on top of a hotel tower next to the conference hotel. Since both hotels are on top of Nob Hill, the view from the TOP OF THE MARK is absolutely spectacular. .pa WEDNESDAY, March 8, 1995 Plenary speakers: Professor Dave Patterson, UC Berkeley "A Case for Networks of Workstations: NOW" John Warnock, CEO of Adobe Systems "The New Information Frontier" Wednesday, Track 7 NOW: Networks of Workstations, D. Patterson, UC Berkeley 1. The IBM SP-2, Tilak Agerwala, IBM 2. The Berkeley NOW Project, Thomas E. Anderson, David E. Culler, and David A. Patterson, U.C. Berkeley 3. Tempest: User-level Shared Memory", Mark D. Hill, James R. Larus, and David A. Wood, University of Wisconsin High speed network protocols, W. Lennon, LLNL 1. 1394 --It's Everywhere, Dan Moore and Gary Hoffman, Skipstone Inc. 2. Fibrechannel 1995, Ed Frymoyer, HP 3. Local Area MultiProcessor: surpassing clusters, David B. Gustavson, SCIzzL, and Prof. Qiang Li, Santa Clara University ATM panel, S. Bell, Bell Consulting 1. The WAN Perspective, Larry Roberts, CEO ATM Systems 2. The LAN Perspective, Robert Newman, Dir. ATM, Synoptics 3. The Silicon Perspective, Akber Kazmi, Philips Semiconductor .pa Wednesday, Track 8 Taligent Object Services, J. Grimes, Taligent 1. Runtime Services for Persistent Objects, Russell Nakano, et al, Taligent 2. An Object-Oriented Device Driver Model, Steve Lemon, et al, Taligent 3. Object-Oriented Wrappers for the Mach Microkernel, Stephen Kurtzman and Kayshav Dattatri, Taligent Multimedia Authoring and Acrobat, J. King, Adobe and M. Harrison, UC Berkeley 1. Technical Issues in Hypermedia Scripting Languages, Brian F. Dennis and Prof. Michael A. Harrison, UC Berkeley 2. Acrobat 2.0, Andrew Shore, Adobe Systems 3. Choosing the Right Tool for the Job: Authoring vs. Programming Tools, Michael McGrath, Grafica Multimedia, Inc. Post-Production (Hollywood), A. Fetzer, consultant 1. Digital Editing Technology in Broadcast Video Production Leon Siverman, Laser Pacific 2. Digital Technology and the Convergence in Film, Video and Multimedia Bruce Pfander, 20th Century Fox 3. Digital Editing Technology - A Film Maker's Perspective Andrew Silver, Silver Productions .pa Wednesday, Track 9 Advanced CD systems, W. Lenth 1. CD technology for the future, Hoss Bozorgzad, Philips 2. CD and Competing Mass Storage Technologies in an Application Driven Environment, Paul Wehrenberg, Apple 3. CD or not to CD, A. Bell, IBM High Performance Storage Systems, R. Morris, IBM 1. Scalable Network Storage, E. K. Lee, Digital Equipment Corporation 2. The Parallel Scotch Storage Server, G. Gibson, CMU 3. Future Directions in RAID, J. Menon, IBM New Trends in Storage Management, J. Menon, IBM 1. ADSM: A multi-platform, scalable, backup and archive mass storage system. L-F Cabrera, B. Rees, S. Steiner, et al. IBM 2. An Object Oriented Model for Distributed Storage Management, David Low, EMC 3. Step by Step, Hierarchical Storage Management, Jim Gast, Palindrome 4. Data Striping for Heterogeneous Environments, Jim McNiel, Cheyenne .pa Wednesday, Track 10 The UltraSPARC Microprocessor with Multimedia Support, Robert Garner, SUN 1. UltraSPARC: The Next Generation Superscalar 64b SPARC Dale Greenley, et al, SUN 2. Verification of the UltraSPARC Microprocessor Shrenik Mehta, et al, SUN 3. The Visual Instruction Set (VIS) in UltraSPARC, Marc Tremblay, SUN 4. Video processing with UltraSparc, Chang Zhou, et al, SUN Can Digital Technology Reinvent the Newspaper? Panel, Paul Freiberger, Interval Research 1. Publishing today is like an electronic pinata, Paul Saffo, Institute for the Future. 2. An optimistic view that says hardware is key, John Markoff, New York Times 3. Bill Mitchell, Director of Mercury Center, Knight-Ridder Inc. Internet Access to Environmental Data, P. Mantey, UC Santa Cruz 1. SEQUOIA 2000, Joseph Pasquale, UC San Diego 2. BADGER: Bay Area Digital GeoResource, David Milgram Lockheed Research Laboratory 3. REINAS: Real-Time Environmental Information Network and Analysis System, Darrell Long, UC Santa Cruz ============== TUTORIALS Sunday, March 5 Yale N. Patt, Computer Architecture Choices Steve W. Bell, ATM Overview Lawrence Rowe, Digital Audio and Video Compression, Multimedia Systems and Applications Henry A. Sowizral, Understanding and Developing Virtual Reality Systems Thursday, March 9 Robert Orfali, Dan Harkey and Jim Gray, Client/Server Overview and Update Dave Grubb and Jerry Owens, Exploring INTERNET on your PC Borko Furht, Distributed Multimedia Systems and Applications Jim King, Color on the Desktop, (1/2 day) M. Ketabchi, Is DBMS Technology in Chaos, Modern DBMS approaches Products and Standards and Trends (1/2 day) Updated 1/6/95 Robin Williams (Program Chair) rwilliams@almaden.ibm.com Winfried W. Wilcke (General Chair) wilcke@hal.com Ted Laliotis (Steering Committee Chair) laliotis@hpl.hp.com Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26929; Thu, 19 Jan 1995 15:30:25 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26924; Thu, 19 Jan 1995 15:30:23 -0600 Received: from pigseye.mmm.com (pigseye.mmm.com [130.99.3.1]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id PAA20163 for ; Thu, 19 Jan 1995 15:30:22 -0600 From: jrbumblis@mmm.com Received: by pigseye.mmm.com (1.38.193.5/SMI-4.1) id AA20313; Thu, 19 Jan 1995 15:34:02 -0600 Date: Thu, 19 Jan 1995 15:31:31 -0600 Message-Id: <9501192131.AA17498@MOLE.mmm.com> To: @newlst.20@mmm.com Subject: IEEE 20th LCN Call for Papers. Content-Length: 2685 ********** CALL FOR PAPERS ********** 20th Annual Conference on Local Computer Networks "The Conference on Practical Leading Edge Computer Networking" October 15-18, 1995, Minneapolis, Minnesota, USA =============================================================== Sponsored by: IEEE Computer Society TC-Computer Communications =============================================================== Theme: The emphasis on this year's conference is on practical experience using computer networks in both the local area and in the global area. This unique approach simulates a workshop environment and allows for an effective interchange among users, researchers, and vendors. Some of the primary goals of the conference are to enable those involved in the local computer network field to share experiences, lessons learned, and prototype data and analysis. Because of these objectives, papers based on experience are especially solicited. The focus of the 20th LCN will be Practical Experience Using and Deploying Local Computer Networks. Papers that cover these areas are explicitly sought and will be given preference. Information for Authors: All authors must submit 5 full copies of the full technical paper by mail or delivery service. DO NOT SUBMIT COMPLETE PAPERS BY FAX. The first page must contain: title of the paper, author's names including affiliations, complete mailing address, telephone and FAX numbers, Internet or Bitnet address, and a 250 word (maximum) abstract (double-spaced) in English to Joe Bumblis, Program Chair, at the address below. Sessions are being organized on: o Internetworking/Routers/Bridges o High Performance Protocols o Multimedia o Metropolitan Area Networks o Distributed Applications o LAN/MAN/WAN Integration o Wide Area Networks o Standards o ATM o Network Management o Fibre Channel Networking o Remote Monitoring o High Speed Networks o Wireless Networks o Error Control Techniques o Emerging Technologies o Congestion Control o Realtime Networks o FDDI and FDDI-II o AI Networks Send papers to: Joe Bumblis, Program Chair Important Dates: 3M 3M Center, Building 224-4N-27 Submission: March 21, 1995 St. Paul, MN 55144-1000 Acceptance: June 27, 1995 Camera Copy: August 1 1995 +1 612-737-4763 (office) Conference Summary +1 612-736-7689 (fax) - Tutorials - Technical Paper Sessions jrbumblis@mmm.com - Panel Discussions Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA13391; Thu, 19 Jan 1995 13:56:52 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA13377; Thu, 19 Jan 1995 13:56:49 -0600 Received: from sun2.nsfnet-relay.ac.uk (sun2.nsfnet-relay.ac.uk [128.86.8.45]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id NAA07532 for ; Thu, 19 Jan 1995 13:56:38 -0600 From: john@cogsci.edinburgh.ac.uk Via: uk.ac.edinburgh.cogsci; Thu, 19 Jan 1995 16:40:32 +0000 Date: Thu, 19 Jan 95 16:40:19 GMT Message-Id: <28141.9501191640@ossian.cogsci.ed.ac.uk> To: cellular@dfv.rwth-aachen.de, tccc@cs.umass.edu, perform@tay1.dec.com, end2end-interest@ISI.EDU, ietf@ISI.EDU, rem-conf@es.net, announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, cip@bbn.com, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sig11@roses.stanford.edu, smds@cnri.reston.va.us, sound@acm.org, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca, schulzrinne@fokus.gmd.de Subject: Workshop (sorry if you've seen this already) Content-Length: 6779 CALL FOR CONTRIBUTIONS and Registration Form This document is also accessible on the Web via the following URL: http://www.cogsci.ed.ac.uk/~john/IMMI_call/ IMMI-1 First International Workshop on Intelligence and Multimodality in Multimedia Interfaces: Research and Applications Human Communication Research Centre and EdCAAD, Dept. of Architecture University of Edinburgh Edinburgh, Scotland Thursday 13th - Friday 14th July 1995 Arranged on behalf of: UK Dept. of Trade and Industry (DTI) Intelligent Systems Integration Programme: Special Interest Group on Intelligent Interfaces (IISIG) In cooperation with the AAAI and in association with The HCI Group (a specialist group of the BCS) ACL SIGMEDIA BT Multimedia is hailed as the next great step forward in interface technology. But the potential of this technology depends on a greater understanding of how to exploit it more dynamically and interactively. Bringing ``intelligence'' into multimedia interfaces is thus increasingly important. This Workshop seeks to assess progress and examine pointers for future research and development directions; it seeks also to highlight issues arising from experience of real multimedia applications, and hence encourages industrial participation and reports from practice. Contributions are invited concerning all kinds of work in the area. Themes include (but are not restricted to): * Intelligent guidance for the creation, indexing and presentation of material stored in multimedia form (as in CD-I). * The development of techniques to handle presentation and dialogue involving arbitrary information in different media. * A focus on the interpretation (semantics) of different channels of communication, allowing display of the same information in different ways (often termed ``multimodality''). * The relationship between multimodal presentation and aspects of users' tasks (e.g. reasoning, identification, etc.), including cognitive approaches to multimodal communication. * Formal methods for specification and reasoning in multimodal interactive systems. * A special theme on the integration of natural language and speech processing technology with interaction using other modalities such as graphics. A followup Workshop is proposed, to be held in Cuernavaca, Mexico, in late 1996, with the intention of further fostering transatlantic links. Edinburgh, historic capital of Scotland, is one of the most attractive of European cities. This Workshop will be located in the majestic City Chambers, less than five minutes' walk from the famous Castle. University accommodation will be available very close to the venue. Edinburgh in Summer is invariably host to a wide range of events and activities, which in 1995 includes for instance the spectacular Tall Ships Race, due to begin immediately following the Workshop. Abstracts of approximately 5 pages in length should be submitted by 14th February 1995 (preferably in electronic form) to: John Lee Human Communication Research Centre University of Edinburgh 2 Buccleuch Place Edinburgh EH8 9LW Scotland, UK. Email: J.Lee@ed.ac.uk Tel: +44 131 650 4420 Fax: +44 131 650 4587 IMMI-1 URL: http://www.cogsci.ed.ac.uk/~john/IMMI_call/ Requests for further information, registration forms, bookings for accommodation etc. should be directed to the same address. A notice of intention to submit an abstract would be appreciated as early as possible. Abstracts will be refereed: participation is limited to promote discussion. Accepted abstracts will be published in the quarterly of the IISIG ("IIQ": ISSN 1356-3262) and it is intended that selected authors will be invited to expand their contributions into full-length papers to be published in book form. International Programme Committee: Elisabeth Andre, DFKI, Germany Noelle Carbonell, CRIN, France Ernest Edmonds, LUTCHI, UK Alistair Kilgour, Heriot-Watt University, UK John Lee, HCRC/EdCAAD, UK Mark Maybury, Mitre Corp., US Jon Oberlander, HCRC, UK Fabio Paterno, CNUCE, Italy Luis Pineda, IEE, Mexico Mike Revett, BT, UK Keith Stenning, HCRC, UK Michael Wilson, RAL, UK Kent Wittenburg, Bellcore, US --------------------------------------------------------------------- REGISTRATION FORM IMMI-1 1st International Workshop on Intelligence and Multimodality in Multimedia Interfaces The Workshop will be held in the Edinburgh City Chambers, 13-14 July 1995 Accommodation is available in Edinburgh University accommodation buildings at Mylne's Court. This is an excellently converted tenement building in the heart of the 18th-century Old Town of Edinburgh, offering a choice of single or twin rooms. It is located very close to the Castle, and about 3 minutes' walk from the Workshop venue. Bed and breakfast will cost 19.95 pounds (sterling) per night. Car parking is unfortunately not easy. Rooms will be available over the weekend for those who wish to extend their stay. Early registration is highly advisable for the University accommodation, due to the limited number of rooms available (especially single rooms). There is also a range of high-quality hotels in the city centre, within easy access of the venue (details can be supplied). The Workshop Fee, which includes preprints etc., lunches and a social event, but not accommodation, is 100 pounds (sterling). There is a discount of 20% for students and members of the BCS HCI Group. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please complete the following details for Registration at IMMI-1: Name: Address: Post/Zip code: Telephone: FAX: Email: Registration fee = 100 pounds sterling (or with 20% discount = 80 pounds, if student or HCI Group member -- please enclose evidence). Cheques, money orders etc. in sterling to be payable to the University of Edinburgh. I wish to reserve University accommodation (Mylne's Court) _____ (yes/no) If "yes": Number of rooms required: _____ (single) _____ (twin) Nights required (mark as applicable): Wed. 13th Thurs. 14th Fri. 15th Sat. 16th Other (please specify) Please send completed form and Registration Fee to: John Lee Human Communication Research Centre University of Edinburgh 2 Buccleuch Place Edinburgh EH8 9LW Scotland, UK. Email: J.Lee@ed.ac.uk Tel: +44 131 650 4420 Fax: +44 131 650 4587 A copy of this registration form is also available via the IMMI-1 URL: http://www.cogsci.ed.ac.uk/~john/IMMI_call/ Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA25641; Thu, 19 Jan 1995 11:32:58 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA25633; Thu, 19 Jan 1995 11:32:53 -0600 Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id LAA19573 for ; Thu, 19 Jan 1995 11:32:50 -0600 Received: from opera.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA04561; Thu, 19 Jan 1995 09:31:00 -0800 Received: from localhost by opera.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1) id AA17451; Thu, 19 Jan 1995 09:30:00 -0800 Message-Id: <9501191730.AA17451@opera.hpl.hp.com> To: cellular@dfv.rwth-aachen.de, tccc@cs.umass.edu, perform@tay1.dec.com, end2end-interest@isi.edu, ietf@isi.edu, rem-conf@es.net, announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, cip@bbn.com, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@acm.org, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca Cc: pitt@hplms26.hpl.hp.com, burak@fokus.gmd.de, ofek@watson.ibm.com Subject: 7th IEEE LAN/MAN Workshop Date: Thu, 19 Jan 95 09:29:59 -0800 From: Daniel Pitt Content-Length: 19717 The deadline is approaching for registration for the 7th IEEE Workshop on Local and Metropolitan Area Networks, to be held in the Florida Keys March 26-29. Highlights include: - a rapid-fire technical program of short, pointed talks - a great keynote speaker, whose wit and insight leave a lasting impression - an intimate setting conducive to lots of discussion - unprecedented worldwide participation - a fabulous location. Found below are the Workshop announcement, the program, and the registration materials. You are urged to act immediately; attendance is limited. ============================================================================ Seventh IEEE Workshop on Local and Metropolitan Area Networks March 26-29, 1995 Hawk's Cay Resort and Marina Marathon, Florida Sponsored by the IEEE Communications Society Local and metropolitan area networks are currently the forging place for new network technologies, broadband services, and multimedia applications. The purpose of the present workshop is to examine the new local ATM technologies, cable and other public multimedia delivery systems, various networking architectures, and the provisioning of networks for the support of broadband multimedia services for businesses and homes. A main theme of this year's Workshop is public and private ATM networks: differences and seams. A prominent feature of this Workshop is its emphasis on short, pointed presentations with ample opportunities for debate and discussion. Controversy is encouraged. Attendance is very limited, so early registration is strongly advised. The Workshop will be held a week before IEEE INFOCOM'95 which will be in Boston from April 2 to 6, 1995. The Workshop will begin with an evening reception on March 26. Technical sessions will begin Monday morning March 27 and conclude around lunchtime on March 29. The program and registration forms follow below. Workshop Committee ------------------ Chair: Yoram Ofek (IBM Watson Research) e-mail: ofek@watson.ibm.com phone: 1-914-784-7085 fax: 1-914-784-6205 Program co-chairs: Daniel Pitt (Hewlett-Packard Laboratories) Markus Burak (GMD FOKUS) Committee: Anthony Acampora (Columbia University) Andres Albanese (ICSI) Joseph Bannister (The Aerospace Corporation) James Field (University of Waterloo) Luigi Fratta (Politecnico di Milano) Mario Gerla (UCLA) Wolfram Lemppenau (IBM Zurich Research) Luciano Lenzini (CNR-CNUCE) Gottfried Luderer (Arizona State University) Fabio Neri (Politecnico di Torino) Allyn Romanow (Sun Microsystems) Izhak Rubin (UCLA) David Skellern (Macquarie University, Sydney) Tatsuya Suda (University of California, Irvine) Csaba Szabo (Technical University of Budapest) Yutaka Takahashi (Kyoto University) Nguyen Tat (MATRA) Fouad Tobagi (Stanford University) Terry Todd (McMaster University) Pitro Zafiropulo (IBM Zurich Research) ============================================================================== ------------------------------------------------------------------------- 7th IEEE LAN/MAN Workshop Program Keynote Speaker --------------- Howard Salwen, Chairman, Proteon, on how we ended up here and what comes next ---------- Session 1: Medium Access Controls -"A Full-duplex Ring with a Fairness Cycle Window," T.-J. Kim, ETRI, Korea; B.-C. Shin, Korea Advanced Institute of Science and Technology, Korea -"Pros and Cons of the Global Fairness Algorithms of CRMA-II," M. Ajmone-Marsan, C. Casetti, F. Neri, Politecnico di Torino, Italy -"The MetaRing MAC Protocol: Performance Evaluations in an Interconnected Environment," G. Anastasi, L. Lenzini, Universita di Pisa, Italy -"A Distributed Cycle Reset Protocol for High-Speed LAN/MAN," H.-B. Jeon, S.-H. Lee, S.-Y. Song, TNRL, Korea Telecom, Korea -"Prototype of an ATM-Based MAN for Multimedia Services," S.-M. Jiang, G. Pujolle, Universite de Versailles, France -"DQCA: A New Medium Access Control Protocol for Broadband Networks," W. Lu, Universiti Teknologi Malaysia, Malaysia ---------- Session 2: New Legacy LANs, Traffic Characterization, and Connectionless ATM -"Message Waiting Times in a LAN Using the Demand-Priority Access Method," W. Seah, Y. Takahashi, T. Hasegawa, Kyoto University, Japan -"Interactive Real-Time Communication in Shared-Medium High-Speed LANs," P. Martini, J. Ottensmeyer, Universitaet Paderborn, Germany -"Testing Bursty Traffic in an ATM Testbed," L. Cheng, H. D. Hughes, Michigan State University, USA -"On the Self-Similar Nature of the Traffic Offered to a MAN," M. Cinotti, S. Giordano, F. Romani, F. Russo, Universita di Pisa, Italy -"On Long-Range Dependence in NSFNET Traffic," S. Klivansky, A. Mukherjee, Georgia Institute of Technology, USA; C. Song, Advantis, USA -"Connectionless Traffic Service in ATM Networks," S. Subramaniam, A. Somani, University of Washington, USA -"Partial Connections Method for the Support of Ethernet Emulation over ATM," R. Brown, J. Pihlaja, Nokia, Finland; N. Kavak, Telia Research, Sweden; A. Meier, IBM, Switzerland ---------- Session 3: Multicasting and Convergence Protocols -"ACBT: A Scalable Routing Protocol for Receiver-Initiated Multicasting in ATM Networks," F.-C. Liaw, FORE Systems, USA -"Providing Protocol Support for Multimedia Broadcasting," S. Beocking, Siemens AG, Germany; R. Schatzmayr, TU-Berlin, Germany -"ATM Adaptation Layer and Group Communication Servers for High-Performance Multipoint Services," G. Carle, Universitaet Karlsruhe, Germany -"An Experimental AAL2 Protocol," D. Brooks, S. Srinidhi, Sterling Software, USA; V. Konangi, Cleveland State University, USA -"A Cooperative Protocol Stack Supporting High-Priority Traffic in an ATM Network," E. Klovning, Telenor Research, Norway -"An Object-Oriented Framework for ATM Interworking and Call Control Software," A. Scheidegger, University of Washington, USA ---------- Session 4: ATM Experience and Video Transport -"BATES - BERKOM ATM Technology Evaluation System," D. Elias, GMD-Fokus, Germany -"The Art of ATM Testing," F. Schulz, J. Micheel, M. Burak, GMD-Fokus, Germany -"Operational Experiences with Fast Packet Technologies in the Internet Environment," P. Mohta, CERFnet, USA -"Continuous Media Dissemination over ATM Networks," G. Polyzos, University of California at San Diego, USA -"Video Transmission over Lossy Packet Networks," A. Albanese, International Computer Science Institute, USA -"Analysis and Modeling of an MPEG-1 Video Source," M. Conti, E. Gregori, A. Larsson, CNR - Istituto CNUCE, Italy -"Adaptive Neural Video Compression," C. Cramer, E. Gelenbe, P. Gelenbe, M. Sungur, Duke University, USA ---------- Session 5: Traffic Management -"A Bandwidth Allocation Scheme to Support Delay Sensitive Traffic in a DQDB MAN," J. Vozmediano, Universidad de Sevilla, Spain; E. Vazquez, J. Berrocal, Universidad Politecnica de Madrid, Spain -"Scheduling and Admission Control Policies: A Case Study for DQDB and ATM," K. Steenhaut, K. Degieter, W. Brissinck, Vrije Universiteit Brussel, Belgium -"Performance Evaluation of Rate Control in ATM Networks," P. Tse, M. Zukerman, Telstra Research Laboratories, Australia -"Best-Effort Statistical Multiplexing of Delay-Tolerant Links in ATM," M. Mateescu, GMD-Fokus, Germany -"A Comparison of Per-VC Queueing and Explicit Rate Algorithms for ABR Traffic," R. Krishnan, Motorola, USA -"MULTIRING, a Possible Post-ATM Network Architecture," W. Dobosiewicz, Monmouth College, USA; P. Gburzynski, University of Alberta, Canada ---------- Session 6: Traffic Control and Quality of Service Provision -"An Adaptive Multi-Service Generic Flow Control Protocol," J. Macharia, Jomo Kenyata University, Kenya; L.-J. Yao, University of Adelaide, Australia -"Packet or Cell Loss Reduction in Networks," V. Srinivasan, E. Gelenbe, A. Ghanwani, Duke University, USA -"Provision of Time-Constrained Services in ATM Networks," G. Mercankosk, Curtin University of Technology, Australia -"QoS Management for Service Integrated Communication Systems," C. Schmidt, M. Zitterbart, Universitaet Karlsruhe, Germany -"QoS Management in a Mobile Multimedia Environment," P. Ray, S. Jha, A. Seneviratne, University of Technology-Sydney, Australia -"A Simple Method for Evaluating QoS Parameters," J.-H. Lin, J.-L. Chen, Industrial Technology Research Institute, Taiwan ROC; J. Biswas, Institute of Systems Science, Singapore. -"Architectural Factors in the Provision of Services by Broadband Customer Premises Equipment," M. Hogan, R. Keaney, E. Wilson, M. Hudson, M. Bickerstaff, D. Skellern, M. Krischer, Macquarie University, Australia ---------- Session 7: Switching Architecture -"CellBus: A Flexible Architecture for ATM LANs," D. Upp, P. Goli, TranSwitch, USA; S. Ghosh, J. Hammond, Clemson University, USA -"A Fast Algorithm for Scheduling Cells in Input-Queued Switches," N. McKeown, Stanford University, USA; J. Walrand, Univesity of California at Berkeley, USA -"A Multicasting Switch for ATM LAN/MAN," S. Shyamsukha, A. Monster, Temple University, USA -"Modular VLSI Implementation Architecture for High-Performance Communication Support," J. Schiller, M. Zitterbart, Universitaet Karlsruhe, Germany -"Performance of Multi-Channel Asymmetric Packet Switch Modules in a Bursty and Nonuniform Traffic Environment," A. Chatterjee, V. Konangi, Cleveland State University, USA -"Analysis of a Class of Telecommunication Models," H. Gail, S. Hantler, IBM, USA; A. Konheim, University of California at Santa Barbara, USA; B. Taylor, University of Michigan, USA ---------- Session 8: Network Organization -"Distributed ATM Switching System for Corporate Communication Networks," R. Hamidi, J.-P. Quinquis, CNET, France -"Virtual Networking in ATM LANs and MANs," M. Gerla, S. Fotedar, University of California at Los Angeles, USA; P. Crocetti, Italtel, Italy; L. Fratta, Politecnico di Milano, Italy -"Migrating to ATM in the Local Area," V. Friesen, J. Wong, University of Waterloo, Canada -"The Metropolitan Area Community Network," C. Venkatraman, D. Pitt, Hewlett-Packard Laboratories, USA -"A MAN Architecture based on a Meshed Network Crossconnect," T. Kuehnel, G. Luderer, Arizona State University, USA -"Ring Networks with Random Extra Links," M. Kovacevic, A. Acampora, Columbia University, USA -"Virtual Embeddings for Linearization of Arbitrary Topology Networks," B. Yener, M. Yung, IBM, USA ---------- Session 9: Optical Networking -"The Use of Wavelength-Selective Couplers in Optical Local Area Networks," T. Todd, A. Grah, O. Barkovic, McMaster University, Canada -"Optical Latency Storage - Unifying Data Communication in Space and Time," T. Pfeifer, Technische Universitaet Berlin, Germany -"A Scalable Optical Packet Switching Network Architecture," I. Chlamtac, University of Massachusetts, USA; V. Elek, C. Szabo, Technical University of Budapest, Hungary; A. Fumagalli, Politecnico di Torino, Italy -"An Adaptable Protocol for Processor Interconnection in a WDM-based Network," P. Dowd, D. Crouse, State University of New York at Buffalo, USA -"ISONet: A Dynamically Reconfigurable Integrated Services Optical Network," T. Bujewski, The Aerospace Corporation, USA; M. Gerla, University of California at Los Angeles, USA -"Implementing the DQDB using Wavelength Division Multiplexing," A. Kamal, H. Hassanein, Kuwait University, Kuwait ----------- Session 10: Technologies for High Performance, and Wireless ATM -"Using ATM Networks Effectively for High-Performance Applications," A. Guha, W. Franta, Network Systems Corporation, USA -"Affordable High Performance Computing: Evaluation of Cluster-based Computing via ATM," P. Dowd, E. Blade, State University of New York at Buffalo, USA; S. Srinidhi, Sterling Software, USA; R. Claus, NASA Lewis Research Center, USA -"Slack-Protocol Design and Performance in Wormhole-Routing Networks," J. Bannister, The Aerospace Corporation, USA; M. Gerla, S. Walton, University of California at Los Angeles, USA -"Fair Cascades of Fibre Channel Switches," L. Cherkasova, V. Kotov, T. Rokicki, Hewlett-Packard Laboratories, USA -"Cut-Through Routing in Intermediate Systems," O. Riebe, Humboldt Universitaet zu Berlin, Germany -"ATM Transport and GSM Circuit and Packet Mode Access Networks: A Platform for Mobile Multimediea of the Immediate Future," S. Chakraborty, Helsinki University of Technology, Finland -"Signaling and Mobility Management in a Wireless ATM LAN," M. Veeraraghavan, M. Karol, AT&T Bell Laboratories, USA ============================================================================= ------------------------------------------------------------------- 7th IEEE Workshop on Local and Metropolitan Area Networks REGISTRATION FORM Name: _______________________________ Company/Affiliation: _________________________________ Address: ____________________________________ ____________________________________ Tel.: ____________________ Fax.: ___________________ E_Mail: _________________ ___ $100 enclosed in personal check or money order payable to "IEEE WORKSHOP 94" Mail the check to: ------------------ Yoram Ofek Workshop Chair IBM T. J. Watson Research Center P.O.Box 704 Yorktown Heights, NY 10598 e-mail: ofek at watson.ibm.com Telephone: (914) 784-7085 FAX: (914) 784-6205 Participants from outside the US, -------------------------------- can send the 100 Dollar registration via INTERNATIONAL CABLE (money transfer) directly --------------------------------------------- to the workshop account: ------------------------ * Routing # 021 000 128 * For Credit to account # 258 500 172 465 * "IEEE 95 WORKSHOP" * Chemical Bank * 324 Saw Mill River Rd. * Elmsford, NY 10523, U.S.A. ===================================================================== HAWK'S CAY RESORT AND MARINA REGISTRATION FORM FOR 7th IEEE WORKSHOP on LOCAL and Metropolitan Area Networks March 26, 1995 - March 29, 1995 Arrival Date ........... Arrival Time ....... Departure Date ...... (List early arrival/late departure dates, if applicable) (GROUP RATES MAY NOT BE AVAILABLE TO EARLY ARRIVALS/LATE DEPARTURES) NAME ....................... SIGNATURE ........... COMPANY ................... PHONE# .............. ADDRESS ............................................ CITY ............. STATE ........... ZIP ....... CREDIT CARD TYPE (Circle One) MC VISA DISCOVER DINERS AMEX CREDIT CARD# ..................... EXPIRATION DATE ............. NAME ON CARD ..................... SIGNATURE ................... # OF GUESTS IN ROOM (Ages if Children) ........................... Children 11 and under are free, extra person charge $25.00 per night. Children ages 4-11 can attend the group dinners for a non-refundable charge of $50,00 per child. Will children be attending group dinners? ____ Yes ____ No Number of Children attending ............. Ages ............ Smoking ................. Non-smoking ......... (Accommodations in each category are limited. We will make every effort to honor your request, however, it cannot be guaranteed) ACCOMMODATIONS: Package Rates for 3 nights/4 days $636,00 per person, based on a single occupancy $383,00 per person, based on double occupancy Additional nights are available at $160.00 per room, per night, plus tax single or double occupancy, including breakfast. Refunds will not be made on any portion of the IEEE three night package. Check in time is 3:00 pm/Check out time is 11:00am. INCLUDED IN RATES: * Three nights accommodations (March 26-28 nights), inclusive of tax * Lavish Breakfast Buffet on March 27-29, 1995 * Dinners on March 27 and 28, 1995 * Wine and Cheese Reception, March 26, 1995 * Coffee Breaks during the workshop * Morning Newspaper * Transportation to/from Marathon Airport (24 hour notice needed) * Nightly Turndown Service * All gratuities, housekeeper, bellman, breakfast and banquet server * All applicable taxes to the above features * Dolphin training sessions (three times daily) ___ Please check here if you require vegetarian meals at the group dinners. Number of people ___ REGISTRATION FORMS MUST BE COMPLETED AND RETURNED TO: Reservations Department OR FAX TO: Reservations Department Hawk's Cay Resort and Marina (305) 743-5215 Mile Marker 61, Duck Key Marathon, FL 33050 1-(800)-432-2242 COMPLETE ONE FORM FOR EACH ROOM NEEDED - A CONFIRMATION WILL BE MAILED ENTIRE PACKAGE PRICE WILL AUTOMATICALLY BE CHARGED TO YOUR CREDIT CARD CANCELLATION POLICY IS THIRTY DAYS PRIOR TO ARRIVAL CANCELLATION WITHIN THIRTY DAYS WILL RESULT IN FORFEITURE OF DEPOSIT. ** RESERVATIONS MUST BE RECEIVED BY FEBRUARY 26, 1995 TO GUARANTEE YOUR ROOM ** ** AND TO GUARANTEE THE GROUP RATE FOR YOUR ROOM** ---------------------------------------------------------------------------------- HAWK'S CAY RESORT AND MARINA Duck Key, Marathon, Florida. GROUND TRANSPORTATION --------------------- Rental Cars: ----------- Budget Rent a Car Avis Rent a Car General Rent a Car Marathon Airport, FL Marathon Airport, FL Marathon, FL 305-743-3998 305-743-5428 800-327-7607 800-527-0700 305-377-2531 (Miami) Motor Coach ----------- A-1 Bus lines Miami Bus & Limo American Meetings and Conventions Miami, FL Miami, FL Miami Lakes, FL 305-325-1000 305-633-3377 305-621-4181 800-826-6754 Go Tours Grayline Bus Company Marathon, FL Miami, FL 305-743-9876 305-587-8080 Car Services ------------ Ambassador Limo Service Island Taxi Paradise to Reality & Back Miami, FL Marathon, FL Miami, FL 305-931-3111 305-743-6004 305-852-4656 800-245-4667 Miami Airport to Hawk's Cay Resort and Marina --------------------------------------------- Miami International Airport to 836 West until you reach the Florida Turnpike. Stay South on the Turnpike until it ends at US-1. Continue South on US-1 to Mile Marker 61 - Hawk's Cay Resort and Marina !! The drive from Miami International Airport to Hawks' Cay Resort is an hour and forty five minutes. It is a beautiful drive, and is described by Rand-McNally as one of the most scenic drives in the United States, "where the sky and the ocean meet". HAWK's CAY RESORT PROVIDES COMPLIMENTARY TRANSPORTATION TO AND FROM THE MARATHON AIRPORT (please give 24 hours notice). American Airlines 800-433-7300 USAir 800-428-4322 Gulfstream International Airlines 800-992-8532 With expansion of the Marathon Airport (scheduled for completion November 1994), the capacity and number of flights will increase. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA16787; Thu, 19 Jan 1995 10:46:22 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA16774; Thu, 19 Jan 1995 10:46:19 -0600 Received: from uswat.advtech.uswest.com (uswat.advtech.uswest.com [130.13.16.1]) by timbuk.cray.com (8.6.9/8.6.9M) with ESMTP id KAA10297 for ; Thu, 19 Jan 1995 10:22:50 -0600 Received: from atqm.advtech.uswest.com (atqm.advtech.uswest.com [130.13.28.1]) by uswat.advtech.uswest.com (8.6.9/8.6.9) with SMTP id JAA10698; Thu, 19 Jan 1995 09:21:15 -0700 Message-Id: Date: 19 Jan 1995 09:11:34 U From: "Sandy McCrady" Subject: RE- client/server image sof To: announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@BBN.COM, ccrc@dworkin.wustl.edu, cellular@dfv.rwth-aachen.de, cip@BBN.COM, cnom@maestro.bellcore.com, end2end-interest@isi.edu, enternet-ec@BBN.COM, enternet@BBN.COM, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg X-Mailer: Mail*Link SMTP-QM 3.0.1 Content-Length: 432 Reply to: RE: client/server image software Anyone know any good client/server (UNIX) existing software or something that could easily be modified that does image/rastor/TIF manipulation (view/zoom, pan, move around on the screen, print). Need some sort of button/menu control so it can talk on the back end to a pgm that talks to an ORACLE data base. (Windows should be MOTIF and maybe use DCE/Encina.) Any good ideas? Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA07698; Thu, 19 Jan 1995 02:46:31 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA07603; Thu, 19 Jan 1995 02:46:12 -0600 Received: from ceres.fokus.gmd.de (ceres.fokus.gmd.de [192.35.149.15]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id CAA01722 for ; Thu, 19 Jan 1995 02:46:11 -0600 Message-Id: <199501190846.CAA01722@timbuk.cray.com> Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Thu, 19 Jan 1995 09:34:17 +0100 X-Mailer: exmh version 1.5.3 12/28/94 To: cellular@dfv.rwth-aachen.de, tccc@cs.umass.edu, perform@tay1.dec.com, end2end-interest@isi.edu, ietf@isi.edu, rem-conf@es.net, announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, cip@bbn.com, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@acm.org, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca From: Henning Schulzrinne Subject: Infocom'95 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jan 95 09:34:33 +0100 Sender: schulzrinne@fokus.gmd.de Content-Length: 6 help Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA19705; Wed, 18 Jan 1995 12:32:02 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA19676; Wed, 18 Jan 1995 12:31:45 -0600 Received: from ceres.fokus.gmd.de (ceres.fokus.gmd.de [192.35.149.15]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id MAA29739 for ; Wed, 18 Jan 1995 12:31:43 -0600 Message-Id: <199501181831.MAA29739@timbuk.cray.com> Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Wed, 18 Jan 1995 19:09:36 +0100 X-Mailer: exmh version 1.5.3 12/28/94 To: cellular@dfv.rwth-aachen.de, tccc@cs.umass.edu, perform@tay1.dec.com, end2end-interest@isi.edu, ietf@isi.edu, rem-conf@es.net, announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, cip@bbn.com, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@acm.org, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca Subject: Infocom'95 Conference Program and Registration Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Jan 95 19:09:30 +0100 From: Henning Schulzrinne Content-Length: 1074 Infocom'95 --- Bringing Information to People Information about Infocom'95, the Fourteenth Annual Joint Conference of the IEEE Computer and Communications Societies is available through the World Wide Web at http://www.research.att.com/~hgs/infocom95/program.html Infocom'95 takes place in Boston, April 2 - 6, 1995. Roughly 160 papers selected from 450 submissions will be presented, as well as panels on satellite communication and resource reservations. The keynote speaker will be Sandy Fraser, AT&T, with a historical perspective on the information revolution. The conference opens with tutorials on integrated service high speed networks (Robert Gallager), broadband networks and ATM (Anthony Acampora), protocol design (Dave Clark), wireless personal communications (David Goodman), and the World Wide Web (David Tennenhouse and others). ---- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin WWW: http://www.fokus.gmd.de/htbin/info/minos/hgs Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA00585; Fri, 23 Dec 1994 17:24:05 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA00570; Fri, 23 Dec 1994 17:24:01 -0600 Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by timbuk.cray.com (8.6.9/8.6.9M) with ESMTP id RAA07878 for ; Fri, 23 Dec 1994 17:24:00 -0600 Received: (maybury@localhost) by linus.mitre.org (8.6.7/RCF-6S) id SAA06804; Fri, 23 Dec 1994 18:08:23 -0500 Date: Fri, 23 Dec 1994 18:08:23 -0500 From: "Mark T. Maybury" Message-Id: <199412232308.SAA06804@linus.mitre.org> To: vcl@arch4.ho.att.com, joel@arch4.ho.att.com, sig11@roses.stanford.edu, uist.chi@xerox.com, tf-mm@i4serv.informatik.rwth-aachen.de, ir-l%uccvma.bitnet@cunyvm.cuny.edu, s-comput%tcsvm.BITNET@cunyvm.cuny.edu, smds@cnri.reston.va.us, iplpdn@cnri.reston.va.us, cip@bbn.com, icad-request@santafe.edu, sigmedia@bellcore.com, sound@acm.org, announcements.chi@xerox.com, tcplw@cray.com, arl@arl1.wustl.edu, ccrc@dworkin.wustl.edu, g-troup@dworkin.wustl.edu, f-troup@AURORA.CIS.UPENN.EDU, end2end-interest@venera.isi.edu, atm@bbn.com, rem-conf@es.net, ietf@venera.isi.edu, tccc@cs.umass.edu Subject: Intelligent Multimedia Information Retrieval Content-Length: 5765 <> <> <> <> <> <> <> <> <> <> <> <> IJCAI-95 Workshop on INTELLIGENT MULTIMEDIA INFORMATION RETRIEVAL Fourteenth International Joint Conference on Artificial Intelligence (IJCAI-95) Montreal, Canada 1 day during 19th-21st August 1995 (to be determined) BACKGROUND In the past there has been concerted effort, largely performed in independent research communities, addressing the automated processing of single media (e.g., text, imagery, audio). The advent of large, multimedia digital libraries has focused attention on the integrated processing and coordination of multiple media including the traditional focus on textual sources and the increasing emphasis on media with spatial and temporal properties (e.g., sound, maps, graphics, images, video). While there have been focused workshops on integration and coordination of multimedia in interfaces and a national conference on the general subject of multimedia, to date there has been no targeted forum to address processing issues which cross media boundaries but have a fundamental basis in processing human language and artifacts. OBJECTIVES Research in this area is in the formative stages and is just now beginning to address difficult fundamental problems, such as the representation and reasoning about spatial and temporal media. IJCAI-95 presents an opportunity to move toward an integrated view of media processing by addressing a specific technical area: multimedia information retrieval. The language processing, speech processing, image/video processing and spatial/temporal reasoning communities have much to offer and much to learn from one another. The purpose of this workshop is to bring together researchers and practitioners to report on current advances in multimedia information retrieval systems and their underlying theories, to foster scientific interchange among these individuals, and as a group to evaluate current efforts and make recommendations for future investigations. A report on the workshop will be submitted to appropriate magazines (e.g., AI Magazine, IEEE Expert, ACL's FINITE String). An edited collection to include the best papers is planned. ISSUES Submissions (papers and/or video/computer demonstrations) are invited on original research in all aspects of multimedia information retrieval, including, but not limited to: * Content-based analysis and retrieval of multimedia sources (e.g., parsing and integrating text, imagery, maps, audio, video) * Application of speech, language, and image processing methods and techniques to multimedia (e.g., signal analysis, parsing, generation, discourse and user modeling) * Multimedia browsing/visualization tools and cross-media query (e.g, visual, linguistic, and auditory) * Multimedia document/presentation design and display * Tailoring multimedia interaction to particular users, tasks, and contexts * Intra- and inter-media representation languages * Architectures for multimedia information retrieval * Evaluation methods and metrics for multimedia information retrieval * Psychoperceptual and cognitive issues in multimodal information retrieval * Control of user's attention, tension, mood, and sense of continuity by use of appropriate sound, color, and editing * Innovative applications of multimedia information retrieval SUBMISSIONS Interested participants should e-mail (prefered) or forward FIVE copies of a 2,000 to 3,000 word position paper (4-5 pages, double spaced) addressing a specific intelligent multimedia information retrieval issue or reporting novel results to: Mark Maybury, MS-K331, The MITRE Corporation, Bedford, MA 01730 Tel: (617) 271-7230. maybury@mitre.org Submissions must be *received* by February 1, 1994. Please include name, affiliation, address, phone, and e-mail address. Video submissions should be complemented with a written abstract or position paper. Criteria for selection will include clarity, orginality, relevance, and significance of results. Attendance at the workshop will be limited to approximately 30 participants. All participants must register with the main IJCAI conference. The IJCAI WWW home pge is http://ijcai.org/. ORGANIZING COMMITTEE Mark Maybury (chair) The MITRE Corporation, Bedford, MA (maybury@mitre.org) Bill Hefley, Software Engineering Institute, Carnegie Mellon Univ. (weh@sei.cmu.edu) Peter Schauble, Swiss Federal Institute of Technology, Zurich (schauble@inf.ethz.ch) Alex "Sandy" Pentland, MIT Media Lab (sandy@media.mit.edu) Stephen Smoliar, Inst of Systems Science, Univ Singapore, 0511 (smoliar@iss.nus.sg) Oliviero Stock, IRST, Italy (stock@irst.it) Wolfgang Wahlster, DFKI, Germany (wahlster@dfki.uni-sb.de) Kent Wittenburg, Bellcore (kentw@bellcore.com) Kazuo Tanaka, NTT, Japan (tanaka@aether.ntt.JP) Philippe Aigrain, IRIT, France (aigrain@cerise.irit.fr) IJCAI SCHEDULE December 1, 1994 -- Call for participation February 1, 1995 -- Submission deadline February 2, 1995 -- Allocation to reviewers February 30, 1995 -- Notification of acceptance (via e-mail) March 15, 1995 -- Camera-ready workshop paper due April 5, 1995 -- Workshop schedule/participants finalized May 5, 1995 -- Workshop notes due to CRC ???, 1995 -- IJCAI early registration deadline ???, 1995 -- IJCAI late registration deadline August 19, 20, or 21 -- Workshop November 1, 1995 -- Workshop report to Workshops Chair ---------------------------------------------------------------------- Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA04560; Fri, 23 Dec 1994 05:53:46 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA04555; Fri, 23 Dec 1994 05:53:45 -0600 Received: from snap.org (charm.snap.org [192.5.18.230]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id FAA26912 for ; Fri, 23 Dec 1994 05:53:44 -0600 Received: by snap.org (4.1/SMI-4.1) id AA00280; Fri, 23 Dec 94 05:56:40 EST Date: Fri, 23 Dec 94 5:56:40 EST From: Gerd Beling To: "Sean O'Malley" Cc: dab@berserkly.cray.com (David A. Borman), end2end-interest@ISI.EDU, nsrg@cs.arizona.edu, sean@cs.arizona.edu, tcplw@cray.com Subject: Re: Some Thoughts on TCPng In-Reply-To: Your message of Tue, 6 Dec 1994 14:26:02 -0700 (MST) Message-Id: Content-Length: 847 hello again, after having been switched from charm to snap.org, here again some thoughts concerning the pseudo-header: a) It is included in TCP/IPv4 to protect TCP against misrouted IP packets. Now, given that the IP-header is protected by a checksum itself, how likely is the case that a packet is misdelivered with a correct IP-checksum? Is that not a little bit overengineered nowadays with better networks? Did anybody try to find out how many packets werde tossed because the pseudo-header detected an error which IP could not find (and TCP anone woukd have detected)? b) If the pseudo-header has to stay for some reasons I prefer the precise architectural decoupling of the protocols TCPnG and IPv6, i.e. make the pseudoheader part an end2end-option within IPv6 and do NOT include it additionally into the TCPnG checksum regards gerd beling Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26165; Fri, 16 Dec 1994 15:36:39 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA26122; Fri, 16 Dec 1994 15:36:31 -0600 Received: from gw1.att.com (gw1.att.com [192.20.239.133]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id PAA15849 for ; Fri, 16 Dec 1994 15:36:23 -0600 From: cn2@arch4.ho.att.com Received: from arch4.ho.att.com by ig2.att.att.com id AA22061; Fri, 16 Dec 94 14:15:29 EST Received: from arch5.ho.att.com by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA09846; Fri, 16 Dec 94 14:04:39 EST Received: by arch5.ho.att.com (4.1/EMS-1.2 GIS) id AA13711; Fri, 16 Dec 94 14:04:37 EST Date: Fri, 16 Dec 94 14:04:37 EST Message-Id: <9412161904.AA13711@arch5.ho.att.com> To: vcl@arch4.ho.att.com, joel@arch4.ho.att.com, sig11@roses.stanford.edu, uist.chi@xerox.com, tf-mm@i4serv.informatik.rwth-aachen.de, ir-l%uccvma.bitnet@cunyvm.cuny.edu, s-comput%tcsvm.BITNET@uunet.uu.net, smds@cnri.reston.va.us, iplpdn@cnri.reston.va.us, cip@bbn.com, icad-request@santafe.edu, sigmedia@bellcore.com, sound@acm.org, announcements.chi@xerox.com, tcplw@cray.com, arl@arl1.wustl.edu, ccrc@dworkin.wustl.edu, g-troup@dworkin.wustl.edu, f-troup@AURORA.CIS.UPENN.EDU, end2end-interest@venera.isi.edu, atm@bbn.com, rem-conf@es.net, ietf@venera.isi.edu, tccc@cs.umass.edu Subject: Community Networking Call For Participation Content-Length: 5473 ============================================================================= Call for Participation ============================================================================= SECOND INTERNATIONAL WORKSHOP ON COMMUNITY NETWORKING INTEGRATED MULTIMEDIA SERVICES TO THE HOME June 20-22, 1995 Princeton, New Jersey, USA Sponsored by the IEEE Communications Society In collaboration with ACM SIGCOMM* Community networking concerns the network infrastructures that will bring integrated multimedia services to home users. Community networking differs in many ways from enterprise networking in its services, technologies, and economics. In contrast to enterprise networking applications, community networking services will not necessarily be work oriented and will range from entertainment to shopping to information services. At present, community networking technology is driven by the requirements of video-on-demand, most notably high bandwidth (compared to narrowband), bandwidth asymmetry, and the delay-jitter constraints imposed by today's limited-storage TV set-top devices. As various other services develop, community networking will evolve to include integrated multimedia communication and user-to-user applications. Community networking must also provide access to resources located outside the community, in an increasingly global repository of information of every conceivable type. This workshop will give researchers and professionals the chance to share their views and advance the state of the art in this field. RELEVANT AREAS: Contributions are encouraged in the five areas listed below with relevant topics: 1. APPLICATIONS AND REQUIREMENTS: types of applications; coding; set-top operating systems; QoS networking requirements (symmetric/asymmetric bandwidth, delay, and losses); security and privacy; service models; user interface and navigation facilities. 2. LOCAL DISTRIBUTION TECHNOLOGY: topology; fiber/cable/UTP/wireless; modulation, bandwidth allocation; MAC (reverse channel); role of ATM; dependencies on equipment/network in the home (e.g., TV set-top). 3. ADDRESSING, SIGNALING, AND UPPER-LAYER PROTOCOLS: local vs. global addressing; the service provider view vs. the common carrier view: the video-dialtone gateway; role of B-ISDN protocols; network- and transport-layer protocols; network management; APIs. 4. INTERNETWORKING AND ARCHITECTURE: the gateway: accessing other networks (data, telephone); server placement and network optimization; the regional distribution centers; testbeds; network traffic models; network cost structure and its implications on service pricing; medium- and long-term network evolution; the impact of regulatory constraints. 5. COMMUNITY ASPECTS, OPPORTUNITIES FOR GROWTH: the success of community networking depends of the degree to which it meets community needs and invites the full participation of community members; community needs, desires and aspirations; networking approaches that have worked well in the past and others that have not; obstacles to success that need to be overcome. INSTRUCTIONS FOR SUBMITTING ABSTRACTS: Please send via electronic mail a detailed abstract (up to 3 pages in ASCII or PostScript) describing a position statement in one of the areas above to cn2@arch4.ho.att.com Note that submissions longer than the limit above will not be reviewed. Only if electronic submission is impossible, a hardcopy version may be sent to: Joel Winthrop AT&T Bell Laboratories 101 Crawfords Corner Rd., RM 1K-306 Holmdel, NJ 07733, USA Participation in the workshop will be by invitation only based on the Program Committee's review of position statements. Some of the authors will be asked to submit papers and to present them during the workshop. Workshop size limitation may preclude attendance of all authors of multi-author abstracts. DATES: Deadline for submitting abstracts . . . . . . . . March 17, 1995 Acceptance notification . . . . . . . . . . . . . April 17, 1995 Papers due (limited to 8 pages) . . May 19, 1995 PROGRAM COMMITTEE: Program Chair: Joel Winthrop AT&T Bell Labs, Holmdel, New Jersey Publication Chair: Vince Lesch AT&T Bell Labs, Holmdel, New Jersey Committee Members: Joydeep Bose National Computer Board, Singapore Jurgen Brommelhoff Digital Equipment Corporation G. Keith Cambron Pacific Bell Andrew Davidson Phillips Interactive Media of America Jeff H. Derby IBM Corporation Alexander D. Gelman Bellcore Riccardo Gusella Hewlett-Packard Laboratories, Palo Alto, California Gordon Kerr BT Labs Andrew Laursen Oracle Corporation Andrew Lippman MIT, Media Lab Tetsuya Miki NTT Transmission Systems Laboratories Mario Morino Morino Foundation Martin De Prycker Alcatel Bell Telephone, Antwerp, Belgium David Skellern Macquarie University, Sydney Albert J. Stienstra Philips Research Mario P. Vecchi Time Warner Cable, Inc. William E. Wall Scientific-Atlanta, Inc. * Approval Pending Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08890; Wed, 14 Dec 1994 16:12:17 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08882; Wed, 14 Dec 1994 16:12:16 -0600 Received: from N3.SP.CS.CMU.EDU (N3.SP.CS.CMU.EDU [128.2.222.83]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id QAA05520 for ; Wed, 14 Dec 1994 16:12:14 -0600 From: Hui.Zhang@N3.SP.CS.CMU.EDU Message-Id: <199412142212.QAA05520@timbuk.cray.com> Date: Wed, 14 Dec 94 17:05:19 EST To: tcplw@CRAY.COM Subject: CFP: ACM MULTIMEDIA'95 Content-Length: 6907 ACM MULTIMEDIA'95 November 5-9, 1995 Hyatt Regency (Embarcadero) San Francisco, CA THE THIRD ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION Sponsored by the ACM SIG Multimedia, SIGCHI, SIGGRAPH, SIGBIT, SIGOIS, SIGIR, and IEEE Communications Society PRELIMINARY CALL FOR PARTICIPATION Multimedia can substantially improve communication between information providers and consumers by making it more effective and more engaging. ACM Multimedia'95 will provide an international forum for papers, panels, videos, demonstrations, courses, workshops, and exhibits focusing on all aspects of this multi-disciplinary field: from underlying technologies to applications and issues, and from theory to practice. We invite your participation. Topics include, but are not limited to: applications in education, entertainment, government, medicine, etc.; collaboration environments; databases; digital libraries; distributed systems; documents and authoring; hardware and architectures; image, video and audio compression techniques; information retrieval; interactive television; media integration and synchronization; networking and communication; operating system extensions; programming paradigms and environments; standards and legal issues; storage and I/O architectures; tools; user interfaces; and virtual reality. Papers ------ Technical papers on completed or in-progress research, innovative applications, or experience with multimedia systems are solicited. Submissions must use a typeface no smaller than 10 point, double sided if possible, and be no longer than 12 pages including figures, tables, and references. Where applicable, prototype demonstrations or videotape presentations are encouraged to supplement the talks. Submit complete papers to: Polle Zellweger, Program Chair. Outstanding papers on different areas of multimedia will be given awards. Papers with a student as the primary author will enter a student paper award competition. A cover letter must identify the paper as a candidate for the student paper competition. Selected papers will be forwarded to ACM/Springer-Verlag Multimedia Systems, Communications of the ACM, IEEE/ACM Transactions on Networking, or ACM Transactions on Information Systems. Panels ------ Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Proposals should be limited to 2 pages, plus a biography of at most one paragraph for each participant. Submit panel proposals to: Fillia Makedon, Panels Chair. Videos ------ Videos of innovative multimedia technology should be 5-8 minutes long, in NTSC format, and accompanied by one copy of a 1-2 page description of the material shown in the video. Submit videos to: Gil Cruz, Videos Chair. Demonstrations -------------- We solicit demonstrations of working systems in technical and artistic categories. Submissions (at most 2 pages) should include a description of the exhibit, demo requirements, a biography, and a single VHS NTSC video. Submit demonstrations to: Tom Little, Demonstrations Chair. Courses ------- There will be a series of 1/2-day tutorial courses, focused on issues relevant to researchers and/or practitioners of multimedia technology. Proposals (at most 5 pages) should include a description of the subject matter and brief biographical sketches of the instructors. Evaluation of proposals will be based on expertise and experience of instructors, relevance of subject matter, and the use of multimedia technology in the presentation. Submit tutorial proposals to: Sorel Reisman, Tutorials Chair. Workshops --------- Workshops preceding the conference will allow participants to exchange ideas on a topic. Workshop results and issues will be integrated into the main body of the conference. Submit workshop proposals to: Ephraim Glinert, Workshops Chair. Exhibits -------- ACM Multimedia'95 offers a unique opportunity for vendors and publishers to exhibit and demonstrate multimedia products. For more information, contact Don Collier, Exhibition Manager. ============= Authors of accepted submissions will be required to submit both a camera- ready copy of the manuscript for the printed proceedings and an electronic copy for the CD ROM proceedings. Authors must assign copyright to ACM as a condition of publishing their work in the proceedings. An author who embeds an object, such as an art image, copyrighted by a third party is expected to obtain that party's permission to include the object with the understanding that the entire work may be distributed as a unity to ACM members and others. Up-to-date information about ACM Multimedia'95, including a more detailed version of this call, can be found on the World Wide Web at http://acm.org/MM95/. IMPORTANT DATES --------------- Six copies of all submissions due: March 29, 1995. Notification of acceptance: June 30, 1995. Submissions in final form due: August 11, 1995. CONFERENCE COMMITTEE -------------------- General Chair: Treasurer: R.B. Allen, Bellcore M. Brown, DEC Electronic Information: Networking: H. Zhang, CMU G. Paxinos, Metro Link Electronic Publishing: Proceedings: R. Phillips, LANL S. Heller, GWU Publicity: European Liaison: R. Mehrotra, UM-St. Louis C. Thanos, Consiglio Nazionale delle Ricerche (Pisa) Steering Committee Co-Chairs: S. Bulick, US WEST A. Kuchinsky, Hewlett Packard PROGRAM CHAIR: PANELS CHAIR: Polle Zellweger Fillia Makedon Xerox PARC Dept. of Math and Computer Sci. 3333 Coyote Hill Road Dartmouth College Palo Alto, CA 94304 USA 6211 Sudikoff Laboratory, Room 109 mm95@parc.xerox.com Hanover, NH 03755-3510 USA Phone: +1-415-812-4426 makedon@kinsman.dartmouth.edu Phone: +1-603-646-3048 VIDEOS CHAIR: DEMONSTRATIONS CHAIR: Gil Cruz, R. Hill Tom Little MRE-2B280 Dept. of Elec. and Computer Engr. Bellcore Boston University 445 South Street 44 Cummington St. Morristown, NJ 07960 USA Boston, MA 02215 USA {gil,rdh}@bellcore.com tdcl@spiderman.bu.edu Phone: +1-201-829-5212 Phone: +1-617-353-9877 TUTORIALS CHAIR: WORKSHOPS CHAIR: Sorel Reisman Ephraim Glinert Dept. of Computer Science Dept. of Computer Science California State University R. P. I. Fullerton, CA 92634 USA Troy, NY 12180 USA sreisman@ccvax.fullerton.edu glinert@cs.rpi.edu Phone: +1-714-773-3325 Phone: +1-518-276-2657 EXHIBITS CHAIR: EXHIBITOR INFORMATION: Brent Hailpern Don Collier IBM T.J. Watson Res. Ctr. DC Expositions, Inc. 30 Sawmill River Roada 555 Republic Drive, Suite #316 Hawthorne, NY 10532 USA Plano, TX 75074 USA bth@watson.ibm.com dcexpo@aol.com Phone: +1-914-784-6821 Phone +1-214-423-4286 1995 ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA22983; Thu, 8 Dec 1994 01:10:47 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA22978; Thu, 8 Dec 1994 01:10:46 -0600 Received: from Sun.COM (Sun.COM [192.9.9.1]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id BAA29466 for ; Thu, 8 Dec 1994 01:10:44 -0600 Received: from Eng.Sun.COM (mxchange.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA11146; Wed, 7 Dec 94 23:10:43 PST Received: from jurassic.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh) id XAA05318; Wed, 7 Dec 1994 23:10:26 -0800 Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id XAA22892; Wed, 7 Dec 1994 23:10:34 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id XAA07516; Wed, 7 Dec 1994 23:10:29 -0800 Date: Wed, 7 Dec 1994 23:10:29 -0800 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <199412080710.XAA07516@bobo.Eng.Sun.COM> To: braden@ISI.EDU Subject: Re: Some Thoughts on TCPng Cc: end2end-interest@ISI.EDU, nsrg@cs.arizona.edu, tcplw@cray.com Mime-Version: 1.0 Content-Length: 836 > The P-hdr is used in TCP to ensure correct delivery. I fail to see > how any other HLP protocol could do that differently. I thought > Sean's idea was rather clever. Protocols like VMTP that include globally unique indentifiers for the source and destination endpoints (if I recall correctly they were called Entity Identifiers in VMTP) will be able to detect that a packets has been delivered to the wrong host without relying on the IP addresses not being modified in flight. Thus such protocols have no need to include the IP source and destination in the pseudo header checksum. Also, protocols that include their own length field have no need to include the packet length in the P-hdr checksum. However, the protocols I'm aware of either have the TCP/UDP P-hdr definition or do not have a pseudo-header at all. Erik Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA23673; Wed, 7 Dec 1994 20:30:43 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA23667; Wed, 7 Dec 1994 20:30:42 -0600 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id UAA10794 for ; Wed, 7 Dec 1994 20:30:40 -0600 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Wed, 7 Dec 1994 18:20:10 -0800 Date: Wed, 7 Dec 1994 18:20:10 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199412080220.AA12837@zephyr.isi.edu> To: sean@cs.arizona.edu, deering@parc.xerox.com Subject: Re: Some Thoughts on TCPng Cc: end2end-interest@ISI.EDU, nsrg@cs.arizona.edu, tcplw@cray.com Content-Length: 583 *> *> Sean, *> *> > I don't see how the higher level protocol would ever affect *> > the pseudo header. *> *> The pseudo-header is used by the higher-layer protocol to detect errors *> in those fields of the IP header upon which it depends for its correct *> operation. It is not necessarily the case that all higher-layer protocols *> depend on the same set of IP fields. *> Steve, The P-hdr is used in TCP to ensure correct delivery. I fail to see how any other HLP protocol could do that differently. I thought Sean's idea was rather clever. Bob Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA12732; Wed, 7 Dec 1994 17:25:19 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA12727; Wed, 7 Dec 1994 17:25:18 -0600 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id RAA26001 for ; Wed, 7 Dec 1994 17:25:17 -0600 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14780(4)>; Wed, 7 Dec 1994 15:14:25 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Wed, 7 Dec 1994 15:13:52 -0800 To: "Sean O'Malley" Cc: end2end-interest@isi.edu, nsrg@cs.arizona.edu, tcplw@cray.com, deering@parc.xerox.com Subject: Re: Some Thoughts on TCPng In-Reply-To: sean's message of Tue, 06 Dec 94 15:08:09 -0800. <199412062308.AA03378@avenir.cs.arizona.edu> Date: Wed, 7 Dec 1994 15:13:44 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Dec7.151352pst.12173@skylark.parc.xerox.com> Content-Length: 561 Sean, > I don't see how the higher level protocol would ever affect > the pseudo header. The pseudo-header is used by the higher-layer protocol to detect errors in those fields of the IP header upon which it depends for its correct operation. It is not necessarily the case that all higher-layer protocols depend on the same set of IP fields. By the way, your desire that the pseudo-header rules for TCP be specified in the IP spec has been satisfied, in IPv6 (as it was in SIP and SIPP before it) -- please see draft-hinden-ipng-ipv6-spec-00.txt. Steve Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA12789; Tue, 6 Dec 1994 17:09:30 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA12780; Tue, 6 Dec 1994 17:09:28 -0600 Received: from optima.CS.Arizona.EDU (optima.CS.Arizona.EDU [192.12.69.5]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id RAA10871 for ; Tue, 6 Dec 1994 17:09:26 -0600 Received: from avenir.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA03263; Tue, 6 Dec 1994 16:09:24 MST From: "Sean O'Malley" Message-Id: <199412062308.AA03378@avenir.cs.arizona.edu> Received: by avenir.cs.arizona.edu; Tue, 6 Dec 1994 16:08:10 MST Subject: Re: Some Thoughts on TCPng To: dab@berserkly.cray.com (David A. Borman) Date: Tue, 6 Dec 1994 16:08:09 -0700 (MST) Cc: sean@cs.arizona.edu, end2end-interest@isi.edu, nsrg@cs.arizona.edu, tcplw@cray.com In-Reply-To: <9412062256.AA10706@frenzy.cray.com> from "David A. Borman" at Dec 6, 94 04:56:55 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2189 > > Sean, > > > The TCP spec currently references the IPv4 address > > so any change to pseudo header will require a modification to the > > TCP spec. My argument is that the world would be a better place if > > the definition of the pseudo header was left up to the lower level > > protocol. I included the implementation detail to show what would > > be entailed by this change. Also since I do not know the BSD source that > > well I have know idea how hard this approach would be to support in > > the BSD TCP implementation. > > Sure, moving the definition of the pseudo-header to the IP document > would mean that the TCP spec wouldn't have to be modified every > time the IP layer is changed, but that then means that the IP > document has to be modifed every time a new transport is added > above IP that uses a pseudo-header. Even if it is the same > as other protocols, (UDP and TCP have the same pseudo-header), > it still would have to be iterated. I don't see much advantage > in terms of having to modify specs to argue one way or the other. Ah I see where we differ. Since the contents of the pseudo header are purely a function of the IP header and semantics I think you could define it once and never do it again. I don't see how the higher level protocol would ever affect the pseudo header. Higher level protocol would have to know if it wanted to include pseudo header information in its checksum but it would never have to know what that pseudo header looks like. If the interface to all protocols that provide pseudo headers is the same you would not even need to change the code. You think we would have to revisit it every time we add a new higher level protocol. Why do you believe this is true? The fact that you think this is possible: > If the pseudo-header is to be considered part of the IP layer, > then I would argue that what you really want to do is to eliminate > the pseudo-header from the TCP (and UDP) checksum, and add an > end-to-end IP option that contains a checksum over the fields > in the IP header that should not change from end-to-end. argues to me that the higher level protocols need not be involved. Sean Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11142; Tue, 6 Dec 1994 16:53:41 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11128; Tue, 6 Dec 1994 16:53:39 -0600 Received: from frenzy.cray.com (frenzy-eth.cray.com [128.162.96.91]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id QAA09552 for ; Tue, 6 Dec 1994 16:53:38 -0600 Received: by frenzy.cray.com id AA10706; 4.1/CRI-5.6; Tue, 6 Dec 94 16:56:55 CST Date: Tue, 6 Dec 94 16:56:55 CST From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9412062256.AA10706@frenzy.cray.com> To: sean@cs.arizona.edu Subject: Re: Some Thoughts on TCPng Cc: end2end-interest@isi.edu, nsrg@cs.arizona.edu, tcplw@cray.com Content-Length: 2541 Sean, > The TCP spec currently references the IPv4 address > so any change to pseudo header will require a modification to the > TCP spec. My argument is that the world would be a better place if > the definition of the pseudo header was left up to the lower level > protocol. I included the implementation detail to show what would > be entailed by this change. Also since I do not know the BSD source that > well I have know idea how hard this approach would be to support in > the BSD TCP implementation. Sure, moving the definition of the pseudo-header to the IP document would mean that the TCP spec wouldn't have to be modified every time the IP layer is changed, but that then means that the IP document has to be modifed every time a new transport is added above IP that uses a pseudo-header. Even if it is the same as other protocols, (UDP and TCP have the same pseudo-header), it still would have to be iterated. I don't see much advantage in terms of having to modify specs to argue one way or the other. If it is a question of modifying documents, then perhaps there should be a TCP spec that doesn't specify a pseudo header, and then there are individual documents that specify the TCP pseudo header for each of the underlying protocols that TCP can be layered on. Then the TCP spec doesn't have to be modified each time someone wants to run it on top of a new network layer. But whether the actual text is in the same document as the TCP specification or in a separate document, it is still part of the Transport layer; it is not part of the layer below it. If the pseudo-header is to be considered part of the IP layer, then I would argue that what you really want to do is to eliminate the pseudo-header from the TCP (and UDP) checksum, and add an end-to-end IP option that contains a checksum over the fields in the IP header that should not change from end-to-end. (The same fields in the current TCP and UPD pseudo-headers.) If an IP packet arrived with the end-to-end checksum option and the checksum was wrong, the then IP layer would toss the packet without ever handing it up to the next layer. On output TCP (and UDP) would instruct the IP layer to insert the pseudo-header checksum option. You might also want the receiving TCP to be able to toss any packets that it receives that did not contain the end-to-end pseudo-header checksum. But I think that that is more than what needs to be done. I'd say we just need to define a new TCP pseudo-header for IPv6/TCP. -David Borman, dab@cray.com Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA00851; Tue, 6 Dec 1994 15:27:16 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA00845; Tue, 6 Dec 1994 15:27:14 -0600 Received: from optima.CS.Arizona.EDU (optima.CS.Arizona.EDU [192.12.69.5]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id PAA00317 for ; Tue, 6 Dec 1994 15:27:12 -0600 Received: from avenir.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP id AA25747; Tue, 6 Dec 1994 14:27:11 MST From: "Sean O'Malley" Message-Id: <199412062126.AA03160@avenir.cs.arizona.edu> Received: by avenir.cs.arizona.edu; Tue, 6 Dec 1994 14:26:02 MST Subject: Re: Some Thoughts on TCPng To: dab@berserkly.cray.com (David A. Borman) Date: Tue, 6 Dec 1994 14:26:02 -0700 (MST) Cc: end2end-interest@ISI.EDU, nsrg@cs.arizona.edu, sean@cs.arizona.edu, tcplw@cray.com In-Reply-To: <9412061911.AA10559@frenzy.cray.com> from "David A. Borman" at Dec 6, 94 01:11:38 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3107 > > The TCP pseudo-header > > In Sean's message below, I don't entirely agree with his > reasoning. There seems to be a bit of mixing of the definition > of the TPC pseudo-header and the implementation of that > definition. The discussion in the IETF should be on the > definition, not on the implementation. Of course, you would > be foolish to not consider the implementation ramifications > of a particular definition of the pseudo-header, but the > definition should just state what fields of the IPv6 header > are included in the TCP pseudo-header for IPv6/TCP. Whether > the implementation does the pseudo-header checksum at the > IPv6 layer and passed up that checksum to TCP, or whether > it lets the TCP layer do the checksum of the pseudo-header > is just an implementation detail, not an issue of what the > TCP pseudo-header should look like. The effect upon the definition of TCP would be to move the follow paragraph from the TCP spec to the IP spec. (retroactively in the case if IPv4). The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP on the IP. +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | zero | PTCL | TCP Length | +--------+--------+--------+--------+ and provide the following modification: Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. The checksum also covers a pseudo header defined by the protocol configured below tcp. You would also need to add some information to the lower level interface section of the TCP document. The TCP spec currently references the IPv4 address so any change to pseudo header will require a modification to the TCP spec. My argument is that the world would be a better place if the definition of the pseudo header was left up to the lower level protocol. I included the implementation detail to show what would be entailed by this change. Also since I do not know the BSD source that well I have know idea how hard this approach would be to support in the BSD TCP implementation. Sean O'Malley Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA20865; Tue, 6 Dec 1994 14:24:39 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA20854; Tue, 6 Dec 1994 14:24:37 -0600 Received: from lotus.com (lotus.com [192.233.136.1]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id OAA22624 for ; Tue, 6 Dec 1994 14:24:35 -0600 Received: from internet1.lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.10801.1994) id AA12851; Tue, 6 Dec 94 15:25:36 EST Received: by internet1.lotus.com (4.1/SMI-4.1.8.5.94) id AA02027; Tue, 6 Dec 94 15:24:44 EST Message-Id: <9412062024.AA02027@internet1.lotus.com> Received: from Lotus with "Lotus Notes Mail Gateway for SMTP" id 2C6473667A5CF1058525611D006F9D1B; Tue, 6 Dec 94 15:24:42 To: "David A. Borman" Cc: end2end-interest , nsrg , sean , tcplw From: Robert Ullmann Date: 6 Dec 94 15:19:29 ES Subject: Re: Some Thoughts on TCPng Mime-Version: 1.0 Content-Type: Text/Plain Content-Length: 24 You might read RFC1475. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08402; Tue, 6 Dec 1994 13:08:22 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA08391; Tue, 6 Dec 1994 13:08:20 -0600 Received: from frenzy.cray.com (frenzy-eth.cray.com [128.162.96.91]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id NAA13296 for ; Tue, 6 Dec 1994 13:08:19 -0600 Received: by frenzy.cray.com id AA10559; 4.1/CRI-5.6; Tue, 6 Dec 94 13:11:38 CST Date: Tue, 6 Dec 94 13:11:38 CST From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9412061911.AA10559@frenzy.cray.com> To: end2end-interest@ISI.EDU, nsrg@cs.arizona.edu, sean@cs.arizona.edu, tcplw@cray.com Subject: Re: Some Thoughts on TCPng Content-Length: 16632 I'm including the tcplw@cray.com mailing list in this reply, so for those on the tcplw mailing list I've included Sean's message below. There are a couple of points I'd like to make about TCPng. First, there are two seperate issues that I'd like to emphasize, and I hope that the discussion at the BOF will reflect this. 1) Changes need to be made to the TCP pseudo-header to allow TCP to run over IPv6. 2) *Any* changes to the TCP header means it is a new version of the TCP header, and it needs a new protocol number. It doesn't matter whether you are talking about TCP/IPv4 or TCP/IPv6. >From an implementation standpoint, if TCP is going to change, there are those who argue that since we are going to be upgrading to IPv6 anyway, that is a good time to change TCP. I understand this argument, but I can't overstate it enough that this is strictly an *implementation* detail. If the TCP header over IPv6 is not the same TCP header over IPv4, then it really is a new version of TCP that requires a new IP protocol number. If we do a new rev of TCP, then there are four combinations: IPv4/TCP, IPv4/TCPng, IPv6/TCP and IPv6/TCPng. Perhaps people don't want to have to support all 4 combinations, and that is fine. But there are 4 combinations, and discussion should keep this in mind so that we don't confuse a transition from IPv4 to IPv6 with a transition from TCP to TCPng (assuming that there is going to be a TCPng). The TCP pseudo-header In Sean's message below, I don't entirely agree with his reasoning. There seems to be a bit of mixing of the definition of the TPC pseudo-header and the implementation of that definition. The discussion in the IETF should be on the definition, not on the implementation. Of course, you would be foolish to not consider the implementation ramifications of a particular definition of the pseudo-header, but the definition should just state what fields of the IPv6 header are included in the TCP pseudo-header for IPv6/TCP. Whether the implementation does the pseudo-header checksum at the IPv6 layer and passed up that checksum to TCP, or whether it lets the TCP layer do the checksum of the pseudo-header is just an implementation detail, not an issue of what the TCP pseudo-header should look like. TCPng I don't take lightly discussing changing the TCP header, which requires a new protocol number for TCPng. But there are some issues with the current TCP that cannot be resolved cleanly without doing a new rev of TCP. Here's my list: 1) Size of port numbers The main arguement that I have seen for changing the size of the port numbers is for transactional processing. Bob's current draft of T/TCP does not require larger port numbers. So, I don't have any reason to increase them. 2) 32 bit vs 16 bit window field The negotiation of the tcp window shift option is required to happen during the exchange of the SYNs. Once this happens, it cannot be changed for that connection. Whether an implementation initializes this based on the buffer size that the user is using or an explicit command from the user, it has to be set up before the connection is established, and gotten correct. In the typical BSD implementation, it is /etc/inetd that establishes inbound connections, and for rcp /etc/inetd just runs /etc/rshd, which then runs /bin/rcp, which is finally where the knowledge is about the size of buffers that will be used. But by the time you get there, the window shift is already fixed. Expanding the window field to 32 bits eliminates the need to determine the window shift value before the connection is established. 3) TCP option space. The main reason that selective ACKs have not been finalized is arguments over how the bits should be layed out in the option to maximize the number of sacks that can be encoded in the limited option space. Expanding the TCP offset field would eliminate that issue. Along with 64 bit alignment, this field should be changed to be in terms of 64 bit words, instead of 32 bit words. 4) 32 bit vs 64 Sequence space, and Timestamps. These are two issues that need to be thought about at the same time. In the current TCP extensions, the Timestamps are used by the PAWS mechanism to keep sequence wraparound from missing the detection of old packets. An alternative way to do this is to expand the sequence space to 64 bits. Both will work. However, the Timestamps are very useful for allowing much better RTT estimations, and allows one to eliminate the need for the Karn algorithm when doing RTT measurements. When using Timestamps for RTT estimation, the worst case scenario is equal to the best case scenario in the typical BSD implementation using the Karn algorithm. In the worst case scenario for the typical BSD/Karn implementation, you never get a valid RTT measurement. If one is going to change TCP, then I would argue very strongly that the Timestamps should be made part of the fixed TCP header. Because of the PAWS mechanism, also expanding the sequence space to 64 bits would be redundant. 5) Urgent pointer The TCP urgent pointer is not used very often, and it takes up space in the fixed TCP header. It would be trivial to remove it (and the URG bit) from the fixed header, and replace it with a TCP Urgent option. 6) 64 bit alignment If TCP is changing, then the header should be made to be 64 bit aligned, just as IPv6 is 64 bit aligned. If you add the Timestamp options, remove the Urgent pointer and expand the Window to 32 bits, you wind up with a header that is not aligned on a 64 bit boundry. Making it 64 bit aligned introduces a "unused" 32 bit field. There are several things that could be done: 1) If the port numbers are expanded to 32 bits, then that would eat up the extra 32 bits. 2) Leave the urgent pointer in the fixed header, as a 32 bit field, and put back the URG bit. 3) Allow options to begin in the Unused field, which would require either: 1) Add an OPT flag to indicate that there are TCP options. 2) Allow the Data Offset to point into the fixed header, which would require: 1) The offset is in terms of 32 bits words. 2) The offset must be even, except that it could be 7, in which case there are no options, and the real data offset is Option 3.2 is really ugly, and I don't like it. Option 3.1 has the nicety that when doing TCP header prediction, you can check for the existance of options along with the checks for the other bits, without having to do a seperate check of the data offset field. Option 2 allows TCP header compression to compress out the urgent pointer. Option 1 is only ok if there is a good reason to expand the size of the port numbers. My order of preference would probably be #2, then #1, then 3.1 Using option 2, leaving in the urgent pointer, yields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Window | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + Sequence Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Acknowledgment Number + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp Reply | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Data | |U|A|P|R|S|F| | | Offset |MBZ|R|C|S|S|Y|I| Checksum | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Urgent Pointer | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | +-+-+-+-+-+-+-+-+ Options +-+-+-+-+-+-+-+-+ | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : : : data : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So, this new proposed version addresses: 1) 64 bit alignment 2) Additional TCP option space 3) Full 32 bit window at all times. 4) Manditory inclusion of Timestamps. Note that this is not the same as what I mailed out in my NTCP proposal a while back. I was under the impression that the TCPng BOF was going to be scheduled to be multicast, but I just checked the multicast guide and it is not listed. So, since I'm not in San Jose, you'll have to have the discussion without me. -David Borman, dab@cray.com P.S: In regards to Sean's last question about IPv4/TCP and IPv6/TCP interoperability: Yes, an IPv4/TCP and an IPv6/TCP can interoperate iff the TCP pseudo-header is chosen properly. The IPv4 host will only be using IPv4 addresses, which get mapped into an IPv6 address format that was specifically chosen so that the checksum value of the 32 IPv4 address and the checksum of the 128 bit IPv6 address that it is mapped to are identical. To make this work then requires that the IPv6/TCP pseudo-header will have to be exactly the source and destination IPv6 address, the TCP protocol number, and the TCP length. > From sean@cs.arizona.edu Sat Dec 3 05:12 CST 1994 > Date: Fri, 2 Dec 1994 11:04:24 MST > From: "Sean O'Malley" > To: end2end-interest@ISI.EDU, nsrg@cs.arizona.edu > Subject: Some Thoughts on TCPng > Content-Length: 5946 > > > I thought I would get the ball rolling for next weeks > TCPng BOF at IETF. After thinking about it for > a couple of days I could not come up with any convincing > reason to change TCP. There are three basic reasons people > are proposing TCPng. > > 1. IPng Pseudo-Header > 2. Clean up the TCPLW option + header > 3. Add features like transactional TCP and multi-cast TCP > > Problem 1: IPng increases the size of the IP address. Hence > putting the current TCP on top of IP creates problems because > TCP expects a pseudo header with old IP style addresses. > > Problem 0.9: Unfortunately the pseudo header is not the only > problem. The BSD TCP code knows what the IP address looks > like and the code is riddled with variables declared to be > type IPhost. > > Solution: > > The TCP source does not really need to know what the > IP address looks like. Most of the uses of the IP host are > for debugging purposes. The key use of a variable of type > IPhost in our implementation is when constructing a demultiplexing > key. The TCP source uses the source field of the IP pseudo > header combined with the source and destination port fields > of the TCP header to demultiplex incoming packets. However > this is actually an artifact caused by the fact that our > TCP implementation is BSD based. In standard x-kernel protocol > implementations the lower level session pointer would be > combined with the local ports to demux incoming packets. > > Obviously when a user opens a TCP connection he is going > to pass in address information which contains IP addresses. > The x-kernel participant structure resolves this problem by > supporting a cheap form of type polymorphism which allows > TCP to pop of its ports without knowing what the remainder > of the address consists of. > > Problem 1.0: Ok at this point the only remaining reference > to a variable of type IPhost in TCP is in the pseudo header. > > Solution: > > Eliminate the need for TCP to see the IP pseudo > header. IPng should support an operation which takes a > a session identifier and a message length and returns the > Internet checksum of the IP pseudo header for a message of that > length. Thus TCP gets to checksum the pseudo header without > ever seeing it. > > Discussion: > > At this point we have an implementation of the standard > TCP protocol which can run on top of IP or IPng as > long as the implementations of the new IPng and the > old IP are changed to support polymorphic address > types, session identifiers, and the checksum operation. > Furthermore TCP is now immune to any further changes > to IP. In fact in the x-kernel such an implementation > would be able to run just about anywhere including > directly on top of a network driver. > > The problem here of course is that this is not a small delta > off of the existing BSD code and is basically an x-kernel > oriented solution. However the only alternate I can think > of is to modify the BSD code to handle both IP and IPng > host address types. I do not believe that this would be > a small delta either. > > Thus it appears to be possible to solve the problem > of the IP pseudo header with changes to the way TCP > is implemented rather than the way it is specified. > In fact it I find hard to imagine that any fix to > the IP pseudo header problem would require a change > to the TCP header. It is purely an implementation > issue and to the extent it is called out in the > TCP spec it is an example of over specification. > TCP should specify that the TCP checksum is to be > computed over the important fields of the lower > level protocols header and leave it up to the lower > level protocol to determine what those fields are and > leave it up to the implementor as to how this is implemented. > > Problem 2: The rather ugly header format required to by the > large window extensions to TCP. > > Solution: > > Who cares? I fought tooth and nail against this format > in the TCPLW group. However given that it is a standard I don't > think it makes any sense to change it. Given the power of modern > processors there is no way processing the TCPLW format is going > to result in a significant performance hit. > > Axiom: If you are going to change a protocol use a rational > header structure, the lack of a rational header structure > is no reason (in and of itself) to change a protocol. > > Problem 3: People want to add functionality to TCP. > > Solution: > > This is why god invented IP protocol numbers. If you want > new functionality write a new protocol. I would argue > against people saving an IP protocol number by adding a > TCP option. > > I believe that the only valid reason to add functionality > to a protocol rather than creating a new protocol is if > the added functionality will result in increased performance for > current users of the protocol. For example, many current TCP applications > use TCP as a reliable request response protocol. Thus something > like transactional TCP might make sense because existing > TCP users will benefit from it. On the other hand no one > currently uses TCP for multi-cast. Thus I believe reliable > multicast is best left to a new protocol. > > This leaves only two semi-legitimate reasons to change > TCP: > > 1. TCPLW is incomplete and requires selective ACKS > which will not fit nicely into the TCP option filed. > > The need for selective ACKS is debatable. > If they are needed they might fit in the option > field. > > 2. TCPLW burns up a significant part of the TCP option > field making it more difficult to make further modifications > to TCP. > > Since I think the primary use of the TCP option > field would be to add functionality to TCP > which really belongs in a new protocol I am not > sure this lack of room is all for the bad. > > > Perhaps TCP should remain as is. > > Sean O'Malley > > ps: > > Does IPng support communication between endpoints where > one end is running IP and one is running IPng without the > IPng endpoint knowing that the other endpoint is running IP? > If so I don't see any good way of supporting an IPng pseudo > header. > Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA07829; Fri, 18 Nov 1994 03:10:52 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA07812; Fri, 18 Nov 1994 03:10:50 -0600 Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id DAA11603 for ; Fri, 18 Nov 1994 03:10:47 -0600 Received: from utis156.cs.utwente.nl by utrhcs.cs.utwente.nl (5.0/csrelayMX-SVR4_1.0/RB) id AA22823; Fri, 18 Nov 1994 10:09:51 --100 Received: by utis156.cs.utwente.nl (4.1/RBCS-1.0.1) id AA10443; Fri, 18 Nov 94 10:09:42 +0100 To: tcplw@cray.com Cc: braden@ISI.EDU, abbondi@hotlan.att.com, smb@research.att.com Subject: Re: rfc1323 In-Reply-To: Your message of Thu, 17 Nov 1994 14:50:03 PST Date: Fri, 18 Nov 1994 10:09:41 +0100 Message-Id: <10442.785149781@utis156.cs.utwente.nl> From: Andras Olah Content-Length: 1044 > From: abbondi@hotlan.att.com (Andre B Bondi +1 908 949 1921) > Date: 15 Nov 94 15:15:00 GMT > To: braden@ISI.EDU > Cc: abbondi@hotlan.att.com, smb@research.att.com > Subject: rfc1323 > > > Greetings! > At Steve Bellovin's suggestion, I am writing to enquire whether > you might know of an implementation of rfc1323 (big windows in TCP) > that is readily available, and with a bit of luck, tried and tested. > > Thanks in advance! The extensions proposed in RFC-1323 are included in the 4.4BSD-Lite distribution. Note also that 4.4BSD-Lite is the basis of two freely distributable OS's: FreeBSD-2.0 and NetBSD-1.0. FreeBSD is limited to i386-based PCs, NetBSD runs on a variety of platforms. 4.4BSD-Lite is available from Berkeley and it's also published by O'Reilly on CD-ROM. Send mail to info@freebsd.org (and probably info@netbsd.org works as well, I'm not sure) to learn how to get FreeBSD (CD-ROM, ftp-sites, mailing-lists, etc). > > Andre B. Bondi, Dept. 1J0K15000, HO 2J414, AT&T Bell Labs, Tel. 908-949-1921 > Andras Olah Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA17451; Thu, 17 Nov 1994 16:48:08 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA17433; Thu, 17 Nov 1994 16:48:02 -0600 Received: from venera.isi.edu (venera.isi.edu [128.9.0.32]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id QAA23026 for ; Thu, 17 Nov 1994 16:47:53 -0600 From: braden@ISI.EDU Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Thu, 17 Nov 1994 14:47:29 -0800 Date: Thu, 17 Nov 1994 14:50:03 -0800 Posted-Date: Thu, 17 Nov 1994 14:50:03 -0800 Message-Id: <199411172250.AA20599@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id ; Thu, 17 Nov 1994 14:50:03 -0800 To: tcplw@cray.com Subject: rfc1323 Cc: braden@ISI.EDU, abbondi@hotlan.att.com, smb@research.att.com Content-Length: 801 ----- Begin Included Message ----- >From abbondi@hotlan.att.com Tue Nov 15 09:44:00 1994 From: abbondi@hotlan.att.com (Andre B Bondi +1 908 949 1921) Date: 15 Nov 94 15:15:00 GMT To: braden@ISI.EDU Cc: abbondi@hotlan.att.com, smb@research.att.com Original-From: hotlan!abbondi (Andre B Bondi +1 908 949 1921) Original-To: att!isi.edu!braden Original-Cc: hotlan!abbondi, research!smb Subject: rfc1323 Content-Type: text Content-Length: 312 X-Lines: 10 Greetings! At Steve Bellovin's suggestion, I am writing to enquire whether you might know of an implementation of rfc1323 (big windows in TCP) that is readily available, and with a bit of luck, tried and tested. Thanks in advance! Andre B. Bondi, Dept. 1J0K15000, HO 2J414, AT&T Bell Labs, Tel. 908-949-1921 ----- End Included Message ----- Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03417; Wed, 9 Nov 1994 15:32:59 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03401; Wed, 9 Nov 1994 15:32:57 -0600 Received: from rab.ieee.org (rab.ieee.org [140.98.2.3]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id PAA27831 for ; Wed, 9 Nov 1994 15:32:29 -0600 Received: from tab.ieee.org by rab.ieee.org (4.1/R-3.71-09.10.94) id AA27981; Wed, 9 Nov 94 15:43:10 EST Received: from [140.98.14.105] (mac05.comm.ieee.org) by tab.ieee.org (4.1/I-3.20) id AA08210; Wed, 9 Nov 94 15:43:01 EST Date: Wed, 9 Nov 94 15:42:57 EST Message-Id: <9411092043.AA08210@tab.ieee.org> To: tcplw@cray.com From: j.keller@ieee.org (Judy Keller) X-Sender: jkeller@140.98.2.2 Subject: Broadband'95 Workshop Content-Length: 9213 November 1994 Dear Colleague: On behalf of Technical Program Co-Chairs Howard Lemberg and Mario Vecchi and the entire Technical Program Committee, we are pleased to invite you - and/or others in your organization - to three days of informal, interactive workshops at Loews Ventana Canyon Resort in Tucson, Arizona. Your participation in Broadband '95, a workshop devoted to "Multimedia Applications and Network Architectures," will benefit you, your company, and your industry. The workshop will be restricted to about 125 attendees to facilitate a free and open exchange of ideas. >From the enclosed Advance Program you can see that we have assembled a group of speakers who are at the forefront of the work in this field. Our objective is to expose the issues, problems, and proposed solutions that will accelerate the emergence of broadband multimedia applications. In addition to exploring the means for creating the content of these applications, it is our aim to examine the supporting systems and networks. We will get into the specifics of network access and control and the "nitty gritty" of the access environment. Early commercial systems as well as past, present and future trials will be covered. If you have any particular subjects that you would like to see us include there is still time for us to consider them. Your suggestions can be sent along with your registration or bring your "hot" ideas and questions with you. Since the capacity of the workshop is limited, we urge you to send the registration form in as soon as possible. You will receive notification of our ability to accomodate you shortly after receipt of your registration. If you have questions please address them to: Judy Keller at: IEEE Communications Society, 345 East 47th Street, New York, NY 10017-2394 Telephone: +1 212 705 8248 Fax: +1 212 705 7865 Email: j.keller@ieee.org Or to Bob Aaron at: telephone: +1 407 687 2345 fax: +1 407 687 8739 email: b.aaron@ieee.org We look forward to seeing you in Tucson! Bob Aaron and Jack Terry General Co-Chairs, Broadband '95 Workshop BROADBAND '95 WORKSHOP Multimedia Applications and Network Architectures Date: January 8-11, 1995 Site: Loews Ventana Canyon Resort, Tucson, Arizona Sponsored by: IEEE Communications Society Theme: Emerging Broadband Applications, Systems, and Networks Keynote Reception: 5pm - Sunday - January 8, 1995 Keynote Speaker: Bob Lucky, Bellcore Reception Hosted by: Motorola Semiconductor Products Pack your bags with provocative questions and join us at this informal, interactive workshop! Seating is limited, so register now! BROADBAND '95 WORKSHOP Technical Sessions* 1 Architecture and Control, Monday, morning, Jan. 9; Session Chair: Mario Vecchi Focuses on network architectures and control with emphasis on software issues relating to the delivery of highly interactive multimedia information. Speakers include: Sheldon Borkin, Silicon Graphics Inc.; Gita Gopal, Bellcore; Andy Laursen, Oracle Corp.; Ed Szurkowski, AT&T Bell Labs; Jay Vaughn, Time Warner 2. Multimedia and Video Access, Monday , afternoon; Jan. 9; Session Chair: Howard Lemberg Addresses wireless and guided media access to multimedia services from a technical and economic viewpoint. Speakers include: Ralph Ballart, Telesis Technology Labs; Bill Pugh, AT&T Bell Labs; Tom Jurus, NYNEX; Rick Jones, BBT; Jim Mollenauer, Technology Strategy Associates 3. Content/Applications, Tuesday, morning, Jan. 10; Session Chair: Steve Weinstein Examines methods for creating the content of multimedia messages and for realizing applications. Speakers include: Steve Dukes, 3DO; Keith Rowe, Microsoft; Richard Weinberg, USC Computer Animation Lab.; Yuet Lee, Pacific Bell; And others to be announced 4. Customer Networks/ Consumer Electronics Compatibility; Tuesday, afternoon, Jan. 10; Session Chair: Jack Terry Addresses how the transport of interactive, wideband signals to, from and within the customers' premises present challenges in quantifying the environment and choosing protocols to match it. Speakers include: Joseph Glaab, General Instrument; Carl Anderson, BNR; Claude Baggett, CableLabs; Brian Bauer, Raychem Corp.; Keku Mistry, Bellcore 5. Trials/Early Commercial Installations, Wed., morning, Jan. 11; Session Chair: Gottfried Luderer Reviews how trials and early services provide the feedback essential to the honing of system designs and service delivery. Covers some aspects of what has been learned and what expectations are for future trials. Speakers include: Jack Warner, AT&T Bell Labs; Peter Heldman, U S WEST; Juergen Kanzow, KETEKON (Germany); Chuck Caroll, TeleWest (UK); Mike Kincaid, MSK Consulting; And others to be announced *Technical Sessions Scheduled as of October 20, 1994 BROADBAND '95 WORKSHOP Registration Information -- All registrations must be received by December 7 in order to guarantee this discounted room rate and room availability. Registrations received after that date may be charged for added room costs. -- All registrations received by December 7 will also qualify for the Early Registration discount. -- Any cancellations received after December 7 will be liable for the full conference fee. -- You must receive written confirmation in order to be registered. If you have any questions about your confirmation, contact Hilda James at: Telephone: +1 305 666 5115 / Fax: +1 305 666 7134 / Email: h.james@conference.com -- To reserve a sleeping room at the conference rate for Saturday, January 7 or Wednesday, January 11, indicate so on the "Scheduled Arrival Date" and/or "Scheduled Departure Date" section below. You are responsible for payment to the hotel for these nights. =============================================================== BROADBAND '95 WORKSHOP Registration Form Workshop Fees Include Workshop Registration, the reception, lodging for three nights (January 8, 9, and 10), and eight meals - from dinner on January 8, through breakfast on January 11, 1995. Limited accommodations available! IEEE Member Early Registration (prior to November 15, 1994): $945 Non-Member Early Registration (prior to November 15, 1994):$995 IEEE Member Late Registration (after November 15, 1994): $995 Non-Member Late Registration (after November 15, 1994): $1,045 Guest/Spouse Registration*: $145 *Guest/Spouse Registration fee is the same for IEEE members and non-members but is valid only in conjuction with a full paid registration. Guest/Spouse Registration includes the reception, lodging for three nights, (January 8, 9, and 10) in a half twin double room shared with a full registrant, and six meals - from dinner on January 8, through breakfast on January 11, excluding luncheons. BROADBAND '95 WORKSHOP Payment Options (Send this completed form to Hilda James at address below.) _______ Enclosed check or money order made out to IEEE. (U.S. funds, drawn on a U.S. bank.) Check number #________ ____VISA ____MasterCard ____AmEx Card Number: ________________________________ Exp. Date (Mo./Yr.): ______________ Signature: ________________________________ Date: _________________________ Scheduled Arrival Date (for Resort reservations information) _______________________ Scheduled Departure Date _______________________ First Name________________________________ Last Name________________________________ (Name for badge, if different)________________________________ IEEE member number________________________________ Phone Number________________________________ Fax Number________________________________ Email Address________________________________ Job Title________________________________ Company/Organization________________________________ Street Address, Mail Stop/Room Number________________________________ City, State/Province, Postal Code, Country________________________________ Guest Name ________________________________________ Send Your Completed Registration Form and Payment to: Hilda James Broadband '95 c/o ICM 7152 SW 47th Street Miami, FL 33155 (U.S.A) Telephone: +1 305 666 5115 For Charge (Credit Card) Orders Only: Fax: +1 305 666 7134 Email: h.james@conference.com NOTE: If you fax or email your charge order please do NOT mail it also. ======================================================= BROADBAND '95 WORKSHOP Objectives: Advance discussion of key broadband and multimedia issues, highlight technical and business opportunities, and lay groundwork for consensus where appropriate. Provide a forum for presentation of latest advances in broadband fiber, wireless, and coax access systems and applications. Identify principal challenges or roadblocks to successful applications of broadband and multimedia technologies. Clarify access network/premises network relationships, matches and mismatches. Project evolution of access network and services, including extent of integration or nonintegration of networks, services, CPE. General Co-Chairs: Bob Aaron, Consultant; Jack Terry, BNR Technical Program Co-Chairs: Howard Lemberg, Bellcore; Mario Vecchi, Time-Warner Technical Program Committee: Dominique Chapelain, CNET; Mike Kincaid, MSK Consulting, Gottfried Luderer, Arizona State University; Curtis Siller, AT&T Bell Labs; Steve Weinstein, NEC USA, Inc. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05960; Tue, 8 Nov 1994 15:33:40 -0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05952; Tue, 8 Nov 1994 15:33:39 -0600 Received: from cards.cis.ohio-state.edu (cards.cis.ohio-state.edu [164.107.53.18]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id PAA00676 for ; Tue, 8 Nov 1994 15:33:37 -0600 Date: Mon, 7 Nov 1994 03:45:23 -0500 Message-Id: <94110703452309@cards.cis.ohio-state.edu> From: jain@cards.cis.ohio-state.edu (Raj Jain, The Ohio State University) To: tcplw@cray.com Subject: Address change [sent to @colleagues] X-Vms-To: SMTP%"tcplw@cray.com" Content-Length: 762 Dear Colleagues, Our department recently moved to a new building. The new address is: Professor Raj Jain Dept of Computer and Information Science Phone: 614-292-3989 The Ohio State University Fax: 614-292-2911 2015 Neil Ave, 497 Dreese Lab Email: Jain@cis.ohio-state.edu Columbus, OH 43210-1277 Life-Time Email: Jain@ACM.Org You probably know that I moved from Digital Equipment Corporation to OSU last April. Also, wanted to let you know about my new book: Raj Jain, "FDDI Handbook: High Speed Networking Using Fiber and Other Media" Addison Wesley Publishing Company, Reading, MA 01867, Phone: 800-822-6339 or 617-944-3700, Fax: 800-333-3328 or 617-944-7273, Email: MaureenC@aw.com, ISBN: 0-201-56376-2, $49.95, 528 pages, 1994. Thanks. -Raj Jain Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA25174; Thu, 29 Sep 1994 13:12:48 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA25168; Thu, 29 Sep 1994 13:12:46 -0500 Received: from hubcap.clemson.edu (hubcap.clemson.edu [130.127.8.1]) by timbuk.cray.com (8.6.9/8.6.9L) with ESMTP id NAA23951 for ; Thu, 29 Sep 1994 13:12:44 -0500 Received: from quickmail.clemson.edu (quickmail.clemson.edu [130.127.8.57]) by hubcap.clemson.edu (8.6.7/8.6.4) with SMTP id OAA28496; Thu, 29 Sep 1994 14:10:55 -0400 Message-Id: Date: 29 Sep 1994 08:33:51 -0500 From: "John Spragins" Subject: Gigabit networking conferen To: "Email Groups14" , "Email Groups15" , "Email Groups16" , "Email Groups17" , "Email Groups18" X-Mailer: Mail*Link SMTP/QM 3.0.0 Content-Length: 4945 Subject: Time:10:15 AM OFFICE MEMO Gigabit networking conference Date:9/28/94 "Gigabit Networks: Key to the Information Superhighway" Center for Computer Communication Systems 5th Annual Conference Clemson House Ballroom, Clemson University November 10-11, 1994 PROGRAM PERSONALITIES: *Dr. Craig Partridge, BBN *Dr. Raj Jain, Ohio State University Dr. David Feldmeier, Bellcore Dr. Michael Hluchyj, Summa Four, Inc. Dr. John Limb, Georgia Tech Dr. Gerald Marin, IBM Dr. Nick Maxemchuk, Bell Laboratories Mr. Alan Pierce, GTE Mr. Dan Stevenson, Microelectronics Center of NC Mr. Bill Smith, BellSouth Telecom Mr. Steven Willis, Wellfleet Communications * Keynote speakers FEE: $215.00 (Includes meals) REGISTRATION: Please send this form and a $215.00 check payable to "Clemson University" to: Ms. Wendy Winn Center for Computer Communication Systems 105 Riggs Hall Clemson, SC 29634 Phone: (803) 656-0848 Fax: (803) 656-5910 Email: wwendy@eng.clemson.edu Name: Affiliation: Address: Phone: E-mail Address: AGENDA: November 10 8:00 A Continental Breakfast 8:30 Keynote Talk "Local Computer Networks at Gigabit and Terabit Bandwidths" Dr. Craig Partridge, Bolt Beranek and Newman Inc. 9:00 Break 9:40 Introduction To Conference/Advisory Board Dr. John Spragins, Director, CCCS and Ms. Wendy Winn, Program Developer, CCCS, Clemson University 10:00 Featured Talk "Broadband Communications to the Home and Community" Dr. John Limb, Professor, College of Computing, Georgia Tech 10:45 Featured Talk "Electronic Distribution of Newspapers and Magazines" Dr. Nick Maxemchuck, Department Head, AT&T Bell Laboratories. 11:30 CCCS Faculty Talk "The Information Superhighway-Expectations for Agricultural Risk Management" Dr. Dale Linvill, Agricultural & Biological Engineering, Clemson 11:50 Lunch/Poster Fair 1:30 P Featured Talk "North Carolina Information Highway: Background, Technology, Applications and Implementation Status" Mr. Bill Smith, Senior Director Broadband Development, BellSouth 2:15 Featured Talk "Development of High Performance Telecommunications Networks from the Northern Telecom Perspective" Mr. Marc Williams,Director, Market Development, Broadband Services, Northern Telecom 3:00 Break 3:10 CCCS Faculty Talk "Performance Modeling of Transient Network Behavior" Dr. David Tipper, University of Pittsburgh 3:30 CCCS Faculty Talk "Wireless Communications Research at Clemson" Dr. Carl Baum, Electrical and Computer Engineering, Clemson 3:50 Featured Talk "The AURORA Gigabit Testbed - History and Results" Dr. Dave Feldmeier, Member of Technical Staff, Bellcore 4:35 Concluding Remarks/Poster Session Judging takes place 6:30 Reception/Dinner November 11 8:00 A Continental Breakfast Announce poster fair winners 8:30 Keynote Talk "ATM Networks: Issues and Challenges Ahead" Dr. Raj Jain, Professor, Ohio State University 9:15 Featured Talk "Information Security in Gigabit Networks" Mr. Dan Stevenson, Manager of Communications Research, Microelectronics Center of North Carolina 10:00 Break 10:10 CCCS Faculty Talk "The Viability of Competition in the New World of Telecommunications" Dr. Michael T. Maloney and Dr. Robert E. McCormick, Economics, Clemson 10:30 Featured Talk "Recent Advances in Rate-based Traffic Management for ATM Networks" Dr. Michael G. Hluchyj, Vice President, Chief Technology Officer, Summa Four, Inc. 11:15 CCCS Faculty Talk "Image Tracking, Binary Error Correction, and Memory Management with One Type of Tool: Neural Networks" Dr. Clark Jeffries, Mathematical Sciences, Clemson 11:35 CCCS Faculty Talk "The Earth in the Balance, or Why We Need Gb/s NOW!" Dr. Walt Ligon, Electrical and Computer Engineering, Clemson 11:55 Buffet Luncheon 1:30 P Featured Talk "Issues in Integrating Multiprotocol and ATM Routing" Mr. Steven Willis, Director, Network Technology, Wellfleet Communications, Inc. 2:15 Featured Talk "An Integrated Approach to High Speed, Multimedia (ATM) Networking." Dr. Gerald A. Marin, Manager High Band Width Networking, IBM 3:00 Break 3:10 CCCS Faculty Talk "Code Recognition Using Prescribed Adaptive Resonance Theory Neural Networks" Dr. Gene Tagliarini, Computer Science, Clemson 3:30 Featured Talk "A Flexible Lab-Scale Platform for ATM Network Research" Mr. Alan Pierce, Network Transport Systems Department, GTE Laboratories 4:15 Closing Remarks LODGING: Blocks of rooms have been reserved, until October 30, at The Clemson House (803) 646-2082, and The Ramada Inn (803) 654-7401. Space is limited so register early. Other recommended Clemson hotels include The Comfort Inn (803) 653-3600 and The Holiday Inn (803) 654-4450. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA02313; Wed, 28 Sep 1994 09:18:35 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA02279; Wed, 28 Sep 1994 09:18:19 -0500 Received: from hubcap.clemson.edu (hubcap.clemson.edu [130.127.8.1]) by timbuk.cray.com (8.6.9/8.6.9L) with ESMTP id JAA11792 for ; Wed, 28 Sep 1994 09:18:16 -0500 Received: from quickmail.clemson.edu (quickmail.clemson.edu [130.127.8.57]) by hubcap.clemson.edu (8.6.7/8.6.4) with SMTP id KAA04247; Wed, 28 Sep 1994 10:16:58 -0400 Message-Id: Date: 28 Sep 1994 10:13:28 -0500 From: "John Spragins" Return-Receipt-To: "John Spragins" Subject: Gigabit networking conferen To: "Email Groups1" , "Email Groups10" , "Email Groups11" , "Email Groups12" , "Email Groups13" , "Email Groups14" , "Email Groups15" , "Email Groups16" , "Email Groups17" , "Email Groups18" , "Email Groups19" , "Email Groups2" , "Email Groups20" , "Email Groups21" , "Email Groups22" , "Email Groups23" , "Email Groups24" , "Email Groups3" , "Email Groups4" , "Email Groups5" , "Email Groups6" , "Email Groups7" , "Email Groups8" , "Email Groups9" X-Mailer: Mail*Link SMTP/QM 3.0.0 Content-Length: 4945 Subject: Time:10:15 AM OFFICE MEMO Gigabit networking conference Date:9/28/94 "Gigabit Networks: Key to the Information Superhighway" Center for Computer Communication Systems 5th Annual Conference Clemson House Ballroom, Clemson University November 10-11, 1994 PROGRAM PERSONALITIES: *Dr. Craig Partridge, BBN *Dr. Raj Jain, Ohio State University Dr. David Feldmeier, Bellcore Dr. Michael Hluchyj, Summa Four, Inc. Dr. John Limb, Georgia Tech Dr. Gerald Marin, IBM Dr. Nick Maxemchuk, Bell Laboratories Mr. Alan Pierce, GTE Mr. Dan Stevenson, Microelectronics Center of NC Mr. Bill Smith, BellSouth Telecom Mr. Steven Willis, Wellfleet Communications * Keynote speakers FEE: $215.00 (Includes meals) REGISTRATION: Please send this form and a $215.00 check payable to "Clemson University" to: Ms. Wendy Winn Center for Computer Communication Systems 105 Riggs Hall Clemson, SC 29634 Phone: (803) 656-0848 Fax: (803) 656-5910 Email: wwendy@eng.clemson.edu Name: Affiliation: Address: Phone: E-mail Address: AGENDA: November 10 8:00 A Continental Breakfast 8:30 Keynote Talk "Local Computer Networks at Gigabit and Terabit Bandwidths" Dr. Craig Partridge, Bolt Beranek and Newman Inc. 9:00 Break 9:40 Introduction To Conference/Advisory Board Dr. John Spragins, Director, CCCS and Ms. Wendy Winn, Program Developer, CCCS, Clemson University 10:00 Featured Talk "Broadband Communications to the Home and Community" Dr. John Limb, Professor, College of Computing, Georgia Tech 10:45 Featured Talk "Electronic Distribution of Newspapers and Magazines" Dr. Nick Maxemchuck, Department Head, AT&T Bell Laboratories. 11:30 CCCS Faculty Talk "The Information Superhighway-Expectations for Agricultural Risk Management" Dr. Dale Linvill, Agricultural & Biological Engineering, Clemson 11:50 Lunch/Poster Fair 1:30 P Featured Talk "North Carolina Information Highway: Background, Technology, Applications and Implementation Status" Mr. Bill Smith, Senior Director Broadband Development, BellSouth 2:15 Featured Talk "Development of High Performance Telecommunications Networks from the Northern Telecom Perspective" Mr. Marc Williams,Director, Market Development, Broadband Services, Northern Telecom 3:00 Break 3:10 CCCS Faculty Talk "Performance Modeling of Transient Network Behavior" Dr. David Tipper, University of Pittsburgh 3:30 CCCS Faculty Talk "Wireless Communications Research at Clemson" Dr. Carl Baum, Electrical and Computer Engineering, Clemson 3:50 Featured Talk "The AURORA Gigabit Testbed - History and Results" Dr. Dave Feldmeier, Member of Technical Staff, Bellcore 4:35 Concluding Remarks/Poster Session Judging takes place 6:30 Reception/Dinner November 11 8:00 A Continental Breakfast Announce poster fair winners 8:30 Keynote Talk "ATM Networks: Issues and Challenges Ahead" Dr. Raj Jain, Professor, Ohio State University 9:15 Featured Talk "Information Security in Gigabit Networks" Mr. Dan Stevenson, Manager of Communications Research, Microelectronics Center of North Carolina 10:00 Break 10:10 CCCS Faculty Talk "The Viability of Competition in the New World of Telecommunications" Dr. Michael T. Maloney and Dr. Robert E. McCormick, Economics, Clemson 10:30 Featured Talk "Recent Advances in Rate-based Traffic Management for ATM Networks" Dr. Michael G. Hluchyj, Vice President, Chief Technology Officer, Summa Four, Inc. 11:15 CCCS Faculty Talk "Image Tracking, Binary Error Correction, and Memory Management with One Type of Tool: Neural Networks" Dr. Clark Jeffries, Mathematical Sciences, Clemson 11:35 CCCS Faculty Talk "The Earth in the Balance, or Why We Need Gb/s NOW!" Dr. Walt Ligon, Electrical and Computer Engineering, Clemson 11:55 Buffet Luncheon 1:30 P Featured Talk "Issues in Integrating Multiprotocol and ATM Routing" Mr. Steven Willis, Director, Network Technology, Wellfleet Communications, Inc. 2:15 Featured Talk "An Integrated Approach to High Speed, Multimedia (ATM) Networking." Dr. Gerald A. Marin, Manager High Band Width Networking, IBM 3:00 Break 3:10 CCCS Faculty Talk "Code Recognition Using Prescribed Adaptive Resonance Theory Neural Networks" Dr. Gene Tagliarini, Computer Science, Clemson 3:30 Featured Talk "A Flexible Lab-Scale Platform for ATM Network Research" Mr. Alan Pierce, Network Transport Systems Department, GTE Laboratories 4:15 Closing Remarks LODGING: Blocks of rooms have been reserved, until October 30, at The Clemson House (803) 646-2082, and The Ramada Inn (803) 654-7401. Space is limited so register early. Other recommended Clemson hotels include The Comfort Inn (803) 653-3600 and The Holiday Inn (803) 654-4450. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11695; Wed, 7 Sep 1994 18:31:48 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA11677; Wed, 7 Sep 1994 18:31:34 -0500 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by timbuk.cray.com (8.6.9/8.6.9L) with ESMTP id SAA27376 for ; Wed, 7 Sep 1994 18:31:32 -0500 Received: from localhost (mm94@localhost) by dworkin.wustl.edu (8.6.8.1/8.6.6.yuck) with SMTP id RAA00524; Wed, 7 Sep 1994 17:30:34 -0500 Message-Id: <199409072230.RAA00524@dworkin.wustl.edu> X-Authentication-Warning: dworkin.wustl.edu: Host localhost didn't use HELO protocol To: atm@bbn.com, end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.EDU, g-troup@dworkin.wustl.edu, ccrc@dworkin.wustl.edu, arl@arl1.wustl.edu, ietf@venera.isi.edu, rem-conf-request@es.net, tcplw@cray.com, tccc@cs.umass.edu, announcements.chi@xerox.com, simon@cui.unige.ch, sound@acm.org, sigmedia@bellcore.com, icad-request@santafe.edu, cip@bbn.com, iplpdn@cnri.reston.va.us, sip-request@catarina.usc.edu, smds@cnri.reston.va.us, s-comput%tcsvm.BITNET@wugate.wustl.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, sig11@roses.stanford.edu Subject: ACM Multimedia 94 Date: Wed, 07 Sep 1994 17:30:23 -0500 From: ACM Multimedia 94 Content-Length: 5247 Please note that the pre-registration deadline is September 15. Sorry if you get more than one copy of this email. ANNOUNCEMENT 2nd ANNUAL ACM MULTIMEDIA CONFERENCE AND EXPOSITION October 15-20, 1994 San Francisco, California Sponsored by the Association for Computing Machinery SIGBIO, SIGBIT, SIGCHI, SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, SIGMM, and SIGOIS and in cooperation with SIGAPP, SIGMOD, SIGOPS and the IEEE Communications Society. =================****=================****=================****============ MULTIMEDIA '94 WWW/MOSAIC AND FTP SITES The Multimedia '94 WWW home page contains the advance program, registration information, as well as other relevant details. The URL is: http://george.lbl.gov/MM94/MM94.html The advance program and registration form can also be retrieved by anonymous ftp: ftp://dworkin.wustl.edu/pub/MM94/program If you need more information about Multimedia'94 or the Advance Program, contact Danieli and O'Keefe (DOK), our conference management company. Address Danieli and O'Keefe 490 Boston Post Road Sudbury, MA 01776-9898 Phone numbers 800-524-1851, or 508-443-3330, Ext. 1214 Email multimedia.dok@notes.compuserve.com or ACMHELP@ACM.org =================****=================****=================****============ CONFERENCE HIGHLIGHTS * Why ACM Multimedia '94? The second ACM Multimedia Conference will present an exciting mixture of technology and art. Sessions will focus on what will be the standards of the future; not what is happening today. The program of papers, panels, courses, demonstrations, videos, and exhibits will explore the breadth and diversity of this ever-changing technology. * You should be there! This conference will be vital for researchers, technical staff, software engineers, educators and artists working in any and all aspects of multimedia research and production. ACM Multimedia will draw attendees and presenters from both academia and industry, including telecommunications, fine arts, engineering, software development, multimedia production, electronic publishing, digital libraries, computer graphics, user interfaces, broadcast media, and networking. * Opening and Closing Plenaries The technical program kicks off with a debate by industry leaders from LucasArts, Philips Electronics and the new Mosaic Communications, moderated by Dr. R.W. Lucky, of Bellcore. They will debate their differing views on the evolution of the Multimedia industry. At the Closing Plenary, Tom Holman, the award-winning designer of the THX sound system and Corporate Technical Director of LucasFilm, discusses presentations standards for sound and graphics and Scott Marden, of Philips Media will give his perspective on the emerging multimedia industry. See page 14 for more details. * The Ubiquitous Art Zone The Ubiquitous Art Zone is that part of Multimedia '94 that presents the creations of artists working in multimedia. The art work ranges from "immersive environments" and "garage VR" to narrative works on interactive CD ROM and hard drive. By their use of interactive interface technologies, the artists invite the visitors to become participants in a shared experience. Come celebrate the emergence of the art made possible by the digital revolution. * Ubiquitous Art Zone/Exhibit Reception Please join us Tuesday evening for a reception that allows you to experience the full range of the arts in multimedia, as well as to spend some unhurried time in the exhibit hall. * Exhibit Hall This is the best opportunity to see and learn from companies who will share their multimedia experiences with you. Digital Equipment Corp. and IBM are just two of the companies who are eager to show their products and services. * Electronic Proceedings The conference proceedings will be available on a CD-ROM and on electronic network. Both media will include the text of the papers being presented, video clips from the video program and other material. * Conference Videotape The ACM Multimedia '94 video will feature videotapes of multimedia systems in action, and other topics relevant to the conference. The videos have been selected based on their relevance, technical content, originality, presentation quality, and clarity. The videotape will be available for purchase at the conference. * Demonstrations Program The demonstration program will feature novel research prototypes that demonstrate the latest advances in multimedia computing and communications technologies. These juried and working prototypes will be exhibited at regular intervals by their creators. Time will be provided for personal interaction with the systems. * Best Paper Awards Both the best paper and the best student paper will be presented in a special session on Thursday afternoon. Come hear the best of the best! * Vendor Track A special venue has been provided for exhibitor presentations on their products and services. This is a unique opportunity to find out about the tools and products that can help you be more productive. =================****=================****=================****============ Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA22769; Mon, 29 Aug 1994 11:53:57 -0500 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA22754; Mon, 29 Aug 1994 11:53:47 -0500 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by timbuk.cray.com (8.6.9/8.6.9j) with SMTP id LAA13253 for ; Mon, 29 Aug 1994 11:53:44 -0500 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Mon, 29 Aug 1994 09:32:14 -0700 Date: Mon, 29 Aug 1994 09:32:14 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199408291632.AA24408@zephyr.isi.edu> To: tcplw@cray.com Subject: RFC-1323 implementations Cc: hsolomon@camden.ge.com Content-Length: 585 ----- Begin Included Message ----- >From hsolomon@camden.ge.com Mon Aug 29 09:29:33 1994 X-Mailer: InterCon TCP/Connect II 1.1 Date: Mon, 29 Aug 1994 12:31:31 -0500 From: Harry Solomon To: braden@ISI.EDU Subject: RFC-1323 implementations Content-Length: 252 X-Lines: 11 I am looking for a publicly available (not necessarily free, though) implementation of RFC-1323 for Sun/Solaris and/or HP/UX-9.0. Do you know of any such? Thanx. Harry Solomon Martin Marietta Communications Systems 1 Federal St. Camden, NJ 08103 ----- End Included Message ----- Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA09758; Mon, 22 Aug 1994 01:43:37 +0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA09753; Mon, 22 Aug 1994 01:43:36 +0600 Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by timbuk.cray.com (8.6.9/8.6.9j) with SMTP id BAA07235 for ; Mon, 22 Aug 1994 01:43:34 -0500 Received: from telecomm.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA04739; Sun, 21 Aug 1994 23:31:50 -0700 Received: by telecomm.hpl.hp.com (1.37.109.8/15.5+ECS 3.3+HPL1.1) id AA15970; Sun, 21 Aug 1994 23:31:54 -0700 Date: Sun, 21 Aug 1994 23:31:54 -0700 From: NOSSDAV Workshop Message-Id: <9408220631.AA15970@telecomm.hpl.hp.com> To: nossdav-groups@telecomm.hpl.hp.com Subject: Workshop announcement Content-Length: 4456 5th International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV '95) CALL FOR PAPERS April 19, 20, 21, 1995 Durham, New Hampshire, USA Sponsored by the IEEE Communications Society In cooperation with ACM SIGCOMM, SIGOPS, SIGMM, SIGGRAPH, and SIGIR Network and operating system support for digital audio and video are becoming increasingly important with the convergence of the computer, the TV, and communications. Innovation in this field is fueling the industry developments in interactive multimedia services to the home. In the past, research in this domain has largely originated as adaptations of specific technologies to support audio and video. This work has lead to an understanding of common cross-disciplinary problems. Increasingly, this work encompasses and integrates the diverse technology necessary to achieve end-to-end systems. To this end, research leading to complete solutions is viewed as particularly important to the workshop. The workshop is intended to bring together practitioners from a variety of areas, including communications and networks, operating systems, real-time systems and distributed computing. It is intended that an outcome of the workshop will be a statement of the the state of the art in this field, highlighting the major areas requiring future research. Relevant topics for the workshop include: High-speed/ATM networks Multimedia-oriented desk, local, and wide area networks Workstation architectures for multimedia Cell-based system architectures Multimedia network interfaces Communication protocols for multimedia Multicast Micro-kernel and OS support for real-time communications Resource management and reservation in the OS and network End-to-end admission control Quality of service and synchronization frameworks Multimedia storage, server, and I/O architectures Distributed multimedia systems APIs and CM programming abstractions for multimedia Community networking TV set-top device communication Instructions for Submitting Papers: Two types of submissions are solicited: position papers and research papers. For the purpose of paper review, position papers are restricted to three single-spaced ASCII pages. Research papers are restricted to an extended abstract no longer than five formatted postscript pages. Papers should be electronically mailed to nossdav95@spiderman.bu.edu Only if electronic submission is impossible, papers may be sent to: Prof. T.D.C. Little, Multimedia Communications Laboratory, Department of Electrical, Computer and Systems Engineering, Boston University, 44 Cummington Street, Boston, MA 02215 USA. Tel: +1 617 353-9877 Fax: +1 617 353-6440 tdcl@bu.edu. The proceedings of the workshop will be published by Springer-Verlag and the best papers will be forwarded to selected journals for publication. Important Dates: Abstracts due: December 12, 1994 Acceptance notification: January 25, 1995 Final paper due: March 8, 1995 Workshop: April 19, 1995 Program Co-Chairs: Riccardo Gusella, HP Labs, USA T.D.C. Little, Boston University, USA Program Committee: Stavros Christodoulakis, Technical University of Crete Domenico Ferrari, University of California, Berkeley Ralf Herrtwich, IBM Creative Multimedia Studios Andy Hopper, Olivetti & University of Cambridge Kevin Jeffay, University of North Carolina at Chapel Hill Chuck Kalmanek, AT&T Bell Laboratories Jim Kurose, University of Massachusetts at Amherst Aurel Lazar, Columbia University Derek McAuley, Cambridge University Duane Northcutt, Sun Microsystems Laboratories Guru Parulkar, Washington University Steve Pink, Swedish Institute of Computer Science Radu Popescu-Zeletin, GMD-FOKUS K.K. Ramakrishnan, Digital Equipment Corporation P. Venkat Rangan, University of California, San Diego Jon Rosenberg, Bell Communications Research Eve Schooler, USC/Information Sciences Institute Doug Shepherd, Lancaster University Cormac Sreenan, AT&T Bell Laboratories Jean-Bernard Stefani, France Telecom/CNET Daniel Swinehart, Xerox PARC Hideyuki Tokuda, Carnegie Mellon University/Keio University Jon Walpole, Oregon Graduate Institute of Science & Technology Raj Yavatkar, University of Kentucky This CFP is on-line at http://spiderman.bu.edu. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05286; Thu, 18 Aug 1994 11:31:07 +0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA05267; Thu, 18 Aug 1994 11:31:00 +0600 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by timbuk.cray.com (8.6.9/8.6.9j) with ESMTP id LAA21410 for ; Thu, 18 Aug 1994 11:30:57 -0500 Received: (from mm94@localhost) by dworkin.wustl.edu (8.6.8.1/8.6.6.yuck) id KAA17718; Thu, 18 Aug 1994 10:53:29 -0500 Date: Thu, 18 Aug 1994 10:53:29 -0500 From: ACM Multimedia 94 Message-Id: <199408181553.KAA17718@dworkin.wustl.edu> To: announcements.chi@Xerox.com, arl@arl1.wustl.edu, atm@bbn.com, ccrc@dworkin.wustl.edu, cip@bbn.com, end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.EDU, g-troup@dworkin.wustl.edu, icad-request@santafe.edu, ietf@venera.isi.edu, iplpdn@nri.reston.va.us, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, s-comput%tcsvm.BITNET@wugate.wustl.edu, sig11@roses.stanford.edu, sigmedia@bellcore.com, sip-request@catarina.usc.edu, smds@nri.reston.va.us, sound@acm.org, tccc@cs.umass.edu, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@Xerox.com Subject: ADVANCE PROGRAM -- ACM MULTIMEDIA 94 Content-Length: 6701 ANNOUNCEMENT 2nd ANNUAL ACM MULTIMEDIA CONFERENCE AND EXPOSITION October 15-20, 1994 San Francisco, California Sponsored by the Association for Computing Machinery SIGBIO, SIGBIT, SIGCHI, SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, SIGMM, and SIGOIS and in cooperation with SIGAPP, SIGMOD, SIGOPS and the IEEE Communications Society. =================****=================****=================****============ MULTIMEDIA '94 WWW/MOSAIC AND FTP SITES The Multimedia '94 WWW home page contains the advance program, registration information, as well as other relevant details. The URL is: http://george.lbl.gov/MM94/MM94.html The advance program and registration form can also be retrieved by anonymous ftp: ftp://dworkin.wustl.edu/pub/MM94/program If you need more information about Multimedia'94 or the Advance Program, contact Danieli and O'Keefe (DOK), our conference management company. Address Danieli and O'Keefe 490 Boston Post Road Sudbury, MA 01776-9898 Phone numbers 800-524-1851, or 508-443-3330, Ext. 1214 Email multimedia.dok@notes.compuserve.com or ACMHELP@ACM.org =================****=================****=================****============ CONFERENCE HIGHLIGHTS * Why ACM Multimedia '94? The second ACM Multimedia Conference will present an exciting mixture of technology and art. Sessions will focus on what will be the standards of the future; not what is happening today. The program of papers, panels, courses, demonstrations, videos, and exhibits will explore the breadth and diversity of this ever-changing technology. * You should be there! This conference will be vital for researchers, technical staff, software engineers, educators and artists working in any and all aspects of multimedia research and production. ACM Multimedia will draw attendees and presenters from both academia and industry, including telecommunications, fine arts, engineering, software development, multimedia production, electronic publishing, digital libraries, computer graphics, user interfaces, broadcast media, and networking. * Opening and Closing Plenaries The technical program kicks off with a debate by industry leaders from LucasArts, Philips Electronics and the new Mosaic Communications, moderated by Dr. R.W. Lucky, of Bellcore. They will debate their differing views on the evolution of the Multimedia industry. At the Closing Plenary, Tom Holman, the award-winning designer of the THX sound system and Corporate Technical Director of LucasFilm, discusses presentations standards for sound and graphics and Scott Marden, of Philips Media will give his perspective on the emerging multimedia industry. See page 14 for more details. * The Ubiquitous Art Zone The Ubiquitous Art Zone is that part of Multimedia '94 that presents the creations of artists working in multimedia. The art work ranges from "immersive environments" and "garage VR" to narrative works on interactive CD ROM and hard drive. By their use of interactive interface technologies, the artists invite the visitors to become participants in a shared experience. Come celebrate the emergence of the art made possible by the digital revolution. * Ubiquitous Art Zone/Exhibit Reception Please join us Tuesday evening for a reception that allows you to experience the full range of the arts in multimedia, as well as to spend some unhurried time in the exhibit hall. * Exhibit Hall This is the best opportunity to see and learn from companies who will share their multimedia experiences with you. Digital Equipment Corp. and IBM are just two of the companies who are eager to show their products and services. * Electronic Proceedings The conference proceedings will be available on a CD-ROM and on electronic network. Both media will include the text of the papers being presented, video clips from the video program and other material. * Conference Videotape The ACM Multimedia '94 video will feature videotapes of multimedia systems in action, and other topics relevant to the conference. The videos have been selected based on their relevance, technical content, originality, presentation quality, and clarity. The videotape will be available for purchase at the conference. * Demonstrations Program The demonstration program will feature novel research prototypes that demonstrate the latest advances in multimedia computing and communications technologies. These juried and working prototypes will be exhibited at regular intervals by their creators. Time will be provided for personal interaction with the systems. * Best Paper Awards Both the best paper and the best student paper will be presented in a special session on Thursday afternoon. Come hear the best of the best! * Vendor Track A special venue has been provided for exhibitor presentations on their products and services. This is a unique opportunity to find out about the tools and products that can help you be more productive. =================****=================****=================****============ CONFERENCE COMMITTEE CO-CHAIRS M. Blattner, Lawrence Livermore National Laboratory and University of California, Davis J. O. Limb, Georgia Institute of Technology, Atlanta ADVISORY COMMITTEE E. Fox, Virginia Polytechnic Institute and SU TREASURER R. B. Allen, Bellcore PROCEEDINGS J. J. Garcia-Luna, University of California, Santa Cruz WORKSHOPS S. Wilbur, Queen Mary & Westfield College, UK DEMONSTRATIONS T. Little, Boston University VIDEO M. Brown, Digital Equipment Corporation D. Redell, Digital Equipment Corporation ELECTRONIC PUBLISHING R. Rada, University of Liverpool, UK PANELS A. Kuchinsky, Hewlett-Packard S. Bulick, US WEST Technologies COURSES E. P. Glinert, Rensselaer Polytechnic Institute D. McIntyre, Morgan, Stanley & Co. K. Wittenburg, Bell Communications Research, LOCAL ARRANGEMENTS J. D. Smith, Lawrence Livermore National Laboratory PUBLICITY G. Parulkar, Washington University in St. Louis EXHIBITS P. Mantey, University of California, Santa Cruz AUDIO/VISUAL N. Johnston, Lawrence Berkeley Laboratory UBIQUITOUS ART ZONE Beverly Reiser PROGRAM COMMITTEE Chair D. Ferrari, University of California, Berkeley CO-CHAIRS S. Ahuja, AT&T Bell Laboratories F. Kitson, Hewlett-Packard T. Kunii, University of Aizu, Japan R. Phillips, Los Alamos National Laboratory R. Rada, University of Liverpool, UK R. Sacks-Davis, the Royal Melbourne Institute of Technology. =================****=================****=================****============ Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03595; Tue, 2 Aug 1994 18:00:57 +0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03591; Tue, 2 Aug 1994 18:00:55 +0600 Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [129.35.208.98]) by timbuk.cray.com (8.6.9/8.6.9fxxx) with SMTP id SAA29862 for ; Tue, 2 Aug 1994 18:00:51 -0500 Received: from vikings.austin.ibm.com by netmail.austin.ibm.com (AIX 3.1/UCB 5.61/gw.0.7) for tcplw@cray.com at cray.com id AA270520; Tue, 2 Aug 94 18:00:49 -0500 Received: by vikings.austin.ibm.com (AIX 3.2/UCB 5.64/4.03-client-2.4) for tcplw@cray.com at austin.ibm.com; id AA27396; Tue, 2 Aug 1994 18:00:47 -0500 From: swise@austin.ibm.com (Stevo Bevo-Devo Wise) Message-Id: <9408022300.AA27396@vikings.austin.ibm.com> To: tcplw@cray.com Subject: Re: checksum on move question In-Reply-To: (Your message of Tue, 02 Aug 94 18:52:09 D.) <29253.775867929@N2.SP.CS.CMU.EDU> Date: Tue, 02 Aug 94 18:00:47 -0600 Content-Length: 952 Brian_Zill@N2.SP.CS.CMU.EDU says: | Steve, | | I'm unclear on why you feel you need to return an error to the user. | Is the read call on your system supposed to guarantee that the remainder | of buffer hasn't been modified without explicitly telling the user? If not, | I'd have read return 0 bytes read (if the socket is marked non-blocking) | or not return until a packet arrives that checksums o.k. (if it is blocking). | | Then again, maybe I'm missing something. | | --Brian Maybe that's ok for someone who directly called the read(), recv(), etc... But what about apps that select() on the file, then read(). If they select() true for read, then I block them or return 0, that could be fatal...could it not? However, I think you touched on the obvious...I suppose I can just return 0 bytes read...that's much better than EINTR at least for the apps that call read()/recv()/etc directly with no selecting going on... Thanx, Stevo. Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03158; Tue, 2 Aug 1994 17:55:12 +0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03151; Tue, 2 Aug 1994 17:55:10 +0600 Received: from N2.SP.CS.CMU.EDU (N2.SP.CS.CMU.EDU [128.2.250.82]) by timbuk.cray.com (8.6.9/8.6.9fxxx) with SMTP id RAA29239 for ; Tue, 2 Aug 1994 17:55:08 -0500 From: Brian_Zill@N2.SP.CS.CMU.EDU Received: from N2.SP.CS.CMU.EDU by N2.SP.CS.CMU.EDU id aa29255; 2 Aug 94 18:52:28 EDT To: Stevo Bevo-Devo Wise Cc: tcplw@CRAY.COM Subject: Re: checksum on move question In-Reply-To: Your message of "Tue, 02 Aug 94 17:18:03 MDT." <9408022218.AA40227@vikings.austin.ibm.com> Date: Tue, 02 Aug 94 18:52:09 -0400 Message-Id: <29253.775867929@N2.SP.CS.CMU.EDU> Content-Length: 886 Steve Wise writes: >I'm implementing protocol-specific send and receive routines for TCP >and UDP in order to checksum the data whilest I move it from user space >to kernel space and vice versa (sp?). > >I'm doing this on...ahem...a *nix O/S which is based on BSD 4.3 Net2. > >Question: If I do this on receive, and the checksum fails, I must >somehow discard the data I moved into the users buffer. Right now I'm >returning EINTR. Is this reasonable? Steve, I'm unclear on why you feel you need to return an error to the user. Is the read call on your system supposed to guarantee that the remainder of buffer hasn't been modified without explicitly telling the user? If not, I'd have read return 0 bytes read (if the socket is marked non-blocking) or not return until a packet arrives that checksums o.k. (if it is blocking). Then again, maybe I'm missing something. --Brian Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA00436; Tue, 2 Aug 1994 17:18:25 +0600 Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA00429; Tue, 2 Aug 1994 17:18:23 +0600 Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [129.35.208.98]) by timbuk.cray.com (8.6.9/8.6.9fxxx) with SMTP id RAA22164 for ; Tue, 2 Aug 1994 17:18:16 -0500 Received: from vikings.austin.ibm.com by netmail.austin.ibm.com (AIX 3.1/UCB 5.61/gw.0.7) for tcplw@cray.com at cray.com id AA248344; Tue, 2 Aug 94 17:18:08 -0500 Received: by vikings.austin.ibm.com (AIX 3.2/UCB 5.64/4.03-client-2.4) for tcplw@cray.com at austin.ibm.com; id AA40227; Tue, 2 Aug 1994 17:18:04 -0500 From: swise@austin.ibm.com (Stevo Bevo-Devo Wise) Message-Id: <9408022218.AA40227@vikings.austin.ibm.com> To: tcplw@cray.com Subject: checksum on move question Date: Tue, 02 Aug 94 17:18:03 -0600 Content-Length: 880 Question for any of you who've already implemented this: I'm implementing protocol-specific send and receive routines for TCP and UDP in order to checksum the data whilest I move it from user space to kernel space and vice versa (sp?). I'm doing this on...ahem...a *nix O/S which is based on BSD 4.3 Net2. Question: If I do this on receive, and the checksum fails, I must somehow discard the data I moved into the users buffer. Right now I'm returning EINTR. Is this reasonable? Has anyone out there done this some other way? I figured well behaved apps should always retry a read operation when they receive EINTR, but the app I was using to test all this didn't!!! It just bailed on any receive error... Any thoughts would be appreciated... Thanx, ******** Steve Wise IBM RISC System/6000 Division - Austin, TX. Internet: swise@austin.ibm.com VNET: AUSTIN(SWISE) Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA13254; Thu, 28 Jul 1994 13:44:53 +0600 Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA13244; Thu, 28 Jul 1994 13:44:50 +0600 Received: from dworkin.wustl.edu by cray.com (Bob mailer 1.3) id AA16838; Thu, 28 Jul 94 13:44:45 CDT Received: (from zubin@localhost) by dworkin.wustl.edu (8.6.8.1/8.6.6.yuck) id NAA22817 for tcplw@cray.com; Thu, 28 Jul 1994 13:46:11 -0500 From: Zubin Dittia Message-Id: <199407281846.NAA22817@dworkin.wustl.edu> Subject: ACM MULTIMEDIA 94 -- ADVANCE PROGRAM To: tcplw@cray.com Date: Thu, 28 Jul 1994 13:46:10 -0500 (CDT) Organization: Washington University in St. Louis Phone: (314)-935-4163 (off), (314)-962-4176 (res) X-Z: I will not be pushed, filed, stamped, indexed, briefed, debriefed, X-Z: or numbered. My life is my own. X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 47757 A D V A N C E P R O G R A M 2nd ANNUAL ACM MULTIMEDIA CONFERENCE AND EXPOSITION October 15-20, 1994 San Francisco, California Sponsored by the Association for Computing Machinery SIGBIO, SIGBIT, SIGCHI, SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, SIGMM, and SIGOIS and in cooperation with SIGAPP, SIGMOD, SIGOPS and the IEEE Communications Society. =================****=================****=================****============ FOR MORE INFORMATION To receive more information about Multimedia'94 or the Advance Program, contact Danieli and O'Keefe (DOK), our conference management company. Address and phone number information on DOK is included at the end of this message. =================****=================****=================****============ CONFERENCE HIGHLIGHTS * Why ACM Multimedia '94? The second ACM Multimedia Conference will present an exciting mixture of technology and art. Sessions will focus on what will be the standards of the future; not what is happening today. The program of papers, panels, courses, demonstrations, videos, and exhibits will explore the breadth and diversity of this ever-changing technology. * You should be there! This conference will be vital for researchers, technical staff, software engineers, educators and artists working in any and all aspects of multimedia research and production. ACM Multimedia will draw attendees and presenters from both academia and industry, including telecommunications, fine arts, engineering, software development, multimedia production, electronic publishing, digital libraries, computer graphics, user interfaces, broadcast media, and networking. * Opening and Closing Plenaries The technical program kicks off with a debate by industry leaders from LucasArts, Philips Electronics and the new Mosaic Communications, moderated by Dr. R.W. Lucky, of Bellcore. They will debate their differing views on the evolution of the Multimedia industry. At the Closing Plenary, Tom Holman, the award-winning designer of the THX sound system and Corporate Technical Director of LucasFilm, discusses presentations standards for sound and graphics and Scott Marden, of Philips Media will give his perspective on the emerging multimedia industry. See page 14 for more details. * The Ubiquitous Art Zone The Ubiquitous Art Zone is that part of Multimedia '94 that presents the creations of artists working in multimedia. The art work ranges from "immersive environments" and "garage VR" to narrative works on interactive CD ROM and hard drive. By their use of interactive interface technologies, the artists invite the visitors to become participants in a shared experience. Come celebrate the emergence of the art made possible by the digital revolution. * Ubiquitous Art Zone/Exhibit Reception Please join us Tuesday evening for a reception that allows you to experience the full range of the arts in multimedia, as well as to spend some unhurried time in the exhibit hall. * Exhibit Hall This is the best opportunity to see and learn from companies who will share their multimedia experiences with you. Digital Equipment Corp. and IBM are just two of the companies who are eager to show their products and services. * Electronic Proceedings The conference proceedings will be available on a CD-ROM and on electronic network. Both media will include the text of the papers being presented, video clips from the video program and other material. * Conference Videotape The ACM Multimedia '94 video will feature videotapes of multimedia systems in action, and other topics relevant to the conference. The videos have been selected based on their relevance, technical content, originality, presentation quality, and clarity. The videotape will be available for purchase at the conference. * Demonstrations Program The demonstration program will feature novel research prototypes that demonstrate the latest advances in multimedia computing and communications technologies. These juried and working prototypes will be exhibited at regular intervals by their creators. Time will be provided for personal interaction with the systems. * Best Paper Awards Both the best paper and the best student paper will be presented in a special session on Thursday afternoon. Come hear the best of the best! * Vendor Track A special venue has been provided for exhibitor presentations on their products and services. This is a unique opportunity to find out about the tools and products that can help you be more productive. =================****=================****=================****============ WORKSHOPS Workshop participation will be by invitation only, based on submission of a position paper. Position papers should be kept short (3-5 pages), and should include information about the author's experience, current projects and a statement on relevant issues. Full contact details should also be included. Three copies of the position paper should be sent to the contact person by 1 August. The workshop fee is $40.00, payable to the appropriate contact person upon acceptance of position paper. Deadline for submission of position papers: 1 August Notification of acceptance: 22 August WORKSHOP W1 Telepresence in Multimedia Collaboration Saturday, October 15 Kate Finn SRI International This workshop will discuss issues in achieving a sense of telepresence in multimedia collaboration. Recent advances in real-time multimedia communications will enable people to collaborate remotely in a wide range of activities, and for some tasks and applications, a sense of telepresence may be essential for effective collaboration. Issues raised by the telepresence concept will be discussed. Topics of interest include the following: visual, verbal, or gestural cues that are good indicators of telepresence; situations where a heightened sense of telepresence is most important; which technologies may increase people's sense of telepresence; design paradigms that best support an improved sense of telepresence. Participants are encouraged to contribute short videos demonstrating aspects of telepresence. Contact person: Kate Finn SRI International Menlo Park, CA 94025 Email: finn@erg.sri.com Phone: 415-859-2124 Fax: 415-859-4812 WORKSHOP W2 Interactive Multipoint Services (organized by IEEE COMSOC Multimedia Systems Committee) Friday, October 21 Sudhir R. Ahuja AT&T Laboratories Jeff Derby IBM Corporation This workshop focuses on the challenges and roadblocks facing implementation and deployment of interactive multipoint services. In spite of significant interest in real-time interaction for applications such as distance learning and multimedia conferencing, multipoint services to support these have been hard to realize. This workshop is intended to address the research and implementation issues facing realization of such systems and services. The topics of interest include, but are not limited to, multicast protocols, multimedia bridging, access control, synchronization, distributed time and multi-user applications such as whiteboards, groupware, etc. Emphasis will be put on discussion of real experiments or systems. Practicing researchers are invited to submit an abstract (< 500 words) describing their work in a topic of interest. Contact person: Sudhir R. Ahuja, 4F-601, AT&T Bell Laboratories 101 Crawfords Corner Road, Holmdel, NJ 07733. Email: sra@research.att.com Phone: 908-949-5569 Fax: 908-949-0399 WORKSHOP W3 Multimedia Database Management Systems (M-DBMS) Friday, October 21 Bruce Berra Syracuse University Kingsley Nwosu IBM Corporation Bhavani Thuraisingham The MITRE Corporation This workshop will investigate issues in designing and developing M-DBMSs. A M-DBMS which supports distributed applications should integrate the two technologies of distributed/heterogeneous databases and multimedia data management. This integration is one of the greatest challenges faced by information systems researchers and developers, and will be the main focus of this workshop. The topics to be discussed include the following: data models; storage structures; system, schema and functional architectures; retrieval algorithms; update algorithms; metadata management for multimedia databases. Participants of the workshop will include members of the database community and the multimedia information systems community. Contact Person: Dr. Bhavani Thuraisingham The Mitre Corporation K329 Burlington Road Bedford MA 01730 Email: Bhavani_Thuraisingham@star9gate.mitre.org Phone: 617-271-8873 Fax: 617-271-2352 =================****=================****=================****============ STUDENT VOLUNTEER PROGRAM Student Volunteers will receive: Free attendance at the Tuesday though Thursday MM '94 conference. In addition, each Student Volunteer may attend two course units (two half day courses or one full day course) for free, space permitting. The Student Volunteers who work at a course will receive all of the course materials and they may participate in the activities of the course to the extent that their work duties will allow. Requests are honored on a first come, first served basis. The conference cannot pay for student lodging, but the student volunteers co-chairs can provide minimal assistance to students with specific needs. For more information on the Student Volunteer Program, or to volunteer, contact: James D. Smith LLNL P.O. Box 808 L-665 Livermore, Ca., 94550, Email: jdsmith@llnl.gov =================****=================****=================****============ TECHNICAL PROGRAM Introduction from the Program Chair The papers selected for presentation at ACM Multimedia '94 describe research ideas, emerging technologies, innovative applications, and experience with multimedia systems. They were chosen from more than 200 submissions that came, as did the 6 Co-Chairs and the 41 members of the Program Committee, from all over the world. Only one out of every four submitted papers could be included in the program. Both in quality and coverage, the paper sessions at ACM Multimedia '94 are the best available snapshot of the state of the art and of the trends in the many facets of this exciting new discipline and of this booming new industry. Domenico Ferrari Program Chair Introduction from the Panel Co-Chairs The range of technical, artistic, and social topics covered by this year's panels reflect the inherently complex nature of the multimedia community, which continues to grow and diversify. While some panels address mostly technical issues and others mostly artistic ones, still others impart a sense of the rich interaction between the two. A common theme is the democratic notion that 500 interactive channels should deliver more than the centrally-originated content of repurposed movie plots and on-demand reruns of old television shows. Panels are real-time experiences for the panelists and the audience, where nascent ideas can be surfaced without much risk and stimulating discussions can be continued in breakout rooms after formal sessions end. Allan Kuchinsky, Steve Bulick Panel Co-Chairs *** TUESDAY, OCTOBER 18 *** Welcoming Remarks Best paper awards =*= Opening Plenary Panel =*= Multimedia: Evolution of a New Industry? Multimedia is the fusion of a large number of technologies, and during the last year it mushroomed in importance. Perhaps we are witnessing the emergence of a new industry. How does multimedia in business relate to multimedia in the home? Will multimedia services to the home be delivered via the set-top? Where are the greatest opportunities games, education, information services, movies? Are all the pieces in place for an industry to take off? A panel of industry leaders will address these questions, as well as issues suggested by the conference attendees. MODERATOR Robert W. Lucky, Corporate Vice President of Applied Research, Bellcore PANELISTS Frank P. Carrubba, Executive Vice President and Chief Technical Officer of Philips Electronics N. V. James H. Clark, CEO and President, Mosaic Communications Corp. Randy S. Komisar, President and CEO, LucasArts Entertainment Company =*= SESSION 1A =*= Video on Demand Chair: Gregory Wallace, The 3DO Company Scheduling Policies for an On-Demand Video Server with Batching A. Dan, D. Sitaram, and P. Shahabuddin, IBM Research Center Providing VCR Capabilities in Large-Scale Video Servers J. Dey, J. Salehi, J. Kurose, and D. Towsley, University of Massachusetts at Amherst A Statistical Admission Control Algorithm for Multimedia Servers H. Vin, P. Goyal, A. Goyal, and A. Goyal, University of Texas at Austin =*= SESSION 1B =*= Tools Chair: Lawrence A. Rowe, University of California at Berkeley SCOOT: An Object-Oriented Toolkit for Multimedia Collaboration E. Craighill, M. Fong, K. Skinner, R. Lang, and K. Gruenefeldt SRI International Direct Manipulation of Temporal Structures in a Multimedia Application Framework P. Ackermann, University of Zurich, Switzerland DAVE: A Plug and Play Model for Distributed Multimedia Application Development R. Mines, J. Friesen, and C. Yang, Sandia National Laboratories =*= PANEL P1 =*= Multimedia Databases and Information Systems Organizers: Dragutin Petrovic, IBM Almaden Research Center and Farshid Arman, Siemens Corporate Research Panelists: Charlie Judice, Bell Atlantic; Alex Pentland, MIT Media Lab; J. Normile, Apple Computer, Inc. =*= SESSION 2A =*= Compressed Stream Processing Chair: Vason Srini, DataFlow Systems The Personal Presence System - Hardware Architecture, M. Lukacs, Bellcore Fast Software Processing of Motion JPEG Video B. Smith, Cornell University Higher Bandwidth X J. Danskin, Princeton University =*= SESSION 2B =*= Presentation Issues Chair: Michael A. Harrison, University of California at Berkeley Content-Based Browsing of Video Sequences F. Arman, R. Depommier, A. Hsu, and M.-Y. Chiu Siemens Corporate Research, Princeton, NJ Towards Usability Guidelines for Multimedia Systems M. Bearne, S. Jones, and J. Sapsford-Francis University of Hertfordshire, UK PREMO: An ISO Standard for Presentation Environment for Multimedia Objects I. Herman, P. ten Hagen, and G. Reynolds Center for Mathematics and Computer Sciences, The Netherlands S. Carson, GSC Associates Inc., J. Davy, Groupe Bull, France D. Duce, Rutherford Appleton Laboratory, UK W. Hewitt, University of Manchester, UK K. Kansy, Gesellschaft fur Mathematik und Datenverarbeitung, Germany B. Lurvey, Wang Laboratories, Inc. R. Puk, Puk Consulting Services H. Stenzel, Fachhochschule Koln, Germany =*= PANEL P2 =*= Collaborative Multimedia: Getting Beyond the Obvious Organizer: Bonnie Nardi, Apple Panelists: Sara Bly, Xerox PARC; Ellen Isaacs, SunSoft; Sha Xin Wei, Stanford University; Steve Whittaker, Lotus Development Corp. =*= SPECIAL PRESENTATIONS =*= Placeholder: Landscape and Narrative in Virtual Environments Brenda Laurel and Rachel Strickland, Interval Research, Palo Alto, CA. Placeholder: Technology and the Senses Rob Tow, Interval Research, Palo Alto, CA. *** WEDNESDAY OCTOBER 19 *** *=* SESSION 3A *=* Synchronization Chair: Jonathan Rosenberg, Bellcore Towards a New Multimedia Synchronization Mechanism and its Formal Definition J.-P. Courtiat, R. Cruz de Oliveira, and L. Rust da Costa Carmo LAAS/CNRS, France Synchronization of Distributed Multimedia Data in an Application-Specific Manner N. Agarwal and S. Son, University of Virginia An Automatic Lip-Synchronization Algorithm for Synthetic Faces K. Waters and T. Levergood, DEC Cambridge Research Laboratory *=* SESSION 3B *=* Documents and Authoring Chair: Richard Phillips, Los Alamos National Laboratory Enabling Hypermedia Messaging K. Lenssen, RWTH, Germany Video Mosaic: Laying Out Time in a Physical Space, W. Mackay and D. Pagani, Rank Xerox EuroPARC, UK The Walk-Through Approach to Authoring Multimedia Documents S. Hudson and C.-N. Hsi, Georgia Institute of Technology *=* PANEL P3 *=* No Multimedia Without Representation Organizer: Marc Davis, MIT Media Laboratory and Interval Research Corporation Panelists: Catherine Baudin, NASA Ames Research Center; Smadar Kedar, Institute for the Learning Sciences; Daniel M. Russell, Apple Computer *=* SESSION 4A *=* Real-Time Networking Chair: Eric Hoffert, Apple Computer, Inc. Experiments with the Tenet Real-Time Protocol Suite on the Sequoia 2000 Wide Area Network A. Banerjea, E. Knightly, F. Templin, and H. Zhang, University of California at Berkeley Capturing and Playing Multimedia Events with STREAMS, G. Cruz and R. Hill, Bellcore Predictive Prefetch in the Nemesis Multimedia Information Service H. Katseff and B. Robinson, AT&T Bell Laboratories *=* SESSION 4B *=* Retrieval Techniques Chair: Arding Hsu, Siemens Corporate Research, Princeton, NJ Content-based Retrieval of Segmented Images T.-S. Chua, S.-K. Lim, and H.-K. Pung, National University of Singapore Rx for Semantic Video Database Retrieval N. Dimitrova and F. Golshani, Arizona State University Towards Intelligent Recognition of Multimedia Episodes in Real-Time Applications J. Gabbe, A. Ginsberg, and B. Robinson, AT&T Bell Laboratories *=* PANEL P4 *=* Special Presentation: Museums and Multimedia: Extending the Experience Beyond the Museum's Walls Organizer: Rob Semper, San Francisco Exploratorium Panelists: Arnold Kramer, Director of Technical Services, US Holocaust Memorial Museum; Dr. Robert J. Semper, Executive Associate Director, San Francisco Exploratorium *=* SESSION 5A *=* Video Transmission Chair: Brian Smith, Cornell University MPEG-2 Coded- and Uncoded-Stream Synchronization Control for Real-Time Multimedia Transmission and Presentation over B-ISDN L. Li and N. Georganas, University of Ottawa, Canada Two-Dimensional Scaling Techniques for Adaptive, Rate-Based Transmission Control of Live Audio and Video Streams T. Talley and K. Jeffay, University of North Carolina at Chapel Hill A Cell Loss Equalization Protocol for Video Multiplexers I. Nikolaidis and I. Akyildiz, Georgia Institute of Technology *=* SESSION 5B *=* Databases Chair: Tosiyasu Kunii, University of Aizu, Japan Multimedia Technology in the Radiology Department F. Sauer and M. Kabuka, University of Miami Building Temporal Structures in a Layered Multimedia Data Model G. Schloss and M. Wynblatt, State University of New York at Stony Brook Quad-Tree Segmentation for Texture-Based Image Query J. Smith and S.-F. Chang, Columbia University *=* PANEL P5 *=* Artists in Multimedia: Creating Meaningful Roles Organizer: Rich Gold, Xerox PARC; Panelists: Char Davies, Visual Research; Michael Naimark, Interval Research; Mark Petrakis, pARTY/SCIENCE *=* SESSION 6A *=* System Support Chair: Ralf G. Herrtwich, IBM ENC, Germany A Continuous Media Application Supporting Dynamic QOS Control on Real-Time Mach T. Nakajima and H. Tezuka Japan Advanced Institute of Science and Technology, Japan Supporting Real-Time Multimedia Behaviour in Open Distributed Systems: An Approach Based on Synchronous Languages G. Blair, M. Papathomas, G. Coulson, P. Robin, L. Hazard, Lancaster University, UK J. Stefani, and F. Horn, Centre National d'Etude des Telecommunications, France The VuSystem: A Programming System for Visual Processing of Digital Video C. Lindblad, D. Wetherall, and D. Tennenhouse MIT Laboratory for Computer Science *=* SESSION 6B *=* Education Chair: Edward Fox, Virginia Polytechnic Institute The Influence of Multimedia on Learning: A Cognitive Study A. Large, J. Beheshti, A. Breuleux, and A. Renaud, McGill University, Canada Hypermedia Method to Teach Concepts of Colour through Art J. Castellanos, J. Delicado, C. Dominguez, Universidad Politecnica de Madrid, Spain and C. Rigo, Universidad Complutense de Madrid, Spain "Enlaces" A Multimedia Based Educational Network P. Hepp, L. Rehbein, E. Hinostroza, E. Laval, C. Dreves, and M. Ripoll, Universidad de La Frontera, Chile *=* PANEL P6 *=* From Generation to Generation: Multimedia, Community and Personal Stories Organizer: Abbe Don, Kaleida Labs Panelists: Laura Teodosio, Co-developer, Multimedia Memory or Mayan Medicine; Joe Lambert, Artistic Director, Life on the Water; Dana Atchley, D3TV *=* PANEL P7 *=* BAGNet: An ATM-Based Multimedia Applications Testbed Organizer: William Johnston, Lawrence Berkeley Laboratory Panelists: Rick Hronicek, Pacific Bell Yuet Lee, Pacific Bell Dan Swinehart, Xerox PARC Additional panelists to be announced. *** THURSDAY OCTOBER 20 *** *=* SESSION 7A *=* Video Analysis Chair: Arturo A. Rodriguez, Kaleida Labs Adaptive Color Map Selection Algorithm for Motion Sequences J. Furlani, Sun Microsystems L. McMillan, University of North Carolina at Chapel Hill, and L. Westover, Division, Inc. Video Tomography: An Efficient Method for Camerawork Extraction and Motion Analysis A. Akutsu and Y. Tonomura, Nippon Telegraph and Telephone Corp., Japan Digital Video Segmentation A. Hampapur, T. Weymouth, University of Michigan and R. Jain, University of California at San Diego *=* SESSION 7B *=* Audio Chair: Joseph Pasquale, University of California at San Diego A Beat Tracking System for Acoustic Signals of Music M. Goto and Y. Muraoka, Waseda University, Japan A Distributed Computer System for Professional Audio, D. Anderson, R. Doris, and J. Moorer, Sonic Solutions Protocols for Integrated Audio and Shared Windows in Collaborative Systems A. Mathur and A. Prakash, University of Michigan *=* PANEL P8 *=* In Search of the Right Model for Video-Mediated Communication Organizers: Sylvia Wilbur, Queen Mary and Westfield College, UK and Kate Finn, SRI International Panelists: Garry Beirne, University of Toronto; Jon Crowcroft, University College London; J. Robert Ensor, AT&T Bell Laboratories; John Tang, Sun Microsystems Laboratories, Inc. *=* SESSION 8A *=* Video Servers Chair: Mon-Song Chen, IBM Research Center Support For Fully Interactive Playout In Disk-Array-Based Video Server, M.-S. Chen, D. Kandlur, and P. Yu, IBM Research Center Distributed Parallel Data Storage Systems: A Scalable Approach to High Speed Image Servers B. Tierney, J. Lee, T. Chen, H. Herzog, G. Hoo, G. Jin, and B. Johnston Lawrence Berkeley Laboratory On Multimedia Repositories, Personal Computers, and Hierarchical Storage Systems S. Ghandeharizadeh and C. Shahabi, University of Southern California *=* SESSION 8B *=* Collaboration Chair: Abel Weinrib, Bellcore Hypermedia Conversation Recording to Preserve Informal Artifacts in Realtime Collaboration, T. Imai, K. Yamaguchi, and T. Muranaga, Toshiba, Japan Multipoint Audio and Video Control For Packet-Based Multimedia Conferencing F. Gong, MCNC Information Technologies Argo: A System for Distributed Collaboration H. Gajewska, J. Kistler, M. Manasse, and D. Redell, DEC Systems Research Center *=* PANEL P9 *=* Should the Multimedia Industry be Regulated? A Legal Debate Organizer: Ina Risman, Pillsbury Madison and Sutro Panelists: Maurice Welsh, Pacific Bell Megan Waters Pierson, Pillsbury Madison and Sutro, Kevin R. Sullivan, Keely Dry and Warren *=* SESSION 9A *=* AWARD PAPERS Chair: Domenico Ferrari, University of California at Berkeley Best Student Paper Automatic Presentation of Multimedia Documents Using Relational Grammars L. Weitzman, MIT Media Laboratory and Kent Wittenburg, Bellcore Best Paper The Personal Presence System - A Wide Area Network Resource for the Real Time Composition of Multipoint Multimedia Communications D. Boyer and M. Lukacs, Bellcore *** CLOSING PLENARY SESSION *** Presentation Technology Standards for Multimedia: Production and reproduction as intended by the director. Tomlinson Holman, Corporate Technical Director, LucasFilm A great many competing standards exist for multimedia software. An area which is practically overlooked for such standardization could bring greater acceptance of the concept of multi-media to large audiences, and that is standardizing presentation technology from the production house to every house. This talk, intended for artistic directors through hardware design engineers, will highlight a direction for multimedia presentation standards with information both distilled from and expanding beyond the standards of film and television. Tom Holman provides stategic planning and development for the THX Division of LucasFilm Ltd. and plays a leading role in setting technical standards and practices for interchange. He continues to work toward the development of more sophisticated solutions to presenting film and video with high picture and sound quality. His technical contributions are the designs of the THX Sound System, Home THX Audio System and other THX systems. Among his many awards are the SMPTE Eastman Kodak Gold Medal and the Samuel L. Warner Medal for progress in film sound. Holman is also an associate professor at the USC School of Cinema-Television. Multimedia: The Evolution of a New Industry Scott Marden, President & CEO, Philips Media Scott will give his perspective on the emerging multimedia industry. He will identify those components and aspects that are critical, and discuss which ideas will succeed and which will fail. He will give examples and show demonstrations to illustrate his viewpoint. Scott Marden joined Philips Electronics N.V. in 1993 as President and CEO of its software and services unit, Philips Media. Based in New York, he has worldwide responsibility for all Philips' electronic media and multimedia interests. Before joining Philips, he was a senior managing director at Bear, Stearns & Co., Inc. Marden also served as President of the International Publishing Division of CBS, Inc. Mr. Marden's presentation will be followed by closing remarks from the Conference Chair of Multimedia '95. =================****=================****=================****============ COURSES * Introduction from the Courses Chair We are proud to offer you two days of exciting courses by leading experts in their fields. They offer something for everyone. Take an in-depth look at how to effectively use metaphor, graphics or sound in the multimedia interface. Acquire practical knowledge in the use of specific authoring software tools, or insight into advanced techniques and issues relating to multimedia production from start to finish, from people who have actually done these things. Explore current and emerging technology, as well as future trends, in networking, digital libraries, multimedia databases, and more. Learn how to design successful multimedia systems for children, and courses for college students. The list goes on and on! Whether you want to get into a new aspect of multimedia or to learn more about your current field, our team of international experts can meet your needs. Ephraim P. Glinert Courses Chair Level Code: N = Novice, I = Intermedia, A = Advanced FOR MORE INFORMATION on any of the following courses, please send email to Professor Ephraim Glinert at glinert@cs.rpi.edu. * SAP1 Level: N Multimedia Systems and Networks: A Guided Tour Sunday, October 16, Full day Organizer: Milan Milenkovic, IBM Lecturer: Borko Furht, Florida Atlantic University * SAP2 Level: N Graphic Design for Multimedia User Interfaces Sunday, October 16, Full day Organizer: Aaron Marcus, Aaron Marcus and Associates Lecturers: Wolfgang Heidrich and Jay Melican, Aaron Marcus and Associates * SAP3 Level: N Designing Multimedia Environments for Children Sunday, October 16, Full day Organizer: Allison Druin, NYU Lecturer: Cynthia Solomon, Consultant * SA4 Level: N Introduction to Multimedia Computing and Systems Sunday, October 16, AM Half day Organizer and Lecturer: John F. Buford, University of Massachusetts, Lowell. * SA5 Level: I Real-Time Graphical and Acoustical Rendering Sunday, October 16, AM Half day Organizer: Peter Astheimer, Fraunhofer Institute for Computer Graphics Lecturer: Stefan Mueller, Fraunhofer Institute for Computer Graphics * SA6 Level: I Broadband Network Services Architecture Sunday, October 16, AM Half day Organizer and Lecturer: Raif O. Onvural, IBM * SA7 Level: I Systems Issues in Desktop Video-conferencing Sunday, October 16, AM Half day Organizer and Lecturer: Kevin Jeffay, University of North Carolina * SA8 Level: I Intelligent Multimedia Interfaces Sunday, October 16, AM Half day Organizer and Lecturer: Mark T. Maybury, MITRE * SP4 Level: I Multimedia Database Systems Sunday, October 16, PM Half day Organizer and Lecturer: Arif Ghafoor, Purdue University. * SP5 Level: A Singularity Modeling for Abstracting Multimedia Data Sunday, October 16, PM Half day Organizer: Tosiyasu L. Kunii, University of Aizu Lecturer: Yoshihisa Shinagawa, University of Tokyo * SP6 Level: A Multimedia Networking Sunday, October 16, PM Half day Organizer and Lecturer: Aurel A. Lazar, Columbia University * SP7 Level: N Creating Producible Multimedia Sunday, October 16, PM Half day Organizer and Lecturer: James H. Alexander, USWest Marketing Resources * SP8 Level: I Designing Cooperative Hypermedia Systems Sunday, October 16, PM Half day Organizer and Lecturer: Norbert A. Streitz, German National Research Center * MAP1 Level: A Advanced Multimedia Production Monday, October 17, Full day Organizer: Marie Redmond, Trinity College Lecturers: Niall Sweeney, Blaise Smith, Eoin Keith, Trinity College * MAP2 Level: I Auditory Displays: Extending the Interface Monday, October 17, Full day Organizer: Gregory Kramer, Clarity Lecturer: Tom Rettig, Broderbund Software * MA3 Level: I Programming Interactive Image, Sound, and QuickTime Stacks in HyperCard Monday, October 17, AM Half day Organizer and Lecturer: Stephen Wilson, San Francisco State University * MA4 Level: I Using Metaphor Effectively in Multimedia Interface Design Monday, October 17, AM Half day Organizer and Lecturer: Adam Marx, USWest * MA5 Level: I Systematic Analysis and Design of Hypermedia Applications Monday, October 17, AM Half day Organizer: Paolo Paolini, Politecnico di Milano Lecturer: Franca Garzotto, Politecnico di Milano * MA6 Level: N Design and Use of Digital Libraries Monday, October 17, AM Half day Organizer and Lecturer: Robert M. Akscyn, Knowledge Systems Inc. * MA7 Level: N Game Design for Marketing and Training Monday, October 17, AM Half day Organizer: Paul Drexler, InterWorks, Inc. Lecturer: Julie Marsh, InterWorks, Inc. * MA8 Level: I Declarative Visual Programming Languages Monday, October 17 AM Half day Organizer and Lecturer: Margaret M. Burnett, Oregon State University * MP3 Level: N Introduction to HyTime Monday, October 17, PM Half day Organizer and Lecturer: Lloyd Rutledge, University of Massachusetts, Lowell * MP4 Level: N Electronic and Network Publishing for the Electronic Arts (a creator's guide to the electronic frontier) Monday, October 17, PM Half day Organizer and Lecturer: Paul Brown, FineArt Forum * MP5 Level: N Legal Strategies for Owners of Computer-Based Property Monday, October 17, PM Half day Organizer: Curtis E. A. Karnow, Landels, Ripley and Diamond Lecturer: Howard A. Simon, Landels, Ripley and Diamond * MP6 Level: A Indexing Multimedia Databases Monday, October 17, PM Half day Organizer and Lecturer: Christos Faloutsos, University of Maryland * MP7 Level: N Image Compression Standards and Architectures Monday, October 17, PM Half day Organizer: Konstantinos Konstantinides, Hewlett Packard Laboratories Lecturer: Vasudev Bhaskaran, Hewlett Packard Laboratories * MP8 Level: I Designing a Senior Level or Graduate Course in Interactive Multimedia Monday, October 17, PM Half day vm Organizer: Rachelle Heller, George Washington University Lecturer: Linda Kieffer, Eastern Washington University =================****=================****=================****============ CONFERENCE REGISTRATION FORM ACM Multimedia'94 Hyatt Regency, San Francisco October 16_20, 1994 Please type or print clearly. Full Name ______________________________________________________ Title ______________________________________________________ E-Mail ______________________________________________________ Organization or Affiliation ________________________________________ Dept. or M/S ______________________________________________________ Address ______________________________________________________ City State/Province ________________________________________________ Zip/Postal Code ___________________________________________________ Country ______________________________________________________ Telephone ______________________________________________________ Fax ______________________________________________________ ACM or SIG MM Member No. IEEE Com Soc Member No. ___________________ You must fill in your member No. above to qualify for member rates. ------------------------------------------------------------------------------- Member Non Member Student By After By After Courses 9/15/94 9/15/94 9/15/94 9/15/94 One Half Day Course $_______ $220 $245 $265 $290 $175 Two Half Day Courses$_______ $385 $430 $465 $510 $300 (or One Full Day) Three Half Day Courses$_____ $550 $615 $665 $730 $425 (or One Full Day & One Half Day) Four Half Day Courses$_____ $715 $800 $865 $930 $550 (or Two Full Days) (You must indicate course selections on the reverse side of this form) Conference Only $______ $325 $395 $425 $495 $195 Exhibits Only* $______ $25 $25 $25 $25 $25 Reception* $______ $25 $25 $25 $25 $25 Conference Videotape$______ $20 $20 $20 $20 $20 Total Amount Enclosed$___________ *Complimentary when signing up for the conference. ------------------------------------------------------------------------------- PAYMENT OPTIONS: Mail this form with payment or a purchase order to Multimedia '94, Danieli & O'Keefe Associates, Inc., 490 Boston Post Rd, Sudbury, MA 01776 or fax, with credit card information or a copy of a purchase order to 508-443-4715. Forms will not be processed without full payment. Make checks or POs payable to: Multimedia '94 or fill in your credit card information below. ___ AMEX ___ MC/VISA ___ Diners Club Card Number _______________ Exp. Date ______________ Name as it appears on card _________________________ Cardholder's Signature _____________________________ Please note: The charge will be billed under Danieli & O'Keefe Associates, Inc. Cancellation Policy: Confirmed Registrants who cannot attend are entitled to a refund of paid fees less a $50 processing fee if a written request is received by us on or before October 1. After October 1, there are no refunds. Substitutions are welcome. For more information, call 800-524-1851 (in USA and Canada only) or 508-443-3330. COURSE SELECTIONS Please check those courses you plan to attend. Full Day Courses Sunday ___ SAP1 Multimedia Systems and Networks: A Guided Tour ___ SAP2 Graphic Design for Multimedia User Interfaces ___ SAP3 Designing Multimedia Environments for Children Monday ___ MAP1 Advanced Multimedia Production ___ MAP2 Auditory Displays: Extending the Interface Half Day Courses Sunday AM ___ SA4 Introduction to Multimedia Computing and Systems ___ SA5 Real-time Graphical and Acoustical Rendering ___ SA6 Broadband Network Services Architecture ___ SA7 Systems Issues in Desktop Videoconferencing ___ SA8 Intelligent Multimedia Interfaces Sunday PM ___ SP4 Multimedia Database Systems ___ SP5 Singularity Modeling for Abstracting Multimedia Data ___ SP6 Multimedia Networking ___ SP7 Creating Producible Multimedia ___ SP8 Designing Cooperative Hypermedia Systems Monday AM ___ MA3 Programming Interactive Image, Sound and QuickTime Stacks in HyperCard ___ MA4 Using Metaphor Effectively in Multimedia Interface Design ___ MA5 Systematic Analysis and Design of Hypermedia Applications ___ MA6 Design and Use of Digital Libraries ___ MA7 Game Design for Marketing and Training ___ MA8 Declarative Visual Programming Languages Monday PM ___ MP3 Introduction to HyTime ___ MP4 Electronic and Network Publishing for the Electronic Arts ___ MP5 Legal Strategies for Owners of Computer-Based Property. ___ MP6 Indexing Multimedia Databases ___ MP7 Image Compression Standards and Architectures ___ MP8 Designing a Senior Level or Graduate Course in Interactive =================****=================****=================****============ HOTEL AND TRAVEL INFORMATION Hotel Reservations The host hotel for Multimedia '94 is: The Hyatt Regency San Francisco 5 Embarcadero Center San Francisco, CA 94111 415-788-1234 800-233-1234 $136 single or double When you make your hotel reservations, you must mention Multimedia to receive the special conference rate. We recommend you make your reservations before September 14, 1994. After that date, there is no guarantee of room availability or the special Multimedia Conference rate. Guests of the Hyatt Regency San Francisco have access to a health and fitness center, business center and indoor/outdoor tennis courts among other amenities. Additional rooms are being held at: The Holiday Inn Financial District 750 Kearny Street San Francisco, CA 94108 415-433-6600 800-424-8292 $115 single or double You must mention Multimedia to receive the conference rate, and you must make your reservation by September 14 to be assured of availability. Travel Arrangements Birkmayer Travel is offering discounted airfares to Multimedia '94 on Delta and United Airlines. Choose from a 5% discount on supersaver fares (Saturday night stay required), or sharply reduced "zone'' fares (2 day minimum stay, 14 day maximum, no Saturday night required). Here are two examples of the potential savings to San Francisco at the time of writing: From New York City: $568 with a 14 day advance purchase $634 with a 7 day advance purchase (the unrestricted coach fare: $1,448) From Dallas: $398 with a 14 day advance purchase $514 with a 7 day advance purchase (the unrestricted coach fare: $1,092) Discounts apply only to travel within the continental United States or originating in Canada. Please note that all fares are subject to change without notice, and prices are guaranteed only after tickets are actually purchased. Space is limited, and some restrictions apply. Please call Birkmayer directly and mention Multimedia '94 for further information and reservations: 1 (800) 338 5735 (continental U.S. and Canada) 1 (518) 272 2650 (New York State and non-US) 1 (518) 272 7257 (fax) Hours: 9:00am - 5:00pm EDT, Monday-Friday or call Delta at 1-800-338-5735 and refer to file #I3293 Birkmayer has also arranged special discounted rates with AVIS for those attendees who wish to rent a car. To make reservations, just call AVIS at: 1 (800) 331 1600 (continental U.S. and Canada) 1 (918) 664 9600 (non -US) 1 (918) 621 4814 (fax) and mention MULTIMEDIA'94 AWD# B347628. Airport transporation Both the Hyatt Regency and the Holiday Inn are about 20 minutes from the airport. Taxi service costs approximately $30. SFO Airporter shuttles leave the airport every 10-20 min, with service to the Hyatt. For more information on the SFO Airporter, call 415-495-8404. More information on ground transportation will be sent with your confirmation letter. =================****=================****=================****============ CONFERENCE COMMITTEE CO-CHAIRS M. Blattner, Lawrence Livermore National Laboratory and University of California, Davis J. O. Limb, Georgia Institute of Technology, Atlanta ADVISORY COMMITTEE E. Fox, Virginia Polytechnic Institute and SU TREASURER R. B. Allen, Bellcore PROCEEDINGS J. J. Garcia-Luna, University of California, Santa Cruz WORKSHOPS S. Wilbur, Queen Mary & Westfield College, UK DEMONSTRATIONS T. Little, Boston University VIDEO M. Brown, Digital Equipment Corporation D. Redell, Digital Equipment Corporation ELECTRONIC PUBLISHING R. Rada, University of Liverpool, UK PANELS A. Kuchinsky, Hewlett-Packard S. Bulick, US WEST Technologies COURSES E. P. Glinert, Rensselaer Polytechnic Institute D. McIntyre, Morgan, Stanley & Co. K. Wittenburg, Bell Communications Research, LOCAL ARRANGEMENTS J. D. Smith, Lawrence Livermore National Laboratory PUBLICITY G. Parulkar, Washington University in St. Louis EXHIBITS P. Mantey, University of California, Santa Cruz AUDIO/VISUAL N. Johnston, Lawrence Berkeley Laboratory UBIQUITOUS ART ZONE Beverly Reiser PROGRAM COMMITTEE Chair D. Ferrari, University of California, Berkeley CO-CHAIRS S. Ahuja, AT&T Bell Laboratories F. Kitson, Hewlett-Packard T. Kunii, University of Aizu, Japan R. Phillips, Los Alamos National Laboratory R. Rada, University of Liverpool, UK R. Sacks-Davis, the Royal Melbourne Institute of Technology. =================****=================****=================****============ MESSAGE FROM THE CONFERENCE CO-CHAIRS We are witnessing the birth of a new epoch, an epoch in which multimedia will rule as the medium of expression. Multimedia will make the world a very different place in 25 years, and will bring with it a revolution in communication as great as that of the invention of the printing press. Multimedia provides the ability not only to see, but to hear and manipulate virtual objects in the computer interface. Gesture, eye contact, and speech allow us to communicate in natural ways that have evolved over millions of years, but until now electronic media has furnished very poor analogs of these interactions. Now we are developing the ability to use the subtleties of drama in exposition, on one hand, and the flexibility of creating group interactions that may one day be more powerful than face-to-face interactions on the other. These new modalities and interactivity comprise the significant difference between multimedia interfaces and other types of computer displays. Rarely can we pinpoint the creation of a new discipline so clearly. The same sense of excitement was felt in the late 50's when logic, mathematics, electrical engineering, and linguistics suddenly merged to create something the world had never seen before: a theory and a foundation for computer science. Over the past five years, we have witnessed something similar: the merging of graphics, text processing, video, audio, hardware, software, communications and other computer-related disciplines. This merging has resulted in the creation of a new technology, and it is called Multimedia. Multimedia has many parents and siblings: nine ACM Special Interest Groups (SIGs) have sponsored this conference to show their involvement and interest in this new arena, with the cooperation of five more ACM SIGs and the IEEE Communications Society. The sense of wonder and excitement is even greater now than when computer science was born. We thought the future of computers was in science, engineering, and business applications. But the future of multimedia lies in everything we see around us: science and engineering, education, digital libraries, home entertainment, arts, medicine, business, aids for the disabled, and more. ACM Multimedia came into existence in 1993, "midwived," so to speak, by SIGGRAPH, and this year is taking place in the nurturing environment of San Francisco, where an estimated 500 companies located in the greater Bay area are involved in the support and development of multimedia products. The world has already seen a financial investment of many billions of dollars in the creation of multimedia products, investments, and sales. We look at this infant technology and ask, "Who does it look like?" And, "What will it grow up to be?" We are here to examine some of these questions. Multimedia '94 will give you the opportunity to sample the advances that have taken place in the last year. Through the courses you can quickly get up to speed in a large number of areas. You can also explore the technical depths in two parallel tracks of sessions. One track will focus on content creation and will be capped by a multimedia arts night featuring the work of over 20 artists. A separate track of panels will enable you to hear experts debate key issues facing the fledgling industry, including legal, technical, and business issues, as well as the concerns of the content creators. Exhibitor presentations will provide more product detail and background. The "piece de resistance" will be the opening and closing plenaries. In the opening plenary, a panel of industry leaders will help establish focus for the overall conference by debating a number of key issues relating to the next directions of our infant industry. What will be the primary path to new information services? Will the greatest opportunities be found in the business environment or in the home? If you have a question that you would like to see addressed, please forward it to us. The closing plenary will consist of a multimedia presentation that will attempt to provide some clues to where the industry is headed. Come meet us at Multimedia '94, and enjoy the diversity that is at the heart of multimedia and the flourish that contributes to the excitement of our growing industry. Meera Blattner John Limb General Co-Chairs =================****=================****=================****============ FOR MORE INFORMATION To receive more information about Multimedia'94 or the Advance Program, contact Danieli and O'Keefe (DOK), our conference management company. Address Danieli and O'Keefe 490 Boston Post Road Sudbury, MA 01776-9898 Phone numbers 800-524-1851, or 508-443-3330, Ext. 1214 Email multimedia.dok@notes.compuserve.com or ACMHELP@ACM.org =================****=================****=================****============ Received: by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA02064; Tue, 17 May 1994 17:16:27 +0600 Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA02060; Tue, 17 May 1994 17:16:25 +0600 Received: from zephyr.isi.edu by cray.com (Bob mailer 1.2) id AA01284; Tue, 17 May 94 17:16:19 CDT Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 17 May 1994 15:15:35 -0700 Date: Tue, 17 May 1994 15:15:35 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199405172215.AA04445@zephyr.isi.edu> To: braden@ISI.EDU, rstevens@noao.edu, skibo@florida.wpd.sgi.com, dab@berserkly.cray.com Subject: Re: window scale option and urgent pointer Cc: tcplw@cray.com Content-Length: 70 Dave, Nice, cogent explanation! "Egad, Watson, elementary!" Bob Received: by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA28934; Tue, 17 May 1994 16:48:39 +0600 Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA28930; Tue, 17 May 1994 16:48:37 +0600 Received: from frenzy.cray.com (frenzy-eth.cray.com) by cray.com (Bob mailer 1.2) id AA29113; Tue, 17 May 94 16:48:34 CDT Received: by frenzy.cray.com id AA04567; 4.1/CRI-5.6; Tue, 17 May 94 16:50:32 CDT Date: Tue, 17 May 94 16:50:32 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9405172150.AA04567@frenzy.cray.com> To: braden@ISI.EDU, rstevens@noao.edu, skibo@florida.wpd.sgi.com Subject: Re: window scale option and urgent pointer Cc: tcplw@cray.com Content-Length: 2651 The question of how does the urgent pointer interact with expanded windows has been brought up in some private email. I'm sending my reply to the tcplw@cray.com mailing list, so that a wider audience can comment on what I am going to say. I've discussed this issue before, but I don't remember in what context and with whom I had the discussion. Problem: What do you do when an Urgent Pointer cannot be accuratly reflected with the 16 bit offset field in the TCP header? First, this is not specific to expanded windows. What do you do if the application writes over 64K of data which has not yet been sent to the other side, and then wants to set an Urgent Pointer? It's the same problem. I will use the term "Urgent Pointer" to mean the sequence number of the urgent pointer, and "Urgent Offset" to mean the 16 bit value in the TCP header. Normally, Seq# + Urgent Offset = Urgent Pointer. The key thing to realize is that once you receive a packet with the URG bit, you go into urgent mode, and you stay in urgent mode, until you get to the Urgent Pointer. While in urgent mode, there can only be one Urgent Pointer, so if a TCP packet arrives with an Urgent Offset that indicates a new Urgent Pointer (i.e., later in the sequence space), then that new value is the Urgent Pointer, and the old value is forgotten. The next thing to realize is that the maximum amount of data that you can have in a single TCP packet is 65495 (64K-1 minus IP & TCP headers) bytes of data, and the maximum Urgent Offset is 65535. This means that for any given packet, you can *always* set the Urgent Offset (and thus the Urgent Pointer) beyond the end of the data that is contained in that packet. So, if the Urgent pointer is beyond what can be reflected in the 16 Urgent Offset field in the TCP header, then you set the URG bit and put 65535 into that field. Each successive packet that is sent will have the URG flag set, and the Urgent Offset will keep pointing beyond to data that has not yet been received. Eventually you'll get within 16 bits of the Urgent Pointer, and the Urgent Offset will now be the correct value (which may still be beyond the data in any given packet), and will keep shrinking as new data is sent, until you finally send the data that actually has the urgent pointer, and the urgent offset will then, and only then, finally point at data within the packet, and the TCP can finally go out of urgent mode. In effect, each packet is saying "There is more urgent data beyond this packet". Seems like a nice simple solution, so perhaps that is a good indication that it is the right answer. :-) -David Borman, dab@cray.com Received: by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA19837; Tue, 17 May 1994 11:07:05 +0600 Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA19833; Tue, 17 May 1994 11:07:03 +0600 Received: from acl.lanl.gov by cray.com (Bob mailer 1.2) id AA04389; Tue, 17 May 94 11:06:49 CDT Received: from doneyet.acl.lanl.gov (doneyet.acl.lanl.gov [128.165.148.58]) by acl.lanl.gov (8.6.8.1/8.6.4) with ESMTP id KAA15957; Tue, 17 May 1994 10:06:45 -0600 From: "Stephen C. Pope" Received: (scp@localhost) by doneyet.acl.lanl.gov (8.6.8.1/8.6.4) id KAA07097; Tue, 17 May 1994 10:06:44 -0600 Date: Tue, 17 May 1994 10:06:44 -0600 Message-Id: <199405171606.KAA07097@doneyet.acl.lanl.gov> To: swise@austin.ibm.com (Stevo Bevo-Devo Wise) Cc: tcplw@cray.com Subject: Congestion window & slow start threshold calculation In-Reply-To: <9405171504.AA24205@vikings.austin.ibm.com> References: <9405171504.AA24205@vikings.austin.ibm.com> Reply-To: "Stephen C. Pope" Content-Length: 1483 Stevo> I have a question about computing these two values when using RFC1323. Stevo> I'm using BSD43 Reno base code, and I notice that in tcp_mss() they Stevo> compute the congestion window and slow start threshold based on the Stevo> MSS. Stevo> Question: Should this be changed to compute these values based on the Stevo> datasize (MSS less any protocol options included in each segment)? Looks like SunOS (or at least my altered copy of it ;-) uses maxseg (which is your "datasize"), not mss. Unicos does not make the distinction, instead decrementing the packet data length for the TCP options length at the last moment of packet generation, so MSS is used for all buffer/window size calculations. When distinguishing between MSS and datasize (say, for determination of send/receive buffer sizes and such), and given you know that TSopt will be used (assumed predicate to making datasize < MSS), I suppose you could go ahead and use datasize for cwnd and slow start... But then, what do I know? Of course, the problem with these different implementations is that you get some nasty fringe effects when a receiver advertises windows based on datasize but the sender eyes the advertisement from an mss point of view; the last segment sent in a given window may come up 12-16 bytes short of what it could have been, spelling disaster for receivers with penalties for not being a multiple of some magic number such as pagesize (ibm, hp, sgi) or stripe size (cm5). stephen. Received: by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA12057; Tue, 17 May 1994 10:04:44 +0600 Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv) id AA12022; Tue, 17 May 1994 10:04:39 +0600 Received: from netmail1.austin.ibm.com by cray.com (Bob mailer 1.2) id AA28891; Tue, 17 May 94 10:04:34 CDT Received: from vikings.austin.ibm.com by netmail1.austin.ibm.com (AIX 3.2/UCB 5.64/gw-1.9) for tcplw@cray.com at cray.com id AA16751; Tue, 17 May 1994 10:04:26 -0500 Received: by vikings.austin.ibm.com (AIX 3.2/UCB 5.64/4.03-client-2.4) for tcplw@cray.com at austin.ibm.com; id AA24205; Tue, 17 May 1994 10:04:24 -0500 From: swise@austin.ibm.com (Stevo Bevo-Devo Wise) Message-Id: <9405171504.AA24205@vikings.austin.ibm.com> To: tcplw@cray.com Subject: Congestion window & slow start threshold calculation Date: Tue, 17 May 94 10:04:24 -0600 Content-Length: 493 I have a question about computing these two values when using RFC1323. I'm using BSD43 Reno base code, and I notice that in tcp_mss() they compute the congestion window and slow start threshold based on the MSS. Question: Should this be changed to compute these values based on the datasize (MSS less any protocol options included in each segment)? Thanx in advance... ******** Steve Wise IBM RISC System/6000 Division - Austin, TX. Internet: swise@austin.ibm.com VNET: AUSTIN(SWISE) Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv) id AA16831; Sun, 1 May 1994 15:33:24 +0600 Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv) id AA16825; Sun, 1 May 1994 15:33:20 +0600 Received: from chipcom.com by cray.com (Bob mailer 1.2) id AA19289; Sun, 1 May 94 15:33:18 CDT Received: from atmguru.stealth ([151.104.20.62]) by chipcom.com (4.1/SMI-4.0) id AA11578; Sun, 1 May 94 16:32:15 EDT Received: by atmguru.stealth (4.1/SMI-4.1) id AA04138; Sun, 1 May 94 16:32:47 EDT Date: Sun, 1 May 94 16:32:47 EDT From: abovopou@chipcom.com (Andreas Bovopoulos) Message-Id: <9405012032.AA04138@atmguru.stealth> To: confctrl-request@isi.edu, rem-conf-request@es.net, rsvp-request@isi.edu, tcplw@cray.com Subject: subscribe Content-Length: 254 Hi, Could you please add my name in the mailing list? Thank you very much Dr. Andreas D. Bovopoulos Principal Engineer Chipcom Corporation 118 Turnpike Road Southborough, MA 01772-1886 tel:(508) 490-5602 fax:(508) 490-5873 e-mail:abovopou@chipcom.com Received: by hemlock.cray.com id AA02997; 4.1/CRI-5.6; Tue, 14 Dec 93 13:10:12 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA02988; 4.1/CRI-5.6; Tue, 14 Dec 93 13:09:59 CST Received: from maxstrat.com ([156.151.254.254]) by cray.com (Bob mailer 1.2) id AA17208; Tue, 14 Dec 93 13:09:52 CST Received: by maxstrat.com (920330.SGI/1.34) id AA11480; Tue, 14 Dec 93 11:29:04 -0800 Date: Tue, 14 Dec 93 11:29:04 -0800 From: ron@maxstrat.com (Ron Lee) Message-Id: <9312141929.AA11480@maxstrat.com> Apparently-To: tcplw@cray.com index Received: by hemlock.cray.com id AA16905; 4.1/CRI-5.6; Fri, 5 Nov 93 12:42:34 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA16898; 4.1/CRI-5.6; Fri, 5 Nov 93 12:42:26 CST Received: from zephyr.isi.edu by cray.com (Bob mailer 1.0) id AA23545; Fri, 5 Nov 93 12:42:24 CST Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Fri, 5 Nov 1993 10:42:22 -0800 Date: Fri, 5 Nov 1993 10:42:22 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199311051842.AA14334@zephyr.isi.edu> To: dab@cray.com Subject: NTCP draft #1 Cc: end2end-interest@ISI.EDU, tcplw@cray.com Dave, I have a few minor suggestions on your draft proposal for a new TCP version. 1. You really ought to give the Boys From Arizona explicit credit for suggesting most of the changes you are making. 2. You need to say something about the cost of doubling the TCP header length. Presumably VJ header compression would be modified for NTCP over slow links... but you should check into whether the NTCP header can be compressed as much and as easily as the present one. 3. Your definition of MSS is exactly 20 larger than the current definition, I believe. Your definition is certainly more logical than the current one, but it may be helpful to point out the constant offset. Bob Received: by hemlock.cray.com id AA13763; 4.1/CRI-5.6; Mon, 20 Sep 93 00:33:56 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13759; 4.1/CRI-5.6; Mon, 20 Sep 93 00:33:53 CDT Received: from brahma.trl.OZ.AU by cray.com (4.1/CRI-MX 2.19) id AA28432; Mon, 20 Sep 93 00:33:13 CDT Received: from [137.147.13.75] (arethusa.trl.OZ.AU) by brahma.trl.OZ.AU with SMTP id AA13205 (5.65c/IDA-1.4.4 for ); Mon, 20 Sep 1993 15:28:02 +1000 Date: Mon, 20 Sep 1993 15:28:02 +1000 Message-Id: <199309200528.AA13205@brahma.trl.OZ.AU> To: tcplw@cray.com From: c.oneill@trl.oz.au (Chris O'Neill) Subject: Re: slow start and large windows Sean O'Malley in the original article of this thread stated that: >Thus the time it takes (the congestion control algorithm of >TCP)to reach the original congestion window is: > > (log2(n/2) + n/2) * the round trip time(RTT) > where n = window size/maximum segment size(MSS) > >Where n is large this algorithm will take a great deal of >time to achieve the original window after a dropped packet. I believe that most of the replies to this article so far have not given attention to what is often the most important term in the above expression, i.e. (n/2) * the round trip time (RTT) so even though the Reno version of the algorithm avoids the slow start, it does not avoid the congestion avoidance phase which leads to the above term. This is not necessarily a problem, of course, because the throughput and the window are not the same thing. Their relationship to each other depends on the sizes of the delay-bandwidth product and the buffer at the bottleneck (as Shenker, Zhang and Clark illustrate in 'Some Observations on the Dynamics of a Congestion Control Algorithm' in Computer Communications Review, Oct 1990). For example, if the buffer is larger than the (round trip delay)-bandwidth product, then full throughput is still achieved even with the window at half maximum size. As the window is gradually increased, this simply leads to an increase in the number of packets in the buffer, without affecting throughput. However, if the bottleneck buffer is smaller than the (round trip delay)-bandwidth product then throughput will be reduced when the window size is at half maximum size. If the buffer is small compared with the delay-bandwidth product then the throughput will be just over half of the bottleneck speed. The throughput will slowly rise with the window size and take the time given in the above expression to reach the full bottleneck speed. The Reno version of the algorithm, just like the Tahoe version, does not avoid this problem (as far as I know). Also, at the beginning of a transmission, if the bottleneck buffer is relatively small then slow start will only get the window up to a relatively small value (with either Tahoe or Reno, I believe) and either version then takes a long time to get the window and throughput up to substantial values. Hence I believe the Reno version does have its performance limitations in cases where the bottleneck buffer size is significantly smaller than the (round trip delay)-bandwidth product. Chris O'Neill Telecom Australia Research Labs Received: by hemlock.cray.com id AA08715; 4.1/CRI-5.6; Tue, 27 Jul 93 13:54:56 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA08711; 4.1/CRI-5.6; Tue, 27 Jul 93 13:54:53 CDT Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19) id AA15875; Tue, 27 Jul 93 13:54:51 CDT Received: by frenzy.cray.com id AA05161; 4.1/CRI-5.6; Tue, 27 Jul 93 13:55:45 CDT Date: Tue, 27 Jul 93 13:55:45 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9307271855.AA05161@frenzy.cray.com> To: tcplw@cray.com Subject: 1323 implementations I had an action item from the TCPLW WG meeting in Amsterdam to update the list of implementations of the TCP Extensions in RFC 1323. Attached is what I have currently, based on the survey that I did last December. If your implementation is not here, please send me the relevent information. If you have updated information on your implementation, please send me that information also. Thanks. -David Borman, dab@cray.com ---------- TCP extensions implementations as of 12/18/92 Cray Research, Inc Product: Unicos Window Scale Timestamps w/ RTT caluculations (7.0 & later) PAWS (7.0 and later) Obsolete Echo and Echo Reply (6.0 & 6.1) Status: Supported Product Availability: Mods available for UNICOS 6.0 Unicos 6.1, 7.0, 7.C Tested with: Van Jacobson's code and many others (see below) Caveats/Problems: The 6.0 and 6.1 versions do not support Timestamps, RTT calculations or PAWS. They use the obsoleted Echo and Echo Reply options defined in RFC 1072. The 7.0 and 7.C versions will send both a Timestamp and an Echo option in SYN packets. SYN/ACK packets will contain either a Timestamp or an Echo, but not both, depending on what was received in the SYN packet. Support for the Echo/Echo Reply options will go away in a future release. The window scale must be set with an explicit setsockopt() call, and the use of Timestamps is tied to the Window Scale option. If a Window Scale is received in a SYN packet, and the application hasn't specified otherwise, the Window Scale is automatically turned around in the SYN/ACK with the same value. 6.1 has no applications (other than nettest) that take advantage of expanded windows. Ftp and ftpd are the only additional applications that have been enhanced in 7.0 and 7.C to use expanded windows. Contact: David Borman, dab@cray.com Interlink Computer Sciences Product: SNSTCP/access 1.0.1 Window Scale Timestamps PAWS Status: Supported Product Availability: PTF MP10497 or PTF MP10498 for 1.1 Tested with: Cray UNICOS Caveats/Problems: The code is enabled for port 21 and other ports if they specify > 64k of buffer space. Some implementations do not like this option and fail. We provide a patch to turn off this option for all cases. Contact: Fred Bohle, fab@interlink.com (301)-317-6600 Silicon Graphics, Inc Product: a future release of IRIX Window Scale Timestamps w/ RTT calculations PAWS Status: Supported Product Availability: "Real Soon Now" (probably spring '93) Tested with: Cray UNICOS Caveats/Problems: Time-stamps are tied to window scaling and window scaling options will only be used on connections when a send or receive buffer is explicitely set to >64K. All other connections will not use any of the options. Old style (RFC 1072) echo/echo-reply options will be ignored. Only the RFC 1323 combined time-stamp/reply option is supported. Contact: Thomas Skibo, skibo@sgi.com University of Illinois Product: Patch to 4.3BSD Net-2 release Window Scale Timestamps w/ RTT calculations PAWS Status: Experimental/research/prototype Availability: Anonymous ftp from uxc.cso.uiuc.edu:/pub/tcplw.shar.Z Tested with: Cray UNICOS Caveats/Problems: Protocol control blocks are held in mbuf clusters. This is very inefficient. Should probably use kmem_alloc() to allocate pcbs. There are problems with handling of options when a socket in TIME_WAIT gets a new connection request (i.e. the other side is using SOREUSEADDR). This can cause the window scaling options to be ignored in those cases. FINs aren't taken into account when deciding to update TS.recent (for the echo reply). A fix for this is mentioned in the README file with the patch. The PAWS check shouldn't drop segments when ts_recent is zero (i.e. invalid). Contact: Thomas Skibo, skibo@sgi.com Sandia National Laboratories Contact: Doug Brown, cdbrown@sandia.gov (505)845-8699 Product: Patch to SunOS 4.1.1, 4.1.2 Window Scale Timestamps w/ RTT calculations PAWS Status: Experimental/research/prototype Availability: Contact cdbrown@sandia.gov for availability Caveats/Problems: For window sizes above approx 160K bytes, the throughput drops off noticably. I suspect some kind of memory management problems in SunOS, but don't know for sure. Tested with: Cray UNICOS 6.0 (Window Scaling only) Information Sciences Institute (ISI) Contact: Bob Braden & Liming Wei, braden@isi.edu & lwei@isi.ed Product: Patch to Sun OS 4.1 Window Scale Timestamps w/ RTT calculations PAWS Status: Contact braden@isi.edu or lwei@isi.ed Sun Microsystems Computer Corporations Contact: Jim Fiori, jim.fiori@east.sun.com Product: SunOS 4.1.X Window Scale Timestamps w/ RTT calculations PAWS Status: Product, available for purchase Availability: This is available as a Sun Consulting Special. These are software specials that are purchased on an "as-is" basis. For more information contact your Sun sales rep. The name of the product is CONSULT-TCPLFN. Caveats/Problems: The timestamps/PAWS must be turned on per application via setsockopt calls. The large windows can be turned on per application via setsockopt calls. There are new options for both. In addition, the default send and receive space (kernel variables) can be set to use the large windows. Received: from berserkly.cray.com by hemlock.cray.com id AA21390; 4.1/CRI-5.6; Wed, 21 Jul 93 12:36:27 CDT Received: by berserkly.cray.com id AA11105; 5.64/CRI-4.9; Wed, 21 Jul 93 12:36:11 -0500 Received: by berserkly.cray.com id AA11100; 5.64/CRI-4.9; Wed, 21 Jul 93 12:36:02 -0500 Date: Wed, 21 Jul 93 12:36:02 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9307211736.AA11100@berserkly.cray.com> To: braden@ISI.EDU Subject: Re: TCPLW WG minutes Cc: mankin@cmf.nrl.navy.mil, tcplw@cray.com Bob, > I believe I was also given an action item to publish > draft-ietf-tcplw-extensions-00.txt as an RFC, after adding to it the > Borman bug that led to the change in the rule for updating TSrecent. Right you are. Here's the text that I will add to the minutes: o Bob Braden will update draft-ietf-tcplw-extensions-00.txt to include an updated description of which TS to echo to explain the bug as described above, and then it will be published as an informational RFC. -David Borman, dab@cray.com Received: by hemlock.cray.com id AA16475; 4.1/CRI-5.6; Wed, 21 Jul 93 11:02:39 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA16471; 4.1/CRI-5.6; Wed, 21 Jul 93 11:02:35 CDT Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.19) id AA05721; Wed, 21 Jul 93 11:02:32 CDT Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Wed, 21 Jul 1993 09:01:46 -0700 Date: Wed, 21 Jul 1993 09:01:46 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307211601.AA08606@zephyr.isi.edu> To: minutes@cnri.reston.va.us, dab@berserkly.cray.com Subject: Re: TCPLW WG minutes Cc: mankin@cmf.nrl.navy.mil, tcplw@cray.com *> *> *> Action Items *> ------------ *> o Bob Braden will update RFC 1323 with the changes that are *> described in draft-ietf-tcplw-extensions-00.txt. The new *> document will be sent to the mailing list for final review, *> and then sent to the IESG for consideration for advancement *> to Draft status. I believe I was also given an action item to publish draft-ietf-tcplw-extensions-00.txt as an RFC, after adding to it the Borman bug that led to the change in the rule for updating TSrecent. *> *> o David Borman will send out the current list of implementations, *> so that people can send in updates. The updated list will be *> given to the IESG at the same time as the updated version of *> RFC 1323. *> *> Mailing list Archives *> --------------------- *> Archives of the mailing list can be accessed by using telnet *> to host berserkly.cray.com (128.162.96.70), port 23000. *> Received: by hemlock.cray.com id AA15888; 4.1/CRI-5.6; Wed, 21 Jul 93 10:54:01 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA15884; 4.1/CRI-5.6; Wed, 21 Jul 93 10:53:57 CDT Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19) id AA04675; Wed, 21 Jul 93 10:53:51 CDT Received: by frenzy.cray.com id AA00917; 4.1/CRI-5.6; Wed, 21 Jul 93 10:54:30 CDT Date: Wed, 21 Jul 93 10:54:30 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9307211554.AA00917@frenzy.cray.com> To: minutes@cnri.reston.va.us Subject: TCPLW WG minutes Cc: mankin@cmf.nrl.navy.mil, tcplw@cray.com Attached is the first draft of the minutes of the TCP LW working group meeting from the Amsterdam IETF meeting. If anyone has corrections that should be made, please let me know ASAP, so that I can get the revision done before the deadline for submitting WG minutes (the end of next week). If there are no changes, these will be the final version. -David Borman, dab@cray.com --------- Cut Here ----------- TCP Large Windows Working Group ------------------------------- Summary reported by David Borman, WG Chair. The TCP Large Windows Working Group met on Wednesday, July 14 at the 27th IETF meeting in Amsterdam. The agenda consisted of: o Review of draft-ietf-tcplw-extensions-00.txt o Consideration of advancing RFC 1323 to Draft o Status of SACK option? The document draft-ietf-tcplw-extensions-00.txt is a compilation of bugs and clarification that need to be made to RFC 1323. It was compiled by Bob Braden. Bob and David Borman led a walk through of the document, to help explain it and to find out if any other changes that are needed to RFC 1323 were missed. RTTM: Relationship to Karn's Algorithm -------------------------------------- One of the items that Karn's Algorithm addresses is how to get valid RTT values in the presence of lost data. With current methods, the answer is that whenever data has to be retransmitted, no valid RTT estimate can be made in that window. The reason for this is that when the ACK is received, it can not be determined whether that ACK came from the original packet or the retransmitted packet. With the use of the Timestamps option, this ambiguity is removed, since the timestamp echoed in the ACK will always be from the data packet that caused the ACK of new data to be generated. The other part of Karn's Algorithm, that of doing exponential back-off on retransmissions, still needs to be done. RTTM: Which TS to Echo ---------------------- (Note: The discussion given during the WG was a bit muddled. This summary provides the clearer explanation...) This is the one real bug in RFC 1323. As stated currently, the TSval is only copied to TS.Recent when a packet is received that advances the left edge of the window. The change allows the TSval to be copied when the left edge of the window is advanced, or if the packet is before the left edge of the window and it has a newer timestamp. The scenario that this addresses is when a packet is sent, its ack is lost, and so the packet is then resent. The second packet will not advance the left edge of the window, but will cause a duplicate ack to be generated. To the sender, this will be the first ack that is received, so it will want to use the timestamp in that packet to update the RTT estimate. If the TSval is not copied from the resent packet, the the sender will get an inflated RTT estimate. By making this change, with the use of timestamps for doing RTT measurements it can be guaranteed that in the worst case at least one RTT measurement can be made per window. Without the timestamps option, in many TCP implementations one RTT estimate per window is the best case. Additionally, this change fixes a problem with a long-lived unidirectional connection. Since all the acks will have the same sequence number, they would never cause TS.Recent to be updated. With this change, the string of ack-only packets will cause TS.Recent to be kept up-to-date, and allow PAWS to work properly. TCP Options and MSS ------------------- The discussion of how the TCP MSS option interacts with the presence of TCP and/or IP options needed some clarification. Since many TCP implementations us the MSS option to indicate how large of a packet can be received without fragmentation, and the MSS does not include the TCP/IP headers, the question is should it also be adjusted for the length of the options that will probably be in each packet? The answer is no, and when sending data the sender should always assume that the MSS that was received did not account for the TCP and IP options, so the MSS should be reduced by the length of the TCP and IP options when determining how much data can be sent. The following grid shows why: | MSS is adjusted | MSS is not adjusted | to include options | to include options ----------------+-----------------------+-------------------- Sender adjusts | packets are too | packets are the length for | short | correct length options | | ----------------+-----------------------+-------------------- Sender doesn't | packets are the | packets are too adjust length | correct length | long. for options | | The goal is to not send IP datagrams that have to be fragmented by IP. Packets sent with the constraints in the lower right of this grid will cause IP fragmentation. The only way to ensure that this doesn't happen is for the data sender to decrease the MSS by the length of the IP and TCP options. Modification to TCP Event Processing Rules ------------------------------------------ The draft document contains a new set of rules for how to process the TCP extensions. Bob wanted feedback on whether or not the format was easy to read and understand. The general feeling was that it was easy to read and understand. SACK ---- There was some discussion of the status of the SACK option. Right now, there is not a lot of visible activity in this area. There are some test implementations of the SACK option as originally defined in RFC-1072. The plan is once there is some hard data on how well it works, then a new draft document will be generated on the SACK option. Action Items ------------ o Bob Braden will update RFC 1323 with the changes that are described in draft-ietf-tcplw-extensions-00.txt. The new document will be sent to the mailing list for final review, and then sent to the IESG for consideration for advancement to Draft status. o David Borman will send out the current list of implementations, so that people can send in updates. The updated list will be given to the IESG at the same time as the updated version of RFC 1323. Mailing list Archives --------------------- Archives of the mailing list can be accessed by using telnet to host berserkly.cray.com (128.162.96.70), port 23000. Received: by hemlock.cray.com id AA25867; 4.1/CRI-5.6; Mon, 28 Jun 93 12:54:27 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA25851; 4.1/CRI-5.6; Mon, 28 Jun 93 12:54:20 CDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by cray.com (4.1/CRI-MX 2.19) id AA05968; Mon, 28 Jun 93 12:54:18 CDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa28153; 28 Jun 93 13:44 EDT To: David Borman Cc: mwalnut@CNRI.Reston.VA.US, braden@isi.edu, mankin@cmf.nrl.navy.mil, tcplw@cray.com Subject: Re: TCPLW & Amsterdam IETF In-Reply-To: Your message of "Thu, 24 Jun 93 20:29:57 CDT." <9306250129.AA16158@berserkly.cray.com> Date: Mon, 28 Jun 93 13:44:29 -0400 From: Megan Davies Walnut Message-Id: <9306281344.aa28153@IETF.CNRI.Reston.VA.US> Great, Thanks Dave, Megan --------- Date: Thu, 24 Jun 93 20:29:57 -0500 From: David Borman Message-Id: <9306250129.AA16158@berserkly.cray.com> To: dab@berserkly.cray.com, mwalnut@CNRI.Reston.VA.US Subject: Re: TCPLW & Amsterdam IETF Cc: braden@isi.edu, mankin@cmf.nrl.navy.mil, tcplw@cray.com > How does 1600-1800 on Wednesday sound? Sounds good to me. I haven't heard any other objections, so I'll plan for the TCP Large Windows WG to meet then. -David Borman, dab@cray.com Received: from berserkly.cray.com by hemlock.cray.com id AA12804; 4.1/CRI-5.6; Thu, 24 Jun 93 20:30:33 CDT Received: by berserkly.cray.com id AA16168; 5.64/CRI-4.9; Thu, 24 Jun 93 20:30:17 -0500 Received: by berserkly.cray.com id AA16158; 5.64/CRI-4.9; Thu, 24 Jun 93 20:29:57 -0500 Date: Thu, 24 Jun 93 20:29:57 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9306250129.AA16158@berserkly.cray.com> To: dab@berserkly.cray.com, mwalnut@CNRI.Reston.VA.US Subject: Re: TCPLW & Amsterdam IETF Cc: braden@isi.edu, mankin@cmf.nrl.navy.mil, tcplw@cray.com > How does 1600-1800 on Wednesday sound? Sounds good to me. I haven't heard any other objections, so I'll plan for the TCP Large Windows WG to meet then. -David Borman, dab@cray.com Received: by hemlock.cray.com id AA12355; 4.1/CRI-5.6; Thu, 24 Jun 93 09:03:11 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA12348; 4.1/CRI-5.6; Thu, 24 Jun 93 09:03:07 CDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by cray.com (4.1/CRI-MX 2.19) id AA28649; Thu, 24 Jun 93 09:03:05 CDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05274; 24 Jun 93 10:00 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: tcplw@cray.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-tcplw-extensions-00.txt Date: Thu, 24 Jun 93 10:00:32 -0400 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9306241000.aa05274@IETF.CNRI.Reston.VA.US> --NextPart A New Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Large Windows Working Group of the IETF. Title : TCP Extensions for High Performance: An Update Author(s) : R. Braden Filename : draft-ietf-tcplw-extensions-00.txt Pages : 10 This memo is a contribution to the TCP Large Windows (TCPLW) Working Group. It presents some suggested modifications to RFC-1323, which defined TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-tcplw-extensions-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-tcplw-extensions-00.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-tcplw-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcplw-extensions-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- Received: by hemlock.cray.com id AA13710; 4.1/CRI-5.6; Tue, 22 Jun 93 16:08:43 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13706; 4.1/CRI-5.6; Tue, 22 Jun 93 16:08:39 CDT Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.19) id AA06023; Tue, 22 Jun 93 16:08:36 CDT Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Tue, 22 Jun 1993 14:08:14 -0700 Date: Tue, 22 Jun 1993 14:08:14 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199306222108.AA28271@zephyr.isi.edu> To: tcplw@cray.com Subject: Re: RFC1323 question Hi. While I was on vacation during May, there was a discussion of how to handle the 25 day timeout (yes, 25 hours was wrong!). Upon returning and processing 1200 accumulated messages, I set some aside for later. Later is now... Steve Wise correctly pointed out a problem in my algorithm, and I agree with Liming Wei's correction. Thanks, Liming! Bob Braden Received: by hemlock.cray.com id AA02169; 4.1/CRI-5.6; Tue, 22 Jun 93 13:41:43 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA02145; 4.1/CRI-5.6; Tue, 22 Jun 93 13:41:36 CDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by cray.com (4.1/CRI-MX 2.19) id AA23847; Tue, 22 Jun 93 13:41:34 CDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10654; 22 Jun 93 13:16 EDT To: David Borman Cc: braden@isi.edu, mankin@cmf.nrl.navy.mil, tcplw@cray.com, mwalnut@CNRI.Reston.VA.US Subject: TCPLW & Amsterdam IETF In-Reply-To: Your message of "Mon, 21 Jun 93 15:15:51 CDT." <9306212015.AA14465@berserkly.cray.com> Date: Tue, 22 Jun 93 13:15:56 -0400 From: Megan Davies Walnut Message-Id: <9306221316.aa10654@IETF.CNRI.Reston.VA.US> How does 1600-1800 on Wednesday sound? Megan --------------- To: mdavies@CNRI.Reston.VA.US Subject: TCPLW & Amsterdam IETF Cc: braden@isi.edu, mankin@cmf.nrl.navy.mil, tcplw@cray.com Megan, Can we schedule in a slot for the TCPLW working group to meet in Amsterdam? It should not conflict with the Telnetw WG. The WG needs to review updates to RFC1323, "TCP Extensions for High Performance". Thanks. -David Borman, dab@cray.com Received: from berserkly.cray.com by hemlock.cray.com id AA04524; 4.1/CRI-5.6; Mon, 21 Jun 93 15:16:20 CDT Received: by berserkly.cray.com id AA14472; 5.64/CRI-4.9; Mon, 21 Jun 93 15:16:04 -0500 Received: by berserkly.cray.com id AA14465; 5.64/CRI-4.9; Mon, 21 Jun 93 15:15:51 -0500 Date: Mon, 21 Jun 93 15:15:51 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9306212015.AA14465@berserkly.cray.com> To: mdavies@CNRI.Reston.VA.US Subject: TCPLW & Amsterdam IETF Cc: braden@isi.edu, mankin@cmf.nrl.navy.mil, tcplw@cray.com Megan, Can we schedule in a slot for the TCPLW working group to meet in Amsterdam? It should not conflict with the Telnetw WG. The WG needs to review updates to RFC1323, "TCP Extensions for High Performance". Thanks. -David Borman, dab@cray.com Received: by hemlock.cray.com id AA18833; 4.1/CRI-5.6; Wed, 19 May 93 15:01:53 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA18827; 4.1/CRI-5.6; Wed, 19 May 93 15:01:49 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.19) id AA19201; Wed, 19 May 93 15:01:48 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA24848; Wed, 19 May 93 12:45:21 -0700 To: tcplw@cray.com Reply-To: skibo@florida.wpd.sgi.com (Thomas Skibo) X-Approved: newsmail@sgi.sgi.com From: skibo@florida.wpd.sgi.com (Thomas Skibo) Subject: Re: rfc1323 question Message-Id: Date: Wed, 19 May 93 19:40:13 GMT Lines: 28 In article , lwei@ISI.EDU writes: |> |> if (Segment contains TSopt) then { |> if (SEG.TSval < TS.Recent |> AND (Not idle too long)) then { |> if (Send.TS.OK |> AND (NOT RST) ) then { |> /* Timestamp too old => |> * segment is unacceptable. |> */ |> Send ACK segment; |> Discard segment and return; |> } |> } |> else { |> if (SEG.SEQ =< Last.ACK.sent) then |> TS.Recent = SEG.TSval; |> } |> } |> |> -- Liming Wei I think that's it. -- --- Thomas Skibo skibo@sgi.com Advanced Networking, Silicon Graphics, Inc. Received: by hemlock.cray.com id AA10931; 4.1/CRI-5.6; Wed, 19 May 93 12:59:54 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA10927; 4.1/CRI-5.6; Wed, 19 May 93 12:59:50 CDT Received: from venera.isi.edu by cray.com (4.1/CRI-MX 2.19) id AA09975; Wed, 19 May 93 12:59:47 CDT Received: from nam.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 19 May 1993 10:59:45 -0700 Date: Wed, 19 May 1993 10:59:53 -0700 From: lwei@ISI.EDU Posted-Date: Wed, 19 May 1993 10:59:53 -0700 Message-Id: <199305191759.AA00299@nam.isi.edu> Received: by nam.isi.edu (5.65c/4.0.3-4) id ; Wed, 19 May 1993 10:59:53 -0700 To: skibo@florida.wpd.sgi.com Subject: Re: rfc1323 question Cc: tcplw@cray.com > From: skibo@florida.wpd.sgi.com (Thomas Skibo) > Subject: Re: rfc1323 question > > .... > > > > The algorithm in Braden's update to the RFC doesn't try to update > > ts.recent if the connection has been idle too long. > > Hmmmm. I think Steve's onto something here... Tom, Interesting observation, so there is a need to make the connection still as robust after idling for a month (or longer). How about this, if (Segment contains TSopt) then { if (SEG.TSval < TS.Recent AND (Not idle too long)) then { if (Send.TS.OK AND (NOT RST) ) then { /* Timestamp too old => * segment is unacceptable. */ Send ACK segment; Discard segment and return; } } else { if (SEG.SEQ =< Last.ACK.sent) then TS.Recent = SEG.TSval; } } > It looks like if SEG.TSval is always less than TS.Recent due to wrap-around, > TS.recent will never get updated until the senders clock wraps completely > around to TS.Recent. The else clause never gets executed so TS.Recent > doesn't get updated. > > Also, I think the wrap-around time was 24 *days*. > > > --- > Thomas Skibo skibo@sgi.com Advanced Networking, Silicon Graphics, Inc. -- Liming Wei Received: by hemlock.cray.com id AA10086; 4.1/CRI-5.6; Thu, 13 May 93 16:47:24 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA10082; 4.1/CRI-5.6; Thu, 13 May 93 16:47:20 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.19) id AA23404; Thu, 13 May 93 16:47:17 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA24204; Thu, 13 May 93 14:41:25 -0700 To: tcplw@cray.com Reply-To: skibo@florida.wpd.sgi.com (Thomas Skibo) X-Approved: newsmail@sgi.sgi.com From: skibo@florida.wpd.sgi.com (Thomas Skibo) Subject: Re: rfc1323 question Message-Id: Date: Thu, 13 May 1993 21:38:41 GMT > What should be done with ts.recent if TCP discovers it to be invalid > via PAWS (idle >= 25 hours)? I realize that it should not be used to > drop incoming packets, but what about putting it in ts.ecr on an > outgoing segment? I don't think it matters if you put the stale TS.recent in TS.ecr in the ACK. If the segment was in-order, TS.recent should be updated (see below). If the segment was out-of-order, the ACK will not acknowledge new data so TS.ecr won't be used for a SRTT anyway. I put zero in just because I think the RFC said somehwere that zero meant invalid TS.recent. > > The algorithm in Braden's update to the RFC doesn't try to update > ts.recent if the connection has been idle too long. Hmmmm. I think Steve's onto something here... if (Segment contains TSopt) then { if (SEG.TSval < TS.Recent) then { if (Send.TS.OK AND (Idle less than 25 hours) AND (NOT RST) ) then { /* Timestamp too old => * segment is unacceptable. */ Send ACK segment; Discard segment and return; } } else { if (SEG.SEQ =< Last.ACK.sent) then TS.Recent = SEG.TSval; } } It looks like if SEG.TSval is always less than TS.Recent due to wrap-around, TS.recent will never get updated until the senders clock wraps completely around to TS.Recent. The else clause never gets executed so TS.Recent doesn't get updated. Also, I think the wrap-around time was 24 *days*. > ******** > Steve Wise IBM AWS - Austin, TX. > Internet: swise@austin.ibm.com > VNET: AUSVMQ(SWISE) --- Thomas Skibo skibo@sgi.com Advanced Networking, Silicon Graphics, Inc. Received: by hemlock.cray.com id AA09167; 4.1/CRI-5.6; Thu, 13 May 93 16:37:04 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA09161; 4.1/CRI-5.6; Thu, 13 May 93 16:37:00 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.19) id AA22469; Thu, 13 May 93 16:36:58 CDT Received: from [192.26.75.8] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA23292; Thu, 13 May 93 14:36:55 -0700 Received: by florida.wpd.sgi.com (921113.SGI/911001.SGI) for @sgi.sgi.com:tcplw@cray.com id AA23162; Thu, 13 May 93 14:36:47 -0700 Date: Thu, 13 May 93 14:36:47 -0700 From: skibo@florida.wpd.sgi.com (Thomas Skibo) Message-Id: <9305132136.AA23162@florida.wpd.sgi.com> To: tcplw@cray.com Subject: Re: rfc1323 question > What should be done with ts.recent if TCP discovers it to be invalid > via PAWS (idle >= 25 hours)? I realize that it should not be used to > drop incoming packets, but what about putting it in ts.ecr on an > outgoing segment? I don't think it matters if you put the stale TS.recent in TS.ecr in the ACK. If the segment was in-order, TS.recent should be updated (see below). If the segment was out-of-order, the ACK will not acknowledge new data so TS.ecr won't be used for a SRTT anyway. I put zero in just because I think the RFC said somehwere that zero meant invalid TS.recent. > > The algorithm in Braden's update to the RFC doesn't try to update > ts.recent if the connection has been idle too long. Hmmmm. I think Steve's onto something here... if (Segment contains TSopt) then { if (SEG.TSval < TS.Recent) then { if (Send.TS.OK AND (Idle less than 25 hours) AND (NOT RST) ) then { /* Timestamp too old => * segment is unacceptable. */ Send ACK segment; Discard segment and return; } } else { if (SEG.SEQ =< Last.ACK.sent) then TS.Recent = SEG.TSval; } } It looks like if SEG.TSval is always less than TS.Recent due to wrap-around, TS.recent will never get updated until the senders clock wraps completely around to TS.Recent. The else clause never gets executed so TS.Recent doesn't get updated. Also, I think the wrap-around time was 24 *days*. > ******** > Steve Wise IBM AWS - Austin, TX. > Internet: swise@austin.ibm.com > VNET: AUSVMQ(SWISE) --- Thomas Skibo skibo@sgi.com Advanced Networking, Silicon Graphics, Inc. Received: by hemlock.cray.com id AA24034; 4.1/CRI-5.6; Thu, 13 May 93 14:08:04 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA24027; 4.1/CRI-5.6; Thu, 13 May 93 14:07:57 CDT Received: from netmail.austin.ibm.com by cray.com (4.1/CRI-MX 2.19) id AA08940; Thu, 13 May 93 14:07:55 CDT Received: from vikings.austin.ibm.com by netmail.austin.ibm.com (AIX 3.1/UCB 5.61/gw.0.7) for tcplw@cray.com at cray.com id AA47361; Thu, 13 May 93 14:07:50 -0500 Received: by vikings.austin.ibm.com (AIX 3.2/UCB 5.64/4.03-client-2.4) for tcplw@cray.com at austin.ibm.com; id AA80611; Thu, 13 May 1993 14:07:46 -0500 From: swise@austin.ibm.com (Stevo Bevo-Devo Wise) Message-Id: <9305131907.AA80611@vikings.austin.ibm.com> To: tcplw@cray.com Subject: rfc1323 question Date: Thu, 13 May 93 14:07:42 -0600 What should be done with ts.recent if TCP discovers it to be invalid via PAWS (idle >= 25 hours)? I realize that it should not be used to drop incoming packets, but what about putting it in ts.ecr on an outgoing segment? The algorithm in Braden's update to the RFC doesn't try to update ts.recent if the connection has been idle too long. Skibo's code set ts.recent=0, AND checks if ts.val can update ts.recent. I could be all bass-ackwards on this, so feel free to correct me... Any thoughts? ******** Steve Wise IBM AWS - Austin, TX. Internet: swise@austin.ibm.com VNET: AUSVMQ(SWISE) Received: by hemlock.cray.com id AA20806; 4.1/CRI-5.6; Mon, 26 Apr 93 19:16:40 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA20801; 4.1/CRI-5.6; Mon, 26 Apr 93 19:16:36 CDT Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.19) id AA01768; Mon, 26 Apr 93 19:16:27 CDT Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Mon, 26 Apr 1993 17:16:18 -0700 Date: Mon, 26 Apr 1993 17:16:18 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199304270016.AA24763@zephyr.isi.edu> To: tcplw@cray.com Subject: Advancing RFC-1323 Folks, Comments on the RFC-1323 RTTM algorithm from Dave Borman and Tom Skibo led me to believe that we need to tinker with RFC-1323 before it is advance to Draft Standard. Here is a summary of my ideas on what ought to be changed. Bob Braden ----- Begin Included Message ----- Date: Mon, 26 Apr 1993 17:14:47 -0700 From: braden (Bob Braden) To: braden Content-Length: 17053 X-Lines: 532 NSF/tcp.extend/newrfc.txt Network Working Group R. Braden Internet Draft ISI April 25, 1993 TCP Extensions for High Performance: An Update Status of This Memo This memo is for information only. Abstract This memo presents some suggested modifications to RFC-1323, which defined TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It is intended that these changes will be merged into the successor to RFC-1323. 1. INTRODUCTION RFC-1323 [Jacobson92] defined a set of extensions to the TCP protocol [Postel81] to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. Specifically, RFC-1323 defined three new mechanisms. (1) Window Scale Option A new TCP option, "Window Scale" allows windows larger than 2**16 bytes. This option defines an implicit scale factor, which is used to multiply the window size value found in a TCP header to obtain the true window size. (2) RTTM: Round-Trip Time Measurement A new TCP option "Timestamps" is introduced, and a mechanism called "RTTM" (Round Trip Time Measurement) uses this option to obtain improved measurement of round trip times (RTTs). (3) PAWS: Protect Against Wrapped Sequence The Timestamps option is used by the PAWS mechanism to extend TCP reliability to transfer rates well beyond the foreseeable upper limit of network bandwidths, with reasonably large values of the Maximum Segment Lifetime (MSL). Braden [Page 1] Internet Draft TCP Performance Extensions: Update April 1993 The present document summarizes several minor issues and clarifications that have accumulated since RFC-1323 was published. 2. MODIFICATIONS TO RFC-1323 2.1 RTTM: When Make RTT Measurement? TCP requires that the RTO (retransmission timeout) values used for successive retransmissions of the same segment form an increasing sequence; this is known as "retransmission back-off". TCP implementations have previously been required [RFC-1323] to use Karn's algorithm [Karn87], which states that (1) retransmission back-off will persist until the next ACK is received for a data segment that has never been retransmitted, and that (2) no RTT measurements will be made from acknowledgments for re-transmitted data segments. Karn's algorithm was designed to allow reliable RTT estimates despite the ambiguity when an ACK is received for a retransmitted data segment: the ACK may have been created from either the original or the retransmission [Zhang86]. However, as RFC-1323 implied but did not clearly state, the RTTM mechanism replaces Karn's algorithm. The RTTM mechanism resolves the ambiguity in RTT measurement from an acknowledgment for a retransmitted data segment; the ACK segment will echo the timestamp from whichever data segment caused it be sent. Overriding the Karn algorithm was implied by the following statement on page 14 of RFC-1323, which was independent of whether or not the new data being acknowledged has been retransmitted: "A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window." This RFC-1323 rule furthermore implies that duplicate acknowledgments will not contribute to measurement of the RTT, even with RTTM in use. Suppose that exactly one segment is lost per window of N segments, resulting in N-1 duplicate ACKs. RTTM will make a new RTT measurement only from the ACK triggered by retransmission of the (assuming it is successfully acknowledged); none of the N segments originally sent will be used. Therefore, * the discussion under bullet (B) on page 15 of RFC-1323 is gratuitous: no matter which timestamp is echoed in a duplicate ACK segment, it (the echoed timestamp) will be ignored; and * with one lost segment per window, RTTM will result in only Braden [Page 2] Internet Draft TCP Performance Extensions: Update April 1993 one RTT measurement per window. However, this is still a significant improvement over a standard TCP without RTTM, which will make no measurements in the same circumstances. The diagram on the top of page 14 of RFC-1323 illustrates why TSecr can be accepted only if new data is acknowledged; otherwise, the RTT value may be artifically inflated. We could consider an alternative criterion for accepting TSecr that would prevent inflation in the RFC-1323 example: only use TSecr if the transmitter has outstanding data, i.e., only if SND_NXT > SND_UNA. However, the following example, involving simultaneous data transmission from both sides, illustrates why this alternative criterion won't work. TCP A TCP B (TSrecent) (TSrecent) 1. ------> (1) 2. (127) <----- (1) 3. (127) ------> (5) . . . . . . . . . . . . . . . . . . . . . . 4. (127) ---> ... 5. ... <--- (5) 4'. ---> (65) 5'. (191) <-- 6. ... <--- (65) 7. (191) ---> ... In this symmetrical data transfer example, both sides send data simultaneously (lines 4 and 5) after a pause of roughly 60 time units. When these segments arrive (lines 4' and 5') each side has outstanding data and therefore would use the TSecr to update its RTT estimate. The result would be to inflate each RTT estimate by 60 time units. We believe that the only way to ensure the measured RTT is accurate is to accept TSecr only when new data is acknowledged, and accept that duplicate ACKs will not update the RTT estimate. Braden [Page 3] Internet Draft TCP Performance Extensions: Update April 1993 2.2 RTTM: Which Timestamp to Echo? Step (2) of the algorithm to control which timestamp is echoed, given in RFC-1323 (see top of p. 16), is incorrect in two regards: (1) it will fail to update TSrecent for a retransmitted segment that resulted from a lost ACK, and (2) it will fail if SEG.LEN = 0. The correct step (2) is actually simpler. It is as follows: (2) If: SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. Observe that this algorithm explicitly constructs a monotonic sequence of TSrecent values. The case SEG.TSval = TSrecent is included here for consistency with the PAWS test. Note also that RFC-1323 correctly rendered this algorithm in Section 4.2.1 discussing PAWS, and also incorrectly (!) on page 35. 2.3 Implementation of TCP Options The hardest part of implementing RFC-1323 extensions is probably the modifications to allow TCP options in data segments while obeying the limits set by the MSS (maximum segment size) and by the connected network MTU (maximum transmission unit). This issue has been widely misunderstood, perhaps partly due to a past imprecision in terminology (e.g., what is a "segment"?). In addition, prior attempts to clarify these issues have been unfortunately obscure [RFC-1122]. To send a segment, the general procedure for a TCP should be: (a) Get a packet buffer and copy a header template into it. (b) Format any required TCP options into the buffer. (c) Copy 'len' bytes of data into buffer, where: len = min( data_to_send, maxseg, maxoptdata - optlen ); Here: * data_to_send = Amount of data to be sent. * maxseg = "Normal" data length in a segment. * maxoptdata = Largest area permitted. Braden [Page 4] Internet Draft TCP Performance Extensions: Update April 1993 * optlen = length of options added in (b). Finally, we must define how to compute 'maxseg' and 'maxoptdata'. maxoptdata = min( Received_MSS, pathMTU - 40) - maxseg = maxoptdata - Here "Received_MSS" is the value received in an MSS option in a SYN segment, or 536 if none is received. The MTU over the path, "pathMTU", may be found by MTU Discovery, or it may be determined by the following heuristic: use "interface_MTU" if the destination is on the connected network, else use 576. In normal usage today, there are no IP options to be considered. An MSS option is intended to specify ONLY a property of the remote host, independent of the path: the largest IP datagram that can be received and reassembled (less 40). For those hosts that have no limit on datagram size, it would not be incorrect to specify "infinity" (65535) in its MSS option. However, a more sensible choice would be "interface_MTU". Note also that 'maxseg' is also used by the SWS (silly-window syndrome) and congestion control algorithms of TCP [RFC-1122], and it should correspond to the "normal" data block size for a segment used in bulk transmission. 3. SUMMARY OF ALGORITHMS Appendix E of RFC-1323 defined the overall algorithm as modifications of the TCP Event Processing rules. The following is a more concise and algorithmic description of the algorithms. We define the following symbols: Options WSopt: TCP Window Scale Option TSopt: TCP Timestamps Option Option Fields shift.cnt: Window scale byte in WSopt. TSval: 32-bit Timestamp Value field in TSopt. TSecr: 32-bit Timestamp Reply field in TSopt. Braden [Page 5] Internet Draft TCP Performance Extensions: Update April 1993 Option Fields in Current Segment SEG.TSval: TSval field from TSopt in current segment. SEG.TSecr: TSecr field from TSopt in current segment. SEG.WSopt: 8-bit value in WSopt Clock Values my.TSclock: Local source of 32-bit timestamp values my.TSclock.rate: Period of my.TSclock (1 ms to 1 sec per tick). Per-Connection State Variables TS.Recent: Latest received Timestamp Last.ACK.sent: Last ACK field sent Snd.TS.OK: 1-bit flag Snd.WS.OK: 1-bit flag Rcv.Wind.Scale: Receive window scale power Snd.Wind.Scale: Send window scale power Start.Time: my.TSclock value when segment being timed was sent (used by pre-1323 code). Procedure Update_SRTT( m ) Procedure to update the smoothed RTT and RTT variance estimates, using the Jacobson algorithms [Jacobson88]. Here m is a new RTT measurement in seconds. PSEUDO-CODE SUMMARY: Create new TCB => { Rcv.wind.scale = MIN( 14, MAX( 0, floor(log2(receive buffer space)) - 15 ) ); Snd.wind.scale = 0; Last.ACK.sent = 0; Snd.TS.OK = Snd.WS.OK = FALSE; } Send initial {SYN} segment => { SEG.WND = MIN( SND.WND, 65535 ); Include in segment: TSopt(TSval=my.TSclock, TCecr=0); Include in segment: WSopt = Rcv.wind.scale; Braden [Page 6] Internet Draft TCP Performance Extensions: Update April 1993 } Send {SYN, ACK} segment => { SEG.ACK = Last.ACK.sent = RCV.NXT; SEG.WND = MIN( SND.WND, 65535 ); if (Snd.TS.OK) then Include in segment: TSopt(TSval=my.TSclock, TSecr=TS.Recent); if (Snd.WS.OK) then Include in segment: WSopt = Rcv.wind.scale; } Receive {SYN} or {SYN,ACK} segment => { if (Segment contains TSopt) then { TS.Recent = SEG.TSval; Snd.TS.OK = TRUE; if (is {SYN,ACK} segment) then Update_SRTT( (my.TSclock - SEG.TSecr)*my.TSclock.rate ) ; } if Segment contains WSopt) then { Snd.wind.scale = SEG.WSopt; Snd.WS.OK = TRUE; } else Rcv.wind.scale = Snd.wind.scale = 0; } Send non-SYN segment => { SEG.ACK = Last.ACK.sent = RCV.NXT; SEG.WND = MIN( SND.WND >> Rcv.wind.scale, 65535 ); if (Snd.TS.OK) then Include in segment: TSopt(TSval=my.TSclock, TSecr=TS.Recent); } Receive non-SYN segment in (state >= ESTABLISHED) => { Window = (SEG.WND << Snd.wind.scale); /* Use 32-bit 'Window' instead of 16-bit 'SEG.WND' * in rest of processing. Braden [Page 7] Internet Draft TCP Performance Extensions: Update April 1993 */ if (Segment contains TSopt) then { if (SEG.TSval < TS.Recent) then { if (Send.TS.OK AND (Idle less than 25 hours) AND (NOT RST) ) then { /* Timestamp too old => * segment is unacceptable. */ Send ACK segment; Discard segment and return; } } else { if (SEG.SEQ =< Last.ACK.sent) then TS.Recent = SEG.TSval; } } if (SEG.ACK > SND.UNA) then { /* (At least part of) first segment in * retransmission queue has been ACKd */ if (Segment contains TSopt) then Update_SRTT( (my.TSclock - SEG.TSecr)/my.TSclock.rate); else Update_SRTT( /* for compatibility */ (my.TSclock - Start.Time)/my.TSclock.rate); } } 4. REFERENCES [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88, Stanford, CA., August 1988. [Jacobson92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC-1323, May 1992. [Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT, August 1987. [Postel81] Postel, J., "Transmission Control Protocol - DARPA Braden [Page 8] Internet Draft TCP Performance Extensions: Update April 1993 Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [RFC-1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", RFC-1122, October 1989. [Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc. SIGCOMM '86, Stowe, Vt., August 1986. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Bob Braden University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (213) 822-1511 EMail: Braden@ISI.EDU Braden [Page 9] ----- End Included Message ----- Received: by hemlock.cray.com id AA09385; 4.1/CRI-5.6; Wed, 14 Apr 93 14:43:19 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA09377; 4.1/CRI-5.6; Wed, 14 Apr 93 14:43:15 CDT Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.17) id AA11437; Wed, 14 Apr 93 14:43:13 CDT Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Wed, 14 Apr 1993 12:43:05 -0700 Date: Wed, 14 Apr 1993 12:43:05 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199304141943.AA13773@zephyr.isi.edu> To: tcplw@cray.com Subject: SunOS 4.1.1 version Hi. I have a version of RFC-1323 changes for SunOS 4.1.1. I recently put together a set of context diffs that would allow someone else with Sun sources to try my code. If you are interested, drop me a line. Bob Braden Received: by hemlock.cray.com id AA08342; 4.1/CRI-5.6; Wed, 31 Mar 93 17:56:39 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA08335; 4.1/CRI-5.6; Wed, 31 Mar 93 17:56:34 CST Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.16) id AA17560; Wed, 31 Mar 93 17:56:32 CST Received: by frenzy.cray.com id AA11423; 4.1/CRI-5.6; Wed, 31 Mar 93 17:56:54 CST Date: Wed, 31 Mar 93 17:56:54 CST From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9303312356.AA11423@frenzy.cray.com> To: tcplw@cray.com, telnet-ietf@cray.com Subject: Mail archives Ok, mail archives for "telnet-ietf@cray.com" and "tcplw@cray.com" mailing lists are now available (finally...). The big problem in the past is that where I save the archive is behind our firewall, with no ftp access. This is still the case. However... you can now access the mailing list archives by using telnet to an alternate port number: Telnet to port 23000 on berserkly.cray.com (128.162.96.70) You will be talking to an interactive program that will ask you to select the archive of your choice. Once an archive is selected, the interface is similar to running the BSD Mail program, but it is read only. It also has some different options, many things from BSD Mail are missing, so things aren't exactly the same, but they are close enough for now. The program doesn't enable any telnet options, so if you have a telnet that supports kludge linemode, you'll go into kludge linemode, a handy feature so that you can do line editing... This is a program that I hacked together in the last couple of days. I make no guarantees that it will always work, and I haven't had time to really fully test it out. If you run into problems (like the connection gets dropped or the session hangs), please drop me a note, being as specific as you can as to what you were doing at the time, and if it is reproducable. Attached is a sample run of just connecting to the server. -David Borman, dab@cray.com ------ % telnet berserkly.cray.com 23000 Trying 128.162.96.70... Connected to berserkly.cray.com. Escape character is '^]'. Cray Research Mail Archive Server Please report any problems to dab@cray.com This is an simple mail archive server, that provides a user interface similiar to the BSD mail program. Type '?' for help. List of available mail archives: 1) tcplw (tcplw@cray.com) 2) telnet-ietf (telnet-ietf@cray.com) Please select an archive number ('q' to quit): 1 Parsing archive... Mail archive for tcplw 135 messages, 321639 bytes > 133 braden@ISI.EDU Mar 25 11:40 1993 33/1229 "Re: TCP MSS & Timestam" 134 braden@ISI.EDU Mar 26 14:34 1993 41/1460 "RFC-1323 to Draft" 135 braden@ISI.EDU Mar 26 15:37 1993 126/3680 "Re: TCP MSS & Timestam" tcplw> ? info print archive information type [msg list] type selected messages all type the entire archive + type the next message - type the previous message = print current message number h print a screen of headers from [msg list] print selected headers z print next screen of headers z- print last screen of headers arch select a new archive idle [idle time] get (set) idle time screen <# lines> set # of lines in screen quit quit ? print this list tcplw> quit Goodbye. Connection closed by foreign host. % Received: by hemlock.cray.com id AA13185; 4.1/CRI-5.6; Fri, 26 Mar 93 15:37:44 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13173; 4.1/CRI-5.6; Fri, 26 Mar 93 15:37:38 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.16) id AA20120; Fri, 26 Mar 93 15:37:36 CST Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Fri, 26 Mar 1993 13:37:34 -0800 Date: Fri, 26 Mar 1993 13:37:34 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199303262137.AA14681@zephyr.isi.edu> To: dab@cray.com Subject: Re: TCP MSS & Timestamps Cc: tcplw@cray.com Dave, Here is a summary of the way I handle TCP options in my version of the RFC-1323 extensions, for SunOS4.1. Perhaps something like this should be included in RFC-1323-bis? Do you believe it? Bob ______________________________________________________________ /* Handling TCP options and Maximum Segment Size (MSS) */ Connection State block (TCB) includes the following quantities: * maxseg: Largest data block to send in a packet. * maxopd: Largest (data + TCP options) area in a packet * Received_MSS: The MSS value received from the remote host in an MSS option. This variable is initialized to 536 (or a cached value). _________________________________________________________________ When receive a segment [tcp_input]: (1) When receive SYN in LISTEN or SYN-SENT state: o Parse the options o If receive an MSS option, store its value into Received_MSS (and perhaps cache it). o Call tcp_nice_mss(). _________________________________________________________________ When send a segment [tcp_output]: (1) Get packet buffer and copy header template into it. (2) Build options in buffer. o MSS option is sent with value tcp_mss(). (But it is not sent if value is 536). (3) Given option length optlen, compute actual data to send: len = min( data_to_send, maxseg, maxopd - optlen ); (4) Copy len bytes of data into buffer. _________________________________________________________________ /* The following algorithms are in fractured-C */ /* tcp_nice_mss(): * * Compute: maxseg = maximum data to ever send in one segment, and * maxopd = maximum total space for data and TCP options. * * Maxseg is rounded down to a "nice" value (a multiple of 512) if possible * without wasting more than 1/16 of the space. Maxopd is set to handle * the "normal" options; if the actual options exceed this size, they will * eat into maxseg. Conversely, if actual data len < maxseg, then more * room is available for options. * * Also initialize the congestion/slow start window to be a single * segment if the destination isn't local. */ tcp_nice_mss() { /* * Compute maxopd = - 40 */ if (!islocal) maxopd = min( Interface_MTU - 40, Received_MSS, pathMTU - 40); /* Until MTU Discovery is available, use heuristic: pathMTU = 576. */ else maxopd = min( Interface_MTU - 40, Received_MSS); maxseg = maxopd; if () maxseg -= sizeof(TSopt); maxseg = NICE_SIZE(maxseg); /* round down if possible */ /* If not on local network, force initial slowstart */ if (!is_local) congestion_window = maxseg; } /* * tcp_mss() * * This routine returns computes the MSS option to be sent; it depends * only on the interface MTU (for a system like BSD that does not have * a fixed-size packet receive buffer): */ tcp_mss() { return(Interface_MTU - 40) } Received: by hemlock.cray.com id AA09881; 4.1/CRI-5.6; Fri, 26 Mar 93 14:34:27 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA09877; 4.1/CRI-5.6; Fri, 26 Mar 93 14:34:22 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.16) id AA14699; Fri, 26 Mar 93 14:34:19 CST Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Fri, 26 Mar 1993 12:34:10 -0800 Date: Fri, 26 Mar 1993 12:34:10 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199303262034.AA11371@zephyr.isi.edu> To: tcplw@cray.com, dab@berserkly.cray.com, braden@ISI.EDU Subject: RFC-1323 to Draft Dave, Before we advance 1323 to Draft Standard, I think we need to clean up three things: 1. Note that Karn algorithm is not needed when RTTM is used. 2. Write some words about how to do TCP options vis a vis MSS. 3. Correct the algorithm error you pointed out. I am pretty well convinced that the *right* answer is: TSrecent is updated when SEG.TS >= TSrecent AND SEG.SEQ <= Last_ACK_Sent. I am still a bit fuzzy about whether there is a different formulation that also works, but this formulation seems to have the right properties and fits well with PAWS. In particular, it explicitly constructs a monotonic sequence of values in TSrecent. If we can get general agreement with this, I will start editing RFC-1323 to make a new document. Bob Braden Received: by hemlock.cray.com id AA00545; 4.1/CRI-5.6; Thu, 25 Mar 93 11:40:09 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA00536; 4.1/CRI-5.6; Thu, 25 Mar 93 11:40:05 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.16) id AA26796; Thu, 25 Mar 93 11:40:01 CST Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Thu, 25 Mar 1993 09:39:59 -0800 Date: Thu, 25 Mar 1993 09:39:59 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199303251739.AA08744@zephyr.isi.edu> To: tcplw@cray.com, dab@berserkly.cray.com Subject: Re: TCP MSS & Timestamps Dave, This is a belated reply to your carefully-reasoned discussion of how to handle TCP options vis a vis MSS. I would note that your conclusion is inescapable. It would not make sense for the receiver to adjust the MSS. Unless the receiver has precognition, it cannot know how much option space the sender will use. This also agrees with 4.2.2.6 of the Host Requirements RFC 1122. This is an area of the Internet architecture that has caused much confusion, because we didn't get it quite right. I'm still not sure what "right" would be, but we didn't get there! Bob Received: by hemlock.cray.com id AA08543; 4.1/CRI-5.6; Tue, 16 Mar 93 21:34:32 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA08539; 4.1/CRI-5.6; Tue, 16 Mar 93 21:34:29 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.16) id AA01907; Tue, 16 Mar 93 21:34:28 CST Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA11475; Tue, 16 Mar 93 19:25:12 -0800 To: tcplw@cray.com Reply-To: skibo@florida.wpd.sgi.com (Thomas Skibo) X-Approved: newsmail@sgi.sgi.com From: skibo@florida.wpd.sgi.com (Thomas Skibo) Subject: Re: 1323 question Message-Id: Date: Wed, 17 Mar 1993 03:23:26 GMT Bob: > Here is a single test that I think may work: > > *> (2) If the packet fits at the left window edge or earlier, > *> and if it its timestamp is later than TSrecent: > *> > *> SEG.SEQ <= Last.ACK.sent > *> and TSval > TS.Recent > *> > *> then the TSval from the segment is copied to TS.Recent; > *> otherwise, the TSval is ignored. > > Bob One advantage to this change is that (I think) it fixes the problem that PAWS does not protect us from old, duplicate ACKs in uni-directional connections. I dug this up from way, way back: > From: braden@ISI.EDU > Posted-Date: Thu, 14 May 92 16:52:37 PDT > Message-Id: <9205142352.AA13866@braden.isi.edu> > Received: by braden.isi.edu (4.1/4.0.3-4) > id ; Thu, 14 May 92 16:52:37 PDT > To: skibo@cs.uiuc.edu > Subject: Re: Does PAWS work for duplicate ACKs in uni-directional connections? > Cc: tcplw@timbuk.UUCP > Status: R > > > From skibo@cs.uiuc.edu Wed May 13 11:51:34 1992 > Date: Wed, 13 May 92 13:51:28 -0500 > From: Thomas Skibo > To: braden@ISI.EDU > Subject: Does PAWS work for duplicate ACKs in uni-directional connections? > Cc: tcplw@timbuk.cray.com > > Bob: > > The messages about 64-bit sequence numbers reminded me of a point I > should have brought up a couple weeks ago when I noticed it. > > As PAWS is defined in the RFC, a completely uni-directional connection > will not have any protection against old duplicate ACKs with wrapped > acknowledgement numbers. Since a pure ACK has a zero length, the > comparison > > SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN > > always fails and so TS.recent is never updated at the sender (the > receiver of the acknowledgement). TS.recent stays at the initial > time-stamp value received at connection set-up and so ALL acknowledgements > pass the PAWS test. > > Would this test be more appropriate? > > SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN if SEG.LEN > 0 > > SEG.SEQ == Last.ACK.sent if SEG.LEN == 0 > > > Am I overlooking something? > > ------ > Thomas Skibo University of Illinois, Dept. of CS. > skibo@cs.uiuc.edu ph: 217-333-7937 > > > This is a very interesting point. My first reaction is that the problem you > point out is real, but I don't like your fix. Strictly, TS.recent should > be updated with the "latest" ACK. This should correspond to the latest > window update, as determined by the SND.WL1 and SND.WL2 variables. So > this makes me suspect that the TS.recent update is actually in the > wrong place, and ought to be in the ACK field processing (p. 72 of > RFC-793). Interesting. > > Bob Braden Received: by hemlock.cray.com id AA08362; 4.1/CRI-5.6; Tue, 16 Mar 93 21:21:57 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA08357; 4.1/CRI-5.6; Tue, 16 Mar 93 21:21:53 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.16) id AA01328; Tue, 16 Mar 93 21:21:52 CST Received: from [192.26.75.8] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA11010; Tue, 16 Mar 93 19:21:47 -0800 Received: by florida.wpd.sgi.com (921113.SGI/911001.SGI) for @sgi.sgi.com:braden@ISI.EDU id AA01942; Tue, 16 Mar 93 19:21:44 -0800 Date: Tue, 16 Mar 93 19:21:44 -0800 From: skibo@florida.wpd.sgi.com (Thomas Skibo) Message-Id: <9303170321.AA01942@florida.wpd.sgi.com> To: braden@ISI.EDU (Bob Braden) Subject: Re: 1323 question Cc: tcplw@cray.com Bob: > Here is a single test that I think may work: > > *> (2) If the packet fits at the left window edge or earlier, > *> and if it its timestamp is later than TSrecent: > *> > *> SEG.SEQ <= Last.ACK.sent > *> and TSval > TS.Recent > *> > *> then the TSval from the segment is copied to TS.Recent; > *> otherwise, the TSval is ignored. > > Bob One advantage to this change is that (I think) it fixes the problem that PAWS does not protect us from old, duplicate ACKs in uni-directional connections. I dug this up from way, way back: > From: braden@ISI.EDU > Posted-Date: Thu, 14 May 92 16:52:37 PDT > Message-Id: <9205142352.AA13866@braden.isi.edu> > Received: by braden.isi.edu (4.1/4.0.3-4) > id ; Thu, 14 May 92 16:52:37 PDT > To: skibo@cs.uiuc.edu > Subject: Re: Does PAWS work for duplicate ACKs in uni-directional connections? > Cc: tcplw@timbuk.UUCP > Status: R > > > From skibo@cs.uiuc.edu Wed May 13 11:51:34 1992 > Date: Wed, 13 May 92 13:51:28 -0500 > From: Thomas Skibo > To: braden@ISI.EDU > Subject: Does PAWS work for duplicate ACKs in uni-directional connections? > Cc: tcplw@timbuk.cray.com > > Bob: > > The messages about 64-bit sequence numbers reminded me of a point I > should have brought up a couple weeks ago when I noticed it. > > As PAWS is defined in the RFC, a completely uni-directional connection > will not have any protection against old duplicate ACKs with wrapped > acknowledgement numbers. Since a pure ACK has a zero length, the > comparison > > SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN > > always fails and so TS.recent is never updated at the sender (the > receiver of the acknowledgement). TS.recent stays at the initial > time-stamp value received at connection set-up and so ALL acknowledgements > pass the PAWS test. > > Would this test be more appropriate? > > SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN if SEG.LEN > 0 > > SEG.SEQ == Last.ACK.sent if SEG.LEN == 0 > > > Am I overlooking something? > > ------ > Thomas Skibo University of Illinois, Dept. of CS. > skibo@cs.uiuc.edu ph: 217-333-7937 > > > This is a very interesting point. My first reaction is that the problem you > point out is real, but I don't like your fix. Strictly, TS.recent should > be updated with the "latest" ACK. This should correspond to the latest > window update, as determined by the SND.WL1 and SND.WL2 variables. So > this makes me suspect that the TS.recent update is actually in the > wrong place, and ought to be in the ACK field processing (p. 72 of > RFC-793). Interesting. > > Bob Braden Received: by hemlock.cray.com id AA06340; 4.1/CRI-5.6; Tue, 16 Mar 93 19:06:42 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA06336; 4.1/CRI-5.6; Tue, 16 Mar 93 19:06:39 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.16) id AA26380; Tue, 16 Mar 93 19:06:37 CST Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Tue, 16 Mar 1993 17:06:34 -0800 Date: Tue, 16 Mar 1993 17:06:34 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199303170106.AA05499@zephyr.isi.edu> To: tcplw@cray.com, dab@berserkly.cray.com Subject: Re: 1323 question Dave, I see your point: the timestamp resolves the ambiguity that forced the Karn algorithm (whether an ACK refers to the original packet or to the retransmitted packet), so maybe we don't need Karn if we have timestamps. Here is a single test that I think may work: *> (2) If the packet fits at the left window edge or earlier, *> and if it its timestamp is later than TSrecent: *> *> SEG.SEQ <= Last.ACK.sent *> and TSval > TS.Recent *> *> then the TSval from the segment is copied to TS.Recent; *> otherwise, the TSval is ignored. Bob Received: from berserkly.cray.com by hemlock.cray.com id AA09338; 4.1/CRI-5.6; Mon, 15 Mar 93 17:27:04 CST Received: by berserkly.cray.com id AA18110; 5.64/CRI-4.9; Mon, 15 Mar 93 17:26:49 -0600 Received: by berserkly.cray.com id AA18103; 5.64/CRI-4.9; Mon, 15 Mar 93 17:26:39 -0600 Date: Mon, 15 Mar 93 17:26:39 -0600 From: dab@berserkly.cray.com (David Borman) Message-Id: <9303152326.AA18103@berserkly.cray.com> To: braden@ISI.EDU, dab@berserkly.cray.com, tcplw@cray.com Subject: Re: 1323 question Bob, Ok, I've flipped back and forth on whether I agree or disagree while writing this up (with a different reason for each flip-flop). In the end, I believe that there is valid reasoning for not ignoring the TSecr in ACKs to retransmitted packets (and hence modifying 1323 to guarantee that the TSecr in those packets is valid for RTT measurement). Short and sweet, if the packet loss rate exceeds 1 packet per RTT, and you ignore the TSecr on ACKs to retransmitted packets, you'll probably never get a valid RTT measurement. Here's my thinking, let me know if I've missed something. I'm assuming the sender is using Van's fast retransmit code, so that packet losses will be noticed within about one RTT of when the packet was sent. If you don't do that, all this is still true, only worse... For using Timestamps to measure RTT: If you lose a data packet, all ACKS due to successive packets after the lost packet, and before the retransmitted packet, will NOT acknowledge new data. They will all cause duplicate ACKs to be generated. The current rules will cause the TSecr in all these ACKs to be ignored. So, you've already lost all the timing information between the lost packet and when you retransmit the lost packet. Assuming the packet after the lost packet is the next one that the receiver expects, now that the hole is filled, its ACK will contain a valid TSecr that can be used correctly in updating the RTT. In fact, all packets between the retransmitted packet, and the next lost packet, can generate valid RTT values. Whether or not you use the ACK to the retransmitted packet in RTT calculations doesn't change any of this. Not using the TSecr of the ACK of the retransmitted packet means you only lose one RTT measurement, that of the retransmitted packet. But if that's the only valid RTT measurement... The old "one RTT measurement per RTT" scenario: When you lose a packet you lose the RTT info for that packet. You also continue to lose RTT info until that packet is ACKed. Once you get that ack, you can start timing again. This means that you go for 2 RTT without getting valid RTT info. Summaries: One-timing-per-RTT: It will take at least one RTT to realize that a packet has been lost. It will take another RTT to get the ACK for the retransmitted packet. If you lose another packet in that time frame, you lose big. Loss rate > 1 per 2*RTT means no accurate RTT measurement. Current Timestamps (ignore TSecr in ACKs to retransmitted packets): Lose if next lost packet is before or immediatly after the retransmitted packet is sent. It takes at least one RTT to determine that a packet has been lost and be retransmitted. If another packet is lost before the retransmitted packet is received, or if the packet immediatly following the retransmitted packet is lost, you lose bit. Loss rate > 1 per RTT means no accurate RTT measurement. Fix Timestamps to allow timing of retransmitted packets: This is the same as the Current Timestamps. However, the big difference is that you are guaranteed at least one valid RTT measurement per successfuly retransmitted and ACKed packet (if you can't do that, you won't have a connection very long...), even if the loss rate exceeds 1 packet per RTT. Loss rate > 1 per RTT means that you'll still get accurate RTT measurement, at about the same accuracy as the "One-timing-per-RTT" gets without any loss. So, it seems to me that for high-loss networks, there is a definite win to being able to use the TSecr in acks to retransmitted packets. I believe that my proposed changes in my previous message will obtain that goal. -David Borman, dab@cray.com > From braden@ISI.EDU Mon Mar 15 15:24:27 1993 > Date: Mon, 15 Mar 1993 13:24:33 -0800 > From: braden@ISI.EDU (Bob Braden) > To: tcplw@cray.com, dab@berserkly.cray.com > Subject: Re: 1323 question > > > Dave, > > I believe you have noted a documentation fault, not an algorithm > fault. The addition of the RFC-1323 changes do not, as Van has noted > to me in the past, mean that one should stop doing all the other good > things -- in particular, one should continue to apply Karn's > algorithm. This means that it does not matter what TSecr arrives in > the the ACK, the sending side should ignore it because it ACKs a packet > that has been retransmitted. > > Does this make sense? > > Bob Received: by hemlock.cray.com id AA03205; 4.1/CRI-5.6; Mon, 15 Mar 93 15:24:42 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA03200; 4.1/CRI-5.6; Mon, 15 Mar 93 15:24:37 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.16) id AA15367; Mon, 15 Mar 93 15:24:35 CST Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Mon, 15 Mar 1993 13:24:33 -0800 Date: Mon, 15 Mar 1993 13:24:33 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199303152124.AA10391@zephyr.isi.edu> To: tcplw@cray.com, dab@berserkly.cray.com Subject: Re: 1323 question Dave, I believe you have noted a documentation fault, not an algorithm fault. The addition of the RFC-1323 changes do not, as Van has noted to me in the past, mean that one should stop doing all the other good things -- in particular, one should continue to apply Karn's algorithm. This means that it does not matter what TSecr arrives in the the ACK, the sending side should ignore it because it ACKs a packet that has been retransmitted. Does this make sense? Bob Received: by hemlock.cray.com id AA00542; 4.1/CRI-5.6; Mon, 15 Mar 93 14:39:44 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA00537; 4.1/CRI-5.6; Mon, 15 Mar 93 14:39:40 CST Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.16) id AA12020; Mon, 15 Mar 93 14:39:39 CST Received: by frenzy.cray.com id AA04683; 4.1/CRI-5.6; Mon, 15 Mar 93 14:39:58 CST Date: Mon, 15 Mar 93 14:39:58 CST From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9303152039.AA04683@frenzy.cray.com> To: tcplw@cray.com Subject: 1323 question Hi. I've been looking at calculating retransmission timers using the Timestamps option. Either we missed a case in 1323, or I missed where it is documented in 1323. The scenario is straight forward. A host sends a packet, the remote side acks it, the ack is lost, the orginating host resends the packet, and the remote host acks it again. TS.Recent -------------------> 1 (lost) <---- (ReXmit) -------------------> ??? <---- One of two things has to happen here. Either "???" has to be set to "4", or the originating host has to ignore the TSecr in the packet for calculating RTT. (I don't like the latter, because it means that the originator has to keep track of everything that has been retransmitted until it it acknowledged.) Received: by hemlock.cray.com id AA26792; 4.1/CRI-5.6; Mon, 1 Feb 93 12:45:35 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA26778; 4.1/CRI-5.6; Mon, 1 Feb 93 12:45:29 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.9) id AA16505; Mon, 1 Feb 93 12:45:25 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Mon, 1 Feb 1993 10:43:28 -0800 Date: Mon, 1 Feb 1993 10:43:28 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199302011843.AA03178@zephyr.isi.edu> To: tcplw@cray.com Subject: Question RFC-1323 experience Cc: mathis@pele.psc.edu ----- Begin Included Message ----- To: van@ee.lbl.gov, braden@ISI.EDU, dab@cray.com Cc: mathis@pele.psc.edu Subject: End to end list and other questions. Date: Mon, 01 Feb 93 10:44:01 -0500 From: mathis@pele.psc.edu X-Mts: smtp Content-Length: 242 X-Lines: 8 Can you give me a pointer to the end-2-end list(s)s and their archive(s)? The IETF people don't... Or more specifically: can you cite the largest pipe on which RFC1323 (Winshift/RTTM/PAWS) compliant TCP has has been demonstrated? --MM-- ----- End Included Message ----- Received: by hemlock.cray.com id AA02106; 4.1/CRI-5.6; Fri, 22 Jan 93 12:21:52 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA02102; 4.1/CRI-5.6; Fri, 22 Jan 93 12:21:49 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.9) id AA08834; Fri, 22 Jan 93 12:21:47 CST Received: from hedgehog.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA12237; Fri, 22 Jan 1993 11:21:45 MST Date: Fri, 22 Jan 1993 11:21:44 MST From: "Sean O'Malley" Message-Id: <199301221821.AA14952@hedgehog.cs.arizona.edu> Received: by hedgehog.cs.arizona.edu; Fri, 22 Jan 1993 11:21:44 MST To: tcplw@cray.com Subject: NACK proposal I presented my NACK proposal to the end-to-end interest group yesterday and the results were encouraging enough (at least from my point of view) for me to continue the process. I plan to implement several variations on the NACK scheme and produce a paper by the SIGCOMM paper deadline (Feb 28th). Since the NACK option (and for that matter the a SACK option) opens the door for a variety of additional TCP modifications I would like to get some feed back on potential changes. 1) NACKS: 1- Single NACK (lost NACK causes slow start) 2- Multiple NACK's (tolerates up to N dropped NACKs) 3- Repeated NACK's (sends NACK's with every duplicate ACK) 2) Congestion window: 1- implement full dual window model[Z. Wang and J. Crowcroft] 2- move congestion window calculation to receiver 3) Timer 1- eliminate TIMESTAMP option 2- move retransmission timer to receiver (al la NETBLT) I plan to mix and match these modifications to see what effect they have on overall performance. If anyone has any other suggestions (or good algorithms for what I have proposed) please let me know. My goal is to have a BSD implementation and an RFC by March. Sean O'Malley Received: by hemlock.cray.com id AA18105; 4.1/CRI-5.6; Thu, 21 Jan 93 09:43:24 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA18101; 4.1/CRI-5.6; Thu, 21 Jan 93 09:43:20 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.8) id AA22483; Thu, 21 Jan 93 09:43:16 CST Received: from hedgehog.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA06467; Thu, 21 Jan 1993 08:43:13 MST Date: Thu, 21 Jan 1993 08:43:12 MST From: "Sean O'Malley" Message-Id: <199301211543.AA13822@hedgehog.cs.arizona.edu> Received: by hedgehog.cs.arizona.edu; Thu, 21 Jan 1993 08:43:12 MST To: tcplw@cray.com Subject: any trafic yesterday I somehow managed to destroy my mail box and have lost all of yesterdays (Jan 20-ths) mail. If there was any on this group could someone send me duplicates? Sean Received: by hemlock.cray.com id AA13268; 4.1/CRI-5.6; Wed, 20 Jan 93 14:45:58 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13264; 4.1/CRI-5.6; Wed, 20 Jan 93 14:45:55 CST Received: from somnet.Sandia.GOV by cray.com (4.1/CRI-MX 2.8) id AA02921; Wed, 20 Jan 93 14:45:53 CST Received: by somnet.Sandia.GOV (5.59/SNLA-3.2.1) id AA19491; Wed, 20 Jan 93 13:41:17 MST From: cdbrown@somnet.sandia.gov (C. Douglas Brown) Message-Id: <9301202041.AA19491@somnet.Sandia.GOV> Subject: Re: slow start and large windows To: tcplw@cray.com Date: Wed, 20 Jan 93 13:41:13 MST In-Reply-To: <199301181831.AA14725@optima.cs.arizona.edu>; from "Sean O'Malley" at Jan 18, 93 11:31 am X-Mailer: ELM [version 2.3 PL11] I have been following the discussion of Sean O'Malley's proposals with great interest and would like to express my concern with performance using TCP large windows in an environment with congestion loss. It appears likely that with high-bandwidth networks (45Mb/s and up), TCP large windows will increase the chances of congestion loss as more hosts dump data into the net at high rates. I've already experienced some router problems when testing TCPLW code for SunOS in a fairly clean environment. Having worked with networks for quite a few years, I've observed that as the raw network bandwidth goes up, the traffic gets more and more bursty. It's desirable to allow hosts to use a big percent- age of the network bandwidth for short bursts, but you never know when several hosts will do this at once, causing temporary congestion loss. Hence, the need to solve the congestion problem without dropping performance to a snail's pace. Now some comments on Sean's conclusions: > Conclusions: > > It is congestion control rather that the cost of duplicate > retransmissions which will have the most effect upon the > achievable bandwidth in the face of dropped packets in > networks with large bandwidth delay products. > Right. When the networks get very fast, we shouldn't worry so much about a few retransmissions, if we can keep overall performance up. > Slow start has to be modified to be more aggressive in > increasing the congestion window when the window is large. > In particular the algorithm should be normalized so that the > time it takes to increase the congestion window back to its > original value is independent of its size. Or, after reading subsequent discussions, perhaps not closing the congestion window so severly in the first place. > > Using slow start to avoid the unnecessary retransmissions > missions is overkill and some other method (SACK's, NACK's > or playing with timers) should be used to solve this problem. It appears that the real intent of most proposals is merely to speed retransmission of dropped segments; hence, a NACK is philosophically what we're looking at, no matter what we call it. I personally like Sean's NACK proposal, or some variant of it. The other parameter of interest is the usable network bandwidth, which would allow the sender to avoid the oscillation problem. Perhaps the NACK could contain the necessary information to calculate effective bandwidth, as has been proposed. > > While some congestion control is probably be required for > each dropped packet the existing reduction of the congestion > window to one segment and invoking slow start appears > draconian. Some other more benign algorithm would appear > to be called for. > Sounds like the more recent Reno release solved the problem of a single dropped packet. Doug Brown (cdbrown@sandia.gov) Sandia National Labs Albuquerque, NM Received: by hemlock.cray.com id AA03349; 4.1/CRI-5.6; Tue, 19 Jan 93 11:20:35 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA03343; 4.1/CRI-5.6; Tue, 19 Jan 93 11:20:31 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.7) id AA17410; Tue, 19 Jan 93 11:20:29 CST Received: from hedgehog.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA23349; Tue, 19 Jan 1993 10:20:27 MST Date: Tue, 19 Jan 1993 10:20:26 MST From: "Sean O'Malley" Message-Id: <199301191720.AA12189@hedgehog.cs.arizona.edu> Received: by hedgehog.cs.arizona.edu; Tue, 19 Jan 1993 10:20:26 MST To: tcplw@cray.com Subject: slow start O. Rose states: > With respect to making TCP more aggressive: Take a look at > what will happen to a router when opening the window according > to the CURRENT TCP algorithm. You already get transient buffer- > loads in the order of the pipesize(!) during the exponential > opening phase (remember you are sending 2 packets in response > to each ACK received, and these ACKs will arrive approximately > at a rate that reflects the capabilities of the bottleneck). > > I think this is already difficult to deal with in routers > (imagine what will happen if you have to buffer several mega- > bytes of data for each connection that is currently recovering > using slow-start. Keep further in mind that connections tend > to synchronize, i.e. many connections passing through a congested > router will slow-start at about the same time. There suddenly > is a need to buffer N megabytes! Even if we assume that such a > lot of memory is available in modern routers (pretty expensive > since memory has to be VERY fast to support let's say 100 Mbit/s), > what about your poor retransmission-timers? > > Now, what will happen if you make TCP even more aggressive? > I think this is not the right direction we have to go in order > to control congestion in high-speed networks. Actually I was only concerned about the effect of large windows on the linear second phase of the slow start algorithm where you are adding one segment to the window per round trip. As you point out large windows have the effect of making the expontial first part of the window opening MORE aggresive. It may be a good idea to make the expontial part of the slow start less aggressive while makeing the linear part of the algorithm more aggressive. Sean Received: by hemlock.cray.com id AA26949; 4.1/CRI-5.6; Tue, 19 Jan 93 09:51:07 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA26943; 4.1/CRI-5.6; Tue, 19 Jan 93 09:51:04 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.7) id AA11398; Tue, 19 Jan 93 09:51:05 CST Received: from hedgehog.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA18388; Tue, 19 Jan 1993 08:51:03 MST Date: Tue, 19 Jan 1993 08:51:02 MST From: "Sean O'Malley" Message-Id: <199301191551.AA11656@hedgehog.cs.arizona.edu> Received: by hedgehog.cs.arizona.edu; Tue, 19 Jan 1993 08:51:02 MST To: Christian.Huitema@sophia.inria.fr, sean@cs.arizona.edu Subject: Re: correction Cc: end2end-interest@ISI.EDU, tcplw@cray.com Christian States > Any design should assume that NACKs can, and will, be lost or duplicated. I > would feel more confortable if the list of nacked packets could be repeated in > successive messages. In general you are of course correct but in this case the NACKs exist merely to speed up retransmission. There are no correctness issues. So the argument is basically do you believe that you will lose enough NACKs to affect performance? In any case dealing with lost and duplicate NACKs is fairly trivial. > I don't understand the purpose of sending "deltas" the way you describe. If > what you want is do derive the effective bandwidth of the link, why not let > the receiver build this estimate and send it? That would be a natural > generalization of the "packet pair" algorithm. All I am trying to do (so far with only fair success) is to minimally extend the reno mods to deal with more than one hole per window. The detla is an attempt to simulate what reno does with duplicate ACKs with NACKS. Moving the entire computation of the congetestion window to the reciver requires that every TCP packet contain a congestion window going in the other direction. A more general solution to this problem requires the addition of congestion control parameter(s) to the timestamp option. Something which is possible but probably unlikely. Sean Received: by hemlock.cray.com id AA20015; 4.1/CRI-5.6; Tue, 19 Jan 93 07:04:35 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA20011; 4.1/CRI-5.6; Tue, 19 Jan 93 07:04:32 CST Received: from mitsou.inria.fr by cray.com (4.1/CRI-MX 2.7) id AA01819; Tue, 19 Jan 93 07:04:32 CST Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA19439; Tue, 19 Jan 1993 13:46:34 +0100 Message-Id: <199301191246.AA19439@mitsou.inria.fr> To: "Sean O'Malley" Cc: tcplw@cray.com, end2end-interest@ISI.EDU Subject: Re: correction In-Reply-To: Your message of "Mon, 18 Jan 93 16:55:55 MST." <199301182355.AA01271@optima.cs.arizona.edu> Date: Tue, 19 Jan 93 13:46:33 +0100 From: Christian Huitema >Upon reflextion the sacked field of the NACK option should >contain the total number of new unacknoldged bytes in the >buffer since the last NACK. Sean, Any design should assume that NACKs can, and will, be lost or duplicated. I would feel more confortable if the list of nacked packets could be repeated in successive messages. I don't understand the purpose of sending "deltas" the way you describe. If what you want is do derive the effective bandwidth of the link, why not let the receiver build this estimate and send it? That would be a natural generalization of the "packet pair" algorithm. Christian Huitema Received: by hemlock.cray.com id AA14057; 4.1/CRI-5.6; Tue, 19 Jan 93 05:05:58 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA14053; 4.1/CRI-5.6; Tue, 19 Jan 93 05:05:55 CST Received: from bells.cs.ucl.ac.uk by cray.com (4.1/CRI-MX 2.7) id AA24624; Tue, 19 Jan 93 05:05:50 CST Message-Id: <9301191105.AA24624@cray.com> Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 19 Jan 1993 11:05:14 +0000 To: Sean O'Malley Cc: tcplw@cray.com, brakmo@cs.arizona.edu, llp@cs.arizona.edu, J.Crowcroft@cs.ucl.ac.uk Subject: Re: slow start and large windows In-Reply-To: Your message of "Mon, 18 Jan 93 11:31:24 MST." <199301181831.AA14725@optima.cs.arizona.edu> Date: Tue, 19 Jan 93 11:05:05 +0000 From: Zheng Wang >The Effect of Large Windows on TCP Slow Start > >The existing version of BSD TCP (or at least the latest one I >could fine) responds to a dropped packet by reducing the >congestion window to one segment and using the TCP slow >start algorithm to attempt to increase the congestion window >back to its orginal value. The stated reason for using this >algorithm is to avoid the cost of duplicate transmissions of >the entire window in the face of a single dropped segment. >While it does effectively avoid these retransmission the >use of this algorithm on networks with very large bandwidth >delay products is problematical. I think the TCP code you looked at is tahoe version (1988). The reno version (1990) handles the problem much better. >Conclusions: >Slow start has to be modified to be more aggressive in >increasing the congestion window when the window is large. >In particular the algorithm should be normalized so that the >time it takes to increase the congestion window back to its >original value is independent of its size. Making the slow start more aggressive will lead to greater oscillation of the window size under normal conditions. I think the right way to handle the problem is to prevent the pipe from going empty. If the pipe is not empty after the loss, you dont have to do slow start. In tahoe tcp, a single window is used for end-to-end flow control and for congestion control. The interaction has some undirable effects. In reno tcp, the window is used differently under normal condition and after losses. In case of single packet loss, reno can avoid pipe breakdown thus recover without slow-start. In case of multiple losses, we have to seperate the flow control and congestion control, and have more accurate info about the lost packets. We have a paper on a dual-window scheme, which can be ftp'ed from bells.cs.ucl.ac.uk 128.16.5.31 darpa/window.ps (a new version of the paper will be available soon with simulation results). You comments are welcome. Cheers Zheng Received: by hemlock.cray.com id AA11382; 4.1/CRI-5.6; Tue, 19 Jan 93 01:54:06 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA11378; 4.1/CRI-5.6; Tue, 19 Jan 93 01:54:02 CST Received: from mitsou.inria.fr by cray.com (4.1/CRI-MX 2.7) id AA06286; Tue, 19 Jan 93 01:53:59 CST Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA18711; Tue, 19 Jan 1993 08:56:28 +0100 Message-Id: <199301190756.AA18711@mitsou.inria.fr> To: partho@cs.UMD.EDU (partho pratim mishra) Cc: floyd@ee.lbl.gov, sean@cs.arizona.edu, tcplw@cray.com Subject: Re: slow start and large windows In-Reply-To: Your message of "Mon, 18 Jan 93 16:30:19 EST." <9301182130.AA07220@seine.cs.UMD.EDU> Date: Tue, 19 Jan 93 08:56:27 +0100 From: Christian Huitema You are absolutely correct. The current slow start parameters, and in particular the "1 packet per RTT" of the linear phase, are obviously dependant of the relation between throughput and delay. Having SACKs, however, enables more than just a scaled up version of the low-star algorithm. If you assume that most losses are due to congestion, then SACKs can let you estimate how many packets (or bytes) were effectively received during the RTT. This gives you a direct estimation of the effective bandwidth available! Tuning for smthg like "the available bandwidth + some margin" would look like a reasonable idea + would also avoid the "saw's teeth" effect of the low star. Christian Huitema Received: by hemlock.cray.com id AA26704; 4.1/CRI-5.6; Mon, 18 Jan 93 17:56:01 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA26700; 4.1/CRI-5.6; Mon, 18 Jan 93 17:55:58 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.7) id AA19295; Mon, 18 Jan 93 17:55:57 CST Date: Mon, 18 Jan 1993 16:55:55 MST From: "Sean O'Malley" Message-Id: <199301182355.AA01271@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA01271; Mon, 18 Jan 1993 16:55:55 MST To: tcplw@cray.com Subject: correction Upon reflextion the sacked field of the NACK option should contain the total number of new unacknoldged bytes in the buffer since the last NACK. the sender should compute cnwnd = cnwnd + sacked and use min(swnd, cnwnd) as effective window Basically the reciver is telling the sender how many bytes it has removed from the pipe. (In this case underestimating it but the reciver probably has enough information to compute it precisely) Sean Received: by hemlock.cray.com id AA24872; 4.1/CRI-5.6; Mon, 18 Jan 93 17:14:44 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA24817; 4.1/CRI-5.6; Mon, 18 Jan 93 17:14:37 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.7) id AA17093; Mon, 18 Jan 93 17:14:35 CST Received: from hedgehog.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA29271; Mon, 18 Jan 1993 16:14:33 MST Date: Mon, 18 Jan 1993 16:14:32 MST From: "Sean O'Malley" Message-Id: <199301182314.AA11019@hedgehog.cs.arizona.edu> Received: by hedgehog.cs.arizona.edu; Mon, 18 Jan 1993 16:14:32 MST To: tcplw@cray.com Subject: NACK option My Proposed SACK Option Alternate: Given Van's Reno mods and some minor modification to the slow start algorithm (al la Floyd and Van) the only known outstanding problem with tcplw is what to do about cases where more than one packet is dropped per window. The duplicate ACK detection in Reno is no help here because there is no timely way for the receiver to notify the sender of exactly which packets are missing and hence the sender cannot re- transimit them, the pipe empties, and one is forced to reduce the congestion window to one segment and slow start. The original SACK option was proposed as a way to get around this problem. The basic problem with this option was that it required that the sender keep around a list of sent but unacked segments. As originally proposed the SACK option truncated the offsets of the SACK'ed segments to 16 bits. The only way that the sender can know what to retransmit is if it keeps information about the segments that it has sent. Since the BSD implementation and its derivatives do not keep such a list the SACK option as proposed would require significant changes to TCP. At the risk of re-inventing the wheel again (I have not seen an implementation of Van's proposed SACK option.) I will propose an alternate to the SACK option. The NACK option: A new NACK option would be defined which contained a 32 bit OFFSET field from the ACK field of the message it is contained in, a 32 bit LENGTH field, and a 32 bit SACKED field which contains the total number of unacknowledged bytes in the receivers buffer. The receiver would keep track of the most recent hole in its receive buffer and if a threshold number of packets beyond this hole were received it would send out a NACK for that hole. The current hole pointer would then be moved to the next hole in the receive buffer (if any). The NACK would contain the offset and length of the hole and the total number of unacknowledged bytes in the buffer. The sender upon receiving a NACK would: 1. Cut the congestion window by 1/2 (al la Reno) 2. Set variable sacked equal to SACKED field in NACK option. 3. Use min(snd_wnd, cwnd+sacked) as the effective window size. 4. Retransmit the offending segment (or segments). 5. Set retransmission timer to at least 1 RTT. The net effect of this change is that retransmission is now primarily the responsibility of the NACK option. Time-outs should only occur when NACKs or re-transmitted segments are lost. The actual algorithm is quite similar to Reno. The primary advantage of this approach is that it is simpler and a much smaller source delta of the existing TCP implementations. The sender keeps no additional information beyond the sacked variable. The receiver needs only to keep track of the oldest hole in its receiver buffer and the total number of unacknowledged bytes. A secondary advantage is that only one NACK entry is needed. The original SACK option was based upon the assumption that at least 6 sacked ranges were required. As far as I can tell the need for multiple ranges is eliminated by sending the SACKED field. In particular if one resets the transmission timer there appears to be no need for the sender to keep track of exactly which segments are in the receivers buffer. If no re-transmitted segments or NACKs are lost no unnecessary re-retransmits will be performed. (Even if a retransmit is lost the Tahoe algorithm with prevent and serious duplicate retransmissions.) If desired dropped NACK's can be handled by having the receiver send NACKs whenever it would previously send duplicate ACKs and/or by sending the n most recent holes in the NACK where n is some small threshold. There is no way to really detect a dropped retransmit which would cause the original Tahoe TCP congestion control algorithm to be invoked. IE the congestion window would be decreased to one segment and slow start would be invoked to fill the pipe. I don't think this is a problem because if you lost a segment and its retransmission you are probably experiencing sever congestion and want to take sever corrective action anyway. The sender resetting the retransmit timer will however result in an extra round trip delay in such case (which should be rare). Note that give this option the need for an accurate RTT estimate is greatly reduced. As long as RTT is greater than the true round trip time TCP+NACK should work efficiently. Fast re- transmits are generated by NACKs not time-outs. Hence is the tcplw timestamp option really required? Sean O'Malley Received: by hemlock.cray.com id AA19450; 4.1/CRI-5.6; Mon, 18 Jan 93 15:30:32 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA19446; 4.1/CRI-5.6; Mon, 18 Jan 93 15:30:28 CST Received: from seine.cs.UMD.EDU by cray.com (4.1/CRI-MX 2.7) id AA11221; Mon, 18 Jan 93 15:30:26 CST Received: by seine.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA07220; Mon, 18 Jan 93 16:30:19 -0500 Date: Mon, 18 Jan 93 16:30:19 -0500 From: partho@cs.UMD.EDU (partho pratim mishra) Message-Id: <9301182130.AA07220@seine.cs.UMD.EDU> To: floyd@ee.lbl.gov, sean@cs.arizona.edu Subject: Re: slow start and large windows Cc: tcplw@cray.com A typo in my last message: > However, apparently Van did know about this change. should be >>However, apparently Van did NOT know about this change. Received: by hemlock.cray.com id AA19173; 4.1/CRI-5.6; Mon, 18 Jan 93 15:25:14 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA19169; 4.1/CRI-5.6; Mon, 18 Jan 93 15:25:11 CST Received: from lena.cs.UMD.EDU by cray.com (4.1/CRI-MX 2.7) id AA10566; Mon, 18 Jan 93 15:25:07 CST Received: from localhost by lena.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA04196; Mon, 18 Jan 93 16:24:59 -0500 Message-Id: <9301182124.AA04196@lena.cs.UMD.EDU> To: "Sean O'Malley" Cc: braden@ISI.EDU, tcplw@cray.com, brakmo@cs.arizona.edu, llp@cs.arizona.edu, partho@cs.UMD.EDU Subject: Re: slow start and large windows In-Reply-To: Your message of "Mon, 18 Jan 93 13:41:12 MST." <199301182041.AA10725@hedgehog.cs.arizona.edu> Date: Mon, 18 Jan 93 16:24:55 -0500 From: Partho Mishra > I still think that the linear slow start algorithm is wrong for > networks with large bandwidth delay products and is > too pessimistic. If you are really attempting to use slow start to > do rate control the total amount of time it takes to recover from > congestion should be the same regardless of the bandwidth delay product. > Therefore slow start should be faster on higher bandwidth networks > This would be easy to do by adjusting the constants in the existing > slow start. Ie How long to you keep increasing expontially vs. what > constant factor you use during the linear phase (currently it is > 1 it might be 5 or 10). This seems fairly obvious. Clearly it is a good idea to adjust the constants of an algorithm depending on the operating environment (speed of links, buffer sizes). Van Jacobson motivated the choice of the constants in the original Sigcomm '88 paper using the then operational environment; it is not clear why these choices should be useful if and when the operating environment changes. Interesting we had a version of the Reno code, here at Maryland, which added an exponential component (maxseg/8) to the linear increase rule. * When new data is acked, open the congestion window. * If the window gives us less than ssthresh packets * in flight, open exponentially (maxseg per packet). * Otherwise open linearly: maxseg per window * (maxseg^2 / cwnd per packet), plus a constant * fraction of a packet (maxseg/8) to help larger windows * open quickly enough. This would cause a much faster increase at the cost of potentially more lost packets. However, apparently Van did know about this change. Thus at this point I am not sure what is standard for 4.3 BSD Reno versions. -Partho Mishra Received: by hemlock.cray.com id AA18995; 4.1/CRI-5.6; Mon, 18 Jan 93 15:21:34 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA18989; 4.1/CRI-5.6; Mon, 18 Jan 93 15:21:28 CST Received: from helios.ee.lbl.gov by cray.com (4.1/CRI-MX 2.7) id AA10067; Mon, 18 Jan 93 15:21:25 CST Received: by helios.ee.lbl.gov for tcplw@cray.com (5.65/1.43) id AA15037; Mon, 18 Jan 93 13:21:16 -0800 From: floyd@ee.lbl.gov (Sally Floyd) Message-Id: <9301182121.AA15037@helios.ee.lbl.gov> To: "Sean O'Malley" Cc: brakmo@cs.arizona.edu, llp@cs.arizona.edu, braden@isi.edu, tcplw@cray.com Subject: Re: slow start and large windows Date: Mon, 18 Jan 93 13:21:15 PST >I still think that the linear slow start algorithm is wrong for >networks with large bandwidth delay products and is >too pessimistic. If you are really attempting to use slow start to >do rate control the total amount of time it takes to recover from >congestion should be the same regardless of the bandwidth delay product. >Therefore slow start should be faster on higher bandwidth networks >This would be easy to do by adjusting the constants in the existing >slow start. Ie How long to you keep increasing expontially vs. what >constant factor you use during the linear phase (currently it is >1 it might be 5 or 10). Van and I have several articles that discuss changes to the slow start algorithm that would result in improving the time to recover from congestion for connections with larger bandwidth delay products. See the section on Interactions with Window Adjustment Algorithms in Floyd, S., and Jacobson, V., Traffic Phase Effects in Packet-Switched Gateways, Computer Communication Review, V.21 N.2, April 1991, pp. 26-42. or in the journal version of the same article: \bibitem[FJ92]{FJ92} Floyd, S., and Jacobson, V., On Traffic Phase Effects in Packet-Switched Gateways, Internetworking: Research and Experience, V.3 N.3, September 1992, p.115-156. For more analysis, see: Floyd, S., Connections with Multiple Congested Gateways in Packet-Switched Networks Part 1: One-way Traffic, Computer Communication Review, V.21 N.5, October 1991, pp. 30-47. The material in these articles was intended in the spirit of research, not in the spirit of proposals for action. We have another paper in progress (but which unfortunately has been on hold for some time) that will discuss modified versions of this window increase algorithm. - Sally ____ Received: by hemlock.cray.com id AA17993; 4.1/CRI-5.6; Mon, 18 Jan 93 15:04:12 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA17989; 4.1/CRI-5.6; Mon, 18 Jan 93 15:04:08 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.7) id AA08573; Mon, 18 Jan 93 15:04:06 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Mon, 18 Jan 1993 13:02:23 -0800 Date: Mon, 18 Jan 1993 13:02:23 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199301182102.AA07791@zephyr.isi.edu> To: braden@ISI.EDU, sean@cs.arizona.edu, tcplw@cray.com Subject: Re: slow start and large windows Cc: brakmo@cs.arizona.edu, llp@cs.arizona.edu > It should be a note in the RFC that you must implement van's modification > to support tcplw. > > There's a more general problem, that this work exists only by example in Tahoe (and is widely implemented), but it has never been documented as far as I know. The closest thing is a set of overheads that Van used at an IETF meeting. The words that go with the overheads was partial gibberish, unfortunately. I guess the E2E RG dropped the ball. > > I still think that the linear slow start algorithm is wrong for > networks with large bandwidth delay products and is > too pessimistic. If you are really attempting to use slow start to > do rate control Huh? Bob Received: by hemlock.cray.com id AA16560; 4.1/CRI-5.6; Mon, 18 Jan 93 14:41:19 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA16556; 4.1/CRI-5.6; Mon, 18 Jan 93 14:41:16 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.7) id AA07068; Mon, 18 Jan 93 14:41:15 CST Received: from hedgehog.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA21636; Mon, 18 Jan 1993 13:41:13 MST Date: Mon, 18 Jan 1993 13:41:12 MST From: "Sean O'Malley" Message-Id: <199301182041.AA10725@hedgehog.cs.arizona.edu> Received: by hedgehog.cs.arizona.edu; Mon, 18 Jan 1993 13:41:12 MST To: braden@ISI.EDU, sean@cs.arizona.edu, tcplw@cray.com Subject: Re: slow start and large windows Cc: brakmo@cs.arizona.edu, llp@cs.arizona.edu Bob states: > o Slow-start is essential in the current Internet, because many routers > are buffer-poor. However if your bandwidth delay protocol is 7.5 megabytes you can probably safefly assume that you are not on the current internetwork. >o Van solved precisely the problem you are worried about, some 4-5 years > ago. The "more benign" algorithm is embodied in the Fast-Retransmit/ > Congestion Avoidance code, which you will also find in BSD TCP. Someone kindly got me a copy of that email and yes it does address the problem by getting rid of the need to go back to one segment. It should be a note in the RFC that you must implement van's modification to support tcplw. >o Making TCP more aggressive is NOT a good idea. However, I think it > is possible to make a SACK scheme (I assume that is what is behind your > comments) that is consistent with congestion avoidance. We can talk > bout this later this week. I still think that the linear slow start algorithm is wrong for networks with large bandwidth delay products and is too pessimistic. If you are really attempting to use slow start to do rate control the total amount of time it takes to recover from congestion should be the same regardless of the bandwidth delay product. Therefore slow start should be faster on higher bandwidth networks This would be easy to do by adjusting the constants in the existing slow start. Ie How long to you keep increasing expontially vs. what constant factor you use during the linear phase (currently it is 1 it might be 5 or 10). Received: by hemlock.cray.com id AA14653; 4.1/CRI-5.6; Mon, 18 Jan 93 14:04:00 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA14649; 4.1/CRI-5.6; Mon, 18 Jan 93 14:03:57 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.7) id AA04267; Mon, 18 Jan 93 14:03:50 CST Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA18635; Mon, 18 Jan 93 11:50:11 -0800 To: tcplw@cray.com Reply-To: skibo@florida.wpd.sgi.com (Thomas Skibo) X-Approved: newsmail@sgi.sgi.com From: skibo@florida.wpd.sgi.com (Thomas Skibo) Subject: Re: slow start and large windows Message-Id: Date: Mon, 18 Jan 1993 19:49:16 GMT > Suppose one has a 600 megabit/second coast-to-coast > connection. The bandwidth delay product (and hence the largest > possible window size) is 7.5 megabytes. If the MSS stays at > 512 bytes (which is not an unreasonable assumption) this > gives an N of about 14000 and implies that it will take > approximately 7000 RTT's to reach the original congestion > window. On a coast-to-coast connection with a 100 > millisecond RTT this would take 700 seconds. If random > packet drops take place more often than this the TCP > congestion window will never reach the bandwidth delay > product. I don't know about the 512 byte MSS. I think if you're serious about doing high-speed TCP, you need to use a bigger MSS (either with MTU discovery or manually putting MTU specifications in route entries so that the default MSS isn't chosen). --- Thomas Skibo Advanced Networking, Silicon Graphics skibo@sgi.com Received: by hemlock.cray.com id AA13774; 4.1/CRI-5.6; Mon, 18 Jan 93 13:50:11 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13770; 4.1/CRI-5.6; Mon, 18 Jan 93 13:50:07 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.7) id AA03261; Mon, 18 Jan 93 13:50:03 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Mon, 18 Jan 1993 11:48:17 -0800 Date: Mon, 18 Jan 1993 11:48:17 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199301181948.AA07337@zephyr.isi.edu> To: tcplw@cray.com, sean@cs.arizona.edu Subject: Re: slow start and large windows Cc: brakmo@cs.arizona.edu, llp@cs.arizona.edu Sean, I think the issue you raise would be most effectively discussed on the end2end-interest list. However, in brief: o Slow-start is essential in the current Internet, because many routers are buffer-poor. o Van solved precisely the problem you are worried about, some 4-5 years ago. The "more benign" algorithm is embodied in the Fast-Retransmit/ Congestion Avoidance code, which you will also find in BSD TCP. o Making TCP more aggressive is NOT a good idea. However, I think it is possible to make a SACK scheme (I assume that is what is behind your comments) that is consistent with congestion avoidance. We can talk bout this later this week. Bob Braden Received: by hemlock.cray.com id AA13650; 4.1/CRI-5.6; Mon, 18 Jan 93 13:47:35 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13644; 4.1/CRI-5.6; Mon, 18 Jan 93 13:47:31 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.7) id AA02840; Mon, 18 Jan 93 13:47:25 CST Received: from [192.26.75.8] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA17659; Mon, 18 Jan 93 11:36:04 -0800 Received: by florida.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:sean@cs.arizona.edu id AA00614; Mon, 18 Jan 93 11:36:03 -0800 Date: Mon, 18 Jan 93 11:36:03 -0800 From: skibo@florida.wpd.sgi.com (Thomas Skibo) Message-Id: <9301181936.AA00614@florida.wpd.sgi.com> To: "Sean O'Malley" Subject: Re: slow start and large windows Cc: tcplw@cray.com > Suppose one has a 600 megabit/second coast-to-coast > connection. The bandwidth delay product (and hence the largest > possible window size) is 7.5 megabytes. If the MSS stays at > 512 bytes (which is not an unreasonable assumption) this > gives an N of about 14000 and implies that it will take > approximately 7000 RTT's to reach the original congestion > window. On a coast-to-coast connection with a 100 > millisecond RTT this would take 700 seconds. If random > packet drops take place more often than this the TCP > congestion window will never reach the bandwidth delay > product. I don't know about the 512 byte MSS. I think if you're serious about doing high-speed TCP, you need to use a bigger MSS (either with MTU discovery or manually putting MTU specifications in route entries so that the default MSS isn't chosen). --- Thomas Skibo Advanced Networking, Silicon Graphics skibo@sgi.com Received: by hemlock.cray.com id AA11759; 4.1/CRI-5.6; Mon, 18 Jan 93 13:16:21 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA11755; 4.1/CRI-5.6; Mon, 18 Jan 93 13:16:17 CST Received: from lena.cs.UMD.EDU by cray.com (4.1/CRI-MX 2.7) id AA00556; Mon, 18 Jan 93 13:16:16 CST Received: from localhost by lena.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA03585; Mon, 18 Jan 93 14:16:09 -0500 Message-Id: <9301181916.AA03585@lena.cs.UMD.EDU> To: sean@cs.arizona.edu Cc: tcplw@cray.com, brakmo@cs.arizona.edu, llp@cs.arizona.edu, partho@cs.UMD.EDU Subject: Re: slow start and large windows In-Reply-To: Your message of "Mon, 18 Jan 93 11:31:24 MST." <199301181831.AA14725@optima.cs.arizona.edu> Date: Mon, 18 Jan 93 14:16:03 -0500 From: Partho Mishra Sean, In our Sigcomm 92 paper and in the companion technical memorandum ("A Hop by hop rate based congestion control scheme" - Mishra and Kanakia) we talked about the same problem with TCP Tahoe. > The existing version of BSD TCP (or at least the latest one I > could find) TCP Reno does things differently. Van's original mail to the end to end mailing group provides the best description of the changes from Tahoe to Reno. >It is congestion control rather that the cost of duplicate >retransmissions which will have the most effect upon the >achievable bandwidth in the face of dropped packets in >networks with large bandwidth delay products. The degree of lost throughput caused by a TCP connection taking a long time to reach the original window size after a loss depends on the amount of available buffering and whether random losses occur. If there are no random losses and the amount of buffering is equal to about one bandwidth x (round trip delay) product, then the amount of throughput lost is not very high. This is because even when the window size is W/2 (where the window size just before the loss was W) the "pipe" may be almost full. However if there is lesser buffering available then there can be a lot of loss in throughput, as you point out. In the presence of random losses, TCP throughput can get shot to pieces. We showed in a recent paper that even at 1-2% loss rates the throughput of a TCP connection is affected badly. The 1-2% loss figure is something we have discovered in Internet experiments (we are still doing experiments to establish how common the problem of random loss is). However, this problem has more to do with the choice of loss as a congestion identification mechanism than the use of the window increase/decrease mechanisms of Slow Start / Cong Avoidance. > It may be time to re-examine TCP congestion control from > scratch. See Zhang's virtual clock work or TP++. If you check the congestion control literature I think you will find several new mechanisms that have been proposed over the last couple of years which should provide better performance compared to TCP albeit at the cost of providing explicit feedback information. -Partho Mishra Received: by hemlock.cray.com id AA09632; 4.1/CRI-5.6; Mon, 18 Jan 93 12:31:37 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA09624; 4.1/CRI-5.6; Mon, 18 Jan 93 12:31:32 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.7) id AA27143; Mon, 18 Jan 93 12:31:27 CST Date: Mon, 18 Jan 1993 11:31:24 MST From: "Sean O'Malley" Message-Id: <199301181831.AA14725@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA14725; Mon, 18 Jan 1993 11:31:24 MST To: tcplw@cray.com Subject: slow start and large windows Cc: brakmo@cs.arizona.edu, llp@cs.arizona.edu The Effect of Large Windows on TCP Slow Start The existing version of BSD TCP (or at least the latest one I could fine) responds to a dropped packet by reducing the congestion window to one segment and using the TCP slow start algorithm to attempt to increase the congestion window back to its orginal value. The stated reason for using this algorithm is to avoid the cost of duplicate transmissions of the entire window in the face of a single dropped segment. While it does effectively avoid these retransmission the use of this algorithm on networks with very large bandwidth delay products is problematical. Note it is unclear to me if this use of slow start is required by the specification or a BSD'ism. TCP slow start works by increasing the congestion window exponentially with respect to round trip times until 1/2 of the original window is reached and at that point slow start increases the congestion window by one maximum segment size per round trip. Thus the time it takes to reach the original congestion window is: (log2(n/2) + n/2) * the round trip time(RTT) where n = window size/maximum segment size(MSS) Where n is large this algorithm will take a great deal of time to achieve the original window after a dropped packet. Suppose one has a 600 megabit/second coast-to-coast connection. The bandwidth delay product (and hence the largest possible window size) is 7.5 megabytes. If the MSS stays at 512 bytes (which is not an unreasonable assumption) this gives an N of about 14000 and implies that it will take approximately 7000 RTT's to reach the original congestion window. On a coast-to-coast connection with a 100 millisecond RTT this would take 700 seconds. If random packet drops take place more often than this the TCP congestion window will never reach the bandwidth delay product. Note even if one assumes a 45 Mbits T3 connection it would still take 50 seconds to reach the orginal congestion window after a dropped packet. In high speed networks the invocation of the slow start algorithm for each dropped packet will significantly decrease the effective bandwidth of the connection for 1000's of RTT's after the packet drop. This effect swamps any potential benefit from avoiding the retransmission of packets already in the receivers buffer. Conclusions: It is congestion control rather that the cost of duplicate retransmissions which will have the most effect upon the achievable bandwidth in the face of dropped packets in networks with large bandwidth delay products. Slow start has to be modified to be more aggressive in increasing the congestion window when the window is large. In particular the algorithm should be normalized so that the time it takes to increase the congestion window back to its original value is independent of its size. Using slow start to avoid the unnecessary retransmissions missions is overkill and some other method (SACK's, NACK's or playing with timers) should be used to solve this problem. While some congestion control is probably be required for each dropped packet the existing reduction of the congestion window to one segment and invoking slow start appears draconian. Some other more benign algorithm would appear to be called for. It may be time to re-examine TCP congestion control from scratch. See Zhang's virtual clock work or TP++. Received: by hemlock.cray.com id AA28843; 4.1/CRI-5.6; Thu, 7 Jan 93 15:26:02 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA28839; 4.1/CRI-5.6; Thu, 7 Jan 93 15:25:59 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.4) id AA15593; Thu, 7 Jan 93 15:25:56 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Thu, 7 Jan 1993 13:24:27 -0800 Date: Thu, 7 Jan 1993 13:24:27 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199301072124.AA02632@zephyr.isi.edu> To: tcplw@cray.com, swise@austin.ibm.com Subject: Re: TCP MSS & Timestamps Stevo, The MSS option is designed/intended to tell the remote TCP about the properties of the host that sent the option, independent of the path. It basically tells what is the largest transport-layer object that the host can receive and reassemble. For a BSD system, that limit is (?) 64K, so it would be correct for a BSD system to advertise an MSS of 65535. Given this data, and its own knowledge about the network path (and the presence of TCP and/or IP options), the host that receives the MSS option can determine the largest datagram it can actually send. On the other hand, A BSD host sends an MSS option that reflects its own opinion about the route. Thus, for a non-local destination, it sends an MSS of 536 (or else it doesn't send it, assuming the default; I've forgotten). This means the remote host MAY NOT send a segment larger than 536, even if the remote host KNOWS (e.g. from MTU Discovery, or special knowledge) that it could send a larger segment. Even if MTU Discovery is installed, the approach will prevent its handling assymmetric paths correctly. Bob Braden Received: by hemlock.cray.com id AA26382; 4.1/CRI-5.6; Thu, 7 Jan 93 14:50:19 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA26378; 4.1/CRI-5.6; Thu, 7 Jan 93 14:50:15 CST Received: from netmail.austin.ibm.com by cray.com (4.1/CRI-MX 2.4) id AA13015; Thu, 7 Jan 93 14:50:14 CST Received: from vikings.austin.ibm.com by netmail.austin.ibm.com (AIX 3.1/UCB 5.61/gw.0.7) for tcplw@cray.com at cray.com id AA18718; Thu, 7 Jan 93 14:50:13 -0600 Received: by vikings.austin.ibm.com (AIX 3.2/UCB 5.64/4.03-client-2.4) for tcplw@cray.com at austin.ibm.com; id AA85829; Thu, 7 Jan 1993 14:50:11 -0600 From: swise@austin.ibm.com (Stevo Bevo-Devo Wise) Message-Id: <9301072050.AA85829@vikings.austin.ibm.com> To: tcplw@cray.com Subject: Re: TCP MSS & Timestamps In-Reply-To: (Your message of Thu, 07 Jan 93 12:36:01 PST.) <199301072036.AA01838@zephyr.isi.edu> Date: Thu, 07 Jan 93 14:50:10 -0600 braden@ISI.EDU says: | | Dave, | | I basically agree with your analysis. When I implemented the RFC-1323 | changes, I ran into this problem, so I went and looked at what I wrote | in RFC-1122. I spent a lot of effort on the discussion of MSS and | segments sizes in RFC-1122, but rereading it, I find it is not as clear | as I would like. I guess the problem was that we had to water it down, | because this was an area where BSD Unix violates the intent of the | protocols. I tried to suggest to people to do the right thing without Could you elaborate on what BSD Unix is doing to violate the intent of the protocols? Is this in respect to how MSS is computed in BSD TCP? Thanx, Stevo. Received: by hemlock.cray.com id AA25503; 4.1/CRI-5.6; Thu, 7 Jan 93 14:37:39 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA25495; 4.1/CRI-5.6; Thu, 7 Jan 93 14:37:33 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.4) id AA12104; Thu, 7 Jan 93 14:37:31 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Thu, 7 Jan 1993 12:36:01 -0800 Date: Thu, 7 Jan 1993 12:36:01 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199301072036.AA01838@zephyr.isi.edu> To: tcplw@cray.com, dab@berserkly.cray.com Subject: Re: TCP MSS & Timestamps Dave, I basically agree with your analysis. When I implemented the RFC-1323 changes, I ran into this problem, so I went and looked at what I wrote in RFC-1122. I spent a lot of effort on the discussion of MSS and segments sizes in RFC-1122, but rereading it, I find it is not as clear as I would like. I guess the problem was that we had to water it down, because this was an area where BSD Unix violates the intent of the protocols. I tried to suggest to people to do the right thing without actually fighting with any BSD person about it. I ended up doing a significant reorganization of how MSS is computed and used in SunOS TCP, to handle this problem properly. Bob Received: by hemlock.cray.com id AA24315; 4.1/CRI-5.6; Thu, 7 Jan 93 14:15:31 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA24308; 4.1/CRI-5.6; Thu, 7 Jan 93 14:15:27 CST Received: from handel.cray.com.cray.com by cray.com (4.1/CRI-MX 2.4) id AA10851; Thu, 7 Jan 93 14:15:26 CST Received: by handel.cray.com.cray.com id AA14604; 5.65/CRI-5.5; Thu, 7 Jan 1993 14:12:12 -0600 Date: Thu, 7 Jan 1993 14:12:12 -0600 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9301072012.AA14604@handel.cray.com.cray.com> To: tcplw@cray.com Subject: TCP MSS & Timestamps In recent private mail conversation, it has come to my attention that we probably don't all have a common view on what to do with the TCP MSS value in the presence of TCP options, since the TCP MSS value only refers to the TCP data part of the packet, and the presence of TCP options will affect that value. Since 1323 is eligible for elevation to Draft status, this is a good time to revise the document to clarify this issue. First, there is a maximum packet size. When you insert options, the amount of space available for TCP data within a non-fragmented IP packet goes down by the length of the options. So, the option length needs to be accounted for. The "be conservative in what you send" rule can be applied in two ways. The first is in the generation of the MSS value, you can say "well, I'll assume that the other side won't adjust for the length of the options, so I'll adjust for the option length when sending the MSS". Meanwhile, on the other side, when sending a packet, you can say "well, I'll assume that the other side did not adjust for the options length when it sent the MSS, and so I'll decrease the data size by the option length". You can do both, but then the packets will usually be short. So, you should pick one or the other, but not both. With two places to do the accounting for the options vs. the MSS value, you get a grid like: | MSS is adjusted | MSS is not adjusted | for options | for options ----------------+-----------------------+-------------------- Sender adjusts | packets are too | packets are the length for | short | correct length options | | ----------------+-----------------------+-------------------- Sender doesn't | packets are the | packets are too adjust length | correct length | long. for options | | The bottom right-hand corner is what we want to avoid, since that is the case when IP will have to fragment the packet. The only way that the side that is sending the datagrams can guarantee that it doesn't send IP packets that are too long is to always adjust the data length by the length of the options. It would be better to send a packet that is a few bytes too short rather than one that is a few bytes too long. So, the bottom line is that I'd like to see a paragraph added to 1323 stating that the generated MSS value only takes into account the fixed IP and TCP header lengths, and that the side that is generating the datagrams needs to adjust the length of the TCP data to account for any IP or TCP options that it inserts into the datagram. Anyone disagree? -David Borman, dab@cray.com Received: by hemlock.cray.com id AA04749; 4.1/CRI-5.6; Wed, 6 Jan 93 02:57:04 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA04745; 4.1/CRI-5.6; Wed, 6 Jan 93 02:57:01 CST Received: from mitsou.inria.fr by cray.com (4.1/CRI-MX 2.4) id AA19210; Wed, 6 Jan 93 02:56:58 CST Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA13436; Wed, 6 Jan 1993 09:59:18 +0100 Message-Id: <199301060859.AA13436@mitsou.inria.fr> To: "Sean O'Malley" Cc: braden@ISI.EDU, tcplw@cray.com Subject: Re: SACK In-Reply-To: Your message of "Tue, 05 Jan 93 11:49:51 MST." <199301051849.AA04964@optima.cs.arizona.edu> Date: Wed, 06 Jan 93 09:59:15 -0500 From: Christian Huitema Sean, Back in 81-82, we implemented a scheme which was very near from the proposed TCP SACK in the "bulk transfer protocol" of the NADIR project, for satellite networks. I remember that maintaining and accessing the list of sacked segments was absolutely non trivial. Out of your two choices, I would consider that we drop "1- Avoid retransmission of SACKed segments." It is difficult to implement, and there seem to be an agreement that we need "soft sacks" anyhow. In this case, we can concentrate on "2- Speed retransmission of unsacked segments", i.e. consider the "sacks" as "advisory nacks". Implementing nacks only makes the memory management much simpler. At worst, you can start from the "last acked packet" and count down the transmitted segments. That is indeed expensive but: 1) way less expensive than actually retransmitting all the counted down segments, 2) often very short as the basic sack is of the form "ack up to N1, sack N2-N3", which means that you have to retransmit the segments located immediately after the last acked packet. The real problem with "soft sacks" or "advisory nacks" have to do with nack filtering, so that duplicate sacks will not cause multiple retransmissions of a missing segment, and interaction with the congestion control mechanisms -- what do we call now a "congestion window"? Christian Huitema Received: by hemlock.cray.com id AA25435; 4.1/CRI-5.6; Tue, 5 Jan 93 12:50:09 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA25424; 4.1/CRI-5.6; Tue, 5 Jan 93 12:50:04 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.4) id AA14513; Tue, 5 Jan 93 12:50:02 CST Date: Tue, 5 Jan 1993 11:49:51 MST From: "Sean O'Malley" Message-Id: <199301051849.AA04964@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA04964; Tue, 5 Jan 1993 11:49:51 MST To: braden@ISI.EDU, sean@cs.arizona.edu, tcplw@cray.com Subject: Re: SACK bob states: > We did an experimental SACK implementation here. Some more questions: What TCP was it based upon? BSD? What was the goal of the SACK option in your implementation. I have considered two different goals: 1) Avoid retransmission of SACKed segments. 2) Speed retransmission of unsacked segments Was it a hard or soft SACK. Is the source code avilable (to look at not to run)? How extensive where the required changes? Sean Received: by hemlock.cray.com id AA20000; 4.1/CRI-5.6; Tue, 5 Jan 93 11:40:20 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA19996; 4.1/CRI-5.6; Tue, 5 Jan 93 11:40:16 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.4) id AA10867; Tue, 5 Jan 93 11:40:14 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Tue, 5 Jan 1993 09:38:46 -0800 Date: Tue, 5 Jan 1993 09:38:46 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199301051738.AA03974@zephyr.isi.edu> To: tcplw@cray.com, sean@cs.arizona.edu Subject: Re: SACK > From tcplw-relay@cray.com Tue Jan 5 08:53:39 1993 > Date: Tue, 5 Jan 1993 09:54:32 MST > From: "Sean O'Malley" > To: tcplw@cray.com > Subject: SACK > Content-Length: 576 > X-Lines: 13 > > > I have been attempting to implement a variation of the > originally proposed SACK option. Because the version of TCP I > am starting from (an x-kernelized version of the BSD TCP) > does not keep a list of transmitted segments implementing > SACK requires extensive code modifications. Getting rid of the > scaling on the SACK ranges helps somewhat but it is still not a > trivial modification. I was wondering if there are any TCP > implementations that keep a list of transmitted segments > around? It would also be nice to know if anyone else has > implemented SACK. > > Sean O'Malley > Sean, We did an experimental SACK implementation here. However, the SACK spec we were considering used sequence numbers, so it would work with a TCP that did not keep a list of transmitted segments. There are not very many TCPs around that do keep such a list, I suspect. I once wrote one that did, but I have decided the Berkeley guys got this one right, and would not do it again. Bob Braden Received: by hemlock.cray.com id AA16653; 4.1/CRI-5.6; Tue, 5 Jan 93 10:54:46 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA16612; 4.1/CRI-5.6; Tue, 5 Jan 93 10:54:36 CST Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.4) id AA07709; Tue, 5 Jan 93 10:54:34 CST Date: Tue, 5 Jan 1993 09:54:32 MST From: "Sean O'Malley" Message-Id: <199301051654.AA29406@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA29406; Tue, 5 Jan 1993 09:54:32 MST To: tcplw@cray.com Subject: SACK I have been attempting to implement a variation of the originally proposed SACK option. Because the version of TCP I am starting from (an x-kernelized version of the BSD TCP) does not keep a list of transmitted segments implementing SACK requires extensive code modifications. Getting rid of the scaling on the SACK ranges helps somewhat but it is still not a trivial modification. I was wondering if there are any TCP implementations that keep a list of transmitted segments around? It would also be nice to know if anyone else has implemented SACK. Sean O'Malley Received: by hemlock.cray.com id AA15752; 4.1/CRI-5.6; Fri, 18 Dec 92 09:19:28 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA15748; 4.1/CRI-5.6; Fri, 18 Dec 92 09:19:24 CST Received: from relay1.UU.NET by cray.com (4.1/CRI-MX 2.4) id AA15786; Fri, 18 Dec 92 09:19:22 CST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18640; Fri, 18 Dec 92 10:19:20 -0500 Received: from unirsvl.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 101831.17294; Fri, 18 Dec 1992 10:18:31 EST Received: by unirsvl.RSVL.UNISYS.COM (smail2.5) id AA02092; 18 Dec 92 08:58:00 CST (Fri) Subject: Re: 50000 connections and gigabit speeds To: uunet!rigden.wpd.sgi.com!rpw3@uunet.UU.NET (Rob Warnock) Date: Fri, 18 Dec 92 8:57:57 CST Cc: tcplw@cray.com In-Reply-To: <9212180702.AA19869@rigden.wpd.sgi.com>; from "Rob Warnock" at Dec 17, 92 11:02 pm X-Mailer: ELM [version 2.2 PL0] Message-Id: <9212180857.AA02088@unirsvl.RSVL.UNISYS.COM> From: kurt@unirsvl.RSVL.UNISYS.COM > > Do you see now? > > > -Rob > Yes I do. Thanks for the info, it pointed out a few things that I had not thought of. Kurt Received: by hemlock.cray.com id AA00763; 4.1/CRI-5.6; Fri, 18 Dec 92 01:10:10 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA00756; 4.1/CRI-5.6; Fri, 18 Dec 92 01:10:07 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.4) id AA09998; Fri, 18 Dec 92 01:09:58 CST Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA15435; Thu, 17 Dec 92 23:08:20 -0800 To: tcplw@cray.com Reply-To: rpw3@rigden.wpd.sgi.com (Rob Warnock) X-Approved: newsmail@sgi.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Subject: Re: 50000 connections and gigabit speeds Message-Id: Date: Fri, 18 Dec 1992 07:08:14 GMT kurt@unirsvl.RSVL.UNISYS.COM writes: +--------------- | > Even in a LAN, increases in link speed give disappointingly small decreases | > in latency. Just ask anybody about NFS over Ethernet versus over FDDI... | > Gigabits are for blasting files, not transactions [unless you have 50,000 | > outstanding transactions or something].... | | By this logic I should be using 2400 baud lines instead of Ethernet or | FDDI? :-) No, seriously, am I missing something? +--------------- I think you may be. Look again at what I said before: "Even in a LAN, increases in link speed give disappointingly small decreases in latency. Just ask anybody about NFS over Ethernet versus over FDDI..." Certainly, you should consider higher speeds than 2400 baud(!), but in most LAN environments latency is a more potent inhibitor than slow link speed. Increasing your link speed only decreases the time it takes to transmit a single packet. It *doesn't* decrease the time it takes for the far end to parse, act on, and respond to that packet, and the near end to parse and act on the reply. (See below for the rest.) +--------------- | Can you only get gigabit speeds out of WANs? Why can't we build a gigabit | LAN if we can build a gigabit WAN? +--------------- Of course gigabit LANs are simpler/easier/cheaper to build than gigabit WANs. That's not the point. The point is that even *LANs* are latency-limited, at gigabit speeds. +--------------- | On another note, I think that we can drop the discussion of 50,000 connections | in a transaction environment here. TCP large windows aren't going to be | helpful in that situation anyway. We are getting sidetracked on an issue that | doesn't really belong here. +--------------- But it *does* belong here! You're missing the fact that increased bandwidth *only* increases performance if the amount of data "in flight" per round-trip- time can increase, which can only happen one of three ways: 1. For a "windowed/streaming" protocol (TCP & others like it), if you increase the "window size", so you keep the faster pipe "full" while waiting for the ACKs from the remote end that *still* are going to take a while to return (since increased bandwidth doesn't help protocol handling times or transmission times for small things like ACKs). The whole point of TCP large windows is to "keep the pipe full" by allowing more than the delay-bandwidth product of data to be outstanding at once. Even on a local, fairly small FDDI ring, we have seen situations where TCP large windows were required to achieve full link rate. At gigabit speeds, it's a "must". 2. If you *are* stuck with a stop&wait request/response protocol (e.g., NFS, most RPCs), you can try increasing the *size* of each request so that at the faster link speed each request still takes about the same amount of time to send or receive. But there's a limit to how big you can make the individual RPC requests/ responses. And if the practical request/response size at the faster bit rate is much less than the round-trip latency (which can easily happen for, say, NFS on a gigabit LAN), then the throughput is dominated by the round-trip latency, and is fairly independent of the actual bitrate of the LAN (provided it's above some minimum speed, of course). For NFS, for example, experience so far puts the "knee" of the curve somewhere between Ethernet and FDDI. I know of no-one who has yet gotten more than a small fraction of an FDDI's worth of NFS traffic on a single client/server connection. 3. If you are stuck with a stop&wait request/response protocol with *really* small transactions compared to the bandwidth*delay product (e.g., typical X Windows packets even on Ethernet, or NFS over FDDI or faster), then the only way to increase total throughput is to do a *lot* of these small things in parallel, which is where the notion of "50,000 connections in a transaction environment" comes from. The latency of each individual connection is still long, and each individual request/response client/server connection's throughput is still slow, but at least you can make some use of your hundreds of megabits or your gigabits by having *lots* of simultaneously outstanding transactions. When the delay-bandwidth product is *really* large (megabytes), then trying to get link-speed performance out of a request/response transaction protocol is ludicrous (for a single client/server connection). You might as well send the entire database to the client with a windowed transport protocol (e.g., TCP), have him do a few transactions locally, and send the entire database back to the server (also with TCP or equiv). [This has been seriously considered in some environments!] Due to latency being essentially constant, there is always *some* speed above which further increases in bitrate do not substantially increase request/response transaction performance, but may (no promises!) increase a windowed/streaming protocol's performance (if the window is large enough). Do you see now? -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)390-1673 2011 N. Shoreline Blvd. Mountain View, CA 94043 Received: by hemlock.cray.com id AA00749; 4.1/CRI-5.6; Fri, 18 Dec 92 01:10:05 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA00740; 4.1/CRI-5.6; Fri, 18 Dec 92 01:09:59 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.4) id AA09969; Fri, 18 Dec 92 01:09:50 CST Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA14717; Thu, 17 Dec 92 22:59:37 -0800 To: tcplw@cray.com Reply-To: rpw3@rigden.wpd.sgi.com (Rob Warnock) X-Approved: newsmail@sgi.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Subject: Re: 50000 connections and gigabit speeds Message-Id: Date: Fri, 18 Dec 1992 06:59:08 GMT kurt@unirsvl.RSVL.UNISYS.COM writes: +--------------- | > Even in a LAN, increases in link speed give disappointingly small decreases | > in latency. Just ask anybody about NFS over Ethernet versus over FDDI... | > | > Gigabits are for blasting files, not transactions [unless you have 50,000 | > outstanding transactions or something].... | | By this logic I should be using 2400 baud lines instead of Ethernet or | FDDI? :-) No, seriously, am I missing something? +--------------- I think you may be. Look again at what I said before: "Even in a LAN, increases in link speed give disappointingly small decreases in latency. Just ask anybody about NFS over Ethernet versus over FDDI..." Certainly, you should consider higher speeds than 2400 baud(!), but in most LAN environments latency is a more potent inhibitor than slow link speed. Increasing your link speed only decreases the time it takes to transmit a single packet. It *doesn't* decrease the time it takes for the far end to parse, act on, and respond to that packet, and the near end to parse and act on the reply. (See below for the rest.) +--------------- | Can you only get gigabit speeds out of WANs? Why can't we build a gigabit | LAN if we can build a gigabit WAN? +--------------- Of course gigabit LANs are simpler/easier/cheaper to build than gigabit WANs. That's not the point. The point is that even *LANs* are latency-limited, at gigabit speeds. +--------------- | On another note, I think that we can drop the discussion of 50,000 connections | in a transaction environment here. TCP large windows aren't going to be | helpful in that situation anyway. We are getting sidetracked on an issue that | doesn't really belong here. +--------------- But it *does* belong here! You're missing the fact that increased bandwidth *only* increases performance if the amount of data "in flight" per round-trip- time can increase, which can only happen one of three ways: 1. For a "windowed/streaming" protocol (TCP & others like it), if you increase the "window size", so you keep the faster pipe "full" while waiting for the ACKs from the remote end that *still* are going to take a while to return (since increased bandwidth doesn't help protocol handling times or transmission times for small things like ACKs). The whole point of TCP large windows is to "keep the pipe full" by allowing more than the delay-bandwidth product of data to be outstanding at once. Even on a local, fairly small FDDI ring, we have seen situations where TCP large windows were required to achieve full link rate. At gigabit speeds, it's a "must". 2. If you *are* stuck with a stop&wait request/response protocol (e.g., NFS, most RPCs), you can try increasing the *size* of each request so that at the faster link speed each request still takes about the same amount of time to send or receive. But there's a limit to how big you can make the individual RPC requests/ responses. And if the practical request/response size at the faster bit rate is much less than the round-trip latency (which can easily happen for, say, NFS on a gigabit LAN), then the throughput is dominated by the round-trip latency, and is fairly independent of the actual bitrate of the LAN (provided it's above some minimum speed, of course). For NFS, for example, experience so far puts the "knee" of the curve somewhere between Ethernet and FDDI. I know of no-one who has yet gotten more than a small fraction of an FDDI's worth of NFS traffic on a single client/server connection. 3. If you are stuck with a stop&wait request/response protocol with *really* small transactions compared to the bandwidth*delay product (e.g., typical X Windows packets even on Ethernet, or NFS over FDDI or faster), then the only way to increase total throughput is to do a *lot* of these small things in parallel, which is where the notion of "50,000 connections in a transaction environment" comes from. The latency of each individual connection is still long, and each individual request/response client/server connection's throughput is still slow, but at least you can make some use of your hundreds of megabits or your gigabits by aggregating lots of sessions. When the delay-bandwidth product is *really* large (megabytes), then trying to get link-speed performance out of a request/response transaction protocol is ludicrous (for a single client/server connection). You might as well send the entire database to the client with a windowed transport protocol (e.g., TCP), have him do a few transactions locally, and send the entire database back to the server (also with TCP or equiv). [This has been seriously considered in some environments!] Due to latency being essentially constant, there is always *some* speed above which further increases in bitrate do not substantially increase request/response transaction performance, but may (no promises!) increase a windowed/streaming protocol's performance (if the window is large enough). Do you see now? -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)390-1673 2011 N. Shoreline Blvd. Mountain View, CA 94043 Received: by hemlock.cray.com id AA00547; 4.1/CRI-5.6; Fri, 18 Dec 92 01:02:46 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA00542; 4.1/CRI-5.6; Fri, 18 Dec 92 01:02:43 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.4) id AA09413; Fri, 18 Dec 92 01:02:29 CST Received: from [192.26.75.58] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA14886; Thu, 17 Dec 92 23:02:15 -0800 Received: by rigden.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:tcplw@cray.com id AA19869; Thu, 17 Dec 92 23:02:14 -0800 Date: Thu, 17 Dec 92 23:02:14 -0800 From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9212180702.AA19869@rigden.wpd.sgi.com> To: tcplw@cray.com Subject: Re: 50000 connections and gigabit speeds Cc: kurt@unirsvl.RSVL.UNISYS.COM kurt@unirsvl.RSVL.UNISYS.COM writes: +--------------- | > Even in a LAN, increases in link speed give disappointingly small decreases | > in latency. Just ask anybody about NFS over Ethernet versus over FDDI... | > Gigabits are for blasting files, not transactions [unless you have 50,000 | > outstanding transactions or something].... | | By this logic I should be using 2400 baud lines instead of Ethernet or | FDDI? :-) No, seriously, am I missing something? +--------------- I think you may be. Look again at what I said before: "Even in a LAN, increases in link speed give disappointingly small decreases in latency. Just ask anybody about NFS over Ethernet versus over FDDI..." Certainly, you should consider higher speeds than 2400 baud(!), but in most LAN environments latency is a more potent inhibitor than slow link speed. Increasing your link speed only decreases the time it takes to transmit a single packet. It *doesn't* decrease the time it takes for the far end to parse, act on, and respond to that packet, and the near end to parse and act on the reply. (See below for the rest.) +--------------- | Can you only get gigabit speeds out of WANs? Why can't we build a gigabit | LAN if we can build a gigabit WAN? +--------------- Of course gigabit LANs are simpler/easier/cheaper to build than gigabit WANs. That's not the point. The point is that even *LANs* are latency-limited, at gigabit speeds. +--------------- | On another note, I think that we can drop the discussion of 50,000 connections | in a transaction environment here. TCP large windows aren't going to be | helpful in that situation anyway. We are getting sidetracked on an issue that | doesn't really belong here. +--------------- But it *does* belong here! You're missing the fact that increased bandwidth *only* increases performance if the amount of data "in flight" per round-trip- time can increase, which can only happen one of three ways: 1. For a "windowed/streaming" protocol (TCP & others like it), if you increase the "window size", so you keep the faster pipe "full" while waiting for the ACKs from the remote end that *still* are going to take a while to return (since increased bandwidth doesn't help protocol handling times or transmission times for small things like ACKs). The whole point of TCP large windows is to "keep the pipe full" by allowing more than the delay-bandwidth product of data to be outstanding at once. Even on a local, fairly small FDDI ring, we have seen situations where TCP large windows were required to achieve full link rate. At gigabit speeds, it's a "must". 2. If you *are* stuck with a stop&wait request/response protocol (e.g., NFS, most RPCs), you can try increasing the *size* of each request so that at the faster link speed each request still takes about the same amount of time to send or receive. But there's a limit to how big you can make the individual RPC requests/ responses. And if the practical request/response size at the faster bit rate is much less than the round-trip latency (which can easily happen for, say, NFS on a gigabit LAN), then the throughput is dominated by the round-trip latency, and is fairly independent of the actual bitrate of the LAN (provided it's above some minimum speed, of course). For NFS, for example, experience so far puts the "knee" of the curve somewhere between Ethernet and FDDI. I know of no-one who has yet gotten more than a small fraction of an FDDI's worth of NFS traffic on a single client/server connection. 3. If you are stuck with a stop&wait request/response protocol with *really* small transactions compared to the bandwidth*delay product (e.g., typical X Windows packets even on Ethernet, or NFS over FDDI or faster), then the only way to increase total throughput is to do a *lot* of these small things in parallel, which is where the notion of "50,000 connections in a transaction environment" comes from. The latency of each individual connection is still long, and each individual request/response client/server connection's throughput is still slow, but at least you can make some use of your hundreds of megabits or your gigabits by having *lots* of simultaneously outstanding transactions. When the delay-bandwidth product is *really* large (megabytes), then trying to get link-speed performance out of a request/response transaction protocol is ludicrous (for a single client/server connection). You might as well send the entire database to the client with a windowed transport protocol (e.g., TCP), have him do a few transactions locally, and send the entire database back to the server (also with TCP or equiv). [This has been seriously considered in some environments!] Due to latency being essentially constant, there is always *some* speed above which further increases in bitrate do not substantially increase request/response transaction performance, but may (no promises!) increase a windowed/streaming protocol's performance (if the window is large enough). Do you see now? -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)390-1673 2011 N. Shoreline Blvd. Mountain View, CA 94043 Received: by hemlock.cray.com id AA07008; 4.1/CRI-5.6; Thu, 10 Dec 92 16:58:18 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA07004; 4.1/CRI-5.6; Thu, 10 Dec 92 16:58:14 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.2) id AA12149; Thu, 10 Dec 92 16:58:08 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Thu, 10 Dec 1992 14:24:10 -0800 Date: Thu, 10 Dec 1992 14:24:10 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199212102224.AA16199@zephyr.isi.edu> To: tcplw@cray.com, dab@berserkly.cray.com Subject: Re: 1323 implementations > > Name: _____________Bob Braden, Liming Wei_____________ > > Organization: _____Information Sciences Institute (ISI) > > Email/Phone: ___braden@isi.edu, lwei@isi.edu___________ > > [ ] This information should be kept confidential > > I have implemented: > [ X ] TCP Window Scale Option > [ X ] TCP Timestamps Option > [ X ] Am using Timestamps for RTT measurements. > [ X ] Am using Timestamps PAWS. > > OS name/version: __Sun OS 4.1____________ > The code is: > [ X ] Experimental/research/prototype. > [ ] Will be/is a Product. > [ ] Not available for distribution. > [ X ] Will be/is available AS IS. > [ ] Will be/is available for purchase. > [ ] There is support for the code. > > Availablity Information (date available, OS version, > how to get the code, who can get the code): > > ___Available Jan. 93, or when someone asks, whichever is > > ___later.__________________________________________________ > > [ ] There are known deficiencies in the implementation. > > Please explain. ____________________________________ > > ____________________________________________________ > > > [ ] I have tested my code against other implementations. > > Please list: _______________________________________ > > ____________________________________________________ > Received: by hemlock.cray.com id AA25214; 4.1/CRI-5.6; Tue, 8 Dec 92 15:10:38 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA25196; 4.1/CRI-5.6; Tue, 8 Dec 92 15:10:32 CST Received: from handel.cray.com.cray.com by cray.com (4.1/CRI-MX 2.2) id AA15101; Tue, 8 Dec 92 15:10:18 CST Received: by handel.cray.com.cray.com id AA20597; 5.65/CRI-5.5; Tue, 8 Dec 1992 15:07:40 -0600 Date: Tue, 8 Dec 1992 15:07:40 -0600 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9212082107.AA20597@handel.cray.com.cray.com> To: tcplw@cray.com Subject: 1323 implementations Hi. It has now been 6 months since RFC 1323 (TCP Extensions for High Performance) was published, so it how now met the minimum time requirement before being allowed to be advanced from a Proposed Standard to a Draft Standard. Before it can be elevated to Draft, there have to be at least two independent and interoperable implementations. So, I am taking an implementation survey. If you check the box to keep the information confidential, then the only information that I will make public is that there is an implementation, and which parts of the RFC it supports. Names/Organization/OS will not be mentioned. If you do not check the box, then I will include that information in my summary of the results back to the mailing list. I will not include the names from the interoperability testing information unless I get conformation from the other implementor that it is ok to release that information, so don't worry about citing other implementations that you have tested against. I've attached a sample reply at the end... -David Borman, dab@cray.com -------- Cut here and return to dab@cray.com ----------- Name: _____________________________________________ Organization: _____________________________________ Email/Phone: ______________________________________ [ ] This information should be kept confidential I have implemented: [ ] TCP Window Scale Option [ ] TCP Timestamps Option [ ] Am using Timestamps for RTT measurements. [ ] Am using Timestamps PAWS. OS name/version: ____________________________ The code is: [ ] Experimental/research/prototype. [ ] Will be/is a Product. [ ] Not available for distribution. [ ] Will be/is available AS IS. [ ] Will be/is available for purchase. [ ] There is support for the code. Availablity Information (date available, OS version, how to get the code, who can get the code): ____________________________________________________________ ____________________________________________________________ [ ] There are known deficiencies in the implementation. Please explain. ____________________________________ ____________________________________________________ [ ] I have tested my code against other implementations. Please list: _______________________________________ ____________________________________________________ ---------- Cut here for Sample form -------------- Name: David Borman Organization: Cray Research, Inc. Email/Phone: dab@cray.com (612)683-5571 [ ] This information should be kept confidential I have implemented: [ X ] TCP Window Scale Option [ X ] TCP Timestamps Option [ X ] Am using Timestamps for RTT measurements. [ X ] Am using Timestamps PAWS. OS name/version: UNICOS 6.1 and later The code is: [ ] Experimental/research/prototype. [ X ] Will be/is a Product. [ ] Not available for distribution. [ ] Will be/is available AS IS. [ ] Will be/is available for purchase. [ X ] There is support for the code. Availablity Information (date available, OS version, how to get the code, who can get the code): The code is part of the regular UNICOS distributions, and is available today with Unicos 6.1, 7.0 and 7.C [ X ] There are known deficiencies in the implementation. The code must be enabled via an explicit setsockopt() call by the application. Just making the kernel buffers large will not do it. The code in 6.1 uses the Echo and Echo Reply options instead of the Timestamps option, and does not support PAWS. There are also mods available for 6.0 and 5.1, but these are not supported and still have bugs that are fixed in the 6.1 code. The 7.0 code supports Window Scale, Timestamps, RTT calculations and PAWS, and also has support for the Echo and Echo Reply options for backwards compatability. [ X ] I have tested my code against other implementations. Please list: Van Jacobson's code At least 3 other partial/complete implementations. Received: by hemlock.cray.com id AA27586; 4.1/CRI-5.6; Mon, 7 Dec 92 12:03:53 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA27580; 4.1/CRI-5.6; Mon, 7 Dec 92 12:03:48 CST Received: from somnet.Sandia.GOV by cray.com (4.1/CRI-MX 2.2) id AA12204; Mon, 7 Dec 92 12:03:46 CST Received: by somnet.Sandia.GOV (5.59/SNLA-3.2.1) id AA22384; Mon, 7 Dec 92 11:01:14 MST Date: Mon, 7 Dec 92 11:01:14 MST From: cdbrown@somnet.sandia.gov (C. Douglas Brown) Message-Id: <9212071801.AA22384@somnet.Sandia.GOV> To: tcplw@cray.com Subject: Latency and Gigabit speeds > By this logic I should be using 2400 baud lines instead of Ethernet or FDDI? :-) > No, seriously, am I missing something? Can you only get gigabit speeds out of > WANs? Why can't we build a gigabit LAN if we can build a gigabit WAN? > > On another note, I think that we can drop the discussion of 50,000 connections > in a transaction environment here. TCP large windows aren't going to be > helpful in that situation anyway. We are getting sidetracked on an issue that > doesn't really belong here. > > Kurt I don't think anyone is trying to say you can't build gigabit LANs, but Rob has a valid point that simply increasing the speed of a network (LAN or WAN) doesn't necessarily decrease its latency. In fact, most of the delays in a network remain pretty constant when you increase the bit rate, except for packet transmission time. This means that the TCP large windows will even be needed for gigabit LANs, as well as WANs, because a sender might fill the standard 64K window before an acknowledgement could be received . Doug Brown Sandia National Labs Received: by hemlock.cray.com id AA09998; 4.1/CRI-5.5; Fri, 4 Dec 92 10:53:09 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA09988; 4.1/CRI-5.5; Fri, 4 Dec 92 10:53:05 CST Received: from relay2.UU.NET by cray.com (4.1/CRI-MX 2.2) id AA24977; Fri, 4 Dec 92 10:53:04 CST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19073; Fri, 4 Dec 92 11:53:06 -0500 Received: from s5000.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 115031.3559; Fri, 4 Dec 1992 11:50:31 EST Received: by unirsvl.RSVL.UNISYS.COM (smail2.5) id AA17030; 4 Dec 92 10:07:00 CST (Fri) Subject: Re: 50000 connections and gigabit speeds To: uunet!cray.com!tcplw-relay@uunet.UU.NET (Rob Warnock) Date: Fri, 4 Dec 92 10:06:58 CST Cc: tcplw@cray.com In-Reply-To: ; from "Rob Warnock" at Nov 29, 92 2:50 am X-Mailer: ELM [version 2.2 PL0] Message-Id: <9212041006.AA17026@unirsvl.RSVL.UNISYS.COM> From: kurt@unirsvl.RSVL.UNISYS.COM > > kurt@unirsvl.RSVL.UNISYS.COM says: > +--------------- > | > > It is highly unlikely that one would want to run > | > > 50,000 tcp connections at gigabit speeds (you would need a > | > > lot of buffer space). > | > | Why not? The gigabit speed would just decrease the network latency time, > | wouldn't it? Then you could get the same transaction rate on the host with > | fewer networks. The buffer space needed would not go up. I am interested in > | a transaction environment only, not doing 50,000 file transfers at the same > | time. > +--------------- > > Then you are going to be mightily disappointed in gigabit networks. Except > for some few cases of mongo-gram transactions in low-diameter LANs, you will > not find gigabit networks decreasing latency much. Consider: An 800 mile T3 > link (through two routers) is about 25 ms [as reported by skibo@cs.uiuc.edu, > now skibo@sgi.com]. That latency will not lessen (and it probably will even > even go up a bit) if you run over an OC-12 ATM link (622 Mb/s). Unless each > separate "transaction" is *huge* [which creates error & flow control problems], > an increase in link speed beyond double-digit megabits/sec will not buy you > much of anything. > > Even in a LAN, increases in link speed give disappointingly small decreases > in latency. Just ask anybody about NFS over Ethernet versus over FDDI... > > Gigabits are for blasting files, not transactions [unless you have 50,000 > outstanding transactions or something].... > > > -Rob > By this logic I should be using 2400 baud lines instead of Ethernet or FDDI? :-) No, seriously, am I missing something? Can you only get gigabit speeds out of WANs? Why can't we build a gigabit LAN if we can build a gigabit WAN? On another note, I think that we can drop the discussion of 50,000 connections in a transaction environment here. TCP large windows aren't going to be helpful in that situation anyway. We are getting sidetracked on an issue that doesn't really belong here. Kurt > ----- > Rob Warnock, MS-9U/510 rpw3@sgi.com > Silicon Graphics, Inc. (415)390-1673 > 2011 N. Shoreline Blvd. > Mountain View, CA 94043 > > > > > Received: by hemlock.cray.com id AA05912; 4.1/CRI-5.5; Sat, 28 Nov 92 20:58:33 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA05907; 4.1/CRI-5.5; Sat, 28 Nov 92 20:58:30 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.2) id AA10175; Sat, 28 Nov 92 20:58:28 CST Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA28409; Sat, 28 Nov 92 18:51:00 -0800 To: tcplw@cray.com Reply-To: rpw3@rigden.wpd.sgi.com (Rob Warnock) X-Approved: newsmail@sgi.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Subject: Re: 50000 connections and gigabit speeds Message-Id: Date: Sun, 29 Nov 1992 02:50:30 GMT kurt@unirsvl.RSVL.UNISYS.COM says: +--------------- | > > It is highly unlikely that one would want to run | > > 50,000 tcp connections at gigabit speeds (you would need a | > > lot of buffer space). | | Why not? The gigabit speed would just decrease the network latency time, | wouldn't it? Then you could get the same transaction rate on the host with | fewer networks. The buffer space needed would not go up. I am interested in | a transaction environment only, not doing 50,000 file transfers at the same | time. +--------------- Then you are going to be mightily disappointed in gigabit networks. Except for some few cases of mongo-gram transactions in low-diameter LANs, you will not find gigabit networks decreasing latency much. Consider: An 800 mile T3 link (through two routers) is about 25 ms [as reported by skibo@cs.uiuc.edu, now skibo@sgi.com]. That latency will not lessen (and it probably will even even go up a bit) if you run over an OC-12 ATM link (622 Mb/s). Unless each separate "transaction" is *huge* [which creates error & flow control problems], an increase in link speed beyond double-digit megabits/sec will not buy you much of anything. Even in a LAN, increases in link speed give disappointingly small decreases in latency. Just ask anybody about NFS over Ethernet versus over FDDI... Gigabits are for blasting files, not transactions [unless you have 50,000 outstanding transactions or something].... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)390-1673 2011 N. Shoreline Blvd. Mountain View, CA 94043 Received: by hemlock.cray.com id AA05821; 4.1/CRI-5.5; Sat, 28 Nov 92 20:49:08 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA05817; 4.1/CRI-5.5; Sat, 28 Nov 92 20:49:05 CST Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.2) id AA09683; Sat, 28 Nov 92 20:49:02 CST Received: from [192.26.75.58] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA28252; Sat, 28 Nov 92 18:48:53 -0800 Received: by rigden.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:kurt@unirsvl.RSVL.UNISYS.COM id AA19390; Sat, 28 Nov 92 18:48:52 -0800 Date: Sat, 28 Nov 92 18:48:52 -0800 From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9211290248.AA19390@rigden.wpd.sgi.com> To: kurt@unirsvl.RSVL.UNISYS.COM Subject: Re: 50000 connections and gigabit speeds Cc: tcplw@cray.com kurt@unirsvl.RSVL.UNISYS.COM says: +--------------- | > > It is highly unlikely that one would want to run | > > 50,000 tcp connections at gigabit speeds (you would need a | > > lot of buffer space). | | Why not? The gigabit speed would just decrease the network latency time, | wouldn't it? Then you could get the same transaction rate on the host with | fewer networks. The buffer space needed would not go up. I am interested in | a transaction environment only, not doing 50,000 file transfers at the same | time. +--------------- Then you are going to be mightily disappointed in gigabit networks. Except for some few cases of mongo-gram transactions in low-diameter LANs, you will not find gigabit networks decreasing latency much. Consider: An 800 mile T3 link (through two routers) is about 25 ms [as reported by skibo@cs.uiuc.edu, now skibo@sgi.com]. That latency will not lessen (and it probably will even even go up a bit) if you run over an OC-12 ATM link (622 Mb/s). Unless each separate "transaction" is *huge* [which creates error & flow control problems], an increase in link speed beyond double-digit megabits/sec will not buy you much of anything. Even in a LAN, increases in link speed give disappointingly small decreases in latency. Just ask anybody about NFS over Ethernet versus over FDDI... Gigabits are for blasting files, not transactions [unless you have 50,000 outstanding transactions or something].... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)390-1673 2011 N. Shoreline Blvd. Mountain View, CA 94043 Received: by hemlock.cray.com id AA07976; 4.1/CRI-5.5; Mon, 16 Nov 92 11:11:48 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA07972; 4.1/CRI-5.5; Mon, 16 Nov 92 11:11:45 CST Received: from relay1.UU.NET by cray.com (4.1/CRI-MX 2.2) id AA24953; Mon, 16 Nov 92 11:11:41 CST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22870; Mon, 16 Nov 92 09:40:45 -0500 Received: from unirsvl.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 093908.23694; Mon, 16 Nov 1992 09:39:08 EST Received: by unirsvl.RSVL.UNISYS.COM (smail2.5) id AA23385; 16 Nov 92 08:30:15 CST (Mon) Subject: Re: 50000 connections and gigabit speeds To: tcplw@cray.com Date: Mon, 16 Nov 92 8:30:12 CST In-Reply-To: <199211140020.AA23575@zephyr.isi.edu>; from "Bob Braden" at Nov 13, 92 4:20 pm X-Mailer: ELM [version 2.2 PL0] Message-Id: <9211160830.AA23381@unirsvl.RSVL.UNISYS.COM> From: kurt@unirsvl.RSVL.UNISYS.COM > > > > It is highly unlikely that one would want to run > > 50,000 tcp connections at gigabit speeds (you would need a > > lot of buffer space). > > > > Sean W. O'Malley > > Why not? The gigabit speed would just decrease the network latency time, wouldn't it? Then you could get the same transaction rate on the host with fewer networks. The buffer space needed would not go up. I am interested in a transaction environment only, not doing 50,000 file transfers at the same time. Kurt Received: by hemlock.cray.com id AA01057; 4.1/CRI-5.5; Fri, 13 Nov 92 18:20:29 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA01053; 4.1/CRI-5.5; Fri, 13 Nov 92 18:20:27 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.2) id AA10159; Fri, 13 Nov 92 18:20:24 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Fri, 13 Nov 1992 16:20:05 -0800 Date: Fri, 13 Nov 1992 16:20:05 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199211140020.AA23575@zephyr.isi.edu> To: tcplw@cray.com, sean@cs.arizona.edu Subject: Re: PCB's and Timestamps Cc: llp@cs.arizona.edu (still processing old mail) Sean, This sort of defeats the purpose of the timetamp option (getting a better estimate of the RTT) doesn't it? Bob Braden > From tcplw-relay@cray.com Thu Sep 3 11:49:56 1992 > Date: Thu, 3 Sep 1992 11:49:04 MST > From: "Sean O'Malley" > To: tcplw@cray.com > Subject: PCB's and Timestamps > Cc: llp@cs.arizona.edu > Content-Length: 1124 > X-Lines: 28 > > > I was incorrect in my last message: > > > The problem with all of this is that we don't really have a hell > > of a lot of room in the TCP option field if the SACK option is > > ever standardized. > > It is highly unlikely that one would want to run > 50,000 tcp connections at gigabit speeds (you would need a > lot of buffer space). Thus the problems would appear to > be orthogonal. > > Given this you could in fact simply overload the timestamp > option to contain a PCB index. Simply open a connection requesting > the timestamp option and a zero window scaling factor and use > the timestamp field to store a PCB index (or poniter if you > are brave). As define the recievier must treat the timestamp > as a magic cookie and return it. (It will waste some time > agonizing about which timestamp to return which in this > case is irrelevent.) The other side of the connection could > be using the timestamp for an actual timestamp or could also > be using it for a PCB pointer. It would not affect the outcome > in either case. Note that this could add signficant processing > overhead to very low bandwidth connections. > > Sean W. O'Malley > > > Received: by hemlock.cray.com id AA00817; 4.1/CRI-5.5; Fri, 13 Nov 92 18:09:17 CST Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA00813; 4.1/CRI-5.5; Fri, 13 Nov 92 18:09:15 CST Received: from zephyr.isi.edu by cray.com (4.1/CRI-MX 2.2) id AA09408; Fri, 13 Nov 92 18:09:11 CST Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Fri, 13 Nov 1992 16:07:28 -0800 Date: Fri, 13 Nov 1992 16:07:28 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199211140007.AA23435@zephyr.isi.edu> To: fisher@mips.com, swise@bach.austin.ibm.com Subject: Re: eliminate TCP input demuxing Cc: tcplw@cray.com > From tcplw-relay@cray.com Thu Sep 3 06:06:54 1992 > From: swise@bach.austin.ibm.com (Steve Wise) > To: fisher@mips.com (William E. Fisher) > Cc: hughes@hughes.network.com, tcplw@cray.com > Subject: Re: eliminate TCP input demuxing > In-Reply-To: Your message of Wed, 02 Sep 92 18:41:29 PDT. > <9209030141.AA07139@orac.mips.com> > Date: Thu, 03 Sep 92 08:08:39 -0600 > Content-Length: 893 > X-Lines: 23 > > > > | One paper that was recnetly published in measuring the PCB lookup overhead was: > | > | 1992 ACM SIGCOMM Conference Proceedings > | August 17-20, 1992, Baltimore, Maryland > | > | Efficient Demultiplexing of Incoming TCP Packets > | Paul McKenney and Ken Dove > | Sequent Computer Systems > | > | The paper covers a number of different algorithms and presents some analytical > | approximations to describe the behavior of various TCP demultiplexing algorithms > | when presented with packet traffic resulting from running the TPC/A benchmarks. > I'm just getting around to responding to this, with an historical note which I cannot resist. Paul's paper is a bood, thorough, and competently done analysis, but the conclusion takes me back about 14 years. Are we always destined to reinvent the same stuff every N years? I wrote one of the 6 original experimental TCP's commissioned by DARPA, starting about 1978, and my implementation used exactly the (standard) chained hashing algorithm that Paul concludes is best. It seemed to me then, and still seems, even without elaborate analysis, that using such an algorithm is simply good software engineering. I would expect any graduate with a CS degree (and I mean *undergraduate*) to do the same. Doing a linear search for demultiplexing is clearly wrong. BTW, my TCP was implemented in IBM BAL for the IBM MVT/MVS operating systems. What an incredible luxury a good C compiler would have been! Bob Braden Received: by hemlock.cray.com id AA02930; 4.1/CRI-5.5; Thu, 15 Oct 92 03:01:55 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA02926; 4.1/CRI-5.5; Thu, 15 Oct 92 03:01:53 CDT Received: from mitsou.inria.fr by cray.com (4.1/CRI-MX 2.2) id AA20567; Thu, 15 Oct 92 03:01:49 CDT Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA06402; Thu, 15 Oct 1992 09:02:55 +0100 Message-Id: <199210150802.AA06402@mitsou.inria.fr> To: swise@bach.austin.ibm.com (Steve Wise) Cc: skibo@florida.wpd.sgi.com (Thomas Skibo), tcplw@cray.com Subject: Re: Source Code In-Reply-To: Your message of "Wed, 14 Oct 92 10:09:15 CST." <9210141509.AA12719@bach.austin.ibm.com> Date: Thu, 15 Oct 92 09:02:49 -0500 From: Christian Huitema X-Mts: smtp I hope the following description will give yoiu an idea of what INRIA is... Christian Huitema ================================ The National Institute for Research in Computer Science and Automation (INRIA) is a French Scientific and Technological Public Institute under the responsability of the Ministry of Research and of the Ministry of Industry. INRIA's missions are: * basic and applied research, * design of experimental systems, * technology transfer, * knowledge transfer, * international scientific exchanges, * scientific assesments, * contribution to standardization Headquartered in Rocquencourt, near Paris, INRIA has four Research Centers in Nancy/Metz, Rennes, Rocquencourt, Sophia Antipolis and a laboratory in Grenoble. In 1992, INRIA's personnel numbers about 1200, the permanent staff accounting for 640. The total budget is about 66 M ECUs (77 M$), 80% of which is the French Government's subsidy. Received: by hemlock.cray.com id AA01315; 4.1/CRI-5.5; Wed, 14 Oct 92 12:45:41 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA01310; 4.1/CRI-5.5; Wed, 14 Oct 92 12:45:39 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.2) id AA05854; Wed, 14 Oct 92 12:45:36 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA21449; Wed, 14 Oct 92 10:45:13 -0700 To: tcplw@cray.com Reply-To: skibo@florida.wpd.sgi.com (Thomas Skibo) X-Approved: newsmail@sgi.sgi.com From: skibo@florida.wpd.sgi.com (Thomas Skibo) Subject: Re: Source Code Message-Id: Date: Wed, 14 Oct 1992 17:43:50 GMT I had replied directly to the author on this before I realized that it was sent to the mailing list so I'll repeat myself in case anybody cares... > > > skibo@florida.wpd.sgi.com says: > > | My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu. > | > | The file you want is "pub/tcplw.shar.Z". > | > | The patched TCP has been running quite stable on a uVAX at U. of > | I. for at least 5 months. There is a minor bug (described in the README) > | which I've been reluctant to fix because I don't want to redo all > | the testing that I went through. It's a one line change. Also, the > > Did you publish your test plan/methods? > > Thanx in advance, > > Steve Wise. No, I guess I didn't really go into much detail of my testing methods when I wrote the tech report. I did show some graphs that I used to verify rtt measurements, though. They compared rtt measurements with and without time-stamps. Window scaling was tested in a variety of ways. I used ttcp and a tool I developed for the SGI that would delay and/or randomly drop packets (it intercepted outgoing packets by changing the if_output pointer in an ifnet structure). By delaying ACKs out of the SGI, I could verify that the uVAX would send over 64K outstanding. By dropping data segments out of the SGI, I could verify that the VAX would report the proper time-stamp echo replies in ACKs (this was tough-- the time-stamp clock is so slow you have to look for instances where the senders clock ticked AND a packet was dropped to verify that out-of-order packets didn't advance the echo replies). I did a lot of "seat-of-the-pants" testing: I kludged the SGI so that the time-stamps would count in increments of 0x1000000 so that I could test the modulo comparisons. I would set back the SGI's time-stamp clock to test packets dropped by PAWs. I set back the SGI's time-stamp clock and set forward the VAX's "expire TS.recent" timer to makes sure TS.recent is thrown away on an idle connection after 24 days. Two bugs that have been found since then: FIN wasn't taken into account when deciding to update TS.recent so the last FIN-ACK would make a properly working sender come up with a ridiculous rtt measurement if the connection had been idle for a while. This one's fairly new: if a connecting TCP reuses an address and the receiving TCP is in TIME_WAIT, TCP will close the old connection and then jump back in tcp_input() to start over. Unfortunately, the options have been discarded by then so then window scaling and time-stamping will not work. I think this is probably a problem in unmodified TCP in that the MSS option might be thrown away, too. Tim Seaver at the MCNC Center for Communications saw this happening and he had it even worse: the fact that the headers are stripped twice in that case corrupted his mbufs (he got a negative length and an offset that was bigger than MLEN). -skibo --- Thomas Skibo skibo@sgi.com Received: by hemlock.cray.com id AA01145; 4.1/CRI-5.5; Wed, 14 Oct 92 12:42:04 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA01141; 4.1/CRI-5.5; Wed, 14 Oct 92 12:42:01 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.2) id AA05373; Wed, 14 Oct 92 12:41:59 CDT Received: from [192.26.75.8] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA21102; Wed, 14 Oct 92 10:41:48 -0700 Received: by florida.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:swise@bach.austin.ibm.com id AA01315; Wed, 14 Oct 92 10:41:47 -0700 Date: Wed, 14 Oct 92 10:41:47 -0700 From: skibo@florida.wpd.sgi.com (Thomas Skibo) Message-Id: <9210141741.AA01315@florida.wpd.sgi.com> To: swise@bach.austin.ibm.com (Steve Wise) Subject: Re: Source Code Cc: tcplw@cray.com I had replied directly to the author on this before I realized that it was sent to the mailing list so I'll repeat myself in case anybody cares... > > > skibo@florida.wpd.sgi.com says: > > | My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu. > | > | The file you want is "pub/tcplw.shar.Z". > | > | The patched TCP has been running quite stable on a uVAX at U. of > | I. for at least 5 months. There is a minor bug (described in the README) > | which I've been reluctant to fix because I don't want to redo all > | the testing that I went through. It's a one line change. Also, the > > Did you publish your test plan/methods? > > Thanx in advance, > > Steve Wise. No, I guess I didn't really go into much detail of my testing methods when I wrote the tech report. I did show some graphs that I used to verify rtt measurements, though. They compared rtt measurements with and without time-stamps. Window scaling was tested in a variety of ways. I used ttcp and a tool I developed for the SGI that would delay and/or randomly drop packets (it intercepted outgoing packets by changing the if_output pointer in an ifnet structure). By delaying ACKs out of the SGI, I could verify that the uVAX would send over 64K outstanding. By dropping data segments out of the SGI, I could verify that the VAX would report the proper time-stamp echo replies in ACKs (this was tough-- the time-stamp clock is so slow you have to look for instances where the senders clock ticked AND a packet was dropped to verify that out-of-order packets didn't advance the echo replies). I did a lot of "seat-of-the-pants" testing: I kludged the SGI so that the time-stamps would count in increments of 0x1000000 so that I could test the modulo comparisons. I would set back the SGI's time-stamp clock to test packets dropped by PAWs. I set back the SGI's time-stamp clock and set forward the VAX's "expire TS.recent" timer to makes sure TS.recent is thrown away on an idle connection after 24 days. Two bugs that have been found since then: FIN wasn't taken into account when deciding to update TS.recent so the last FIN-ACK would make a properly working sender come up with a ridiculous rtt measurement if the connection had been idle for a while. This one's fairly new: if a connecting TCP reuses an address and the receiving TCP is in TIME_WAIT, TCP will close the old connection and then jump back in tcp_input() to start over. Unfortunately, the options have been discarded by then so then window scaling and time-stamping will not work. I think this is probably a problem in unmodified TCP in that the MSS option might be thrown away, too. Tim Seaver at the MCNC Center for Communications saw this happening and he had it even worse: the fact that the headers are stripped twice in that case corrupted his mbufs (he got a negative length and an offset that was bigger than MLEN). -skibo --- Thomas Skibo skibo@sgi.com Received: by hemlock.cray.com id AA21901; 4.1/CRI-5.5; Wed, 14 Oct 92 10:07:16 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA21897; 4.1/CRI-5.5; Wed, 14 Oct 92 10:07:14 CDT Received: from bach.austin.ibm.com by cray.com (4.1/CRI-MX 2.2) id AA25170; Wed, 14 Oct 92 10:07:12 CDT Received: by bach.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA12719; Wed, 14 Oct 1992 10:09:15 -0500 From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9210141509.AA12719@bach.austin.ibm.com> To: skibo@florida.wpd.sgi.com (Thomas Skibo) Cc: tcplw@cray.com Subject: Re: Source Code In-Reply-To: (Your message of Tue, 29 Sep 92 21:37:44 GMT.) Date: Wed, 14 Oct 92 10:09:15 -0600 skibo@florida.wpd.sgi.com says: | My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu. | | The file you want is "pub/tcplw.shar.Z". | | The patched TCP has been running quite stable on a uVAX at U. of | I. for at least 5 months. There is a minor bug (described in the README) | which I've been reluctant to fix because I don't want to redo all | the testing that I went through. It's a one line change. Also, the Did you publish your test plan/methods? Thanx in advance, Steve Wise. Received: by hemlock.cray.com id AA26071; 4.1/CRI-5.5; Tue, 29 Sep 92 17:38:14 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA26067; 4.1/CRI-5.5; Tue, 29 Sep 92 17:38:12 CDT Received: from elroy.Jpl.Nasa.Gov by cray.com (4.1/CRI-MX 2.2) id AA22168; Tue, 29 Sep 92 17:38:10 CDT Received: from puente.Jpl.Nasa.Gov by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA24738; Tue, 29 Sep 92 15:38:08 PDT Received: by puente.Jpl.Nasa.Gov (4.1/SMI-4.1+DXRs2.0) id AA15005; Tue, 29 Sep 92 15:29:51 PDT From: garyf@puente.Jpl.Nasa.Gov (Gary Friedman) Message-Id: <9209292229.AA15005@puente.Jpl.Nasa.Gov> Subject: subscribe To: tcplw@cray.com Date: Tue, 29 Sep 92 15:29:50 PDT X-Mailer: ELM [version 2.3 PL11] Subscribe Received: by hemlock.cray.com id AA24943; 4.1/CRI-5.5; Tue, 29 Sep 92 17:06:46 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA24935; 4.1/CRI-5.5; Tue, 29 Sep 92 17:06:41 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.2) id AA20485; Tue, 29 Sep 92 17:06:33 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA21894; Tue, 29 Sep 92 14:55:31 -0700 To: tcplw@cray.com Reply-To: skibo@florida.wpd.sgi.com (Thomas Skibo) X-Approved: newsmail@sgi.sgi.com From: skibo@florida.wpd.sgi.com (Thomas Skibo) Subject: Re: Source Code Message-Id: Date: Tue, 29 Sep 1992 21:37:44 GMT My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu. The file you want is "pub/tcplw.shar.Z". The patched TCP has been running quite stable on a uVAX at U. of I. for at least 5 months. There is a minor bug (described in the README) which I've been reluctant to fix because I don't want to redo all the testing that I went through. It's a one line change. Also, the PCB's are stored in cluster mbufs which is REALLY wasteful. You might want to change that. -skibo --- Thomas Skibo skibo@sgi.com Received: by hemlock.cray.com id AA21543; 4.1/CRI-5.5; Tue, 29 Sep 92 16:22:15 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA21538; 4.1/CRI-5.5; Tue, 29 Sep 92 16:22:12 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.2) id AA17094; Tue, 29 Sep 92 16:22:10 CDT Received: from [192.26.75.8] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA16947; Tue, 29 Sep 92 14:21:59 -0700 Received: by florida.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:sean@cs.arizona.edu id AA25073; Tue, 29 Sep 92 14:21:58 -0700 Date: Tue, 29 Sep 92 14:21:58 -0700 From: skibo@florida.wpd.sgi.com (Thomas Skibo) Message-Id: <9209292121.AA25073@florida.wpd.sgi.com> To: "Sean O'Malley" Subject: Re: Source Code Cc: tcplw@cray.com My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu. The file you want is "pub/tcplw.shar.Z". The patched TCP has been running quite stable on a uVAX at U. of I. for at least 5 months. There is a minor bug (described in the README) which I've been reluctant to fix because I don't want to redo all the testing that I went through. It's a one line change. Also, the PCB's are stored in cluster mbufs which is REALLY wasteful. You might want to change that. -skibo --- Thomas Skibo skibo@sgi.com Received: by hemlock.cray.com id AA17393; 4.1/CRI-5.5; Tue, 29 Sep 92 15:29:53 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA17389; 4.1/CRI-5.5; Tue, 29 Sep 92 15:29:50 CDT Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 2.2) id AA12996; Tue, 29 Sep 92 15:29:48 CDT Date: Tue, 29 Sep 1992 13:29:47 MST From: "Sean O'Malley" Message-Id: <199209292029.AA14652@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA14652; Tue, 29 Sep 1992 13:29:47 MST To: tcplw@cray.com Subject: Source Code Is there a version of the extended TCP available by ftp? (Preferablty a BSD version) Sean O'Malley Received: by hemlock.cray.com id AA13636; 4.1/CRI-5.5; Tue, 15 Sep 92 15:55:33 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13631; 4.1/CRI-5.5; Tue, 15 Sep 92 15:55:31 CDT Received: from ames.arc.nasa.gov by cray.com (4.1/CRI-MX 2.2) id AA21616; Tue, 15 Sep 92 15:55:28 CDT Received: from ultra.UUCP by ames.arc.nasa.gov with UUCP id AA08459 (5.65c/IDA-1.4.4 for tcplw@cray.com); Tue, 15 Sep 1992 12:59:55 -0700 Received: from sly.ultra.com by ultra.com (4.1/Ultra-1.4-10-10-91) id AA15621; Tue, 15 Sep 92 13:01:09 PDT Date: Tue, 15 Sep 92 13:01:08 PDT From: wayne@ultra.com (Wayne Hathaway) Message-Id: <9209152001.AA15621@ultra.com> To: tcplw@cray.com Subject: Re: eliminate TCP input demuxing Christian Huitema comments: > You mention the your-ref/my-ref exchange of TP4 as an optimization. > It certainly can be used to facilitate demuxing and quickly locating > your context in a PCB list, modulo a couple of caveats -- one needs > to check the consistency of "your-ref" with the source address if > one is serious about security, so the instruction count is not so > small as it appears. True, but a consistency check is just a compare, which can be done a *LOT* faster than searching a hash chain or something. It could even be done relatively easily by the hardware in parallel with "other stuff," although that probably isn't worth it. > But this exchange has one big cost: it prevents "direct transmission", > and inserts a delay during which a complete transaction could probably > have taken place on a high speed network. It can only be factored > out for long connections, not for RPC type transactions. Remember that this discussion was in the context of TCP, which of course suffers the same COTS drawback. The point was that a connection identifier in TCP is a 12-byte quantity, which takes time to process, while a connection identifier in TP4 is a 16-bit quantity that can be used as a direct index. All of which has nothing at all to do with CLTS! Wayne Hathaway domain: wayne@Ultra.COM Ultra Network Technologies uucp: ...!ames!ultra!wayne 101 Daggett Drive phone: 408-922-0100 x132 San Jose, CA 95134 FAX: 408-433-9287 PS: You mention an "exchange" as if it were something extra beyond the normal connection-establishment handshake. It is not, of course, so using a reference *IS* "free" once you bite the connection-oriented bullet. Received: by hemlock.cray.com id AA12268; 4.1/CRI-5.5; Tue, 15 Sep 92 15:36:26 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA12264; 4.1/CRI-5.5; Tue, 15 Sep 92 15:36:22 CDT Received: from ames.arc.nasa.gov by cray.com (4.1/CRI-MX 2.2) id AA20114; Tue, 15 Sep 92 15:36:19 CDT Received: from ultra.UUCP by ames.arc.nasa.gov with UUCP id AA08356 (5.65c/IDA-1.4.4 for tcplw@cray.com); Tue, 15 Sep 1992 12:57:28 -0700 Received: from sly.ultra.com by ultra.com (4.1/Ultra-1.4-10-10-91) id AA15236; Tue, 15 Sep 92 12:57:45 PDT Date: Tue, 15 Sep 92 12:57:44 PDT From: wayne@ultra.com (Wayne Hathaway) Message-Id: <9209151957.AA15236@ultra.com> To: tcplw@cray.com Subject: Re: eliminate TCP input demuxing Me: > Since the term "Ultra-net" (actually UltraNet :-) was used in this > discussion in the sense of a "protocol" like XTP I feel justified in > jumping in ... > > UltraNet actually runs fairly vanilla ISO TP4 internally (as well as > TCP),... Vernon Schryver: > Does it still move the checksum to the end of the packet, after the > data? Yes, internally to an UltraNet we still put the checksum in a trailer, computed by special hardware as the packet is flowing through. (We do this with TCP as well.) This gives us a significant performance gain, and is why I said "fairly vanilla TP4." However, whenever a packet *LEAVES* an UltraNet (e.g., being routed onto Ethernet or FDDI) then we do stop the packet long enough to move the checksum up front where the rest of the world expects to find it. Wayne Hathaway domain: wayne@Ultra.COM Ultra Network Technologies uucp: ...!ames!ultra!wayne 101 Daggett Drive phone: 408-922-0100 x132 San Jose, CA 95134 FAX: 408-433-9287 Received: by hemlock.cray.com id AA05758; 4.1/CRI-5.5; Mon, 14 Sep 92 07:41:03 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA05754; 4.1/CRI-5.5; Mon, 14 Sep 92 07:41:01 CDT Received: from mitsou.inria.fr by cray.com (4.1/CRI-MX 2.2) id AA04556; Mon, 14 Sep 92 07:39:46 CDT Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA00767; Mon, 14 Sep 1992 14:37:52 +0200 Message-Id: <199209141237.AA00767@mitsou.inria.fr> To: wayne@ultra.com (Wayne Hathaway) Cc: tcplw@cray.com Subject: Re: eliminate TCP input demuxing In-Reply-To: Your message of "Sat, 12 Sep 92 10:44:05 PDT." <9209121744.AA18563@ultra.com> Date: Mon, 14 Sep 92 14:37:46 -0400 From: Christian Huitema X-Mts: smtp You mention the your-ref/my-ref exchange of TP4 as an optimization. It certainly can be used to facilitate demuxing and quickly locating your context in a PCB list, modulo a couple of caveats -- one needs to check the consistency of "your-ref" with the source address if one is serious about security, so the instruction count is not so small as it appears. But this exchange has one big cost: it prevents "direct transmission", and insert a delay during which a complete transaction could probably have taken place on a high speed network. It can only be factored out for long connection, not for RPC type transactions. Christian Huitema Received: by hemlock.cray.com id AA29482; 4.1/CRI-5.5; Sun, 13 Sep 92 00:23:24 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA29478; 4.1/CRI-5.5; Sun, 13 Sep 92 00:23:21 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 2.2) id AA16723; Sun, 13 Sep 92 00:23:19 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA21143; Sat, 12 Sep 92 22:20:07 -0700 To: tcplw@cray.com Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: eliminate TCP input demuxing Message-Id: Date: Sun, 13 Sep 1992 05:09:31 GMT wayne@ultra.com (Wayne Hathaway) writes: > Since the term "Ultra-net" (actually UltraNet :-) was used in this > discussion in the sense of a "protocol" like XTP I feel justified in > jumping in ... > > UltraNet actually runs fairly vanilla ISO TP4 internally (as well as > TCP),... Does it still move the checksum to the end of the packet, after the data? Vernon Schryver, vjs@sgi.com Received: by hemlock.cray.com id AA17178; 4.1/CRI-5.5; Sat, 12 Sep 92 13:04:49 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA17174; 4.1/CRI-5.5; Sat, 12 Sep 92 13:04:48 CDT Received: from ames.arc.nasa.gov by cray.com (4.1/CRI-MX 2.2) id AA00640; Sat, 12 Sep 92 13:04:45 CDT Received: from ultra.UUCP by ames.arc.nasa.gov with UUCP id AA13579 (5.65c/IDA-1.4.4 for tcplw@cray.com); Sat, 12 Sep 1992 10:43:13 -0700 Received: from sly.ultra.com by ultra.com (4.1/Ultra-1.4-10-10-91) id AA18563; Sat, 12 Sep 92 10:44:05 PDT Date: Sat, 12 Sep 92 10:44:05 PDT From: wayne@ultra.com (Wayne Hathaway) Message-Id: <9209121744.AA18563@ultra.com> To: tcplw@cray.com Subject: Re: eliminate TCP input demuxing Since the term "Ultra-net" (actually UltraNet :-) was used in this discussion in the sense of a "protocol" like XTP I feel justified in jumping in ... UltraNet actually runs fairly vanilla ISO TP4 internally (as well as TCP), and one of the reasons for choosing TP4 for a high speed net is exactly the topic being discussed: the TP4 "reference" field. This is a fixed-location 16-bit VC identifier that can be *VERY* quickly translated into a PCB pointer. Our custom hardware actually uses it directly as a "subscript" into a PCB array, so we have no hashing, no caching, no nuttin': just stuff it into a register and the hardware does the rest. And frankly it surprises me to see this idea being "reinvented" in this group. ISO TP4 sure ain't God's gift to protocols, but it did do a *FEW* things right that even almighty TCP can learn from! :-) Wayne Hathaway domain: wayne@Ultra.COM Ultra Network Technologies uucp: ...!ames!ultra!wayne 101 Daggett Drive phone: 408-922-0100 x132 San Jose, CA 95134 FAX: 408-433-9287 Received: by hemlock.cray.com id AA14569; 4.1/CRI-5.5; Fri, 4 Sep 92 13:59:44 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA14565; 4.1/CRI-5.5; Fri, 4 Sep 92 13:59:42 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 1.6ah) id AA00791; Fri, 4 Sep 92 13:59:38 CDT Received: from [192.26.75.58] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA18391; Fri, 4 Sep 92 11:59:34 -0700 Received: by rigden.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:tcplw@cray.com id AA15470; Fri, 4 Sep 92 11:59:33 -0700 Date: Fri, 4 Sep 92 11:59:33 -0700 From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9209041859.AA15470@rigden.wpd.sgi.com> To: tcplw@cray.com Subject: Re: TCP demultiplexing kurt@unirsvl.RSVL.UNISYS.COM writes: +--------------- | We use this method on one of our proprietary protocols. It works very well. | I have wished for it with TCP for awhile now. My problem is that even with a | hash table with 511 slots in it I have to search approximately 50 tables on | average if there are 50,000 connections. +--------------- So use a bigger hash table! If you have 50,000 connections (PCBs) you surely can afford the memory space for an average of one more pointer per connection, so build a hash table with 50,000 entries in it. Hashing only works really well if the *average* number of probes per lookup is ~1. But you should also note that if you have 50,000 connections, you might as well use a direct index on a 16-bit port number as the "hash". There are two common methods: 1. XOR the local and remote port numbers. (Simple enough.) 2. If the local port number is above the "reserved" range, use it by itself as the "hash", else use the remote port number by itself. That is: hash = (lport > IPPORT_RESERVED) ? lport : rport; For most TCP connections, this means that the hash will be a "randomly"- assigned port number. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)390-1673 2011 N. Shoreline Blvd. Mountain View, CA 94043 Received: by hemlock.cray.com id AA13974; 4.1/CRI-5.5; Fri, 4 Sep 92 13:50:49 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA13970; 4.1/CRI-5.5; Fri, 4 Sep 92 13:50:46 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 1.6ah) id AA29952; Fri, 4 Sep 92 13:50:44 CDT Received: from [192.26.75.58] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for tcplw@cray.com id AA17525; Fri, 4 Sep 92 11:50:36 -0700 Received: by rigden.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:tcplw@cray.com id AA15446; Fri, 4 Sep 92 11:50:34 -0700 Date: Fri, 4 Sep 92 11:50:34 -0700 From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9209041850.AA15446@rigden.wpd.sgi.com> To: tcplw@cray.com Subject: Re: eliminate TCP input demuxing vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: +--------------- | swise@bach.austin.ibm.com (Steve Wise) writes: | > hash algorithm REDUCES the need for connection ID passing that | > is used in other protocols (TP4, X.25, and XTP are cited). | > | > I'm wondering what the gain (if any) would be going from the | > hash table lookup described by the folks at Sequent to actually | > passing some sort of connection ID's... | | I know some XTP silicon designers who seemed to me to find the XTP | connection ID equivalent to the TCP/IP 96-bit connection ID of | ((host,port)(host,port)). I think both get hashed to find the "context." +--------------- The problem with the XTP "connection" ID is that its number space is local to a "route" ID, and route IDs are local to the "source MAC" addresses, so what you end up looking up is {connection, route, src_MAC}. Hmmm... 96 bits, just like TCP's {src_host, src_port, dst_host, dst_port}. So, yes, we [SGI/PEI joint-development] built some generic conditional extracting/hashing hardware into the PEI chipset's data pipeline, and we hashed {protocol, protocol- dependent-96-bits}, in hardware. I did a bunch of simulations on hashing functions for the hardware, to see what kind of hash distributions we got with actual traces from the traffic from a few internal LANs (no attempt at a really broad sampling), and found that: 1. Division by just about any primitive polynomial (think "prime", if you like) is a decent hash. 2. You really want about as many buckets as the average number of open connections, to avoid too many collisions and too-long chains. 3. If you including the cost of moving the most recent match to the head of its hash chain, the average cost of a lookup was (slightly) more expensive than *not* promoting the most recent match, for the traces I was working with with (a few million packets). This latter was a surprising result to me, until I realized that (a) the cost in memory/CPU cycles to promote a non-first entry in a chain to the first entry is more than the cost of sequentially searching a two-entry chain, and (b) most of the chains were short -- even *without* promoting recent matches, the average number of chain entries searched per lookup was ~1.1. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)390-1673 2011 N. Shoreline Blvd. Mountain View, CA 94043 Received: by hemlock.cray.com id AA28580; 4.1/CRI-5.5; Fri, 4 Sep 92 09:04:32 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA28573; 4.1/CRI-5.5; Fri, 4 Sep 92 09:04:28 CDT Received: from relay2.UU.NET by cray.com (4.1/CRI-MX 1.6ah) id AA12489; Fri, 4 Sep 92 09:04:25 CDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA13924; Fri, 4 Sep 92 10:04:23 -0400 Received: from unirsvl.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 100312.10335; Fri, 4 Sep 1992 10:03:12 EDT Received: by unirsvl.RSVL.UNISYS.COM (smail2.5) id AA25769; 4 Sep 92 08:48:47 CDT (Fri) Subject: Re: eliminate TCP input demuxing To: tcplw@cray.com Date: Fri, 4 Sep 92 8:48:45 CDT In-Reply-To: message from Steve Wise X-Mailer: ELM [version 2.2 PL0] Message-Id: <9209040848.AA25765@unirsvl.RSVL.UNISYS.COM> From: kurt@unirsvl.RSVL.UNISYS.COM > > In article , swise@bach.austin.ibm.com (Steve Wise) writes: > > .... > > I've read this paper. They note at the end that their proposed > > hash algorithm REDUCES the need for connection ID passing that > > is used in other protocols (TP4, X.25, and XTP are cited). > > > > I'm wondering what the gain (if any) would be going from the > > hash table lookup described by the folks at Sequent to actually > > passing some sort of connection ID's... > I think the point here was that the hashing reduced the search time enough so that there was less incentive to go to connection id passing. Connection id passing will be more efficient since there is no search at all. Kurt Matthys Received: by hemlock.cray.com id AA22507; 4.1/CRI-5.5; Thu, 3 Sep 92 13:49:12 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA22502; 4.1/CRI-5.5; Thu, 3 Sep 92 13:49:09 CDT Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 1.6ah) id AA00403; Thu, 3 Sep 92 13:49:06 CDT Date: Thu, 3 Sep 1992 11:49:04 MST From: "Sean O'Malley" Message-Id: <199209031849.AA21386@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA21386; Thu, 3 Sep 1992 11:49:04 MST To: tcplw@cray.com Subject: PCB's and Timestamps Cc: llp@cs.arizona.edu I was incorrect in my last message: > The problem with all of this is that we don't really have a hell > of a lot of room in the TCP option field if the SACK option is > ever standardized. It is highly unlikely that one would want to run 50,000 tcp connections at gigabit speeds (you would need a lot of buffer space). Thus the problems would appear to be orthogonal. Given this you could in fact simply overload the timestamp option to contain a PCB index. Simply open a connection requesting the timestamp option and a zero window scaling factor and use the timestamp field to store a PCB index (or poniter if you are brave). As define the recievier must treat the timestamp as a magic cookie and return it. (It will waste some time agonizing about which timestamp to return which in this case is irrelevent.) The other side of the connection could be using the timestamp for an actual timestamp or could also be using it for a PCB pointer. It would not affect the outcome in either case. Note that this could add signficant processing overhead to very low bandwidth connections. Sean W. O'Malley Received: by hemlock.cray.com id AA18122; 4.1/CRI-5.5; Thu, 3 Sep 92 12:16:58 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA18116; 4.1/CRI-5.5; Thu, 3 Sep 92 12:16:55 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 1.6ah) id AA23929; Thu, 3 Sep 92 12:16:52 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) for tcplw@cray.com id AA05342; Thu, 3 Sep 92 10:16:50 -0700 To: tcplw@cray.com Reply-To: vjs@sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com Control: cancel From: vjs@sgi.com (Vernon Schryver) Subject: cmsg cancel Message-Id: Date: Thu, 3 Sep 1992 17:13:03 GMT Approved: mailnews@sgi.sgi.com cancel Received: by hemlock.cray.com id AA18110; 4.1/CRI-5.5; Thu, 3 Sep 92 12:16:56 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA18106; 4.1/CRI-5.5; Thu, 3 Sep 92 12:16:53 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 1.6ah) id AA23928; Thu, 3 Sep 92 12:16:49 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) for tcplw@cray.com id AA05319; Thu, 3 Sep 92 10:16:47 -0700 To: tcplw@cray.com Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: eliminate TCP input demuxing Message-Id: Date: Thu, 3 Sep 1992 17:12:54 GMT In article , swise@bach.austin.ibm.com (Steve Wise) writes: > .... > I've read this paper. They note at the end that their proposed > hash algorithm REDUCES the need for connection ID passing that > is used in other protocols (TP4, X.25, and XTP are cited). > > I'm wondering what the gain (if any) would be going from the > hash table lookup described by the folks at Sequent to actually > passing some sort of connection ID's... I know some XTP silicon designers who seemed to me to find the XTP connection ID equivalent to the TCP/IP 96-bit connection ID of ((host,port)(host,port)). I think both get hashed to find the "context." Vernon Schryver, vjs@sgi.com (retrans #3) Received: by hemlock.cray.com id AA18101; 4.1/CRI-5.5; Thu, 3 Sep 92 12:16:49 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA18097; 4.1/CRI-5.5; Thu, 3 Sep 92 12:16:47 CDT Received: from sgi.sgi.com (SGI.COM) by cray.com (4.1/CRI-MX 1.6ah) id AA23921; Thu, 3 Sep 92 12:16:45 CDT Received: by sgi.sgi.com (920330.SGI/910110.SGI) for tcplw@cray.com id AA05290; Thu, 3 Sep 92 10:16:42 -0700 To: tcplw@cray.com Reply-To: vjs@sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com Control: cancel From: vjs@sgi.com (Vernon Schryver) Subject: cmsg cancel Message-Id: Date: Thu, 3 Sep 1992 17:11:24 GMT Approved: mailnews@sgi.sgi.com cancel Received: by hemlock.cray.com id AA16696; 4.1/CRI-5.5; Thu, 3 Sep 92 11:51:21 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA16686; 4.1/CRI-5.5; Thu, 3 Sep 92 11:51:19 CDT Received: from optima.cs.arizona.edu by cray.com (4.1/CRI-MX 1.6ah) id AA21925; Thu, 3 Sep 92 11:51:17 CDT Date: Thu, 3 Sep 1992 09:51:10 MST From: "Sean O'Malley" Message-Id: <199209031651.AA14747@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA14747; Thu, 3 Sep 1992 09:51:10 MST To: kurt@unirsvl.rsvl.unisys.com, tcplw@cray.com Subject: Re: TCP demultiplexing >Granted, PCB pointers is implementation specific, but the idea could be >generalized... I think that a better way to think about the problem is to use additional information in the TCP header to increase the cache size. Suppose we define a TCP option which contains two 16 bit values. Each end of the connection assigns a value to each connection and the other end simply reflects that value. (much in the way the timestamps are defined) This value is an index into a very large cache of PCB's (up to 64k). When a message arives the value in the option is used to look up a TCB. The same steps used to check the current single value cache are required. 1. check to see if anything is cached in that slot 2. check to see if the PCB is the right one. This approach would eliminated security and bad pointer problems and allow one to cache the 64k most used connections. The problem with all of this is that we don't really have a hell of a lot of room in the TCP option field if the SACK option is ever standardized. Sean O'Malley ps. I may implement this in our x-kernel TCP (which uses a hash table anyway). Anyone have any good test cases? Received: by hemlock.cray.com id AA15944; 4.1/CRI-5.5; Thu, 3 Sep 92 11:35:30 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA15940; 4.1/CRI-5.5; Thu, 3 Sep 92 11:35:28 CDT Received: from relay2.UU.NET by cray.com (4.1/CRI-MX 1.6ah) id AA20633; Thu, 3 Sep 92 11:35:25 CDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14062; Thu, 3 Sep 92 12:35:29 -0400 Received: from unirsvl.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 123404.19373; Thu, 3 Sep 1992 12:34:04 EDT Received: by unirsvl.RSVL.UNISYS.COM (smail2.5) id AA04436; 3 Sep 92 09:53:05 CDT (Thu) Subject: TCP demultiplexing To: tcplw@cray.com Date: Thu, 3 Sep 92 9:53:00 CDT X-Mailer: ELM [version 2.2 PL0] Message-Id: <9209030953.AA04432@unirsvl.RSVL.UNISYS.COM> From: kurt@unirsvl.RSVL.UNISYS.COM >Has there been any discussion about modifying (via RFC + negotiated TCP >option) TCP to allow the sending of PCB pointers in each TCP packet? >It seems to me that if at connect time, the TCPs send pass their >respective PCB pointers, and the pair of pointers are sent in all >traffic on this particular TCP connection, then on receive, tcp_input() >would not have to demux at all... > >Granted, PCB pointers is implementation specific, but the idea could be >generalized... >This could potentially greatly improve TPC/A type performance (mucho >connections, small packets, few packet trains)... We use this method on one of our proprietary protocols. It works very well. I have wished for it with TCP for awhile now. My problem is that even with a hash table with 511 slots in it I have to search approximately 50 tables on average if there are 50,000 connections. I would be interested in any info on good hashing functions for the socket information since that is all that you have to hash with. If there are any papers available that discuss this I would appreciate it someone would let me know. On the original question, you don't need to pass both pointers with every message: only the pointer of the destination of the message. Also, the option would not have to be a pointer per se, but could just be an identifier. The option could contain the length of the identifier which would allow different implementations to have different lengths and formats for the identifier. It is certainly reasonable to put some other information in the identifier other than the pointer to the connection table. A limit on the identifier length would probably be necessary though to limit how much space a receiver would have to allocate to store the peer's identifier. Kurt Matthys Received: by hemlock.cray.com id AA05807; 4.1/CRI-5.5; Thu, 3 Sep 92 08:37:07 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA05802; 4.1/CRI-5.5; Thu, 3 Sep 92 08:37:03 CDT Received: from MC8.MACH.CS.CMU.EDU by cray.com (4.1/CRI-MX 1.6ah) id AA07862; Thu, 3 Sep 92 08:37:00 CDT Message-Id: <9209031337.AA07862@cray.com> From: Christopher Maeda Date: Thu, 3 Sep 92 09:36:52 EDT To: swise@bach.austin.ibm.com Cc: tcplw@cray.com In-Reply-To: Steve Wise's message of Thu, 03 Sep 92 08:14:31 -0600 <9209031314.AA24178@bach.austin.ibm.com> Subject: eliminate TCP input demuxing Reply-To: cmaeda@cs.cmu.edu From: swise@bach.austin.ibm.com (Steve Wise) Date: Thu, 03 Sep 92 08:14:31 -0600 True. I guess PCB pointers was a bad choice...maybe connection ID's that are ONLY used by the host sending them. So, their semantics don't need to be standardized or defined... Hmm. I sub-optimally posted my message *before* carefully reading the McKenney paper (I have the version in Computing Systems). PCB pointers are perfectly reasonable when you think about them as connection ids. So if you ship around a connection id, I'm assuming you'll stick it in the tcp options. (This means you still have to ship around the ip addresses and tcp port numbers. Yuck.) Still, it would be interesting to implement it and see what kind of savings you get for various workloads. The algorithms people have looked at this (the in_pcblookup) problem. Search for papers on self-adjusting datastructures by {Tarjan, Sleator}. There was actually one result that showed the move to front heuristic was within a constant factor of optimal for certain distributions of requests. Chris Received: by hemlock.cray.com id AA04023; 4.1/CRI-5.5; Thu, 3 Sep 92 08:12:35 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA04014; 4.1/CRI-5.5; Thu, 3 Sep 92 08:12:33 CDT Received: from bach.austin.ibm.com by cray.com (4.1/CRI-MX 1.6ah) id AA06485; Thu, 3 Sep 92 08:12:31 CDT Received: by bach.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA24178; Thu, 3 Sep 1992 08:14:31 -0500 From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9209031314.AA24178@bach.austin.ibm.com> To: cmaeda@cs.cmu.edu Cc: tcplw@cray.com Subject: Re: eliminate TCP input demuxing In-Reply-To: Your message of Wed, 02 Sep 92 21:09:11 EDT. <9209030112.AA15865@bach.austin.ibm.com> Date: Thu, 03 Sep 92 08:14:31 -0600 | A number of problems with this approach: | | (1) Your tcp might be implemented in a language with garbage collected | storage. The pcb may get moved around during a gc. True. I guess PCB pointers was a bad choice...maybe connection ID's that are ONLY used by the host sending them. So, their semantics don't need to be standardized or defined... The remote TCP simply echos the ID you sent at connection time in every packet destined for this connection. Since the remote TCP does not use the ID,semantics do not have to be agreed upon between both TCPs. One side could use it's ID as a pointer to a PCB, while the other side uses it's ID as an index into an array... | (2) How big is a pointer? | 16bits? 18bits? 32bits? 64bits? What byte order? Right. Pointer is a bad choice...I would choose 32 bits :-) | | (3) If you don't very carefully check to see that the pointer points | to a real piece of memory that is in fact a pcb, you could crash your | machine or even create a potential security hole. Yep. There would be overhead in verifying this. Assuming the remote TCP is compliant to the proposed RFC would not be wise especially if you're passing memory pointers around... Stevo. Received: by hemlock.cray.com id AA03429; 4.1/CRI-5.5; Thu, 3 Sep 92 08:06:39 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA03423; 4.1/CRI-5.5; Thu, 3 Sep 92 08:06:34 CDT Received: from bach.austin.ibm.com by cray.com (4.1/CRI-MX 1.6ah) id AA05952; Thu, 3 Sep 92 08:06:32 CDT Received: by bach.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA13912; Thu, 3 Sep 1992 08:08:40 -0500 From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9209031308.AA13912@bach.austin.ibm.com> To: fisher@mips.com (William E. Fisher) Cc: hughes@hughes.network.com, tcplw@cray.com Subject: Re: eliminate TCP input demuxing In-Reply-To: Your message of Wed, 02 Sep 92 18:41:29 PDT. <9209030141.AA07139@orac.mips.com> Date: Thu, 03 Sep 92 08:08:39 -0600 | One paper that was recnetly published in measuring the PCB lookup overhead was: | | 1992 ACM SIGCOMM Conference Proceedings | August 17-20, 1992, Baltimore, Maryland | | Efficient Demultiplexing of Incoming TCP Packets | Paul McKenney and Ken Dove | Sequent Computer Systems | | The paper covers a number of different algorithms and presents some analytical | approximations to describe the behavior of various TCP demultiplexing algorithms | when presented with packet traffic resulting from running the TPC/A benchmarks. I've read this paper. They note at the end that their proposed hash algorithm REDUCES the need for connection ID passing that is used in other protocols (TP4, X.25, and XTP are cited). I'm wondering what the gain (if any) would be going from the hash table lookup described by the folks at Sequent to actually passing some sort of connection ID's... Received: by hemlock.cray.com id AA18240; 4.1/CRI-5.5; Wed, 2 Sep 92 20:42:02 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA18236; 4.1/CRI-5.5; Wed, 2 Sep 92 20:41:59 CDT Received: from spim.mips.com by cray.com (4.1/CRI-MX 1.6ah) id AA27004; Wed, 2 Sep 92 20:41:58 CDT Received: from orac.mips.com by spim.mips.com via SMTP (5.61.15/2.9) id AA00589; Wed, 2 Sep 92 18:41:55 -0700 Received: by orac.mips.com (5.61/Relay-2.9) id AA07139; Wed, 2 Sep 92 18:41:53 -0700 From: fisher@mips.com (William E. Fisher) Message-Id: <9209030141.AA07139@orac.mips.com> Subject: Re: eliminate TCP input demuxing To: swise@bach.austin.ibm.com (Steve Wise) Date: Wed, 2 Sep 92 18:41:29 PDT Cc: hughes@hughes.network.com, tcplw@cray.com, fisher@mips.com In-Reply-To: <9209030024.AA20694@bach.austin.ibm.com>; from "Steve Wise" at Sep 2, 92 7:24 pm X-Mailer: ELM [version 2.3 PL11] > > | Since you asked... > | > | You are right that in the case of packet trains (this packet is the > | same as the last) there is no performance difference because a simple > | check to see that this packet is the same as the previous one will > | allow you to have the PCB pointer already validated without processing > | any option fields. > | > | Tell me, how much faster is validating this option verses finding the > | PCB from scratch? > | > | If the packet is not part of a train, the you must at least validate > | that the PCB is still valid and indeed for this connection. > | > | Has the search been optimized? > | > | If the search is log n, [n connections open], then the average search > | cost is 1/2 log n. > | > | With significantly large hash tables then the overhead would be (on > | the average) a simple hash, single look up, and a simple verification. > | > | If you use the PCB option, what is the validation cost? What is the > | cost of pulling the PCB "cookie" out of the options? > | > | Have you MEASURED that IP lookup is indeed a high overhead point in > | your implementation? I have measured several TCP implementations and > | in the ones I have measures (not IBM) the total elimination IP lookup > | would not make a significant difference. Thread signalling, thread > > Are you measuring thousands of connections, each sending small > packets intermittently? > > | dispatches, data copies, Mbuf allocation, timer maintance, page fixing > | and or flushing are all areas to significantly improve the protocol > > Yes, these are all areas which need to be dealt with. Assuming, > however, that you can do input path with one data copy, then > maybe the demux time becomes important for reducing CPU usage > in DB & OLTP environments... > > | implementation without resorting [even gracefully] changing the > | protocol. > > I agree. Again, just wondering if folks have considered > the approach I mentioned. I believe this type of demuxing > is done by other networks/protocols? Like Ultra-net? XTP? > > > Currently in AIX 3.2, we're using a linear search (ala RENO) > to find the PCB. If it was the last one accessed, we don't > have to search. I am aware of the hash table algorithms and > realize that this will help. > One paper that was recnetly published in measuring the PCB lookup overhead was: 1992 ACM SIGCOMM Conference Proceedings August 17-20, 1992, Baltimore, Maryland Efficient Demultiplexing of Incoming TCP Packets Paul McKenney and Ken Dove Sequent Computer Systems The paper covers a number of different algorithms and presents some analytical approximations to describe the behavior of various TCP demultiplexing algorithms when presented with packet traffic resulting from running the TPC/A benchmarks. The McKenney and Dove paper also references some of the original e-mail postings on this subject posted to the tcp-ip mailing list. 1) Jon Crowcroft. Re: Inefficient dfemultiplexing by 4.3 TCP/IP Message-ID 2142@ucl-cs.uucp, to the tcp-ip mailing list, December 1991 2) Lance Visser. Re: Inefficient dfemultiplexing by 4.3 TCP/IP Message-ID visser.691884939@convex.convex.com to the tcp-ip mailing list, December 1991 On other paper which might be of interest is: Multiplexing Issues in Communciation System Design David Fieldmeier 1990 ACM SIGCOMM Conference Proceedings, Pages 209-219 September 1990, Philadelphia, PA -- Bill Received: by hemlock.cray.com id AA17723; 4.1/CRI-5.5; Wed, 2 Sep 92 20:09:57 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA17719; 4.1/CRI-5.5; Wed, 2 Sep 92 20:09:55 CDT Received: from MC8.MACH.CS.CMU.EDU by cray.com (4.1/CRI-MX 1.6ah) id AA25722; Wed, 2 Sep 92 20:09:52 CDT Message-Id: <9209030109.AA25722@cray.com> From: Christopher Maeda Date: Wed, 2 Sep 92 21:09:11 EDT To: swise@bach.austin.ibm.com Cc: tcplw@cray.com In-Reply-To: Steve Wise's message of Wed, 02 Sep 92 16:41:15 -0600 <9209022141.AA17990@bach.austin.ibm.com> Subject: eliminate TCP input demuxing Reply-To: cmaeda@cs.cmu.edu From: swise@bach.austin.ibm.com (Steve Wise) Date: Wed, 02 Sep 92 16:41:15 -0600 Has there been any discussion about modifying (via RFC + negotiated TCP option) TCP to allow the sending of PCB pointers in each TCP packet? It seems to me that if at connect time, the TCPs send pass their respective PCB pointers, and the pair of pointers are sent in all traffic on this particular TCP connection, then on receive, tcp_input() would not have to demux at all... A number of problems with this approach: (1) Your tcp might be implemented in a language with garbage collected storage. The pcb may get moved around during a gc. (2) How big is a pointer? 16bits? 18bits? 32bits? 64bits? What byte order? (3) If you don't very carefully check to see that the pointer points to a real piece of memory that is in fact a pcb, you could crash your machine or even create a potential security hole. Chris Received: by hemlock.cray.com id AA16919; 4.1/CRI-5.5; Wed, 2 Sep 92 19:22:26 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA16914; 4.1/CRI-5.5; Wed, 2 Sep 92 19:22:24 CDT Received: from bach.austin.ibm.com by cray.com (4.1/CRI-MX 1.6ah) id AA23998; Wed, 2 Sep 92 19:22:23 CDT Received: by bach.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20694; Wed, 2 Sep 1992 19:24:30 -0500 From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9209030024.AA20694@bach.austin.ibm.com> To: hughes@hughes.network.com (Jim Hughes) Cc: tcplw@cray.com Subject: Re: eliminate TCP input demuxing In-Reply-To: Your message of Wed, 02 Sep 92 19:16:57 EDT. Date: Wed, 02 Sep 92 19:24:29 -0600 | Since you asked... | | You are right that in the case of packet trains (this packet is the | same as the last) there is no performance difference because a simple | check to see that this packet is the same as the previous one will | allow you to have the PCB pointer already validated without processing | any option fields. | | Tell me, how much faster is validating this option verses finding the | PCB from scratch? | | If the packet is not part of a train, the you must at least validate | that the PCB is still valid and indeed for this connection. | | Has the search been optimized? | | If the search is log n, [n connections open], then the average search | cost is 1/2 log n. | | With significantly large hash tables then the overhead would be (on | the average) a simple hash, single look up, and a simple verification. | | If you use the PCB option, what is the validation cost? What is the | cost of pulling the PCB "cookie" out of the options? | | Have you MEASURED that IP lookup is indeed a high overhead point in | your implementation? I have measured several TCP implementations and | in the ones I have measures (not IBM) the total elimination IP lookup | would not make a significant difference. Thread signalling, thread Are you measuring thousands of connections, each sending small packets intermittently? | dispatches, data copies, Mbuf allocation, timer maintance, page fixing | and or flushing are all areas to significantly improve the protocol Yes, these are all areas which need to be dealt with. Assuming, however, that you can do input path with one data copy, then maybe the demux time becomes important for reducing CPU usage in DB & OLTP environments... | implementation without resorting [even gracefully] changing the | protocol. I agree. Again, just wondering if folks have considered the approach I mentioned. I believe this type of demuxing is done by other networks/protocols? Like Ultra-net? XTP? Currently in AIX 3.2, we're using a linear search (ala RENO) to find the PCB. If it was the last one accessed, we don't have to search. I am aware of the hash table algorithms and realize that this will help. STevo. Received: by hemlock.cray.com id AA15759; 4.1/CRI-5.5; Wed, 2 Sep 92 18:17:19 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA15754; 4.1/CRI-5.5; Wed, 2 Sep 92 18:17:16 CDT Received: from hughes.network.com by cray.com (4.1/CRI-MX 1.6ah) id AA21271; Wed, 2 Sep 92 18:17:14 CDT Received: by hughes.network.com (/\==/\ Smail3.1.25.1 #25.6) id ; Wed, 2 Sep 92 18:16 EDT Message-Id: From: hughes@hughes.network.com (Jim Hughes) Subject: Re: eliminate TCP input demuxing To: swise@bach.austin.ibm.com (Steve Wise) Date: Wed, 2 Sep 92 19:16:57 EDT Cc: tcplw@cray.com In-Reply-To: <9209022141.AA17990@bach.austin.ibm.com>; from "Steve Wise" at Sep 2, 92 4:41 pm X-Mailer: ELM [version 2.3 PL11] > > > Hi! > > Has there been any discussion about modifying (via RFC + negotiated TCP > option) TCP to allow the sending of PCB pointers in each TCP packet? > It seems to me that if at connect time, the TCPs send pass their > respective PCB pointers, and the pair of pointers are sent in all > traffic on this particular TCP connection, then on receive, tcp_input() > would not have to demux at all... > > Granted, PCB pointers is implementation specific, but the idea could be > generalized... > > This could potentially greatly improve TPC/A type performance (mucho > connections, small packets, few packet trains)... > > Any thoughts? Since you asked... You are right that in the case of packet trains (this packet is the same as the last) there is no performance difference because a simple check to see that this packet is the same as the previous one will allow you to have the PCB pointer already validated without processing any option fields. Tell me, how much faster is validating this option verses finding the PCB from scratch? If the packet is not part of a train, the you must at least validate that the PCB is still valid and indeed for this connection. Has the search been optimized? If the search is log n, [n connections open], then the average search cost is 1/2 log n. With significantly large hash tables then the overhead would be (on the average) a simple hash, single look up, and a simple verification. If you use the PCB option, what is the validation cost? What is the cost of pulling the PCB "cookie" out of the options? Have you MEASURED that IP lookup is indeed a high overhead point in your implementation? I have measured several TCP implementations and in the ones I have measures (not IBM) the total elimination IP lookup would not make a significant difference. Thread signalling, thread dispatches, data copies, Mbuf allocation, timer maintance, page fixing and or flushing are all areas to significantly improve the protocol implementation without resorting [even gracefully] changing the protocol. > Steve Wise IBM AWD - Austin, TX. But I am open to other thoughts. jim Received: by hemlock.cray.com id AA10150; 4.1/CRI-5.5; Wed, 2 Sep 92 16:39:16 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA10139; 4.1/CRI-5.5; Wed, 2 Sep 92 16:39:12 CDT Received: from bach.austin.ibm.com by cray.com (4.1/CRI-MX 1.6ah) id AA16256; Wed, 2 Sep 92 16:39:10 CDT Received: by bach.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17990; Wed, 2 Sep 1992 16:41:16 -0500 From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9209022141.AA17990@bach.austin.ibm.com> To: tcplw@cray.com Subject: eliminate TCP input demuxing Date: Wed, 02 Sep 92 16:41:15 -0600 Hi! Has there been any discussion about modifying (via RFC + negotiated TCP option) TCP to allow the sending of PCB pointers in each TCP packet? It seems to me that if at connect time, the TCPs send pass their respective PCB pointers, and the pair of pointers are sent in all traffic on this particular TCP connection, then on receive, tcp_input() would not have to demux at all... Granted, PCB pointers is implementation specific, but the idea could be generalized... This could potentially greatly improve TPC/A type performance (mucho connections, small packets, few packet trains)... Any thoughts? ******** Steve Wise IBM AWD - Austin, TX. Internal: swise@elric.austin.ibm.com VNET: AUSVMQ(SWISE) Internet: swise@bach.austin.ibm.com Received: by hemlock.cray.com id AA02200; 4.1/CRI-5.5; Wed, 19 Aug 92 10:21:36 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA02195; 4.1/CRI-5.5; Wed, 19 Aug 92 10:21:34 CDT Received: from bach.austin.ibm.com by cray.com (4.1/CRI-MX 1.6ah) id AA02784; Wed, 19 Aug 92 10:21:32 CDT Received: by bach.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA13322; Wed, 19 Aug 1992 10:23:20 -0500 From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9208191523.AA13322@bach.austin.ibm.com> To: braden@ISI.EDU Cc: tcplw@cray.com Subject: Re: Modified TCP congestion avoidance algorithm In-Reply-To: Your message of Tue, 18 Aug 92 16:56:47 MST. <199208182356.AA14068@braden.isi.edu> Date: Wed, 19 Aug 92 10:23:20 -0600 Thanx Bob. I did not realize the algorithm was done in Reno tcp. Knowing this, I don't need you to send me the original discussions...I'll read the code... Thanx again, Stevo. | | | I will dig it out and send it, but you may find the most useful | reference to be the BSD Reno release of TCP. It is well commented | and quite clear. | | Bob Braden | Received: by hemlock.cray.com id AA05330; 4.1/CRI-5.5; Tue, 18 Aug 92 18:57:33 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA05326; 4.1/CRI-5.5; Tue, 18 Aug 92 18:57:32 CDT Received: from venera.isi.edu by cray.com (4.1/CRI-MX 1.6ah) id AA16766; Tue, 18 Aug 92 18:57:28 CDT Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Tue, 18 Aug 1992 16:57:12 -0700 Date: Tue, 18 Aug 1992 16:56:47 -0700 From: braden@ISI.EDU Posted-Date: Tue, 18 Aug 1992 16:56:47 -0700 Message-Id: <199208182356.AA14068@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Tue, 18 Aug 1992 16:56:47 -0700 To: swise@bach.austin.ibm.com, tcplw@cray.com Subject: Re: Modified TCP congestion avoidance algorithm I will dig it out and send it, but you may find the most useful reference to be the BSD Reno release of TCP. It is well commented and quite clear. Bob Braden Received: by hemlock.cray.com id AA27559; 4.1/CRI-5.5; Tue, 18 Aug 92 15:30:30 CDT Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA27555; 4.1/CRI-5.5; Tue, 18 Aug 92 15:30:26 CDT Received: from bach.austin.ibm.com by cray.com (4.1/CRI-MX 1.6ah) id AA05201; Tue, 18 Aug 92 15:30:21 CDT Received: by bach.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA06241; Tue, 18 Aug 1992 15:32:25 -0500 From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9208182032.AA06241@bach.austin.ibm.com> To: tcplw@cray.com Subject: Modified TCP congestion avoidance algorithm Date: Tue, 18 Aug 92 15:32:24 -0600 RFC 1323 refers to a message from Jacobson sent to the end2end-interest mailing list describing an algorithm to help reduce the performance degradation of retransmits on an LFN. The RFC refers to this as the Fast Retransmit and Fast Recovery Algorithms. Does anyone have a copy of this they could email to me? Thanx in advance, ******** Steve Wise IBM AWD - Austin, TX. Internal: swise@elric.austin.ibm.com VNET: AUSVMQ(SWISE) Internet: swise@bach.austin.ibm.com Received: by hemlock.cray.com id AA10057; 4.1/CRI-5.5; Mon, 6 Jul 92 23:41:53 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA10053; 4.1/CRI-5.5; Mon, 6 Jul 92 23:41:51 CDT Received: from sgi.sgi.com (SGI.COM) by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA15341; Mon, 6 Jul 92 23:41:45 CDT Received: from [192.26.75.8] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for tcplw@timbuk.cray.com id AA18203; Mon, 6 Jul 92 21:41:44 -0700 Received: by florida.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:tcplw@timbuk.cray.com id AA01379; Mon, 6 Jul 92 21:41:43 -0700 Date: Mon, 6 Jul 92 21:41:43 -0700 From: skibo@florida.wpd.sgi.com (Thomas Skibo) Message-Id: <9207070441.AA01379@florida.wpd.sgi.com> To: tcplw@cray.com Subject: minor bug in rfc 1323 patch for BSD net 2 Folks: I thought I'd let everyone in on a small bug I've found in my BSD Net 2 implementation of the RFC 1323 TCP extensions. It's kind of intriguing. There is a test to see if the range of sequence numbers of a segment contains the value in Last.ACK.sent at line 812 of tcp_input.c. If the test succeeds, TS.recent should be updated. I forgot to take into account that SYN and FIN take up a sequence number. So, TS.recent isn't updated on a FIN segment (unless it carries other data). The implication is subtle. The time-stamp reply on the segment that ACK's the FIN will not reflect the value of the time-stamp of the FIN. But, the acknowledgement number is increased and so the receiver (the TCP that sent the FIN) uses the echo reply to calculate a round-trip time sample. If the connection was idle for quite a while (idle in the direction that the FIN was sent), the calculated round-trip time can be HUGE and really throw off the smoothed round-trip time. This wouldn't be a problem (the connection is closed in that direction and so the retransmit timer isn't used anymore) except that on Reno systems the srtt and rttvar values might be merged into the routing entry. So the final result could be inflated rtt values in routing entries. I've attached a patch that I'm 99% sure will work but it's untested. I think I'll attach this letter to the README file in the shar file on uxc.cso.uiuc.edu (/pub/tcplw.shar.Z) as well. -Thomas -------------------------------------cut here------------------------- *** tcp_input.c.orig Mon Jul 6 23:07:49 1992 --- tcp_input.c Mon Jul 6 23:08:03 1992 *************** *** 810,817 **** /* If last ACK falls within this segments sequence numbers, * record its time-stamp. */ ! if ( ts_val && SEQ_LEQ( ti->ti_seq, tp->last_ack_sent ) && ! SEQ_LT( tp->last_ack_sent, ti->ti_seq+ti->ti_len) ) { tp->ts_recent_age = 0; tp->ts_recent = ts_val; } --- 810,818 ---- /* If last ACK falls within this segments sequence numbers, * record its time-stamp. */ ! if ( ts_present && SEQ_LEQ( ti->ti_seq, tp->last_ack_sent ) && ! SEQ_LT( tp->last_ack_sent, ti->ti_seq+ti->ti_len+ ! ((tiflags&(TH_SYN|TH_FIN))!=0) ) ) { tp->ts_recent_age = 0; tp->ts_recent = ts_val; } Thomas Skibo Advanced Networking Group, Silicon Graphics, Inc. skibo@sgi.com Received: by hemlock.cray.com id AA01641; 4.1/CRI-5.5; Mon, 22 Jun 92 11:14:27 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA01637; 4.1/CRI-5.5; Mon, 22 Jun 92 11:14:25 CDT Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA21885; Mon, 22 Jun 92 11:14:22 CDT Received: by handel.cray.com id AA05308; 5.57/CRI-5.5; Mon, 22 Jun 92 11:13:29 -0500 Date: Mon, 22 Jun 92 11:13:29 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9206221613.AA05308@handel.cray.com> To: tcplw@cray.com Subject: second message And here's a follow-up message that also got bounced by our mail gateway... -David Borman, dab@cray.com Received: by hemlock.cray.com id AA01440; 4.1/CRI-5.5; Mon, 22 Jun 92 11:10:40 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA01436; 4.1/CRI-5.5; Mon, 22 Jun 92 11:10:37 CDT Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA21196; Mon, 22 Jun 92 11:10:33 CDT Received: by handel.cray.com id AA05295; 5.57/CRI-5.5; Mon, 22 Jun 92 11:09:41 -0500 Date: Mon, 22 Jun 92 11:09:41 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9206221609.AA05295@handel.cray.com> To: tcplw@cray.com Subject: Message from Van Van's attached message got bounced when going to over half of the tcplw mailing list. Seems a patch that was installed to sendmail on our mail gateway broke MX record processing... They claim it is now fixed, so I am re-sending Van's message for those of you who didn't get it. Sorry to those of you who get it twice... -David Borman, dab@cray.com From: hughes@hughes.network.com (Jim Hughes) Subject: Re: Checksumming on TCP To: van@ee.lbl.gov (Van Jacobson) Date: Mon, 22 Jun 92 9:06:59 EDT Cc: swise@bach.austin.ibm.com, tcplw@cray.com X-Mailer: ELM [version 2.3 PL11] > > > Yes, 4.4 and the long fat pipe mods are available. > > Tom Skibo's long fat pipe mods were made to the BSD Net-2 > release, not 4.4. The architecture of Net-2 is fairly close to > that of 4.2/3 BSD and doesn't include the changes that Craig > mentioned. The code that I hope will be in the 4.4 release is a > ground-up re-architecting of the BSD networking kernel & is very > different from Net-2. E.g., mbufs are gone, netipl is gone, > ip_output is gone, the arp table is gone, all the xxx_usrreq are > gone, xxx_usrsend (the protocol specific replacement for sosend > that Craig mentioned) and xxx_usrrecv (the equivalent > replacement for soreceive) have been added, ... The 4.4 code > isn't available yet. I had hoped to have it on the 4.4alpha > tape coming out in July but my personal life went through major > trauma starting last December & I've been catatonic most of the > last 6 months. Although I'm not really functioning technically > yet, most of the remaining work is just cleanup & integration > (e.g., the OSI stack won't compile with the new architecture > yet) and I'm pretty sure an alpha of the networking code will be > available by the end of the summer. Van, I apologize for my incorrect statement. The confusion is based on the definition of 4.4. There is a tape called 4.4free and Thomas did code to that. I don't have any knowledge of what level of networking is in that release. > - Van jim Received: by hemlock.cray.com id AA19359; 4.1/CRI-5.5; Mon, 22 Jun 92 08:08:25 CDT Received: from timbuk (timbuk.cray.com) by hemlock.cray.com id AA19355; 4.1/CRI-5.5; Mon, 22 Jun 92 08:08:23 CDT Received: from hughes.network.com by timbuk (4.1/CRI-MX 1.6ag) id AA23148; Mon, 22 Jun 92 08:08:21 CDT Received: by hughes.network.com (/\==/\ Smail3.1.25.1 #25.6) id ; Mon, 22 Jun 92 08:06 EDT Message-Id: From: hughes@hughes.network.com (Jim Hughes) Subject: Re: Checksumming on TCP To: van@ee.lbl.gov (Van Jacobson) Date: Mon, 22 Jun 92 9:06:59 EDT Cc: swise@bach.austin.ibm.com, tcplw@cray.com In-Reply-To: <9206221101.AA24312@rx7.ee.lbl.gov>; from "Van Jacobson" at Jun 22, 92 4:01 am X-Mailer: ELM [version 2.3 PL11] > > > Yes, 4.4 and the long fat pipe mods are available. > > Tom Skibo's long fat pipe mods were made to the BSD Net-2 > release, not 4.4. The architecture of Net-2 is fairly close to > that of 4.2/3 BSD and doesn't include the changes that Craig > mentioned. The code that I hope will be in the 4.4 release is a > ground-up re-architecting of the BSD networking kernel & is very > different from Net-2. E.g., mbufs are gone, netipl is gone, > ip_output is gone, the arp table is gone, all the xxx_usrreq are > gone, xxx_usrsend (the protocol specific replacement for sosend > that Craig mentioned) and xxx_usrrecv (the equivalent > replacement for soreceive) have been added, ... The 4.4 code > isn't available yet. I had hoped to have it on the 4.4alpha > tape coming out in July but my personal life went through major > trauma starting last December & I've been catatonic most of the > last 6 months. Although I'm not really functioning technically > yet, most of the remaining work is just cleanup & integration > (e.g., the OSI stack won't compile with the new architecture > yet) and I'm pretty sure an alpha of the networking code will be > available by the end of the summer. Van, I apologize for my incorrect statement. The confusion is based on the definition of 4.4. There is a tape called 4.4free and Thomas did code to that. I don't have any knowledge of what level of networking is in that release. > - Van jim To: hughes@hughes.network.com (Jim Hughes) Cc: swise@bach.austin.ibm.com (Steve Wise), tcplw@cray.com Subject: Re: Checksumming on TCP Date: Mon, 22 Jun 92 04:01:35 PDT From: Van Jacobson > Yes, 4.4 and the long fat pipe mods are available. Tom Skibo's long fat pipe mods were made to the BSD Net-2 release, not 4.4. The architecture of Net-2 is fairly close to that of 4.2/3 BSD and doesn't include the changes that Craig mentioned. The code that I hope will be in the 4.4 release is a ground-up re-architecting of the BSD networking kernel & is very different from Net-2. E.g., mbufs are gone, netipl is gone, ip_output is gone, the arp table is gone, all the xxx_usrreq are gone, xxx_usrsend (the protocol specific replacement for sosend that Craig mentioned) and xxx_usrrecv (the equivalent replacement for soreceive) have been added, ... The 4.4 code isn't available yet. I had hoped to have it on the 4.4alpha tape coming out in July but my personal life went through major trauma starting last December & I've been catatonic most of the last 6 months. Although I'm not really functioning technically yet, most of the remaining work is just cleanup & integration (e.g., the OSI stack won't compile with the new architecture yet) and I'm pretty sure an alpha of the networking code will be available by the end of the summer. - Van Received: by hemlock.cray.com id AA14552; 4.1/CRI-5.5; Mon, 22 Jun 92 06:00:49 CDT Received: from timbuk (timbuk.cray.com) by hemlock.cray.com id AA14547; 4.1/CRI-5.5; Mon, 22 Jun 92 06:00:47 CDT Received: from rx7.ee.lbl.gov by timbuk (4.1/CRI-MX 1.6ag) id AA08331; Mon, 22 Jun 92 06:00:46 CDT Received: by rx7.ee.lbl.gov for tcplw@timbuk.cray.com (5.65/1.44r) id AA24312; Mon, 22 Jun 92 04:01:36 -0700 Message-Id: <9206221101.AA24312@rx7.ee.lbl.gov> To: hughes@hughes.network.com (Jim Hughes) Cc: swise@bach.austin.ibm.com (Steve Wise), tcplw@cray.com Subject: Re: Checksumming on TCP In-Reply-To: Your message of Fri, 19 Jun 92 14:16:04 EDT. Date: Mon, 22 Jun 92 04:01:35 PDT From: Van Jacobson > Yes, 4.4 and the long fat pipe mods are available. Tom Skibo's long fat pipe mods were made to the BSD Net-2 release, not 4.4. The architecture of Net-2 is fairly close to that of 4.2/3 BSD and doesn't include the changes that Craig mentioned. The code that I hope will be in the 4.4 release is a ground-up re-architecting of the BSD networking kernel & is very different from Net-2. E.g., mbufs are gone, netipl is gone, ip_output is gone, the arp table is gone, all the xxx_usrreq are gone, xxx_usrsend (the protocol specific replacement for sosend that Craig mentioned) and xxx_usrrecv (the equivalent replacement for soreceive) have been added, ... The 4.4 code isn't available yet. I had hoped to have it on the 4.4alpha tape coming out in July but my personal life went through major trauma starting last December & I've been catatonic most of the last 6 months. Although I'm not really functioning technically yet, most of the remaining work is just cleanup & integration (e.g., the OSI stack won't compile with the new architecture yet) and I'm pretty sure an alpha of the networking code will be available by the end of the summer. - Van Received: by hemlock.cray.com id AA21156; 4.1/CRI-5.5; Fri, 19 Jun 92 14:09:56 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA21152; 4.1/CRI-5.5; Fri, 19 Jun 92 14:09:54 CDT Received: from sgi.sgi.com (SGI.COM) by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA18519; Fri, 19 Jun 92 14:09:51 CDT Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for tcplw@cray.com id AA22797; Fri, 19 Jun 92 12:09:45 -0700 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:tcplw@cray.com id AA12009; Fri, 19 Jun 92 13:09:40 -0600 Date: Fri, 19 Jun 92 13:09:40 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9206191909.AA12009@rhyolite.wpd.sgi.com> To: atm@sun.com, tcplw@cray.com Subject: TCP checksums, bcopys, etc I composed and flushed responses to Craig Partridge and others along these lines 3 times yesterday. I can't help myself today. -Both input and output data is often (but not always) not copied when sending or receiving TCP buffers in Silicon Graphics' UNIX system. At speed, the data sees each system bus between the fiber and user-space one (1) time. It does see the local, on-board or on-chip buses inside the FDDI hardware more often. In other words, there are no byte copies between user space and kernel space when things are running at speed. -It is possible to finesse the checksum either 1. during the user-space/system-buffer copies 2. in the driver and below Since I choose to make byte copies run fast by not doing them, you might guess that I prefer (2). -The calculation of checksum for TCP/IP/FDDI does not consume most of the cycles in systems I know about, despite the fact that the copies consume zero (0) CPU cycles. However, I will admit we do a little more than 17-22 Mb/s. (reported in the ATM mailing list). SHEEEESH! That's only twice ethernet. You can do better than that with a 16MHz CPU and a stupid DMA engine even the designer won't acknowledge, and while computing the checksum and using the nearly the old number of bcopy()'s on the host. -Any system now in a lab that does not consume substantially more than 50% of the ~98Mb/s FDDI speed of light with a single TCP virtual circuit should be cancelled to avoid embarrassment. After all, we demonstrated 50Mb/s at InterOP91 with FDDI hardware we are not proud of, while simultaneously doing CFD simulations. -Neither the checksum nor the bcopy() should matter in modern systems. Modern CPU's can compute the TCP checksum in <= 1 clock/byte, and can copy data in <0.5 clocks/byte. What makes bcopy() or the checksumming slow are the cache misses and pollution. Depending on the upper layer protocol, you may have to pay the cache regardless, making the cost of byte copies and checksumming 5-20% of the inevitable cache cost. -The TCP checksum has some handy properties. The checksum of the concatenation of two buffers (containing 16-bit words) is a sum of their checksums. The checksum of part of a buffer is a difference of the checksum of the entire buffer and the checksum of the other part. These two properties computing the checksum in drivers or in user-space copies much easier. You need not worry about computing the checksum of the psuedo-header in copyin(). -Vector machines may find the calculation of the checksum more onerous. -I do not know about Gb/s TCP, such as Cray has reported. Vernon Schryver, vjs@sgi.com Received: by hemlock.cray.com id AA18793; 4.1/CRI-5.5; Fri, 19 Jun 92 13:29:14 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA18789; 4.1/CRI-5.5; Fri, 19 Jun 92 13:29:12 CDT Received: from newton.ncsa.uiuc.edu by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA16166; Fri, 19 Jun 92 13:29:10 CDT Received: from europa.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23265 (5.65a/IDA-1.4.2 for tcplw@timbuk.cray.com); Fri, 19 Jun 92 13:29:09 -0500 Return-Path: Received: by europa.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA01173; Fri, 19 Jun 92 13:29:08 CDT Date: Fri, 19 Jun 92 13:29:08 CDT From: rbutler@ncsa.uiuc.edu (Randy Butler) Message-Id: <9206191829.AA01173@europa.ncsa.uiuc.edu> To: hughes@hughes.network.com, swise@bach.austin.ibm.com Subject: Re: Checksumming on TCP Cc: tcplw@cray.com >Yes, 4.4 and the long fat pipe mods are available. The mods can be >gotten from Thomas Skibo @UIUC.edu Thomas has moved on now but the mods can still be gotten from the anonymous ftp server "uxc.cso.uiuc.edu" and found in the pub directory. Randy Butler National Center for Supercomputing Applications Received: by hemlock.cray.com id AA18122; 4.1/CRI-5.5; Fri, 19 Jun 92 13:16:47 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA18117; 4.1/CRI-5.5; Fri, 19 Jun 92 13:16:44 CDT Received: from hughes.network.com by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA15078; Fri, 19 Jun 92 13:16:42 CDT Received: by hughes.network.com (/\==/\ Smail3.1.25.1 #25.6) id ; Fri, 19 Jun 92 13:16 EDT Message-Id: From: hughes@hughes.network.com (Jim Hughes) Subject: Re: Checksumming on TCP To: swise@bach.austin.ibm.com (Steve Wise) Date: Fri, 19 Jun 92 14:16:04 EDT Cc: craig@aland.bbn.com, tcplw@cray.com In-Reply-To: <9206191720.AA23155@bach.austin.ibm.com>; from "Steve Wise" at Jun 19, 92 12:20 pm X-Mailer: ELM [version 2.3 PL11] > > > | What has been done in 4.4 and in the modifications to 4.3 that I'm > | aware of to support rolling checksum and copy loops is to add protocol > | specific versions of sosend() to the protosw structure and have sendit() > | call these routines (if they exist) instead of sosend(). > > Is the BSD 4.4 code available? Yes, 4.4 and the long fat pipe mods are available. The mods can be gotten from Thomas Skibo @UIUC.edu > | > | far simpler. Also, by being in protocol-specific code when copying data > | from application space, one can make more intelligent memory placement > | decisions (e.g. Jacobson's idea to copy direct from application space > | to interface memory requires that one know which interface one will send > | out -- which is a protocol-specific decision). Finally, one can easily > > About Van Jacobson's stuff. Does the TCP segment stay in > interface memory until the ACK is received? This memory's on the > adapter, right? > > | roll together checksum and copy because one knows how big a segment one > | is going to send and which checksum algorithm to use. > | > | Hope this is useful. > > It is...thanx > Stevo. > This is exactly what is being worked on in the Gigabit Nectar testbed. Outboard memory for ACK storage, and also for data that the Appl has not issued a read for, so that the data can be copied directly to the appl from network memory and vice versa on receive. Also the checksum is calculated as the packet is moved out to adapter memory, and also as it is being received into adapter memory. The software issues are indeed large, and we are working on that as well. Hopefully it will be on 4.4 large winow TCP. jim Received: by hemlock.cray.com id AA15549; 4.1/CRI-5.5; Fri, 19 Jun 92 12:24:44 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA15543; 4.1/CRI-5.5; Fri, 19 Jun 92 12:24:43 CDT Received: from bach.austin.ibm.com by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA11792; Fri, 19 Jun 92 12:24:39 CDT Received: by bach.austin.ibm.com (AIX 2.1 2/4.03) id AA23155; Fri, 19 Jun 92 12:20:33 CDT From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9206191720.AA23155@bach.austin.ibm.com> To: Craig Partridge Cc: tcplw@cray.com Subject: Re: Checksumming on TCP In-Reply-To: Your message of Fri, 19 Jun 92 09:32:28 MST. <9206191632.AA17814@aland.bbn.com> Date: Fri, 19 Jun 92 12:20:32 -0600 | What has been done in 4.4 and in the modifications to 4.3 that I'm | aware of to support rolling checksum and copy loops is to add protocol | specific versions of sosend() to the protosw structure and have sendit() | call these routines (if they exist) instead of sosend(). Is the BSD 4.4 code available? | | far simpler. Also, by being in protocol-specific code when copying data | from application space, one can make more intelligent memory placement | decisions (e.g. Jacobson's idea to copy direct from application space | to interface memory requires that one know which interface one will send | out -- which is a protocol-specific decision). Finally, one can easily About Van Jacobson's stuff. Does the TCP segment stay in interface memory until the ACK is received? This memory's on the adapter, right? | roll together checksum and copy because one knows how big a segment one | is going to send and which checksum algorithm to use. | | Hope this is useful. It is...thanx Stevo. Received: by hemlock.cray.com id AA12808; 4.1/CRI-5.5; Fri, 19 Jun 92 11:35:05 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA12798; 4.1/CRI-5.5; Fri, 19 Jun 92 11:35:01 CDT Received: from uu2.psi.com by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA09053; Fri, 19 Jun 92 11:34:57 CDT Received: from port14.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA09810; Fri, 19 Jun 92 12:33:14 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA17814; Fri, 19 Jun 92 09:32:28 PDT Message-Id: <9206191632.AA17814@aland.bbn.com> To: swise@bach.austin.ibm.com (Steve Wise) Cc: tcplw@cray.com Cc: posix-net-ptp@ucbvax.Berkeley.EDU Subject: re: Checksumming on TCP Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 19 Jun 92 09:32:28 -0700 Sender: craig@aland.bbn.com > One argument, which I agree with, is that you should reduce your > copies/moves of the data to a minimum. If you're doing more than one > copy, you might as well not worry about the checksum time...And, > assuming you must move from user space to system memory (or adapter > memory), do the checksum during this move. > > Question: > On a BSD 4.3 RENO based system, is this possible? My understanding is > that you move it into a mbuf chain in the socket layer. Since there is > no guarantee that the exact chain will be shipped as a TCP segment, > what good is checksumming this data during the copy into the > socketbuff? > > My guess would be to only move in chunks of TCP segments in at a time, > checksum while you move it into the socket layer, then make sure TCP > sends exactly that segment using the checksum computed during the > move. > > Since (I believe) the checksum includes parts of the IP and TCP > headers, then this move from user space to kernel space would need to > be done in tcp_output() instead of sosend()...hmmm Steve: Well, you could modify sosend to checksum each mbuf separately and store the IP checksum of that mbuf's worth of data in the mbuf. Then when you assemble the TCP segment, you simply add together the IP checksums of the constituent mbufs. However, to make this practice useful you'll want to keep mbufs small (i.e. no clusters) which will hurt performance in other ways. What has been done in 4.4 and in the modifications to 4.3 that I'm aware of to support rolling checksum and copy loops is to add protocol specific versions of sosend() to the protosw structure and have sendit() call these routines (if they exist) instead of sosend(). This practice is a win on multiple levels -- a lot of sosend()'s code is not relevant to most protocols so the protocol specific sosend() can be far simpler. Also, by being in protocol-specific code when copying data from application space, one can make more intelligent memory placement decisions (e.g. Jacobson's idea to copy direct from application space to interface memory requires that one know which interface one will send out -- which is a protocol-specific decision). Finally, one can easily roll together checksum and copy because one knows how big a segment one is going to send and which checksum algorithm to use. One other point (perhaps of interest to the POSIX types). When rolling the checksum and copy together on the inbound side, the semantics of recv*() routines have to change slightly, to wit: * EWOULDBLOCK must be a valid return code even after select() indicates there is data to be read. [The data to be read has not yet been checksummed because we don't know what application buffer to put it in until a recv*() call tells us. But on checksumming we may discover the data is bad...] * The entire buffer provided may be modified even if the number of bytes read is smaller than the buffer size. (In UDP it may be the first datagram we tried to copy filled the entire buffer but failed the checksum, so we copied in the following datagram which was smaller but checksummed correctly...] Hope this is useful. Craig Partridge craig@bbn.com Received: by hemlock.cray.com id AA05704; 4.1/CRI-5.5; Fri, 19 Jun 92 10:04:56 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA05700; 4.1/CRI-5.5; Fri, 19 Jun 92 10:04:54 CDT Received: from bach.austin.ibm.com by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AB02184; Fri, 19 Jun 92 10:04:51 CDT Received: by bach.austin.ibm.com (AIX 2.1 2/4.03) id AA22989; Fri, 19 Jun 92 10:00:41 CDT From: swise@bach.austin.ibm.com (Steve Wise) Message-Id: <9206191500.AA22989@bach.austin.ibm.com> To: tcplw@cray.com Cc: posix-net-ptp@ucbvax.Berkeley.EDU Subject: Checksumming on TCP Date: Fri, 19 Jun 92 10:00:40 -0600 Hi! I have been hearing lots of discussion about turning off the TCP checksum over links that provide checksumming (like HiPPI, FCS, ATM, etc). I understand somewhat the arguments pro and con. One argument, which I agree with, is that you should reduce your copies/moves of the data to a minimum. If you're doing more than one copy, you might as well not worry about the checksum time...And, assuming you must move from user space to system memory (or adapter memory), do the checksum during this move. Question: On a BSD 4.3 RENO based system, is this possible? My understanding is that you move it into a mbuf chain in the socket layer. Since there is no guarantee that the exact chain will be shipped as a TCP segment, what good is checksumming this data during the copy into the socketbuff? My guess would be to only move in chunks of TCP segments in at a time, checksum while you move it into the socket layer, then make sure TCP sends exactly that segment using the checksum computed during the move. Since (I believe) the checksum includes parts of the IP and TCP headers, then this move from user space to kernel space would need to be done in tcp_output() instead of sosend()...hmmm Any thoughts, comments? ******** Steve Wise IBM PSP - Austin, TX. Internal: swise@elric.austin.ibm.com VNET: AUSVMQ(SWISE) Internet: swise@bach.austin.ibm.com Received: by hemlock.cray.com id AA04169; 4.1/CRI-5.5; Fri, 5 Jun 92 04:41:02 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA04165; 4.1/CRI-5.5; Fri, 5 Jun 92 04:41:00 CDT Received: from mhs-relay.cs.wisc.edu by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA16453; Fri, 5 Jun 92 04:40:58 CDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 5 Jun 1992 04:40:39 +0000 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Fri, 5 Jun 1992 04:40:26 +0000 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Fri, 5 Jun 1992 04:40:21 +0000 Date: Fri, 5 Jun 1992 04:40:21 +0000 X400-Originator: Olav.Kvittem@delab.sintef.no X400-Recipients: tcplw@cray.com X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;920605114021] X400-Content-Type: P2-1984 (2) Content-Identifier: 3369 From: Olav.Kvittem@delab.sintef.no Message-Id: <3369*/G=Olav/S=Kvittem/OU=delab/O=sintef/PRMD=uninett/C=no/@MHS> To: tcplw@cray.com (Non Receipt Notification Requested) Subject: Implementations of RFC1323 Hello, I am doing a performace study of Supernett, a 34 Mbps inter-city IP-network in Norway, having FDDI access MAN's using NSC and cisco routers. I have discovered that the current 64KB TCP window is to small for filling the network with one session due to larger bandwitdth*delay product. We have DECstations, Suns, a Cray and possibly an Alliant available. Is there interest for testing any of the upcoming trial implementations in such an environment ? Also - if possible I would like to listen in on the discussions by joining the list. Regards Olav Kvittem RFC Address Olav.Kvittem@delab.sintef.no OR Address C=no;ADMD=" ";PRMD=uninett; O=sintef;OU=delab;S=Kvittem;G=Olav Postal Address SINTEF DELAB N-7034 Trondheim Phone +47-7-532586(FAX) Phone +47-7-596981 Description Research Scientist - Group for Communication Networks Received: by hemlock.cray.com id AA13146; 4.1/CRI-5.5; Mon, 18 May 92 10:37:07 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA13141; 4.1/CRI-5.5; Mon, 18 May 92 10:37:05 CDT Received: from Sun.COM ([192.9.9.1]) by timbuk.cray.com (4.1/CRI-MX 1.6ae) id AA20961; Mon, 18 May 92 10:37:03 CDT Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03431; Mon, 18 May 92 08:37:02 PDT Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA07348; Mon, 18 May 92 08:37:00 PDT Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1) id AA04942; Mon, 18 May 92 11:36:59 EDT Received: from nitehawk.East.Sun.COM by spdev.East.Sun.COM (4.1/SMI-4.1) id AA26739; Mon, 18 May 92 11:36:58 EDT Date: Mon, 18 May 92 11:36:58 EDT From: jdf@spdev.East.Sun.COM (Jim Fiori - Special Projects) Message-Id: <9205181536.AA26739@spdev.East.Sun.COM> To: tcplw@cray.com Subject: mailing list Can I be placed in this mailing list please? Thanks Received: by hemlock.cray.com id AA13854; 4.1/CRI-5.5; Fri, 15 May 92 11:30:22 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA13850; 4.1/CRI-5.5; Fri, 15 May 92 11:30:20 CDT Received: from Sun.COM ([192.9.9.1]) by timbuk.cray.com (4.1/CRI-MX 1.6ae) id AA04662; Fri, 15 May 92 11:30:18 CDT Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA23182; Fri, 15 May 92 09:30:17 PDT Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA12251; Fri, 15 May 92 09:30:11 PDT Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1) id AA01642; Fri, 15 May 92 12:30:10 EDT Received: from nitehawk.East.Sun.COM by spdev.East.Sun.COM (4.1/SMI-4.1) id AA20631; Fri, 15 May 92 12:30:08 EDT Date: Fri, 15 May 92 12:30:08 EDT From: jdf@spdev.East.Sun.COM (Jim Fiori - Special Projects) Message-Id: <9205151630.AA20631@spdev.East.Sun.COM> To: tcplw@cray.com Subject: RFC 1323 Has anyone implemented this RFC (TCP Extensions for High Performance) on SunOS 4.1.X? I've started to do so and I'd like to know about problems/results, etc. Any information would be greatly appreciated. Jim Fiori (410) 312-1726 Received: by hemlock.cray.com id AA25298; 4.1/CRI-5.5; Thu, 14 May 92 20:44:28 CDT Received: from timbuk (timbuk.cray.com) by hemlock.cray.com id AA25294; 4.1/CRI-5.5; Thu, 14 May 92 20:44:27 CDT Received: from delirius.cs.uiuc.edu (delirius-exp.cs.uiuc.edu) by timbuk (4.1/CRI-MX 1.6ad) id AA19685; Thu, 14 May 92 20:44:23 CDT Received: from julius.cs.uiuc.edu by delirius.cs.uiuc.edu with SMTP id AA25287 (5.64+/IDA-1.3.4 for tcplw@timbuk.cray.com); Thu, 14 May 92 20:44:11 -0500 Date: Thu, 14 May 92 20:44:11 -0500 From: Thomas Skibo Message-Id: <9205150144.AA25287@delirius.cs.uiuc.edu> To: tcplw@cray.com Subject: Second revision of BSD implementation of RFC 1323 extensions now available. Cc: nesheim@think.com, paul@cso.uiuc.edu, roy@cs.uiuc.edu, rpw3@sgi.com, yhc@concert.net Folks: Now available is the second revision of my 4.3 BSD implementation of the RFC 1323 TCP Extensions. This revision has the following features in addition to the first revision: * No more setsockopt()'s! Window scaling is automatic and based on receive buffer space at connect time. * Correct (more correct?) time-stamps and PAWS. The first revision handled PAWS wrong. * General spiffying up. Also available is a draft tech report about experiences with the extensions. It's an informal paper about the implementation and some experiments done with the extensions. I appreciate any comments on it. The patch is for BSD net release 2 TCP code. A README file briefly describes using the extensions (much easier now that scaling is automatic). The README file, the patch, and the tech report in PostScript are all in a (compressed) shell archive file available anonymous ftp from uxc.cso.uiuc.edu (128.174.5.50). Go to directory /pub, go to binary mode, and get the file "tcplw.shar.Z". Running the shell archive will dump three files into the current working directory: README, tcpx.patch, and tcpx.ps. Hope it's useful. -skibo ------ Thomas Skibo University of Illinois, Dept. of CS. skibo@cs.uiuc.edu ph: 217-333-7937 Received: by hemlock.cray.com id AA24223; 4.1/CRI-5.5; Thu, 14 May 92 18:53:12 CDT Received: from timbuk (timbuk.cray.com) by hemlock.cray.com id AA24219; 4.1/CRI-5.5; Thu, 14 May 92 18:53:11 CDT Received: from venera.isi.edu by timbuk (4.1/CRI-MX 1.6ad) id AA15605; Thu, 14 May 92 18:53:09 CDT Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 14 May 1992 16:53:33 -0700 Date: Thu, 14 May 92 16:52:37 PDT From: braden@ISI.EDU Posted-Date: Thu, 14 May 92 16:52:37 PDT Message-Id: <9205142352.AA13866@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Thu, 14 May 92 16:52:37 PDT To: skibo@cs.uiuc.edu Subject: Re: Does PAWS work for duplicate ACKs in uni-directional connections? Cc: tcplw@cray.com From skibo@cs.uiuc.edu Wed May 13 11:51:34 1992 Date: Wed, 13 May 92 13:51:28 -0500 From: Thomas Skibo To: braden@ISI.EDU Subject: Does PAWS work for duplicate ACKs in uni-directional connections? Cc: tcplw@timbuk.cray.com Bob: The messages about 64-bit sequence numbers reminded me of a point I should have brought up a couple weeks ago when I noticed it. As PAWS is defined in the RFC, a completely uni-directional connection will not have any protection against old duplicate ACKs with wrapped acknowledgement numbers. Since a pure ACK has a zero length, the comparison SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN always fails and so TS.recent is never updated at the sender (the receiver of the acknowledgement). TS.recent stays at the initial time-stamp value received at connection set-up and so ALL acknowledgements pass the PAWS test. Would this test be more appropriate? SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN if SEG.LEN > 0 SEG.SEQ == Last.ACK.sent if SEG.LEN == 0 Am I overlooking something? ------ Thomas Skibo University of Illinois, Dept. of CS. skibo@cs.uiuc.edu ph: 217-333-7937 This is a very interesting point. My first reaction is that the problem you point out is real, but I don't like your fix. Strictly, TS.recent should be updated with the "latest" ACK. This should correspond to the latest window update, as determined by the SND.WL1 and SND.WL2 variables. So this makes me suspect that the TS.recent update is actually in the wrong place, and ought to be in the ACK field processing (p. 72 of RFC-793). Interesting. Bob Braden Received: by hemlock.cray.com id AA00863; 4.1/CRI-5.5; Wed, 13 May 92 14:44:34 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA00859; 4.1/CRI-5.5; Wed, 13 May 92 14:44:32 CDT Received: from md.interlink.com (leo.md.interlink.com) by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA03156; Wed, 13 May 92 14:44:27 CDT Received: by md.interlink.com (4.1/SMI-4.1.2) id AA28589; Wed, 13 May 92 15:40:55 EDT Date: Wed, 13 May 92 15:40:55 EDT From: fab@md.interlink.com (Fred Bohle) Message-Id: <9205131940.AA28589@md.interlink.com> To: cdbrown@somnet.sandia.gov, tcplw@cray.com Subject: Re: TCP Large Window Implem. at Sandia Cc: lgpiers@somnet.sandia.gov I have implemented the same options in our product, SNS/TCPacces. If you would like to test your implementation with mine, please emain me directly. Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@leo.md.interlink.com Interlink Computer Sciences AT&T : 301-317-6600 9145 Guilford Road, Suite 175 Columbia, MD 21046 ------------------------------------------------------------------------ Received: by hemlock.cray.com id AA24106; 4.1/CRI-5.5; Wed, 13 May 92 13:51:35 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA24102; 4.1/CRI-5.5; Wed, 13 May 92 13:51:34 CDT Received: from delirius.cs.uiuc.edu (delirius-exp.cs.uiuc.edu) by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA28809; Wed, 13 May 92 13:51:32 CDT Received: from julius.cs.uiuc.edu by delirius.cs.uiuc.edu with SMTP id AA04214 (5.64+/IDA-1.3.4 for tcplw@timbuk.cray.com); Wed, 13 May 92 13:51:28 -0500 Date: Wed, 13 May 92 13:51:28 -0500 From: Thomas Skibo Message-Id: <9205131851.AA04214@delirius.cs.uiuc.edu> To: braden@isi.edu Subject: Does PAWS work for duplicate ACKs in uni-directional connections? Cc: tcplw@cray.com Bob: The messages about 64-bit sequence numbers reminded me of a point I should have brought up a couple weeks ago when I noticed it. As PAWS is defined in the RFC, a completely uni-directional connection will not have any protection against old duplicate ACKs with wrapped acknowledgement numbers. Since a pure ACK has a zero length, the comparison SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN always fails and so TS.recent is never updated at the sender (the receiver of the acknowledgement). TS.recent stays at the initial time-stamp value received at connection set-up and so ALL acknowledgements pass the PAWS test. Would this test be more appropriate? SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN if SEG.LEN > 0 SEG.SEQ == Last.ACK.sent if SEG.LEN == 0 Am I overlooking something? ------ Thomas Skibo University of Illinois, Dept. of CS. skibo@cs.uiuc.edu ph: 217-333-7937 Received: by hemlock.cray.com id AA23347; 4.1/CRI-5.5; Wed, 13 May 92 13:25:29 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA23343; 4.1/CRI-5.5; Wed, 13 May 92 13:25:28 CDT Received: from delirius.cs.uiuc.edu (delirius-exp.cs.uiuc.edu) by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA26901; Wed, 13 May 92 13:25:25 CDT Received: from julius.cs.uiuc.edu by delirius.cs.uiuc.edu with SMTP id AA04034 (5.64+/IDA-1.3.4 for tcplw@timbuk.cray.com); Wed, 13 May 92 13:25:19 -0500 Date: Wed, 13 May 92 13:25:19 -0500 From: Thomas Skibo Message-Id: <9205131825.AA04034@delirius.cs.uiuc.edu> To: cdbrown@somnet.sandia.gov Subject: Re: TCP Large Window Implem. at Sandia Cc: tcplw@cray.com > There are a couple of differences between my implementation and the code > that I've looked at for Cray and Univ of Illinois (after I'd already done > the SunOS code), and I'd appreciate your comments. > 1. I calculated the shift count proposed by each end from the TCP receive > buffer size. It seems to me that this is the best way for each node to > ensure that the window will fit into 16 bits. I noticed that the other > two implementations I studied added a new TCP option for the user to > call to establish a shift count, and I can't see the reason for this > other than to let the user play around with the parameter for research > purposes. Otherwise, I'd rather keep the changes to the application > code to a minimum. Yes. This is MUCH better. My latest revision no longer uses setsockopt()'s to control window scaling. The setsockopt() was gross and the latest RFC states something to the effect that the application interface shouldn't change. > 2. The above design decision revealed what I consider to be a design flaw > in TCP (probably generic Berkeley code and not just SunOS). The client > side worked fine, but the server couldn't get the expanded receive buffer > side before the connection was accepted; hence, it couldn't calculate the > correct shift count. If I did the 'setsockopt' for the RCVBUF after the > 'accept', the connection was established before the large buffer size > was set. If I did the 'setsockopt' on the 'master' socket before the > accept, it didn't propogate to the new socket created by the 'accept'. > I solved the problem by adding code to 'tcp_attach' to get the buffer > sizes from the 'parent' socket using the 'so_head' pointer (if it was > valid) and calling 'sbreserve' with those buffer sizes. It would have > been possible to copy buffer sizes in the socket routines, but I was > trying to limit mods to the TCP routines. Anybody else run into this > problem?: The socket buffer sizes DO propagate to the new socket. It's done in sonewconn() in uipc_socket2.c. What I'm doing now is calculating the scaling value from the buffer sizes when a PRU_CONNECT or PRU_LISTEN is done on a TCP socket. So, in the case of a listen socket, you do the setsockopt( SO_RCVBUF ) call before you make the listen() call. When a listening TCP accepts a connection, the created connection gets the same socket buffer space as the listen socket. My implementation has the created TCP connection "inherit" the scaling value from the listen TCP. A better way might be to have the window scaling computed from the socket buffer space at the time that a listening TCP accepts a connection. One problem with my method is that if you changed the buffer space of a socket already listening, the scaling value of subsequent connections would be incorrect. I'd change it but the current implementation is thoroughly tested and I'm desperately trying to finish finals and document all this stuff before I run off and join the ranks of the gainfully employed. My latest revision of the extensions has the above change as well as significant changes to time-stamps (I was doing a few things wrong). I'll be making them available by the end of the week. I've also got a tech report in the works and it should be available by Monday. ------ Thomas Skibo University of Illinois, Dept. of CS. skibo@cs.uiuc.edu ph: 217-333-7937 Received: by hemlock.cray.com id AA21409; 4.1/CRI-5.5; Wed, 13 May 92 12:31:12 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA21405; 4.1/CRI-5.5; Wed, 13 May 92 12:31:10 CDT Received: from somnet.Sandia.GOV by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA22718; Wed, 13 May 92 12:31:01 CDT Received: by somnet.Sandia.GOV (5.59/SNLA-3.2.1) id AA11648; Wed, 13 May 92 11:28:25 MDT Date: Wed, 13 May 92 11:28:25 MDT From: cdbrown@somnet.sandia.gov (Nov-C. Douglas Brown) Message-Id: <9205131728.AA11648@somnet.Sandia.GOV> To: tcplw@cray.com Subject: TCP Large Window Implem. at Sandia Cc: lgpiers@somnet.sandia.gov I've just joined the 'tcplw' mailing list and wanted to discuss my implementation of TCP large windows at Sandia National Labs with the rest of the group. I've modified TCP on SunOS 4.1.1 to do the window scaling and have tested it successfully against our Cray. Have designed the mods to do the RTT according to RFC1072, but will redesign to implement the latest recommendations in the current draft that I got yesterday. We don't necessarily need SACK, as our studies show it to be useful only in a narrow range of error rate, and our long-haul links have been good enough that retransmissions due to errors shouldn't be a problem. There are a couple of differences between my implementation and the code that I've looked at for Cray and Univ of Illinois (after I'd already done the SunOS code), and I'd appreciate your comments. 1. I calculated the shift count proposed by each end from the TCP receive buffer size. It seems to me that this is the best way for each node to ensure that the window will fit into 16 bits. I noticed that the other two implementations I studied added a new TCP option for the user to call to establish a shift count, and I can't see the reason for this other than to let the user play around with the parameter for research purposes. Otherwise, I'd rather keep the changes to the application code to a minimum. 2. The above design decision revealed what I consider to be a design flaw in TCP (probably generic Berkeley code and not just SunOS). The client side worked fine, but the server couldn't get the expanded receive buffer side before the connection was accepted; hence, it couldn't calculate the correct shift count. If I did the 'setsockopt' for the RCVBUF after the 'accept', the connection was established before the large buffer size was set. If I did the 'setsockopt' on the 'master' socket before the accept, it didn't propogate to the new socket created by the 'accept'. I solved the problem by adding code to 'tcp_attach' to get the buffer sizes from the 'parent' socket using the 'so_head' pointer (if it was valid) and calling 'sbreserve' with those buffer sizes. It would have been possible to copy buffer sizes in the socket routines, but I was trying to limit mods to the TCP routines. Anybody else run into this problem?: Received: by hemlock.cray.com id AA03236; 4.1/CRI-5.5; Fri, 10 Apr 92 14:54:53 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA03232; 4.1/CRI-5.5; Fri, 10 Apr 92 14:54:51 CDT Received: from optima.cs.arizona.edu by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA05908; Fri, 10 Apr 92 14:54:48 CDT Date: Fri, 10 Apr 92 12:54:45 MST From: "Sean O'Malley" Message-Id: <9204101954.AA23045@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (4.1/15) id AA23045; Fri, 10 Apr 92 12:54:45 MST To: tcplw@cray.com Subject: apology to Bob Of course Bob is correct and any posting of his TWA paper to this group should have come from through him. Please disregard my posting. Sean W. O'Malley Received: by hemlock.cray.com id AA01425; 4.1/CRI-5.5; Fri, 10 Apr 92 14:21:38 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA01421; 4.1/CRI-5.5; Fri, 10 Apr 92 14:21:36 CDT Received: from venera.isi.edu by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA03850; Fri, 10 Apr 92 14:21:31 CDT Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-4) id ; Fri, 10 Apr 1992 12:21:53 -0700 Date: Fri, 10 Apr 92 12:21:20 PDT From: braden@ISI.EDU Posted-Date: Fri, 10 Apr 92 12:21:20 PDT Message-Id: <9204101921.AA02365@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Fri, 10 Apr 92 12:21:20 PDT To: sean@cs.arizona.edu, tcplw@cray.com Subject: Re: Bradens PAWS bug From tcplw-relay@timbuk.cray.com Fri Apr 10 09:35:14 1992 Date: Fri, 10 Apr 92 09:33:39 MST From: "Sean O'Malley" To: tcplw@timbuk.cray.com Subject: Bradens PAWS bug Bob Braden put out a document to the endtoend interest group outline a set of problems with the PAWS mechanism. The question is does this group want to reopen the PAWS discussion? Sean, This is an inaccurate characterization of my message. My note is NOT about a bug in PAWS; mmy tests indicate that PAWS works just fine. My note might be described as a bug in the current TCP, but I would not use such a term, for fear of what Communication Weekly would do with it! PAWS still does exactly what it was designed to do: prevent TCP errors caused by high bandwidths. PAWS has the bonus that it fixes the most serious of the TWA hazards, erroneous data delivery. PAWS cannot prevent unnecessary (but probably extremely rare) connection failures due to TWA. There is a real question whether the TWA hazards are more than a highly theoretical exercise. I do not think the research on this is complete (which is why I did not send it to the tcplw list). I pointed out in my note that I believe that 64-bit sequence numbers will solve the TWA hazards. I also believe that instituting 64-bit sequence numbers is a subtle issue, that needs to be approached with some care and understanding. In short, it is a useful avenue for research at this time. Sean, you will find the Internet community downright hostile, if you do not show the normal courtesies due to fellow researchers -- like checking with someone before forwarding his paper to a mailing list, especially with misleading implications. Bob Braden Received: by hemlock.cray.com id AA24630; 4.1/CRI-5.5; Fri, 10 Apr 92 11:34:21 CDT Received: from timbuk.cray.com by hemlock.cray.com id AA24626; 4.1/CRI-5.5; Fri, 10 Apr 92 11:34:19 CDT Received: from optima.cs.arizona.edu by timbuk.cray.com (4.1/CRI-MX 1.6ad) id AA23233; Fri, 10 Apr 92 11:34:12 CDT Date: Fri, 10 Apr 92 09:33:39 MST From: "Sean O'Malley" Message-Id: <9204101633.AA12573@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (4.1/15) id AA12573; Fri, 10 Apr 92 09:33:39 MST To: tcplw@cray.com Subject: Bradens PAWS bug Bob Braden put out a document to the endtoend interest group outline a set of problems with the PAWS mechanism. The question is does this group want to reopen the PAWS discussion? Bob's Document follows: April 2, 1992 TIME-WAIT ASSASSINATION HAZARDS FOR TCP Bob Braden, USC-ISI Experiments to validate the proposed TCP extensions led me to investigate an interesting class of TCP failures that I call the "Time-Wait Assassination" (TWA) hazards. I believe that these hazards exist in current TCP at current rates, although they may be more likely on "fast" network paths, those with bandwidth >> 2Mbps. This note describes the hazards, gives examples, and discusses possible prevention measures. In particular, it considers the impact of Jacobson's time-stamp based PAWS ("Protect Against Wrapped Sequences") mechanism, which is one of the proposed TCP extensions. 1. Time-Wait Assassination TCP uses sequence numbers to protect against old duplicate segments from the current incarnation of a given connection (defined by a particular host and port pair). If the bandwidth is very high, the PAWS mechanism of RFC-1185 will effectively extend the sequence numbers so wrap-around will not be a hazard. Time-Wait state removes the hazard due to old duplicate segments from an earlier instance of the same connection [See e.g. Appendix to RFC-1185]. Time-Wait state prevents reopening the same TCP connection for 4 minutes, which is assumed to be time enough for all old duplicates to die in the Internet. We now observe that Time-Wait state can be killed ("assassinated") by an old duplicate segment, either data or ACK, from the current or an earlier incarnation of the same connection. Figure 1 shows an example. In Figure 1, segments 1-5 are copied exactly from Figure 13 of RFC-793, showing a normal close handshake. Packets 5.1, 5.2, and 5.3 are an extension to this sequence, illustrating TWA. Here 5.1 is ANY OLD SEGMENT that is unacceptable to TCP A. It might be unacceptable because of its sequence number or because of an old PAWS timestamp. In either case, TCP A sends an ACK segment 5.2 for its current SND.NXT and RCV.NXT. Since it has no state for this connection, TCP B reflects this as RST segment 5.3, which assassinates the TIME-WAIT state at A! Note that TWA is not at all an unlikely event, if there are any duplicate segments that may be delayed in the network. Furthermore, TWA cannot be prevented by PAWS timestamps; the event may happen within the same tick of the timestamp clock. TWA is a consequence of TCP's half-open connection discovery mechanism (see pp 33-34 of RFC-793) to clean up after a system crash. TCP A TCP B 1. ESTABLISHED ESTABLISHED 2. (Close) FIN-WAIT-1 --> --> CLOSE-WAIT 3. FIN-WAIT-2 <-- <-- CLOSE-WAIT 4. (Close) TIME-WAIT <-- <-- LAST-ACK 5. TIME-WAIT --> --> CLOSED - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5.1. TIME-WAIT <-- ... old duplicate 5.2 TIME-WAIT --> --> ???? 5.3 CLOSED <-- <-- ???? - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6. (2 MSL) CLOSED Figure 1. TWA Example 2. The TWA Hazards If the connection is immediately reopened after a TWA event, the new incarnation will be exposed to old duplicate non-SYN segments (the 3-way handshake handles SYN-segment hazards). Clock-driven ISN selection guards against old duplicates for "short and slow" connections [see eg the appendix to RFC-1185] [The algorithm used by BSD for stepping ISN complicates the analysis slightly, but does not change the conclusions]. However, clock-driven ISN selection does not guard against old duplicates for "fast" or "long" connections; in either case, the sequence space of the old connection incarnation may overlap the sequence space of the new incarnation. Each of the following possible hazards depend upon overlap of sequence space from the previous incarnation. H1. Old duplicate data may be accepted erroneously. H2. The new connection may die. A duplicate segment (data or ACK) arriving in SYN-SENT state may kill the new connection after it has apparently opened successfully. H3. The new connection may be de-synchronized, with the two ends in permanent disagreement on the state. Following the spec of RFC-793, this will result in an infinite ACK loop (!); it might be reasonable to change this aspect of RFC-793 and kill the connection instead. This hazard results from ACKing somethat that was not sent. This may result from an old duplicate ACK or as a side-effect of hazard H1. Example scenarios for these hazards are given later. Note that each of these requires the coincidence of the old duplicate falling into a particular range of sequence numbers. Thus, they are not as likely as TWA itself. I have demonstrated TWA and the three hazards H1, H2, and H3, using stock Sun OS 4.1.1 TCP running in an simulated environment that deliberately duplicates segments. This environment is far more hazardous than most real TCP's must cope with. However, the demonstration gives us confidence in the existence of the hazards. 3. Fixes for TWA Hazards We discuss two possible fixes to the current TCP, to avoid these hazards. (F1) Ignore RST segments in Time-Wait state. This is the simplest fix, and if the 2 minute MSL (Maximum Segment Lifetime) of TCP is enforced, it avoids all three hazards. One could also argue that this is formally the correct thing to do; since one of Time-Wait state's functions is to allow any old duplicate segments to die, it should not be interrupted by a RST. After a system crash, the Quiet Time at system startup will replace the Time-Wait delay. On the other hand, this fix leaves me a bit uneasy about robustness. The RST mechanism is designed to bring both sides into agreement, and turning it off in Time-Wait state could make it more difficult to recover from some pathological situations. (F2) Use PAWS to avoid the hazards. Mechanism: ignore RST segments in Time-Wait state, but only long enough to guarantee that the timestamp clocks on both ends have ticked. Then PAWS will prevent old duplicate data segments from interfering with new incarnation. For reasons explained below, it may not eliminate all old duplicate ACK segments, so hazards H2 and H3 still exist. In the language of the forthcoming TCP Extensions RFC: When processing a RST bit in TIME-WAIT state: If (Snd.TS.OK is off) or (Time.in.TW.state() >= Q) then enter the CLOSED state, delete the TCB, drop the RST segment, and return. else simply drop the RST segment and return. Here "Time.in.TW.state()" is a function returning the elapsed time since Time-Wait state was entered, and Q is a constant that is at least twice the longest possible period for timestamp clocks. The TCP Extension RFC requires a period in the range of 1 sec - 1 ms. Thus, we could choose Q = 2 seconds. This assumes that the timestamp clock at each end continues to advance at a constant rate, whether or not there are any open connections. We do not have to consider what happens across a system crash (e.g., the timestamp clock may jump randomly), because of the assumed Quiet Time at system startup. Once this change is in place, the initial timestamps that occur on the SYN and {SYN,ACK} segment reopening the connection will be larger than any timestamp on a segment from earlier incarnations. As a result, the PAWS mechanism operating in the new connection incarnation will avoid the H1 hazard, ie. acceptance of old duplicate data. I have demonstrated the effectiveness of F2 in preventing acceptance of old duplicate data segments in the Sun OS TCP mentioned earlier. Unfortunately, these tests also revealed a somewhat surprising fact: old duplicate ACKs from the earlier incarnation can still slip past PAWS, so that F2 will not prevent failures H2 or H3. What happens is that Time-Wait state effectively regenerates the timestamp of an old duplicate ACK. That is, when an old duplicate arrives in Time-Wait state, an extended TCP will send out its own ACK with a timestamp option containing its CURRENT timestamp clock value. If this happens immediately before the TWA mechanism kills Time-Wait state, the result will be a "new old duplicate" segment with a current timestamp, which may be able to pass the PAWS test on the reopened connection. We can modify F2 to accomodate the second function of TIME-WAIT state, supporting the bi-directional reliable close of TCP. We would do so by replacing Q by max(Q, N*RTT), where N is chosen constant and RTT is the measured round-trip time. We choose N large enough so that there is sufficient probability of the close completing successfully if at all possible, and assume that the RTT is appproximately the same in both directions. It only possible to have many short connections if RTT is very small, in which case the mimimum TIME-WAIT time reduces to Q. Shortening TIME-WAIT state as in F2 is very attractive, since it helps the problem of excessive resources tied up by many short connections. Unfortunately, it does not prevent H2 or H3. Only F1 will do that. Whether H2 and H3 are critical depends upon how often they happen, and what assumptions applications make about TCP semantics. In fact, many production TCPs have (despite the advice of the researchers who developed TCP) incorporated keep-alives which tended to often kill connections unnecessarily. The frequency of occurrence of H2 and H3 may well be much lower than keep-alive failures or total communication failures. 4. A More Radical Solution O'Malley and Peterson have suggested that simply expanding the TCP sequence space to 64 bits would be simpler than PAWS for preventing wrapped sequence numbers. We should consider the impact on the TWA hazards of using 64-bit sequence numbers. The 64 bit space is so large that sequence numbers need "never" be reused. If a connection ran at a terabyte per second, the sequence space would take over 200 years to wrap its sign bit. If we assume no connection lasts that long, there will be no "long" connections. We can also increase the frequency of the timer-driven ISN selection to e.g. incrementing the low order bit every nanosecond. Then all connections will "short" and "slow" in the sense of the Appendix to RFC-1185, and the timer-driven ISN selection will prevent any overlap of sequence numbers in successive connections. 64 bit sequence numbers will not prevent TWA itself - the early termination of Time-Wait state due to an old duplicate from the SAME incarnation. However, 64 bit sequence numbers WILL prevent the accompanying hazards H1, H2, and H3, since these hazards all depend upon sequence number reuse across connection incarnations. Furthermore, 64 bits sequences plus a limited connection lifetime (200 years) will obviate the need to Time-Wait state to let old duplicates die. Then Time-Wait state will be required only to support reliable close; therefore, Time-Wait state timeout can be set to N*RTT, allowing many short connections (i.e., "transactions") when RTT is small. Thus, I concur with O'Malley and Peterson that expansion to 64 bit sequence space is an attractive fix, at least from the viewpoint of the ideal world of research. It amounts to rescaling the problem out of existence. It is probably not a temporary fix, as it will extend reliable TCP operation to speeds which are many orders of magnitude beyond the likely upper limit of usefulness of a window-based protocol. _______________________________________________________________________ _______________________________________________________________________ Appendix SCENARIOS: Each of the following scenarios assumes that a TWA event has occurred and that the connection has been reopened soon thereafter. HAZARD H1: Acceptance of erroneous old duplicate data. TCP A TCP B 1. ESTABL. --> --> ESTABL. 2. ESTABL. <-- <-- ESTABL. 3. (old dupl)... --> ESTABL. 4. ESTABL. <-- <-- ESTABL. 5. ESTABL. --> --> ESTABL. 6. ... <-- ESTABL. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7a. ESTABL. --> --> ESTABL. 8a. ESTABL. <-- ... 9a. ESTABL. --> --> ESTABL. Figure 2: Accepting Erroneous Data Old duplicate data segment 3 falls within the current receive window and is queued. It "lurks" in the TCP reassembly queue until segment 5 overlaps it. At that point, either 80 or 40 bytes of erroneous data is delivered to the user B; the choice depends upon the particulars of the reassembly algorithm, which may accept the first or the last duplicate data. As a result, B sends segment 6, an ACK for something that A did not send. Assume for the present that this ACK arrives at A *after* A has sent segment 7a, the next full data segment. In that case, the ACK segment 8a acknowledges data that has been sent, and the error goes undetected. Another possible continuation after segment 6 leads to hazard H3, as shown below. ________________________________________________________________________ HAZARD H2: Connection Failure TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> --> SYN-RECEIVED 3. ... <-- SYN-RECEIVED 4. SYN-SENT <-- ... (old duplicate) 5. SYN-SENT --> --> LISTEN 6. ESTABLISHED <-- ... 7. ESTABLISHED --> --> LISTEN 8. CLOSED <-- <-- LISTEN Figure 3: Connection Failure from Old Duplicate TCP A sees an apparent refusal of its connection attempt, due to the old duplicate ACK segment #4. The key to this failure is that the RST segment 5 is acceptable to TCP B in SYN-RECEIVED state. This is only possible when the sequence space of the earlier connection that produced this old duplicate overlaps the new connection space; e.g., in segment #5 falls within TCP B's receive window [100,900). Note that PAWS cannot prevent this failure mode. The PAWS procedure does not maintain the remote timestamp between connections, so it cannot do a timestamp check on a segment received in SYN-SENT state. Even if it did a timestamp check, the timestamp might be current because of the regeneration feature of Time-Wait state, and even if it failed, the result would probably be just to send the same RST segment It was quite easy to demonstrate this failure mode. ___________________________________________________________________ ___________________________________________________________________ HAZARD H3: De-synchronized Connection As mentioned earlier, this can happen either as a side effect of H1 or directly from an old duplicate ACK that happens to be exactly acceptable but ACKs something that has not been sent. Referring to Figure 2 above, suppose that the ACK generated by the old duplicate data segment arrived before the next data segment had been sent. The result is an infinite ACK loop, as shown by the following alternate continuation of Figure 2. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7b. ESTABL. <-- ... (ACK something not yet sent => send ACK) 8b. ESTABL. --> --> ESTABL. (Below window => send ACK) 9b. ESTABL. <-- <-- ESTABL. (etc.!) Figure 4: Infinite ACK loop ___________________________________________________________________ Received: by hemlock.cray.com id AA01023; 4.1/CRI-5.5; Wed, 25 Mar 92 11:35:26 CST Received: from timbuk (timbuk.cray.com) by hemlock.cray.com id AA01019; 4.1/CRI-5.5; Wed, 25 Mar 92 11:35:25 CST Received: from optima.cs.arizona.edu by timbuk (4.1/CRI-MX 1.6ac) id AA12296; Wed, 25 Mar 92 11:35:06 CST Date: Wed, 25 Mar 92 10:34:36 MST From: "Sean O'Malley" Message-Id: <9203251734.AA07033@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (4.1/15) id AA07033; Wed, 25 Mar 92 10:34:36 MST To: end2end-interest@isi.edu, tcplw@cray.com Subject: More TCMP Motivation Perhaps I should give some more motivation. I have been writing a paper on backward compatible extensions to communications protocols. The basic idea being that everyone seems to think backward compatibility is a good idea but no two people have the same definition of what backward compatibility is. In examining the proposed TCP extensions my conclusion was that absolute preservation of the current TCP packet format and length was required. The reason for this is that there seems to be (or at least everyone worries about) software and hardware other than TCP which contain TCP header dependencies. What someone needs to do is define exactly what are the important features of the TCP header that must be preserved and specify WHY the must be preserved. A good start would be to determine exactly what assumptions are being made about the TCP header by hardware and software other than TCP. 1) does the TCP header length matter 2) does the TCP format matter 3) if the format matters does the content of the fields matter 4) if so which fields. Without this information it is hard to have a meaningful discussion of different approaches to backward compatibility. With this in mind: Rob Warnock states: > No new IP protocol number is needed. I think an IP protocol number is required even if we use the reserve bits for a packet type field. Each TCP protocol would claim to be two IP protocol numbers (this is easy to do in the x-kernel) and send all new packet types using the alternate IP protocol number. The reason for this is that no will be peeking into headers sent using the new protocol ID. Now this might create problems if the software or hardware doing the peeking does something useful (as apposed to simply making it difficult to change TCP). Wether TCMP is a real protocol or just another IP protocol number for TCP is not relevant. If we can get away with changing the header format that would be wonderful. (and that was one of my original proposals) However if we can't change the header format then we have to lower our expectations... Jon Crowcroft states: > this has one major failing - you have lost the fact that the SACK > information was carried with the ACK clock information because the > TCMP packet is separate (worse, it be carried through the net on a > different path at different priority...) This leads me to believe that I do not understand the SACK option. In my view the SACK option simply a very round about way to suggest to the sender that it might be a good idea to retransmit a frame or frame(s). In my proposal the SACK option is not piggy backed with an real TCP ACK. If you want to ACK you can send another packet. As such all that really seems to matter is that the sender be able to identify the session and weed out old SACK's. Hence the SACK field probably should contain timestamps. However when the SACK actually arrives is irrelevant. If the sender has already done something about those frames no problem. The SACK should not be used to compute RRTs it is just a hint. It might help here if someone would explain how an advisory SACK differs from a NACK? Sean O'Malley ps. sorry about the duplicate posting I forgot about the tcplw mail alias. Received: by hemlock.cray.com id AA14679; 4.1/CRI-5.5; Wed, 25 Mar 92 03:30:30 CST Received: from timbuk.cray.com by hemlock.cray.com id AA14675; 4.1/CRI-5.5; Wed, 25 Mar 92 03:30:27 CST Received: from sgi.sgi.com (SGI.COM) by timbuk.cray.com (4.1/CRI-MX 1.6ac) id AA16914; Wed, 25 Mar 92 03:30:24 CST Received: from [192.26.75.58] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for tcplw@cray.com id AA07594; Wed, 25 Mar 92 01:30:22 -0800 Received: by rigden.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:tcplw@cray.com id AA12315; Wed, 25 Mar 92 09:30:20 GMT Date: Wed, 25 Mar 92 09:30:20 GMT From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9203250930.AA12315@rigden.wpd.sgi.com> To: tcplw@cray.com Subject: Re: SACK vs. TCMP (*blush*) Please excuse the junk at the end of my recent submission to the TCPLW list. A slip o' the keyboard failed to delete it... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)335-1673 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 Received: by hemlock.cray.com id AA13633; 4.1/CRI-5.5; Wed, 25 Mar 92 01:13:55 CST Received: from timbuk.cray.com by hemlock.cray.com id AA13629; 4.1/CRI-5.5; Wed, 25 Mar 92 01:13:52 CST Received: from sgi.sgi.com (SGI.COM) by timbuk.cray.com (4.1/CRI-MX 1.6ac) id AA00634; Wed, 25 Mar 92 01:13:38 CST Received: from [192.26.75.58] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for tcplw@cray.com id AA01557; Tue, 24 Mar 92 23:13:25 -0800 Received: by rigden.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:sean@cs.arizona.edu id AA11961; Wed, 25 Mar 92 07:13:23 GMT Date: Wed, 25 Mar 92 07:13:23 GMT From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9203250713.AA11961@rigden.wpd.sgi.com> To: sean@cs.arizona.edu Subject: Re: SACK vs. TCMP Cc: tcplw@cray.com Sean, Your proposal for a "TCMP" is interesting. It reminds me strongly of several historical parallels/precedents in other protocols. On the one hand, your suggestion of a separate IP protocol number parallels IP & ICMP (as you obviously intended). But there are other approaches: Xerox NS (XNS) provides a "datastream type" at the transport packet level which can be used for such "large" control messages. Mostly, they're just used for the "suggested" (i.e., standard) close handshake, with types 255, 254, etc., but many other values are available for use by transport clients in "out-of-band" signalling. XTP provides more explicitly defined "packet types", of which the most commonly used are "DATA" and "CONTROL". (There is also a "FIRST", which is just a DATA packet prefixed by an "address segment".) CONTROL packets are where XTP puts its SACK-equivalent "span" lists, and also other flow-control information that is not carried in every DATA packet. For example, opening the window ("alloc") requires a CONTROL packet back from the receiver to the sender, since DATA packets don't have have a field in them for "alloc". So given the XNS & XTP examples, it feels like what you are really talking about -- despite the suggestive name "TCMP" -- is *not* so much an "ICMP-like" thing for doing fatal error handling, echo tests, and other miscellany, but a full-fledged "control" packet type -- larger and more extensible than what we can cram in the TCP options. And that feels to me like something that belongs within TCP, not in a bolt-on-the-side parallel protocol. Well, go ahead, why not bite the bullet? I'll say it, if no one else will... Maybe it's finally time to allocate another one (or two?) of the six remaining "reserved" flag bits in the TCP header, said field to be called "Packet Type". [A extremely conservative approach would allocate but one bit, and call it simply "Control".] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |PKT|U|A|P|R|S|F| | | Offset| Rsvd |TYP|R|C|S|S|Y|I| Window | | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value "0" (or "00" or whatever) to mean "DATA" -- that is, the same old TCP byte datastream we know and love(?). Value "1" (or "01") would be "CONTROL", and would contain something very much like your "TCMP" packet (or an XTP CONTROL packet) and contain (at least) large window update information and SACKs. And we define one more new TCP option that says "yes, I know how to process packet types other than DATA" that each end must receive before sending CONTROL (or other non-DATA) packet types to the other. With the "I understand non-DATA" option, *all* the extended window stuff gets swept from the TCP Options into the CONTROL packet. Without succesfully exchanging this option, the formerly-"reserved" bit(s) stay zero, and "old" TCP proceeds as always. No new IP protocol number is needed. Comments? -Rob p.s. It's going to take *something* more or less like a CONTROL packet to add multicast to TCP (which I'd like to do one of these days)... ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)335-1673 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 To: postmaster@isi.edu Subject: is end2end-interest list dead/moved? Dear Postmaster@ISI.edu: I sent the following to , and it bounced. Has this list moved or been renamed? -Rob +------ attachment --------- | From MAILER-DAEMON@sgi.sgi.com Wed Mar 25 07:06:49 1992 | Received: from whizzer.wpd.sgi.com by rigden.wpd.sgi.com via SMTP (911016.SGI/911001.SGI) | for rpw3 id AA11922; Wed, 25 Mar 92 07:06:49 GMT | Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (911016.SGI/911001.SGI) | for rpw3@rigden.wpd.sgi.com id AA09050; Tue, 24 Mar 92 23:06:45 -0800 | Received: by sgi.sgi.com (911016.SGI/910110.SGI) | for rpw3@rigden.wpd.sgi.com id AA01361; Tue, 24 Mar 92 23:06:31 -0800 | Date: Tue, 24 Mar 92 23:06:31 -0800 | From: MAILER-DAEMON@sgi.sgi.com (Mail Delivery Subsystem) | Subject: Returned mail: Service unavailable | Message-Id: <9203250706.AA01361@sgi.sgi.com> | To: rpw3 | Status: R | | ----- Transcript of session follows ----- | While talking to isi.edu: | >>> RCPT To: | <<< 554 :include:/div7/iab/end2end-interest.list... Cannot open /div7/iab/end2end-interest.list: No such file or directory | 554 <@sgi.sgi.com:end2end-interest@isi.edu>... Service unavailable | | ----- Unsent message follows ----- | Received: from [192.26.75.58] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) | for end2end-interest@isi.edu id AA01360; Tue, 24 Mar 92 23:06:31 -0800 | Received: by rigden.wpd.sgi.com (911016.SGI/911001.SGI) | for @sgi.sgi.com:sean@cs.arizona.edu id AA11917; Wed, 25 Mar 92 07:06:29 GMT | Date: Wed, 25 Mar 92 07:06:29 GMT | From: rpw3@rigden.wpd.sgi.com (Rob Warnock) | Message-Id: <9203250706.AA11917@rigden.wpd.sgi.com> | To: sean@cs.arizona.edu | Subject: SACK vs. TCMP | Cc: end2end-interest@isi.edu | | Sean, | | Your proposal for a "TCMP" is interesting. It reminds me strongly of several | historical parallels/precedents in other protocols. On the one hand, your | ...remainder deleted... +--------------- ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)335-1673 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 Received: by hemlock.cray.com id AA11251; 4.1/CRI-5.5; Tue, 24 Mar 92 22:04:22 CST Received: from timbuk.cray.com by hemlock.cray.com id AA11247; 4.1/CRI-5.5; Tue, 24 Mar 92 22:04:20 CST Received: from optima.cs.arizona.edu by timbuk.cray.com (4.1/CRI-MX 1.6ac) id AA26509; Tue, 24 Mar 92 22:04:15 CST Date: Tue, 24 Mar 92 21:04:13 MST From: "Sean O'Malley" Message-Id: <9203250404.AA05590@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (4.1/15) id AA05590; Tue, 24 Mar 92 21:04:13 MST To: tcplw@cray.com Subject: SACK vs. TCMP The TCP Control Message Protocol (TCMP) Short Summary of SACK Option to Date The TCP SACK (selective acknowledgment) option was added to TCP in order to reduce the amount of retransmissions required on networks with large bandwidth-delay products. The SACK option allows the receiver to selectively acknowledge frames in its window. The sender uses the information contained in the SACK option to select frames for retransmission. The SACK is strictly advisory in that the sender cannot discard frames that have been SACK'ed. Because of the small amount of room available for TCP extensions the original proposal used 16 bit offset and length fields and scaled those fields using the same value used to scale the window size field. This resulting in a total of 6 frames. The SACK option was then modified to use 32 bit fields in order to simplify the algorithm and eliminate the interaction between the SACK and window scale options. Which reduced the maximum number of frames to 3. Since then evidence has been given by Van Jacobson that at least 6 frames must be included in each packet for any significant improvement and the SACK option is currently being redesigned. Option Field is a Scarce Resource Both of the proposed SACK options share the same problem. In the worst case they consume the entire remaining room in the TCP option field. This makes any subsequent backward compatible extension to TCP difficult if not impossible. Any subsequent TCP modification that requires a TCP option which appears in every TCP header (like the timestamp option) will compete with the SACK option for space. I believe that we must treat the option field as a scarce resource and preserve some of for future use. The question then becomes is the TCP option field the right place to put the SACK? I think the answer is no. TCMP A more realistic proposal would be to take advantage of the fact that selective ACKs are purely advisor and treat the SACK as a control message similar in formate to the messages used by ICMP to manage IP. The simplest solution would be to give the modified TCP protocol an additional IP protocol number to use when transmitting a TCMP messages. The format of a possible TCMP SACK message is given below: struct { long type; long length; long checksum; short src,dest; long seq,ack; long count; struct { long offset,length; } frame[0]; } Since TCMP messages are limited only by the IP MTU there is no need to save space. The packet contains standard TCMP preamble: a type field which identifies which TCMP message type this and length field which gives the length of the packet in 32 bit words. The body of the packet consists of the data that would have been sent using the SACK option. The source and destination ports are needed to identify the correct connection. The remaining information can be used to identify the fragments for retransmission. One may want to include the timestamp field. This is by no means the only approach to SACK. I believe that NACK'ing holes rather than SACK'ing frames would be preferable. The TCMP message formate could also be made to more closely resemble the TCP header to permit the unmodified TCP code to find the correct session. Performance would either be superior or unaffected by this proposal. TCMP can be used to handle asynchronous and unreliable communications between TCP peers. More importantly TCMP permits changes to TCP without changing the existing TCP header. The option field in the TCP header can be reserved for modifications which require reliable agreement (as the TCP window scale option does) or per-packet information (as the TCP timestamp option does). Other uses of TCMP are also possible. For example the receiver could use TCMP to inform the sender of the maximum packet size recieved. The sender could use this information to set its frame size to avoid addition IP fragmentation. TCMP permits very large SACKs and does not require any scaling of the fields. Sean W. O'Malley Received: by hemlock.cray.com id AA13691; 4.1/CRI-5.5; Sun, 8 Mar 92 22:04:47 CST Received: from timbuk.cray.com by hemlock.cray.com id AA13687; 4.1/CRI-5.5; Sun, 8 Mar 92 22:04:45 CST Received: from delirius.cs.uiuc.edu by timbuk.cray.com (4.1/CRI-MX 1.6aa) id AA24673; Sun, 8 Mar 92 22:04:43 CST Received: from julius.cs.uiuc.edu by delirius.cs.uiuc.edu with SMTP id AA07859 (5.64+/IDA-1.3.4 for tcplw@cray.com); Sun, 8 Mar 92 22:04:37 -0600 Date: Sun, 8 Mar 92 22:04:37 -0600 From: Thomas Skibo Message-Id: <9203090404.AA07859@delirius.cs.uiuc.edu> To: tcplw@cray.com Subject: TCP Extensions Implementation on 4.3 BSD NR2 Cc: Brian_Zill@N2.SP.CS.CMU.EDU, hughes@hughes.NETWORK.COM, yhc@concert.net Folks: I'm making my experimental implementation of the 1072/1185 extensions available as a patch file to 4.3 BSD Networking Release 2. I finally got a machine to test it out on and it's been working well. The patch file and a README file briefly describing how to use the extensions are available via anonymous ftp from uxc.cso.uiuc.edu (128.174.5.50). It's a small shar file in the /pub directory called "tcplw.shar". (Also, that same machine is the now running the implementation.) All the details are in the README file there. All your comments, suggestions, criticisms, etc., are welcome. -skibo ------ Thomas Skibo skibo@cs.uiuc.edu ph: 217-333-7937 Received: by hemlock.cray.com id AA12857; 4.1/CRI-5.5; Tue, 25 Feb 92 09:28:58 CST Received: from timbuk.cray.com by hemlock.cray.com id AA12853; 4.1/CRI-5.5; Tue, 25 Feb 92 09:28:57 CST Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6z) id AA24382; Tue, 25 Feb 92 09:28:55 CST Received: by hemlock.cray.com id AA12850; 4.1/CRI-5.5; Tue, 25 Feb 92 09:28:55 CST Date: Tue, 25 Feb 92 09:28:55 CST From: dab@hemlock (David Borman) Message-Id: <9202251528.AA12850@hemlock.cray.com> To: tcplw@cray.com Subject: FYI: Last Call This is for the revised document, draft-ietf-tcplw-tcpext-02.txt -David Borman, dab@cray.com To: IETF Cc: IESG@NRI.Reston.VA.US From: IESG Secretary Subject: Last Call: TCP Extensions for High Performance Date: Mon, 24 Feb 92 13:11:19 -0500 The IESG has received a request from the TCP Large Windows Working Group to recommend the Internet Draft "TCP Extensions for High Performance" be published as a Proposed Standard. The IESG plans to issue a recommendation in the next few weeks, and solicits final comments on this elevation. Please send any comments to the iesg@nri.reston.va.us, or ietf@isi.edu mailing lists by March 5th. Greg Vaudreuil IESG Secretary Received: by hemlock.cray.com id AA01497; 4.1/CRI-5.5; Fri, 14 Feb 92 11:56:17 CST Received: from timbuk.cray.com by hemlock.cray.com id AA01493; 4.1/CRI-5.5; Fri, 14 Feb 92 11:56:16 CST Received: from venera.isi.edu by timbuk.cray.com (4.1/CRI-MX 1.6z) id AA10091; Fri, 14 Feb 92 11:56:12 CST Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-2) id ; Fri, 14 Feb 1992 09:58:07 -0800 Date: Fri, 14 Feb 92 09:55:45 PST From: braden@ISI.EDU Posted-Date: Fri, 14 Feb 92 09:55:45 PST Message-Id: <9202141755.AA10310@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Fri, 14 Feb 92 09:55:45 PST To: dab@cray.com Subject: Progress... Cc: tcplw@cray.com Friends, Yesterday I finally finished editing a new version of the I-D containing window scaling, RTTM, and PAWS, without SACK, and submitted it to be published as a new Internet Draft. It was proof-read by Dave Borman and by Liming Wei here at ISI; my thanks to both eagle-eyes! Thanks also to all who contributed comments at the IETF meeting. My understanding is that Dave Borman will now put on his IESG hat and introduce this version into the Internet standards track. Bob Braden Received: by hemlock.cray.com id AA17412; 4.1/CRI-5.5; Tue, 4 Feb 92 22:58:21 CST Received: from timbuk.cray.com by hemlock.cray.com id AA17408; 4.1/CRI-5.5; Tue, 4 Feb 92 22:58:19 CST Received: from sgi.sgi.com (SGI.COM) by timbuk.cray.com (4.1/CRI-MX 1.6y) id AA12946; Tue, 4 Feb 92 22:58:16 CST Received: from [192.26.75.58] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for tcplw@cray.com id AA12842; Tue, 4 Feb 92 20:58:14 -0800 Received: by rigden.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:tcplw@cray.com id AA06615; Wed, 5 Feb 92 04:58:07 GMT Date: Wed, 5 Feb 92 04:58:07 GMT From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9202050458.AA06615@rigden.wpd.sgi.com> To: tcplw@cray.com Subject: Re: What to do??? Cc: fred_s@pei.wpd.sgi.com, greg@sgi.com In the TCPLW mailing list, jdemarco@ftp.com (Jim DeMarco) writes: +--------------- | > 1) Leave the SACK option as currently stated in the draft, | > and publish it. | > 2) Change the SACK from a hard ack to a soft ack, and | > publish it. | I'd like to vote for #2. This proposed option has the least amount of | *real-world* experience (as far as I know). Let's implement soft | SACKs and find out how well it works. +--------------- Note for comparison that XTP has "soft" SACKs, and XTP is installed in a number of environments (albeit almost all *low*-delay LANs). Also, XTP uses 32-bit sequence numbers in SACKs (that is, 8 bytes per range SACK'd). Small XTP tutorial (skip if not interested), omitting details not relevant to selective ACKs: - XTP retransmission is "sender driven". The receiver *never* volunteers information unless the sender asks (with the SREQ or DREQ bit in the flags) for the receiver to send back a control packet. - Each packet, control or data, carries SEQ and DSEQ sequence numbers in both directions. - In a data packet, SEQ is the same as TCP SEQ. In a control packet from the sender, SEQ is what would be sent with the next "new" data, that is, it's one greater than the highest sequence number ever consumed by output data for that connection (a "high water mark"). - DSEQ is similar to TCP ACK, except that DSEQ guarantees that the data has been delivered all the way to the XTP client, and is not still sitting in the transport layer buffers. Retransmission buffers may not be freed until the data in them has been covered by DSEQ. DSEQ is a "hard ACK" [compare with RSEQ, below]. - Control packets (e.g., ones that come back from a receiver because the sender sent SREQ/DREQ) don't carry data, but do carry a bunch of additional "header" fields. The SACK-related ones are: ALLOC - Like TCP's WINDOW, but 32 bits (so no "large window option" needed). RSEQ - Similar to TCP ACK, in that it contains one plus the highest sequence of contiguously received data without error so far. However, RSEQ is a "soft ACK"; it's advisory only. Until DSEQ covers the data, it still may need retransmission. That is, the receiver is allowed to "renege" an RSEQ value in a later control packet [provided DSEQ <= new RSEQ]. NSPANS - The number of "spans" (SACKs, or sequence-number pairs). Spans, if present (NSPANS may be 0), follow the end of the fixed portion of a control packet. A span - Each "span" is a pair (low,high) of sequence numbers indicating a contiguous range of sequence numbers of data received without error. Since sequence numbers are 32 bits, each span is 8 bytes. The spans must be sorted in increasing sequence, and may not overlap RSEQ or each other. Spans are purely advisory (soft SACK). So each span describes both a contiguous sequence of data received (SACK). They also describe a non-empty set of "gaps" between the lower sequence number of the span and the higher sequence number of the next-lower span (or RSEQ, for the lowest span). There may or may not be a gap between the highest sequence number of the highest span and the sender's SEQ. The gaps are thus the logical candidates for retransmission. XTP specifically allows a sender to ignore some or all of the spans it gets back from a receiver if necessary (e.g., because of implementation limits on a small system), and (for example) base retransmission on just SEQ and RSEQ. So XTP, at least, has not only soft SACKs (spans), but separate soft ACK (RSEQ) and hard ACK (DSEQ) as well. Caveat: While the DSEQ/RSEQ/spans/SEQ scheme has been used "successfully" in XTP, it has been almost entirely in high-speed low-latency LAN environments, where data loss rates are very low (and what there is if it is often due to network adapter misdesign!). As far as I know, there has been no extensive trial of XTP in a "long, fat pipe" environment. [Greg?] -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com Silicon Graphics, Inc. (415)335-1673 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 Received: by hemlock.cray.com id AA05945; 4.1/CRI-5.5; Thu, 30 Jan 92 16:57:51 CST Received: from timbuk.cray.com by hemlock.cray.com id AA05938; 4.1/CRI-5.5; Thu, 30 Jan 92 16:57:50 CST Received: from md.interlink.com (leo.md.interlink.com) by timbuk.cray.com (4.1/CRI-MX 1.6w) id AA09530; Thu, 30 Jan 92 16:57:46 CST Received: by md.interlink.com (4.1/SMI-4.1.2) id AA24328; Thu, 30 Jan 92 17:55:41 EST Date: Thu, 30 Jan 92 17:55:41 EST From: fab@md.interlink.com (Fred Bohle) Message-Id: <9201302255.AA24328@md.interlink.com> To: dab Subject: Re: SACK option Cc: tcplw@cray.com OK, you want a vote, here is mine. Yes, split the document in two parts. Pass the first one up as you suggest. Hold the second while we resolve how the SACK option is formatted and how it is used. The question in my mind is why does Van say at least 4 SACK values are required??? Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@leo.md.interlink.com Interlink Computer Sciences AT&T : 301-317-6600 9145 Guilford Road, Suite 175 Columbia, MD 21046 ------------------------------------------------------------------------ Received: by hemlock.cray.com id AA03280; 4.1/CRI-5.5; Thu, 30 Jan 92 15:23:04 CST Received: from timbuk.cray.com by hemlock.cray.com id AA03276; 4.1/CRI-5.5; Thu, 30 Jan 92 15:23:02 CST Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6w) id AA03417; Thu, 30 Jan 92 15:23:00 CST Received: by hemlock.cray.com id AA03273; 4.1/CRI-5.5; Thu, 30 Jan 92 15:22:56 CST Date: Thu, 30 Jan 92 15:22:56 CST From: dab@hemlock (David Borman) Message-Id: <9201302122.AA03273@hemlock.cray.com> To: tcplw@cray.com Subject: SACK option Cc: iesg@NRI.Reston.VA.US Bob Braden and I discussed the issue about what to do with the SACK option. When we all agreed on the SACK option at the Santa Fe IETF meeting, it was generally felt that even though we didn't have a solid feeling for the semantics of the SACK option, we at least knew what the format should look like. Well, we don't feel that that is true anymore. The discussion that I have had with Van Jacobson, the limited discussion here on the mailing list, and the silence from the vast majority of this mailing list (there are 74 individuals and 6 exploders on this mailing list) indicates that we really have to get a better feel for the SACK option before we can say that we know what it should look like. So, to expedite matters, Bob has agreed to split the document into two pieces. The first part will contain the description of the Window Scale and Timestamps options. This document will be sent to the IESG with a recomendation that it be published as a proposed standard. The other document will contain the SACK option, and we can continue to bash it around until we get it right, or at least have a better understanding of what it is trying to accomplish. Our intention would be to pull the two documents back into a single document at a later point in time. They would get published as individual proposed standards, and then when they are both ready to go to draft status, we would pull them back together. If anyone has any objections to this approach, nows the time to speak up. Otherwise, I'll take silence as agreeing to splitting the document into two pieces. -David Borman, dab@cray.com Received: by hemlock.cray.com id AA03900; 4.1/CRI-5.5; Mon, 27 Jan 92 16:29:35 CST Received: from timbuk.cray.com by hemlock.cray.com id AA03893; 4.1/CRI-5.5; Mon, 27 Jan 92 16:29:34 CST Received: from ftp.com (babyoil.ftp.com) by timbuk.cray.com (4.1/CRI-MX 1.6v) id AA23188; Mon, 27 Jan 92 16:29:26 CST Received: by ftp.com id AA01344; Mon, 27 Jan 92 17:29:36 -0500 Date: Mon, 27 Jan 92 17:29:36 -0500 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9201272229.AA01344@ftp.com> To: dab Cc: tcplw@cray.com In-Reply-To: David Borman's message of Mon, 27 Jan 92 10:10:30 CST <9201271610.AA06182@hemlock.cray.com> Subject: What to do??? Reply-To: jdemarco@ftp.com >So, changing the length to 16 bits, without scaling, is really not a >viable solution. Ok, then, I'm reducing my options to just two: > > 1) Leave the SACK option as currently stated in the draft, > and publish it. > 2) Change the SACK from a hard ack to a soft ack, and > publish it. > >My preference is for #2. I'd like to vote for #2. This proposed option has the least amount of *real-world* experience (as far as I know). Let's implement soft SACKs and find out how well it works. After all, this is a "proposal" and is still subject to change depending on what our implementation experience shows us. --Jim jdemarco@ftp.com Received: by hemlock.cray.com id AA10538; 4.1/CRI-5.5; Mon, 27 Jan 92 11:46:56 CST Received: from timbuk.cray.com by hemlock.cray.com id AA10527; 4.1/CRI-5.5; Mon, 27 Jan 92 11:46:54 CST Received: from himnariki.cs.UMD.EDU by timbuk.cray.com (4.1/CRI-MX 1.6v) id AA03496; Mon, 27 Jan 92 11:46:24 CST Received: by himnariki.cs.UMD.EDU (5.61/UMIACS-0.9/04-05-88) id AA17268; Mon, 27 Jan 92 12:46:06 -0500 Date: Mon, 27 Jan 92 12:46:06 -0500 From: ogud@cs.UMD.EDU (Olafur Gudmundsson) Message-Id: <9201271746.AA17268@himnariki.cs.UMD.EDU> To: tcplw@cray.com Subject: Re: SACK option Cc: ogud@cs.UMD.EDU > > Ok, I sent out my mail to voice Van's concerns about the changes > that were made to the SACK option, and I have seen very > little response to it. I suppose everyone is off at Usenix... > I would like to get this thing published as a proposed RFC, so that > leaves me these options: > 1) Pass it up to the IESG as is. > 2) Change the SACK from a hard ack to a soft ack, and > pass it up to the IESG To summarize the arguments: The argument against soft ack is that the receiver may run out of buffer space and it may get stuck because it can not receive the packet that drains the out of sequence queue. The argument for soft ack is that less bandwidth is wasted on retransmissions. If receiver has fixed buffers allocated to a connection this is hard or soft SACK is of no consequence. If receiver behaves as the BSD as having one buffer pool a deadlock can occurre. If soft ack is the way we go then we may have a behavior that is realy strange, and wasteful. The scenario goes as follows: A packet get lost, SACK is sent back reflecting that this packet got lost, but everything after it got there. Sender retransmits that packet and sends some more packets, by the time the retransmitted packet arrives to the receiver, the first SACK'ed packet after it has been dropped. New retransmit cycle takes place, under this condition the throughput drops down to few packets per roundtrip time. I personaly think that by careful engineering both behaviors (deadlock and silly SACK) can be avoided and/or prevented. To avoid the problem of having to hold on to packets that have been SACK'ed when number of free buffers is limited is to suspend SACK's and to drop all packets that arrive on connections that have a packets received out of order. TCP should make the choice of stop sending SACK's when buffer pool falls below a certain mark. When buffer space becomes even thighter it starts dropping all out of sequence packets. Even if receiver agrees to support SACK's it is always free to suspending sending SACK's when it deems so necessary. > 3) Change the length part of the SACK back to a 16 bit > value, so that the SACK contain 4 slots instead of 3, > and pass it up to the IESG. I'm neutral on this one but the reason the meeting changed this one was to separate the window scaling and the SACK's. If the SACK is 16 bits host needs to support window scaling to be able to support SACK. If it is 32 bits implementors are free to support only SACK's. The argument about number of slots is valid but, I think am not ready to agree to this argument without getting more information on the assumptions used in the simulations that Van ran. Most packet losses on the Internet are random, burst losses are infrequent and to my experience occur about the same time as connectivity is lost (routing problems and crashing gateways). Therefore I agree with Van that if optimation is needed it should be to accommodate random losses. > 4) Do both 2 & 3. Change the SACK from a hard ack to a soft > ack, and change the length part of the SACK back to a 16 > bit value, so that the SACK contain 4 slots instead of 3, > and pass it up to the IESG. > Any other option (and probably options 3 & 4) would probably require > that this get held up a bit more... not what I want to see. > I am inclined to do option #2, change the SACK to a soft ack, and > then pass it on to the IESG, leaving the offset/length fields at > 32 bits each. Van had indicated to me that he really would like > to see it be a soft ack, but that he could live with the 32 bit > offset/length fields, even if he didn't like it. #1 and #3 are fine by me. The arguments for 2 are sound to much like a particular implementation likes that better than the other option rather than strong argument against doing things that way. Of course this is the most widely used implementation. Given that window scaling is a simple change I'm sure that for most implementing the SACK's and the timestamp addition it is not a big problem of adding window scaling at the same time. > This gets the thing published, and we can then hammer out any > problems with SACK later. Any changes would necessitate a new > TCP option number to avoid interoperability problems, but I don't > really view that as a serious obstacle. > -David Borman, dab@cray.com - - - - - - - - - Olafur Gudmundsson Dept. of Computer Science University of Maryland Internet: ogud@cs.umd.edu UUCP: {...!}uunet!mimsy!ogud UPS: College Park MD. 20742 Tel: (301)-405-2767 FAX:6707 Received: by hemlock.cray.com id AA06192; 4.1/CRI-5.5; Mon, 27 Jan 92 10:10:34 CST Received: from timbuk.cray.com by hemlock.cray.com id AA06187; 4.1/CRI-5.5; Mon, 27 Jan 92 10:10:32 CST Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6v) id AA26856; Mon, 27 Jan 92 10:10:30 CST Received: by hemlock.cray.com id AA06182; 4.1/CRI-5.5; Mon, 27 Jan 92 10:10:30 CST Date: Mon, 27 Jan 92 10:10:30 CST From: dab@hemlock (David Borman) Message-Id: <9201271610.AA06182@hemlock.cray.com> To: tcplw@cray.com Subject: Re: What to do??? I received a letter from Thomas Skibo that he did not copy to the mailing list, and he brought up a very valid point. I mentioned changing the length field of the SACK from 32 to 16 bits, to allow there to be 4 slots instead of 3. Unfortunatly, my brain was in the wrong gear... I was thinking of NACKs spread out evenly over the window, in which case the 16 bit length field would work. But as Thomas pointed out, the SACK option is acknowlding the data that did arrive, and if you have a large window and not much loss, you will get many packets together and with the 16 length you would not be able put them into a single SACK option when the length exceeds 64K. So, changing the length to 16 bits, without scaling, is really not a viable solution. Ok, then, I'm reducing my options to just two: 1) Leave the SACK option as currently stated in the draft, and publish it. 2) Change the SACK from a hard ack to a soft ack, and publish it. My preference is for #2. I'd like to see some e-mail voting out there. Please either reply to the mailing list, or directly to me. I'll count up the votes, and announce the results to the mailing list. I'd like to wrap up this issue, and get the thing published. -David Borman, dab@cray.com P.S. There is one other option. Pull the SACK option out into a seperate document, and publish the document with just the Window Shift and Timestamp options, and continue to discuss the SACK option... Received: by hemlock.cray.com id AA02215; 4.1/CRI-5.5; Fri, 24 Jan 92 09:38:51 CST Received: from timbuk.cray.com by hemlock.cray.com id AA02211; 4.1/CRI-5.5; Fri, 24 Jan 92 09:38:49 CST Received: from relay1.UU.NET by timbuk.cray.com (4.1/CRI-MX 1.6r) id AA22853; Fri, 24 Jan 92 09:38:32 CST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26870; Fri, 24 Jan 92 10:38:23 -0500 Received: from s5000.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 103703.1374; Fri, 24 Jan 1992 10:37:03 EST Received: by s5000.RSVL.UNISYS.COM (smail2.5) id AA08408; 24 Jan 92 09:21:45 CST (Fri) Subject: What to do? To: tcplw@cray.com Date: Fri, 24 Jan 92 9:21:42 CST X-Mailer: ELM [version 2.2 PL0] Message-Id: <9201240921.AA08404@s5000.RSVL.UNISYS.COM> From: kurt@s5000.RSVL.UNISYS.COM After reading what Dave wrote about Van's concerns, I would like the SACK to be advisory since our implementation also over commits its receive buffers. Otherwise I don't have any problems at the moment with the current draft. Send it in with this one change. Kurt Matthys Received: by hemlock.cray.com id AA18397; 4.1/CRI-5.5; Thu, 23 Jan 92 17:25:57 CST Received: from timbuk.cray.com by hemlock.cray.com id AA18393; 4.1/CRI-5.5; Thu, 23 Jan 92 17:25:55 CST Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6r) id AA26359; Thu, 23 Jan 92 17:25:54 CST Received: by hemlock.cray.com id AA18390; 4.1/CRI-5.5; Thu, 23 Jan 92 17:25:54 CST Date: Thu, 23 Jan 92 17:25:54 CST From: dab@hemlock (David Borman) Message-Id: <9201232325.AA18390@hemlock.cray.com> To: tcplw@cray.com Subject: What to do??? Ok, I sent out my mail to voice Van's concerns about the changes that were made to the SACK option, and I have seen very little response to it. I suppose everyone is off at Usenix... I would like to get this thing published as a proposed RFC, so that leaves me these options: 1) Pass it up to the IESG as is. 2) Change the SACK from a hard ack to a soft ack, and pass it up to the IESG 3) Change the length part of the SACK back to a 16 bit value, so that the SACK contain 4 slots instead of 3, and pass it up to the IESG. 4) Do both 2 & 3. Change the SACK from a hard ack to a soft ack, and change the length part of the SACK back to a 16 bit value, so that the SACK contain 4 slots instead of 3, and pass it up to the IESG. Any other option (and probably options 3 & 4) would probably require that this get held up a bit more... not what I want to see. I am inclined to do option #2, change the SACK to a soft ack, and then pass it on to the IESG, leaving the offset/length fields at 32 bits each. Van had indicated to me that he really would like to see it be a soft ack, but that he could live with the 32 bit offset/length fields, even if he didn't like it. This gets the thing published, and we can then hammer out any problems with SACK later. Any changes would necessitate a new TCP option number to avoid interoperability problems, but I don't really view that as a serious obstacle. -David Borman, dab@cray.com Received: by hemlock.cray.com id AA23959; 4.1/CRI-5.5; Tue, 21 Jan 92 12:33:38 CST Received: from timbuk.cray.com by hemlock.cray.com id AA23955; 4.1/CRI-5.5; Tue, 21 Jan 92 12:33:36 CST Received: from mitsou.inria.fr by timbuk.cray.com (4.1/CRI-MX 1.6r) id AA18411; Tue, 21 Jan 92 12:33:31 CST Received: from localhost by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA07969; Tue, 21 Jan 1992 09:33:15 +0100 Message-Id: <199201210833.AA07969@mitsou.inria.fr> To: dab@berserkly.cray.com (David Borman) Cc: tcplw@cray.com Subject: Re: SACK option In-Reply-To: Your message of "Mon, 20 Jan 92 17:22:53 CST." <9201202322.AA16668@berserkly.cray.com> Date: Tue, 21 Jan 92 09:33:11 +0000 From: Christian Huitema X-Mts: smtp A couple of months ago, I contributed a message explaining why I was not very enthusiastic about SACKs, essentially because SACKs trade network efficiency for longer delays and larger memory requirements. SACKs have two theoretical advantages: 1) they enable the emitter to "only retransmit the missing bits", instead of retransmitting the full window, resulting in better network utilisation. 2) they enable the emitter to "decommit s-acked buffers", thus resulting in better memory utilisation at the emitter side. Van's idea of "soft-sacks", which would be merely hints of "I believe I have received bytes X to Y and Z to T, so please retransmit up to X-1 and also Y+1 to Z-1, but maybe I am wrong, so expect me to ask you to also retransmit X to Y, basically destroys the second advantage. Indeed, as he points out, the memory can only be decommitted at the emitter side if the corresponding part was committed at the receiver side. Committing memory at the receiver side is contradictory with "system buffer" implementations, where the only bytes which can be safely hard-acknowledged are those already processed by the application. If you buy that, as I am ready to, then you should pursue your analysis a bit more. Your sacks are not "selective acks" anymore, as they do not enable the emitter to decommit its memory; in fact, they are "selective nacks", or SNACKs, telling the emitter that something is missing, and would you please retransmit it asap. Then, if you also buy the "random loss" hypothesis, you can go a bit further (in fact, if you do not buy that, you should not do selective acks at all). Why not simply redesign the SNACK option to contain a sequence of sequence numbers, essentially meaning: I did not receive byte number X. It will then be easy for the emitter to figure out which packets are concerned -- as easy as if a length field was present. And you could stick many of these numbers in the packets. If you dont feel confortable with a sequence number only, then you could imagine that the SNACK contains holes, with a "first byte of hole (32), length of hole (16)" philosophy. You could even save space by mandating that the first hole id be omitted, as it is equal to the sequence number. Christian Huitema PS. SNACKs work fine for multipoint, too... Received: by hemlock.cray.com id AA29217; 4.1/CRI-5.5; Mon, 20 Jan 92 18:10:54 CST Received: from timbuk.cray.com by hemlock.cray.com id AA29213; 4.1/CRI-5.5; Mon, 20 Jan 92 18:10:53 CST Received: from optima.cs.arizona.edu by timbuk.cray.com (4.1/CRI-MX 1.6r) id AA21604; Mon, 20 Jan 92 18:10:49 CST Date: Mon, 20 Jan 92 17:10:44 MST From: "Sean O'Malley" Message-Id: <9201210010.AA07270@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (4.1/15) id AA07270; Mon, 20 Jan 92 17:10:44 MST To: dab@berserkly.cray.com, tcplw@cray.com Subject: Re: SACK option I am still against any interaction between the SACK option and window scaling. Has anyone looked at this problem from a data compression angle? The algorithm proposed by Van et all is essentially an ad-hoc lossy compression algorithm. Before we start truncating random offsets (even when we don't have to!) I think someone should show that no non-lossy compression algorithm that gives us 6 slots is possible. Given that droped packets are not on the critical path I think we can afford to spend some cycles. Stated more formally: Is there a fuction f such that finverse(f(y)) = y where y is an arbitrary 6 slot SACK and sizeof(f(y)) <= 12 * 16 bits. This is what data compression research is for. Even if such an algorithm turns out to be more "complex" then the orginal SACK proposal we probably come out ahead because the resulting offsets and lengths will be correct if the function is correct and it should be possible to write a machine independant version of the function in C and give it away. You might also be able to do better than 6 slots. Sean O'Malley Received: from berserkly.cray.com by hemlock.cray.com id AA27764; 4.1/CRI-5.5; Mon, 20 Jan 92 17:23:15 CST Received: by berserkly.cray.com id AA16672; 5.64/CRI-4.9; Mon, 20 Jan 92 17:22:59 -0600 Received: by berserkly.cray.com id AA16668; 5.64/CRI-4.9; Mon, 20 Jan 92 17:22:53 -0600 Date: Mon, 20 Jan 92 17:22:53 -0600 From: dab@berserkly.cray.com (David Borman) Message-Id: <9201202322.AA16668@berserkly.cray.com> To: tcplw@cray.com Subject: SACK option Well, I have yet to see anything on the mailing list from Van Jacobson about the changes to the SACK option that were agreed upon at the last IETF meeting, and I know he has some concerns because he told me about them when I saw him the week before last. I would like to see this document get approved, but I'd also like to make sure that what gets approved is something that everyone can live with, Van included. So, to expidite matters, I'll bring up Vans points for him. 1) First, the issue of whether the SACK is a hard ACK or just advisory information. As you know, it was agreed upon at the IETF meeting that the SACK would be a hard ACK of data. Van feels that it should be the other way around, that the SACK is just advisory information. I was the one who brought up the issue to begin with, because in doing my implementation it occured to me that my code could potentially, on the receiver side, throw away data that had been received out of sequence, and that had been SACKed. I didn't really care whether they were hard acks or advisory, as long as it was specified. Bob Braden pointed out that if you have real buffers reserved on the reciever side, then it doesn't matter which way you set things up, either way will work. Van's view is that on a system where the buffers are not pre-allocated (like the BSD code) and the receiving host often over-commits its receive buffers, the hard SACK can cause connections and/or hosts to hang. The worst case scenario is that the receiver needs to free up some of its buffers to allow more packets to come in, but all of the buffers are sitting on TCP resequencing queues, and cannot be thrown away because they have been SACKed, and they cannot be delivered to the user because there is a hole in the data. So, Van would like to see the SACK be made strictly advisory; SACKs are just hints to the re-transmitter about what should be retransmitted, it is not a commitment that the SACKed data will never have to be resent. 2) The second concern that Van brought up is about the changing of the fields of the SACK option from 16 to 32 bits. As everyone knows, due to the maximum length of the TCP options, with the 16-bit fields you could have up to 6 sacks per SACK option, and with 32-bit fields you can only have 3 sacks per SACK option. His claim is that with the simulations that he has been running, it shows that you really need between 4 and 6 slots in the SACK, and that 4 is a minimal number. There are three things that could be done: 1) Leave it at 32-bits, we'll just have to deal with only having 3 slots/SACK option. If Van is right, then leaving things as they are will keep the SACK option from being as useful as it could be. 2) Leave the offset at 32-bits, and change the length back to 16 bits. This would allow 4 slots/SACK option. This means that if you loose more than 64K worth of packets in a row, you will have to use multiple slots in the SACK to acknowledge them, or not be able to SACK all the data. The flip side is that if you have random drop, which Van claims is the case, the loses will be spread out over the window, so you won't be having large lengths, and you get one more slot in the SACK. 3) Change both fields back to 16 bits, allowing 6 slots/SACK, but buying back the interaction with the window scale option... Van says something like: "What's the problem? It's not complicated. When the packet comes in, you shift the values by the window scale option, and use those new values. When sending the SACK, you shift the value just before filling in the fields. It is not a difficult problem, and then you have 6 slots in the SACK". Well, having put forth Vans viewpoints (Van, if I mis-represented you, please set the record straight), I'll offer my views. I don't have any problem with making the first change. As I said before, I really don't care whether SACKs are hard or advisory, as long as it is set one way or the other. And since my code is based on the BSD code, I'm inclined to advocate making SACK strictly advisory. As for the slots/SACK issue, in my mind it comes down to a couple of questions: 1) Do you want to buy into the interoperation between the SACK and the Window Scale options? If that's ok, then lets go back to all 16-bit fields. 2) Do you belive that losses will be random, or in clumps? If you belive the former, then a 16-bit length field is fine, and will give a fourth slot in the SACK. If you belive the latter, then you'll probably want the 32-bit fields. I don't like having interaction between the SACK and the Window Scale option. If Van can support the argument that we need at least 4 slots, I'd be willing to accept changing the length to 16-bits to allow a fouth slot in the SACK. After thinking about the SACK option and the number of slots, I sent a message to Van about it. My back-of-the-envelope analysis says that the minimum number of slots needed in the SACK is dependent on the loss rate: If you lose less than one packet per RTT, then you only need 1 slot. If you lose 1-2 packets per RTT, then you need two slots. At 2-3 losses per RTT, you need 3 slots. And so on. With that kind of thinking, then as long as there is a limit to the number of slots/SACK, there will be a threshhold for losses; below that threshhold, things will work just fine. Above that threshhold, you will not be as effecient as possible. Attached is a copy of the note I sent to Van. -David Borman, dab@cray.com > From dab@cray.com Fri Jan 10 17:59:10 1992 > To: van@ee.lbl.gov > Subject: SACK > Cc: braden@isi.edu > Status: R > > > Van, > > With regards to the # of SACK entries needed, you said to me that > the minimum number needed was four, and you talked about some > "leap-frogging" as the reason. I don't remember exactly what > you were saying, so I've sat down and done some thinking about > this. As you said, the loss that we are concerned about is where > the loss rate is random, not bursty, so our losses are distributed > over the window. > > It seems to me that the number of slots needed in the SACK option > is dependent only on how often packets are lost per RTT, and that > the higher the loss rate, the more slots are needed. > > Here's my thinking: > > For the sake of argument, let's assume that we can send 10 full-size > packets per RTT, and that the receivers window is large enough that > the sender isn't going to have to slow down. If we have exactly one > lost packet, the we'll see something like this from when the lost > packet was first sent: > > Time Sender Receiver > ---- ------ -------- > 0.0RTT packet 1 is sent & lost > 0.1RTT packet 2 is sent > 0.2RTT packet 3 is sent > 0.3RTT packet 4 is sent > 0.4RTT packet 5 is sent > 0.5RTT packet 6 is sent (Packet 1 does not arrive...) > 0.6RTT packet 7 is sent Packet 2 arrives, ACK:0/SACK:2 sent > 0.7RTT packet 8 is sent Packet 3 arrives, ACK:0/SACK:2-3 sent > 0.8RTT packet 9 is sent Packet 4 arrives, ACK:0/SACK:2-4 sent > 0.9RTT packet 10 is sent Packet 5 arrives, ACK:0/SACK:2-5 sent > 1.0RTT packet 11 is sent Packet 6 arrives, ACK:0/SACK:2-6 sent > 1.1RTT ACK:0/SACK:2 arrives Packet 7 arrives, ACK:0/SACK:2-7 sent > Packet 12 is sent > 1.2RTT ACK:0/SACK:2-3 arrives Packet 8 arrives, ACK:0/SACK:2-8 sent > Packet 13 is sent > 1.3RTT ACK:0/SACK:2-4 arrives Packet 9 arrives, ACK:0/SACK:2-9 sent > *** Packet 1 is sent > 1.4RTT ACK:0/SACK:2-5 arrives Packet 10 arrives, ACK:0/SACK:2-10 sent > Packet 14 is sent > 1.5RTT ACK:0/SACK:2-6 arrives Packet 11 arrives, ACK:0/SACK:2-11 sent > Packet 15 is sent > 1.6RTT ACK:0/SACK:2-7 arrives Packet 12 arrives, ACK:0/SACK:2-12 sent > Packet 16 is sent > 1.7RTT ACK:0/SACK:2-8 arrives Packet 13 arrives, ACK:0/SACK:2-13 sent > Packet 17 is sent > 1.8RTT ACK:0/SACK:2-9 arrives Packet 1 arrives, ACK:13 sent > Packet 18 is sent > 1.9RTT ACK:0/SACK:2-10 arrives Packet 14 arrives, ACK:14 sent > Packet 19 is sent > 2.0RTT ACK:0/SACK:2-11 arrives Packet 15 arrives, ACK:15 sent > Packet 20 is sent > 2.1RTT ACK:0/SACK:2-12 arrives Packet 16 arrives, ACK:16 sent > Packet 21 is sent > 2.1RTT ACK:0/SACK:2-13 arrives Packet 17 arrives, ACK:17 sent > Packet 22 is sent > 2.1RTT ACK:13 arrives Packet 18 arrives, ACK:18 sent > Packet 22 is sent > 2.2RTT ACK:14 arrives Packet 19 arrives, ACK:19 sent > Packet 23 is sent > > > So, at 1.5RTT + 2 packets, the reciever stops sending SACK for the missing > packet. By 2 RTT + 1 packet, everything is all cleaned up. If there were > no dropped packets between when packet 1 was lost and when it was > retransmitted, then just 1 SACK slot is needed. Packet 1 gets retransmitted > at 1RTT+3 pkt, so if the drop rate is less than 1 packet per 1RTT+3pkt, then > only 1 slot/SACK is needed. If the drop rate is such that between 1-2 > packets per 1RTT+3pkt is lost, then we would have the above scenario > overlapped once, and a SACK with 2 slots is needed during the overlap. > Likewise, if the drop rate is between 2-3 packets/1RTT+3pkt, then a > three slot SACK is needed, and so on, and so on. In general, if the > drop rate is more than D packets per 1RTT+Npkt, you will need a SACK option > with D+1 slots to achieve maximum throughput, where D is the # of dropped > packets, and N is the # of SACKs needed to kick off the retransmit. > > This analysis doesn't support your contention that three SACK slots is > not enough. What it does support is that the more lossy the network, > the more slots you need. > > Back-of-the-envelop says that the maximum number of SACK slots needed > would be on the order of the number of packets that can be sent per RTT. > > What are the loss rates that you are using in your simulations? > > Any comments or holes in my logic? > > -David Borman, dab@cray.com > Received: by hemlock.cray.com id AA01493; 4.1/CRI-5.5; Thu, 9 Jan 92 03:52:12 CST Received: from timbuk.cray.com by hemlock.cray.com id AA01489; 4.1/CRI-5.5; Thu, 9 Jan 92 03:52:10 CST Received: from wugate.wustl.edu by timbuk.cray.com (4.1/CRI-MX 1.6p) id AA13026; Thu, 9 Jan 92 03:52:07 CST Received: by wugate.wustl.edu (5.65c/WUSTL-0.3) with SMTP id AA19334; Thu, 9 Jan 1992 03:52:01 -0600 Received: by dworkin.wustl.edu (4.0/yuck-4.0) id AA14639; Thu, 9 Jan 92 03:52:31 CST Date: Thu, 9 Jan 92 03:52:31 CST From: zubin@dworkin.wustl.edu (Zubin Dittia) Message-Id: <9201090952.AA14639@dworkin.wustl.edu> To: end2end-interest@venera.isi.edu, tcplw@cray.com Subject: SACK option... If we allow 32 bits for the relative offset and length fields in the SACK option, I was wondering if it might make more sense to use the starting sequence number and the ending sequence number (or the starting sequence number and the block length) for each block of data being acknowledged. Could someone explain why relative offset and length were selected, and the trade-offs involved, if any. Zubin. Received: by hemlock.cray.com id AA12794; 4.1/CRI-5.5; Tue, 31 Dec 91 15:53:12 CST Received: from timbuk.cray.com by hemlock.cray.com id AA12790; 4.1/CRI-5.5; Tue, 31 Dec 91 15:53:10 CST Received: from winter.nas.nasa.gov by timbuk.cray.com (4.1/CRI-MX 1.6p) id AA01209; Tue, 31 Dec 91 15:53:05 CST Received: by winter.nas.nasa.gov (5.61/1.34) id AA00956; Tue, 31 Dec 91 13:52:59 -0800 Date: Tue, 31 Dec 91 13:52:59 -0800 From: dji@nas.nasa.gov (the dirty vicar) Message-Id: <9112312152.AA00956@winter.nas.nasa.gov> To: tcplw@cray.com Subject: Info wanted Where can I get documentation of the current status of RFCs 1072 and 1185, and a detailed description of the latest technical issues regarding them? Thanks much. Dave Iannucci dji@nas.nasa.gov | In girum imus NASA Ames Research Center ...ames!nas.nasa.gov!dji | nocte et Numerical Aerodynamic Simulation / Systems Development | consumimur igni Received: by hemlock.cray.com id AA14900; 4.1/CRI-5.5; Mon, 30 Dec 91 15:19:47 CST Received: from timbuk.cray.com by hemlock.cray.com id AA14895; 4.1/CRI-5.5; Mon, 30 Dec 91 15:19:44 CST Received: from wc.novell.com ([130.57.64.11]) by timbuk.cray.com (4.1/CRI-MX 1.6p) id AA21631; Mon, 30 Dec 91 15:19:20 CST Received: from plasma.wc.novell.com by wc.novell.com (4.0/SMI-DDN) id AA11486; Mon, 30 Dec 91 13:17:10 PST Received: from localhost by plasma.wc.novell.com (3.2/SMI-3.2) id AA06446; Mon, 30 Dec 91 13:31:53 PST Message-Id: <9112302131.AA06446@plasma.wc.novell.com> To: tcplw@cray.com Subject: Re: TCP LW mailing list Date: Mon, 30 Dec 91 13:31:52 -0800 From: minshall@wc.novell.com Hi! Please sign up . Thanks. Received: by hemlock.cray.com id AA10588; 4.1/CRI-5.5; Mon, 30 Dec 91 12:41:24 CST Received: from timbuk.cray.com by hemlock.cray.com id AA10584; 4.1/CRI-5.5; Mon, 30 Dec 91 12:41:22 CST Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6p) id AA16059; Mon, 30 Dec 91 12:41:21 CST Received: by hemlock.cray.com id AA10580; 4.1/CRI-5.5; Mon, 30 Dec 91 12:41:18 CST Date: Mon, 30 Dec 91 12:41:18 CST From: dab@hemlock (David Borman) Message-Id: <9112301841.AA10580@hemlock.cray.com> To: tcplw@cray.com Subject: tcplw@cray.com Hi there. You are on the "tcplw@cray.com" mailing list. If you wish to be removed, send mail to "tcplw-request@cray.com". -David Borman, dab@cray.com Received: by hemlock.cray.com id AA10454; 4.1/CRI-5.5; Mon, 30 Dec 91 12:38:22 CST Received: from timbuk.cray.com by hemlock.cray.com id AA10450; 4.1/CRI-5.5; Mon, 30 Dec 91 12:38:20 CST Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6p) id AA15924; Mon, 30 Dec 91 12:38:18 CST Received: by hemlock.cray.com id AA10446; 4.1/CRI-5.5; Mon, 30 Dec 91 12:38:17 CST Date: Mon, 30 Dec 91 12:38:17 CST From: dab@hemlock (David Borman) Message-Id: <9112301838.AA10446@hemlock.cray.com> To: end2end-interest@ISI.EDU, ietf-interest@venera.isi.edu, tcplw@cray.com Subject: TCP LW mailing list A new mailing list has been set up for continuing discussion of the new TCP options for large windows. The list is: tcplw@cray.com tcplw-request@cray.com The initial list consists of those who were at the Santa Fe TCP Large Windows working group. I will send a seperate note to just the list, so that those who are on it will know. -David Borman, dab@cray.com For the moment, let $r_{i}$ denote node $i$'s average roundtrip time including queueing delays. In the congestion avoidance phase of TCP, node $i$'s window is increased by roughly $1$ packet every $r_{i}$ seconds. Thus, node $i$'s throughput is increased by $1/r_i$ pkts/sec every $r_i$ seconds, or by $1/(r_{i})^2$ pkts/sec every second. Therefore, after a packet from node 2 is dropped and node 2's window is decreased, it takes node 2 significantly longer than node 1 to recover its former throughput rate. This accounts for the reduced throughput for node 2. Note that if each node $i$ increases its window by $c*(r_{i})^2$ packets each roundtrip time, for some constant $c$, then each node would increase its throughput by $c$ pkts/sec in one second, regardless of roundtrip time. Since each source already has an estimate for the roundtrip time for each connection, such an algorithm is easily implemented. Figure \ref{f:addsq_ed} shows the results of simulations where each connection increases its window by $2*(r_{i})^2$ packets each roundtrip time. These simulations differ from the simulations in Figure \ref{f:addoneed} only in the window increase algorithm; in every other respect the two sets of simulations are the same. These simulations use Fast Recovery TCP, Selective Acknowledgement sinks, and Random Early Detection gateways that do not discriminate against bursty traffic. Node 1 and node 2 each receive roughly half of the total throughput, regardless of roundtrip time. This result is analyzed in more detail elsewhere \cite{F91}. These simulation results are in accord with previous analytical results \cite{Chi89}. Chiu and Jain consider linear algorithms for increasing and decreasing the load, where the load could be considered either as a rate or as a window. They show that a purely additive increase in the load gives the quickest convergence to fairness. For the model investigated by Chiu and Jain, this increase occurs at fixed time intervals. For a network with connections with different roundtrip times, comparable rates and comparable windows are quite different things. If the fairness goal is to provide comparable rates for connections with different roundtrip times, then the quickest convergence to fairness should occur with an additive increase in the rate for each fixed time interval. This is accomplished if every source increases its rate by $c$ pkts/sec each second, for some constant $c$. This is equivalent to each connection increasing its window by $c*(r_{i})^2$ packets each roundtrip time. If the fairness goal is to allocate equal network resources to different connections, a connection traversing $n$ congested gateways uses $n$ times the resources of one traversing one gateway. To be `fair', the long connection should get only $1/n$th the bandwidth of the short. Thus, different fairness goals would imply different window increase algorithms. With a window increase of $c*r_{i}$ packets each roundtrip time, for example, each connection increases its window by $c$ packets in one second, and increases its throughput by $c/{r_{i}}$ pkts/sec each second. Fairness goals for connections with multiple congested gateways are discussed further elsewhere \cite{F91}. There are many open questions concerning alternatives to the TCP window modification algorithms. If the goal is for each connection to increase its rate by $c$ pkts/sec each second, how do we choose $c$? What would be the impact of connections with large maximum windows increasing their window much more rapidly than they do now? Instead of using the average roundtrip time to calculate window increases, would it be better to use the average window size, averaged over a rather long period of time, or some other measure? And the ultimate difficult question: What is the meaning of ``fair''? At the moment, this section is intended only to suggest that the current network bias in favor of connections with shorter roundtrip times is a result of the TCP window increase algorithm, and not of the performance of Random Drop or of Drop Tail gateways. retransmitted packet before saving the timestamp into TS.Recent (rule #2, page 16), so when we send the ack, it'll have the old TS.Recent value, not the one in the just received packet. The originator gets the retransmitted ack with the old TSecr and because the first ack was lost, the ack acknowledges new data at the left of the window, so it uses the TSecr in the RTT calculation (section 3.3, page 14). It has now calculated into its RTT its current retransmission timer!!! A quick proposal on how to fix this. On page 16, add the indicated section to case #2: (2) If Last.ACK.sent falls within the range of sequence numbers of an incoming segment: SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN + or if the packet is strictly old data, but its TSval is + more recent than TS.Recent (indicating that it is a + retransmit due to the ACK being lost): + + SEG.SEQ + SEG.LEN <= Last.ACK.sent + and TSval > TS.Recent + then the TSval from the segment is copied to TS.Recent; otherwise, the TSval is ignored. If this problem is already addressed in 1323 and I have just missed it, I'd sure appreciate someone pointing out what I missed. -David Borman, dab@cray.com