Re: iSCSI: Markers

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

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

>  By PDU processing do you imply
>  doing the word stuffing processing? 

Yes, that's part of it.

>  It should be something
>  that can be rolled into the copy loop (if iSCSI is in user space
  [...]

This is still a change to the TCP _implementation_. Only the
implementor of the TCP and the kernel/user boundary can do it, and it
has to be tied, somehow, to the particular socket/fd/whatever is using
not just TCP, but iSCSI-over-TCP.

The issue I see here isn't IETF mandates: its that reasonable-quality
software implementations require changes to code which may well be
beyond the control (or even the access) of the iSCSI implementor.


>  NOTE: If the data is touched once anyway, the cost of an additional
>  touch is fairly minimal because everything is in the processor cache.

No, it isn't, not always.  I can think of at least three SIGCOM/TON
papers, measuring data on top-end 1996 vintage machines, on which this
assumption has been conclusively shown to be wrong. That
price/performance point is still quite viable.  Torsten Braun and
Christoph Diot had one paper in SIGCOMM 95 and later in ToN; I dont
recall the other one (my Stanford office papers are all packed).

I can't speak to COWS. I have done a COBS implementation, and the
byte-insertion meant that COBS dirtied every cache line; it turned out
simpler and faster to just do another copy.


[...]

[header options]

My understanding is that the limited option space, and the rather
large demand on it which SACK can generate in wide-area links
(transatlantic can regularly show 50% drop rate!), means our friendly
transport representatives are reluctant to admit further use of TCP options.

As I said, I'm willing to examine the numbers with the people I know.
I'd be for it, myself.