RE: iSCSI: Markers

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

> -----Original Message-----
> From: Jonathan Stone [mailto:jonathan@DSG.Stanford.EDU]
> Sent: Thursday, January 10, 2002 11:42 AM
> To: somesh_gupta@silverbacksystems.com
> Cc: John Hufferd; ips@ece.cmu.edu
> Subject: Re: iSCSI: Markers 
> 
> 
> 
> 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.

  Yes and at least the IETF should not object to that part. John was
  referring to the fact that iSCSI charter states no changes to
  TCP (and by that I mean protocol). Even markers require changes
  to TCP on the receiver end, and fairly heavy at that.

> 
> 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.

  By PDU processing do you imply
  doing the word stuffing processing? It should be something
  that can be rolled into the copy loop (if iSCSI is in user space
  and one of the applications that John referred to in the past)
  or into the checksum loop (if iSCSI is in the kernel space), or
  into the CRC loop.
 
  NOTE: If the data is touched once anyway, the cost of an additional
  touch is fairly minimal because everything is in the processor cache.

  The worst case is an accelerated NIC which does everything except
  COWS and CRC - the sender uses iSCSI, does not to do CRC, but
  does do COWS. This requires an extra touch.

> 
> 
> [*] 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.

  Actually as someone pointed out at the last IETF, the timestamp
  option wastes a couple of bytes(?). Seems like an opportunity
  without adding overhead. That is really the right way but people
  point at all sorts of misbehaving middle boxes.

  The advantage with COWS is that detection of alignment is
  deterministic.
> 
>