Re: Thoughts on the Urgent Pointer issue.

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

Julian:

I have now looked at the two implementations I have easiest
access to... and of course both are quite different in
there handling of the urgent pointer :)

One thing common to both I looked at:

Urgent DATA always takes the slowest path. So in
sending or receiving, as many of the comments say,
"Urgent data is a pain" :) Don't expect any great
performance out of your TCP stack when this is used
... you won't get it!

Now as far as your statements below are concerned this may
be because (A) you never hit packet losses at the right
times or (B) your implementation DOES keep multiple pointers.

One implementation I looked at, does NOT.. There is one urgent send
pointer and one urgent receive pointer. And the urgent pointer collapse
I stated is not quite right but close :/  It turns out that EVERY
segement
would be marked urgent making the urgent pointer mark of utterly NO USE
to you. Another interesting point on this was the fact that if the 
size of the urgent data exceeds a maximum, all the urgent mark is pulled
off of the data... so this would cause some real interesting behavior..
The comments basically indicated that no one expects to have this
much urgent data sent :/

The second implementation I looked at seemed to possibly have more
than one pointer (it was harder to tell... since it was written
much poorer :<). But I am not so sure... 

To get other implementations (I think I could poke up two others) would
require a LOT of effort and I don't feel like digging that deep :)

After my brief look, I have changed my mind on the urgent pointer
section! I think this whole concept MUST be removed. The URGENT pointer
will NOT do what you want always... oh, yes it may work most of the
time... but in reality it is a SERIOUS flaw waiting to byte you, pun
intended :)

I cannot support even having this urgent method has an option. It is to
unstable and WILL NOT work reliably...


Regards

R





julian_satran@il.ibm.com wrote:
> 
> Randall,
> 
> What you describe is interesting but it is not the behaviour mandate buy
> the RFC nor that exposed by several stacks we have played with.  In all
> cases we observed several urgent pointers in the stream (in fact one in
> every packet including the urgent marked bit and nothing beyond it.  There
> is no collapse of the pointer and the receiver is not notified well ahead
> of the existence of the pointer.  However beware of the API!. I have no
> clue what happens in various stacks with the Urgent Signal or the ioctl
> that gets the stream to the urgent point - those where all devised years
> ago for the remote login and for iSCSI we can let the sleep... (we are not
> going to need them).  The same happens after the window closes and at
> retransmission.
> 
> Regards,
> Julo
> 
> "Randall R. Stewart" <randall@stewart.chicago.il.us> on 20/11/2000 15:01:30
> 
> Please respond to "Randall R. Stewart" <randall@stewart.chicago.il.us>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   "GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@hp.com>,
>       "HAAGENS,RANDY (HP-Roseville,ex1)" <randy_haagens@hp.com>, "'Dick
>       Gahan'" <Dick_Gahan@eur.3com.com>, Daniel Smith/Almaden/IBM@IBMUS,
>       ips@ece.cmu.edu, "Matt Wakeley (E-mail)" <matt_wakeley@agilent.com>
> Subject:  Thoughts on the Urgent Pointer issue.
> 
> Julian:
> 
> Interesting paper, it at least frames some of the
> ideas that have been mulled on by the design team... this
> is a good thing.
> 
> I have been thinking about the Urgent pointer use that
> Matt is proposing off and on all weekend. And I finally
> came up with what bugs me about it.
> 
> Yes, I think it will work if you are lucky enough to
> only have ONE loss. The Urgent mark will be present
> to guide you in to where to recover and you will only
> need to buffer some smaller amount of data in the NIC.
> 
> But the problem is what is happening at the sender during
> this loss. Two things are occuring when the loss is
> realized,
> 
> A) The congestion window is 1/2'ed (assuming a fast retransmit)
>   <and>
> B) The sender experiences a Urgent pointer collapse upward. This is
>    because you must assume a constant sending rate (in order to
>    maintain your high transfer) and since we have only one urgent
>    pointer, each send pushes the urgent mark further and further
>    up the list of queued iSCSI packets.
> 
> Now everything will be fine if we can get this 150-250Meg of data
> (with 1 urgent mark out at the end) through without a loss, but what
> happens when you get a subsequent loss? The receiver will have
> no urgent pointer for quite some time.
> 
> I really think using this mechanism is completely unreliable and would
> not be very advisable...
> 
> The alignment proposed below seems more dependable but you may be
> using up to much bandwidth on this depending on how you
> choose a boundary etc...  Another thought, listed in your memo is
> the choice of a "magic" signature. But this may present a problem
> as well (CPU wise) since now one must scan memory looking for the
> "magic" mark (when one gets out of sync) and of course one would
> need a escape sequence in case data heading for a disk or tape had
> the magic mark...
> 
> I don't know of any other viable options though.. I think the
> only two assured ones are the (A) alignment method and (B) the
> "magic" signature. I don't see that the Urgent pointer is a
> safe option since it will be quite unreliable.
> 
> Regards
> 
> R
> 
> julian_satran@il.ibm.com wrote:
> >
> > Somesh,
> >
> > It has been dicussed extensively.   There is even a memo describing it on
> > the document area
> > of the Mail Archive.
> >
> > Regards,
> > Julo
> >
> > "GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@hp.com> on 19/11/2000
> > 07:17:37
> >
> > Please respond to "GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@hp.com>
> >
> > To:   "HAAGENS,RANDY (HP-Roseville,ex1)" <randy_haagens@hp.com>, "'Dick
> >       Gahan'" <Dick_Gahan@eur.3com.com>, Daniel Smith/Almaden/IBM@IBMUS
> > cc:   ips@ece.cmu.edu, "Matt Wakeley (E-mail)" <matt_wakeley@agilent.com>
> > Subject:  RE: Concensus Call on Urgent Pointer.
> >
> > One possible alternative that has not been discussed (might have been
> > discussed in the old design team) is ensuring alignment of iSCSI header
> > at fixed intervals (the intervals could be fixed by spec or negotiated
> > in each direction at login time) - i.e. an iSCSI header appears every
> > mod n = 0 bytes in the TCP byte stream. Multiple iSCSI PDUs will appear
> > in an interval, but the last one will be followed by pad bytes.
> >
> > This has 2 implications - one is that the largest iSCSI data PDU must be
> > less than the negotiated interval. Second there is some wasted bandwidth
> > - the percentage is probably inversely proportional to the length of
> > the interval.
> >
> > This is nowhere near as efficient as tightly coupled iSCSI/TCP
> > implementations
> > either sending out iSCSI headers aligned at TCP segment boundaries or
> > using URG pointer in a particular way. However, it does enable
> > recovery of sync (except for the pathological case). If the connections
> > have negligible loss/out-of-order delivery, or if the implementation has
> > lot
> > of buffer memory (host stacks or some other offload implementations) then
> a
> > very very large interval can be negotiated. If the connections are in a
> > lossy environment (or where the tolerance for packet loss is low),
> > a smaller interval can be negotiated (probably causing even more loss
> > in an already poor environment).
> >
> > > -----Original Message-----
> > > From: HAAGENS,RANDY (HP-Roseville,ex1) [mailto:randy_haagens@hp.com]
> > > Sent: Friday, November 17, 2000 4:06 PM
> > > To: 'Dick Gahan'; Daniel Smith
> > > Cc: ips@ece.cmu.edu; Matt Wakeley (E-mail)
> > > Subject: RE: Concensus Call on Urgent Pointer.
> > >
> > >
> > > I disagree with making a solution to the framing problem optional.
> > >
> > > The framing problem is real.  Without a solution to it, iSCSI
> > > will fail.
> > > Failure is not an option.
> > >
> > > Those who doubt the importance of finding a solution to the
> > > framing problem
> > > should argue that point directly, without trying to negate proposed
> > > solutions by making them optional.
> > >
> > > 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.
> > >
> > > I myself am not yet convinced that the urgent pointer
> > > mechanism is a viable
> > > solution to the framing problem.  But I do applaud Matt's
> > > attempts to find a
> > > solution.
> > >
> > > R
> > >
> > > Randy Haagens
> > > Director, Networked Storage Architecture
> > > Storage Organization
> > > Hewlett-Packard Co.
> > > e-mail: Randy_Haagens@hp.com
> > > tel: +1 916 785 4578
> > > fax: +1 916 785 0391
> > >
> > >
> > > -----Original Message-----
> > > From: Dick Gahan [mailto:Dick_Gahan@eur.3com.com]
> > > Sent: Friday, November 17, 2000 10:14 AM
> > > To: Daniel Smith
> > > Cc: ips@ece.cmu.edu
> > > Subject: Re: Concensus Call on Urgent Pointer.
> > >
> > >
> > >
> > >
> > > I agree with Daniel smiths wording.
> > >
> > > >"During login, if the target reqests use of the Urgent
> > > Pointer (UP) then
> > > >.this should be taken as meaning that the target will operate more
> > > >efficiently when the UP is used.  The initiator should make
> > > an effort to
> > > use
> > > >the UP.  If it is unable (or unwilling, because of user
> > > intervention*) to
> > > >use the UP then it must indicate its non-compliance to the target."
> > >
> > >
> > > Neither the target or the initiator must support it but
> > > either or both can
> > > request it.
> > > The requested party does not have to support it to be complient.
> > >
> > > Dick Gahan
> > > 3com
> > >
> > >
> > >
> > > I apologize for the advertizing in my last memo - some MIS people have
> > > enabled
> > > this and I havn't had time
> > > to turn it off.
> > >
> > > Dick
> > >
> > >
> > >
> > > PLANET PROJECT will connect millions of people worldwide through the
> > > combined
> > > technology of 3Com and the Internet. Find out more and register now at
> > > http://www.planetproject.com
> > >
> > >
> > >
> 
> --
> Randall R. Stewart
> randall@stewart.chicago.il.us or rrs@cisco.com
> 815-342-5222 (cell) 815-477-2127 (work)

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