Re: iSCSI: multiple sessions b/n a pair of WWUIs.

[Pierre Labat <pierre_labat@hp.com>]

John,


John Hufferd wrote:

> Pierre,
> You are correct when you create a second session from the same (i)SCSI
> Initiator Device (iSCSI Initiator Node) using a different ISID, it becomes
> another (i)SCSI Initiator Delivery PORT (I took some freedom and preceded
> the SCSI PORT with an "i". to denote that it is used with iSCSI, no
> significant in the name it is still a SCSI Delivery Port (SDP), and in this
> case a SCSI Initiator Delivery Port or SIDP or (i)SIDP or .......
>
> There should have  been nothing in my note that tied the (i)SCSI Initiator
> Delivery Port to any HW.  (It can be, but that was not what I was
> addressing.)

OK

>
>
> As soon as the second session is started, to the same Target Device (but
> with a different ISID), you now have new (i)SCSI Initiator Delivery Port
> and an issue of determining how you handle the delivery of commands, in
> what kind of order, etc.  since the same LUs can be address across the
> different sessions.  This is where the complications of Wedge Drivers
> (active and passive) come into effect.

It can be too, a configuration where each of the 2 (for ex) sessions access
a separate subset of luns of the target. In this case the ordering is not
violated
and some implementations/applications (can be something else than wedge
driver) could make benefit from that.
It's a legal configuration that the spec must allow.

Regards,

Pierre

>
>
> The value of Multiple Connections per Session, is that they have  built-in
> load balancing and order delivery.  This is usually easier to deal with
> then Multiple SCSI Delivery Ports and Wedge Drivers.
>
> If you reread my note, you should find that we are saying the same thing
> (now that you understand my free use of the "i" ).
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Internet address: hufferd@us.ibm.com
>
> Pierre Labat <pierre_labat@hp.com>@ece.cmu.edu on 05/09/2001 09:52:50 AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.
>
> John Hufferd wrote:
>
> > Santosh,
> > I think I am beginning to see the problem.  A given iSCSI Initiator Port
> > can NOT have a second session with the same iSCSI Initiator Port and be
> > consistent with SCSIness.  The second session could be started with
> another
> > ISID, (to the same iSCSI Target Port) but if the session was established
> it
> > would not have any of its commands and data handled via any techniques
> > defined by SCSI or iSCSI.  In fact its use would require a wedge driver.
> > This is the exact confusion I was trying to avoid.  Technically if you
> were
> > actually able to start another Session to the same Target Port, it would
> > be, by definition another iSCSI Initiator Port.   The two different Ports
> > would need to be coordinated by what we have been calling a Wedge Driver.
> >
> > Today, the way we use multiple Fibre Channel Initiator Ports connected to
> > the same Fibre Channel Target Ports is by use of Wedge Drivers.  I think
> > what you are suggesting causes the need for a Wedge Drivers to integrate
> > the iSCSI Initiator Ports.  Not sure that we want to cause this type of
> > thinking, by accident.  One of the reasons for Multiple Connections per
> > Session was to remove the "Hard" need for Wedge Drivers.
>
> John,
> Could you give your exact definition of a iSCSI port.
> Till your mails they were the definition of
> - a "portal" (IP add),
> - a SCSI service delivery port (=session end point from what i hearded in
> Nashua)
>
> It seems that you want to tie the  notion of SCSI service delivery port
> to hardware, the opposite of what was presented in Nashua.
>
> Do i miss something?
>
> I see nothing wrong against SCSI or iSCSI to have two sessions (with 2 #
> ISID) flowing from the same initiator adapter to the same target adapter.
> Each session end point represents a SDP.
>
> Regards,
>
> Pierre
>
> >
> >
> > OK, that's what I think our misunderstanding is all about.  If I am
> > mistaken, please set me straight.
> > .
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/SSG San Jose Ca
> > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > Internet address: hufferd@us.ibm.com
> >
> > Santosh Rao <santoshr@cup.hp.com>@cup.hp.com on 05/08/2001 05:44:41 PM
> >
> > Sent by:  santoshr@cup.hp.com
> >
> > To:   John Hufferd/San Jose/IBM@IBMUS
> > cc:   Black_David@emc.com, ips@ece.cmu.edu
> > Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.
> >
> > John,
> >
> > By the name-disc definition, an iSCSI initiator or target port is a
> > logical entity that constitutes the end points of a session.
> >
> > Hence, there never can be 2 sessions b/n the *same* 2  initiator &
> > target port. Each session established spawns a *new* initiator and
> > target iSCSI port.
> >
> > Going by the above semantics, there is always only 1 ISID/TSID per iSCSI
> > Initiator/Target port.
> >
> > Hence, I'm unable to understand your statements below.
> >
> > As for the uniqueness of ISID across all initiators, is there any reason
> > not to allow implementations to do that ? I would have thought that is
> > the most typical use of an ISID and also allows initiators to lookup
> > their target structures based on ISID.
> >
> > Regards,
> > Santosh
> >
> > John Hufferd wrote:
> > >
> > > Also, since a second session by the same iSCSI Initiator Port, to the
> > same
> > > iSCSI Target Port is not, in my opinion "legal", it is not clear to me
> > that
> > > any given iSCSI Port needs any more then one ISID.  I
> > >
> > > Therefore, I suggest that we Not put any such notes, like you suggest,
> in
> > > the draft, but in fact encourage a single ISID/TSID per iSCSI
> > > Initiator/Target Port.
> >
> > > To:   Jim Hafner/Almaden/IBM@IBMUS, marjorie_krueger@hp.com
> > > cc:   ips@ece.cmu.edu
> > > Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.
> > >
> > > While Jim's correct ... in Marj's defense, what
> > > she wrote is a fairly obvious way to implement
> > > it, and that might be worth noting in the draft.
> > >
> > > --David