RE: FCIP: Multiple connections

["Sriram Rupanagunta" <sriramr@aarohi-inc.com>]

Venkat,

> - the reverse direction frames are sent to the same IP address of
>   the source of the forward direction.
>

This would still not eliminate the need for the FCIP peers
to maintain some sort of state information. They would still need
to remember the IP addresss from which they received each flow,
and make sure to use appropriate connection to send the
reverse traffic.

Imposing any rule other than rule 1 (Sec 5.5) would make the
implementations more difficult, without any great benefit.

I agree with you to some extent about the error recovery situation,
but then, we need to come up with scenarios, to make sure that
these additional rules solve a real problem, before adding
them, and increasing the complexity of implementations.

- Sriram

> [Sudhir]
> This precludes taking advantage of multi-homed NICs (not that
> I see that as very critical, but somebody else might).
> I think the real way to solve this problem is to complete
> the specification of how discovery on the IP plane will happen.
> If there is a way of establishing tunnel context during
> connection setup, then each side can independently enforce
> any property such as "NIC allegiance" as needed rather than
> putting a rather arbitrary blanket requirement in the standard.
>
> - 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.
>
> [Sudhir]
> What if the FCIP device reboots and gets a different IP address
> from DHCP? I don't see the need for this.
>
>
> 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
> >
>