SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Re: multiple tcp connections



    I don't think we want to invent sessions because some implementation
    could not achieve link speed using a single connection.
    
    First of all, we have demonstrated link speed on high speed links
    with a single TCP connection. There are two reasons I can come up
    with on short notice that may prevent one from acheiving this number.
    
    One is that the TCP window size may not be large enough. With the
    large window size option, this should not be an issue. The other
    is poor design - and that is something that should be solved
    through better design.
    
    There may be other reasons why this is not achievable that I
    don't know.
    
    -- 
    
    When we get to adding all the other objectives, that is another
    can of worms. We should at least spell out the requirements we
    are placing on a session in the spec.
    
    Somesh
    
    
    -----Original Message-----
    From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
    Sent: Saturday, July 08, 2000 10:38 PM
    To: ips@ece.cmu.edu
    Subject: FW: Re: multiple tcp connections
    
    
    
    
    John,
    
    Correct - the only difference would be that the higher levels of software
    would have to be aware
    and handle it (error recovery, exceptions, balancing, increasing the
    number, decreasing the number).
    Those where the considerations that lead me to invent the session (channel
    group in our own slang) -
    as we think we can handle those well under the hood.
    
    Julo
    
    
    hufferd@us.ibm.com on 08/07/2000 21:34:22
    
    Please respond to hufferd@us.ibm.com
    
    To:   julian_satran%ibmil.RSCS@DEVM.DE.IBM.COM
    cc:   ips@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)
    Subject:  Re: multiple tcp connections
    
    
    
    
    
    
    Julian,
    Since a session is only an iSCSI thing, your statements would be correct
    even if there were only one TCP connection per session, but several
    sessions on the same NIC.
    
    
    
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSD San Jose Ca
    (408) 256-0403, Tie: 276-0403
    Internet address: hufferd@us.ibm.com
    Notes address: John Hufferd/San Jose/IBM @ IBMUS
    VM address: hufferd at IBMUSM54
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 07/07/2000 11:18:48 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: multiple tcp connections
    
    
    
    
    
    Parallelism on end-points could be another reasons.
    
    A long time ago when running some benchmarks we achieved considerably
    better numbers with 4 sockets than with one.
    
    This type of result repeated itself in different contexts and with
    different stacks.
    
    That is probably due to some serialization that is inherent in the way
    stacks are built
    and API's are used (this is a long discussion subject).
    
    With SMPs the differences are even more striking.
    
    Julo
    
    Matt Wakeley <matt_wakeley@agilent.com> on 08/07/2000 02:11:57
    
    Please respond to Matt Wakeley <matt_wakeley@agilent.com>
    
    To:   Randy Haagens <Randy_Haagens@hp.com>, Julian Satran/Haifa/IBM@IBMIL
    cc:
    Subject:  multiple tcp connections
    
    
    
    
    Hi,
    
    I was asked the question:
    
    If there is only 1 MAC (available to the system), would there ever be more
    than 1 tcp connection per iSCSI session.  I couldn't think of a good reason
    why there would be, but thought I'd ask you. The only reason I could think
    of
    using multiple tcp connections per iSCSI session was for port aggregation
    when
    there are multiple MACs available.  Any comments?
    
    Thanks,
    
    -Matt
    
    
    
    
    
    
    
    
    
    
    


Home

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