SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: new iSCSI draft - 02.txt



    
    
    David,
    
    Several of us thought that we have to have a framing solution in the
    current draft and since the TCP option
    (flag, length etc>) got a thumbs down at the last IETF and since in-stream
    and out-of-stream solution that could be used by others (like the chunking
    or my IPV6-like proposal) will take a long time to get through the process
    and mature we where left with two options:
    
       the marker
       having a padding mechanism that will insure that at certain boundaries
       there is always a PDU boundary
    
    
    I felt that the marker is preferable due to several reasons:
    
       It can be implemented "underneath" iSCSI - at the boundary with TCP; the
       iSCSI code (its main part) will be unaware of it and it can be replaced
       by another mechanism when such a mechanism becomes available
       it wastes less than the padding
       it is easy to implement in software and even in a plain vanilla TCP/IP
       adapter with hardware assists (and it can be used by many protocols)
    
    We had a "low key" consensus that this is a decent solution and even Doug
    Otis does not object!
    
    And yes - we can discuss at any length in Orlando.
    
    Regards,
    Julo
    
    "David Peterson" <dap@cisco.com> on 03/01/2001 16:47:07
    
    Please respond to "David Peterson" <dap@cisco.com>
    
    To:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
    cc:
    Subject:  RE: new iSCSI draft - 02.txt
    
    
    
    
    I believe there was agreement to remove the Urgent-Pointer framing
    mechanism
    but don't recall any agreement to replace it with an in-stream marker. For
    a
    software implementation it would be hard to support this type of framing
    mechanism. I believe a TCP option indicating the message boundry or a
    fixed-length PDU at a granularity to minimize overhead are much better
    solutions and are workable for both software and hardware implementations.
    I
    have not seen an agenda but I would hope this issue would be discussed at
    the upcoming meeting in Orlando.
    Dave
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    julian_satran@il.ibm.com
    Sent: Saturday, December 30, 2000 11:11 AM
    To: ips@ece.cmu.edu
    Subject: new iSCSI draft - 02.txt
    
    
    
    
    
    
    Dear colleagues,
    
    I've just submitted to the Internet-Drafts repository and to our list
    archive (at CMU) a new
    version of the draft.
    
    Changes (from 2b!):
    
       framing by Urgent-Pointer replaced by framing through in-stream marker
       editorials and typos (not completed yet)
       simpler digests
       digest recovery and some clarifications on iSCSI specific errors (more
       to come)
    
    
    I will have version 03 with many more editorial changes before the
    intermediate meeting.
    
    You can see the draft at:
    
    http://www.haifa.il.ibm.com/satran/draft-ietf-ips-iSCSI-02.txt
    
    Regards,
    Julo
    
    
    
    
    
    
    
    
    


Home

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