Re: iSCSI: Towards Urgent Pointer Consensus

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

Jim Williams wrote:
> 
> 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?
> 

I believe it will fail due to misaligned boundary messages...


> If the former then this scheme should be ruled out as flawed
> (or negotiated only in case 4 if that works).  If the latter,

This is my point, it is flawed... if you would like I can
post clips of code from netbsd that illustrate the problem :>

When the following occurs:

1) Urgent markings being sent, rwnd/cwnd is high (to sustain
   the high throughput.
2) A segment is lost, with the iSCSI header.
3) The receiver, uses the URGENT pointer correctly
   to find a new frame (note depending on how they have
   coded the receive side they may have quite a few
   frames to move through).
4) The sender (after a RTT) figures out, via fast-recovery,
   that the original segment is lost, 1/2's its cwnd.
5) The sender is still getting the highrate sent to it by
   its app.
6) The ONE urgent pointer starts to slide backward, ALL frames
   begin to get URGENT marks, no matter if they have a
   iSCSI header or not.
7) During the recovery another frame is lost...

At 7) you are now faced with one of two scenario's (depending
on the receiver)...

A) All URGENT marks will be turned off if the amount of urgent
   data exceeds a threshold... 
or

B) All frames are marked urgent... 

You are now in a situation that it just does not WORK...

If you do has you say above, and only do it for case #4, what
you are advocating is redesigning a special hook in the adaptors
to do different things than what TCP does.

The URGENT pointer was designed as a mechanism to transfer a
"Ctl-C" or some other small amount of priority data. It was NOT
designed as a framing mechanism...

In my mind you are warping a mechanism outside of the scope of what
it was designed for.. By looking inside two implemenations of TCP
I have confirmed this... I just don't see how this scheme will
ever work..


R


> 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

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