> From: James Lentini [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 20, 2005 12:59 PM > > On Thu, 20 Oct 2005, Fab Tillier wrote: > > > > From: James Lentini [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, October 20, 2005 11:39 AM > > > > > > I like Sean's idea better. Have a well know service id or range of > > > service ids on which this protocol is used. I think of it as a service > > > running on top of the CM protocol for using IP addresses on native IB. > > > I don't think it should be mandatory for every CM connection. > > > > The well known service ID implies that a DAPL application *would* > > prevent a TCP application from using a particular port, which seems > > to conflict your statement that DAPL apps shouldn't prevent TCP apps > > from working. > > I don't understood what you mean by TCP application. I assumed you > meant an application that uses the Berkley sockets API to communicate > over TCP, but I see now that is not what you meant. This IBTA > proposal does not involve any interactions with the TCP protocol > stack.
I meant a TCP application that was re-routed over IB through the use of some protocol (SDP-like). SDP itself isn't a good example because it already handles the IP addressing issues itself in the hello message. > > That's not to say you couldn't have one range of service IDs for TCP > > applications, > > What do you mean by "TCP applications" in this context? Applications that expect TCP-like behavior with respect to IP address and port usage. > > and another range for DAPL applications, > > I don't see a reason why DAPL applications couldn't take advantage of > the services being provided by the proposed protocol. It depends on whether DAPL expects to consume a full TCP address (IP+port), or is just using the IP addresses to 'facilitate' connection establishment. > > and yet another range per protocol or application that wishes to use > > IP addressing during connection establishment. > > How are the applications in this group different from the "TCP > applications" above? An application may wish to use IP addresses (without port numbers) to allow users to easily specify addressing information in a way they are familiar with. However, such an application may not care about the port number at all, and there's no need to force it to claim a port (and thus prevent someone who cares about port numbers from getting one). DAPL to me fell into this category, but maybe it falls into the "TCP" category. > > However, this doesn't extend the CM protocol, but just creates an > > ad-hoc group of protocols that happen to define the first 32-bytes > > of their private data similarly. > > > > Having a bit in the CM REQ indicate whether the first 32-bytes of > > private data contain the source and destination IP addresses allows > > any app using any service ID to use IP addresses as source and > > destination identifiers regardless of what protocol they actually > > use once the connection is established. > > For a particular protocol, I would expect this addressing service > either to be used or not used. I can't envision a situation were you > would want the protocol to use this service in some situations and not > use the service in others. Using a bit allows the protocol to be used independently of the service ID, allowing any client, using any service ID, to use the facility if it so desires. I wasn't advocating allowing arbitrary use of the protocol with any given service ID, and I agree with you that the protocol would be either used or not given a particular service ID. > If multiple protocols are going to be using the same service id (some > times an server for protocol X is listening on service ID Z, sometimes > a server for protocol Y is listening on service ID Z,...) and their > use of this service isn't consistent, then I agree that the CM bit > solves this problem. The CM bit allows protocol usage to be clear and independent of service ID. It comes down to whether we want to tie protocol use with a set of SIDs, rather than defining a protocol generically, and just tying SID usage to protocol use. - Fab _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
