SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Performance of iSCSI, FCIP and iFCP



    I am more hopeful on the point of adapting the algorithm
    as environments change. The TCP gurus are conservative but
    not totally inflexible.
    
    -----Original Message-----
    From: Victor Firoiu [mailto:vfiroiu@nortelnetworks.com]
    Sent: Thursday, January 18, 2001 1:34 PM
    To: somesh_gupta
    Cc: IPS Reflector
    Subject: Re: Performance of iSCSI, FCIP and iFCP
    
    
    Somesh,
    
    I was looking more at the comparison between the FCIP case of multiple
    FC connections (all connections between two FCIP gateways) per TCP
    connection and the iFCP case of one/few TCP connections per FC
    connection (thus multiple TCP connections per pair of iFCP gateways).
    
    I think that, in general, one TCP connection per storage connection is
    closer to "one/two TCP connections per user" model, and thus 
    easier to defend as being "fair", compared to multiple TCP connections
    per storage connection.  I agree, this is quite a fuzzy quantification,
    but is as precise as RFC 2914 and 2309 get in this matter.
    
    Regarding modifing TCP congestion control as you suggest, I am again
    very skeptical.
    
    Victor
    
    
    
    
    Somesh Gupta wrote:
    > 
    > Victor,
    > 
    > I just assumed that you were familiar with the iSCSI specification
    > of multiple connections per session - which is essentially as you
    > describe in the second last paragraph - there is one big "flow"
    > between the initiator and the target (called an iSCSI session)
    > which is then striped across multiple TCP connections - and I
    > think people assumed that your statements were in support of
    > such a proposal.
    > 
    > Having said that, the math still holds. And also the fact that
    > fundamental limits to the throughput of a single TCP connection
    > really do require a change to TCP congestion avoidance (esp when
    > mistaking link error for congestion) formulae.
    > 
    > If the link error rate is such that errors occur faster than time
    > to recover (or of that order), TCP will have to accomodate that
    > somehow. I don't think the TCP gurus are inflexible in this area
    > - PAWS, window scaling, and SACK are all example of TCP accomodating
    > the characteristics of the underlying network.
    > 
    > Somesh
    >
    
    


Home

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