RE: iSCSI : Reject PDU Concerns.

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

Matt,

Unless encoding headers to hide typical PDU signatures, an analyzer will
have little difficulty in discovering PDU boundaries.  Should a scheme force
PDU alignment every 8192 bytes as example, discovery would be a certainty
within 8k bytes.  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.

As for the diagnostics, I would suggest there is no reason to encode data
into decimal text for the same reason and so a hexadecimal encoding should
be the default for all numeric encoded settings.  This information is not
for human consumption and such decimal conversion requires additional
processing for dubious benefit.  If there is an analyzer dissecting content,
such human aid can be added much as text is appended to a code dump.

Doug

> julian_satran@il.ibm.com wrote:
>
> > 2) An error_byte field should be considered for inclusion in the Reject
> > PDU which contains the byte offset of the errant byte[or word] in the
> > received header/payload that caused the target to send a Reject response
> > to the command.
> >
> > This is a simple solution that provides for quick fault isolation and
> > root cause of the reason for the reject. This also rids the Reject PDU
> > of any detailed elaboration of reason codes meant to allow root cause of
> > the reason for the reject.
> >
> > <js> that is no big help since there can be more than one error and it
> > helps mostly in debugging. For implementation errors in the
> target and/or
> > initiator I am sure the protocol analyzer will be happy to help
> but running
> > implementation should not be burdened with. For those that are running
> > errors on good implementations we will provide some details
> when necessary
> > </js>
>
> Julian,
>
> With only in-band framing [the markers that are currently defined in the
> spec], there is no way a protocol analyzer can be used in the traditional
> way.  In order for the protocol analyzer to work, it would have to be
> continuously running since the tcp connection(s) was
> established.  Besides,
> early on there will not be any protocol analyzers.
>
> -Matt
>