Proposed socket API change

Proposed socket API change

[gerrit]

I have the following proposal to simplify the use of the DCCP socket API
and would like to poll for opinions before  sending any patches to the list:

Suggested Change: If user doesn't want to set a service code, that's fine,
                  leave the service code associated with connection at 0.

Justification: 
In a forthcoming communication to SIGCOMM-06, the inventors of DCCP say that
they were "motivated by keeping the basic API as simple as UDP's" and that
"DCCP should provide applications with an API as simple as that of UDP".

DCCP mandates the use of service codes (RFC 4340, sec. 8.1.2). This is mirrored
in the Linux socket API by throwing an error if the application programmer
did not set a service code.

The actual use of service codes, however, depends on the applications. It seems
that the main intention of using service codes is for middleboxes: " Middleboxes,
such as firewalls, can use the Service Code to identify the application running
on a nonstandard port (assuming the DCCP   header has not been encrypted)."

However, there are applications which do not talk through middleboxes - such as
streaming on the intranet, local LAN applications, or testing applications. 
These would be at a disadvantage if forced to come up with service codes.

What makes UDP simple to program is the use of sensible defaults; a message can
be sent with little set-up effort, due to the use of sensible defaults.

The service code `0' has been singled out and designated to indicate the absence
of a meaningful service code.

So,

 * applications which do not want to allocate a service code leave it at the
   default 0, without being required to pass a socket option
 * applications which depend on service codes are free to do so by explicitly
   setting the socket option

Otherwise, if setting service codes is mandatory, it will require applications to
set `dummy' service codes (which have to be hardcoded into both server and client).

The use of service codes is still initial; only a single service code has been 
registered so far, cf.  http://www.iana.org/assignments/service-codes 

So as to not compromise listening sockets, I was thinking of treating an `uninitialized'
0 on a server socket different from a service code = 0 which has been explicitly set by 
the application.


- Gerrit

Re: Proposed socket API change

[Andrea Bittau]

On Fri, Sep 08, 2006 at 10:31:41AM +0100, gerrit@erg.abdn.ac.uk wrote:
> Suggested Change: If user doesn't want to set a service code, that's fine,
>                   leave the service code associated with connection at 0.

I totally agree with you on this, but I have been killed when suggesting this on
dccp@itef.org.

> Justification: 
> In a forthcoming communication to SIGCOMM-06, the inventors of DCCP say that
> they were "motivated by keeping the basic API as simple as UDP's" and that
> "DCCP should provide applications with an API as simple as that of UDP".

I think the same authors killed me on this point.  I believe their motivation is
"we want service codes to be used" and that they are a useful thing.  I agree
with them, but I don't agree on "forcing the users to use service codes".  

In practice, I think the situation will end up just as you described:
programmers will say "what is a service code?" and all weird things will start
emerging by people setting random codes just to get their application working.
Indeed, question 1 of Linux's DCCP FAQ will end up being: "connect() returns
error HELP!  Did you set a SC?".  Most of the initial DCCP applications will be
test apps anyway, and I think the burden of "inventing" a service code or
assigning one should be avoided.

Re: Proposed socket API change

[gerrit]

|  > In a forthcoming communication to SIGCOMM-06, the inventors of DCCP say that
|  > they were "motivated by keeping the basic API as simple as UDP's" and that
|  > "DCCP should provide applications with an API as simple as that of UDP".
|  
|  I think the same authors killed me on this point.  I believe their motivation is
|  "we want service codes to be used" and that they are a useful thing.  I agree
|  with them, but I don't agree on "forcing the users to use service codes".  
I have the same idea; the proposal is an attempt to make the API simple without
contradicting the spec. UDP also does not contradict its spec and yet is simple
to program; if the same can be done with DCCP, that would be great. 

Thanks for mentioning dccp@ietf.org, have copied message there. If there are no 
strong objections, will send patch on Monday.

- Gerrit

Re: Proposed socket API change

[Ian McDonald]

On 9/8/06, gerrit@erg.abdn.ac.uk <gerrit@erg.abdn.ac.uk> wrote:
> Thanks for mentioning dccp@ietf.org, have copied message there. If there are no
> strong objections, will send patch on Monday.
>
> - Gerrit

I agree about the service code personally but we shouldn't accept into
Linux something that deliberately breaks the RFC. We need to convince
the protocol authors first.

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: Proposed socket API change

[Eddie Kohler]

Well, here's what I think about service codes.  I think I speak for the 
authors here.  This has all been said previously on the list FWIW.


* I think service codes should be part of the sockaddr for DCCP.  The decision 
to make them a setsockopt() I think has made things harder.  From 9/9/05:

> I agree with Arnaldo et al. here.  The Service Code should be considered similar to a port.  It is best to specify it at bind() time, rather than separately.  The structure names may want some updating; sockaddr_in_dccp and sockaddr_in6_dccp, rather than sockaddr_dccp, for example.  The servicecode member should finish off the structure, so that sockaddr_in is a prefix of sockaddr_in_dccp.  And the code should be smart enough to supply a 0 service code if the sa_len corresponds to sockaddr_in instead of sockaddr_in_dccp. 


* I am fine with the default service code being 0.  11/23/05:

> Again, there's always Service Code 0, which "represents the absence of a meaningful Service Code".  This should be the default, if you desperately want a default.


* I am NOT fine, and have never been fine, with 0 acting as a *wildcard* in 
any way.  Service code 0 acts like a specific service code in every way: if a 
Request with Service Code 1 arrived at a listening socket with Service Code 0, 
then the Request would be rejected with Bad Service Code.  Likewise, if a 
Request with SC 0 arrived at a listening socket with SC 1, the Request would 
be rejected with Bad Service Code.


So to summarize, a default SC of 0 is fine, for either listening or active 
sockets, although we still think people should use real service codes.  If the 
following comment suggests woildcarding, then that's not fine.

> So as to not compromise listening sockets, I was thinking of treating an `uninitialized'
> 0 on a server socket different from a service code = 0 which has been explicitly set by 
> the application.



Eddie



Andrea Bittau wrote:
> On Fri, Sep 08, 2006 at 10:31:41AM +0100, gerrit@erg.abdn.ac.uk wrote:
>> Suggested Change: If user doesn't want to set a service code, that's fine,
>>                   leave the service code associated with connection at 0.
> 
> I totally agree with you on this, but I have been killed when suggesting this on
> dccp@itef.org.
> 
>> Justification: 
>> In a forthcoming communication to SIGCOMM-06, the inventors of DCCP say that
>> they were "motivated by keeping the basic API as simple as UDP's" and that
>> "DCCP should provide applications with an API as simple as that of UDP".
> 
> I think the same authors killed me on this point.  I believe their motivation is
> "we want service codes to be used" and that they are a useful thing.  I agree
> with them, but I don't agree on "forcing the users to use service codes".  
> 
> In practice, I think the situation will end up just as you described:
> programmers will say "what is a service code?" and all weird things will start
> emerging by people setting random codes just to get their application working.
> Indeed, question 1 of Linux's DCCP FAQ will end up being: "connect() returns
> error HELP!  Did you set a SC?".  Most of the initial DCCP applications will be
> test apps anyway, and I think the burden of "inventing" a service code or
> assigning one should be avoided.
> -
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Proposed socket API change

[Eddie Kohler]

Last time, vger ate this reply as possible spam, trying again.


Well, here's what I think about service codes.  I think I speak for the 
authors here.  This has all been said previously on the list FWIW.


* I think service codes should be part of the sockaddr for DCCP.  The decision 
to make them a setsockopt() I think has made things harder.  From 9/9/05:

 > I agree with Arnaldo et al. here.  The Service Code should be considered 
similar to a port.  It is best to specify it at bind() time, rather than 
separately.  The structure names may want some updating; sockaddr_in_dccp and 
sockaddr_in6_dccp, rather than sockaddr_dccp, for example.  The servicecode 
member should finish off the structure, so that sockaddr_in is a prefix of 
sockaddr_in_dccp.  And the code should be smart enough to supply a 0 service 
code if the sa_len corresponds to sockaddr_in instead of sockaddr_in_dccp.


* I am fine with the default service code being 0.  11/23/05:

 > Again, there's always Service Code 0, which "represents the absence of a 
meaningful Service Code".  This should be the default, if you desperately want 
a default.


* I am NOT fine, and have never been fine, with 0 acting as a *wildcard* in 
any way.  Service code 0 acts like a specific service code in every way: if a 
Request with Service Code 1 arrived at a listening socket with Service Code 0, 
then the Request would be rejected with Bad Service Code.  Likewise, if a 
Request with SC 0 arrived at a listening socket with SC 1, the Request would 
be rejected with Bad Service Code.


So to summarize, a default SC of 0 is fine, for either listening or active 
sockets, although we still think people should use real service codes.  If the 
following comment suggests woildcarding, then that's not fine.

 > So as to not compromise listening sockets, I was thinking of treating an 
`uninitialized' 0 on a server socket different from a service code = 0 which 
has been explicitly set by the application.



Eddie

Re: Proposed socket API change

[Gerrit Renker]

Hi Eddie,

many thanks for the references and comments; please see inline.

- Gerrit
  
|  * I think service codes should be part of the sockaddr for DCCP.  The decision 
|  to make them a setsockopt() I think has made things harder.  From 9/9/05:
|  
|   > I agree with Arnaldo et al. here.  The Service Code should be considered 
|  similar to a port.  It is best to specify it at bind() time, rather than 
|  separately.  The structure names may want some updating; sockaddr_in_dccp and 
|  sockaddr_in6_dccp, rather than sockaddr_dccp, for example.  The servicecode 
|  member should finish off the structure, so that sockaddr_in is a prefix of 
|  sockaddr_in_dccp.  And the code should be smart enough to supply a 0 service 
|  code if the sa_len corresponds to sockaddr_in instead of sockaddr_in_dccp.
I think the idea is good, but find the realisation problematic:

* sockaddr_in{,6}_dccp would be a special API exception, TCP/UDP use sockaddr_in/6, 
  all other sockaddr_xxx types are indexed by layer-3 name.

* since servers may multiplex different services over the same port, this would
  mean that sockaddr_dccp contains a variable-length list - which may be at odds
  with the maximum length of sockaddr_storage.

* would make integration with v4/v6 getaddrinfo() difficult. The glibc function 
  getaddrinfo() does not yet support DCCP (nor UDP-Lite),  but the conversion/
  upgrade is in principle simple(r) if sockaddr_in/6 are used, as the basic socket
  API can be retained.

Why not achieve the same by providing a library call which takes port number,
service number, v4/v6 address as argument and returns a connected/listening socket
handle? Maybe there is even potential for providing a library call for well-known
services such as get_service_and_port_by_name(), but all this leads far away from
what I actually was concerned about.
 
|  * I am fine with the default service code being 0.  11/23/05:
|  
|   > Again, there's always Service Code 0, which "represents the absence of a 
|  meaningful Service Code".  This should be the default, if you desperately want 
|  a default.
Yes, this is exactly what I meant to ask - if an application really has no present use
for a service code, then give it the default. All other applications will have to
consider the spec, RFC 4340, from which it is clear what to provide.

|  * I am NOT fine, and have never been fine, with 0 acting as a *wildcard* in 
|  any way.  Service code 0 acts like a specific service code in every way: if a 
|  Request with Service Code 1 arrived at a listening socket with Service Code 0, 
|  then the Request would be rejected with Bad Service Code.  Likewise, if a 
|  Request with SC 0 arrived at a listening socket with SC 1, the Request would 
|  be rejected with Bad Service Code.
The main concern was to simplify the socket programming API, while remaining fully
conformant with RFC 4340; without implying any bad uses of default values. 

  
|  So to summarize, a default SC of 0 is fine, for either listening or active 
|  sockets, although we still think people should use real service codes.  If the 
|  following comment suggests woildcarding, then that's not fine.
|  
|   > So as to not compromise listening sockets, I was thinking of treating an 
|  `uninitialized' 0 on a server socket different from a service code = 0 which 
|  has been explicitly set by the application.
That was my fault, the comment was a bit ill-formulated and clarified by one look
at the sources - it considered safely overriding the uninitialised service code state,
not wildcarding.

Re: Proposed socket API change

[Gerrit Renker]

Hi Ian,
|  > Thanks for mentioning dccp@ietf.org, have copied message there. If there are no
|  > strong objections, will send patch on Monday.
|  >
|  > - Gerrit
|  
|  I agree about the service code personally but we shouldn't accept into
|  Linux something that deliberately breaks the RFC. We need to convince
|  the protocol authors first.
That is a good point.

I am in the process of compiling a `dccp socket programming mini how-to', in which all 
these questions play a role. I am currently using the Wand pages as input but would 
appreciate any other information, e.g. if the pmtu discovery issue reported on
http://linux-net.osdl.org/index.php/DCCP_Testing
has been resolved (the to-do list of the same server lists only `PMTU'; if it
is not resolved, it would be a next thing).

- Gerrit