[openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3

[Sean Hefty]

Kanevsky, Arkady wrote:
> So what you are proposing is that Listener will specify IETF port (2
> bytes).
> CM will generate an IB SID to listen on. That SID will have wildcarding
> for 24 bits.
> The requestor will specify: version, IP version, SRC port and DST port.
> Based on that CM will generate the SID to send request to.

No, the listener or requester generate the SID, not the IB CM - the same way SDP 
works today.

> It will also encode IP addresses into Private data based on IP version.
> 
> This makes IP addresses, SIDs and private data format interdependent and
> not
> orthogonal which it is now.
> It also changes the meaning of SID which currently has a meaning of TCP
> port.

I'm not proposing this.  I'm merely stating that is is a valid option to 
consider.  The private data format and SIDs are not orthogonal anyway.  The port 
number's embedded in the SID, and the SID indicates the format of the private 
data.  They are interdependent by definition.

If it's okay to put the destination port number in the SID, why not the protocol 
type, or IP version?

> It also does not allow to use the private data formating for other SIDs.

Private data is private.  It should not be owned, set, interpreted, modified, or 
touched by the CM.  It's up to the service to define and use.

What's this proposal defines is basically a 65th bit for the service ID.  If the 
new 65 bit SID is:

1 <anything>	- private data has this format
0 <anything>	- private data format is unknown

Why do we need this 65th bit?

> It looks like a big hack. Is it worth it for extra 4 bytes of private
> data
> for Consumers?

It's a trade off between SID space and private data.  Consumers need to decide 
how important those extra 4 bytes are.

- Sean