RE: iSCSI: Towards Urgent Pointer Consensus

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

..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