Tom, here are my notes - Eddie may like to reply - but from my side most
of this seems in-line with my thinking, and hopefully is now better
reflected in the new rev of the draft to be published soon.
My understanding (tell me if I am wrong) is that multiple applications
ARE allowed to share the port using different service codes - but there
can only be ONE active application with any combination of
{src-IP,dst-IP,src-port,dst-port}, and this MUST be associated with the
SC used in the connect. I see ths as the "Enhanced Support" model, not
the default for the moment.
The dst port is still used for demux of packets in the flow.
Comments are MOST welcome on the next rev of the draft (ask again if
needed!!!)
Gorry
Phelan, Tom wrote:
Hi Eddie,
So I've gone back and reread what the spec says on service codes, and
you're correct that what I suggested is in conflict. I didn't mean to
be in conflict; I'm only trying for clarity. I'll try again and please
comment.
I see two possible scenarios that result from what the spec says,
depending on what the implementer decides to do about "Passive sockets
MAY, at the implementation's discretion, be associated with more than
one Service Code; this might let multiple applications, or multiple
versions of the same application, listen on the same port,
differentiated by Service Code".
If the implementer decides to not do this (only one service code per
port):
o Each actively listening destination port is associated with one and
only one service code.
o The same service code can be associated with multiple ports.
o Applications that want to support multiple versions of their protocol
on one port must not use different service codes for those versions (the
HTTP/1.0--HTTP/1.1 example below). They must differentiate the versions
at the application level.
o At the listening system, the service code functions as an "are you
sure?" mechanism. You've connected to a port, now prove you really know
what you're doing by giving me a second indication that this is what you
intend.
If the implementer decides to support this (multiple service codes
associated with a port):
o Each actively listening destination port is associated with one or
more service codes.
o The service code sets associated with different ports can overlap in
any manner.
o The service code functions as an additional demux mechanism -- OK,
you've connected to a port that supports multiple services, which one do
you want? It's like the tcpmux service on port 1 for tcp.
o The spec then gives the implementer two more choices to make --
whether a single application is allowed to use multiple service codes,
and whether multiple applications are allowed to share the port using
different service codes.
o If the implementer supports multiple service codes per application,
then version differentiation through service codes is possible.
o If the implementer supports multiple applications sharing the same
port, then I'm not sure what destination port means anymore -- one port
could support all of the services the system wants to offer (or not
depending on the next item).
o Implementers will need to apply some limit to the number of service
codes that can share a port -- the spec is silent on what this should
be. Some implementers will choose a large number, others a small one.
Is this correct?
Tom P.
-----Original Message-----
From: Eddie Kohler [mailto:kohler@xxxxxxxxxxx]
Sent: Wednesday, June 06, 2007 3:11 PM
To: Phelan, Tom
Cc: gorry@xxxxxxxxxxxxxx; DCCP mailing list
Subject: Re: Comments on draft-fairhurst-dccp-serv-codes-03.txt
Tom,
The addition of service codes by DCCP allows us to break this
demultiplexing/identifying duality. We can now say that the
*exclusive*
use of port numbers is for demultiplexing, and the *exclusive* use
of
service codes is for identifying applications. This implies a few
rules:
We COULD say this, but why would we? It also goes against the
language
in the DCCP RFC, which explicitly allows a listening socket to be
associated with multiple Service Codes. (Think HTTP/1.0 and
HTTP/1.1.)
Similarly, the DCCP stack MUST understand Service Codes, as it is
required to send an error if service codes don't match.
Gorry's draft should not be redefining the RFC in my opinion. On the
other hand I still don't quite understand the goal of Gorry's draft.
Eddie
o Demultiplexing is based on the source and destination IP address
and
source and destination port numbers only, just as it is for the
other
connection-oriented transports. Only one application/socket can
"listen" on a port number for incoming connection requests.
o It is not necessary for the DCCP stack to know the service code
associated with an application that is listening on a port number,
since
the DCCP stack is really only concerned with demultiplexing, not
application identity. A DCCP stack SHOULD (MUST?) allow an
application
to check the service code in an incoming DCCP-Request and decide
whether
or not to proceed with the connection. A DCCP stack MUST NOT
require an
application to perform this check. A DCCP stack MAY (SHOULD?) allow
an
application to pre-specify the service code[s] that it will accept
and
process incoming DCCP-Requests based on that information.
o A DCCP stack MUST allow an application to specify the service
code to
be used in DCCP_Request packets.
o Applications MAY use well-known port numbers to facilitate
client/server rendezvous.
o Applications SHOULD register and use a service code specific to
the
application.
o Devices, for example, firewalls, wishing to identify an
application
associated with a connection MUST use only the service code.
Devices
MUST NOT use port numbers to identify the type of application using
a
connection.
Comments appreciated :-).
Tom P.
