headers
Gwendal Grignou | 1 Dec 2004 02:55

Update StatSN after sending a Reject PDU

Hello,

I am wondering if the target must increase the connection StatSN after
sending a reject PDU.

In the RFC, it is stated

10.17.3 StatSN, ExpCmdSN and MaxCmdSN 
These fields carry their usual values and are not related to the
rejected command

It is not clear to me if StatSN must be incremented after sending the
PDU or not. I would say no, but I would like a confirmation.

Thank you,

Gwendal.

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Permalink | Reply | 0 comments |
headers
Buck Landry | 1 Dec 2004 03:37
Favicon

RE: Update StatSN after sending a Reject PDU

The final RFC 3720 10.17.3 (as opposed to draft20) states pretty clearly
"StatSN is advanced after a Reject."

I believe the full text says,
>>>
10.17.3.  StatSN, ExpCmdSN and MaxCmdSN

   These fields carry their usual values and are not related to the
   rejected command. StatSN is advanced after a Reject.
<<<

Hope this helps,
--buck

-----Original Message-----
From: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org]On Behalf Of
Gwendal Grignou
Sent: Tuesday, November 30, 2004 7:55 PM
To: ips <at> ietf.org
Subject: [Ips] Update StatSN after sending a Reject PDU

Hello,

I am wondering if the target must increase the connection StatSN after
sending a reject PDU.

In the RFC, it is stated

10.17.3 StatSN, ExpCmdSN and MaxCmdSN 
These fields carry their usual values and are not related to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
BillMurray | 1 Dec 2004 14:51
Favicon

Re: Clarification of MaxBurstLength parameter

That clears it up, thanks. 

> 
> TOTAL of a sequence not the whole command.
> 

> > Am I correct in thinking that MaxBurstLength governs the TOTAL amount
> > of solicited data sent across the 'entire sequence' of Data-in/Data-out
> > PDU's or is it the maximum length of just one Data-in/Data-out PDU?
> > 
> > 12.13.  MaxBurstLength
> > 
> > The initiator and target negotiate maximum SCSI data payload in bytes
> > in a Data-In or a solicited Data-Out iSCSI sequence.  A sequence
> > consists of one or more consecutive Data-In or Data-Out PDUs that end
> > with a Data-In or Data-Out PDU with the F bit set to one.
> > 
> > Thanks in advance,
> > Bill
> > 
> > 
> > _______________________________________________
> > Ips mailing list
> > Ips <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> 

_______________________________________________
Ips mailing list
Ips <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
elizabeth.rodriguez | 2 Dec 2004 09:50
Favicon

Changes to FC Mgmt MIB -- Please Review!


Hi all,

The FC Mgmt MIB has completed IETF last call, but as mentioned in the IETF
meeting in D.C.,
an IETF last call comment was inadvertently missed.  This change is the
addition of a column to the 
fcmSwitchTable.  Since this is a special circumstance, we will be addressing
this issue at this time.

In addition, there are a few other change that have been approved to go into
the draft, some editorial, and some which have been discussed on this list
before.
Please review the proposed changes that Keith lists below and discuss on the
ips list and/or get any feedback to Keith, David and I as soon as possible.
Should no discussion occur by Dec 9th, we will assume consensus and go forth
with these changes.

Thanks,

Elizabeth

> Forwarded message:
> > IP Storage (ips) WG - Washington DC minutes - DRAFT
> > ...
> > November 8, 2004 at the IETF meetings in Washington, DC.
> > ...
> > 	FC Management MIB (draft-ietf-ips-fcmgmt-mib-05.txt)
> > 	- New field to be added to deal with a MIB instance that
> > 	  covers multiple switches.  This was submitted as an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Ko | 6 Dec 2004 00:59
Picon
Favicon

iSER Open Issues

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mallikarjun C. | 7 Dec 2004 01:31
Picon

Re: iSER Open Issues

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

Mike Ko wrote:
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Caitlin Bestler | 7 Dec 2004 18:58

RE: iSER Open Issues


> From: "Mallikarjun C." <cbm <at> rose.hp.com>
> Subject: Re: [Ips] iSER Open Issues
> 
> 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).
> 

That is only true from the sending perspective, where "None"
essentially means "don't worry about it", and that does match
TCP semantics. You don't have to worry about overflowing the
target because TCP bottlenecking will efficiently prevent that.

But that is *not* the case at the other end. Instead of meaning,
"you can read these at whatever pace you want, it will only impact
Performance, not correctness" selecting "NONE" means you MUST at
least accept these messages from the transport layer at full speed.

I agree with the concern raised at the DC meeting that this is
not an appropriate default. An implementation that does not know
To set the key is probably *not* capable of meeting the requirements
of "NONE", and any capable of doing so would have no problem explicitly
setting the limit.

That said, explicitly setting the key is not that hard for *anyone*, so
What the default value is is really not that important, as long as it
is defined.

However, for simplicity of the specification I would recommend that it
(Continue reading)

Permalink | Reply | 501 comments |
headers
Pittman, Joseph | 8 Dec 2004 15:49
Picon

iSCSI: Session continuation and ERL=0

I have a question about session continuation and ErrorRecoveryLevel=0
sessions.
 
In short:
  In an ERL=0 session, is a session allowed to persist beyond
  the loss of its last constituent TCP connection?
 
I think the answer is yes, and my reasoning is based partly on
text in Section 5.3.6 of RFC3720.  That section describes
Session Continuation as
 
 "the process by which a preexisting session continues to be used
  by connection reinstatement... or by adding a connection
  with a new CID."
 
No mention is made of ErrorRecoveryLevel.  This leads me to think
that as long as the target supports session continuation in this
case, and as long as the initiator adds a new connection to the
session in a timely fashion, the session can survive loss of its
last TCP connection.
 

In general, my understanding is that, whenever ANY connection is
terminated on an ERL=0 session, all commands allegiant to THAT
connection are immediately terminated at the target.  But the
session can survive loss of any individual connection, subject to
target-imposed Time2Retain timeout after loss of the LAST connection.
 

Is my understanding correct?  Or am I missing something?
 
Thanks in advance, either for confirmation, or for setting me
straight.
 
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Permalink | Reply | 2 comments |
headers
BillMurray | 8 Dec 2004 18:39
Favicon

Distinction between format and protocol error

Sections 6.6 and 6.11 seem to clearly explain what
Format and Protocol Errors are and how they are
handled. However section 10 seems a bit contradictory
(unless reserved areas of the pdu header are not
considered fields).

How am I to interpret this?

Also, what is the difference between 'illegal' and
'inconsistent' in section 6.6 below?

6.6 Format Errors

The following two explicit violations of PDU layout rules are
format errors:

a) Illegal contents of any PDU header field except the Opcode
(legal values are specified in Section 10 iSCSI PDU Formats).
b) Inconsistent field contents (consistent field contents are
specified in Section 10 iSCSI PDU Formats).

10. iSCSI PDU Formats

Receipt of reserved code values in defined fields MUST be reported as a protocol error.

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Permalink | Reply | 3 comments |
headers
Mallikarjun C. | 9 Dec 2004 01:26
Picon

Re: RE: iSER Open Issues

 > But that is *not* the case at the other end.....selecting "NONE" 
means you MUST at
 > least accept these messages from the transport layer at full speed.

Let us not mix iSCSI-3720 semantics with what it means for RNICs that 
don't do graceful handling.

iSCSI-3720 places _no_ restrictions on how many unexpected PDUs must be 
received "at full speed" - the receiving iSCSI layer is allowed to 
discard an unexpected PDU without any processing and while the PDU is 
not received, the PDU sits in the transport buffers.

The thing I like about a "None" default is that an iSCSI-3720 pair that 
doesn't negotiate this key works the same way as an iSCSI-3720+iSER pair 
that chooses not to negotiate.

 > What the default value is is really not that important

Indeed.  Also what I said in the DC meeting.  Mike's request for list 
input was what prompted me.

Mallikarjun

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

Caitlin Bestler wrote:
>>From: "Mallikarjun C." <cbm <at> rose.hp.com>
>>Subject: Re: [Ips] iSER Open Issues
>>
>>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).
>>
> 
> 
> That is only true from the sending perspective, where "None"
> essentially means "don't worry about it", and that does match
> TCP semantics. You don't have to worry about overflowing the
> target because TCP bottlenecking will efficiently prevent that.
> 
> But that is *not* the case at the other end. Instead of meaning,
> "you can read these at whatever pace you want, it will only impact
> Performance, not correctness" selecting "NONE" means you MUST at
> least accept these messages from the transport layer at full speed.
> 
> I agree with the concern raised at the DC meeting that this is
> not an appropriate default. An implementation that does not know
> To set the key is probably *not* capable of meeting the requirements
> of "NONE", and any capable of doing so would have no problem explicitly
> setting the limit.
> 
> That said, explicitly setting the key is not that hard for *anyone*, so
> What the default value is is really not that important, as long as it
> is defined.
> 
> However, for simplicity of the specification I would recommend that it
> either be the minimum or "NONE". That way no third special value is 
> created.
> 
> 
> 
> 
> --
> Caitlin Bestler
> Director Software Architecture
> Siliquent Technologies
> caitlinb <at> siliquent.com
> 
> _______________________________________________
> Ips mailing list
> Ips <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Permalink | Reply | 501 comments |

Gmane