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

> No new wire protocol is required.

Please explain to me how credit can be replenished
in the following example - without new positive flow 
control protocol.

An initiator sends an immediate command in an untagged
message to the target (and thus consumes one "fringe" credit).

Considerations: a) CmdSN is not unique, can't be acked.
b) target may discard it, or may process it c) no assumptions
can be made based on  subsequent command processing.

The other specific iSCSI PDU types that I listed present
a similar "problem" - for both directions.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email protected]

----- Original Message ----- 
From: "Caitlin Bestler" <[email protected]>
To: "Mallikarjun C." <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Wednesday, July 30, 2003 6:10 PM
Subject: [rddp] Re: iSCSI/iWARP drafts and flow control


> 
> On Wednesday, July 30, 2003, at 07:49 PM, Mallikarjun C. wrote:
> 
> >
> >> There is an identical flow control issue for
> >> RDMA Reads.
> >
> > Not true.  There's a built-in credit renewal in an RDMA Read.
> > The Peer issuing the RDMA Read knows it can reuse the
> > Read credit when it receives an RDMA Read Response.
> > Send Messages carrying the "fringe" iSCSI PDUs need both
> > new wire protocol and cross-layer chit-chat within an end-node
> > between iSCSI and iSER - in order to renew credits.
> 
> No new wire protocol is required.
> 
> Restoration of no-CmdSNs credits could be piggy-backed on top
> of the existing CmdSN credit system.
> 
> Basically each Cmd reply restores one "Cmd Credit". It could
> also restore an implicit number of "NoCmd" credits. Basically
> if Cmd X had been proceeded by Y "NoCmd" messages, then the
> reply to Cmd X would restore Y "NoCmd" credits.
> 
> It is simple credit counting, suitable for implementation in
> hardware or software at any number of layers, and requires
> no additional wire messages or even fields.
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>