ipoib-cm multiple connection model
Dror Goldenberg <[email protected]> Wed, 19 Oct 2005 12:11:48 +0200
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1697557823== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D495.84040A00" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5D495.84040A00 Content-Type: text/plain 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 ------_=_NextPart_001_01C5D495.84040A00 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <TITLE>Message</TITLE> <META content="MSHTML 6.00.2900.2769" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>I think that the current model for multiple connections establishment between </FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>two peers works well for 1 connection but is broken for more than one connection.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>Because of cases where CM packets are dropped or travel on different VLs, they </FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>might get reordered on the way and observed in a different order than were originally</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>sent. </FONT></SPAN></SPAN><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>This breaks the current model which assumes that the REQs are sent and </FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>processed in order. </FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2></FONT></SPAN></SPAN> </DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>I think that we need to think of a model which is robust to CM packets reordering</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>which can be one of:</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>- Adding a "channel ID" in the private data. The field goes 0,1,2 and on. It helps </FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2> synchronizing both peers on which is the channel at question now. The rest</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2> of the decision (per channel) of whether to accept or reject can be the same </FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2> as defined in the </FONT></SPAN></SPAN><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>draft.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005><FONT face=Arial size=2>- Not supporting multiple connections between the same peers.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005></SPAN></SPAN> </DIV> <DIV><SPAN class=466025707-19102005><SPAN class=466025707-19102005>-Dror</SPAN></SPAN></DIV></FONT></SPAN></DIV></SPAN></BODY></HTML> ------_=_NextPart_001_01C5D495.84040A00-- --===============1697557823== 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 --===============1697557823==--