Tom,
These are good questions, and I'd like to see if we are converging (and seek
other people's inputs too). If we can agree on these things, I can certainly
simplify the SC draft and direct our effort to the undone parts.
On 25/7/07 11:21, "Phelan, Tom" <tphelan@xxxxxxxxxxxx> wrote:
> Hi All,
>
> That was a very interesting discussion of service codes on Monday :-).
> Here are some opinions I've come away with. One of the interesting
> items in the discussion was that one of the purposes of service codes
> was to relieve port scarcity -- it was explicitly intended that multiple
> apps with different service codes could listen simultaneously on the
> same port.
>
Yes - I think that was intended, section 3.3.2 of the SC draft says:
Also a single destination port
MAY be associated with multiple Service Codes (wildcarding a set of
Service Codes), although an active (open) connection can only be
associated with a single Service Code [RFC4340].
The possibility of one well-known port for a SC, is a simple subset (also
allowed).
> I'm going to use socket terminology here because it's too much work to
> think up something totally generic. DCCP sockets have some different
> characteristics from other socket types, but mostly they're the same. I
> see two normal socket call flows, one for initiated connections and one
> for received connections. For initiated connections you call open, bind
> and connect. For received connections you call open, bind, listen and
> accept.
>
OK
> Bound DCCP sockets are slightly different from bound other sockets -- a
> bound DCCP socket has a destination address, destination port AND A
> SERVICE CODE associated with it.
>
That's the way it currently works in Linux, section 5:
o Extend the existing socket parameterization command (e.g., Unix
setsockopt()) to set a service-code option. This is implemented in
the present Linux API for a DCCP socket (where the Service Code
should be wrapped by htonl/ntohl to ensure network byte order).
> Given this I would like to suggest the
> following requirements:
>
> REQ: A DCCP implementation MUST require the using application to
> explicitly set the service code associated with a socket before it can
> be used in a listen or connect request. The service code for a socket
> MUST NOT default to 0. It could default to SC=xFFFF, which is not a
> valid value for SC and will be rejected if ever used.
>
I think there are two possibilities:
* one is to allow an unbound socket to use 0 as the SC, which was written in
section 1.0 as:
If an application does not set a Service Code, the connection is
associated with a Service Code of zero, with the intended server
identified only by the destination port number.
* Another approach is to set the default unbound value to 0xFFFF (i.e.
declared illegal), as you suggest.
As I said at the Prague meeting, I would prefer to see us reduce the Support
models that we support - and IMHO this Minimal support model is the most
difficult to justify, except for backwards API compatibility, if the group
agrees to this, it would simplify things. What do others think?
>
> REQ: A DCCP application in development SHOULD NOT use SC=0. It SHOULD
> choose a code from the private use space (first ASCII character equal to
> '?').
>
I think that the SC draft already says this (i.e. SC:0 is NOT RECOMMENDED).
>
> REQ: A DCCP implementation MUST reject a DCCP-Request with SC=0 if no
> socket is listening on that port with SC=0 (SC=0 MUST NOT be interpreted
> as a wildcard).
>
That's not the way the draft interprets this currently... Since the Minimal
mode was based on what was being implemented. Of co
> Justification: If we allow SC to default to 0, and allow apps to use
> it, we'll get everyone using SC=0 and we'll loose the ability to
> alleviate port scarcity.
>
We spoke about this previously, and that's a danger.
> REQ: A DCCP implementation MUST allow multiple sockets with different
> service codes to listen on the same port.
>
I'd like implementors to feedback on how feasible this was.
This was the most complex of the options that were discussed called the
"Enhanced Support" in the draft - I asked last IETF and this whether we
really wanted to have these levels... So feedback would be good.
> Justification: If some implementations allow multiple listening sockets
> and others don't, app writers are going to be forced to assume the
> lowest common denominator and we'll have port scarcity problems.
>
> I realize that none of the existing implementations work this way, but I
> think that's asking for long-term problems.
>
> Tom P.
>
Gorry
