Re: Thoughts on the Urgent Pointer issue.

[julian_satran@il.ibm.com]

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)