|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iscsi : numerical negotiation wording is ambiguousSanjeev, 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 ##################################
Home Last updated: Mon Oct 01 16:17:21 2001 6940 messages in chronological order |