RE: ipoib-cm multiple connection model
Vivek Kashyap <[email protected]> Tue, 15 Nov 2005 15:06:34 -0800
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <OF8C1DD76D.4FB517ED-ON882570BA.007F0986-882570BA.007F188B@us.ibm.com> |
This is a multipart message in MIME format. --===============1592646987== Content-Type: multipart/alternative; boundary="=_alternative 007F187F882570BA_=" This is a multipart message in MIME format. --=_alternative 007F187F882570BA_= Content-Type: text/plain; charset="US-ASCII" ok..I'll target submitting the updated draft by monday. Vivek -- Vivek Kashyap Linux Technology Center, IBM [email protected] [email protected] Ph: 503 578 3422 T/L: 775 3422 "Dror Goldenberg" <[email protected]> Sent by: [email protected] 11/15/2005 03:04 PM To: "H.K. Jerry Chu" <[email protected]>, <[email protected]>, [email protected] cc: [email protected], [email protected] Subject: RE: [Ipoverib] ipoib-cm multiple connection model I think it's OK. We can move forward from my perspective. > -----Original Message----- > From: H.K. Jerry Chu [mailto:[email protected]] > Sent: Monday, November 14, 2005 9:34 PM > To: [email protected]; [email protected] > Cc: [email protected]; [email protected] > Subject: RE: [Ipoverib] ipoib-cm multiple connection model > > > Hi folks, > > Have we reached a concensus the connection setup procedure in > the current draft is "good enough", or folks still think it > needs to be improved? > > I'd like to see any remaining issue resolved asap so we can > start a WG last call (after Vivke revs the draft based on all > the comments so far). > > Jerry > > >Date: Thu, 27 Oct 2005 22:47:16 -0700 (PDT) > >From: Vivek Kashyap <[email protected]> > >X-X-Sender: [email protected] > >To: Dror Goldenberg <[email protected]> > >Subject: RE: [Ipoverib] ipoib-cm multiple connection model > >MIME-Version: 1.0 > >X-Spam-Score: 0.0 (/) > >X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad > >Cc: "'[email protected]'" <[email protected]>, Vandana Rao > ><[email protected]> > >X-BeenThere: [email protected] > >X-Mailman-Version: 2.1.5 > >List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org> > >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, > <mailto:[email protected]?subject=unsubscribe> > >List-Post: <mailto:[email protected]> > >List-Help: <mailto:[email protected]?subject=help> > >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, > <mailto:[email protected]?subject=subscribe> > > > >Hi Dror, > > > >On Thu, 27 Oct 2005, Dror Goldenberg wrote: > > > >> Hi Vivek, > >> > >> I agree with the flows that you describe, and with the > fact that the > >> original requester has always the "second chance" to withdraw its > >> request by rejecting the REP. However, in my opinion, > giving all this > >> freedom to the implementation can lead to interoperability > issues and > >> poor implementations. If an implementation tries to open n > >> connections with a certain peer, it may end up opening > more or less > >> than n and that might take few iterations and that all > depends on the > >> CM timing and some other "unrelated" parameters - how can you even > >> test it ? I therefore feel that we should provide a robust and > >> deterministic specification of how to establish more than one > >> connection in the RFC or live with a single connection. > > > >I'd like to delve into this a bit more to be sure. As per > >your/Vandana's comments, the left peer will cancel the > request. Isn't > >this is a 'conscious' decision by the ULP? The ULP would then remove > >the its internal object that it would associate with this IB > >connection. If it was successful in cancelling the REQ then there is > >only one connection. > > > >If, however, as you pointed out it is unable to, it might > receive a REP > >*if* the remote peer accepts multiple connections. The left > peer's ulp > >however will not find any object associated with the private > data and > >the connection request (there will be another one already existing > >though) and can use that to indicate rejection. > > > >Does the above sound right? > > > >Vivek > > > >> > >> BTW, this is my opinion in this case, and if folks feel OK > with the > >> current draft, then maybe we should move on ? > >> > >> Thanks > >> Dror > >> > >>> -----Original Message----- > >>> From: Vivek Kashyap [mailto:[email protected]] > >>> Sent: Wednesday, October 26, 2005 10:33 PM > >>> To: Dror Goldenberg > >>> Cc: Vandana Rao; '[email protected]' > >>> Subject: RE: [Ipoverib] ipoib-cm multiple connection model > >>> > >>> > >>> On Wed, 26 Oct 2005, Dror Goldenberg wrote: > >>> > >>>> Vivek, > >>>> > >>>> I agree that the two scenarios you mention here are the > interesting > >>>> ones. I don't agree about the solution. Let's look at the two > >>>> cases: > >>>> > >>>> 1) Left peer accepts > >>>> I disagree. You have an assumption that left peer can > >>>> revoke its original connection request - BEFORE transmitting > >>>> the REP that accepts the peer request. I am not sure that > >>>> you can do it with every CM implementation. Even if you can, > >>>> then the HCA can reorder those packets if they are on > >>>> different QPs, and the fabric can reorder them as well if > >>>> they are on different VLs. > >>> > >>> Yes, that has the potential for extra connections..however, the > >>> following will occur if CM checks don't work. > >>> > >>> Left peer accepted. Sent a REP. And of course the REQ was > also sent. > >>> The right receiver can receive : > >>> > >>> a. REP first > >>> > >>> It sets up the connection. Then receives a REQ. > >>> > >>> i) If it accepts multiple connections from the same peer: > >>> it will REP with a new QP (connection). > >>> > >>> Now, if the left peer decides that it didn't > >>> need another > >>> connection it terminates the connection. > >>> > >>> Otherwise, it is legitimate to setup multiple > connections > >>> since it is equivalent to a second valid request. > >>> > >>> ii) If the right peer does not accept multiple connections from > >>> the > >>> same peer then it will reject the request. > >>> > >>> Note that these decisions in part depend on the ipoib component > >>> peeking > >>> into the local link address and not on CM. > >>> > >>> > >>> b. REQ first > >>> > >>> Since its own REQ is outstanding, and as per link > >>> address comparison, > >>> the left peer accepts then this will be rejected. > >>> > >>> Vivek > >>>> > >>>> 2) Left peer rejects > >>>> I think that this scenario works. > >>>> > >>>> Thanks > >>>> Dror > >>>> > >>>>> -----Original Message----- > >>>>> From: Vivek Kashyap [mailto:[email protected]] > >>>>> Sent: Tuesday, October 25, 2005 11:38 PM > >>>>> To: Vandana Rao > >>>>> Cc: Dror Goldenberg; '[email protected]' > >>>>> Subject: RE: [Ipoverib] ipoib-cm multiple connection model > >>>>> > >>>>> > >>>>> Hi Vandana, > >>>>> > >>>>> I too agree there is no problem here. > >>>>> > >>>>> I think you are right if the left peer accepts the connection. > >>>>> However, if the reverse was the case, that is the left > >>> peer rejected > >>>>> the connection since it is found that the local address is > >>>>> numerically larger. It will do this comparison since its > >>> REQ is also > >>>>> outstanding. The right peer will not receive any REQ (it > >>> is delayed > >>>>> or yet to be retransmitted). If it receives the reject it > >>> will cancel > >>>>> its request. At a later time it will receive the > >>>>> delayed/retransmitted request and one connection will be > >>>>> established. > >>>>> > >>>>> Dror, do these two scenarios look right to you? > >>>>> > >>>>> Vivek > >>>>> > >>>>> On Thu, 20 Oct 2005, Vandana Rao wrote: > >>>>> > >>>>>> 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 > _______________________________________________ IPoverIB mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipoverib --=_alternative 007F187F882570BA_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">ok..I'll target submitting the updated draft by monday. </font> <br> <br><font size=2 face="sans-serif">Vivek</font> <br><font size=2 face="sans-serif">--<br> Vivek Kashyap<br> Linux Technology Center, IBM<br> [email protected] <br> [email protected] <br> Ph: 503 578 3422 T/L: 775 3422<br> </font> <br> <br> <br> <table width=100%> <tr valign=top> <td> <td><font size=1 face="sans-serif"><b>"Dror Goldenberg" <[email protected]></b></font> <br><font size=1 face="sans-serif">Sent by: [email protected]</font> <p><font size=1 face="sans-serif">11/15/2005 03:04 PM</font> <td><font size=1 face="Arial"> </font> <br><font size=1 face="sans-serif"> To: "H.K. Jerry Chu" <[email protected]>, <[email protected]>, [email protected]</font> <br><font size=1 face="sans-serif"> cc: [email protected], [email protected]</font> <br><font size=1 face="sans-serif"> Subject: RE: [Ipoverib] ipoib-cm multiple connection model</font></table> <br> <br> <br><font size=2><tt>I think it's OK. We can move forward from my perspective.<br> <br> > -----Original Message-----<br> > From: H.K. Jerry Chu [mailto:[email protected]] <br> > Sent: Monday, November 14, 2005 9:34 PM<br> > To: [email protected]; [email protected]<br> > Cc: [email protected]; [email protected]<br> > Subject: RE: [Ipoverib] ipoib-cm multiple connection model<br> > <br> > <br> > Hi folks,<br> > <br> > Have we reached a concensus the connection setup procedure in <br> > the current draft is "good enough", or folks still think it <br> > needs to be improved?<br> > <br> > I'd like to see any remaining issue resolved asap so we can <br> > start a WG last call (after Vivke revs the draft based on all <br> > the comments so far).<br> > <br> > Jerry<br> > <br> > >Date: Thu, 27 Oct 2005 22:47:16 -0700 (PDT)<br> > >From: Vivek Kashyap <[email protected]><br> > >X-X-Sender: [email protected]<br> > >To: Dror Goldenberg <[email protected]><br> > >Subject: RE: [Ipoverib] ipoib-cm multiple connection model<br> > >MIME-Version: 1.0<br> > >X-Spam-Score: 0.0 (/)<br> > >X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad<br> > >Cc: "'[email protected]'" <[email protected]>, Vandana Rao <br> > ><[email protected]><br> > >X-BeenThere: [email protected]<br> > >X-Mailman-Version: 2.1.5<br> > >List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org><br> > >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <br> > <mailto:[email protected]?subject=unsubscribe><br> > >List-Post: <mailto:[email protected]><br> > >List-Help: <mailto:[email protected]?subject=help><br> > >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>,<br> > <mailto:[email protected]?subject=subscribe><br> > ><br> > >Hi Dror,<br> > ><br> > >On Thu, 27 Oct 2005, Dror Goldenberg wrote:<br> > ><br> > >> Hi Vivek,<br> > >><br> > >> I agree with the flows that you describe, and with the <br> > fact that the <br> > >> original requester has always the "second chance" to withdraw its <br> > >> request by rejecting the REP. However, in my opinion, <br> > giving all this <br> > >> freedom to the implementation can lead to interoperability <br> > issues and <br> > >> poor implementations. If an implementation tries to open n <br> > >> connections with a certain peer, it may end up opening <br> > more or less <br> > >> than n and that might take few iterations and that all <br> > depends on the <br> > >> CM timing and some other "unrelated" parameters - how can you even <br> > >> test it ? I therefore feel that we should provide a robust and <br> > >> deterministic specification of how to establish more than one <br> > >> connection in the RFC or live with a single connection.<br> > ><br> > >I'd like to delve into this a bit more to be sure. As per <br> > >your/Vandana's comments, the left peer will cancel the <br> > request. Isn't <br> > >this is a 'conscious' decision by the ULP? The ULP would then remove <br> > >the its internal object that it would associate with this IB <br> > >connection. If it was successful in cancelling the REQ then there is <br> > >only one connection.<br> > ><br> > >If, however, as you pointed out it is unable to, it might <br> > receive a REP<br> > >*if* the remote peer accepts multiple connections. The left <br> > peer's ulp <br> > >however will not find any object associated with the private <br> > data and <br> > >the connection request (there will be another one already existing <br> > >though) and can use that to indicate rejection.<br> > ><br> > >Does the above sound right?<br> > ><br> > >Vivek<br> > ><br> > >><br> > >> BTW, this is my opinion in this case, and if folks feel OK <br> > with the <br> > >> current draft, then maybe we should move on ?<br> > >><br> > >> Thanks<br> > >> Dror<br> > >><br> > >>> -----Original Message-----<br> > >>> From: Vivek Kashyap [mailto:[email protected]]<br> > >>> Sent: Wednesday, October 26, 2005 10:33 PM<br> > >>> To: Dror Goldenberg<br> > >>> Cc: Vandana Rao; '[email protected]'<br> > >>> Subject: RE: [Ipoverib] ipoib-cm multiple connection model<br> > >>><br> > >>><br> > >>> On Wed, 26 Oct 2005, Dror Goldenberg wrote:<br> > >>><br> > >>>> Vivek,<br> > >>>><br> > >>>> I agree that the two scenarios you mention here are the <br> > interesting <br> > >>>> ones. I don't agree about the solution. Let's look at the two <br> > >>>> cases:<br> > >>>><br> > >>>> 1) Left peer accepts<br> > >>>> I disagree. You have an assumption that left peer can<br> > >>>> revoke its original connection request - BEFORE transmitting<br> > >>>> the REP that accepts the peer request. I am not sure that<br> > >>>> you can do it with every CM implementation. Even if you can,<br> > >>>> then the HCA can reorder those packets if they are on<br> > >>>> different QPs, and the fabric can reorder them as well if<br> > >>>> they are on different VLs.<br> > >>><br> > >>> Yes, that has the potential for extra connections..however, the <br> > >>> following will occur if CM checks don't work.<br> > >>><br> > >>> Left peer accepted. Sent a REP. And of course the REQ was <br> > also sent. <br> > >>> The right receiver can receive :<br> > >>><br> > >>> a. REP first<br> > >>><br> > >>> It sets up the connection. Then receives a REQ.<br> > >>><br> > >>> i) If it accepts multiple connections from the same peer:<br> > >>> it will REP with a new QP (connection).<br> > >>><br> > >>> Now, if the left peer decides that it didn't<br> > >>> need another<br> > >>> connection it terminates the connection.<br> > >>><br> > >>> Otherwise, it is legitimate to setup multiple <br> > connections<br> > >>> since it is equivalent to a second valid request.<br> > >>><br> > >>> ii) If the right peer does not accept multiple connections from <br> > >>> the<br> > >>> same peer then it will reject the request.<br> > >>><br> > >>> Note that these decisions in part depend on the ipoib component <br> > >>> peeking<br> > >>> into the local link address and not on CM.<br> > >>><br> > >>><br> > >>> b. REQ first<br> > >>><br> > >>> Since its own REQ is outstanding, and as per link<br> > >>> address comparison,<br> > >>> the left peer accepts then this will be rejected.<br> > >>><br> > >>> Vivek<br> > >>>><br> > >>>> 2) Left peer rejects<br> > >>>> I think that this scenario works.<br> > >>>><br> > >>>> Thanks<br> > >>>> Dror<br> > >>>><br> > >>>>> -----Original Message-----<br> > >>>>> From: Vivek Kashyap [mailto:[email protected]]<br> > >>>>> Sent: Tuesday, October 25, 2005 11:38 PM<br> > >>>>> To: Vandana Rao<br> > >>>>> Cc: Dror Goldenberg; '[email protected]'<br> > >>>>> Subject: RE: [Ipoverib] ipoib-cm multiple connection model<br> > >>>>><br> > >>>>><br> > >>>>> Hi Vandana,<br> > >>>>><br> > >>>>> I too agree there is no problem here.<br> > >>>>><br> > >>>>> I think you are right if the left peer accepts the connection. <br> > >>>>> However, if the reverse was the case, that is the left<br> > >>> peer rejected<br> > >>>>> the connection since it is found that the local address is <br> > >>>>> numerically larger. It will do this comparison since its<br> > >>> REQ is also<br> > >>>>> outstanding. The right peer will not receive any REQ (it<br> > >>> is delayed<br> > >>>>> or yet to be retransmitted). If it receives the reject it<br> > >>> will cancel<br> > >>>>> its request. At a later time it will receive the <br> > >>>>> delayed/retransmitted request and one connection will be <br> > >>>>> established.<br> > >>>>><br> > >>>>> Dror, do these two scenarios look right to you?<br> > >>>>><br> > >>>>> Vivek<br> > >>>>><br> > >>>>> On Thu, 20 Oct 2005, Vandana Rao wrote:<br> > >>>>><br> > >>>>>> Hi Dror,<br> > >>>>>> I think you are confusing the 2 IDs that come into play in<br> > >>>>> this setup.<br> > >>>>>> The<br> > >>>>>> communication ID is something that the CM entity on a node<br> > >>>>> understands but<br> > >>>>>> the transaction ID is something that the MAD handling<br> > >>>>> entity uses (for<br> > >>>>>> retransmission, req/resp matchup etc.).<br> > >>>>>> So, in the second slide, there should not be a<br> > >>>>> retransmission of the left<br> > >>>>>> peer REQ MAD since when the left peer accepts the<br> > >>>>> connection, it will cancel<br> > >>>>>> its outstanding REQ request and hence the retransmission<br> > >>>>> should not take<br> > >>>>>> place.<br> > >>>>>> -Vandana<br> > >>>>>><br> > >>>>>> At 12:39 AM 10/20/2005, Dror Goldenberg wrote:<br> > >>>>>>> After giving it some more thought, I think that there <br> > is still a <br> > >>>>>>> problem. Please look at the attached pdf.<br> > >>>>>>><br> > >>>>>>> In the first slide, everything happens smoothly, the left<br> > >>>>> peer knows<br> > >>>>>>> that<br> > >>>>>>> it has to accept the connection and the right peer knows<br> > >>>>> that it has to<br> > >>>>>>> decline.<br> > >>>>>>> On the 2nd slide, the left peer REQ transmission is<br> > >>>>> dropped in the fabric.<br> > >>>>>>> It is retransmitted independently by the CM way after a<br> > >>>>> channel has already<br> > >>>>>>> been established. Now the right side can not really tell<br> > >>>>> whether this is a<br> > >>>>>>> new channel request or an old "simultaneous connection<br> > >>>>> channel". This may<br> > >>>>>>> lead to two channels being opened mistakenly.<br> > >>>>>>><br> > >>>>>>> I don't believe it can be solved by looking at the<br> > >>>>> communication ID.<br> > >>>>>>> This<br> > >>>>>>> number is just being fabricated by the sender of the REQ<br> > >>>>> and is just a<br> > >>>>>>> "random number" with respect to what we're trying to <br> > determine.<br> > >>>>>>><br> > >>>>>>> -Dror<br> > >>>>>>><br> > >>>>>>> -----Original Message-----<br> > >>>>>>> From: Dror Goldenberg<br> > >>>>>>> Sent: Wednesday, October 19, 2005 9:37 PM<br> > >>>>>>> To: 'Vandana Rao'; Dror Goldenberg; [email protected]<br> > >>>>>>> Subject: RE: [Ipoverib] ipoib-cm multiple connection model<br> > >>>>>>><br> > >>>>>>> Hi Vandana,<br> > >>>>>>><br> > >>>>>>> Thanks for clarifying this. I agree that if IPoiB-CM<br> > >>>>> implementation<br> > >>>>>>> looks<br> > >>>>>>> at the Communication ID it can make those decisions<br> > >>>>> correctly. The question<br> > >>>>>>> is whether this value is exposed through common CM APIs.<br> > >>>>> For all other<br> > >>>>>>> purposes, the CM doesn't need to expose the Communication<br> > >>>>> ID to the ULP.<br> > >>>>>>> However, seems like it's not a big deal to expose this<br> > >>>>> value to the ULP.<br> > >>>>>>> Anyway, it worth noting this explanation in the RFC so<br> > >>>>> that it's clear that<br> > >>>>>>> a proper implementation of IPoIB-CM should monitor<br> > >>>>> Communication ID as part<br> > >>>>>>> of the simultaneous connection decision.<br> > >>>>>>><br> > >>>>>>> -Dror<br> > >>>>>>> -----Original Message-----<br> > >>>>>>> From: Vandana Rao [mailto:[email protected]]<br> > >>>>>>> Sent: Wednesday, October 19, 2005 6:40 PM<br> > >>>>>>> To: Dror Goldenberg; [email protected]<br> > >>>>>>> Subject: Re: [Ipoverib] ipoib-cm multiple connection model<br> > >>>>>>><br> > >>>>>>> Hi Dror,<br> > >>>>>>> The purpose of the MAD transaction ID is to allow one to<br> > >>>>> do what you<br> > >>>>>>> say<br> > >>>>>>> below, i.e. have multiple connection establishment MADs<br> > >>>>> between 2 peers. It<br> > >>>>>>> is essentially the same as the "channel ID" that you talk<br> > >>>>> about below. Its<br> > >>>>>>> just that it is a generic channel ID for any MAD<br> > >>>>> transactions, not just CM<br> > >>>>>>> MADs.<br> > >>>>>>> I do not believe there is any issue with existing IB CM in<br> > >>>>> this regard.<br> > >>>>>>> -Vandana<br> > >>>>>>><br> > >>>>>>> At 03:11 AM 10/19/2005, Dror Goldenberg wrote:<br> > >>>>>>>> I think that the current model for multiple connections <br> > >>>>>>>> establishment between two peers works well for 1 <br> > connection but <br> > >>>>>>>> is broken for<br> > >>>>> more than one<br> > >>>>>>>> connection.<br> > >>>>>>>> Because of cases where CM packets are dropped or travel<br> > >>>>> on different VLs,<br> > >>>>>>>> they<br> > >>>>>>>> might get reordered on the way and observed in a<br> > >>>>> different order than were<br> > >>>>>>>> originally<br> > >>>>>>>> sent. This breaks the current model which assumes that<br> > >>>>> the REQs are sent<br> > >>>>>>>> and<br> > >>>>>>>> processed in order.<br> > >>>>>>>><br> > >>>>>>>> I think that we need to think of a model which is <br> > robust to CM <br> > >>>>>>>> packets reordering which can be one of:<br> > >>>>>>>> - Adding a "channel ID" in the private data. The field<br> > >>>>> goes 0,1,2 and on.<br> > >>>>>>>> It helps<br> > >>>>>>>> synchronizing both peers on which is the channel at<br> > >>>>> question now. The<br> > >>>>>>>> rest<br> > >>>>>>>> of the decision (per channel) of whether to accept or<br> > >>>>> reject can be the<br> > >>>>>>>> same<br> > >>>>>>>> as defined in the draft.<br> > >>>>>>>> - Not supporting multiple connections between the same peers.<br> > >>>>>>>><br> > >>>>>>>> -Dror<br> > >>>>>>>> _______________________________________________<br> > >>>>>>>> IPoverIB mailing list<br> > >>>>>>>> [email protected]<br> > >>> https://www1.ietf.org/mailman/listinfo/ipoverib<br> > >>>>>>><br> > >>>>>><br> > >>>>><br> > >>>><br> > >>><br> > >><br> > ><br> > >_______________________________________________<br> > >IPoverIB mailing list<br> > >[email protected] https://www1.ietf.org/mailman/listinfo/ipoverib<br> > <br> <br> _______________________________________________<br> IPoverIB mailing list<br> [email protected]<br> https://www1.ietf.org/mailman/listinfo/ipoverib<br> </tt></font> <br> --=_alternative 007F187F882570BA_=-- --===============1592646987== 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 --===============1592646987==--