RE: Framing Formats

["Nate Lawson" <nate@decru.com>]

> From: owner-ips@ece.cmu.edu On Behalf Of Mike Parkhurst
> In my previous posting I was referring to the TCP-unaware variety. At
> the heart of the matter is whether we trust the underlying transport
> mechanism or not. If we don't, then there has to be some sort of
> error-recovery procedure for when information/data is lost in transit.
> If we do trust it, then the iSCSI specification is simplified and we
> assume that the protocol is riding on an error free link.

With TCP you get reliable delivery and sending rate adaptability for free.
Some posts on this thread have expressed sentiments doubting the reliability
of the transport which is surprising.

> Byte and word stuffing mechanisms have been proven to work for many
> years. Picking a 32 bit number reduces the chances of it showing up in
> the data stream. Even if it does the stuffing mechanism would mask it.

At least in the most naive case, this hurts performance since you have to
analyze more data looking for the marker than you would otherwise
(type/length/value or fixed size headers).  I certainly hope that I wouldn't
have to parse the data of a read looking for autosense data separated by a
marker.  If you have N bytes of data, here is a summary of the amount you'd
have to examine to retrieve a header:

Naive case (say SLIP over a serial link): N bytes
Fixed length packet size: 0 bytes
Fixed length header, variable data: ~4 bytes (length field)
Type/Length: 1 byte type, 4 byte length

The problem with fixed headers is that they're not expandable for future
protocols.  To be fair, TLV has a problem where if the length field gets
corrupted, you have to read up to the maximum number of bytes before
throwing away the PDU.  But I thought iSCSI will be depending on a reliable
transport.

In any case, TLV should be familiar since this is how SCSI cdbs work.

-Nate