|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [rddp] Re: iSCSI/iWARP drafts and flow controlOn Thursday, July 31, 2003, at 07:43 PM, Mallikarjun C. wrote: >> 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. I thought of at least one algorithm overnight. This is not presented as a definitive proposal, merely to show a strategy that can allow iSER to provide flow control of *all* untagged messages. iSER untagged messages are divided into a predictable portion regulated by CmdSNs in a very direct fashion and asynchronous messages. The latter category can be characterized as having a low sustained rate compared to the CmdSN-related untagged messages, but that the traffic is very bursty. That is, the peak rate can be high. That suggests adapting a classic "leaky bucket" credit system of the type typically used to regulate burst traffic over rate controlled networks. The key difference is that the "clock" is the Max CmdSN. What is required is the following: The sender maintains a asynch-credit counter. It is initialized to a known value. This value could be negotiated if it is believed that there is enough variation to warrant negotiation, otherwise it would be fixed. That caveat applies to all other "constants" cited in this algorithm. When the ULP desires to send an untagged message using one of these credits: The credit count is brought up to date: The current Max CmdSN is compared with the value when the prior "fringe" send was performed. The delta is used to grant new credits, however there is a maximum number of credits that may be accumulated. If there are enough credits: the credit count is reduced and the untagged message may be sent. If there are not enough credits: the untagged message must be delayed until the Max CmdSN is advanced. After a configurable delay, iSER SHOULD send some form of NOP command to cause Max CmdSN to advance. Note that there are NO iSER defined messages for the purpose of flow control. Untagged messages may be delayed, but that could happen over TCP just as easily. The only change is that *only* untagged messages will be delayed, never tagged messages, and *where* they are delayed (iSER versus TCP).
Home Last updated: Tue Aug 05 12:46:07 2003 12771 messages in chronological order |