Eddie, thank you for your comments, this has been very helpful.
I'm pleased to try to address the issues you raised (see below), and
will make a new revision soon. My belief is that draft is converging
(and it is shortening each rev). I note that several fundamental issues
will still need to be agreed by the WG, before we can finalise things.
Gorry
Eddie Kohler wrote:
Gorry, some comments.
1.0
=> "It is not intended to be used to
specify a variant of an application, or a specific variant of a
protocol."
==> I would soften this, to say "It is not intended to be used to
differentiate minor variants in applications or protocols." I could see
using a service code to differentiate major variants; why not.
I'm not happy in softening it this much. My take would be, that I would
not like to encourage use of it to denote flavours of applications or
specific vendor versions, this makes the use by midboxes more cumbersome
(I included a forward ref to section 2.2, which tries to be more concrete:
"Applications/protocols that provide version negotiation or indication
in the protocol operating over DCCP do not require a new server port for
each new protocol version. New versions of such applications/protocols
SHOULD continue to use the same Service Code. If the application
developers feel that the new version provides significant new
capabilities (e.g. that will change the behavior of middleboxes), they
MAY allocate a new Service Code associated with the same or a different
set of well-known ports. If the new Service Code is associated with
well-known ports, the DCCP Well-Known Ports registry MUST also be
updated to include the new Service Code value."
=> "Only one application may listen on a specific port
at any time,"
==> This contradicts RFC4340.
Not intended.
"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." RFC4340, 8.1.2.
Also this paragraph contradicts itself; the last sentence seems to
indicate multiple applications per listening port.
"An application identifies the requested service by the Service Code
value in a DCCP-CONNECT. Each application may listen on one or more
ports associated with one or more Service Codes."
=> "Use of a Service Code value, instead of binding a service to a
particular publicly-known port number, permits a larger number of
concurrent connections for a particular service. For example, this
may be useful for applications where servers need to handle very
large numbers of simultaneous open ports to the same service."
==> This is misleading. A new connection can only be accepted if BOTH
the Service Code AND the Destination Port match.
True.
I propose:
"The more flexible use of server ports can offer benefit to applications
where servers need to handle very large numbers of simultaneous open
ports to the same service."
Service Codes do not
change the fact that services will most likely bind to well known
ports. Service Codes do not on their own increase the port space. The
most a Service Code does is identify the intended meaning of a port.
Well as I understand a DCCP server that is willing to accept connections
on several ports can associate these all with the same SC (and passively
listen - even if other applications with other codes all "share"
listening to these ports). It can either do this directly, by opening
several ports, or if the OS supports it, the OS could monitor the ports
(as in inetd) and launch on demand. We don't say how applications choose
which specific port to use.
- I will update the later text to explain.
1.1
=> " o The use of port-based firewalls encourages application-writers to
disguise one application as another in an attempt to bypass
firewall filter rules. This encourages firewall writers to use
deep packet inspection in an attempt to validate that the
application actually is that associated with a port number. "
==> And Service Codes do not change this, either. A smart firewall
would STILL use deep packet inspection to verify that data wasn't being
smuggled through a fake Service Code. Service Codes do very little to
increase security on their own, at least from the point of view of
network admins, since they are controlled by possibly malicious parties
(the end hosts). The security impact of Service Codes is simply that
they allow middleboxes to make assumptions based on "intended protocol"
rather than port. Middleboxes must still VERIFY these assumptions.
All true, will rewrite this section, and also include:
"Although Service Codes label a connection and can (and is encouraged
to) associate specific delivery properties (e.g. use Service Codes to
identify the real-time nature of a flow that claims to be using RTP),
there is no guarantee that the actual connection data corresponds to the
associated Service Code. A Middlebox implementor may still therefore
desire to use deep packet inspection, and other means, in an attempt to
verify the content of a connection."
=> "RFC 43404"?
Fixed:-(.
=> "The intent was that the Service Code maintained its original role of
being the globally-unique identifier for the application or protocol
being used over DCCP, and that the pair of ports would effectively be
a 32-bit connection identifier, unique at both end-systems, even
though the two parts were allocated by the two different ends of a
connection. "
==> I don't know what "globally unique" means here. I would cut that
phrase and say "The intent was that the Service Code identify the
application or protocol being used over DCCP, providing middleboxes with
information about the intended use of a connection,".
Agreed. I now have problems with this too. I propose:
"The intent was that the Service Code identified the application or
protocol using DCCP, providing middleboxes with information about the
intended use of a connection, and that the pair of ports effectively
formed a 32-bit connection identifier, which was unique between a pair
of end-systems."
2.1
=> " This section updates section 19.9 of [RFC4340] in the following way:
"Each DCCP port entered in this registry MUST be associated with at
least one pre-defined Service Code (see section 2.2)." "
==> How is this an update? RFC4340:
" Each port registration SHALL include the following information:
...
o A short English phrase describing the port's purpose. This MUST
include one or more space-separated textual Service Code
descriptors naming the port's corresponding Service Codes (see
Section 8.1.2)."
I adapted this from Mark's input, he may be able to explain whether an
update was intended. For now, I shall refer to RFC4340:
"DCCP supports well-known and reserved ports, which are allocated in the
DCCP IANA port registry (Section 19.9 of [RFC4340]). A registered DCCP
port MUST be associated with at least one pre-defined Service Code."
2.2
=> "A single destination port may be associated with more than one
Service Code value."
==> Prefer "passively opened socket" or "listening port" to "destination
port".
I'll make a change.
=> "they MAY allocate a new Service Code (which MAY be associated with
the same set of DCCP well-known ports). "
==> I would advise that people SHOULD update the Well Known Ports
registry in this case, to add the new textual Service Code.
I suggest - if there is a new SC using a well-known port it MUST be
updated in the registry?
3
=> "This section explicitly updates RFC 4340 as follows:
"A DCCP implementation MUST allow multiple applications using
different DCCP service codes to listen on the same server port.
A DCCP implementation SHOULD provide a method that informs a server
of the Service Code value that was selected by an active connection." "
==> I disagree with the first requirement, the MUST. That is too harsh
and I see no need for it.
>
I expect Mark was trying to mandate that multiple passive listeners
could use the same port, to "solve" the limited port-space issues.
However, I agree care is needed. I'm curious how far the working group
would go with this: Is an implementation that supports one listener not
compliant? The current text actually only requires 2 or more listeners
to be supported... Linux (I believe) currently supports 32.
"SHOULD allow more than one Service Code to be associated with a passive
socket, enabling multiple applications, or multiple versions of an
application, to listen on the same port, differentiated by Service Code."
I like the second requirement.
OK
3.2
=> "Middleboxes [RFC3234] SHOULD instead use the Service Code
to identify the application-service (even when running on a non-
standard port). Middlebox devices are therefore expected to check
Service Code values before port numbers for DCCP. "
==> Please drop the word "instead",
Fine.
and replace "before" with "as well
as, or even instead of,". There are good reasons for middleboxes to
check both ports and service codes.
>
Fine.
3.3.1
=> "A Service Code of zero MUST only be accepted for servers that
have no associated Service Code or are explicitly associated with the
Service Code value of zero."
==> Delete "have no associated Service Code or". As RFC4340 and this
draft state, every socket has at least one service code. An
implementation may choose to supply a default of zero, of course, but
that still associates a service code with the app
>
On this we seem to be all at cross-purposes. My take is that RFC4340
says this is "permanently reserved (it represents the absence of a
meaningful Service Code)".
Do we NEED to revise RFC4340 to allow use at all? and if so why?
I am now suggesting: "This document clarifies section 19.8 of RFC 4340:
"Implementations MUST NOT permit applications to listen with a Service
Code of zero"."
That is MUST reject connection using the reserved service code (zero),
and MUST NOT permit applications to listen to this Service Code.
=> " RFC 4340 states that a Service Code MAY be associated with more than
one destination port (corresponding to a set of port values). Also a
single destination port MAY be associated with multiple Service
Codes, although an active (open) connection can only be associated
with a single Service Code. "
==> Actually, RFC4340 only explicitly says the second of these (that a
single passively opened port MAY have multiple SCs), although both are
true.
RFC4340 states that a single passively opened (listening) port MAY be
associated with multiple Service Codes, although an active (open)
connection can only be associated with a single Service Code. This
document updates RFC4340 to add:
"A Service Code MAY be associated with more than one destination port
(corresponding to a specified set of server port values)."
5.1
=> I would cut this section. I disagree with it. In particular I do
not think we should recommend a change in the way OSes allocate DCCP
port numbers.
Could you say more?
6
=> It does not make sense to allocate a single PERF service code for a
number of different and incompatible applications ("e.g., iperf, ttcp,
etc."). This allocation should be dropped or made more specific.
Well, yes and no. I can see why one would comment so from the host-side,
the tools need different servers, hence different service codes.
I can see why this was suggested as a way to identify performance tests
in the network and let such applications transit middlebox interfaces.
Inventing a separate treatment for each perf test seems annoying.
The rationale cited to me is that SC=RTPV covers many different codecs
that do alsorts of different things and are used by a range of
incompatible applications. They all however carry video over RTP. So, is
there a case for all test applications that try to measure performance
be allowed to call them selves "SC=PERF". If not, why not?
Eddie
<snip>
> => Some text here is copied from RFC4340. I do not see the value of
> repeating this text here. But if it is repeated, then it should be
> clearly identified as repeated. A general problem with the document is
> lack of guidance as to what is old and what is new.
>
This is true - and will be addressed.
If you have further responses or comments, do send, and I'll prepare a
new revision.
Gorry
