Re: iSCSI: new draft

[Matt Wakeley <matt_wakeley@agilent.com>]

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:

> Am I missing something?  As David states, it's the TCP layer that will
> handle SACK and recovering segments.  The iSCSI layer will always have to
> buffer the full iSCSI message...
>
> To review: (in a single session scenario)
> TCP has buffering requirements of <window size>
> iSCSI has buffering requirements of <SCSI message size>
>
> The iSCSI layer must "buffer" data (somewhere) until a complete iSCSI
> message has arrived.
>
> If you are worried about "having to pile-up a lot of data in an adaptor or a
> separate memory area until you can figure where to put it" - isn't this what
> TCP's sliding window controls?  When this begins to happen (because a packet
> was dropped), the receiving TCP can decrease it's window size advertisement.

The problem is, at higher and higher link rates over longer and longer
distances, you need to make the window size huge to keep "data flowing in the
pipe", in the order of megabytes of window size.

Also, as Julian pointed out in another message, it's better to place data in the
right place the first time, rather than copy it.


> If you are using standard TCP implementations, and the iSCSI layer is
> strictly an application, it will NEVER receive out of order data.  It will
> always know message demarkation from the iSCSI header length field.  The use
> of the urgent pointer won't break this sort of implementation, but it won't
> necessarily augment it either.

Agreed, legacy TCP implementations and/or iSCSI in software applications will
see no benefit.


> It seems to me the only time "framing markers" are useful (other than for
> facilitating protocol analyzers) is when you have an "accelerated" custom
> implementation of iSCSI/TCP where the iSCSI and TCP stack are intimately
> interconnected.  In this case, framing markers of any kind allow the iSCSI
> layer to "sync up" framing when interim packets have been lost (somewhat
> independantly from the TCP mechanism).

Exactly what was intended!

>  But what good will this do?  Would
> an implementation deliver subsequent SCSI frames if you are missing a
> preceeding frame?

It could, but the real benefit is what Julian stated in his reply: place the
data in the right place the first time.  If there was no "framing", data would
have to be piled up somewhere, then sorted out and recopied when all the missing
data arrived.

>  And if it did, what will it do in the TCP layer to
> indicate those "out of order" bytes have already been delivered?

It won't be able to do anything in the TCP layer to indicate those bytes have
been delivered.  That would break the existing TCP model.  The only thing it
could do is use the SACK option to help the sending TCP reduce the amount of
retransmitted data.


> This sort of implementation will maintain a fuzzy boundary between TCP and
> iSCSI. (just a statement, not a criticism)

>
>
> Go ahead, flame me if this has already been discussed, I admit I'm still
> catching up on my "reflector reading".
>
> Marjorie Krueger
> Networked Storage Architecture
> Hewlett-Packard Storage Organization
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com

-Matt Wakeley
Agilent Technologies