RE: iSCSI : Reject PDU Concerns.

["Douglas Otis" <dotis@sanlight.net>]

Matt,

As both schemes are periodic, once an interval has been deciphered, a
boundary is discovered and can be applied to later data already in progress.
Once a sample has been scanned for typical PDU signatures, a trial intercept
should confirm success with little effort even at OC-192 rates.  By making
the intervals a modulo that is a power of 2, you would not need to be
concerned about potential wraps between efforts.

The evolution is called SCTP for transforming TCP into a frame aligned
object based protocol.  Such changes to TCP as you suggest will hardly end
with a flag here or there.

Doug


> I disagree with you Doug,
>
> Douglas Otis wrote:
> >
> > Matt,
> >
> > Unless encoding headers to hide typical PDU signatures, an analyzer will
> > have little difficulty in discovering PDU boundaries.
>
> I think that at 10Gig, it will be very difficult for an analyzer
> to find an
> iSCSI header in a byte stream and keep up with the incoming
> traffic while it's
> doing it. Furthermore, I could come up with a data pattern that
> would make it
> really difficult for your searching analyzer to synchronize on
> the real PDUs
> vs the fake ones in the data.
>
> > Should a scheme force
> > PDU alignment every 8192 bytes as example, discovery would be a
> certainty
> > within 8k bytes.
>
> How is that?  Remember, TCP's initial sequence number is random,
> so how will
> you know where the 8K boundary is?
>
> > To prevent blockage, the size of the PDU is limited and so
> > the search is not impossible as you imply nor even difficult.  Either
> > markers or alignment seems a good solution for minimizing
> impact of segment
> > loss to that of the interval rather than 2RTT x rate.  For
> either a periodic
> > marker or alignment scheme to work for sending, no changes to TCP is
> > required.
>
> Tweeking TCP a little by adding even an option bit in the header
> signalling a
> start of a new PDU would be a lot better.  TCP and any other
> protocol should
> evolve to track the evolution of the rest of computer technology.
>
> -Matt
>