Subject: [Ips] Separation of MaxOutstandingUnexpectedPDUs into 2 keys, for initiator and target

From: "Alex Nezhinsky" <[email-masked]>
Date: Thu, 17 Mar 2005 21:14:52 +0200

Mike, 
 
Here is the definition from the last spec:
> MaxOutstandingUnexpectedPDUs - This key is used by the initiator and 
> the target to declare the maximum number of outstanding "unexpected" 
> control-type PDUs that it can receive. It is intended to allow the 
> receiving side to determine the amount of buffer resources needed
beyond the normal flow control mechanism available in iSCSI.
> ... 
> If the sending side fails to adhere to the declared limit as set by 
> the receiving side, it is up to the receiving side to determine ways
of
> handling the overrun, including dropping the connection."

The current model of using NoticeKeyValue, as far as I understand it,
implies that the operational keys, for which the final values are
reported, have a single well-defined interpretation. It should be
absolutely clear to the iSER layer from a key name only, if its value is
the result of negotiation, has been declared by the remote side or has
been declared by the local side. 

This allows the iSER layer not to read the contents of Login Req/Resp
PDUs and rely upon the values passed through NoticeKeyValue() only.
Values that are not communicated during the login phase are supposed to
be passed from iSCSI to iSER by some implementation-specific means.

This is the only reason I can find for having separate
InitiatorRecvDataSegmentLength and TargetRecvDataSegmentLength keys. If
NoticeKeyValue() had an rx/tx "context", then having plain
MaxRecvDataSegmentLength would be enough.

Similar logic may be applied to MaxOutstandingUnexpectedPDUs, because
the same key is sent by both sides and both values (rx & tx) are of
interest for iSER. So we have a problem here - only one of the values
may be passed to NoticeKeyValue(). So I'd suggest to replace the
existing key MaxOutstandingUnexpectedPDUs with 2 new keys:
InitiatorMaxOutstandingUnexpectedPDUs and
TargetMaxOutstandingUnexpectedPDUs, both declarative, where
InitiatorMaxOutstandingUnexpectedPDUs is the value sent by the initiator
to the target, designating the maximum number of unexpected PDUs the
initiator may be expected to receive. TargetMaxOutstandingUnexpectedPDUs
is just reversed.

What do you think?

Alexander Nezhinsky

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Mike Ko <[email-masked]>
Date: Thu, 17 Mar 2005 16:37:14 -0800

Alex,

Since the MaxOutstandingUnexpectedPDUs key is declared, not negotiated, 
the value declared by the iSCSI layer should be in line with the 
capability as implemented in the iSER layer and should be known by the 
iSER layer.  The only MaxOutstandingUnexpectedPDUs key-value pair that the 
iSCSI layer needs to convey to the iSER layer via the Notice_Key_Values 
primitive is that which is delcared by the other side.  Hence I don't see 
the need to create separate keys for the initiator and the target.

Mike
Sent by:        [email-masked]
To:     "Mike Ko" <[email-masked]>
cc:     [email-masked] 
Subject:        [Ips] Separation of MaxOutstandingUnexpectedPDUs into 2 
keys,   for initiator and target

Mike, 
 
> the  receiving side, it is up to the receiving side to determine ways of

This allows the iSER layer not to read the contents  of Login Req/Resp 
PDUs and rely upon the values passed through NoticeKeyValue()  only. 
Values that are not communicated during the login phase are supposed to be 
 passed from iSCSI to iSER by some implementation-specific means.

Similar logic may  be applied to MaxOutstandingUnexpectedPDUs, because the 
same key is  sent by both sides and both values (rx & tx) are of interest 
for iSER. So we  have a problem here - only one of the values may be 
passed to NoticeKeyValue().  So I'd  suggest to replace the existing key 
MaxOutstandingUnexpectedPDUs with 2 new  keys:
InitiatorMaxOutstandingUnexpectedPDUs and 
TargetMaxOutstandingUnexpectedPDUs, both  declarative, where 
InitiatorMaxOutstandingUnexpectedPDUs is the value sent by  the initiator 
to the target, designating the maximum number of unexpected  PDUs the 
initiator may be expected to receive.  TargetMaxOutstandingUnexpectedPDUs 
is just reversed.

What do you  think?

Alexander  Nezhinsky