RE: Concensus Call on Urgent Pointer

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

Daniel,

Even this modified Urgent Pointer scheme has an impact on standard TCP.  As
everyone looks to TCP offload engines, making flavors of TCP is not helpful
in that effort.  There must be a formalized API for this modified TCP Urgent
Pointer scheme to be assessed.  With this option in place, will a single
spoof be able to hang a system or corrupt data?  Remember more than one
application may be using this scheme.  As there is a larger audience with
respect to networking, expect an "all is fair in the box" explanation to not
win the day.  This Urgent Pointer modification API should be completed and
presented for review.

The ugly aspect of the urgent pointer idea comes from requirements placed on
data handling.  As this scheme can not be identified, it will be difficult
for TOE to operate in the correct mode.  Should there be a desire for a new
mode of TCP operation, select a new option code rather than debase a prior
and include API documentation rather than just a description of wire
traffic.  As this is not within the IPS charter, details being discussed
here even for changes found compatible if viewed at the wire should be
tasked to the group responsible for TCP.  Perhaps you will find a better
solution than thought possible as a result.

Doug


> "HAAGENS,RANDY (HP-Roseville,ex1)" wrote:
> >
> > Those who accept the framing problem, but disagree with the
> urgent pointer
> > mechanism as a solution, can contribute constructively by (a)
> exhibiting an
> > alternative solution; (b) fully explaining their reservations
> about use of
> > the urgent pointer mechanism.
>
> Costa's TCP RDMA Option was also put forward to solve the framing
> problem.
> Is that still on the table too?  I actually prefer the urgent
> pointer as an
> interim framer.
>
> My only requirement as far as this topic goes is that iSCSI MUST
> be able to
> run over vanilla TCP.  I.e., it must be able to run over something that is
> architecturally just a bidirectional byte stream.  Any things
> added to that
> are performance (flavor) enhancers, are desirable, and highly recommended
> (especially chocolate).  But anything in the protocol that ties us to TCP
> only, really must be optional in my opinion (and default
> OFF---i.e., if you
> don't specify a flavor, you get vanilla).
>
> Daniel Smith
>
> (Aside to Randy: I accept the framing problem as a minor
> performance issue*.
> I do not believe iSCSI /needs/ an alternate solution.  I do believe iSCSI
> /should/ have an alternate solution.)
>
> * It'll remain minor in my mind until someone publishes measured figures
> that demonstrate >10% degradation in a reasonable set up.  Has anybody
> measured it?
> --
> IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
> K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010
>