Subject: FCIP: Multiple connections

From: Sudhir Srinivasan <[email-masked]>
Date: Mon, 14 May 2001 16:53:04 -0400

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.                [email-masked]
978-929-0830 x139                   www.trebia.com

---

From: Venkat Rangan <[email-masked]>
Date: Thu, 17 May 2001 08:36:53 -0700

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:[email-masked]]
Sent: Monday, May 14, 2001 1:53 PM
To: [email-masked]'
Cc: Sudhir Srinivasan
Subject: FCIP: Multiple connections

-Sudhir

---

From: Venkat Rangan <[email-masked]>
Date: Thu, 17 May 2001 19:11:00 -0700

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.

-----Original Message-----
From: Sriram Rupanagunta [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 4:07 PM
To: Sudhir Srinivasan; 'Venkat Rangan'; [email-masked]
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
> 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?
>
> From: Venkat Rangan [mailto:[email-masked]]
> Sent: Thursday, May 17, 2001 11:37 AM
> To: 'Sudhir Srinivasan'; [email-masked]'
> Subject: RE: FCIP: Multiple connections
>
>
> Sudhir,
>