Re: iSCSI: Markers

[Jonathan Stone <jonathan@dsg.stanford.edu>]

In message <NMEALCLOIBCHBDHLCMIJIEBHCKAA.somesh_gupta@silverbacksystems.com>,
"Somesh Gupta" writes:

>I think the objections are to more to changing TCP wire
>protocol (i.e. header) than to the implementation.
>
>Also with NFS, there are two things.
>1. There is some built-in containment in NAS which does
>provide some protection again "buggy" implementation/administration/
>deliberate access to the wrong data. SANs as a rule require the
>clients to be much better behaved.
>2. The security problems are recognized and being addressed in
>newer revs - also a sign that protocols can evolve. Would it
>be better to have everything in up-front - of course. But in
>this case, the evidence isn't there - and to make a choice
>just to accomodate - "software implementation but no rolling
>of the COWS in the copy or checksum loop, and which does not
>do CRC" and "in a hurry"??

Somesh,

Part of the message seems to've suffered packet drop.

I can, and do, change my TCP implementation.  The gotcha is that
folding another operation into the existing loops in my TCP protocol--
whether it's COBS or COWS or a CRC -- *IS* changing my TCP
implementation.  Even if it doesn't change the on-the wire semantics,
its still a change to my TCP.

In fact, it's easier for me to change my TCP to make it guarantee to
preserve any segment boundaries between iSCSI PDUs[*], than it is to
fold iSCSI-PDU processing into TCP processing.


[*] when sending/retransmitting, that is.
If we could guarantee that, hardware-accelerated receiers could use a
TCP header option to indicate start-of-frame in this segment, and be
done with it.  I'd even to go to bat with the transport-area
representative, arguing that the ratio of iSCSI PDUs to expected drops
is ``small enough'' that using that portion of the limited TCP option
space for non-SACK usage was in fact a good trade-off.  (My
understanding is that it's not really necessary to mark *all* PDU
boundaries, just to mark enough of them to permit a reassembly buffer
significantly smaller than BW*RTT, which therefore doesn't require
lots of external SRAM; while still allowing direct data placement.)

I understand that  door is well and truly closed, though.