SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: A Transport Protocol Without ACK



    
    Actually, I have not heard any discussion of Netware networking protocols -
    IPX, SPX, etc...  these work fine, are widely supported, and could be using
    instead of TCP.
    
    I am not familiar enough with a comparison to be able and determine the pros
    and cons, but I would invite someone to express a reasoned opinion.
    
    Jim
    
    
    -----Original Message-----
    From: Randall R. Stewart [mailto:randall@stewart.chicago.il.us]
    Sent: Saturday, September 16, 2000 5:34 PM
    To: Y P Cheng
    Cc: 'Ips@Ece. Cmu. Edu'
    Subject: Re: A Transport Protocol Without ACK
    
    
    Y P Cheng wrote:
    > 
    > David Black wrote:
    > > < From: Y.P. Cheng>
    > > > The main difference between my view and that of ips discussions is the
    > > > semantics on creating and interpreting the iSCSI headers.  The working
    > > > group assumes the iSCSI in using TCP/IP will need several system
    calls:
    > > > write command, read/write data, and read status. Hence, iSCSI will
    have
    > the
    > > > problem of interlocking.  The working group tries to solve the problem
    > > > with asymmetric and symmetric models.  However, if the group assumes a
    > > > single system call to send an iSCSI request, we can let the transport
    > layer
    > > > break up iSCSI requests into PDUs of command, data, and status.  The
    > > > asymmetricmodel is no longer needed.
    > > I think "system calls" is the wrong word.  The whole point of
    > > sessions is to take advantage of network fabric parallelism,
    > > i.e., use two or more NICs on initiator and target.
    > > This requires the transport layer to figure out which PDU
    > > to send on which NIC (i.e., which TCP connection) independent of what's
    > > implemented in hardware or software, and entails logic on the far side
    to
    > > put things back in order.  This logic could be in iSCSI or a
    > > transport like SCTP.
    > > <snip>
    David: .. I missed this earlier... has mentioned by me somewhat
    a while ago.. SCTP can help you only in that it will retransmit
    on a alternate network. There is a notion of a "primary" transport
    address. This is where all sends, by default, go. Now the sender (i.e.
    iSCSI)
    can override this, by specifing either an override or changing the
    primary... but I don't think this accomplishes what you are after.
    
    I think that multiple streams and the automatic message
    bounding are the big wins iSCSI can gain from SCTP. The 
    multi-homing will help only in the sense that you gains
    some fault tolerance...
    
    > > Because reliable delivery isn't enough.  Congestion control is also
    > > required.  TCP does congestion control in a fashion that no existing
    > > SCSI transport or mechanism does.  It's not the only solution, but it
    > > or an equivalent congestion control solution is REQUIRED.  Please read
    > >
    > > http://www.ietf.org/internet-drafts/draft-floyd-cong-04.txt
    > >
    > 
    > Thank you for pointing out that in addition to mapping a SCSI request to
    > iSCSI PDU's, the working group is also addressing the delivery of PDU's to
    > prevent deadlock when TCP/IP is used.  It is also assumed that TCP/IP
    > provides the congestion and flow control. Whether I like it or not, the
    > reality is that many iSCSI implementation will be TCP/IP.  However, I do
    > have concerns if iSCSI requires the ACK to achieve reliable delivery.  Let
    > me use the following example to illustrate my concern.
    > 
    > Assume we wish to perform backup to a device 3000 miles away using iSCSI
    > protocol.  It would take 10 milliseconds for an IP packet to travel from
    the
    > source to destination.  Similarly, it takes another 10 milliseconds for
    the
    > ACK to come back.  Lets also assume that the backbone is capable of 1
    > gigabit per second throughput.  To keep data streaming on this connection,
    > the source needs to send 2 megabytes of data before seeing the first ACK
    > coming back.  Similarly, the target must be prepared to buffer 2 megabyte
    of
    > data.  This example becomes much more interesting when we increase the
    > backbone connection speed to that of OC-192 at 10 gigabits per second or
    if
    > the backup devices are accepting incoming streams from multiple
    initiators.
    > It needs a lot of memory.
    > 
    > We could take a lesson from the fibre channel FCP using class-3 datagram.
    > The SCSI protocol is inherited acknowledged by the returning of status
    PDU.
    > If an ACK to datagrams is not necessary, then the 2MB buffer requirement
    in
    > the above example can be reduced to less than 100KB to accommodate the
    speed
    > variation of the host system bus and the connecting media.  By the way,
    > multiple paths does not solve this problem.  The problem of lost PDU's due
    > to traffic jam or congested system bus are also still there. However, the
    > congestion and retransmission problem has already been solved in the
    > implementation of a fibre channel adapter.  TCP/IP is not the only
    protocol
    > providing a solution.
    
    I am a bit confused by the above Y.P. you state " by the returning of
    status
    PDU."... Both SCTP and TCP will carry a piggyback
    ACK with that PDU, so you end up accomplishing the same thing. What are
    you trying to say that I am missing???
    
    
    > I guess my point is that the iSCSI should allow a transport protocol that
    > does not require ACK.  (My apology for mentioning UDP in my previous
    > postings.)  If iSCSI is not limiting itself to TCP/IP, then, the
    asymmetric
    > model is also a non-issue for people who design a smart NIC adapter.
    
    Y.P. please enumerate the protocols that have this property that also
    provide TCP friendly congestion control. If you could enumerate the
    exact
    protocols and pointers to the specifications I would be more than
    glad to have a look at these and see if I can support them. Making vague
    references to "not limiting itself to TCP/IP" does not do anything for
    me and I think nothing for the WG. We need specific transport protocols
    listed that are capable of transporting iSCSI AND have TCP friendly
    congestion control principles built into them...
    
    Right now I assess that list to be:
    
    1) TCP
    2) SCTP
    
    Please feel free to add to this list..
    
    
    Thanks
    
    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:07:12 2001
6315 messages in chronological order