Subject: [rddp] Re: iSCSI/iWARP drafts and flow control

From: Mike Ko <[email-masked]>
Date: Fri, 8 Aug 2003 14:32:02 -0700

Since the Asynchronous Message is associated with a StatSN, instead of 
waiting for the initiator to send "a command with CmdSN that was only 
enabled after the non-responding target message", another possibility is 
to wait for the initiator to send any PDU containing the ExtStatSN field 
that acknowledges that the particular StatSN has been received.

Mike Ko
IBM Almaden Research
[email-masked]

To:     Mike Ko <[email-masked]>
cc:     <[email-masked]>, <[email-masked]> 
Subject:        Re: iSCSI/iWARP drafts and flow control

On Thursday, August 7, 2003, at 12:52 PM, Mike Ko wrote:

> Caitlin, since MaxCmdSN is used by the target to limit the number of
> commands it can receive from the initiator, your suggestion would work
> for
> limiting the number of "fringe" messages the initiator can send to the
> target.  However, for "fringe" messages from the target to the
> initiator,
> such as the Aysnchronous Message, the target cannot simply raise
> MaxCmdSN
> and expect the initiator to increase the number of receive buffers for
> "fringe" messages correspondingly.

The target may always send untagged messages when they are
a response to an initiator request. Additionally the target
may have N extra outstanding untagged messages, where N is
a protocol constant or negotiated for the session.

A non-responding target message is "outstanding" until
one of the following occurs:

The initiator responds to a "Nop Out Request".

The initiator sends a command with CmdSN that
was only enabled after the non-responding target
message.

The fact that a prior non-responding target untagged
message is no longer "outstanding" merely means that
whatever buffers are allocated for this purpose have
been replaced. It does not guarantee that the initiator
has completed any associated processing, that logic
is left totally to the ULP.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 9 Aug 2003 13:43:55 -0500

> that acknowledges that the particular StatSN has been received.

Even better.

I am not favoring any specific mechanism, just saying that
mechanisms exist -- and that they do not have to be an
explicit "protocol".

Note that none of the algorithms described, including your
suggestion, require the receiver to calculate or issue
credits. They merely have to replenish buffers in manner
consistent with the rules. They can also be sloppy about
it if they have slop in their buffers.

The rules suggested shift the burden of flow control
to the sender, where it should be. Rule enforcement
at the sending side can also be quite lax if other
implementation specific rules limit the number of
untagged messages that could be sent.

Caitlin Bestler - [email-masked] - http://asomi.com/

---

From: [email-masked]
Date: Fri, 15 Aug 2003 14:12:00 -0700 (PDT)

> untagged messages that could be sent.

Sorry for my delay in responding.

One of the things I've been wondering through this whole thread is can't
we expand iSCSI negotiation to handle these parameters (like how many
async messages are ok, how many immediate commands, etc.)? That way, to
the extent that iSCSI/iWARP needs new parameters, we can decide on them
out easily.

Maybe it's been in everyone's thoughts, but the thread had been talking
about needing new limits and talking like it's hard to do. Can't we just
negotiate them?

Take care,

Bill

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 15 Aug 2003 17:13:37 -0500

> about needing new limits and talking like it's hard to do. Can't we 

Bill,

There are two separate issues.

The first is establishing what the credit limits are. That could
be negotiated on a per session basis, or it could be established
by the draft as a simple rule. You are correct that negotiating
is not terribly complex. Therefore, if there is *any* benefit to
varying those limits on a per-session basis, then negotiations
should be allowed.

So far, however, I do not believe that anyone has identified
a specific need for per-session negotiation of these credits.

The second issue is the mechanism by which credits are replenished.
The iSER draft authors were opposed to creation of additional
messages to exchange credits. My contention is that under virtually
all circumstances, credit replenishment can be inferred from
existing message exchanges. Under worst case circumstances a
"NOP" might have to be sent that would not have otherwise
been required. No additional message types are required.

I believe the last few prior exchanges may have established
that tracking credits is not as onerous as the draft authors
had originally thought. But it is on that issue, not the
overhead of negotiation during setup, that was their concern.