Re: ipoib-cm multiple connection model
Vandana Rao <[email protected]> Wed, 19 Oct 2005 09:39:31 -0700
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
--===============1375933318== Content-Type: multipart/alternative; boundary="=====================_89815618==.ALT" --=====================_89815618==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Dror, The purpose of the MAD transaction ID is to allow one to do what you say below, i.e. have multiple connection establishment MADs between 2 peers. It is essentially the same as the "channel ID" that you talk about below. Its just that it is a generic channel ID for any MAD transactions, not just CM MADs. I do not believe there is any issue with existing IB CM in this regard. -Vandana At 03:11 AM 10/19/2005, 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 --=====================_89815618==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Hi Dror,<br> The purpose of the MAD transaction ID is to allow one to do what you say below, i.e. have multiple connection establishment MADs between 2 peers. It is essentially the same as the "channel ID" that you talk about below. Its just that it is a generic channel ID for any MAD transactions, not just CM MADs.<br> I do not believe there is any issue with existing IB CM in this regard.<br> -Vandana<br><br> At 03:11 AM 10/19/2005, Dror Goldenberg wrote:<br> <blockquote type=cite class=cite cite=""><font size=2>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> </font> <br> <font size=2>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> </font>_______________________________________________<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></blockquote></body> </html> --=====================_89815618==.ALT-- --===============1375933318== 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 --===============1375933318==--