Re: iSCSI: Towards Urgent Pointer Consensus

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Glen:

Comments below...

Glen Turner wrote:
> 
> David Robinson wrote:
> >
> > While I am not convinced in the value of using URG, the lack of an API
> > specification MUST NOT stop discussion of the architectural merits.
> 
> A protocol definition does specify what OSI called "services".
> The TCP RFC specifies these before specifying the on-the-wire
> formats and the state machine.
> 
> A change to the services is a change to the protocol, so Douglas
> is correct in as far as a proposal to use URG for inter-PDU
> marking should specify the altered TCP services that this provides
> in an update to the TCP RFC.
> 
> As others have pointed out, such a change obviously requires
> the agreement of people outside of this WG and a discussion
> of the architectural merits must include them and, in the end,
> it is those people that will pass/veto the URG proposal.
> 

I don't think this group has any license to change TCP API or other
parts of TCP for that matter...

I think it is much more fundamental than the API. Has I have stated,
after looking at two implementations, you are defining a
behavior that IS NOT assured. When you use the URG pointer as
a record marker under multiple loss conditions it WILL FAIL to do
what is being defined. Yes, you can play with this all day in labs
with test code... but if you do this you had better:

A) Have a varity of TCP implemenations,
B) Put routers in the middle that can be configured
   to add delay and selectively drop packets.

If you just put a couple of implemenations together across a
room everything will work fine....

The problem will show up after you have deployed a broken spec
since it rely's on behavior that is not assured or designed
into the TCP spec.

If you insist on using the URG pointer has a marker then you must
move forward with a draft of some sort to specify changing TCP
to require this behavior... Doing this violates the WG charter!!

Consequently you must remove this from the spec in the next
version IMO...


R

> The practical implications seem to be:
> 
>  - we need a better handle on the non-URG behaviour of
>    iSCSI over TCP.  People with sample implementations
>    need to step up to the plate.
> 
>  - iSCSI should be specified with TCP as the preferred
>    transport, but iSCSI should allow other transports to
>    be used (which the enterprise users may choose, since they
>    have no firewall concerns, etc).  This probably implies
>    splitting the current draft into two: one to define
>    the iSCSI PDUs, another to define their encapsulation
>    in TCP.  Other WGs have done this (eg: SNMP).
> 
>  - negotiation of URG must be easily removed in a future
>    draft after some implementation experience has occurred
>    and also easily expanded to allow negotiation of some
>    other PDU-marking mechanism.
> 
> --
>  Glen Turner                                 Network Engineer
>  (08) 8303 3936      Australian Academic and Research Network
>  glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
> --
>  The revolution will not be televised, it will be digitised

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)