SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: ISCSI: draft-wakeley-iscsi-msgbndry-00.txt



    Matt,
    
    Use of the urgent pointer requires very careful investigation. If you
    look at the TCP RFC it mentions that that the urgent pointer
    location is a connection-wide pointer, both on the receiver side
    and the sender side.
    
    >From the sender side, even if TCP emits a TCP segment for every
    user send, you are not guaranteed the preservation of the urgent
    pointer - e.g.
    
    1. Let us say that a retransmission timeout occurs and a number
       of segments have to be retransmitted. In this case, based on
       (my interpretation) of RFC 793, only the last value of the
       urgent pointer is meaningful.
    
    2. Let us say that user data gets queued up due to flow control
       issues. Again this will cause the last value of the urgent
       pointer to take effect.
    
    the second part will have an impact in the slow start case. A
    further analysis is required, but it seems that in cases where
    packets are being dropped, the urgent pointer setting will not
    be the most optimal (just about when it is needed the most).
    The urgent pointer proposal may have a benefit when you are
    loosing exactly one packet per window size (maybe even two
    with SACK).
    
    On the receive side, again the same thing happens when multiple
    segments with urg pointer are received. Since it is a connection-
    wide pointer, only the last one should be provided to the user.
    
    If the data passes through "intermediate TCP devices" then again
    the urgent pointer setting will be again be suboptimal.
    
    I would urge some TCP expert to jump in here.
    
    Somesh
    


Home

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