Re: iSCSI/iWARP drafts and flow control

Caitlin Bestler <[email protected]>
Newsgroups gmane.ietf.ips,gmane.ietf.rddp
Message-ID <[email protected]>
On Friday, August 15, 2003, at 04:12 PM, [email protected] 
wrote:

> 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

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.





Caitlin Bestler - [email protected] - http://asomi.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.