|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: FCIP: Multiple connectionsI 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 |