SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: FCIP: Multiple connections



    I think another proposal could be that:
    
    - the reverse direction frames are sent to the same IP address of
      the source of the forward direction.
    - rule 1 still applies: i.e., frames of the same flow in the reverse
      direction can not be sent on multiple connections.
    - when a new connection is established to recover into, that new
      connection is again to the same IP address and not to a different
      IP address.
    
    This removes the possibility of the reverse direction frames landing
    on a different NIC/port.
    
    Venkat Rangan
    Rhapsody Networks Inc.
    http://www.rhapsodynetworks.com
    
    
    -----Original Message-----
    From: Sriram Rupanagunta [mailto:sriramr@aarohi-inc.com]
    Sent: Thursday, May 17, 2001 4:07 PM
    To: Sudhir Srinivasan; 'Venkat Rangan'; ips@ece.cmu.edu
    Subject: RE: FCIP: Multiple connections
    
    
    I agree with Sudhir on this. It is harder to make sure that
    both sides adhere to same connection.
    
    - Sriram
    
    >
    > > Implementing this "flow allegiance" is
    > > not a significant incremental effort since in order to map all
    > frames of a
    > > single direction of a flow on to a particular connection, most of the
    > > work is already done anyway.
    >
    > I disagree - mapping in one direction only is much
    > easier than mapping consistently in both directions
    > across multiple vendors' solutions -- both ends have
    > to use the same mapping algorithm or have to remember
    > a LOT of stuff to do this in an interoperable manner.
    >
    > Now let's look at the issues you raise.
    > 1. Asymmetric routing: Routers won't distinguish between
    >    two FCIP connections; so I argue that using a different
    >    connection does not add routing asymmetry.
    > 2. NIC application - Such devices should be built to ensure
    >    that the connections don't span IP addresses (NICs) and
    >    the processing should be done above the TCP port level
    >    so that using a different TCP port wouldn't matter.
    > 3. Connection failure - even with a single connection,
    >    the issue you mention is already there to some extent.
    >    One side may terminate the connection and it will take
    >    a while for the other side to realize it. Also, ULP
    >    mechanisms should kick in to contain the damage.
    >
    > So, in summary, I don't believe these issues are
    > sufficient to justify the extra burden that the rule
    > places on devices or the potential risk of interoperability
    > problems.
    >
    > On the issue of "negotiating", FCIP does not have any notion
    > of parameter negotiation today, correct?
    >
    > -----Original Message-----
    > From: Venkat Rangan [mailto:venkat@rhapsodynetworks.com]
    > Sent: Thursday, May 17, 2001 11:37 AM
    > To: 'Sudhir Srinivasan'; 'ips@ece.cmu.edu'
    > Subject: RE: FCIP: Multiple connections
    >
    >
    > Sudhir,
    >
    > For a given FC Flow (indicated by a SID, DID pair of the FC frames),
    > both forward and reverse directions are mapped to the same connection.
    > This ensures that:
    >
    > 1. Any TCP congestion related rate adjustment on one direction impacts the
    >    other direction equally. Although even a single TCP connection
    > is subject
    > to
    >    variations introduced due to assymmetric routing, we do not want to
    > introduce
    >    more assymmetry by sending forward direction frames of one flow on one
    >    connection and the reverse on a different connection.
    >
    > 2. By allowing forward and reverse traffic flow on different connections,
    >    the protocol may exclude implementation of a class of products that
    >    rely on seeing the forward and reverse traffic on the same NIC where
    >    the connection is processed. If the connections end up on different
    >    NICs or ports and the processing is off-loaded to them, then you have
    >    the need to either exchange state or forward traffic to a common point.
    >
    > 3. Error recovery in the case of TCP connection failure may cause
    > one of the
    >    two directions to be functional while the other is not. If both
    > directions
    >    are mapped to the same connection, such recovery is more
    > easily mapped to
    >    a link/ISL failure.
    >
    > If the protocol allows forward and reverse directions of a flow
    > to be mapped
    > on
    > different connections, I would like to suggest that there is an
    > option that
    > allows a pair of FCIP Device Endpoints to negotiate that both directions
    > must be
    > mapped on to the same connection. Implementing this "flow allegiance" is
    > not a significant incremental effort since in order to map all frames of a
    > single direction of a flow on to a particular connection, most of the
    > work is already done anyway.
    >
    > Regards,
    >
    > Venkat Rangan
    > Rhapsody Networks Inc.
    > http://www.rhapsodynetworks.com
    >
    >
    >
    > -----Original Message-----
    > From: Sudhir Srinivasan [mailto:SudhirS@trebia.com]
    > Sent: Monday, May 14, 2001 1:53 PM
    > To: 'ips@ece.cmu.edu'
    > Cc: Sudhir Srinivasan
    > Subject: FCIP: Multiple connections
    >
    >
    >
    > In Section 5.5, what is the reason to include rule (2)?
    > Is it not sufficient that frames in each direction be delivered
    > in order? Physical analogy is to have two half-duplex lines
    > instead of a full-duplex line. Vendor should have the choice
    > to go either way.
    >
    > -Sudhir
    >
    > Trebia Networks, Inc.                Sudhir.Srinivasan@trebia.com
    > 978-929-0830 x139                   www.trebia.com
    >
    


Home

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