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



    David Robinson wrote:
    > 
    > Douglas Otis wrote:
    > > At the least, strike this sentence.  If this proposal seeks to not redefine
    > > TCP then there is no need to specify TCP behavior.  This proposal has yet to
    > > document an API that can take advantage of this required and likely
    > > problematic Urgent Pointer Record Marking.  As this mechanism is likely to
    > > be problematic and the API has yet to be provided, the entire option should
    > > be removed.  Requiring dramatically different data handling without any
    > > means to identify whether this option is in use will be to the detriment of
    > > those making adapters.  The WG may wish to continue discussion as to whether
    > > the use of flagging the first byte of each PDU as urgent should be a SHOULD,
    > > but until there is a complete proposal that includes the API, this seem
    > > premature.
    > 
    > In general the IETF does not create API standards, just protocols.  At
    > best
    > it provides Informational documentation suggesting APIs that could be
    > used.
    > 
    > The key question is not *what* the API is, but *if* an API can be
    > created
    > to support the feature. As a system architect the answer is clearly yes
    > that an API can be created to reflect the desired semantics.
    > 
    > While I am not convinced in the value of using URG, the lack of an API
    > specification MUST NOT stop discussion of the architectural merits.
    > 
    >         -David
    David:
    
    I don't care about API's either... my whole problem with the URGENT
    issue is it will NOT work! Not reliably anyway... The whole mess
    needs to be removed from the draft. Yes you can
    get it to work most of the time, but get a double loss and it
    will not work... or then again you may be lucky and the sender
    might just do what you expect... The implementation's of TCP I looked
    at will not... 
    
    I cannot go along with putting a buggy concept into a protocol
    specification
    that will basically NOT work under loss conditions. This is what you
    will have if it is left in...(IMO anyway)...
    
    R
    
    
    R
    
    -- 
    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:20 2001
6315 messages in chronological order