Subject: RE: P1394> 1394PWG Thick Transport Stack Requirements

From: Nagasaka Fumio <[email-masked]>
Date: Mon, 3 Nov 1997 22:07:51 +0900

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

I don't think so. If the buffer service provides segmentaion and
reassembly,
it makes a transport architecture more complex. Actually segmentation
and reassembly is required due to limit of bus specification. However
any
requirements caused by bus specification shall be resolved in a data
link
layer such as IEEE 1284.3. And transport protocol shall be abstracted
from
any bus-specific requirements.

Toru, Brian, I am so sorry for my interruption for your discussion. Your
discussion bring us produvtive result. Thank you.

Fumio Nagasaka

>-----Original Message-----
>From:	Toru Ueda [SMTP:[email-masked]]
>Sent:	Wednesday, October 29, 1997 9:16 PM
>To:	Brian Batchelder
>Cc:	1394 PWG; PWG-C
>Subject:	Re: P1394> 1394PWG Thick Transport Stack Requirements 
>
>
>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
>
>
>  >>At 09:54 PM 10/24/97 +0900, Toru Ueda wrote:
>  >>--
>  >>--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 ?
>  >>
>  >>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.
>  >>--My understanding is the transport will handle the
>  >>--differences of physical buffer sizes of sending and
>  >>--receiving endpoints.
>  >>
>  >>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?
>  >>--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.
>  >>
>  >>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 
>  >>--case) data. 
>  >>
>  >>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
>  >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  >>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
>  >>
>
>
>
>
>