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

[Sean Hefty]

>> If you want to maximize consumer usable private data, then
>> you can move the version, IP version, protocol, source and
>> destination ports into the service ID.
>
>Not at the expense of redefining what Service ID is.
>How do you propose to move all these fields into Service ID without
>violating IBTA spec Annex A3.2.? Remember Service ID is what responder
>advertize and requestor sends communucation requests to. It may be
>possible
>to server to advertize multiple service IDs to cover version and IP
>version
>variations but it will not be symmetrical to iWARP. Port is port
>(service ID)
>and address is address. Port does not encode IP version.

The service ID could be formatted as:

Set ID:	24
Version:	 4	
IP version:	 4
Src port:	16
Dst port:	16

I don't see how this violates the spec.  Beyond the set ID, the rest is defined
as "any".  It's not necessary, but it does save 4 bytes of private data for the
user.

>> Separately, if there's any defined mapping to a service ID or
>> set of service IDs, then the service ID indicates the format
>> of the private data.  No additional information is needed in
>> the CM REQ, such as using a reserve bit.
>
>That is a good point.
>But this restricts the usage of IP addressing only to these ports.

It doesn't restrict the usage at all.  It defines a portion of the private data
for a specific range of service IDs, the same way it is done for SDP.  There's
no restriction that other service IDs not use the same format.

Even with the proposal to use a reserved bit in the CM, a particular service
could format its private data this way, not set the bit, and still be spec
compliant.

>The question is what is easier to check 1 bit or Service ID.
>Of course, service ID will have to be checked anyhow to direct the
>request.

Exactly.  If the service ID is checked anyway, why set the bit?

>While this overloads the semantic meaning of Service ID it is a viable
>method.

How is this not viable?  There's a _working_ implementation today for both
userspace and kernel mode clients to connect using IP addressing that didn't
require any modifications to the IB CM.

>> To be clear, the CM REQ _carries_ the IP address.  There
>> should be no requirement that the CM performs the mapping,
>> and I see no reason why it should even care.
>>
>Can you elaborate on this? Is this addresses who populates the formated
>portion of
>the provate data?

I'm referring to who formats the private data and performs the mapping to the
service IDs (slide 13)

- Sean