SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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)
    


Home

Last updated: Tue Sep 04 01:06:19 2001
6315 messages in chronological order