SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Lets Move on



    1.This is not new information.
    2.NFS uses TCP/IP esp on major networks.
    3. We have discussed UDP before.
    4. Lets move on and not repeat history for each new guy.
    
    .
    .
    .
    John L. Hufferd
    
    
    "Y P Cheng" <ycheng@advansys.com>@ece.cmu.edu on 09/11/2000 09:06:20 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
    cc:
    Subject:  RE: a vote for asymmetric connections in a session
    
    
    
    Julo wrote:
    >I hove some trouble with your note as it contains many items
    >some that where repeatedly discussed and already agreed upon,
    >some with smaller or larger misunderstandings (like the duplex
    >issue - the links are in fact used in duplex mode <snip> ...
    
    Being a late comer into this discussion, I do apologize for repeating some
    subjects that were already been agreed before.  However, I do have problems
    with the iSCSI over TCP -- see my reply to the TCP speed thread -- and the
    sliding window, alternate path retry, wedge driver, and load balance
    issues.
    I don't understand the deadlock issue when a iSCSI adapter can accept
    hundreds and even thousands SCSI requests and execute them atomically.  Let
    me explain this.
    
    An iSCSI NIC adapter accepts a SCSI request and builds a table entry in its
    internal memory describing the SCSI session.  It sends the request datagram
    to a target.  When a response comes back in the form of datagrams, the
    adapter refers back to the table entry and quickly moves the datagrams to
    the application software.  There is no possibility of deadlock and there
    are
    hundreds or thousands of the table entries in the adapter's local memory --
    limited by the local memory size, of course.  A target iSCSI NIC adapter
    waits for incoming requests after the application software has already been
    in "listening" mode. Like its initiator counterpart, referring to the table
    entries, the incoming datagrams can be moved to the application without
    delay.  Of course, an NIC adapter can be both initiator and target.
    
    I am not familiar with the context of previous discussions which require
    TCP
    and sliding window to support iSCSI.  With regard to the full-duplex
    transmission, while a target can piggy back the acknowledge in its
    datagrams, there is no SCSI command starting data transfers in both
    directions today.  Although we could add such commands in the future, in
    general the need for acknowledge on transport with long latency on the net
    is bad.  As I said, the SCSI status gives the ultimate acknowledge anyway.
    I don't know if we need to define iSCSI in such a manner that it would
    require a very complicated driver implementation to work with legacy
    Ethernet adapters.
    
    If the new information introduced creates confusion, I do apologize.
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    julian_satran@il.ibm.com
    Sent: Monday, September 11, 2000 6:42 AM
    To: ips@ece.cmu.edu
    Subject: RE: a vote for asymmetric connections in a session
    
    Dear Mr. Cheng,
    
    I hove some trouble with your note as it contains many items some that
    where
    repeatedly discussed and already agreed upon, some with smaller or larger
    misunderstandings (like the duplex issue - the links are in fact used in
    duplex mode
    even for iSCSI as R2T and data can flow on the same links and outbound and
    inbound data can be used simultaneously with different commands, deadlocks
    are not
    caused by execution speed - or lack of,  a NT miniport serves a port driver
    which in turns serves a class driver, UDP is not more efficient than TCP -
    although is has a better matching datagram model it lacks reliable delivery
    and congestion control, etc.).
    
    I will try to summarize your subject line position for my (and our list
    records) - and please correct if I am wrong:
    
    - you are against the asymmetric model as it requires more work to execute
    a SCSI
    command than the symmetric model.
    
    Regards,
    Julo
    
    "Y P Cheng" <ycheng@advansys.com> on 11/09/2000 02:13:02
    
    Please respond to "Y P Cheng" <ycheng@advansys.com>
    
    To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL,
          black_david@emc.com
    cc:   ips@ece.cmu.edu
    Subject:  RE: a vote for asymmetric connections in a session
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:07:24 2001
6315 messages in chronological order