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

[Kanevsky, Arkady]

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

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

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

Arkady


Arkady Kanevsky                       email: arkady at netapp.com
Network Appliance Inc.               phone: 781-768-5395
275 Totten Pond Rd.                  Fax: 781-895-1195
Waltham, MA 02451-2010          central phone: 781-768-5300
 

> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com] 
> Sent: Thursday, November 10, 2005 6:53 PM
> To: Kanevsky, Arkady; Sean Hefty
> Cc: swg at infinibandta.org; dat-discussions at yahoogroups.com; 
> openib-general at openib.org
> Subject: RE: [openib-general] RE: [dat-discussions] socket 
> based connectionmodel for IB proposal - round 3
> 
> >> 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
>