RE: iscsi : numerical negotiation wording is ambiguous

["Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>]

Oke, i can accept this because  a renogotiation still allows some room for
flexibility where a little misbehaving devices can still work.

So if we come to conclusion of this thread we dont need an reject message in
both case and there should be a consensus call for the way of negotiation
whether (initiator determined negotiation or responder determined)

Sanjeev          

-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com]
Sent: Monday, October 01, 2001 9:07 PM
To: Sanjeev Bhagat (TRIPACE/Zoetermeer)
Cc: ips@ece.cmu.edu
Subject: Re: iscsi : numerical negotiation wording is ambiguous


Sanjeev,

I do not believe your example is in line with the discussion. I'd rather
you considered the case of an FC initiator that got back a PLOGI
response with parameters that are not acceptable for that initiator. Do
you expect the initiator to send a LS_RJT to the target ??? 

I would hope not :)

The FC initiator would give up on that Nx_Port and move onto another
one. Ditto for iSCSI. Either re-negotiate parameters, or close the TCP
connection. REJECTs are only sent from targets to initiators.

Regards,
Santosh



"Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> 
> Julian, Santosh,
> 
> Here is what i have to say
> 
> In either of the cases reject message is not needed if there is no double
> check required.
> 
> A reject is needed in both cases to allow some flexibility and i will give
> you an example for this
> 
> All SCSI devices today available have Sync options for more than 10MB/sec.
> 
> Consider a chip designed which works fine for sync negotiation rate of
> upto40MB/sec but misbehaves or behaves illegally for sync options less
than
> 10 MB/sec. In such case a device driver for such a chip will start
> negotiating with the SCSI device for 40 MB/sec. If the SCSI device returns
a
> value of 8MB/sec then in this case the device driver must send a reject
> message for sync negotiation. (although it is an illegal condition but it
> still allows room for slightly misbehaving devices to operate properly in
> Non-SYNC mode). This is my basis of saying that we must have a reject
> message in both cases although it is strictly not required.
> 
> Sanjeev
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Monday, October 01, 2001 8:38 PM
> To: ips@ece.cmu.edu
> Cc: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Julian Satran'
> Subject: Re: iscsi : numerical negotiation wording is ambiguous
> 
> Julian & Sanjeev,
> 
> Responding to both your mails......
> 
> Julian :
> 
> I think you may have mis-interpreted my comments. I believe Sanjeev has
> clarified the intent of my suggestions.
> 
> I am *not* suggesting that the responder send back its values and these
> be blindly imposed on the originator. On the contrary, my suggestion is
> that the computation of the result of the negotiation (higher or lower
> of the 2 values) be only performed by the responder and sent back to the
> originator.
> 
> The result of the negotiation is the same in both cases and there is no
> REJECT required in my case nor yours. The difference is the advantages
> I've stated in my model.
> 
> Sanjeev, in response to your comment :
> 
> " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >  no reject , but it can be a problem in future .
> >  Consider your example of DataPDULength in your own
> >  message. Suppose offering party sends a value of 16,384
> >  (this is also lowest value it can send) and responding
> >  party responds with 8,192. In this case the offering
> >  party will have to reject the negotiation. So a reject
> >  message is needed in this case also. "
> 
> There is NO need for any REJECT in the above case. If the initiator
> is'nt satisfied with the value returned by the originator and cannot
> function with the negotiated values, it can simply close the TCP
> connection. There is no need to send any REJECT.
> 
> Thanks,
> Santosh
> 

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################