[T11.3] Re: FCP-4: Continuously Increasing SEQ_CNT

Jim.Coomes at seagate.com Jim.Coomes at seagate.com
Thu Nov 9 07:40:07 PST 2006


Kevin,
In the case of a lost read Sequence, The target will send the Response
indicating it has completed the command and the host will detect a transfer
length error. The error does get detected.
Jim
	     "Kevin Jones"						   
	     <kev at bri.hp.com>						   
	     No Phone Info						To 
	     Available		       Jim.Coomes at seagate.com, T10	   
				       <t10 at t10.org>, T11_3		   
				       <t11_3 at t11.org>			   
	     11/08/2006 02:13						cc 
	     AM 							   
								   Subject 
				       Re: FCP-4: Continuously Increasing  
				       SEQ_CNT				   
My guess at the problem being addressed is the case of an entire
READ DATA SEQUENCE being lost.
eg. a 17KByte read might consist of 2 sequences:
1st sequence = 8*2K frames
2nd sequence = 1*1K frame, which might be lost.
In systems which use only SEQ_CNT for reassembly
(see FC-FS 19.6 "Reassembly Rules") there is a risk of data loss.
In a system is using RELATIVE OFFSET for reassembly then,
as you indicated, a dropped read sequence would be detected
via relative offset (in this case, final relative offset +
final payload size != FCP_CMD.FCP_DL).
Hence, if
PLOGI->N Port Service Parameters->Common Service Parameters->Common
Features->Continuously Increasing Offset == 1
then I see no requirement that SEQ_CNT be set.
The SEQ_CNT proposal seems to be a major change. My perspective
is that reliable class 3 reassembly is done using relative offsets.
Kevin Jones
kevin.jones at hp.com
On Mon, 06 Nov 2006 21:52:23 -0000, <Jim.Coomes at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Jim.Coomes at seagate.com
> *
>
> There is Continuously Increasing SEQ_CNT and there is Continuously
> Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
> Sequences and across streamed Sequences. The other Continuously
Increasing
> SEQ_CNT is established at port login and is Continuously Increasing
SEQ_CNT
> across the whole Exchange.
>
> As SCSI FCP is basically an interlock protocol, what is the gain in
> Exchange Continuously Increasing SEQ_CNT for error detection? If the
> command is lost, there is no response from the target. The host has to
> time-out. If a write data frame is lost, it is detected by relative
offset
> or SEQ_CNTat the target. If a transfer ready is lost, the host or the
> target has to time-out. If a read data frame is lost, it is detected by
> relative offset or SEQ_CNT at the host. If the ending response is lost,
the
> host has to time-out.
>
> These detection scenarios apply to bidirectional commands also.
>
> Exchange Continuously Increasing SEQ_CNT does not change this behavior.
> What is the gain in using Exchange Continuously Increasing SEQ_CNT?
>
> FC has a large installed base of which many devices do not support
Exchange
> Continuously Increasing SEQ_CNT. This would support not making Exchange
> Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
> warning that it could be a time delay before Exchange Continuously
> Increasing SEQ_CNT could be available widely.
>
> Jim
> ----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
>	      Claudio DeSanti
>	       <cds at cisco.com>
>	       Sent by:
To
>	       owner-t10 at t10.org	 "Craig W. Carlson"
>	       No Phone Info		 <craig.carlson at qlogic.com>
>	       Available
cc
>					 Bob.Nixon at Emulex.Com,
>					 David.Peterson at mcdata.com, T10
>	       11/03/2006 03:38 	 <t10 at t10.org>
>	       PM
Subject
>					 Re: [T11.3] FCP-4: Continuously
>					 Increasing SEQ_CNT
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Claudio DeSanti <cds at cisco.com>
> *
> Craig, Bob, Dave,
>
> there are functions defined in FCP-4, such as data overlay or certain
> bi-directional commands, that are simply not implementable in Class 3
> without the use of CISC. I bet that the devices you are referring to do
> not implement these functions. I recommend to identify these functions
> in FCP-4 and either:
> a) obsolete them; or
> b) clearly state that use of CISC is required to implement them in Class
3.
>
> In addition, the usage of CISC greatly simplifies error recovery in
> Class 3. We should encourage this behavior moving forward. I recommend
> that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
> not its use. CISC should be mandatory to support and optional to use in
> FCP-4. In this way we set a good path for the future, while allowing
> complete interoperability with FCP-3 and older devices that do not
> support CISC. To ease this interoperability FCP-4 may also recommend to
> not use CISC by default. But mandating its support in FCP-4 devices, we
> achieve that when connecting FCP-4 only devices CISC may be turned on
> and used, with all its advantages.
>
> Thanks,
>
> Claudio.
>
>
> Craig W. Carlson wrote:
>> I’d have to agree with Bob on this one. We are aware of devices which
>> cannot support CISC, and which would seriously break if presented with
>> it. A change such as this (either a or b) could create havoc with
>> device interoperability.
>>
>> +Craig
>>
>> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com>
wrote:
>>
>>     Dave,
>>
>>     Despite the potential value of CISC to FCP operation in Class 3,
>>     we must advise against requiring or even recommending it.
>>
>>     In our interoperability testing, we have discovered there are
>>     devices with significant installed base that do not behave
>>     properly when actually presented with CISC. Unfortunately, they do
>>     not reject an N_Port Login that offers CISC, so this problem is
>>     not discoverable.
>>
>>     Even recommending CISC in a standard would therefore increase the
>>     incidence of interoperability problems with use of Fibre Channel.
>>
>>     - Bob Nixon, Emulex alternate representative
>>
>>     -----Original Message-----
>>     *From:* t11_3-bounces at listserve.com
>>     [mailto:t11_3-bounces at listserve.com]
>>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>>     *Sent:* Sunday, October 08, 2006 12:34 PM
>>     *To:* t10 at t10.org
>>     *Cc:* t11_3 at t11.org
>>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>>
>>     Howdy All,
>>
>>     At the last FCP-4 working group meeting I presented a proposal to
>>     request the use of continuously increasing SEQ_CNT (CISC) for
>>     Class 3 service.
>>
>>     While most believe requiring continuously increasing SEQ_CNT for
>>     Class 3 service is a good idea, one vendor indicated that none of
>>     their implementations support CISC, and another vendor was
>>     concerned about the requirement.
>>
>>     As such, we have the following options:
>>
>>     a. require CISC for Class 3 service. This means that existing
>>     implementations can claim compliance to a prior standard (e.g.,
>>     FCP-3);
>>     b. specify that CISC should be used for Class 3 service;
>>     c. no change (i.e., CISC is not required except for streamed
>>     Sequences).
>>
>>     My preference would be option a.
>>
>>     What say ye?
>>
>>     ...Dave
>>
>>     (no disclaimer)
>>
>>
>>
> ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     T11_3 mailing list
>>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>>
>>
>> ------------------------------------------------------------------
>> Craig W. Carlson mailto:craig.carlson at qlogic.com
>> QLogic Corporation (952) 932-4064
>> 6321 Bury Drive
>> Eden Prairie, MN 55346
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> T11_3 mailing list
>> http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>



More information about the T10 mailing list