[openib-general] Re: [swg] Re: private data...

[James Lentini]

On Thu, 20 Oct 2005, Fab Tillier wrote:

> > From: James Lentini [mailto:jlentini at netapp.com]
> > 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.

> 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?

> 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.

> 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?

> 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. 

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.

> Defining service ID ranges for particular protocols then becomes the 
> responsibility of the organizations defining such protocols and the 
> owner of the OUI with which the service ID ranges are defined, and 
> is outside the scope of the IBTA.

This is a good benefit.

I still think viewing this as a new service that uses a well known 
service id is cleaner. Then the addressing protocol and CM protocol 
aren't tied together.