FC_Tape Minutes Oct 7, 1998 Ft.Lauderdale

STEWART_R_WYATT at HP-Boise-om2.om.hp.com STEWART_R_WYATT at HP-Boise-om2.om.hp.com
Wed Oct 14 07:07:29 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* STEWART_R_WYATT at HP-Boise-om2.om.hp.com
     Fibre Channel Tape Profile Meeting T11/98-523v0.pdf
     Fort Lauderdale, Florida, October 7, 1998
     Stewart Wyatt
     1. Introductions: Group
     Facilitator Dale LaFollette, StorageTek, called the meeting to order 
     shortly after 3 PM. He welcomed the participants and had everyone 
     introduce themselves.
     2. Approval of Agenda: T11/98-487v0 Group.
     The group approved the agenda without any change.
     3. Approval of 9/15 Minutes: T11/98-473v0 Stewart Wyatt, HP.
     The group approved the minutes without change.
     4. Old Action Items: Stewart Wyatt
     #1 Public/private addressing - Jim Coomes: On today's agenda
     #2 ABTS proposal, updated, numbered and posted - Dave Peterson: Not 
     completed but on today's agenda. 
     #3 Review SMC SCSI commands and parameters for inclusion in the 
     profile - Dale Lafollette: Completed
     #3 Update the Profile by September 24 - Dave Peterson: Completed
     #4 Post a request for letter ballot on September 24 - Dale LaFollette: 
     5. Public/Private Addressing Continued: Jim Coomes, Seagate.
     Jim found a lot of issues regarding when a public device may have to 
     accept the "0000" alias address instead of the "DDAA" address 
     particularly with regards to the discovery process. He started to put 
     together a table detailing when the 0000 address is required. Then he 
     concluded that to keep things simple he would propose having public 
     devices always respond to the 0000 alias.
     A long discussion followed. Jeff Stai, Brocade, pointed out that Fibre 
     Channel requires each alias address to have a separate node name. The 
     need for this requirement was extensively debated. Charles Binford, 
     LSI Logic, said that this change would cause problems with existing 
     silicon. Jim noted that Seagate's earlier silicon will not support 
     this behavior but later silicon would. Bill Martin, Gadzook, was 
     concerned that responding to an ADISC addressed to the private device 
     with the public address would violate the rules. Pak Seto, Quantum, 
     suggested allowing only unsolicited frames to use 0000 and require all 
     others to use the DDAA address.
     Then the discussion expanded to the FAN ELS. Since many of the 
     participants were not familiar with FAN some tutorial discussion was 
     solicited. The fabric sends out a FAN frame after a log 
     re-initialization. This allows each logged in device to check its Node 
     Name/Port Name/Native address against the value previously logged in 
     to the fabric. The devices are then able to validate themselves. If 
     the device finds the address has changed it does a logout. The 
     question was raised was raised as to whether FAN replaces the 
     discovery process on the local loop. The answer was that it does for 
     the public loop devices. Another discussion followed about possible 
     bugs in the FAN implementation. Matthew Wakeley, HP, was certain that 
     there a bug was introduced in allowing FAN to replace ADISC. Matthew 
     referred to the FLA clause 5.6.j. 
     After all of the discussion the group tried to come to a conclusion. 
     Jeff Stai thought the answer should be included in the FC-FS document. 
     Various proposals were submitted and discussed. Jim Coomes didn't want 
     to "play policeman" for initiators and so wanted the proposal worded 
     so as to allow flexibility for targets. The final proposal was to 
     require public devices to accept PLOGI, ABTS and LOGO frames with 
     either the DDAA address or the 0000 alias, but the device can (but 
     does not have to) discard all others frames received that are 
     addressed to the alias.
     It was suggested that ACK and P_RJT be included but the group was not 
     able to document a need for them. Some additional discussion followed 
     about whether an ACK should include the 0000 alias or the DDAA address 
     in the S_ID field. Dal Allan, ENDL, said that FC-PH was very clear 
     that ACKS are created by reversing the S_ID and D_ID fields in the 
     received frame. The ACK then does not provide an opportunity for a 
     public device to return its correct address if it receives a frame to 
     the 0000 alias.
     6. ABTS Enhancement Continued: Dave Peterson, StorageTek.
     No application was found for the enhancements other than the 
     sequence/exchange bit in the parameter field. An uncompleted action 
     item was for Dave Peterson to update the ABTS proposal, assign a 
     document number and post it for review. Since it is documented in the 
     tape profile (in clause 9.5.4) which is shortly going for public 
     review, it was decided to cancel this action and rely on the profile 
     7. FCP_DL: Dale LaFollette
     Dale posted an overhead with "7.4.2 FCP_RESID" text from the FCP 
     noting that when there is an FCP_RESID_OVER there is ambiguity in the 
     text as to the resulting action of the device. He presented a proposal 
     on an overhead hoping to minimize the ambiguity.
     The original text (which was from the previous "Rev A" version of the 
     profile read, "FCP_DL in the FCP_CMND payload should always be equal 
     to the number of bytes expected to be transferred for the command." 
     Dale proposed changing the text to read, "FCP_DL in the FCP_CMND 
     payload shall always be equal to the number of bytes of the transfer 
     length in the CDB." 
     A heated discussion followed. Ed Gardner, Ophidian Designs, felt that 
     initiators would be forced to provide information unavailable to them. 
     Bob Snively, SUN, agreed with the goal of getting the tapes to behave 
     To sort out the discussion, Dale, provided an example on an overhead. 
     Imagine a tape with four fixed blocks of 100 bytes each. Three 
     different commands were considered. The first example was the most 
     interesting. A read command arrives where the CDB reads 4 blocks and 
     the FCP_DL has a value of 300 bytes. While the CDB requests a transfer 
     of 400 bytes, the FCP_DL restricts the transfer to 300. Dale asked 
     where the tape should be positioned after completing the command - at 
     the end of the third or the fourth block. Dal Allan thought the answer 
     was completely obvious. The CDB instructs the drive to read four 
     blocks. That is the overriding command. The FCP_DL restricts the data 
     transferred to the first three blocks. The result is that the tape 
     transfers the first three blocks but is positioned after the fourth 
     Editor Dave Peterson pointed out that he had already modified the 
     draft from what Dale had posted. Dave had already made some of the 
     same changes that Dale proposed. His changes included specific 
     instructions about how the FCP_DL byte length was calculated. Dave's 
     draft was accepted after changing "expected to be transferred" to 
     "requested in the CBD".
     8. FC-TAPE Draft Review: T11/98-124vB Dave Peterson
     Matthew Wakeley objected to the having the profile restrict SCSI 
     commands. He preferred the approach used in the PLDA which required 
     certain commands and allowed all others. He felt that the restrictions 
     violated the goal of allowing existing SCSI implementations to be 
     easily converted to Fibre Channel.
     Dale LaFollette argued that the goal of interoperability requires 
     specifying a minimum set of commands. Bob Snively said that he 
     currently has to have a unique driver for every different tape drive 
     and wants to have this profile help limit the variations towards 
     enabling a common driver. Brian Smith, Crossroads noted that using 
     hierarchical drivers is an approach to reduce the magnitude of the 
     problem Bob described. Dal Allan noted that Bob Snively had raised the 
     scope of the profile with this approach which had been previously 
     agreed to by this group. This argument has been rehashed before here 
     and in previous profile discussions. Jim McGrath, Quantum, ridiculed 
     the use of the term prohibited which varies from the normal English 
     use of the term. (Jim was not in attendance last month when the choice 
     of terms was debated at length and so his criticism was not acted 
     After an extended discussion the issue was dropped for letter ballot 
     The next issue raised was allowing the port name to be equal to the 
     node name. Some heated discussion followed as to whether this is 
     prohibited in FC-PH. Bob Snively was adamant that it was prohibited 
     while Charles Binford, LSI Logic, Dave Baldwin, Emulex, and Brian 
     Smith, Crossroads felt that it was allowable and have implementations 
     that are doing this. 
     Dal Allan responded that it was prohibited in FC-PH. Bob noted the 
     prohibition is in FC-PH clause 3.1.99. Charles reviewed the text and 
     still felt there interpretation was valid. Dal Allan believed it was 
     prohibited but that the PLDA had allowed it in a footnote. The 
     footnote is in clause 5.1 note 4. Dal said the footnote was inserted 
     only to cover existing implementations NOT to justify new designs. He 
     noted that this has issue has been repeatedly debated, most recently 
     in Hawaii, and the decision to not allow this behavior has been 
     repeatedly upheld, however ignored by those who wish to continue this 
     The facilitator called a straw poll. The results were that 10 
     participants were opposed to allowing the node name to be equal to the 
     port name and 5 were in favor of allowing it. The conclusion then was 
     to reject the comment and make no mention of the subject in the 
     profile, deferring the issue to FC-PH and to not include the footnote 
     from the PLDA.
     The next issue was noting that the text in clause "9.4, FCP Error 
     Recovery (Target Class 2)" was incorrect, having been obsoleted by the 
     new ABTS model. The decision was to eliminate the second and third 
     sentences of the second paragraph.
     Next Dave Peterson asked the group if RRQ (see clause 9.5.7) should be 
     different for the two flavor of ABTS (abort sequence and abort 
     exchange). No one had an opinion so Dave said he would look into it 
     Dave had added a row to the bottom of  "Table 25 - Clearing Effects of 
     SCSI Initiator Actions" on page 58 of the rev B version of the profile 
     to document the clearing effects of persistent reservations. Bob 
     Snively noted that tape drives are not expected to keep persistent 
     reservations across power cycles like disk drives are. This behavior 
     is controlled by the APTPL bit and is mentioned in footnote 11 of the 
     table. Bob said that tapes typically do not have access to nonvolatile 
     memory like disk drives do making persistent reservations more 
     difficult for tape drives to implement. However, he doesn't anticipate 
     a need to power cycle tape drives like disk drives do when being hot 
     plugged making this feature less necessary.
     A comment was made that a SCSI reset and a power cycle are supposed to 
     produce the same results. The variation in the behavior of persistent 
     reservation violated that rule. That comment was acknowledged but it 
     was noted that the SCSI committee had approved this exception.
     Matthew Wakeley had submitted some comments which were reviewed by the 
     In "Table 6 - NL_Port and N_Port Common Service Parameters (PLOGI)", 
     of the current draft of the profile Dynamic Half Duplex - DHD is set 
     to 0. Matthew wanted it removed from the table. There was some 
     opposition to this request but Dal Allan noted that the group had 
     previously agreed to remove from the profile parameters negotiated at 
     login. Dal felt that port characteristic don't belong in the profile. 
     He thought that this item had been overlooked by the editor and should 
     have been removed. The editor, Dave Peterson, preferred to leave it in 
     the table and mark it with an "X". This way it wouldn't look like the 
     issue had been overlooked. 
     Matthew noted that the SEQ_CNT field in Table 6 should be an "X" 
     instead of a "1" to be consistent with other parts of text. This 
     change was agreed to.
     Matthew noted that "Tables 8 and 9 - Class 2 Service Parameters (PLOGI 
     and FLOGI)" have a `1" in the Class validity row. This requires the 
     drive to support Class 2 which was not the intention of the profile. 
     The group concluded to add to the introductory text a statement that 
     these tables only applied to devices that choose to support Class 2. 
     Matthew also noted that note 1 in both of these tables is unnecessary 
     because the RX_ID is returned in the ACK and is known to the sequence 
     initiator. The group agreed to have the note removed. The group agreed 
     that in "Table 10 and 11 - Class 3 Service Parameters (PLOGI and 
     FLOGI)" should remain unchanged with regard to the Class validity bit 
     as Class 3 support is required by the profile.
     Matthew had a number of comments about clause "5.13 Exchange and 
     Sequence Management". The text in this clause was largely copied from 
     the PLDA. The group agreed to have clauses 5.13.1 to 5.13.4 removed 
     and include a reference to the original sources to avoid duplicating 
     material in the profile. Paula Zoller, Exabyte, was concerned about 
     having to reference multiple documents to understand the intent of the 
     profile. Some comments were made about not wanting to include tutorial 
     information in the profile and suggestions to read Bob Kembel's 
     arbitrated loop book and/or hiring a consultant.
     Matthew wanted to modify the note in "6.2 Alternate Login_BB_Credit 
     management" which was approved.
     Matthew had several comments about clause "7 Timers on Public and 
     Private Loop". This portion of the text was largely lifted from the 
     disk profiles. Clause "7.4 Error_Detect Timeout (E_D_TOV)" item "c)" 
     is in error. The group agreed to remove the item from the profile. 
     Item "d)" is a minimum not a maximum and applies to sequence 
     initiator. This correction was accepted. Matthew wanted the 
     LIS_HOLD_TIME parameter in "Table 17 Timer Summary" removed. He noted 
     that this parameter is from the PLDA and is not included anywhere 
     else. The group agreed to have it removed.
     Matthew had noted a very serious problem with the timers. He observed 
     that if write data is lost, the timers as defined will cause the 
     target to log out the initiator (RR_TOV = 2 sec) before the initiator 
     will try error recovery (FCP_TOV = 3 sec). The group decided to 
     redefine RR_TOV to be 2*FCP_TOV + R_A_TOV (SEQ_QUAL). 
     Matthew had comments on several of the figures in "Annex B Error 
     Detection and Recovery Diagrams". Most of his comments related to 
     Class 2 cases where the ACK was lost but the sequence initiator could 
     infer that the original frame arrived by receiving subsequent frames. 
     In Figure 11 an ACK is lost for a transfer ready. The write data would 
     arrive before the E_D_TOV timer expires and most likely the exchange 
     would have completed and status sent as well! Matthew thought it was 
     unnecessary to complete the ABTS procedure described in the figure. 
     Dave agreed to add a note to the figure. Similar cases occur with 
     missing ACKs from read and write commands where implicit confirmation 
     is provided by the arrival of data or a transfer ready. 
     Some discussion followed about what value Class 2 features were 
     providing to the profile. The summary of the discussion was that class 
     2 provides a means of short-circuiting the FCP_TOV timer, enabling the 
     device to discover the error sooner. (Editor's note - other benefits 
     to Class 2 have been presented in previous meetings.)
     Matthew had a comment about the text associated with Figure 15. The 
     text stated that the during the error recovery from lost write data 
     frames that the target "may or may not" hold sequence initiative. 
     Matthew stated that the Fibre Channel specification states that the 
     target will not have sequence initiative after a sequence error.
     Matthew was concerned about "Figure 20 SRR or SRR Response lost". This 
     figure combines two error cases. Losing the SRR and losing the ACC for 
     the SRR. Matthew felt they should be separated. If SRR arrives and the 
     ACC is lost, arrival of data implies delivery. Matthew was concerned 
     about potential malfunctions if the second SRR is blindly sent. 
     Matthew also requested that two additional figures be added to cover 
     lost ACK for FCP_DATA for read and write cases.
     After Matthew's list was finished, Dale LaFollette raised the question 
     of why half duplex operations was prohibited. Rather than continuing 
     the discussion Dale said he would raise the issue in a letter ballot. 
     Charles Binford was concerned that the complete loss of a read data 
     sequence in a multiple sequence exchange could be undetected. As it 
     was late he agreed to post his concerns to the reflector.
     9. T11 New Business: Group
     a. FC-TAPE for T11 Letter Ballot: Group
     It was getting late in the evening. A even dozen participants remained 
     in the room. Dale LaFollette asked the survivors if we should proceed 
     with a request tomorrow to ask for a letter ballot for the profile 
     draft that included the changes made in this meeting. The group agreed 
     unanimously go to the letter ballot.
     There was some discussion about how soon the editor could get the 
     profile updated. Dale proposed two weeks though Dave thought he could 
     get it done sooner. Bob Snively wanted the editor to include a 
     persistent reservation table (98/T10-164v1) added to the document. He 
     suggested several sources that the editor could get it from and 
     offered to send a copy email if needed.
     10. T10 New Business: Group
     11. Review New Action Items: Stewart Wyatt
     #1 Jim Coomes will update the public/private address proposal next 
     week for inclusion in the profile.
     #2 Stewart Wyatt to get a resolution on HP SCSI command comments.
     #3 Dave Peterson to get a copy of persistent resolution table for the 
     #4 Charles Binford to write up his concern about loss of a read data 
     sequence and post to reflector.
     12. Adjournment: Group
     The meeting was adjourned around 8:30 PM.

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com

More information about the T10 mailing list