Subject: P1394> 1394PWG Thick Transport Stack Requirements

From: Brian Batchelder <[email-masked]>
Date: Fri, 17 Oct 1997 16:36:51 -0700

1394PWG - Client Requirements for Our Thick Transport Stack 
-----------------------------------------------------------
The following is a list of requirements the client places on the thick
transport stack.  The requirements are split into two sections: musts and
wants.  They are intentionally brief, with definitions of terms following
each requirement.  

Musts
-----
* Support multiple, concurrent, independent, symmetrical connections
     Multiple, concurrent - Allows for more than one connection at a time.
     Independent - Activity on one connection has no effect on other
                   connections.
     Symmetrical - Either endpoint can open and close the connection, and 
                   send data.
     Connection - well-bounded communication path between two endpoints.
                  The endpoints can be on the same device or on different 
                  devices.
* Provide in-order, byte-stream and in-order, buffer (datagram?) services
     In-order - Data is delivered to the receiving endpoint in the same
                order as it was presented by the sending endpoint.
     Byte-stream - Data is delivered as a stream of bytes.  The stream of
                   bytes is not guaranteed to be delivered to the 
                   receiving endpoint in the same form as it was 
                   presented by the sending endpoint.  For example, a 
                   stream of 80 bytes of data may be presented as 4-20 
                   byte buffers, but delivered as 2-40 byte buffers.
     Buffer (datagram?) - Data is guaranteed to be delivered to the
                          receiving endpoint in the same form as it was
                          presented by the sending endpoint.
                          For example, if data is presented in a buffer of
                          30 bytes, it must be delivered in a buffer of 30 
                          bytes.  The transport stack may limit the size of 
                          buffers.  It does not have to support segmentation 
                          and reassembly.
* Provide a directory service
     Endpoints on a specific device may be referenced by their service name.
     This allows connections to be opened without any knowledge of the 
     underlying layer's implementation of sockets, etc.
* Transparently handle transient link interruptions
     The transport stack shall handle transient link interruptions without
     affecting the endpoints.  These link interruptions include: temporary 
     cable disconnect, 1394 bus reset, etc.  Do we want to provide a service 
     to optionally notify clients when there is a link interruption?
* Reliability
     What level of reliability is required by the clients?

Wants
-----
* Connectionless service
     A non-bounded communication path between two endpoints.  Data may be 
     sent without "opening" a connection.
* Multi-casting
     Simultaneously sending data from one endpoint to multiple endpoints.  
     Does this need to be bidirectional?  Does it need to be reliable?
* Data tagging
     Data can be tagged as "special data" by the sending endpoint.  The 
     transport will indicate to the receiving endpoint that the data is
     tagged.  This is also known as out-of-band data.
* Provide endpoints with fair access to other endpoints
     The transport will prevent endpoints from monopolizing the link and 
     preventing other endpoints from access.
* Selectable quality of service
     The ability to adjust various quality of service parameters, including:
         Isochronous delivery
         Priority
         Propagation Delay
         Rate of transfer (bandwidth)

Internal Thick Transport Stack Requirements
-------------------------------------------
The following are the requirements the transport stack places on itself.

Musts
-----
* Be data, application and O/S independent
     The transport stack shall not put any requirements on the format of 
     the data, nor shall it interpret the data in any way.  The transport
     stack shall work with any application that correctly uses the 
     appropriate interfaces.  The transport shall be implementable under
     any operating system.
* Do not preclude concurrent operation of other protocol stacks
     Devices may implement and use other protocol stacks concurrently with
     this transport stack.  
* Provide efficient data transmission
     Prevent unnecessary bus traffic (e.g. retransmissions) by not 
     transferring data until that data can be handled by the receiving 
     device.  Balance bus traffic with protocol overhead.

Wants
-----
* Bus-independent transport layer
     The transport layer may be used on other busses.
* Reuse existing protocols
     Save time by reusing existing protocols, rather than inventing new ones.

Brian Batchelder
Greg Shue

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:[email-masked]  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

---

From: Toru Ueda <[email-masked]>
Date: Fri, 24 Oct 1997 21:54:11 +0900

Brian,

Thank you for forwarding your client requirements for thick
transport stack document.

I have one question about thick "MUST".

I don't understand how to use buffer service.
Why must thick transport have buffer service ?

My understanding is the transport will handle the
differences of physical buffer sizes of sending and
receiving endpoints.

I assume that the indication of receiving the 30bytes packet
to upper layer will issue when 30bytes data receives whether
this packet is divided into 2-15 bytes or 3-10 bytes data if 
the transport packet size is 30 bytes.

But buffer service allows to send only fixed(30bytes in this 
case) data. 

Does this help to write application ?
I misunderstand buffer service ?

  >>To: 1394 PWG <[email-masked]>, PWG-C <[email-masked]>
  >>From: Brian Batchelder <[email-masked]>
  >>Subject: P1394> 1394PWG Thick Transport Stack Requirements
  >>Mime-Version: 1.0
  >>Content-Type: text/plain; charset="us-ascii"
  >>Sender: [email-masked]
  >>

Toru Ueda
Sharp Corp
Software labs.

---

From: Brian Batchelder <[email-masked]>
Date: Fri, 24 Oct 1997 12:48:52 -0700

>Why must thick transport have buffer service ?

The buffer service is used by clients who need to have data delivered with
well-defined starting and ending points.  For example, this data might be a
message that needs to be delivered whole.  If a byte stream service is
used, the message might be broken into multiple buffers, or if might have
other data appended to it.   This might make the message impossible to
interpret by the receiving service.

>differences of physical buffer sizes of sending and

Yes, the transport must handle varying buffer sizes in each direction.  For
the byte stream service it must be able to break up a large request buffer
into multiple send buffers.  For the buffer service it must either be able
to somehow ommunicate to the client the largest buffer that can be sent or
provide buffer segmentation and reassembly services.  Maybe this should be
added to the requirements?

>the transport packet size is 30 bytes.

I think the requirement is that the 30 bytes be delivered as a buffer if
the transmitted buffer is 30 bytes and there is some indication that it
should be delivered as a single, whole buffer.  I don't think it is a
requirement that the smaller packets be reassembled into one larger buffer
(in other words, that a reassembly service be provided).

>But buffer service allows to send only fixed(30bytes in this 

The buffer service would allow UP TO 30 bytes of data to be delivered as a
single, whole buffer.  A buffer of less than 30 bytes could also be
transmitted.

>Does this help to write application ?

It does help some applications that want to send messages without those
messages  inherently providing some way to be extracted from a byte stream.

>I misunderstand buffer service ?

I think that the requirements document is not complete.  For now, we
probably have many interpretations of the requirements.  Our challenge is
to refine the requirements list until we all agree on them.

Brian

---

From: Toru Ueda <[email-masked]>
Date: Wed, 29 Oct 1997 21:16:08 +0900

Hi Brian,

I understand the meaning of buffer service. 

If the buffer service provides segmentaion and reassembly,
it may be more useful.
(This might sucrifice the simplicity of buffer service.)

Because IEEE1394 has maximum packet size(512 bytes for S100), 
segmentaion and reassembly service may be required if buffer
service treats more than 512 bytes.

Toru Ueda
Software Labs.
Sharp Corporation

  >>--
  >>--Brian,
  >>--
  >>--Thank you for forwarding your client requirements for thick
  >>--transport stack document.
  >>--
  >>--I have one question about thick "MUST".
  >>--
  >>--I don't understand how to use buffer service.
  >>--Why must thick transport have buffer service ?
  >>
  >>--My understanding is the transport will handle the
  >>--differences of physical buffer sizes of sending and
  >>--receiving endpoints.
  >>
  >>--I assume that the indication of receiving the 30bytes packet
  >>--to upper layer will issue when 30bytes data receives whether
  >>--this packet is divided into 2-15 bytes or 3-10 bytes data if 
  >>--the transport packet size is 30 bytes.
  >>
  >>--But buffer service allows to send only fixed(30bytes in this 
  >>--case) data. 
  >>
  >>--Does this help to write application ?
  >>
  >>--I misunderstand buffer service ?
  >>