Re: iSCSI: Towards Urgent Pointer Consensus

[julian_satran@il.ibm.com]

In the old and faithfull Stevens - Unix Network Programming you can find
the rationale behind the
Urgent Data (read carefully the remote login implementation) and its
associated APIs in BSD (and successors).

Julo

"Randall R. Stewart" <randall@stewart.chicago.il.us> on 23/11/2000 00:39:20

Please respond to "Randall R. Stewart" <randall@stewart.chicago.il.us>

To:   "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: Towards Urgent Pointer Consensus




Marjorie:

In the implemenation that is most clear (netbsd) I have
wondered if this is not a bug...

There is only one urgent pointer (in all implementations
that I have looked at). Has the urgent pointer is
added to, it resets the sequence mark to this new
point (+ 1, since Berkley always pointed to
1 byte past the urgent pointer mark not the last
byte of the urgent pointer as the spec says).

Now whenever you go to send a block of data it
just does a check to see if the next segment
is smaller than this urgent mark, if so it
sets the URG bit and then caclulates the urgent
location by a subtraction between the URG sequence
number and the segement heading out... This would
result in of course a bigger than 16bit value yeilding
a index into the data that would be unreliable...


I think the reason this is done this way is as I said, the
URG pointer is designed for a small URGENT piece of information.
There are comments within the code that indicate this as well.

I think you will find that many implementations have taken
this sort of approach.. since the point of URGENT data is
"here is a small bit of info that must get there quick"  NOT
"I am using this to mark each frame where a header begins"

This marking is a total corruption of the purpose of URGENT data
and I think it is prone to many many problems if it is left in
the spec... it MUST be removed IMO...


R

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
>
> ..snip..
> > > 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...
> >
> >
>
> .. more snipping ..
>
> > 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.
>
> When you refer to the urgent pointer "sliding backwards", what did you
> observe?
>
> RFC 793 very loosely defines urgent pointer behavior, but it appears that
> the coalescing allowed would still mean that a "coalesced" urgent pointer
> should correctly point at some urgent data marked by the sender. (ie, it
> should eventually correctly point at an iSCSI header).  If an
implementation
> doesn't coalesce urgent pointers correctly, it seems there's bug in the
> implementation.
>
> Even so, it seems clear to me that the TCP specification of the Urgent
> pointer behavior is too loose to allow for the kind of framing that iSCSI
is
> looking for. Thanks for your examples, they nicely point out this
ambiguity.
>
> Marjorie Krueger
> Networked Storage Architecture
> Hewlett-Packard Storage Organization
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com

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