Minutes of SBP-3 Working Group, July 16-17

Eric Anderson ewa at apple.com
Sat Jul 20 15:17:49 PDT 2002

  DocNum: T10/02-282r0
  Author: Eric Anderson
   Title: Minutes of SBP-3 Working Group

Minutes of the SBP-3 Working Group meeting, July 16-17, 2002.
Wyndham Hotel, Colorado Springs.


Eric Anderson     Apple                 ewa at apple.com
Robert Botchek    Granite Digital       rbotchek at granitedigital.com
John Fuller       Sony                  jfuller at computer.org
Rob Haydt         Microsoft             robhay at microsoft.com
Peter Johansson   Congruent Software    PJohansson at ACM.org

The following agenda was presented by Johansson.  In the minutes that
follow, the start of discussion of items listed below is denoted by
the index number listed within square brackets, such as [4.1].  Note
that these references do not always appear in order, and may not
signify the conclusion of discussion of a previous agenda item.

1. Introductions and procedures
1.1 T10 Membership and voting
1.2 Document naming conventions
1.3 Two-week rule
1.4 Meeting fees
1.5 Approval of prior minutes
2. Call for patents
3. Informal liaison
3.1 IEEE P1394.1 [Johansson]
3.2 IEEE P1394.3 [Johansson]
4. Prior action items
4.1 Publish 02-069r2 with agreed modifications and incorporate into
working draft [Johansson]
4.2 Update working draft to clarify net update effect on timers
4.3 Review draft in re bridge-aware login when no bridges are present
5. Review of changes in working draft
6. Review reflector traffic
7. Old business
7.1 AVD Commands
7.2 Persistent ownership of SBP-3 targets
8. New business
8.1 Target retry after busy acknowledgment
8.2 Prototype AV command set [Johansson]
8.3 Bare-bones isochronous [Johansson]
9. Meeting schedule
10. Review of action items
11. Adjournment

[1] Johansson called the meeting to order and updated the agenda, as
reflected above.

[1.3] Johansson briefly reviewed the two-week rule, explaining that it
did not prevent the discussion of documents posted less than two weeks
before a meeting.

[1.5] Anderson noted that he had previously distributed draft minutes
|from November 6 (Monterey) and May 29 (Timberline).  After review, the
group approved the minutes from both meetings.



[1.1] [2] Johansson reviewed general T10 policies and procedures.  In
general, attendance and participation at T10 ad hoc meetings (such as
this one) is open to both visitors and T10 members. When formal votes
are taken, either in an ad hoc meeting or in the T10 plenary, one vote
is permitted each organization, to be cast by its principal
representative or designated alternative.  A two-week rule is in
effect: No matter may be voted on unless notice was given at least two
weeks prior.  Documents to be voted on must have been posted two weeks
prior to the vote.  The two-week rule can be waived if nobody objects.
 Announcements of new documents and meetings must be posted to the T10
email reflector; all other business can be conducted on the working
group reflector.

The following paragraph about ANSI/T10 patent policy is copied from
past T10 Plenary minutes:

A document is available from ANSI, "Procedures for the Development and
Coordination of American National Standards", at no charge.  This
document is also on the web at http://www.ncits.org/help/ansi_sdo.html. =
 Section 1.2.11 contains the ANSI patent policy.  Amy Marasco manages
patent issues for ANSI and can be contacted at amarasco at ansi.org or
212-642-4954.  Gene Milligan prepared a useful =B3Handy dandy
Technical Committee's Patents Guide=B3, which is available at

[3.1] Johansson reported that the IEEE 1394.1 BRC was continuing to
resolve ballot comments.

[3.2] Johansson noted that IEEE 1394.3 had one significant ballot
comment remaining to be resolved.

[4.1] Johansson reported that he had published 02-069r2 with
previously agreed modifications, and had incorporated this 1394.1
bridge awareness text into the working draft of SBP.  Johansson noted
that the updated SBP draft would be reviewed later in the agenda.


[4.2] Johansson reported that he had updated the SBP working draft to
clarify the effect of a 1394.1 net update on timers, which would also
be covered in the scheduled draft review.

[4.3] Johansson reported that he had not reviewed the SBP draft
regarding the possibility for bridge-aware login when no bridges are
present.  Johansson asked Fuller to take this action item, and Fuller
accepted it.

[5] Johansson led a review of changes in SBP-3 draft "2a":


In (Node Handle ORB) Anderson suggested clarifying "one or
all" in the paragraph below figure 30.  Johansson and Botchek agreed,
and Johansson reworded the text.

Johansson updated the body text to match the terminology change in the
table in section 5.3.1 (Request status) where "Login ID not
recognized" became "Login ID invalid".

Various comments were made regarding the clarity of the two paragraphs
in section 6.4.6 (HEARTBEAT_MONITOR).  Johansson agreed that the
section should be clarified.  Anderson noted that 6.4.6 required a
type error to be sent to heartbeat requests that arrive during the
reconnect process or outside of a login.  Anderson asked if this
requirement was consistent with other text regarding fetch agent write
attempts during a reconnect.

Johansson identified the final paragraph of 6.4 (Command block
registers) which covered this requirement in a general way.  Fuller
identified section 9.1.5 (Fetch agent state machine) which provided
further clarity on this point.  Johansson explained that during the
reconnect period, any access would fall into the category described by
9.1.5 because there would be no known node ID for a login that had not
yet been reconnected.  Anderson agreed but suggested that 9.1.5 could
benefit from text explaining Johansson's observation, and Johansson
agreed to add such text.

Finding that 9.1.5, from SBP-2, specified type_error, the group agreed
not to change the response from type_error to address_error.  Anderson
suggested that 6.4 should make reference to 9.1.5 for greater clarity,
and Johansson agreed.  Fuller suggested that 9.1.5 should require the
use of a type_error response by bridge-aware targets, and Anderson
agreed.  Johansson added corresponding text at the end of the section,
making the requirement dependent upon the unit having a non-zero
revision entry.

Johansson suggested that it would be valuable to have an informative
annex summarizing changes from SBP-2 to SBP-3, and what combinations
of features would be sensible.  Anderson said he might be able to
provide a draft of such an annex.

Anderson observed that in 8.2.1 (Login) steps c) and d) could be
exchanged for greater efficiency, though executing them in the order
shown would lead to correct results with a slight inefficiency.=20
Fuller agreed.  Johansson determined that clause d) could be done
before clause b) for even greater efficiency, and all present agreed
with this change.

Reviewing 8.2.1, Anderson observed that 6.3 (MANAGEMENT_AGENT
register) required the target to execute only a single management ORB
at one time, which guarantees there will be no interruption of an
update login operation, nor any query logins operation during such an
update.  Anderson suggested that the second paragraph after step h)
could be simplified by giving reference to section 6.3.

Johansson suggested that the second sentence of the final paragraph of
8.2.1 (not the note) was unnecessary.  Anderson said the sentence was
incorrect, and agreed to its removal.  Johansson promoted the
following Note to be part of the final paragraph.

Johansson observed that an update login could be implemented by a
target as a completely new login, and suggested that the login
response could indicate new values for any field, such as node handle
and reconnect.  Anderson agreed with this possibility, stating that it
could simplify the implementation of the update login capability in
targets.  Johansson added text stating that the update login response
values could differ from those previously returned by the login that
was being updated.

In review of 8.3.3 (Node handle update after bus reset), Anderson
asked if the requirement to process self-IDs in order to track node
IDs was unduly burdensome on targets.  Anderson observed that self ID
sets can arrive in rapid succession due to a "bus reset storm".=20
Anderson further speculated that the process was not robust, and was
subject to failure (such as mis-identifying a node) in the face of bus
reset storms, suspend faults, and other hot-plug related problems that
are observed in practice.

Anderson suggested that targets should be required to confirm their
node ID tracking by way of a GUID read, and to initiate recovery
operations when this read finds an error.  Botchek agreed that the
existing mechanism was not robust and that a verification and recovery
mechanism was desirable.  Fuller suggested that a target failing the
GUID check could simply be required to loop over all node IDs on the
bus until the desired GUID was found.  Anderson agreed with
Johansson's comment that a GUID check would cause additional bus
traffic, but felt that the cost was bearable and was reasonable in
order to achieve a robust service.  Johansson agreed to add text
describing the verification and recovery strategy, and worked out
preliminary text with the group based on Anderson's proposal.

In section 10.5 (Task management event matrix), in the fourth
paragraph after the table, Johansson observed that fully-local
bridge-aware logins should be exempted from the abort following a net
update.  Fuller and Anderson agreed with this change.

Botchek noted that section C.2 (Login) should be updated according to
the ordering changes earlier made in section 8.2.1 (Login).  Johansson
made the appropriate changes.  Johansson further observed that step c)
regarding three failed logins should be relocated.

[7.2] Johansson mentioned that Microsoft and Apple are working on
solutions for the two host, one drive problem based on existing drive
products and exclusive logins.  Johansson suggested the group should
consider new mechanisms that could be used in a future, more flexible
or powerful solution.  Johansson mentioned passwords and reservations
(such as in SBC-2) as mechanisms that could be applied to the problem.

The group divided up the solution space in three ways:

Initiator-based solutions:  Initiators keep track of drives and
possibly cooperate regarding who logs in when.  Fuller observed that a
"most favored" Initiator might arrive later than other Initiators,
after another Initiator has taken control of a drive.  Fuller
suggested that a mechanism for "please let go" and "I have let go"
messages would be helpful.

Drive-based solutions:  Drives keep track of Initiators, and enforce
who can or cannot log in.  Anderson observed that this style of
solution would be most robust in the presence of legacy initiators.

Hybrid solutions:  Both Initiators and Drives cooperate using the
features listed above.

Fuller and Johansson agreed that password protection was orthogonal to
these three approaches, but could be used as a mechanism to enforce
one of the above approaches.  Johansson added that passwords can cover
the "one preferred initiator" case, but not the "list of preferred
initiators" case.

Johansson suggested that in the proposed Apple/Microsoft solution
(where one Initiator logs in, then makes the drive available to all
others over IP/1394), it would be helpful for a drive to indicate who
its preferred initiator was (if any) in order to obtain reproducible
results.  Fuller noted that such cooperation could also be done in
initiator software. =20

Fuller observed that target-only solutions were unlikely, because
initiator changes to use new target features would probably be
required.  Fuller concluded that since initiators must be changed, one
could look for an initiator-only solution that would be less work and
yield more compatibility with legacy targets.

Johansson noted that Microsoft had observed that exposing Target
information in 1394 Configuration ROM was convenient because it could
be accessed without a login, which is both fast and unlikely to
require coordination with other Initiators.

Fuller observed that for booting from a target, it would be desirable
to have a strong affinity mechanism such as a password, because
sharing mechanisms were unlikely to be feasible during the boot load
or paging process.

[8.1] Johansson reported that the 1394 TA Architecture Working Group
had contemplated deprecating the 1394 BUSY_TIMEOUT register, opening a
question as to how SBP should address retries.  Anderson remarked that
SBP was "the" protocol that demonstrated the need for an effective
retry strategy, due to the high penalty of a transport failure.=20
Johansson observed that SBP targets primarily use request subactions,
especially for payload transport. =20

Johansson suggested that SBP-3 could require the BUSY_TIMEOUT register
to be unimplemented.  Anderson noted that legacy SBP-2 initiators
might fail if they detected an error when writing BUSY_TIMEOUT.=20
Johansson remarked that BUSY_TIMEOUT was optional in 1394, but Fuller
observed that SBP-2 required BUSY_TIMEOUT.  Anderson suggested that
SBP-3 specify a desirable busy retry strategy that would work if an
initiator never wrote to BUSY_TIMEOUT, without removing the actual
register, so legacy initiators would not be affected.

Johansson suggested preserving BUSY_TIMEOUT, but requiring the initial
values be set to either zero or greater than or equal to 200
milliseconds for second/cycle limit (as determined by the implementor)
and 15 for retry count, with all writes to be ignored (with
ack_complete or resp_complete).  Initiators recognizing SBP-3 via the
revision level in the 1394 Configuration ROM will know that there is
no need to set this register.  Anderson endorsed this plan, with a
provision that all target retries must be separated by at least one
isochronous cycle time (whether or not a cycle master was active on
the bus), in addition to any required separation due to fair
arbitration and other bus access rules.  Johansson suggested an
exponential backoff for retries, such as consecutive doubling of the
retry interval, which Anderson endorsed.  Fuller noted that backoff
would be OK for single-phase retry, but that dual-phase retry had
specific retry timing requirements that must be honored in order for
it to work correctly.

Johansson noted that exponential backoff starting with one cycle time
would lead to a four second retry delay if 15 retries were allowed.=20
Anderson and Johansson agreed that an arithmetic backoff (1 cycle, 2
cycles, 3 cycles, etc. to 15) would be more effective for single-phase
retry, leading to a maximum retry delay of 15 cycles and a total retry
period of about 120 cycles (15 milliseconds).  Johansson suggested
adding text in section 9 to explain this, with a reference from the
register description section.  Anderson suggested recommending support
for dual-phase in all transactions, but not requiring it beyond what
other specifications require.  Fuller suggested that outbound
dual-phase retry be mandatory for bridge-aware targets.  Johansson
suggested that all outbound dual-phase retry should skip one fairness
interval instead of applying the arithmetic backoff strategy.

[8.3] Johansson led a review of the updated Bare bones isochronous


Johansson explained the proposal to add an isochronous bit to the
normal command ORB.  The group discussed the viability of a
peer-to-peer isochronous transfer, such as a scanner delivering a page
to a printer.  Anderson noted that the devices would either need
matched mechanical speeds, or the faster device would need to be able
to pause or otherwise slow down.  Anderson said that though some
devices like laser printers had no ability to vary their mechanical
speed during a page, many devices did, such as scanners and ink-jet

Johansson suggested the use of a "go" token associated with an
isochronous ORB, sent isochronously on the reserved isochronous
channel, prior to the start of isochronous data flow.  Anderson noted
that contemporary OHCI did not provide hardware support to trigger
isochronous transmission based on the receipt of an isochronous
packet, but added that system software could perform this duty with
precise latency, though perhaps not bounded as tightly as a single
1394 isochronous cycle.

Anderson described the synchronization requirement between two peers
such as a scanner and a printer.  Anderson said that after the receipt
of a command to start the mechanism, there would be a variable but
bounded delay until the mechanism was ready to produce or consume
data.  Anderson proposed that if each device provided internal
buffering sufficient to cover the maximum variation of this delay due
to its own mechanism, two devices with dissimilar delays could still
be synchronized to transport data successfully.  Anderson noted that
while it was fairly intuitive for a printer to buffer incoming data
when its mechanism was not quite ready, a scanner would be similarly
obligated to hold its outbound data until the end of its variable
window, so that the arrival of data on the bus would be precisely

Johansson suggested collapsing isochronous control into a single
command ORB with an isochronous bit, and using 61883 plug control
registers and other existing services to manage the establishment of
isochronous transfer.  Johansson said this would allow the use of a
single task set for devices that have simple, single-stream

Johansson suggested that CREATE STREAM should be renamed CREATE TASK
SET.  The group agreed that it was not necessary to specify talker or
listener (data direction) at the task set creation time, and that
bi-directional transfer could be allowed.  Johansson suggested that
the contents of 01-287r1 were ready to be incorporated into the SBP

Anderson moved to incorporate 01-287r1 into SBP.
Fuller seconded.
Motion passed with none opposed.

[7.1] [8.2] Johansson led a review of the Prototype AVD Commands:


Johansson noted that all of the proposed commands could be multiplexed
through a single opcode.  How to deal with trick-play commands such as
play-fast-forward was unclear, as was how to deal with super-realtime
transport.  Anderson suggested that data transported in a
super-realtime way should be recorded no differently from data sent in
real time, because there should be no limitations on the subsequent
playback speeds.  This would require knowledge in the SBP device,
because SBP records cycle marks.

Johansson and Anderson agreed that the SBP model of cycle awareness
and cycle mark recording was greatly at odds with the concept of
variable super-realtime transport, and its resolution should be
deferrd to future study.

Johansson expressed a desire for further comment from Apple and
Microsoft regarding the AVD proposal.

Action:  Anderson to review 02-281r0 with Apple and provide comment.

Action:  Johansson to request similar consideration from Microsoft.

[9] The next scheduled meeting is tentatively November 5-6, during the
T10 meeting in Huntington Beach, CA, tentatively followed by a meeting
on January 20-21, following the January 2003 1394 TA meeting.

[10] Johansson briefly reviewed the newly assigned action items.

[6] Johansson led a brief review of email traffic since May 29 and
found no issues needing to be addressed by the group.

[11] Meeting adjourned.


General information and document index

The SBP-3 email reflector SBP3 at isg.apple.com can be accessed as

  email requests at isg.apple.com w/subject "subscribe sbp3"

  email requests at isg.apple.com w/subject "help"

An automated system had been created for the allocation of T10
document numbers, and the subsequent submission of documents for


The following documents have been posted pertaining to SBP-3:

00-328   Eric Anderson
         Fast Start proposal (PowerPoint slides)

00-371   Peter Johansson
         Minutes of SBP-3 Study Group  September 19, 2000

00-388   Peter Johansson
         SBP-3 Project Proposal

01-057   Eric Anderson
         Fast Start Proposal

01-060   Eric Anderson
         Minutes of SBP-3 Working Group  January 24-25, 2001

01-067   Lance Flake
         RBC Access For AV/C Data Interchange=20

01-069   Steve Powers
         Surprise Removal of 1394 Storage Devices

01-070   Peter Johansson
         Bridge-aware targets and node handles

01-101   Eric Anderson
         Minutes of SBP-3 Working Group  March 6-7, 2001

01-102   Scott Smyers
         Proposal for modifications to SBP3 and RBC

01-103   Firooz Farhoomand
         Using SBP-3 for DVD playback

01-137   Peter Johansson
         Stream command block ORB

01-138   Peter Johansson
         Bi-directional ORBs (PowerPoint slides)

01-139   Eric Anderson
         Minutes of SBP-3 Working Group  April 26-27, 2001

01-179   Andy Green
         Proposal to modify isochronous recording format

01-180   Peter Johansson
         RBC-2 commands for extent management

01-187   Eric Anderson
         Minutes of SBP-3 Working Group  June 5-6, 2001

01-200   Peter Johansson
         Distributed Buffers

01-222   Peter Johansson
         Simplified Isochronous

01-223   Eric Anderson
         Minutes of SBP-3 Working Group  July 17-18, 2001

01-248   Peter Johansson
         MP-friendly Fast-Start

01-265   Eric Anderson
         Minutes of SBP-3 Working Group  August 22-23, 2001

01-287   Peter Johansson
         Bare-bones Isochronous

01-304   John Fuller
         SBP3 changes

01-318   Rob Elliott
         Elimination of SCSI-2 from SAM-2 SPC-3

01-330   Peter Johansson
         Minutes of SBP-3 Working Group  October 3-4, 2001

01-331   Eric Anderson
         Minutes of SBP-3 Working Group  November 6-7, 2001

01-332   Scott Smyers
         Isochronous SBP3

02-069   Peter Johansson
         Bridge-aware SBP-3 target operations

02-075   Peter Johansson
         EUI-48 software interface ID VPD page

02-206   Eric Anderson
         Minutes of SBP-3 Working Group  January 21-22, 2002

02-207   Eric Anderson
         Minutes of SBP-3 Working Group  March 12-13, 2002

02-208   Eric Anderson
         Minutes of SBP-3 Working Group  May 29-30, 2002

02-281   Peter Johansson
         Prototype AVD Commands

Latest draft SBP-3 document:



SBP-3 protocol for FireWire Mailing List
send email to requests at isg.apple.com with subject "unsubscribe sbp3"

Set to Digest Mode:
send email to requests at isg.apple.com with subject "subscribe digest =

send email to requests at isg.apple.com with subject "help"

More information about the T10 mailing list