Re: [dccp] Re: wildcard service code?

[Andrea Bittau <a.bittau at cs.ucl.ac.uk>]

On Wed, Nov 23, 2005 at 08:27:28AM -0800, Eddie Kohler wrote:
> were intending to contact.  Think of a NAT, for example; a NAT that  
> changed payload could work for connections using nonstandard ports,  
> if it knew which app was running on which port.

I think the service code is a very good idea for the NAT case.  However, since
some service codes mangle the payload, when I write my new application, I will
have to choose a random service code which doesn't, for my application to work.

> But if most connections on the Internet have the default Service  
> Code, we will never know how much Service Codes could have helped.   
> This is why I'm pushing back.

Similary you will never know if they didn't help as you are forcing people to
use them =D  Perhaps the NULL service code will emerge naturally since not all
applications writers want to interact with the Service Code allocation
authority.

TCP's port number is needed for practical purposes [de-multiplexing].  However,
the Service Code is just polishing the protocol, therefore I believe there
should be a way of making sure it doesn't interact with your application.

> 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.  A Linux- or DCCP-specific default  
> Service Code would be strictly worse than 0.

Shouldn't this be made explicit?  This way an application writer knows that by
using service code 0, no one will modify / drop the payload [unless explicitly
configured].

In practice, everyone will probably start using the WWW SC since it will be the
only one which doesn't get dropped blindly or gets mangled [perhaps a
transparent proxy on the way might do strange stuff].

> application.  For instance, Section 14 says that "fragmentation  
> SHOULD NOT be the default", meaning that DCCP should by default  
> refuse to send any datagram that would lead to a packet larger than  
> the MTU.  Although an implementer might ignore this advice, that  
> would be a shame, since it will lead to worse-performing applications  
> in the end.

Yes agreed.  But the service code doesn't contribute to performance and may
become a niusance for a "I am not patient" developer [which probably shouldn't
code at all =D ].