RE: ipoib-cm multiple connection model
Vandana Rao <[email protected]> Wed, 26 Oct 2005 11:34:50 -0700
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
--===============1220309086== Content-Type: multipart/alternative; boundary="=====================_701526201==.ALT" --=====================_701526201==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Dror, You are absolutely right. It is upto the CM implementation (if it is using multiple QPs for its communication) to ensure that the MADs belonging to the same transaction (by that I mean all the MAD's to setup a connection) end up on the same UD QP. If not, there is potential for the state machines to get messed up. -Vandana At 12:20 AM 10/26/2005, Dror Goldenberg wrote: >Hi Vandana, > >The ability to revoke a request is a CM API issue that may or may >not be present in an implementation. Assuming it is present, you >might be late to revoke, e.g. the CM has already scheduled the REQ >to be retransmitted. In which case, you have a very strong >assumption that the retransmitted REQ will go out to the wire BEFORE >the REP will. This assumption may break in the following cases: >1) The CM uses more than one QP, in which case the HCA can reorder >those packets >2) The CM uses different SL/VL, in which case the fabric can reorder >the packets >3) The CM may choose to internally queue the packets and then submit >them to the HCA. This internal queuing mechanism can reorder >packets, e.g. when you have a queue per CPU. > >My feeling is that relying on packet ordering between different >unrelated streams won't be robust, and can cause more connections to >be established than were actually required. > >-Dror >-----Original Message----- >From: Vandana Rao [mailto:[email protected]] >Sent: Thursday, October 20, 2005 7:25 PM >To: Dror Goldenberg; Dror Goldenberg; '[email protected]' >Subject: RE: [Ipoverib] ipoib-cm multiple connection model > >Hi Dror, >I think you are confusing the 2 IDs that come into play in this >setup. The communication ID is something that the CM entity on a >node understands but the transaction ID is something that the MAD >handling entity uses (for retransmission, req/resp matchup etc.). > So, in the second slide, there should not be a retransmission of > the left peer REQ MAD since when the left peer accepts the > connection, it will cancel its outstanding REQ request and hence > the retransmission should not take place. >-Vandana > >At 12:39 AM 10/20/2005, Dror Goldenberg wrote: >>After giving it some more thought, I think that there is still a >>problem. Please look at the attached pdf. >> >>In the first slide, everything happens smoothly, the left peer >>knows that it has to accept the connection and the right peer knows >>that it has to decline. >>On the 2nd slide, the left peer REQ transmission is dropped in the >>fabric. It is retransmitted independently by the CM way after a >>channel has already been established. Now the right side can not >>really tell whether this is a new channel request or an old >>"simultaneous connection channel". This may lead to two channels >>being opened mistakenly. >> >>I don't believe it can be solved by looking at the communication >>ID. This number is just being fabricated by the sender of the REQ >>and is just a "random number" with respect to what we're trying to determine. >> >>-Dror >> >>-----Original Message----- >>From: Dror Goldenberg >>Sent: Wednesday, October 19, 2005 9:37 PM >>To: 'Vandana Rao'; Dror Goldenberg; [email protected] >>Subject: RE: [Ipoverib] ipoib-cm multiple connection model >> >>Hi Vandana, >> >>Thanks for clarifying this. I agree that if IPoiB-CM implementation >>looks at the Communication ID it can make those decisions >>correctly. The question is whether this value is exposed through >>common CM APIs. For all other purposes, the CM doesn't need to >>expose the Communication ID to the ULP. However, seems like it's >>not a big deal to expose this value to the ULP. >>Anyway, it worth noting this explanation in the RFC so that it's >>clear that a proper implementation of IPoIB-CM should monitor >>Communication ID as part of the simultaneous connection decision. >> >>-Dror >>-----Original Message----- >>From: Vandana Rao [ mailto:[email protected]] >>Sent: Wednesday, October 19, 2005 6:40 PM >>To: Dror Goldenberg; [email protected] >>Subject: Re: [Ipoverib] ipoib-cm multiple connection model >> >>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 >_______________________________________________ >IPoverIB mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/ipoverib --=====================_701526201==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Hi Dror,<br> You are absolutely right. It is upto the CM implementation (if it is using multiple QPs for its communication) to ensure that the MADs belonging to the same transaction (by that I mean all the MAD's to setup a connection) end up on the same UD QP. <br> If not, there is potential for the state machines to get messed up.<br> -Vandana<br><br> At 12:20 AM 10/26/2005, Dror Goldenberg wrote:<br> <blockquote type=cite class=cite cite=""><font size=2 color="#0000FF">Hi Vandana,<br> </font> <br> <font size=2 color="#0000FF">The ability to revoke a request is a CM API issue that may or may not be present in an implementation. Assuming it is present, you might be late to revoke, e.g. the CM has already scheduled the REQ to be retransmitted. In which case, you have a very strong assumption that the retransmitted REQ will go out to the wire BEFORE the REP will. This assumption may break in the following cases:<br> 1) The CM uses more than one QP, in which case the HCA can reorder those packets<br> 2) The CM uses different SL/VL, in which case the fabric can reorder the packets<br> 3) The CM may choose to internally queue the packets and then submit them to the HCA. This internal queuing mechanism can reorder packets, e.g. when you have a queue per CPU.<br> </font> <br> <font size=2 color="#0000FF">My feeling is that relying on packet ordering between different unrelated streams won't be robust, and can cause more connections to be established than were actually required.<br> </font> <br> <font size=2 color="#0000FF">-Dror<br> </font> <dl> <dd><font face="Tahoma" size=2>-----Original Message-----<br> <dd>From:</b> Vandana Rao [<a href="mailto:[email protected]" eudora="autourl"> mailto:[email protected]</a>] <br> <dd>Sent:</b> Thursday, October 20, 2005 7:25 PM<br> <dd>To:</b> Dror Goldenberg; Dror Goldenberg; '[email protected]'<br> <dd>Subject:</b> RE: [Ipoverib] ipoib-cm multiple connection model<br><br> </font> <dd>Hi Dror,<br> <dd>I think you are confusing the 2 IDs that come into play in this setup. The communication ID is something that the CM entity on a node understands but the transaction ID is something that the MAD handling entity uses (for retransmission, req/resp matchup etc.).<br> <dd> So, in the second slide, there should not be a retransmission of the left peer REQ MAD since when the left peer accepts the connection, it will cancel its outstanding REQ request and hence the retransmission should not take place.<br> <dd>-Vandana<br><br> <dd>At 12:39 AM 10/20/2005, Dror Goldenberg wrote:<br> <blockquote type=cite class=cite cite=""> <dd><font size=2 color="#0000FF">After giving it some more thought, I think that there is still a problem. Please look at the attached pdf.<br> </font> <dd> <br> <dd><font size=2 color="#0000FF">In the first slide, everything happens smoothly, the left peer knows that it has to accept the connection and the right peer knows that it has to decline.<br> <dd>On the 2nd slide, the left peer REQ transmission is dropped in the fabric. It is retransmitted independently by the CM way after a channel has already been established. Now the right side can not really tell whether this is a new channel request or an old "simultaneous connection channel". This may lead to two channels being opened mistakenly.<br> </font> <dd> <br> <dd><font size=2 color="#0000FF">I don't believe it can be solved by looking at the communication ID. This number is just being fabricated by the sender of the REQ and is just a "random number" with respect to what we're trying to determine.<br> </font> <dd> <br> <dd><font size=2 color="#0000FF">-Dror<br> </font> <dd> <dl> <dd><font face="Tahoma" size=2>-----Original Message----- <dd>From: Dror Goldenberg <dd>Sent: Wednesday, October 19, 2005 9:37 PM <dd>To: 'Vandana Rao'; Dror Goldenberg; [email protected] <dd>Subject: RE: [Ipoverib] ipoib-cm multiple connection model<br><br> </font> <dd><font size=2 color="#0000FF">Hi Vandana,</font> <dd> <dd><font size=2 color="#0000FF">Thanks for clarifying this. I agree that if IPoiB-CM implementation looks at the Communication ID it can make those decisions correctly. The question is whether this value is exposed through common CM APIs. For all other purposes, the CM doesn't need to expose the Communication ID to the ULP. However, seems like it's not a big deal to expose this value to the ULP. <dd>Anyway, it worth noting this explanation in the RFC so that it's clear that a proper implementation of IPoIB-CM should monitor Communication ID as part of the simultaneous connection decision.</font> <dd> <dd><font size=2 color="#0000FF">-Dror</font> <dl> <dd><font face="Tahoma" size=2>-----Original Message----- <dd>From: Vandana Rao [ <a href="mailto:[email protected]" eudora="autourl"> mailto:[email protected]</a>] <dd>Sent: Wednesday, October 19, 2005 6:40 PM <dd>To: Dror Goldenberg; [email protected] <dd>Subject: Re: [Ipoverib] ipoib-cm multiple connection model<br><br> </font> <dd>Hi Dror, <dd>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. <dd>I do not believe there is any issue with existing IB CM in this regard. <dd>-Vandana<br> <dd>At 03:11 AM 10/19/2005, Dror Goldenberg wrote:<blockquote type=cite class=cite cite=""> <dd><font size=2>I think that the current model for multiple connections establishment between <dd>two peers works well for 1 connection but is broken for more than one connection. <dd>Because of cases where CM packets are dropped or travel on different VLs, they <dd>might get reordered on the way and observed in a different order than were originally <dd>sent. This breaks the current model which assumes that the REQs are sent and <dd>processed in order. </font> <dd> <dd><font size=2>I think that we need to think of a model which is robust to CM packets reordering <dd>which can be one of: <dd>- Adding a "channel ID" in the private data. The field goes 0,1,2 and on. It helps <dd> synchronizing both peers on which is the channel at question now. The rest <dd> of the decision (per channel) of whether to accept or reject can be the same <dd> as defined in the draft. <dd>- Not supporting multiple connections between the same peers.<br> <dd> <dd>-Dror</font> <dd>_______________________________________________ <dd>IPoverIB mailing list <dd>[email protected] <dd> <a href="https://www1.ietf.org/mailman/listinfo/ipoverib" eudora="autourl"> https://www1.ietf.org/mailman/listinfo/ipoverib</a></blockquote> </blockquote> </dl> </dl> </dl>_______________________________________________<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> --=====================_701526201==.ALT-- --===============1220309086== 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 --===============1220309086==--