Minutes of SBP-2/Isochronous Ad-hoc meeting

[Stephen Finch/SSI1]

* From the SCSI Reflector (scsi at symbios.com), posted by:
* Stephen Finch/SSI1 <Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com>
*
Minutes/notes from the SBP-2 Isochronous study meeting held December 10 and 11, 
1996 at the Sony facilities in San Jose.  This group wishes to thank Sony for 
providing both the meeting facilities and beverages and snacks for breaks.  

This meeting was an open, ad-hoc meeting which was established via X3T10.  The 
purpose of the meeting is to determine a common understanding of isochronous 
transfers in the 1394 environment from which we can move forward.  

Attendance:

Richard Mourn Symbios Logic richard.mourn at symbios.com
Peter Johansson Congruent Software pjohansson at aol.com
Ron Roberts Apple rkroberts at aol.com
Joe Wach Seagate joe_wach at notes.seagate.com
Steven W. Brown Firefly swb at fireflyinc.com
Hugh Curley Knowledgetek hcurley at indra.com
Pete McLean Maxtor pete_mclean at maxtor.com
John Fuller Microsoft jfuller at microsoft.com
Steve Finch Silicon Systems Inc steve.finch at tus.ssi1.com
Mike McMurdie Adaptec mcmurdie at corp.adaptec.com
Dave Evans Symbios Logic dave.evans at symbios.com
Hisato Shima Sony shima at ssl.sel.sony.com
John Packer Adaptec john_packer at corp.adaptec.com


Peter Johansson agreed to act as chair of the meeting.  Steve Finch agreed to 
take notes.

It was agreed that there is a need to educate the others within the storage 
industry about Isochronous Transfers on 1394.  It was agreed that it would be 
helpful to provide basic tutorial at the January 20-21, 1997 X3T10 SBP-2 
Working Group.  Estimated length for this tutorial is 1 hour.  Hugh Curley of 
KnowledgeTek volunteered to be the presenter and to put together such a 
presentation.

Today, isochronous transfers are being used by consumer A/V devices.  IEC-1883 
defines the isochronous protocol used in consumer A/V devices.  Includes 
Function Control Protocol (FCP).

AV/C is a 1394 TA Specification describing some protocol and command set for 
DVCR (camcorder).

The existing SBP-2 draft has a set of commands addressing isochronous 
transfers.  The isochronous sections have, by common consent of the working 
group, been largely ignored in preference to addressing the more immediate 
needs of asynchronous transfers in the storage arena.

A lively and informative discussion about isochronous transfers, capabilities, 
restrictions and usage ensued.  The following information found its way onto 
various papers, white boards and overheads, all hand drawn and often radically 
modified on the fly.  An attempt was made to capture the final state of each 
page.

==========================================================
First Paper Sheet was an attempt to see where isochronous transfers were used 
and what issues existed:

PRODUCTS:
 ISOCH Playback device
 ISOCH Record device

Question:  Raw storage or file system storage or both

<<editors note:  Raw storage meant record and play back without the ability to 
provide random access to the data.  Random access is used needed for 
applications to make use of the recorded data, such as in  editing.  File 
system access is how storage is used today in computer systems.)  

----------------------------------
DESIGN GOALS:

Multiple streams
Robustness across bus resets

Continued support of PCRs (Plug Control Registers) to maintain compatibility 
with A/V equipment.
 If so, how is this managed

Concurrent asynchronous and isochronous activity
 permit isolation of functions to enable various performance levels of storage 
devices
  async only
  isoch only
  async and isoch without concurrency
  multiple isoch channels
  multiple isoch and async concurrency
  levels of bandwidth supported

Support of Common Isochronous Packet (CIP) or other generic packets
 format needs enough inf. for off-line edits
 

==========================================================
Second Paper Sheet:

Issues:

 ERROR REPORTING/RECOVERY
  running of not

 CHUNK SIZE
  login??
  command??
  elsewhere??

<editors note:  Chunk size was a term used to describe many things at the 
meeting.  Its definition seemed to changed depending on who was talking and 
what was being discussed (at least to this observer).  The final definition 
seemed to be:  that size that the host computer must meet of exceeds on every 
ORB sent to the isochronous task set control engine. See min_transfer_length as 
presently defined by SBP-2>
  
==========================================================
First White Board:

Attempt to define the typical startup and usage of an isochronous storage 
device in record mode:

Isoch Login:
 --->  rate (affects max. aggregate payload)
 --->  # channels
 <--- chunk size
 
 async read --->

 +---------+
 |         |
 |     v
 |    check stream ready
 |     |
 +---------+
 
STREAM CONTROL  STREAM TASK SET
------------------ -----------------
a)  stream GO  b)  Read
 :              read
 :                read
    stream STOP

==========================================================
Second White Board:

The data stream could look like:

 cycle start
  ch1, length n1
  ch7, length n2
  ch63, length n3
  other channels
  async traffic

 cycle start
  ch1, length n4
  ch7, length n5/n5A ; original size was n5, and this
      ; size of data was originally
      ; recorded, but the size was changed
      ; to n5A during editing.  n5A could
      ; be larger or smaller than the 
      ; original n5
  ch63, length n6
  other channels
  async traffic

 cycle start
  ch1, length n7
  ch63, length n9  ; note: channel 7 missing
  other channels
  async traffic

 cycle start
  ch1, length n10
  ch7, length n11
  ch63, length n12
  other channels
  async traffic


Key points:  
1.  What is played back is what was recorded:  a sequence of packets.  For this 
sequence to useful, it must maintain the (time based) order and size of the 
packets.  If no edits are applied, play back must be the same as what was 
recorded.  The device can not change the size or content of the packet, nor 
affect the time ordered delivery of the data.
2.  A stream can consist of multiple channels of related data (e.g., one video 
and two audio channels) and may be a subset of all channels currently active on 
the bus. The terms STREAM and CHANNEL have separate meanings.
3.  The talker places a packet on the bus for each isochronous cycle, although 
the listener may not see it. The packet for a channel could be missing due to a 
transmission error (packets with bad CRC are thrown away) and this could occur 
on arbitrary cycles.  
4.  We need to allow for editing of data for one or more channels and these 
edits could result in less/more data than originally recorded.  These changes 
could effectively change the chunk size of the data recorded.  These issues 
must be dealt with by our solution. 

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

Summary of other key points covered in the discussions:

1.  The storage device will need to add information (headers) to the stream 
data during the recording process to facilitate playback.  The headers 
envisioned include:
 cycle start
 packet data
 null packet (some questioned the need)

2.  These headers must defined in standards to allow:
a.  applications to access and modify the stream data
b.  interchangeable media to be recorded on one manufactures device and played 
back on anothers.

3.  There was an issue raised regarding error tolerance.  A key point to keep 
in mind is that delays of data are just as serious a problem as bad data, and 
possibly even worse.  It was pointed out that some A/V-tuned disk drives have 
modes of operation which can be invoked to minimize delays in data delivery.  
One is the ability to disable re-reads (and associated rotational delays) as a 
form of error recovery, selecting instead to deliver data which may contain 
errors.  The problem envisioned was if error retries are disabled and such an 
error were to occur it is possible that the portion of the sector which was in 
fact in error was a size value in one of the control fields (CIPs) inserted 
into the data stream by the recording device.  Since the size fields are used 
to determine the location of the next CIP, if a size field is corrupted it 
might not be possible to re-establish CIP positioning and the results could be 
that we would be unable to continue playback at all.  It was agreed by all that 
this must be addressed.  Several ideas were kicked around, but no decision was 
made.

END DAY 1.

Started a review of sections in SBP-2 that deal with isochronous transfers.  
Discussion went to discussion of how a disk is used in a camera-only 
environment and then moved to a computer system (editing, etc.).  Desire is for 
disk to be usable in this mode AND as a standard disk drive.  Two types of disk 
drive is not acceptable.

Isoch Login changed to Create Stream.  Discussed streams as unidirectional 
(previously stated, but made clear to group)

The group reviewed the sections of SBP-2 that relate to isochronous operation.  
Many changes were suggested that the editor agreed to make, but most of these 
changes were not of a major nature (i.e., were more of the nature of 
clarifications and editorial changes).  Those that might be of significance 
include:

1.  All of section 12.1 will be replaced with a few paragraphs and a pointer to 
1394A which will have all of the plug control descriptions.

2.  Add a figure which provides a basis of description of streams.  Such 
diagram has possibly new names for stream controller and stream command 
processing.  This was based on a lively discussion resulting in general 
agreement that the new diagram and change in names will add a lot of clarity to 
the document without changing any functionality.

A general discussion of errors and recover/notification occurred.  A basic 
foundation was tentatively agreed to, but no modifications to the document were 
discussed.
*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com