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

[Fab Tillier]

> From: James Lentini [mailto:jlentini at netapp.com]
> Sent: Thursday, October 20, 2005 12:59 PM
> 
> 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.

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