SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI : Reject PDU Concerns.



    Matt Wakeley wrote:
    
    > julian_satran@il.ibm.com wrote:
    >
    > > 2) An error_byte field should be considered for inclusion in the Reject
    > > PDU which contains the byte offset of the errant byte[or word] in the
    > > received header/payload that caused the target to send a Reject response
    > > to the command.
    > >
    > > This is a simple solution that provides for quick fault isolation and
    > > root cause of the reason for the reject. This also rids the Reject PDU
    > > of any detailed elaboration of reason codes meant to allow root cause of
    > > the reason for the reject.
    > >
    > > <js> that is no big help since there can be more than one error and it
    > > helps mostly in debugging.
    
    Julian,
    
    1) The iSCSI layer, on parsing a PDU, will stop on detecting the first error.
    So, there should really be only one error to report and that is the first one
    discovered.
    
    2) Helping in debugging is a big issue since one of the major problems
    iSCSI implementations will need to deal with is inter-operability. This is not a
    one-time problem as new implmentations of devices and initiators keep coming
    along. The iSCSI draft must attempt to provide some aids for quick fault
    isolation.
    
    3) The cost of providing this error_byte based fault indication feature is
    really minimal, compared to the benefits it provides.
    
    Regards,
    Santosh
    
    
    
    > For implementation errors in the target and/or
    > > initiator I am sure the protocol analyzer will be happy to help but running
    > > implementation should not be burdened with. For those that are running
    > > errors on good implementations we will provide some details when necessary
    > > </js>
    >
    > Julian,
    >
    > With only in-band framing [the markers that are currently defined in the
    > spec], there is no way a protocol analyzer can be used in the traditional
    > way.  In order for the protocol analyzer to work, it would have to be
    > continuously running since the tcp connection(s) was  established.  Besides,
    > early on there will not be any protocol analyzers.
    >
    > -Matt
    
    begin:vcard 
    n:Rao;Santosh 
    tel;work:408-447-3751
    x-mozilla-html:FALSE
    org:Hewlett Packard, Cupertino.;SISL
    adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
    version:2.1
    email;internet:santoshr@cup.hp.com
    title:Software Design Engineer
    x-mozilla-cpt:;21088
    fn:Santosh Rao
    end:vcard
    


Home

Last updated: Tue Sep 04 01:05:46 2001
6315 messages in chronological order