SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Concensus Call on Urgent Pointer.



    
    
    Somesh,
    
    It has been dicussed extensively.   There is even a memo describing it on
    the document area
    of the Mail Archive.
    
    Regards,
    Julo
    
    "GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@hp.com> on 19/11/2000
    07:17:37
    
    Please respond to "GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@hp.com>
    
    To:   "HAAGENS,RANDY (HP-Roseville,ex1)" <randy_haagens@hp.com>, "'Dick
          Gahan'" <Dick_Gahan@eur.3com.com>, Daniel Smith/Almaden/IBM@IBMUS
    cc:   ips@ece.cmu.edu, "Matt Wakeley (E-mail)" <matt_wakeley@agilent.com>
    Subject:  RE: Concensus Call on Urgent Pointer.
    
    
    
    
    One possible alternative that has not been discussed (might have been
    discussed in the old design team) is ensuring alignment of iSCSI header
    at fixed intervals (the intervals could be fixed by spec or negotiated
    in each direction at login time) - i.e. an iSCSI header appears every
    mod n = 0 bytes in the TCP byte stream. Multiple iSCSI PDUs will appear
    in an interval, but the last one will be followed by pad bytes.
    
    This has 2 implications - one is that the largest iSCSI data PDU must be
    less than the negotiated interval. Second there is some wasted bandwidth
    - the percentage is probably inversely proportional to the length of
    the interval.
    
    This is nowhere near as efficient as tightly coupled iSCSI/TCP
    implementations
    either sending out iSCSI headers aligned at TCP segment boundaries or
    using URG pointer in a particular way. However, it does enable
    recovery of sync (except for the pathological case). If the connections
    have negligible loss/out-of-order delivery, or if the implementation has
    lot
    of buffer memory (host stacks or some other offload implementations) then a
    very very large interval can be negotiated. If the connections are in a
    lossy environment (or where the tolerance for packet loss is low),
    a smaller interval can be negotiated (probably causing even more loss
    in an already poor environment).
    
    > -----Original Message-----
    > From: HAAGENS,RANDY (HP-Roseville,ex1) [mailto:randy_haagens@hp.com]
    > Sent: Friday, November 17, 2000 4:06 PM
    > To: 'Dick Gahan'; Daniel Smith
    > Cc: ips@ece.cmu.edu; Matt Wakeley (E-mail)
    > Subject: RE: Concensus Call on Urgent Pointer.
    >
    >
    > I disagree with making a solution to the framing problem optional.
    >
    > The framing problem is real.  Without a solution to it, iSCSI
    > will fail.
    > Failure is not an option.
    >
    > Those who doubt the importance of finding a solution to the
    > framing problem
    > should argue that point directly, without trying to negate proposed
    > solutions by making them optional.
    >
    > Those who accept the framing problem, but disagree with the
    > urgent pointer
    > mechanism as a solution, can contribute constructively by (a)
    > exhibiting an
    > alternative solution; (b) fully explaining their reservations
    > about use of
    > the urgent pointer mechanism.
    >
    > I myself am not yet convinced that the urgent pointer
    > mechanism is a viable
    > solution to the framing problem.  But I do applaud Matt's
    > attempts to find a
    > solution.
    >
    > R
    >
    > Randy Haagens
    > Director, Networked Storage Architecture
    > Storage Organization
    > Hewlett-Packard Co.
    > e-mail: Randy_Haagens@hp.com
    > tel: +1 916 785 4578
    > fax: +1 916 785 0391
    >
    >
    > -----Original Message-----
    > From: Dick Gahan [mailto:Dick_Gahan@eur.3com.com]
    > Sent: Friday, November 17, 2000 10:14 AM
    > To: Daniel Smith
    > Cc: ips@ece.cmu.edu
    > Subject: Re: Concensus Call on Urgent Pointer.
    >
    >
    >
    >
    > I agree with Daniel smiths wording.
    >
    > >"During login, if the target reqests use of the Urgent
    > Pointer (UP) then
    > >.this should be taken as meaning that the target will operate more
    > >efficiently when the UP is used.  The initiator should make
    > an effort to
    > use
    > >the UP.  If it is unable (or unwilling, because of user
    > intervention*) to
    > >use the UP then it must indicate its non-compliance to the target."
    >
    >
    > Neither the target or the initiator must support it but
    > either or both can
    > request it.
    > The requested party does not have to support it to be complient.
    >
    > Dick Gahan
    > 3com
    >
    >
    >
    > I apologize for the advertizing in my last memo - some MIS people have
    > enabled
    > this and I havn't had time
    > to turn it off.
    >
    > Dick
    >
    >
    >
    > PLANET PROJECT will connect millions of people worldwide through the
    > combined
    > technology of 3Com and the Internet. Find out more and register now at
    > http://www.planetproject.com
    >
    >
    >
    
    
    
    


Home

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