|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Iterating long text responsesThe "bookmark" solution that Julian had mentioned is currently in the -98 version of the iSCSI draft at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-06-98.txt This solution is more akin to #3, since the target does need to keep track of bookmarks, and the initiator requests each piece. This doesn't seem quite as simple as #5, but it will work. Simple targets that will not return enough addresses to fill a 4k text response PDU would not have to implement the bookmarks at all. Anyway, this is a change from what we had been discussing on the list, so it's worth looking at, and would perhaps be a good thing to do a consensus call on so we can put this thing to rest either way. -- Mark Julian Satran wrote: > > I think that both 4 and 5 involve in fact some state to be kept at the > target between PDUs sent in something related to > to a "task control block" if we assume that all the text commands carry the > same ITT. > 4 enables the initiator to reuse its parse buffer while 5 requires the > initiator to allocate a buffer for all the text responses (or keep the pipe > closed). > 4 is simpler than 5. If you add to 4 a handle that the initiator has to > give back the target next time (the bookmark) > then the target does not have to keep state. > A 0 bookmark says start from the top. It is very much like an offset (that > was mentioned) but it is generic and opaque. > > Regards, > Julo > > Mark Bakke <mbakke@cisco.com> on 29-06-2001 23:18:20 > > Please respond to Mark Bakke <mbakke@cisco.com> > > To: IPS <ips@ece.cmu.edu> > cc: > Subject: iSCSI: Iterating long text responses > > Initiator developers- > > Please respond to the questions at the end. > > Thanks, > > Mark > > The current iSCSI draft allows text command and response > PDUs of up to 4096 bytes. While we don't see any real > problems for the command PDU size, commands such as SendTargets > can easily exceed the response size. > > There are several ways we can fix this. The first two solutions > require no differences in the current iSCSI text command and > response; the latter three involve the use of the F bit. > > 1. Assume that such commands are done on a "special" connection > or are handled completely in software, and allow its response > PDU to be as large as it needs to be. > > This one appears too restrictive to be a solid solution. It > will also weaken any data digests done on the longer PDU. > > 2. Create an iterative SendTargets key (and do the same for any > other text commands that need this), that would allow the > initiator to request the "next target" or "next address". > > This would work, but would require any new command that needed > a large response to implement an iterator. It also means that > each part of the response from the iterator would have to fit > in the 4k PDU. > > The remainder of these require that only one text command sequence > be outstanding on a connection at a given time. They use the F > bit to indicate the last PDU of the sequence. Note that connection > allegiance is assumed for the entire sequence, and text commands > are never retried on another connection; a new command is issued > instead. > > 3. Do a text-response R2T, where the initiator controls when the > next partial response is sent. This would be more generic: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > I->T Text Command (with some indicator that we want more) > T->I Text Response (next PDU, F bit cleared) > > ... > > I->T Text Command (with indicator that we want more) > T->I Text Response (last PDU, F bit set) > > The main problem with this is that the target must keep track > of the state of its responses; if the initiator just stops asking, > it may have to keep a buffered response around until it times out, > the connection is dropped, or another text command comes along. > > 4. Allow multiple response PDUs to a single text command: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > T->I Text Response (next PDU, F bit cleared) > > ... > > T->I Text Response (last PDU, F bit set) > > Basically, we are doing (3) without the R2T. The initiator, > upon sending the text command, must be prepared either to > accept as many PDUs as come back, or throw them away if it > can't handle them. This solution is a lot like #1, but with > the response spread across 4k PDUs. > > Also note that this (and the following scheme) avoid the problem > of the target keeping state; it sends ALL of the response PDUs > without the initiator asking for them. > > 5. Do #4, but allow the initiator to specify the amount of data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > In the above example, we have created a new text command field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k response. > The target returned the first 4k in the text response, but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than the > AcceptResponseLength, the initiator knows the amount of buffer > space it will need to get the full response. It can then choose > whether it will re-send the command, and if so, can give it a > large enough response length: > > I->T Text Command (F bit set, AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > Note that most initiators will probably send an AcceptResponseLength > of the largest response they would normally accept, and that most > target responses will fit in one or a few PDUs anyway. > > #5 is really a compromise between #3 and #4; the target has the > benefit of being less statefull, and the initiator has the benefit > of controlling the amount of data it receives. > > I would like to recommend either #4 or #5. I think that #5 is > probably the safest solution, but #4 may not be a problem for anyone. > > Assuming that none of the implementors of initiators have a problem > with #4, I would pick that. > > If they do have a problem with it, we should go with #5. > > Targets probably don't care much whether we do #4 or #5. > > Initiator developers- > > Please indicate which solution (#4 or #5) appeals to you. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054
Home Last updated: Tue Sep 04 01:04:16 2001 6315 messages in chronological order |