Gorry,
Gorry Fairhurst wrote:
"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."
Sounds good.
=> "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."
Good!
=> "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?
RFC4340 doesn't prevent use. RFC4340 reserves two ranges of Service Codes: (1)
the single service code SC=0, and (2) the range SC=1056964608 to SC=1073741823
(the Private Use range). These "reserved" codes are not allocated by the
normal process, but they can still be used in the normal way.
Here's what RFC4340 means
- Service Code SC=0 means "no application info provided". It can be used in
Requests and socket identification. It acts like any other Service Code; it
must match exactly and is not a wildcard, etc.
- Service Code SC=xFFFFFFFF is INVALID. Sockets should be prevented from using
this SC; any Request with this SC is dropped. The Invalid Service Code is
provided so implementations can use a special four-byte value to indicate "no
valid service code". They can't use 0 because 0 IS a valid service code,
meaning "no application info provided".
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"."
Disagree.
That is MUST reject connection using the reserved service code (zero),
and MUST NOT permit applications to listen to this Service Code.
Disagree. We have SC=xFFFFFFFF for that. SC=0 is for "no application info
provided".
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?
I think that's really all I had to say. I see no reason to recommend a change
in the way OSes allocate DCCP port numbers. I think changing this procedure
from TCP/UDP/SCTP to DCCP, especially when they all share a port numbers
registry, asks for confusion, with no corresponding gain of usability except
something theoretical/religious.
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?
RTP has common headers, I believe. So a middlebox can DTRT with an RTPV
service code; based on the service code the middlebox can parse the contents,
to first order. That for me is what service codes fundamentally mean. If the
headers fundamentally differ, so should the service code. If middleboxes can't
use the service code to differentiate parsers, what good is it for?
Eddie
