Re: ipoib-cm multiple connection model
Michael Krause <[email protected]> Mon, 24 Oct 2005 09:46:07 -0700
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
--===============1666386800== Content-Type: multipart/alternative; boundary="=====================_219106037==.ALT" --=====================_219106037==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:32 PM 10/21/2005, Bill Strahm wrote: >Let me try to understand what you are worried about: >I am assuming that each TCP connection (5-tuple) can be on its own CM >connection, and not multiplex a single TCP connection over multiple CM >connections. > >Is this your understanding ? > >Now if this is what we are talking about - we don't have a problem. TCP >only guarantees in order delivery to a single connection - if I have >multiple TCP connections to the same hosts, IP packets can be completely >reordered/jumbled by the intermediate network - and all I am guaranteed >is that each TCP stream will have in order delivery relative to itself. > >I am not aware of any applications where in order IP packet delivery is >required between multiple streams. If this is the case - it has to be >handled above TCP anyway, as TCP does not make this guarantee. >Comments ? Your understanding is correct. IP packets can arrive in any order on any interface though all implementations prefer them to arrive close to in order and on the same interface (Ethernet aggregation technology attempts to maintain the same interface is used consistently). Now, having multiple IB connections between endnode pairs is not an issue - does not matter what VL, path, etc. is taken. However, ideally, the IP datagrams for a given connection are injected for a given tuple on the same path consistently as this leads to optimal performance - it is not a correctness issue though as ordering is the TCP layer's responsibility. Mike >Bill > >Dror Goldenberg wrote: > >>I think that the current model for multiple connections establishment between >>two peers works well for 1 connection but is broken for more than one >>connection. >>Because of cases where CM packets are dropped or travel on different VLs, >>they >>might get reordered on the way and observed in a different order than >>were originally >>sent. This breaks the current model which assumes that the REQs are sent and >>processed in order. >> >>I think that we need to think of a model which is robust to CM packets >>reordering >>which can be one of: >>- Adding a "channel ID" in the private data. The field goes 0,1,2 and on. >>It helps >> synchronizing both peers on which is the channel at question now. The >> rest >> of the decision (per channel) of whether to accept or reject can be >> the same >> as defined in the draft. >>- Not supporting multiple connections between the same peers. >> >>-Dror >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>IPoverIB mailing list >>[email protected] >>https://www1.ietf.org/mailman/listinfo/ipoverib >> > > > >_______________________________________________ >IPoverIB mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/ipoverib --=====================_219106037==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> <font size=3>At 08:32 PM 10/21/2005, Bill Strahm wrote:<br> <blockquote type=cite class=cite cite="">Let me try to understand what you are worried about:<br> I am assuming that each TCP connection (5-tuple) can be on its own CM<br> connection, and not multiplex a single TCP connection over multiple CM<br> connections.<br><br> Is this your understanding ?<br><br> Now if this is what we are talking about - we don't have a problem. TCP<br> only guarantees in order delivery to a single connection - if I have<br> multiple TCP connections to the same hosts, IP packets can be completely<br> reordered/jumbled by the intermediate network - and all I am guaranteed<br> is that each TCP stream will have in order delivery relative to itself.<br><br> I am not aware of any applications where in order IP packet delivery is<br> required between multiple streams. If this is the case - it has to be<br> handled above TCP anyway, as TCP does not make this guarantee.</blockquote><br> <blockquote type=cite class=cite cite="">Comments ?</font></blockquote><br> Your understanding is correct. IP packets can arrive in any order on any interface though all implementations prefer them to arrive close to in order and on the same interface (Ethernet aggregation technology attempts to maintain the same interface is used consistently). Now, having multiple IB connections between endnode pairs is not an issue - does not matter what VL, path, etc. is taken. However, ideally, the IP datagrams for a given connection are injected for a given tuple on the same path consistently as this leads to optimal performance - it is not a correctness issue though as ordering is the TCP layer's responsibility.<br><br> Mike<br><br> <blockquote type=cite class=cite cite=""><font size=3>Bill<br><br> Dror Goldenberg wrote:<br><br> <blockquote type=cite class=cite cite="">I think that the current model for multiple connections establishment between<br> two peers works well for 1 connection but is broken for more than one connection.<br> Because of cases where CM packets are dropped or travel on different VLs, they<br> might get reordered on the way and observed in a different order than were originally<br> sent. This breaks the current model which assumes that the REQs are sent and<br> processed in order.<br> <br> I think that we need to think of a model which is robust to CM packets reordering<br> which can be one of:<br> - Adding a "channel ID" in the private data. The field goes 0,1,2 and on. It helps<br> synchronizing both peers on which is the channel at question now. The rest<br> of the decision (per channel) of whether to accept or reject can be the same<br> as defined in the draft.<br> - Not supporting multiple connections between the same peers.<br> <br> -Dror<br><br> ------------------------------------------------------------------------<br> <br> _______________________________________________<br> IPoverIB mailing list<br> [email protected]<br> <a href="https://www1.ietf.org/mailman/listinfo/ipoverib" eudora="autourl"> https://www1.ietf.org/mailman/listinfo/ipoverib</a><br> <br> </blockquote><br><br> <br> _______________________________________________<br> IPoverIB mailing list<br> [email protected]<br> <a href="https://www1.ietf.org/mailman/listinfo/ipoverib" eudora="autourl"> https://www1.ietf.org/mailman/listinfo/ipoverib</a></font></blockquote> </body> </html> --=====================_219106037==.ALT-- --===============1666386800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPoverIB mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipoverib --===============1666386800==--