|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI - Change proposal Removing the X bitJulian When would the initiator decide to issue the cleaning NOP ? Would this be done on a sequence wraparound ? My one concern is that this puts the onus of doing things correctly on the initiator, and the target susceptible to initiator bugs. Here's an alternate idea.. It seems that for this scenario to occur the following condition must also be valid : A target MUST have a positive (expStatSN-statSN) for connection c1 when it receives c2&c3 in a new window on the same connection c1 - since the status acks are pending in-order after the retried c2&c3. If this is correct.. then would the following condition detect a connection which has gone stale ? A target MUST NOT allow a new CmdSN which is 2^31-1 greater than the unacknowledged status PDU for the last cmdSN sent on all connections. This would involve maintaining an additional counter per connection. (e.g. Connection->cmdSN_of_last_unacknowledged_statSN) In other words, if connection C1 sent status PDU for (c3) which has not yet been acked thru expStatSN, then the target will not allow a new command (Cn) which is 2^31-1 greater than c3. This must hold for all connections. This ensures that sequence wraparound does not cause old commands to reappear. Either the connection is closed or the target issues a NOP-IN which flushes that connection. If this is true, there is no need to issue the cleaning NOP since the target ensures that stale connections dont exist. Note that currently, we have a very loose requirement Sec 2.2.2.2 "A large difference between StatSN and ExpStatSN may indicate a failed connection." If we can strengthen this condition, we can ensure that the target as well as the initiator detect the sequence wrap-around without relying on one end too much. Comments ? -Sandeep Julian Satran wrote: > > Dear colleagues, > > We intend to publish very soon version 09 of the draft in its current > format (not many changes) and postpone the editorial changes (already under > way) for 10. > > One of the latest change proposal involves removing the X bit. > > The X bit has been used in several types of restart/replay but is somewhat > made redundant by the removal > of the command replay. > > This involves removing the X bit from request byte 0 and either making it > reserved or "shifting left" the rest of the general-use bits (I and the > direction bit). > > It also involves mandating a cleaning NOP. > > The cleaning NOP is needed in order to "flush out" old command PDU that can > be left over by simple sequences like the one in the following scenario: > > 2 connections > > On connection 1 I->T c1,c2,c3 > On connection 2 I->T c4,c5,c6 > > Targets receives everything and acts on commands but responses are sluggish > and initiators sees only an ack for > c1. It then retransmits c2, and c3 while there answer are in flight back > after which the connection is almost dead and not used by initiator. > > After a complete wrap around, involving only connection 2, the target > suddenly gets c2, c3 in a correct window and acts on them. > > The need to clean-up old PDUs is common to all protocols that use a > sequence that wraps and we suggested cleaning up using a NOP. We will > mandate a cleaning NOP only on connections that had at least one "retry". > > It looks like we might e able also to abandon the task management - > reassign function and do it with a reissue (with the same NOP cleanout > implication) since retiring the replay function makes the reassign > unambiguous (reissuing a command, after logout, on a new connection - > implies reassign). > > Please comment - I need your input urgently. > > Julo
Home Last updated: Fri Oct 26 20:17:29 2001 7415 messages in chronological order |