RE: iSCSI: NIC interoperability

["shailesh Manjrekar" <shaileshm@aarohi-inc.com>]

Hi Folks,

I would like to question the (C) requirement, in the interest of
implementation simplicity. I have also seen some previous threads
on whether to have a host based session manager v/s session handling 
at the offload engine with routing on the host (each NIC, independent
portal group).

The value add with session spanning across NIC's namely :
	- availability at the connection level and
      - ability to scale by bandwidth aggregation, 

could also be reasonably achieved by
      - reestablishing session on the different path ( the time
        taken for failover to different connection v/s establishing
        a new session needs to be characterized, but should not be
        significant if weighed against the simplicity ).
	- bandwidth aggregation can be achieved by multi-ported, 
        multi-engine HBA's and also at a multi-connection level.

The price to pay for session spanning across NIC's would be of having a 
intelligent session manager on the host managing the per session counters, 
parameters etc. which would result in somewhat performance hit of going 
between on-chip and off-chip and making the interface between the host and 
offload engine, less intelligent.

Would there be really vendor interest of having added complexity on host
side for iscsi implementations.

Any directions/comments appreciated !

Regards,
Shailesh.
Aarohi Communications.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
KRUEGER,MARJORIE (HP-Roseville,ex1)
Sent: Monday, October 15, 2001 11:32 AM
To: 'Julian Satran'; ips@ece.cmu.edu
Subject: RE: iSCSI: NIC interoperability


Mallikarjun is advocating including A,B,and C statements explicitly in the
document.  I support this.

Marj

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, October 12, 2001 10:03 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: NIC interoperability
> 
> 
> Mallikarjun,
> 
> I have repeatedly stated that from a practical point of view we are
> spending a lot of ink on a non-issue.
> I have even insisted on mandating C in the draft. Some of the list
> members/readers/authors seem to consider such a requirement 
> as "excessive"
> - as it implies resorting to a higher authority on every 
> session creation -
> and that might not be strictly necessary (although it will be 
> sufficient).
> Adding a text key is neither simpler nor easier nor will it solve the
> conflict problem.
> And I have very little time and patience left for pages of 
> debate on the
> merits of one or other port naming script.
> 
> Julo
> 
> 
> 
>                                                               
>                                 
>                     "Mallikarjun                              
>                                 
>                     C."                  To:     ips 
> <ips@ece.cmu.edu>                        
>                     <cbm@rose.hp.c       cc:                  
>                                 
>                     om>                  Subject:     iSCSI: 
> NIC interoperability             
>                     Sent by:                                  
>                                 
>                     owner-ips@ece.                            
>                                 
>                     cmu.edu                                   
>                                 
>                                                               
>                                 
>                                                               
>                                 
>                     10-10-01 04:14                            
>                                 
>                     Please respond                            
>                                 
>                     to cbm                                    
>                                 
>                                                               
>                                 
>                                                               
>                                 
> 
> 
> 
> After seeing some of the emails on this topic from Dave
> Sheehy, David Black and Jim Hafner, I have some comments
> and questions.
> 
> It appears to me that the following three are the major
> issues that one has to deal with for building a multi-NIC
> iSCSI Node, where the NICs are potentially from different
> vendors.
>            A. Each NIC MUST allow the Node name to be configurable.
>            B. Each NIC MUST allow the ISID range to be configurable
>            (if deployed in an initiator configuration).
>            C. In addition, if only one (initiator/target) portal group
>            is sought to be presented (i.e. session spanning across
>            any and all of these NICs is a requirement), each NIC
>            MUST allow itself to be managed by an externally-resident
>            "session manager" in some "TBD standard way".
> 
> Admittedly, C is is the hardest and till the "TBD standard way"
> is defined to interact with a session manager, it cannot be
> mandated.  Failure to comply with C would only create multiple
> portal groups in an iSCSI implementation - each portal group
> limited to NIC(s) from a given vendor.
> 
> But, A and B above seem reasonable and in fact seem required
> to be mandated - both to avoid the problems as with FC Node
> Name, and also to address the concerns of not leaving target
> with a deterministic way to enforce access control mechanisms
> and such.
> 
> I realize that the "no duplicate nexus" goal does not strictly
> require A (hence neither B), but I recommend that A be mandated,
> thus automatically making B an additional requirement for initiator
> configurations.  Rev08 iSCSI draft seems to refer to A and B
> in section 9 (implementation notes) as "should".  Was there a
> concern about the appropriateness of mandating A and B in the
> main modeling discussion?  They appear fairly straightforward
> to implement.
> 
> If the reasoning was not to require _any_ configuration of an
> iSCSI NIC, I would argue that you require some "name" to be
> configurable anytime you want to build a logically monolithic
> entity (as in a node) from smaller components (each of which
> can act as a logically independent entity in its own right).
> 
> Comments from NDT and/or Julian would help.
> 
> Thanks.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> 
> 
>