Subject: RE: [Ips] NOP-IN question

From: "Pat Thaler" <[email-masked]>
Date: Thu, 18 Oct 2007 14:30:33 -0700

Ken,

There are MUSTs that require a target to send NOP-IN at times. See
10.4.11 on updating MaxCmdSN and 10.19 on resonding to an initiator
ping.  A requirement to have only one "on the wire" wouldn't be
consistant with that. Also, since StatSN isn't advanced for a NOP
initiated by the target and the one sent to update SN values gets no
response from the initiator, the target doesn't know whether that type
of SN is still in transit.  Possibly at one time there was text about
not sending too many of the target-initiated ping NOP-In PDUs but I
don't see anything in the RFC.

Regards,
Pat 

-----Original Message-----
From: Sandars, Ken [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2007 5:18 PM
To: Ken Craig; [email-masked]
Subject: RE: [Ips] NOP-IN question

Hi Ken,

I can't recall that limit being suggested, nor can I find anything in
the docs.
Given the number of reasons a Nop-In may be generated it seems like an
unusual hurdle to have introduced (ping response, target-initiated ping,
target soliciting ExpStatSN, target advertising new CmdSN counter
values).

Cheers,
Ken Sandars

-----Original Message-----
From: Ken Craig [mailto:[email-masked]] 
Sent: Saturday, 22 September 2007 04:40
To: [email-masked]
Subject: [Ips] NOP-IN question

During my Target development I convinced myself that somewhere in the
RFC I read that only one Target originated NOP IN was allowed on the
wire at a time per Connection.  However I can no longer find anything
like that in the latest RFC or addendums.  I would like to know if I was
dreaming or can someone point me to a place somewhere where the
statement is made.

Thanks,
Ken Craig

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

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

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 24 Oct 2007 08:20:08 -0700

On Sep 21, 2007, at 11:40 AM, Ken Craig wrote:

> During my Target development I convinced
> myself that somewhere in the RFC I read
> that only one Target originated NOP IN
> was allowed on the wire at a time per
> Connection.  However I can no longer find
> anything like that in the latest RFC or
> addendums.  I would like to know if I was
> dreaming or can someone point me to a
> place somewhere where the statement is
> made.
>
> Thanks,
> Ken Craig
>
>

Section 8.1 of the iSER draft discusses the need to regulate  
Unexpected messages
sent over an iSER connection, and defines a  
'MaxOutstandingUnexpectedPDUs'
key to regulate this behavior.

An RDMA receiver (iSER or not) must pre-post untagged buffers. If it  
fails to do so
the connection is torn down when the N+1st untagged message shows up.  
How
it does so is left to each ULP. The 'MaxOutstandingUnexpectedPDUs'  
key enables
iSER receivers to safely provision their untagged buffer pool (in  
combination with
the existing logic that tells them how many expected PDUs to allow for).

With plain iSCSI there is a presumption that an excessive number of  
unexpected
messages will *stall* the connection, but not tear it down. Therefore  
there is no
need for any explicit requirements on avoiding this situation.