Re: ISCSI: Urgent pointer consensus

[Daniel Smith <dfsmith@almaden.ibm.com>]

Matt Wakeley wrote:
> 
> Um, who, besides Doug, has objected?  Seems to me most of the discussion has

I object to the use of "MUST" with the urgent pointer, for the following
reasons.  If you're time pressed, just read the first sentence of the
objections.  B-)

1) It slows down every iSCSI implementation while benefiting a handful of
iSCSI analysers.  (The slowdown is marginal---a few bytes every segment.) I
don't see how using the urgent pointer could help a TCP adapter card (which
knows exactly where it is in the TCP stream anyway).  An analyser that joins
an iSCSI session mid-stream should have no problem picking up
synchronisation after a brief statistical analysis.  Not a perfect solution,
I agree, but not insurmountable.  We have to weigh a <1% slowdown in iSCSI
against a 4s "lock-in" time for a newly introduced, independent analyser. 
(Also note, that if iSCSI traffic is light, this actually reduces the
lock-in time, because PDUs will be at the start of TCP segments.)

2) Firewalls devices have the option of removing the urgent pointer if they
are repackaging the TCP streams.  I have not seen this happen in practice,
but I think it is something noteworthy.  Without the urgent pointer, the
iSCSI protocol is transport agnostic---that is, TCP could be replaced with
any other streaming protocol.  (For example, a named pipe, a generic socket,
an RS232 cable, any high speed streaming system interconnect.)

3) I am a firm believer that it should be harder to do difficult things. 
That is, using the urgent pointer is more tricky than /not/ using the urgent
pointer.  Thus the default should be no urgent pointer, with the option of
enabling it.  (Of course, I feel the same way about RTT and some of the
RNs---they're not necessary for the protocol to work, but were placed there
to satisfy some perceived need in performance or error recovery.  The
network world has normally worked the other way around---make the protocol
simple and the world will adapt to meet you.*)

Summary: there is no single, powerful reason why the urgent pointer should
not be mandatory.  But there is no pressing reason (I can see) to require it
either, and there are several small reasons not to use it.

My preference: remove the mandatory urgent pointer.  Wording should be
closer to "The TCP urgent flag MAY be utilized.  Should the TCP urgent flag
be employed, then it MUST point to....  Use of the urgent flag is
recommended when troubleshooting an iSCSI installation, and a network
manager should be able to use it if desired."

I think that about wraps up my thoughts on the matter.  We now return to
normal programming....

Daniel Smith.


* I have heard the argument that if something is made optional in the
storage world, then nobody implements it.  Strangely enough, this position
is normally taken by people who want to make things mandatory.  I take the
opinion that if people aren't using a feature, then it probably wasn't too
hot in the first place. 
-- 
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