RE: ipoib-cm multiple connection model
Dror Goldenberg <[email protected]> Wed, 19 Oct 2005 21:37:11 +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. --===============1723269462== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D4E4.802CA56E" 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_01C5D4E4.802CA56E Content-Type: text/plain 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 <https://www1.ietf.org/mailman/listinfo/ipoverib> ------_=_NextPart_001_01C5D4E4.802CA56E 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"> <META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD> <BODY> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640463119-19102005>Hi Vandana,</SPAN></FONT></DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640463119-19102005></SPAN></FONT> </DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640463119-19102005>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.</SPAN></FONT></DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640463119-19102005>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.</SPAN></FONT></DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640463119-19102005></SPAN></FONT> </DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=640463119-19102005>-Dror</SPAN></FONT></DIV> <BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"> <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Vandana Rao [mailto:[email protected]]<BR><B>Sent:</B> Wednesday, October 19, 2005 6:40 PM<BR><B>To:</B> Dror Goldenberg; [email protected]<BR><B>Subject:</B> Re: [Ipoverib] ipoib-cm multiple connection model<BR><BR></DIV></FONT>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 class=cite cite="" type="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></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C5D4E4.802CA56E-- --===============1723269462== 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 --===============1723269462==--