Subject: Conservative behaviours
From: Luigi Rizzo <[email-masked]>
To: [email-masked]
Date: Tue, 6 Feb 1996 14:22:19 +0100 (MET)

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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

From: Luigi Rizzo <[email-masked]>
Subject: Re: Thoughts about RFC1323 timestamps
To: [email-masked]
Date: Tue, 6 Feb 1996 14:31:23 +0100 (MET)
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

Date: Tue, 6 Feb 96 01:19:00 PST
From: [email-masked] (Biswanath Mukherjee)
To: [email-masked]
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 "[email-masked]".

Biswanath Mukherjee
Technical Program Chair, IEEE INFOCOM '96
University of California
Department of Computer Science
Davis, California 95616, USA
Email:     [email-masked] (for all correspondence re: Infocom '96)
Telephone: +1-916-752-4826
Fax:       +1-916-752-4767

From: David Borman <[email-masked]>
Date: Mon, 5 Feb 1996 14:38:33 -0600
To: [email-masked]
Subject: Re: Thoughts about RFC1323 timestamps
Cc: [email-masked], [email-masked]

> From: Luigi Rizzo <[email-masked]>
> 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, [email-masked]

From: Luigi Rizzo <[email-masked]>
Subject: Re: Thoughts about RFC1323 timestamps
To: [email-masked] (David Borman)
Date: Mon, 5 Feb 1996 19:20:50 +0100 (MET)
Cc: [email-masked], [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

From: David Borman <[email-masked]>
Date: Mon, 5 Feb 1996 11:17:20 -0600
To: [email-masked]
Subject: Re: Thoughts about RFC1323 timestamps
Cc: [email-masked], [email-masked]

> From [email-masked] Sun Feb  4 17:04 CST 1996
> From: Luigi Rizzo <[email-masked]>
> Subject: Re: Thoughts about RFC1323 timestamps
> To: [email-masked] (Matt Mathis)
> Date: Sun, 4 Feb 1996 23:56:51 +0100 (MET)
> Cc: [email-masked], [email-masked]
> 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, [email-masked]

From: Luigi Rizzo <[email-masked]>
Subject: Re: Thoughts about RFC1323 timestamps
To: [email-masked] (Matt Mathis)
Date: Sun, 4 Feb 1996 23:56:51 +0100 (MET)
Cc: [email-masked], [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

To: Luigi Rizzo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Thoughts about RFC1323 timestamps 
Date: Sun, 04 Feb 1996 11:26:29 -0500
From: "Matt Mathis" <[email-masked]>

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--

From: Luigi Rizzo <[email-masked]>
Subject: Thoughts about RFC1323 timestamps
To: [email-masked]
Date: Sun, 4 Feb 1996 10:14:25 +0100 (MET)
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

To: IETF-Announce:;@cnri.reston.va.us
cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-tcplw-sack-00.txt
Date: Fri, 26 Jan 96 09:37:13 -0500
Sender: [email-masked]

--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:  [email-masked]. 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 [email-masked].

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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--

--NextPart--

From: David Borman <[email-masked]>
Date: Thu, 25 Jan 1996 10:26:01 -0600
To: [email-masked]
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, [email-masked]

> From [email-masked] Wed Jan 24 14:51 CST 1996
> Mime-Version: 1.0
> Date: Wed, 24 Jan 1996 15:47:54 -0500
> To: [email-masked]
> From: Marcia Beaulieu <[email-masked]>
> Subject: LOS ANGELES IETF: TCPLW
> Cc: [email-masked]
> 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

To: [email-masked] (Fred Bohle)
Cc: [email-masked]
Subject: Re: SACK options draft 
Date: Tue, 23 Jan 1996 22:47:24 -0500
From: "Matt Mathis" <[email-masked]>

>       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--

From: Luigi Rizzo <[email-masked]>
Subject: Re: SACK options draft
To: [email-masked] (Sally Floyd)
Date: Wed, 24 Jan 1996 01:45:12 +0100 (MET)
Cc: [email-masked], [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

From: [email-masked]
Date: Tue, 23 Jan 96 15:40:34 PST
Posted-Date: Tue, 23 Jan 96 15:40:34 PST
To: [email-masked], [email-masked]
Subject: Re: SACK options draft
Cc: [email-masked]

  *> 
  *> (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

To: [email-masked] (Fred Bohle)
cc: [email-masked]
Subject: Re: SACK options draft
Date: Tue, 23 Jan 1996 15:07:41 PST
From: Sally Floyd <[email-masked]>

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: SACK options draft
Date: Tue, 23 Jan 1996 16:31:38 -0500
From: "Matt Mathis" <[email-masked]>

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--

Date: Tue, 23 Jan 1996 15:45:01 +0500
From: [email-masked] (Fred Bohle)
To: [email-masked]
Subject: Re: SACK options draft
Cc: [email-masked]
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: [email-masked]
Interlink Computer Sciences	AT&T : 410-992-7750 
9250 Rumsey Road, Suite 200     Home : 410-643-6720
Columbia, MD 21045-1946
------------------------------------------------------------------------

Date: Tue, 23 Jan 1996 11:51:32 -0800
From: [email-masked] (Allyn Romanow)
To: [email-masked]
Subject: SACK options draft
Cc: [email-masked]

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.

From: [email-masked]
Date: Mon, 22 Jan 96 09:31:46 PST
Posted-Date: Mon, 22 Jan 96 09:31:46 PST
To: [email-masked], [email-masked]
Subject: TTCP BOF at LA IETF meeting
Cc: [email-masked], [email-masked]

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

From: Luigi Rizzo <[email-masked]>
Subject: Re: internet-draft for SACK
To: [email-masked] (Greg Miller)
Date: Sat, 20 Jan 1996 11:18:53 +0100 (MET)
Cc: [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

To: [email-masked]
Subject: Re: internet-draft for SACK
Date: Thu, 18 Jan 96 15:46:56 -0500
From: Greg Miller <[email-masked]>

  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         [email-masked]

Date: Thu, 18 Jan 96 12:32:09 CST
From: [email-masked] (David A. Borman)
To: [email-masked], [email-masked]
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          [email-masked]          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, [email-masked]

Date: Thu, 18 Jan 1996 12:15:00 -0600
From: Matt Crawford <[email-masked]>
Subject: Two questions from a non-subscriber
Sender: [email-masked]
To: [email-masked]

1. Is there an archive for tcplw?

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          [email-masked]          Fermilab
  PGP: D5 27 83 7A 25 25 7D FB  09 3C BA 33 71 C4 DA 6A

Date: Tue, 16 Jan 1996 14:01:31 -0800 (PST)
From: Bob Gilligan <[email-masked]>
Reply-To: Bob Gilligan <[email-masked]>
Subject: Re: Fast retransmit in Solaris 2.x
To: Fred Bohle <[email-masked]>
Cc: [email-masked]

> 
> > 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
> [email-masked]

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.

Date: Tue, 16 Jan 1996 14:32:14 +0500
From: [email-masked] (Fred Bohle)
To: [email-masked]
Subject: Re: Fast retransmit in Solaris 2.x
Cc: [email-masked]
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
[email-masked]

Date: Tue, 16 Jan 1996 11:21:08 -0800 (PST)
From: Bob Gilligan <[email-masked]>
Reply-To: Bob Gilligan <[email-masked]>
Subject: Re: Fast retransmit in Solaris 2.x
To: [email-masked]
Cc: [email-masked]

> 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

From: [email-masked]
Date: Tue, 16 Jan 96 09:17:24 PST
Posted-Date: Tue, 16 Jan 96 09:17:24 PST
To: [email-masked]

   ----- 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: <[email-masked]>
Received: by can.isi.edu (4.1/4.0.3-4)
	id <AA05411>; Tue, 16 Jan 96 09:04:14 PST
To: [email-masked]
Subject: Minutes of tcpfix BOF in Dallas
Cc: tcplw, end2end-interest, mankin, [email-masked], [email-masked]

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 -----

From: [email-masked] (Richard Stevens)
Date: Mon, 15 Jan 1996 07:19:10 -0700
Reply-To: Richard Stevens <[email-masked]>
To: [email-masked], [email-masked]
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

From: [email-masked]
Date: Fri, 12 Jan 1996 17:40:53 +0100
To: [email-masked]
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
[email-masked]
tel: +49 6151 807596
fax: +49 6151 807304

EUMETSAT
Am Kavalleriesand 31
64295 Darmstadt
Germany
===========================================================
=========================

From: [email-masked]
Date: Wed, 10 Jan 1996 16:37:38 +0100
To: [email-masked]
Subject: Second IEEE International Conference on Engineering of Complex Computer Systems
Cc: [email-masked]
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
[email-masked]

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.
[email-masked]

Tutorials Chair
Neville Dean, Anglia Polytechnic University

Local Arrangements Chair
John Harauz, Ontario Hydro

Publicity Chair
Michael Hinchey
New Jersey Institute of Technology
[email-masked]

-----------------------------------------------------------------------------
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
[email-masked]
+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
[email-masked]
+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.
-----------------------------------------------------------------------------

From: [email-masked]
Date: Wed, 10 Jan 1996 16:46:14 +0100
To: [email-masked]
Subject: Second IEEE International Conference on Engineering of Complex Computer Systems
Cc: [email-masked]
Reply-To: [email-masked]
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
[email-masked]

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.
[email-masked]

Tutorials Chair
Neville Dean, Anglia Polytechnic University

Local Arrangements Chair
John Harauz, Ontario Hydro

Publicity Chair
Michael Hinchey
New Jersey Institute of Technology
[email-masked]

-----------------------------------------------------------------------------
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
[email-masked]
+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
[email-masked]
+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.
-----------------------------------------------------------------------------

From: Luigi Rizzo <[email-masked]>
Subject: Re: Cheap SACKs
To: [email-masked]
Date: Fri, 12 Jan 1996 17:57:07 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

Date: Fri, 12 Jan 1996 10:02:24 -0500
From: Jamshid Mahdavi <[email-masked]>
To: Luigi Rizzo <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Cheap SACKs
Reply-to: [email-masked]

> From: Luigi Rizzo <[email-masked]>
> Cc: [email-masked] (Luigi Rizzo), [email-masked],
>         [email-masked], [email-masked], [email-masked]
> Date: Thu, 11 Jan 1996 18:18:20 +0100 (MET)
> X-From-Line: [email-masked]  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

From: Luigi Rizzo <[email-masked]>
Subject: Re: Cheap SACKs
To: [email-masked] (Matt Mathis)
Date: Fri, 12 Jan 1996 09:24:44 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

To: Luigi Rizzo <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Cheap SACKs 
Date: Thu, 11 Jan 1996 23:28:17 -0500
From: "Matt Mathis" <[email-masked]>

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--

From: Luigi Rizzo <[email-masked]>
Subject: Cheap SACKs
To: [email-masked]
Date: Thu, 11 Jan 1996 18:18:20 +0100 (MET)
Cc: [email-masked] (Luigi Rizzo), [email-masked], [email-masked], [email-masked], [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

To: Luigi Rizzo <[email-masked]>
cc: [email-masked]
Subject: Re: internet-draft for SACK
Date: Fri, 05 Jan 96 17:59:46 PST
From: Sally Floyd <[email-masked]>

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

From: Luigi Rizzo <[email-masked]>
Subject: Re: internet-draft for SACK
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 6 Jan 1996 02:24:46 +0100 (MET)
Cc: [email-masked] (Luigi Rizzo)
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

From: Luigi Rizzo <[email-masked]>
Subject: Re: internet-draft for SACK
To: [email-masked] (Bob Braden)
Date: Sat, 6 Jan 1996 02:20:04 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 2860

Bob Braden said:

>   *> From [email-masked] 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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

Date: Fri, 5 Jan 1996 12:25:43 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: internet-draft for SACK
Cc: [email-masked], [email-masked]

  *> From [email-masked] Fri Jan  5 12:13:02 1996
  *> From: Luigi Rizzo <[email-masked]>
  *> Subject: Re: internet-draft for SACK
  *> To: [email-masked] (Bob Braden)
  *> Date: Fri, 5 Jan 1996 21:15:01 +0100 (MET)
  *> Cc: [email-masked], [email-masked], [email-masked]
  *> In-Reply-To: <[email-masked]> 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: [email-masked]       Universita' di Pisa
  *> tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
  *> fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
  *> ====================================================================
  *> 

From: Luigi Rizzo <[email-masked]>
Subject: Re: internet-draft for SACK
To: [email-masked] (Bob Braden)
Date: Fri, 5 Jan 1996 21:15:01 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

To: [email-masked] (Bob Braden)
Cc: [email-masked], [email-masked]
Subject: Re: internet-draft for SACK 
Date: Fri, 05 Jan 1996 14:31:03 -0500
From: "Matt Mathis" <[email-masked]>

>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--

Date: Fri, 5 Jan 1996 11:04:14 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: internet-draft for SACK
Cc: [email-masked]

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

Date: Fri, 5 Jan 1996 10:41:26 -0800
From: [email-masked] (Bob Braden)
To: [email-masked]
Subject: Re: internet-draft for SACK
Cc: [email-masked]

  *> From [email-masked] Fri Jan  5 10:38:16 1996
  *> To: Andras Olah <[email-masked]>
  *> Cc: [email-masked]
  *> Subject: Re: internet-draft for SACK 
  *> In-Reply-To: Your message of "Fri, 05 Jan 1996 09:28:05 +0100."
  *>              <[email-masked]> 
  *> Date: Fri, 05 Jan 1996 13:34:21 -0500
  *> From: "Matt Mathis" <[email-masked]>
  *> 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

To: Andras Olah <[email-masked]>
Cc: [email-masked]
Subject: Re: internet-draft for SACK 
Date: Fri, 05 Jan 1996 13:34:21 -0500
From: "Matt Mathis" <[email-masked]>

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--

To: [email-masked]
Subject: Re: internet-draft for SACK 
Date: Fri, 05 Jan 1996 09:28:05 +0100
From: Andras Olah <[email-masked]>

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

Date: Thu, 4 Jan 1996 15:57:58 -0800
From: [email-masked] (Allyn Romanow)
To: [email-masked]
Subject: internet-draft for SACK

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       [email-masked]
                        Jamshid Mahdavi         [email-masked]
                        Sally Floyd             [email-masked]
                        Allyn Romanow           [email-masked]

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.

From: Luigi Rizzo <[email-masked]>
Subject: Selective Acknowledgements... (fwd)
To: [email-masked]
Date: Mon, 18 Dec 1995 20:27:05 +0100 (MET)
Cc: [email-masked] (Luigi Rizzo)
Content-Length: 5585

Hi,

Jamshid Mahdavi <[email-masked]> pointed me to this group where
(among others) discussions on SACKs are being done. I have browsed
in the archives of the "[email-masked]" 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 <[email-masked]>
To: [email-masked]
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 <[email-masked]> 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: [email-masked]       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

From: [email-masked] (Aurel A. Lazar)
Date: Mon, 20 Nov 1995 18:08:06 -0500
To: [email-masked]
Subject: xbind software available in alpha release
Cc: [email-masked]

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

From: [email-masked]
Date: Mon, 20 Nov 1995 13:12:37 cst
Subject: NOSDAV Mailing list
To: [email-masked]
Cc: [email-masked]

To whom it may concern.
 
I received your address from [email-masked]

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
 
         [email-masked]
 to:
         [email-masked]
 
 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:
[email-masked]
Cameron Bramwell                  Intellibyte Inc.
330 Bay Street, Suite 1600     
Toronto, Ontario, Canada
M5H 2S8
Voice 416-368-7817 Ex#28      FAX 416-368-4617
-----------------------------------------------------------------------

Organization: Eurecom, Sophia-Antipolis, France
Date: Mon, 20 Nov 95 18:44:43 +0100
From: Biersack Ernst <[email-masked]>
To: [email-masked]
Subject: Call for Paper: Euromicro 1996
Cc: [email-masked]

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

 

To: [email-masked]
Subject: Call for Paper: NOSSDAV'96
Date: Mon, 20 Nov 1995 14:07:50 JST
From: Tatsuo Nakajima <[email-masked]>

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
[email-masked].

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: [email-masked] 

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 

From: [email-masked]
Date: Fri, 3 Nov 1995 08:42:13 -0800
Posted-Date: Fri, 3 Nov 1995 08:42:13 -0800
To: [email-masked], [email-masked]
Subject: Re: Final CFP: Real-Time Imaging J.

  *> From [email-masked] Thu Nov  2 19:54:41 1995
  *> Date: Fri, 3 Nov 95 04:49:15 +0100
  *> From: [email-masked] (Alberto Broggi)
  *> To: [email-masked]
  *> 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

Comments: Authenticated sender is <[email-masked]>
From: "Niall Downey" <[email-masked]>
Organization: Dept. Computer Science, UCD, IRL.
To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING"<[email-masked]>
Date: Fri, 3 Nov 1995 12:52:09 +0000
Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE
Reply-to: [email-masked]
CC: [email-masked]
Priority: normal

CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING

======================================================================

Comments: Authenticated sender is <[email-masked]>
From: "Niall Downey" <[email-masked]>
Organization: Dept. Computer Science, UCD, IRL.
To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING"<[email-masked]>
Date: Fri, 3 Nov 1995 15:05:14 +0000
Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE
Reply-to: [email-masked]
Priority: normal

CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING

-------------- Enclosure number 1 ----------------

Comments: Authenticated sender is <[email-masked]>
From: "Niall Downey" <[email-masked]>
Organization: Dept. Computer Science, UCD, IRL.
To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING"<[email-masked]>
Date: Fri, 3 Nov 1995 12:52:09 +0000
Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE
Reply-to: [email-masked]
CC: [email-masked]
Priority: normal

CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING

======================================================================

Comments: Authenticated sender is <[email-masked]>
From: "Niall Downey" <[email-masked]>
Organization: Dept. Computer Science, UCD, IRL.
To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING"<[email-masked]>
Date: Fri, 3 Nov 1995 15:03:41 +0000
Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE
Reply-to: [email-masked]
Priority: normal

CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING

-------------- Enclosure number 1 ----------------

Comments: Authenticated sender is <[email-masked]>
From: "Niall Downey" <[email-masked]>
Organization: Dept. Computer Science, UCD, IRL.
To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING"<[email-masked]>
Date: Fri, 3 Nov 1995 15:05:59 +0000
Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE
Reply-to: [email-masked]
Priority: normal

CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING

-------------- Enclosure number 1 ----------------

Comments: Authenticated sender is <[email-masked]>
From: "Niall Downey" <[email-masked]>
Organization: Dept. Computer Science, UCD, IRL.
To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING"<[email-masked]>
Date: Fri, 3 Nov 1995 15:05:15 +0000
Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE
Reply-to: [email-masked]
Priority: normal

CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING

-------------- Enclosure number 1 ----------------

Comments: Authenticated sender is <[email-masked]>
From: "Niall Downey" <[email-masked]>
Organization: Dept. Computer Science, UCD, IRL.
To: "CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING"<[email-masked]>
Date: Fri, 3 Nov 1995 15:01:37 +0000
Subject: CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINE
Reply-to: [email-masked]
Priority: normal

CFP: INTELLIGENCE AND INTEGRATION IN NETWORKS AND SERVICE ENGINEERING

Date: Fri, 3 Nov 95 04:49:15 +0100
From: [email-masked] (Alberto Broggi)
To: [email-masked]
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 [email-masked] or from 
[email-masked].

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: [email-masked]                  E-Mail: [email-masked]

Date: Tue, 26 Sep 1995 13:12:11 +0100
From: Sysadmin D <[email-masked]>
To: [email-masked]
Subject: test (you can delete this mail)

testing mailing list ...

From: [email-masked] (Rajiv Mehrotra)
Subject: no subject (file transmission)
To: [email-masked]
Date: Wed, 6 Sep 1995 09:23:21 -0045 (GMT-0:45)
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:   [email-masked]
     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:   [email-masked]
     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:   [email-masked]
     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:   [email-masked]
     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:   [email-masked]
     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:   [email-masked]
     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:   [email-masked]
     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: [email-masked]

==================

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: [email-masked]
   
===================

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

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" <[email-masked]>
Sender: "bhumip (b.) khasnabish" <[email-masked]>
Subject:  CFP (textFile): Workshop on Enterprise Networking (in ICC-96) 
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: [email-masked]
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)

To: [email-masked]
Subject: Please send me a reference in RFC1323
Date: Thu, 17 Aug 95 23:02:04 +0900
From: Tohru Asami <[email-masked]>
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: [email-masked]
KDD = an international telecommunication company in Japan

Date: Tue, 1 Aug 1995 16:12:40 -0700
From: Alex Pang <[email-masked]>
To: [email-masked]
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,  |
|          [email-masked]                                   |
+-------------------------------------------------------------------------+

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

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" <[email-masked]>
Sender: "bhumip (b.) khasnabish" <[email-masked]>
Subject:  CFP (textFile): Workshop on Enterprise Networking (in ICC-96) 
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: [email-masked]
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)

From: Thomas Auer <[email-masked]>
Date: Thu, 22 Jun 1995 11:37:55 +0200
To: [email-masked]
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. *
* [email-masked]  |    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:         [email-masked]
   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:
        <A HREF="http://www.cosy.sbg.ac.at/proms/">Proms on the WWW</A>

or contact:   Prof. Ulrich Hofmann [email-masked]
              Dr. Ilka Miloucheva [email-masked]

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 .... 

Date: Fri, 9 Jun 95 13:22:39 +0200
From: [email-masked] (Alberto Broggi)
To: [email-masked]
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 
[email-masked].

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: [email-masked]                  E-Mail: [email-masked]

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.

From: John Lee (EdCaad) <[email-masked]>
Date: Wed, 7 Jun 1995 15:53:34 +0100
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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:  [email-masked]
---------------------------------------------------------------------------

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" <[email-masked]>
Sender: "bhumip (b.) khasnabish" <[email-masked]>
Subject:  CFP - Workshop on 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: [email-masked]

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:[email-masked]

ComSoc Co-Ordinator:
.....................
Tom Stevenson (IEEE ComSoc HQ)
        Internet:[email-masked]

Committee Members:
...................
Majid Ahmadi (U of Windsor, Canada)
 	Internet:[email-masked] 
Salah Aidarous (BNR, Canada)
        Internet:[email-masked]
Robert S. Braudy (DMW Group, USA) 
        Internet:[email-masked]
Bob Fike (RNF Systems, USA)
        Internet:[email-masked]
David Kirsch (SunNetworks, USA)
        Internet:[email-masked]
Ken Lutz (BellCore, USA)
	[email-masked]
Branislav Meandzija (MetaAccess, USA)
        Internet:[email-masked]
Totumo Murase (NEC, Japan)
        Internet:[email-masked]
Toshihiro Sikama (Mitsubishi, Japan)
        Internet:[email-masked]
Karen Seo (BBN, USA)
        Internet:[email-masked]
Douglas N. Zuckerman (AT&T, USA)
        Internet:[email-masked]
Steven Weinstein (NEC, USA)
        Internet:[email-masked] 

===================================================================

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: [email-masked]                   |
o---------------------------------------o

Date: Mon, 3 Apr 1995 05:11:46 -0400
To: (Recipient list suppressed)
From: [email-masked] (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: [email-masked]

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
[email-masked]
--------
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

From: [email-masked]
Date: Mon, 27 Mar 95 21:16:11 EST
To: [email-masked]
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
[email-masked] for paper submission guidelines and cover sheet forms.

Please forward this message to friends, colleagues, or other interested
parties.

From: [email-masked]
Date: Wed, 22 Mar 95 11:58:07 EST
To: [email-masked]
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.

Date: Sun, 12 Mar 1995 23:51:11 -0500
From: Arif Ghafoor <[email-masked]>
Content-Length: 3048
Apparently-To: [email-masked]

                          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: [email-masked]
Tel: (317) 494-0638
Fax: (317) 494-6440

Ralf G. Herrtwich,
IBM Creative Multimedia Studios
Vangerowstrasse 18,
D-69115 Heidelberg, Germany
email: [email-masked]
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:  [email-masked]
Tel:  (212) 662-3864
Fax:  (212) 316-9068

Ian M Leslie
Computer Laboratory
University of Cambridge
email [email-masked]
Tel: +44 223 334658
Fax: +44 223 334678

From: [email-masked]
Date: Mon, 27 Feb 95 10:54:30 EST
To: [email-masked]
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/

Date: Tue, 14 Feb 1995 17:25:29 -0500 (EST)
From: Ken Vastola <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: "William C. Jennings" <[email-masked]>
Subject: Faculty Position at RPI
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                         [email-masked] 
  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 [email-masked]. Rensselaer is an affirmative action/equal 
opportunity employer and specifically encourages applications from women 
and minorities.

From: [email-masked] (Mark Boolootian)
Subject: Re: WANTED: Solaris implementation of RFC-1323
To: [email-masked] (Karl Jonas)
Date: Fri, 10 Feb 1995 10:41:19 -0800 (PST)
Cc: [email-masked]
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 <[email-masked]> 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		[email-masked]		+1 510 423 1948

To: [email-masked]
From: "Claudia Popien"  <[email-masked]>
Organization: Informatik IV - RWTH Aachen  
Date:     10 Feb 1995 10:49:58 GMT+1
Subject:  CfP: ICDP96 (Germany)
Priority: normal
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: [email-masked]

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: [email-masked]
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         [email-masked]
__________________________________________________________________

From: [email-masked] (Karl Jonas)
Date: Fri, 10 Feb 1995 08:42:53 +0100
To: [email-masked]
Subject: WANTED: Solaris implementation of RFC-1323
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: [email-masked]
-----------------------------------------------------

Date: Wed, 8 Feb 1995 16:01:27 +0100
From: Karl Jonas <[email-masked]>
Apparently-To: [email-masked]
Content-Length: 1

Date: Fri, 3 Feb 1995 10:54:07 GMT
From: John Lee <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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:  [email-masked]
---------------------------------------------------------------------------

From: "James P.G. Sterbenz" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: "James P.G. Sterbenz" <[email-masked]>
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: [email-masked]
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
[email-masked] and Cc: to [email-masked]), 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 [email-masked]; 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   [email-masked]

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   [email-masked]

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
[email-masked]                         Richard A. Thompson, Univ. of Pittsburgh
http://info.gte.com/jpgs                     Shukri Wakid, NIST

Date: Thu, 19 Jan 1995 18:53:00 -0800
To: Sandy McCrady <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Henning Schulzrinne <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "[email-masked]" <[email-masked]>, [email-masked], [email-masked]
From: [email-masked] (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
[email-masked]                                3031 Alhambra Dr, Suite 102
http://www.lloyd.com                           Cameron Park, CA  95682
(916) 676-1147 - voice                         (916) 676-3442 - fax

From: [email-masked]
Date: Thu, 19 Jan 95 21:00:30 EST
To: [email-masked]
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	 	
 [email-masked]		 
 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
 [email-masked]
 Phone: +1-603-646-3048.

VIDEOS CHAIR:				
 Gil Cruz, R. Hill		
 MRE-2B280		
 Bellcore				
 445 South Street		 
 Morristown, NJ 07960 USA	 
 {gil,[email-masked] 	 	 
 Phone: +1-201-829-5212		

DEMONSTRATIONS CHAIR:
 Tom Little
 Dept. of Elec. and Computer Engr.
 Boston University
 44 Cummington St.
 Boston, MA 02215 USA
 [email-masked]
 Phone: +1-617-353-9877

TUTORIALS CHAIR:			
 Sorel Reisman			 	
 Dept. of Management Science/Information Systems
 California State University	 
 Fullerton, CA 92634 USA	 	 	
 [email-masked] 	  	
 Phone: +1-714-773-3325		 

WORKSHOPS CHAIR:
 Ephraim Glinert
 Dept. of Computer Science
 R. P. I.
 Troy, NY 12180 USA
 [email-masked]
 Phone: +1-518-276-2657

EXHIBITS CHAIR:			
 Brent Hailpern			 
 IBM T.J. Watson Res. Ctr.	 
 30 Sawmill River Roada		 
 Hawthorne, NY 10532 USA	 	 
 [email-masked]		 
 Phone: +1-914-784-6821		 

EXHIBITOR INFORMATION:
 Don Collier
 DC Expositions, Inc.
 555 Republic Drive, Suite #316
 Plano, TX 75074 USA
 [email-masked]
 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
***************************************************************************

From: Ted Laliotis <[email-masked]>
Subject: Information Superhighway Conference
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 19 Jan 95 17:51:43 PST
Cc: [email-masked]
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: [email-masked]
 FAX: 408 973 1325

URL for World Wide Web access: http://www.hal.com/compcon

To Register for the conference:
 e-mail: [email-masked]
 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) [email-masked]
  Winfried W. Wilcke (General Chair) [email-masked]
  Ted Laliotis (Steering Committee Chair) [email-masked]

From: [email-masked]
Date: Thu, 19 Jan 1995 15:31:31 -0600
To: @[email-masked]
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
[email-masked]                    - Panel Discussions

From: [email-masked]
Via: uk.ac.edinburgh.cogsci; Thu, 19 Jan 1995 16:40:32 +0000
Date: Thu, 19 Jan 95 16:40:19 GMT
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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:  [email-masked]
    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:  [email-masked]
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/

To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: 7th IEEE LAN/MAN Workshop
Date: Thu, 19 Jan 95 09:29:59 -0800
From: Daniel Pitt <[email-masked]>
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: [email-masked]
                    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.

Date: 19 Jan 1995 09:11:34 U
From: "Sandy McCrady" <[email-masked]>
Subject: RE- client/server image sof
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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?

To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Henning Schulzrinne <[email-masked]>
Subject: Infocom'95
Date: Thu, 19 Jan 95 09:34:33 +0100
Sender: [email-masked]
Content-Length: 6

help

To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Infocom'95 Conference Program and Registration
Date: Wed, 18 Jan 95 19:09:30 +0100
From: Henning Schulzrinne <[email-masked]>
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: [email-masked]
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

Date: Fri, 23 Dec 1994 18:08:23 -0500
From: "Mark T. Maybury" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Intelligent Multimedia Information Retrieval
Content-Length: 5765

<<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  
<<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  
<<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  <<CALL FOR PAPERS>>  

   			   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.  [email-masked]

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 
  ([email-masked])
Bill Hefley, Software Engineering Institute, Carnegie Mellon Univ. 
  ([email-masked])
Peter Schauble, Swiss Federal Institute of Technology, Zurich 
  ([email-masked])
Alex "Sandy" Pentland, MIT Media Lab ([email-masked])
Stephen Smoliar, Inst of Systems Science, Univ Singapore, 0511 
  ([email-masked])
Oliviero Stock, IRST, Italy ([email-masked])
Wolfgang Wahlster, DFKI, Germany ([email-masked])
Kent Wittenburg, Bellcore ([email-masked])
Kazuo Tanaka, NTT, Japan ([email-masked])
Philippe Aigrain, IRIT, France ([email-masked])

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

----------------------------------------------------------------------

Date: Fri, 23 Dec 94 5:56:40 EST
From: Gerd Beling <[email-masked]>
To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked] (David A. Borman), [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng
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

From: [email-masked]
Date: Fri, 16 Dec 94 14:04:37 EST
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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

                [email-masked]

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

From: [email-masked]
Date: Wed, 14 Dec 94 17:05:19 EST
To: [email-masked]
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
[email-masked]		 	Hanover, NH 03755-3510 USA
Phone: +1-415-812-4426		 	[email-masked] 
				 	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,[email-masked] 	 		[email-masked] 
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
[email-masked] 	  	[email-masked]
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
[email-masked]		 	[email-masked]
Phone: +1-914-784-6821		 	Phone +1-214-423-4286

       1995 ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION

Date: Wed, 7 Dec 1994 23:10:29 -0800
From: [email-masked] (Erik Nordmark)
To: [email-masked]
Subject: Re: Some Thoughts on TCPng
Cc: [email-masked], [email-masked], [email-masked]
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

Date: Wed, 7 Dec 1994 18:20:10 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng
Cc: [email-masked], [email-masked], [email-masked]
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

To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng 
Date: 	Wed, 7 Dec 1994 15:13:44 PST
Sender: Steve Deering <[email-masked]>
From: Steve Deering <[email-masked]>
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

From: "Sean O'Malley" <[email-masked]>
Subject: Re: Some Thoughts on TCPng
To: [email-masked] (David A. Borman)
Date: Tue, 6 Dec 1994 16:08:09 -0700 (MST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
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

Date: Tue, 6 Dec 94 16:56:55 CST
From: [email-masked] (David A. Borman)
To: [email-masked]
Subject: Re: Some Thoughts on TCPng
Cc: [email-masked], [email-masked], [email-masked]
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, [email-masked]

From: "Sean O'Malley" <[email-masked]>
Subject: Re: Some Thoughts on TCPng
To: [email-masked] (David A. Borman)
Date: Tue, 6 Dec 1994 14:26:02 -0700 (MST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
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

To: "David A. Borman" <[email-masked]>
Cc: end2end-interest <[email-masked]>, nsrg <[email-masked]>, sean <[email-masked]>, tcplw <[email-masked]>
From: Robert Ullmann <[email-masked]>
Date:  6 Dec 94 15:19:29 ES
Subject: Re: Some Thoughts on TCPng
Content-Length: 24

You might read RFC1475.

Date: Tue, 6 Dec 94 13:11:38 CST
From: [email-masked] (David A. Borman)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Some Thoughts on TCPng
Content-Length: 16632

I'm including the [email-masked] 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, [email-masked]

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 [email-masked] Sat Dec  3 05:12 CST 1994
> Date: Fri, 2 Dec 1994 11:04:24 MST
> From: "Sean O'Malley" <[email-masked]>
> To: [email-masked], [email-masked]
> 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.
> 

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: rfc1323
Date: Fri, 18 Nov 1994 10:09:41 +0100
From: Andras Olah <[email-masked]>
Content-Length: 1044

> From: [email-masked] (Andre B Bondi +1 908 949 1921)
> Date: 15 Nov 94 15:15:00 GMT
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> 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 [email-masked] (and probably
[email-masked] 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

From: [email-masked]
Date: Thu, 17 Nov 1994 14:50:03 -0800
Posted-Date: Thu, 17 Nov 1994 14:50:03 -0800
To: [email-masked]
Subject: rfc1323
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 801

----- Begin Included Message -----

>From [email-masked] Tue Nov 15 09:44:00 1994
From: [email-masked] (Andre B Bondi +1 908 949 1921)
Date: 15 Nov 94 15:15:00 GMT
To: [email-masked]
Cc: [email-masked], [email-masked]
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 -----

Date: Wed, 9 Nov 94 15:42:57 EST
To: [email-masked]
From: [email-masked] (Judy Keller)
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: [email-masked]
Or to Bob Aaron at:
  telephone:  +1 407 687 2345
  fax:  +1 407 687 8739
  email:  [email-masked]
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:
[email-masked]
-- 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: [email-masked]
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.

Date: Mon, 7 Nov 1994 03:45:23 -0500
From: [email-masked] (Raj Jain, The Ohio State University)
To: [email-masked]
Subject: Address change [sent to @colleagues]
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: [email-masked]
Columbus, OH 43210-1277				Life-Time Email: [email-masked]

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: [email-masked],
ISBN: 0-201-56376-2, $49.95, 528 pages, 1994.

Thanks.

-Raj Jain

Date: 29 Sep 1994 08:33:51 -0500
From: "John Spragins" <[email-masked]>
Subject: Gigabit networking conferen
To: "Email Groups14" <[email-masked]>, "Email Groups15" <[email-masked]>, "Email Groups16" <[email-masked]>, "Email Groups17" <[email-masked]>, "Email Groups18" <[email-masked]>
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: [email-masked]

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.

Date: 28 Sep 1994 10:13:28 -0500
From: "John Spragins" <[email-masked]>
Return-Receipt-To: "John Spragins" <[email-masked]>
Subject: Gigabit networking conferen
To: "Email Groups1" <[email-masked]>, "Email Groups10" <[email-masked]>, "Email Groups11" <[email-masked]>, "Email Groups12" <[email-masked]>, "Email Groups13" <[email-masked]>, "Email Groups14" <[email-masked]>, "Email Groups15" <[email-masked]>, "Email Groups16" <[email-masked]>, "Email Groups17" <[email-masked]>, "Email Groups18" <[email-masked]>, "Email Groups19" <[email-masked]>, "Email Groups2" <[email-masked]>, "Email Groups20" <[email-masked]>, "Email Groups21" <[email-masked]>, "Email Groups22" <[email-masked]>, "Email Groups23" <[email-masked]>, "Email Groups24" <[email-masked]>, "Email Groups3" <[email-masked]>, "Email Groups4" <[email-masked]>, "Email Groups5" <[email-masked]>, "Email Groups6" <[email-masked]>, "Email Groups7" <[email-masked]>, "Email Groups8" <[email-masked]>, "Email Groups9" <[email-masked]>
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: [email-masked]

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.

To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: ACM Multimedia 94
Date: Wed, 07 Sep 1994 17:30:23 -0500
From: ACM Multimedia 94 <[email-masked]>
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

       [email-masked] or [email-masked]

=================****=================****=================****============

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.

=================****=================****=================****============

Date: Mon, 29 Aug 1994 09:32:14 -0700
From: [email-masked] (Bob Braden)
To: [email-masked]
Subject: RFC-1323 implementations
Cc: [email-masked]
Content-Length: 585

----- Begin Included Message -----

>From [email-masked] 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 <[email-masked]>
To: [email-masked]
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 -----

Date: Sun, 21 Aug 1994 23:31:54 -0700
From: NOSSDAV Workshop <[email-masked]>
To: [email-masked]
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
[email-masked]

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 [email-masked].

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.

Date: Thu, 18 Aug 1994 10:53:29 -0500
From: ACM Multimedia 94 <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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

       [email-masked] or [email-masked]

=================****=================****=================****============

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.

=================****=================****=================****============

From: [email-masked] (Stevo Bevo-Devo Wise)
To: [email-masked]
Subject: Re: checksum on move question 
Date: Tue, 02 Aug 94 18:00:47 -0600
Content-Length: 952

[email-masked] 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.

From: [email-masked]
To: Stevo Bevo-Devo Wise <[email-masked]>
Cc: [email-masked]
Subject: Re: checksum on move question 
Date: Tue, 02 Aug 94 18:52:09 -0400
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

From: [email-masked] (Stevo Bevo-Devo Wise)
To: [email-masked]
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:	[email-masked]
VNET:		AUSTIN(SWISE)

From: Zubin Dittia <[email-masked]>
Subject: ACM MULTIMEDIA 94 -- ADVANCE PROGRAM
To: [email-masked]
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)
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: [email-masked]
  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: [email-masked]
  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: [email-masked]
  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: [email-masked]

=================****=================****=================****============

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 [email-masked]. 

  * 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

       [email-masked] or [email-masked]

=================****=================****=================****============

Date: Tue, 17 May 1994 15:15:35 -0700
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re:  window scale option and urgent pointer
Cc: [email-masked]
Content-Length: 70

Dave,

Nice, cogent explanation! "Egad, Watson, elementary!"

Bob

Date: Tue, 17 May 94 16:50:32 CDT
From: [email-masked] (David A. Borman)
To: [email-masked], [email-masked], [email-masked]
Subject: Re:  window scale option and urgent pointer
Cc: [email-masked]
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 [email-masked] 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, [email-masked]

From: "Stephen C. Pope" <[email-masked]>
Date: Tue, 17 May 1994 10:06:44 -0600
To: [email-masked] (Stevo Bevo-Devo Wise)
Cc: [email-masked]
Subject: Congestion window & slow start threshold calculation
Reply-To: "Stephen C. Pope" <[email-masked]>
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.

From: [email-masked] (Stevo Bevo-Devo Wise)
To: [email-masked]
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:	[email-masked]
VNET:		AUSTIN(SWISE)

Date: Sun, 1 May 94 16:32:47 EDT
From: [email-masked] (Andreas Bovopoulos)
To: [email-masked], [email-masked], [email-masked], [email-masked]
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:[email-masked]

Date: Tue, 14 Dec 93 11:29:04 -0800
From: [email-masked] (Ron Lee)
Apparently-To: [email-masked]

index

Date: Fri, 5 Nov 1993 10:42:22 -0800
From: [email-masked] (Bob Braden)
To: [email-masked]
Subject: NTCP draft #1
Cc: [email-masked], [email-masked]

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

Date: Mon, 20 Sep 1993 15:28:02 +1000
To: [email-masked]
From: [email-masked] (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

Date: Tue, 27 Jul 93 13:55:45 CDT
From: [email-masked] (David A. Borman)
To: [email-masked]
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, [email-masked]

----------
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, [email-masked]

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, [email-masked]  (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, [email-masked]

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, [email-masked]

Sandia National Laboratories

	Contact: Doug Brown, [email-masked]  (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 [email-masked] 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, [email-masked] & [email-masked]

	Product: Patch to Sun OS 4.1

		Window Scale
		Timestamps w/ RTT calculations
		PAWS

	Status:
		Contact [email-masked] or [email-masked]

Sun Microsystems Computer Corporations

	Contact: Jim Fiori, [email-masked]

	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.

Date: Wed, 21 Jul 93 12:36:02 -0500
From: [email-masked] (David Borman)
To: [email-masked]
Subject: Re: TCPLW WG minutes
Cc: [email-masked], [email-masked]

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, [email-masked]

Date: Wed, 21 Jul 1993 09:01:46 -0700
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: TCPLW WG minutes
Cc: [email-masked], [email-masked]

  *> 
  *> 
  *> 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.
  *> 

Date: Wed, 21 Jul 93 10:54:30 CDT
From: [email-masked] (David A. Borman)
To: [email-masked]
Subject: TCPLW WG minutes
Cc: [email-masked], [email-masked]

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, [email-masked]

--------- 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.

To: David Borman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: TCPLW & Amsterdam IETF 
Date: Mon, 28 Jun 93 13:44:29 -0400
From: Megan Davies Walnut <[email-masked]>

Great,

Thanks Dave,

Megan

---------

Date: Thu, 24 Jun 93 20:29:57 -0500
From: David Borman <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: TCPLW & Amsterdam IETF
Cc: [email-masked], [email-masked], [email-masked]

> 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, [email-masked]

Date: Thu, 24 Jun 93 20:29:57 -0500
From: [email-masked] (David Borman)
To: [email-masked], [email-masked]
Subject: Re: TCPLW & Amsterdam IETF
Cc: [email-masked], [email-masked], [email-masked]

> 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, [email-masked]

To: IETF-Announce:;@CNRI.Reston.VA.US
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: ID ACTION:draft-ietf-tcplw-extensions-00.txt
Date: Thu, 24 Jun 93 10:00:32 -0400
Sender: [email-masked]

--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:  [email-masked]. In the body type: 
     "SEND draft-ietf-tcplw-extensions-00.txt".
							
For questions, please mail to [email-masked].

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="[email-masked]"

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--

Date: Tue, 22 Jun 1993 14:08:14 -0700
From: [email-masked] (Bob Braden)
To: [email-masked]
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

To: David Borman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: TCPLW & Amsterdam IETF 
Date: Tue, 22 Jun 93 13:15:56 -0400
From: Megan Davies Walnut <[email-masked]>

How does 1600-1800 on Wednesday sound?

Megan

---------------

To: [email-masked]
Subject: TCPLW & Amsterdam IETF
Cc: [email-masked], [email-masked], [email-masked]

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, [email-masked]

Date: Mon, 21 Jun 93 15:15:51 -0500
From: [email-masked] (David Borman)
To: [email-masked]
Subject: TCPLW & Amsterdam IETF
Cc: [email-masked], [email-masked], [email-masked]

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, [email-masked]

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re: rfc1323 question
Date: Wed, 19 May 93 19:40:13 GMT
Lines: 28

In article <[email-masked]>, [email-masked] 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     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

Date: Wed, 19 May 1993 10:59:53 -0700
From: [email-masked]
Posted-Date: Wed, 19 May 1993 10:59:53 -0700
To: [email-masked]
Subject: Re: rfc1323 question
Cc: [email-masked]

> From: [email-masked] (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     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

 
-- Liming Wei

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re: rfc1323 question
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:	[email-masked]
> VNET:		AUSVMQ(SWISE)

---
Thomas Skibo     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

Date: Thu, 13 May 93 14:36:47 -0700
From: [email-masked] (Thomas Skibo)
To: [email-masked]
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:	[email-masked]
> VNET:		AUSVMQ(SWISE)

---
Thomas Skibo     [email-masked]     Advanced Networking, Silicon Graphics, Inc.

From: [email-masked] (Stevo Bevo-Devo Wise)
To: [email-masked]
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:	[email-masked]
VNET:		AUSVMQ(SWISE)

Date: Mon, 26 Apr 1993 17:16:18 -0700
From: [email-masked] (Bob Braden)
To: [email-masked]
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.         <A,TSval=1,TSecr=120>         ------>       (1)

      2.  (127)  <-----      <X,ACK(A),TSval=127,TSecr=1>    (1)

      3.  (127)  <ACK(X),TSval=5,TSecr=127>    ------>       (5)

             . . . . . . . . . . . . . . . . . . . . . .

      4.  (127)  <B,ACK(X),TSval=65,TSecr=127> --->  ...

      5.            ... <--- <Y,ACK(A),TSval=191,TSecr=5>    (5)

      4'.               <B,ACK(X),TSval=65,TSecr=127> --->  (65)

      5'.  (191)  <-- <Y,ACK(A),TSval=191,TSecr=5>

      6.            ... <--- <Y,ACK(B),TSval=195,TSecr=65>  (65)

      7.  (191)  <B,ACK(Y),TSval=68,TSecr=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 <data + TCP options> 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) -

                                      <max IP option length>

          maxseg = maxoptdata - <size of 'normal' TCP options>

      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: [email-masked]

Braden                                                          [Page 9]


----- End Included Message -----

Date: Wed, 14 Apr 1993 12:43:05 -0700
From: [email-masked] (Bob Braden)
To: [email-masked]
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

Date: Wed, 31 Mar 93 17:56:54 CST
From: [email-masked] (David A. Borman)
To: [email-masked], [email-masked]
Subject: Mail archives

Ok, mail archives for "[email-masked]" and "[email-masked]"
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, [email-masked]

------
% 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 [email-masked]

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        ([email-masked])
        2) telnet-ietf  ([email-masked])

Please select an archive number ('q' to quit): 1
Parsing archive...
Mail archive for tcplw
135 messages, 321639 bytes

> 133 [email-masked]       Mar 25 11:40 1993   33/1229  "Re: TCP MSS & Timestam"
  134 [email-masked]       Mar 26 14:34 1993   41/1460  "RFC-1323 to Draft"
  135 [email-masked]       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.
%

Date: Fri, 26 Mar 1993 13:37:34 -0800
From: [email-masked] (Bob Braden)
To: [email-masked]
Subject: Re: TCP MSS & Timestamps
Cc: [email-masked]

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 = <maximum segment size we can send> - 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 (<Allowed to send TSopt>)
		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)
  }

Date: Fri, 26 Mar 1993 12:34:10 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked], [email-masked]
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

Date: Thu, 25 Mar 1993 09:39:59 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
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

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re: 1323 question
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: [email-masked]
> Posted-Date: Thu, 14 May 92 16:52:37 PDT
> Message-Id: <[email-masked]>
> Received: by braden.isi.edu (4.1/4.0.3-4)
> 	id <AA13866>; Thu, 14 May 92 16:52:37 PDT
> To: [email-masked]
> Subject: Re:  Does PAWS work for duplicate ACKs in uni-directional connections?
> Cc: [email-masked]
> Status: R
> 
> 
> 	From [email-masked] Wed May 13 11:51:34 1992
> 	Date: Wed, 13 May 92 13:51:28 -0500
> 	From: Thomas Skibo <[email-masked]>
> 	To: [email-masked]
> 	Subject: Does PAWS work for duplicate ACKs in uni-directional connections?
> 	Cc: [email-masked]
> 
> 	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.
> 	[email-masked]	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

Date: Tue, 16 Mar 93 19:21:44 -0800
From: [email-masked] (Thomas Skibo)
To: [email-masked] (Bob Braden)
Subject: Re: 1323 question
Cc: [email-masked]

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: [email-masked]
> Posted-Date: Thu, 14 May 92 16:52:37 PDT
> Message-Id: <[email-masked]>
> Received: by braden.isi.edu (4.1/4.0.3-4)
> 	id <AA13866>; Thu, 14 May 92 16:52:37 PDT
> To: [email-masked]
> Subject: Re:  Does PAWS work for duplicate ACKs in uni-directional connections?
> Cc: [email-masked]
> Status: R
> 
> 
> 	From [email-masked] Wed May 13 11:51:34 1992
> 	Date: Wed, 13 May 92 13:51:28 -0500
> 	From: Thomas Skibo <[email-masked]>
> 	To: [email-masked]
> 	Subject: Does PAWS work for duplicate ACKs in uni-directional connections?
> 	Cc: [email-masked]
> 
> 	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.
> 	[email-masked]	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

Date: Tue, 16 Mar 1993 17:06:34 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
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

Date: Mon, 15 Mar 93 17:26:39 -0600
From: [email-masked] (David Borman)
To: [email-masked], [email-masked], [email-masked]
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, [email-masked]

> From [email-masked] Mon Mar 15 15:24:27 1993
> Date: Mon, 15 Mar 1993 13:24:33 -0800
> From: [email-masked] (Bob Braden)
> To: [email-masked], [email-masked]
> 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

Date: Mon, 15 Mar 1993 13:24:33 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
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

Date: Mon, 15 Mar 93 14:39:58 CST
From: [email-masked] (David A. Borman)
To: [email-masked]
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
            <A, TSval=1> ------------------->
                                                  1
 (lost)              <---- <ACK(A), TSecr=1>

 (ReXmit)   <A, TSval=4> ------------------->
                                                  ???
                     <---- <ACK(A), TSecr=???>

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.)

Date: Mon, 1 Feb 1993 10:43:28 -0800
From: [email-masked] (Bob Braden)
To: [email-masked]
Subject: Question RFC-1323 experience
Cc: [email-masked]

----- Begin Included Message -----

To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: End to end list and other questions.
Date: Mon, 01 Feb 93 10:44:01 -0500
From: [email-masked]
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 -----

Date: Fri, 22 Jan 1993 11:21:44 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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

Date: Thu, 21 Jan 1993 08:43:12 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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

From: [email-masked] (C. Douglas Brown)
Subject: Re: slow start and large windows
To: [email-masked]
Date: Wed, 20 Jan 93 13:41:13 MST

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 ([email-masked])
Sandia National Labs
Albuquerque, NM

Date: Tue, 19 Jan 1993 10:20:26 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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 

Date: Tue, 19 Jan 1993 08:51:02 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: correction
Cc: [email-masked], [email-masked]

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

To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: correction 
Date: Tue, 19 Jan 93 13:46:33 +0100
From: Christian Huitema <[email-masked]>

>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

To: Sean O'Malley <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: slow start and large windows
Date: Tue, 19 Jan 93 11:05:05 +0000
From: Zheng Wang <[email-masked]>

 >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

To: [email-masked] (partho pratim mishra)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: slow start and large windows 
Date: Tue, 19 Jan 93 08:56:27 +0100
From: Christian Huitema <[email-masked]>

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

Date: Mon, 18 Jan 1993 16:55:55 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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

Date: Mon, 18 Jan 1993 16:14:32 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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

Date: Mon, 18 Jan 93 16:30:19 -0500
From: [email-masked] (partho pratim mishra)
To: [email-masked], [email-masked]
Subject: Re: slow start and large windows
Cc: [email-masked]

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.

To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: slow start and large windows 
Date: Mon, 18 Jan 93 16:24:55 -0500
From: Partho Mishra <[email-masked]>

> 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

From: [email-masked] (Sally Floyd)
To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
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

____

Date: Mon, 18 Jan 1993 13:02:23 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: slow start and large windows
Cc: [email-masked], [email-masked]

> 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

Date: Mon, 18 Jan 1993 13:41:12 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: slow start and large windows
Cc: [email-masked], [email-masked]

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). 

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re:  slow start and large windows
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     [email-masked]

Date: Mon, 18 Jan 1993 11:48:17 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: slow start and large windows
Cc: [email-masked], [email-masked]

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

Date: Mon, 18 Jan 93 11:36:03 -0800
From: [email-masked] (Thomas Skibo)
To: "Sean O'Malley" <[email-masked]>
Subject: Re:  slow start and large windows
Cc: [email-masked]

> 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     [email-masked]

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: slow start and large windows 
Date: Mon, 18 Jan 93 14:16:03 -0500
From: Partho Mishra <[email-masked]>

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

Date: Mon, 18 Jan 1993 11:31:24 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
Subject: slow start and large windows
Cc: [email-masked], [email-masked]

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++.

Date: Thu, 7 Jan 1993 13:24:27 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
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

From: [email-masked] (Stevo Bevo-Devo Wise)
To: [email-masked]
Subject: Re: TCP MSS & Timestamps 
Date: Thu, 07 Jan 93 14:50:10 -0600

[email-masked] 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.

Date: Thu, 7 Jan 1993 12:36:01 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
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

Date: Thu, 7 Jan 1993 14:12:12 -0600
From: [email-masked] (David A. Borman)
To: [email-masked]
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, [email-masked]

To: "Sean O'Malley" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SACK 
Date: Wed, 06 Jan 93 09:59:15 -0500
From: Christian Huitema <[email-masked]>

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

Date: Tue, 5 Jan 1993 11:49:51 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
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

Date: Tue, 5 Jan 1993 09:38:46 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: SACK

> From [email-masked] Tue Jan  5 08:53:39 1993
> Date: Tue, 5 Jan 1993 09:54:32 MST
> From: "Sean O'Malley" <[email-masked]>
> To: [email-masked]
> 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

Date: Tue, 5 Jan 1993 09:54:32 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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

Subject: Re: 50000 connections and gigabit speeds
To: [email-masked] (Rob Warnock)
Date: Fri, 18 Dec 92 8:57:57 CST
Cc: [email-masked]
From: [email-masked]

> 
> 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

To: [email-masked]
Reply-To: [email-masked] (Rob Warnock)
From: [email-masked] (Rob Warnock)
Subject: Re: 50000 connections and gigabit speeds
Date: Fri, 18 Dec 1992 07:08:14 GMT

[email-masked] 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		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

To: [email-masked]
Reply-To: [email-masked] (Rob Warnock)
From: [email-masked] (Rob Warnock)
Subject: Re: 50000 connections and gigabit speeds
Date: Fri, 18 Dec 1992 06:59:08 GMT

[email-masked] 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		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Date: Thu, 17 Dec 92 23:02:14 -0800
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: 50000 connections and gigabit speeds
Cc: [email-masked]

[email-masked] 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		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Date: Thu, 10 Dec 1992 14:24:10 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: 1323 implementations

> 
> 	Name: _____________Bob Braden, Liming Wei_____________
> 
> 	Organization: _____Information Sciences Institute (ISI)
> 
> 	Email/Phone: [email-masked], [email-masked]
> 
> 	[   ] 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: _______________________________________
> 
> 		____________________________________________________
> 

Date: Tue, 8 Dec 1992 15:07:40 -0600
From: [email-masked] (David A. Borman)
To: [email-masked]
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, [email-masked]

-------- Cut here and return to [email-masked] -----------

	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: [email-masked] (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.

Date: Mon, 7 Dec 92 11:01:14 MST
From: [email-masked] (C. Douglas Brown)
To: [email-masked]
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

Subject: Re: 50000 connections and gigabit speeds
To: [email-masked] (Rob Warnock)
Date: Fri, 4 Dec 92 10:06:58 CST
Cc: [email-masked]
From: [email-masked]

> 
> [email-masked] 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 [email-masked],
> now [email-masked]]. 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		[email-masked]
> Silicon Graphics, Inc.		(415)390-1673
> 2011 N. Shoreline Blvd.
> Mountain View, CA  94043
> 
> 
> 
> 
> 

To: [email-masked]
Reply-To: [email-masked] (Rob Warnock)
From: [email-masked] (Rob Warnock)
Subject: Re: 50000 connections and gigabit speeds
Date: Sun, 29 Nov 1992 02:50:30 GMT

[email-masked] 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 [email-masked],
now [email-masked]]. 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		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Date: Sat, 28 Nov 92 18:48:52 -0800
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: 50000 connections and gigabit speeds
Cc: [email-masked]

[email-masked] 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 [email-masked],
now [email-masked]]. 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		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Subject: Re: 50000 connections and gigabit speeds
To: [email-masked]
Date: Mon, 16 Nov 92 8:30:12 CST
From: [email-masked]

> > 
> > 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

Date: Fri, 13 Nov 1992 16:20:05 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: PCB's and Timestamps
Cc: [email-masked]

(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 [email-masked] Thu Sep  3 11:49:56 1992
> Date: Thu, 3 Sep 1992 11:49:04 MST
> From: "Sean O'Malley" <[email-masked]>
> To: [email-masked]
> Subject: PCB's and Timestamps
> Cc: [email-masked]
> 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 
> 
>   
> 

Date: Fri, 13 Nov 1992 16:07:28 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: eliminate TCP input demuxing
Cc: [email-masked]

> From [email-masked] Thu Sep  3 06:06:54 1992
> From: [email-masked] (Steve Wise)
> To: [email-masked] (William E. Fisher)
> Cc: [email-masked], [email-masked]
> Subject: Re: eliminate TCP input demuxing 
> In-Reply-To: Your message of Wed, 02 Sep 92 18:41:29 PDT.
>              <[email-masked]> 
> 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

To: [email-masked] (Steve Wise)
Cc: [email-masked] (Thomas Skibo), [email-masked]
Subject: Re: Source Code 
Date: Thu, 15 Oct 92 09:02:49 -0500
From: Christian Huitema <[email-masked]>

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.

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re: Source Code
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...

> 
> 
> [email-masked] 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
[email-masked]

Date: Wed, 14 Oct 92 10:41:47 -0700
From: [email-masked] (Thomas Skibo)
To: [email-masked] (Steve Wise)
Subject: Re: Source Code
Cc: [email-masked]

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...

> 
> 
> [email-masked] 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
[email-masked]

From: [email-masked] (Steve Wise)
To: [email-masked] (Thomas Skibo)
Cc: [email-masked]
Subject: Re: Source Code 
Date: Wed, 14 Oct 92 10:09:15 -0600

[email-masked] 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.

From: [email-masked] (Gary Friedman)
Subject: subscribe
To: [email-masked]
Date: Tue, 29 Sep 92 15:29:50 PDT

Subscribe

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re:  Source Code
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
[email-masked]

Date: Tue, 29 Sep 92 14:21:58 -0700
From: [email-masked] (Thomas Skibo)
To: "Sean O'Malley" <[email-masked]>
Subject: Re:  Source Code
Cc: [email-masked]

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
[email-masked]

Date: Tue, 29 Sep 1992 13:29:47 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
Subject: Source Code

Is there a version of the extended TCP available by ftp?

(Preferablty a BSD version)

Sean O'Malley

Date: Tue, 15 Sep 92 13:01:08 PDT
From: [email-masked] (Wayne Hathaway)
To: [email-masked]
Subject: Re: eliminate TCP input demuxing

Christian Huitema <[email-masked]> 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: [email-masked]
    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.

Date: Tue, 15 Sep 92 12:57:44 PDT
From: [email-masked] (Wayne Hathaway)
To: [email-masked]
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: [email-masked]
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134              FAX: 408-433-9287

To: [email-masked] (Wayne Hathaway)
Cc: [email-masked]
Subject: Re: eliminate TCP input demuxing 
Date: Mon, 14 Sep 92 14:37:46 -0400
From: Christian Huitema <[email-masked]>

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

To: [email-masked]
Reply-To: [email-masked] (Vernon Schryver)
From: [email-masked] (Vernon Schryver)
Subject: Re: eliminate TCP input demuxing
Date: Sun, 13 Sep 1992 05:09:31 GMT

[email-masked] (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,  [email-masked]

Date: Sat, 12 Sep 92 10:44:05 PDT
From: [email-masked] (Wayne Hathaway)
To: [email-masked]
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: [email-masked]
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134              FAX: 408-433-9287

Date: Fri, 4 Sep 92 11:59:33 -0700
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: TCP demultiplexing

[email-masked] 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          [email-masked]
Silicon Graphics, Inc.          (415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Date: Fri, 4 Sep 92 11:50:34 -0700
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: eliminate TCP input demuxing

[email-masked] (Vernon Schryver) writes:
+---------------
| [email-masked] (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		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Subject: Re: eliminate TCP input demuxing
To: [email-masked]
Date: Fri, 4 Sep 92 8:48:45 CDT
From: [email-masked]

> 
> In article <[email-masked]>, [email-masked] (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

Date: Thu, 3 Sep 1992 11:49:04 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
Subject: PCB's and Timestamps
Cc: [email-masked]

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 

To: [email-masked]
Reply-To: [email-masked] (Vernon Schryver)
Control: cancel <[email-masked]>
From: [email-masked] (Vernon Schryver)
Subject: cmsg cancel <[email-masked]>
Date: Thu, 3 Sep 1992 17:13:03 GMT
Approved: [email-masked]

cancel <[email-masked]>

To: [email-masked]
Reply-To: [email-masked] (Vernon Schryver)
From: [email-masked] (Vernon Schryver)
Subject: Re: eliminate TCP input demuxing
Date: Thu, 3 Sep 1992 17:12:54 GMT

In article <[email-masked]>, [email-masked] (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,   [email-masked]					(retrans #3)

To: [email-masked]
Reply-To: [email-masked] (Vernon Schryver)
Control: cancel <[email-masked]>
From: [email-masked] (Vernon Schryver)
Subject: cmsg cancel <[email-masked]>
Date: Thu, 3 Sep 1992 17:11:24 GMT
Approved: [email-masked]

cancel <[email-masked]>

Date: Thu, 3 Sep 1992 09:51:10 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked], [email-masked]
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?

Subject: TCP demultiplexing
To: [email-masked]
Date: Thu, 3 Sep 92 9:53:00 CDT
From: [email-masked]

>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

From: Christopher Maeda <[email-masked]>
Date: Thu, 3 Sep 92 09:36:52 EDT
To: [email-masked]
Cc: [email-masked]
Subject: eliminate TCP input demuxing 
Reply-To: [email-masked]

   From: [email-masked] (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

From: [email-masked] (Steve Wise)
To: [email-masked]
Cc: [email-masked]
Subject: Re: eliminate TCP input demuxing 
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.	

From: [email-masked] (Steve Wise)
To: [email-masked] (William E. Fisher)
Cc: [email-masked], [email-masked]
Subject: Re: eliminate TCP input demuxing 
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...

From: [email-masked] (William E. Fisher)
Subject: Re: eliminate TCP input demuxing
To: [email-masked] (Steve Wise)
Date: Wed, 2 Sep 92 18:41:29 PDT
Cc: [email-masked], [email-masked], [email-masked]

>  
> | 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 [email-masked], to the tcp-ip mailing list, December 1991

2) Lance Visser. Re: Inefficient dfemultiplexing by 4.3 TCP/IP
   Message-ID [email-masked] 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

From: Christopher Maeda <[email-masked]>
Date: Wed, 2 Sep 92 21:09:11 EDT
To: [email-masked]
Cc: [email-masked]
Subject: eliminate TCP input demuxing
Reply-To: [email-masked]

   From: [email-masked] (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

From: [email-masked] (Steve Wise)
To: [email-masked] (Jim Hughes)
Cc: [email-masked]
Subject: Re: eliminate TCP input demuxing 
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.

From: [email-masked] (Jim Hughes)
Subject: Re: eliminate TCP input demuxing
To: [email-masked] (Steve Wise)
Date: Wed, 2 Sep 92 19:16:57 EDT
Cc: [email-masked]

> 
> 
> 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

From: [email-masked] (Steve Wise)
To: [email-masked]
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: 	[email-masked]
VNET:		AUSVMQ(SWISE)
Internet:	[email-masked]

From: [email-masked] (Steve Wise)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Modified TCP congestion avoidance algorithm 
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
| 

Date: Tue, 18 Aug 1992 16:56:47 -0700
From: [email-masked]
Posted-Date: Tue, 18 Aug 1992 16:56:47 -0700
To: [email-masked], [email-masked]
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

From: [email-masked] (Steve Wise)
To: [email-masked]
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: 	[email-masked]
VNET:		AUSVMQ(SWISE)
Internet:	[email-masked]

Date: Mon, 6 Jul 92 21:41:43 -0700
From: [email-masked] (Thomas Skibo)
To: [email-masked]
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.
[email-masked]

Date: Mon, 22 Jun 92 11:13:29 -0500
From: [email-masked] (David A. Borman)
To: [email-masked]
Subject: second message

And here's a follow-up message that also got bounced by
our mail gateway...
			-David Borman, [email-masked]

Date: Mon, 22 Jun 92 11:09:41 -0500
From: [email-masked] (David A. Borman)
To: [email-masked]
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, [email-masked]

From: [email-masked] (Jim Hughes)
Subject: Re: Checksumming on TCP
To: [email-masked] (Van Jacobson)
Date: Mon, 22 Jun 92 9:06:59 EDT
Cc: [email-masked], [email-masked]
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

From: [email-masked] (Jim Hughes)
Subject: Re: Checksumming on TCP
To: [email-masked] (Van Jacobson)
Date: Mon, 22 Jun 92 9:06:59 EDT
Cc: [email-masked], [email-masked]

> 
> > 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: [email-masked] (Jim Hughes)
Cc: [email-masked] (Steve Wise), [email-masked]
Subject: Re: Checksumming on TCP
Date: Mon, 22 Jun 92 04:01:35 PDT
From: Van Jacobson <[email-masked]>

> 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

To: [email-masked] (Jim Hughes)
Cc: [email-masked] (Steve Wise), [email-masked]
Subject: Re: Checksumming on TCP
Date: Mon, 22 Jun 92 04:01:35 PDT
From: Van Jacobson <[email-masked]>

> 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

Date: Fri, 19 Jun 92 13:09:40 -0600
From: [email-masked] (Vernon Schryver)
To: [email-masked], [email-masked]
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,  [email-masked]

Date: Fri, 19 Jun 92 13:29:08 CDT
From: [email-masked] (Randy Butler)
To: [email-masked], [email-masked]
Subject: Re: Checksumming on TCP
Cc: [email-masked]

>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

From: [email-masked] (Jim Hughes)
Subject: Re: Checksumming on TCP
To: [email-masked] (Steve Wise)
Date: Fri, 19 Jun 92 14:16:04 EDT
Cc: [email-masked], [email-masked]

> 
> 
> | 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

From: [email-masked] (Steve Wise)
To: Craig Partridge <[email-masked]>
Cc: [email-masked]
Subject: Re: Checksumming on TCP 
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.

To: [email-masked] (Steve Wise)
Cc: [email-masked]
Cc: [email-masked]
Subject: re: Checksumming on TCP
Reply-To: Craig Partridge <[email-masked]>
From: Craig Partridge <[email-masked]>
Date: Fri, 19 Jun 92 09:32:28 -0700
Sender: [email-masked]

> 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
[email-masked]

From: [email-masked] (Steve Wise)
To: [email-masked]
Cc: [email-masked]
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: 	[email-masked]
VNET:		AUSVMQ(SWISE)
Internet:	[email-masked]

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: [email-masked]
X400-Recipients: [email-masked]
X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;920605114021]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 3369
From: [email-masked]
To: [email-masked] (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     [email-masked]
      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

Date: Mon, 18 May 92 11:36:58 EDT
From: [email-masked] (Jim Fiori - Special Projects)
To: [email-masked]
Subject: mailing list

Can I be placed in this mailing list please?

Thanks

Date: Fri, 15 May 92 12:30:08 EDT
From: [email-masked] (Jim Fiori - Special Projects)
To: [email-masked]
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

Date: Thu, 14 May 92 20:44:11 -0500
From: Thomas Skibo <[email-masked]>
To: [email-masked]
Subject: Second revision of BSD implementation of RFC 1323 extensions now available.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

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.
[email-masked]	ph: 217-333-7937

Date: Thu, 14 May 92 16:52:37 PDT
From: [email-masked]
Posted-Date: Thu, 14 May 92 16:52:37 PDT
To: [email-masked]
Subject: Re:  Does PAWS work for duplicate ACKs in uni-directional connections?
Cc: [email-masked]

	From [email-masked] Wed May 13 11:51:34 1992
	Date: Wed, 13 May 92 13:51:28 -0500
	From: Thomas Skibo <[email-masked]>
	To: [email-masked]
	Subject: Does PAWS work for duplicate ACKs in uni-directional connections?
	Cc: [email-masked]

	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.
	[email-masked]	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

Date: Wed, 13 May 92 15:40:55 EDT
From: [email-masked] (Fred Bohle)
To: [email-masked], [email-masked]
Subject: Re:  TCP Large Window Implem. at Sandia
Cc: [email-masked]

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: [email-masked]
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

Date: Wed, 13 May 92 13:51:28 -0500
From: Thomas Skibo <[email-masked]>
To: [email-masked]
Subject: Does PAWS work for duplicate ACKs in uni-directional connections?
Cc: [email-masked]

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.
[email-masked]	ph: 217-333-7937

Date: Wed, 13 May 92 13:25:19 -0500
From: Thomas Skibo <[email-masked]>
To: [email-masked]
Subject: Re:  TCP Large Window Implem. at Sandia
Cc: [email-masked]

> 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.
[email-masked]	ph: 217-333-7937

Date: Wed, 13 May 92 11:28:25 MDT
From: [email-masked] (Nov-C. Douglas Brown)
To: [email-masked]
Subject: TCP Large Window Implem. at Sandia
Cc: [email-masked]

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?:

Date: Fri, 10 Apr 92 12:54:45 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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

Date: Fri, 10 Apr 92 12:21:20 PDT
From: [email-masked]
Posted-Date: Fri, 10 Apr 92 12:21:20 PDT
To: [email-masked], [email-masked]
Subject: Re:  Bradens PAWS bug

	From [email-masked] Fri Apr 10 09:35:14 1992
	Date: Fri, 10 Apr 92 09:33:39 MST
	From: "Sean O'Malley" <[email-masked]>
	To: [email-masked]
	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

Date: Fri, 10 Apr 92 09:33:39 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

  3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK

  5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED

 - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  5.1. TIME-WAIT   <--  <SEQ=255><ACK=33> ... old duplicate

  5.2  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>    -->  ????

  5.3  CLOSED      <-- <SEQ=301><CTL=RST>             <--  ????

 - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  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.  --> <SEQ=400><ACK=101><DATA=100><CTL=ACK> -->  ESTABL.
 
 2. ESTABL.  <--     <SEQ=101><ACK=500><CTL=ACK>     <--    ESTABL.

 3.  (old dupl)...<SEQ=560><ACK=101><DATA=80><CTL=ACK> -->  ESTABL.

 4. ESTABL.  <--     <SEQ=101><ACK=500><CTL=ACK>     <--    ESTABL.
 
 5. ESTABL.  --> <SEQ=500><ACK=101><DATA=100><CTL=ACK> -->  ESTABL.

 6.             ...  <SEQ=101><ACK=640><CTL=ACK>     <--    ESTABL.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
 
 7a. ESTABL.  --> <SEQ=600><ACK=101><DATA=100><CTL=ACK> -->  ESTABL.
 
 8a. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK> ...

 9a. ESTABL.  --> <SEQ=700><ACK=101><DATA=100><CTL=ACK> -->  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    --> <SEQ=100><CTL=SYN>                  --> SYN-RECEIVED

  3.         ... <SEQ=400><ACK=101><CTL=SYN,ACK><WIN=800> <-- SYN-RECEIVED

  4.  SYN-SENT    <-- <SEQ=300><ACK=123><CTL=ACK> ... (old duplicate)

  5.  SYN-SENT    --> <SEQ=123><CTL=RST>                    --> LISTEN
  
  6.  ESTABLISHED  <-- <SEQ=400><ACK=101><CTL=SYN,ACK><W=900> ...

  7.  ESTABLISHED  --> <SEQ=101><ACK=401><CTL=ACK>          --> LISTEN

  8.  CLOSED      <--  <SEQ=401><CTL=RST>                   <-- 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.,
<SEQ=123> 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.  <--    <SEQ=101><ACK=640><CTL=ACK>   ...
(ACK something not yet
 sent => send ACK)

 8b. ESTABL.  -->    <SEQ=600><ACK101><CTL=ACK>       -->   ESTABL.
                                                      (Below window =>
                                                       send ACK)

 9b. ESTABL.  <--    <SEQ=101><ACK=640><CTL=ACK>     <--    ESTABL.

                          (etc.!)

                Figure 4: Infinite ACK loop
___________________________________________________________________

Date: Wed, 25 Mar 92 10:34:36 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked], [email-masked]
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.

Date: Wed, 25 Mar 92 09:30:20 GMT
From: [email-masked] (Rob Warnock)
To: [email-masked]
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		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

Date: Wed, 25 Mar 92 07:13:23 GMT
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: SACK vs. TCMP
Cc: [email-masked]

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		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

To: [email-masked]
Subject: is end2end-interest list dead/moved?

Dear [email-masked]:

I sent the following to <[email-masked]>, and it bounced.
Has this list moved or been renamed?

-Rob

+------ attachment ---------
| From [email-masked]  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 [email-masked] id AA09050; Tue, 24 Mar 92 23:06:45 -0800
| Received: by sgi.sgi.com (911016.SGI/910110.SGI)
| 	for [email-masked] id AA01361; Tue, 24 Mar 92 23:06:31 -0800
| Date: Tue, 24 Mar 92 23:06:31 -0800
| From: [email-masked] (Mail Delivery Subsystem)
| Subject: Returned mail: Service unavailable
| Message-Id: <[email-masked]>
| To: rpw3
| Status: R
| 
|    ----- Transcript of session follows -----
| While talking to isi.edu:
| >>> RCPT To:<[email-masked]>
| <<< 554 :include:/div7/iab/end2end-interest.list... Cannot open /div7/iab/end2end-interest.list: No such file or directory
| 554 <@sgi.sgi.com:[email-masked]>... Service unavailable
| 
|    ----- Unsent message follows -----
| Received: from [192.26.75.58] by sgi.sgi.com via SMTP (911016.SGI/910110.SGI)
| 	for [email-masked] id AA01360; Tue, 24 Mar 92 23:06:31 -0800
| Received: by rigden.wpd.sgi.com (911016.SGI/911001.SGI)
| 	for @sgi.sgi.com:[email-masked] id AA11917; Wed, 25 Mar 92 07:06:29 GMT
| Date: Wed, 25 Mar 92 07:06:29 GMT
| From: [email-masked] (Rob Warnock)
| Message-Id: <[email-masked]>
| To: [email-masked]
| Subject: SACK vs. TCMP
| Cc: [email-masked]
| 
| 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		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

Date: Tue, 24 Mar 92 21:04:13 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked]
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        

Date: Sun, 8 Mar 92 22:04:37 -0600
From: Thomas Skibo <[email-masked]>
To: [email-masked]
Subject: TCP Extensions Implementation on 4.3 BSD NR2
Cc: [email-masked], [email-masked], [email-masked]

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		[email-masked]	ph: 217-333-7937

Date: Tue, 25 Feb 92 09:28:55 CST
From: dab@hemlock (David Borman)
To: [email-masked]
Subject: FYI: Last Call

This is for the revised document, draft-ietf-tcplw-tcpext-02.txt
			-David Borman, [email-masked]

To: IETF <[email-masked]>
Cc: [email-masked]
From: IESG Secretary <[email-masked]>
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 [email-masked], or [email-masked] mailing lists by March
5th.

Greg Vaudreuil
IESG Secretary

Date: Fri, 14 Feb 92 09:55:45 PST
From: [email-masked]
Posted-Date: Fri, 14 Feb 92 09:55:45 PST
To: [email-masked]
Subject: Progress...
Cc: [email-masked]

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

Date: Wed, 5 Feb 92 04:58:07 GMT
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: What to do???
Cc: [email-masked], [email-masked]

In the TCPLW mailing list, [email-masked] (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		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

Date: Thu, 30 Jan 92 17:55:41 EST
From: [email-masked] (Fred Bohle)
To: dab
Subject: Re:  SACK option
Cc: [email-masked]

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: [email-masked]
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

Date: Thu, 30 Jan 92 15:22:56 CST
From: dab@hemlock (David Borman)
To: [email-masked]
Subject: SACK option
Cc: [email-masked]

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, [email-masked]

Date: Mon, 27 Jan 92 17:29:36 -0500
From: [email-masked] (Jim DeMarco)
To: dab
Cc: [email-masked]
Subject: What to do???
Reply-To: [email-masked]

>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                                   [email-masked]

Date: Mon, 27 Jan 92 12:46:06 -0500
From: [email-masked] (Olafur Gudmundsson)
To: [email-masked]
Subject: Re: SACK option
Cc: [email-masked]

 > 
 > 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, [email-masked]

-	-	-	-	-	-	-	-	-
Olafur Gudmundsson  Dept. of Computer Science University of Maryland
Internet: [email-masked]               UUCP: {...!}uunet!mimsy!ogud
UPS: College Park MD. 20742             Tel: (301)-405-2767 FAX:6707

Date: Mon, 27 Jan 92 10:10:30 CST
From: dab@hemlock (David Borman)
To: [email-masked]
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, [email-masked]

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...

Subject: What to do?
To: [email-masked]
Date: Fri, 24 Jan 92 9:21:42 CST
From: [email-masked]

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

Date: Thu, 23 Jan 92 17:25:54 CST
From: dab@hemlock (David Borman)
To: [email-masked]
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, [email-masked]

To: [email-masked] (David Borman)
Cc: [email-masked]
Subject: Re: SACK option 
Date: Tue, 21 Jan 92 09:33:11 +0000
From: Christian Huitema <[email-masked]>

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...

Date: Mon, 20 Jan 92 17:10:44 MST
From: "Sean O'Malley" <[email-masked]>
To: [email-masked], [email-masked]
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

Date: Mon, 20 Jan 92 17:22:53 -0600
From: [email-masked] (David Borman)
To: [email-masked]
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, [email-masked]

> From [email-masked] Fri Jan 10 17:59:10 1992
> To: [email-masked]
> Subject: SACK
> Cc: [email-masked]
> 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, [email-masked]
> 

Date: Thu, 9 Jan 92 03:52:31 CST
From: [email-masked] (Zubin Dittia)
To: [email-masked], [email-masked]
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.

Date: Tue, 31 Dec 91 13:52:59 -0800
From: [email-masked] (the dirty vicar)
To: [email-masked]
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                         [email-masked] | In girum imus
NASA Ames Research Center     ...ames!nas.nasa.gov!dji | nocte et
Numerical Aerodynamic Simulation / Systems Development | consumimur igni

To: [email-masked]
Subject: Re: TCP LW mailing list 
Date: Mon, 30 Dec 91 13:31:52 -0800
From: [email-masked]

Hi!  Please sign up <[email-masked]>.  Thanks.

Date: Mon, 30 Dec 91 12:41:18 CST
From: dab@hemlock (David Borman)
To: [email-masked]
Subject: [email-masked]

Hi there.
You are on the "[email-masked]" mailing list.  If you wish to
be removed, send mail to "[email-masked]".
			-David Borman, [email-masked]

Date: Mon, 30 Dec 91 12:38:17 CST
From: dab@hemlock (David Borman)
To: [email-masked], [email-masked], [email-masked]
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:
		[email-masked]
		[email-masked]	<to join/leave the list>
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, [email-masked]

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, [email-masked]