Re: iSCSI: Towards Urgent Pointer Consensus

["Jim Williams" <jimw@giganet.com>]

I would like to outline my understanding of how the
urgent pointer framing mechanism would work.  This
is done with the hope the any misunderstandings
will be corrected and any gaps filled.

My understanding is that iSCSI MUST be fully interoperable
with all existing TCP implementations and MAY contain
features that allow customized TCP implementations to
extract additional performance.  Use of the urgent
pointer to delineate message boundaries in the 
presence of dropped packets is such a feature.

This creates four cases that should be considered.

1.  standard TCP sending to standard TCP
2.  customized TCP sending to standard TCP
3.  standard TCP sending to customized TCP
4.  customized TCP sending to customized TCP

It seems clear that in case 1 and 2, urgent data
should not be used.  There is no way for a standard
TCP to use received urgent data designations to
any advantage, and it would only slow things down.

Case 4 can easily insert the urgent markers where
needed and extract them to optimum advantage on
the receiving end.  The only potential problem
with this case is if the urgent pointer is
modified within the network (or more accurately
by some gateway in the network path).  If the urgent
pointer is moved to point to some byte NOT indicated
as urgent by the sender, then the scheme is broken.
We NEED to guarantee that this can't happen.
If the urgent pointer is coalesced so that some
bytes designated as urgent at the sender are no
longer urgent when received by the receiver,
everything should still work, but possibly with
lower performance.  If this happens rarely, 
no problem.  If it happens often, then perhaps
the urgent data mechanism is not the best way
to recover framing.

Case 3 is the most problematic.  We are potentially
lowering the performance on one end in order to 
improve the performance on the other.  Case 3
has the same concerns as case 4 with the additional
concern that the sender may coalesce the urgent
pointer in some cases.  These concerns can
be resolved in a number of ways:

  a. Negotiate the use of urgent data only in case 4.

  b. Negotiate the use of urgent data in cases 3 and 4,
     and accept the fact that the performance gain in
     case 3 may in some cases be small due to excessive
     coalescing of the urgent pointer.

  c. Verify that for most TCP implementations, sent
     urgent data is usually received at the remote
     end with the TCP urgent marker intact.  In this
     case everything is fine (at least from the 
     receiver's view point).

----- Original Message ----- 
From: Randall R. Stewart <randall@stewart.chicago.il.us>
To: David Robinson <david.robinson@EBay.Sun.COM>
Cc: <ips@ece.cmu.edu>
Sent: Tuesday, November 21, 2000 4:40 PM
Subject: Re: iSCSI: Towards Urgent Pointer Consensus


> David:
> 
> I don't care about API's either... my whole problem with the URGENT
> issue is it will NOT work! Not reliably anyway... The whole mess
> needs to be removed from the draft. Yes you can
> get it to work most of the time, but get a double loss and it
> will not work... or then again you may be lucky and the sender
> might just do what you expect... The implementation's of TCP I looked
> at will not... 
> 
> I cannot go along with putting a buggy concept into a protocol
> specification
> that will basically NOT work under loss conditions. This is what you
> will have if it is left in...(IMO anyway)...

By "NOT work" do you mean that the framing information will be corrupted
in such a way as to cause the receiving end to fail due to misaligned
message boundary recovery?  Or do you mean that it will not in all
cases give the performance boost it was intended to?

If the former then this scheme should be ruled out as flawed
(or negotiated only in case 4 if that works).  If the latter,
then an assessment needs to be made as to whether this happens
often enough to make this proposal unattractive.

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


 - Jim Williams