|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iscsi : iscsi parameter default valuesWould all cases look like these? (If I made a mistake, please correct it). Note that I am attempting to use the rule specified as: The negotiation MAY proceed only up to the point where both parties can unequivocally compute the result; continuing beyond this point is OPTIONAL. And my interpretation of the rule is that when a responder gets a binary value, it can compare that against the default and can therefore compute the result and therefore does not need to respond if the result is what he wants. Am I correct in my interpretation? Eddy Default ImmediateData="yes" =========================== Initiator wants immediate data & target supports it. --------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 yes * yes = yes Initiator does not want immediate data & target supports it. ----------------------------------------------------------- I -> T : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * yes = no Initiator wants immediate data & target does not support it. ----------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 yes * no = no Initiator does not want immediate data & does not target support it. ------------------------------------------------------------------- I -> T : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * yes = no Default ImmediateData="no" ========================== Initiator wants immediate data & target supports it. ----------------------------------------------------------- I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) yes * no = no Initiator does not want immediate data & target supports it. -------------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent) (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) no * no = no Initiator wants immediate data & target does not support it. ----------------------------------------------------------- I -> T : ImmediateData="yes". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 yes * no = no Initiator does not want immediate data & does not target support it. ------------------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * no = no Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Monday, October 01, 2001 7:16 PM To: John Hufferd Cc: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values John Hufferd wrote: > > I think your logic reverses if the support wanted is yes and the target is > supporting yes. How so ? Here are the scenarios when initiator wants to use immediate data and target supports it, first with default ImmediateData set to "yes" and then, with default Immediatedata set to "no". In both cases, a single login handshake occurs. The only difference being that when ImmediateData defaults to "yes", the key need not be sent in either direction, whereas when it defaults to no, the ImmediateData key travels in both directions in the login payload. (FFP = FullFeaturePhase). Default ImmediateData="yes" --------------------------- Initator wants immediate data & targets supports it. ---------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 Default ImmediateData="no" -------------------------- Initiator wants immediate data and target supports it. ----------------------------------------------------------- I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : Immediatedata="yes" (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) Same number of handshakes in both cases. The only difference is that the key is not sent in the first case, and key is explicitly exchanged in the 2nd case. > If they say No they clearly do not care about extra handshakes sense R2T is > all they have and it requires extra handshakes. Hmm.... The way I see it, an initiator that does not use ImmediateData is a simple initiator and is more interested in seeing a simpler login (completed in a single login req/rsp) than one that does support ImmediateData. Those implementations that can do the extra work of supporting ImmediateData can well do the extra work of negotiating for its use. Regards, Santosh
Home Last updated: Tue Oct 02 13:17:19 2001 6963 messages in chronological order |