Subject: [Ips] iSER Open Issues

From: Mike Ko <[email-masked]>
Date: Sun, 5 Dec 2004 15:59:44 -0800

Here are the open issues on iSER from the last IETF meeting minutes:

1. "Draft will need to contain discussion of unexpected vs. expected PDUs 
and buffering requirements, and when an unexpected PDU ceases to be 
outstanding.  Add cautionary notes to avoid NOP-out and NOP-in abuse, but 
take this to the list, as there may be a possibility of being able to 
specify initiator behavior that always works."  The notes that I sent out 
on Nov. 11 and 12 after the IETF meeting with the subject titled "Updated 
text for MaxOutstandingUnexpectedPDUs for iSER" provided the new text for 
MaxOutstandUnexpectedPDUs.  A new subsection in section 8 under Flow 
Control will likely be created to contain part of the new text on buffer 
requirements for unexpected PDUs, retiring outstanding unexpected PDUs, 
etc.

2. "Using a key to limit # of outstanding unexpected PDUs is the right 
approach.  "None" = "No Limit" is allowed.  Minimum value (e.g., to avoid 
1 or 2) is TBD."  For the unexpected PDUs from the initiator to the 
target, 2 is the minimum per connection per RFC3720 which states that an 
"iSCSI target MUST be able to handle at least one immediate task 
management command and one immediate non-task-management iSCSI command per 
connection at any time".  So it seems that 2 is the minimum value for 
MaxOustandingUnexpectedPDUs.  Should it be bigger than 2?  If so, what 
should it be and what is the rationale?  A related question is should a 
different minimum value be defined for unexpected PDUs from the target to 
the initiator. 

3. "Specified default value (None vs. specific value) in absence of 
negotiation will be taken to list."  For the class of implementations that 
support SRQ, can replenish receive buffers as fast as the PDU arrival 
rate, and/or support graceful handling in lack of buffer situations, the 
choice of the default being "None" is the preferred value.  Alternatively 
for other implementations, the argument is for a specific default value 
which is finite (not "None").  The preferred default value for this class 
of implementations could be dependent on the implemenation itself.  The 
issue is also complicated by the negotiated value for MaxConnections.  So 
a finite default value might be acceptable only to a subclass consisting 
of single connection sessions.  What should this default value be and what 
is the rationale behind the selection?  Similarly, should a different 
default value be defined for both the initiator side and the target side?

Comments?

Mike
Sent by:        [email-masked]
To:     [email-masked]
cc:      
Subject:        RE: [Ips] Draft  DC minutes

Having seen no comments, these are the final minutes that will be
sent to the secretariat for the proceedings, and the decisions
made in DC are now the rough consensus of the IP Storage WG.

The iSER draft authors should take this as a cue to start
list discussion on their [Open Issue]'s identified below.

Thanks,
--David

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 06 Dec 2004 16:31:53 -0800

IMO, a default of None makes sense since these are essentially RFC 3720 
semantics (and RFC 3720-compliant implementations do not 
negotiate/understand the new key).

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com