Thanks for your answers, I shall update this draft this weekend. I
removed the items that I've now put it in the new rev. I have a few
questions in-line, on some topics:
Gorry
Eddie Kohler wrote:
Gorry,
<snip>
=> "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;
>
That then is how the draft shall describe RFC4340.
it must match exactly and is not a wildcard, etc.
>
The term 'wildcard', relating to applications, seems to have caused
problems - sorry for introducing this.
My immediate goal is to make sure I understand how RFC4340 should be read:
* If my understanding is correct, RFC4340 says exactly ONE application
(we do not indicate which) can be associated with a specific SC of zero
on a particular server port.
* Which set of ports do you expect SC=0 to be valid for? All?
The next rev will use this description of RFC4340.
However, at the moment, I can still see issues with multiple
applications using SC=0. Is this indeed what we want: It would help me a
lot, if you can propose a use-case where SC=0 is more useful than simply
SC=?foo (with ?foo chosen by developer). The latter seems at least an
attempt to assure both client and server are using what they this is the
"?foo" service.
- 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".
Right, that is now clear to me.
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.
See above.
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".
I'll ammend.
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,
>
To me (no WG Chair hat - just asking questions to get the draft
correct), it seems we still have a (short) time to reflect on whether we
got this right - we're seeing the first real applications emerge, and
the first implementations that are near complete.
especially when they all share
a port numbers registry, asks for confusion, with no corresponding gain
of usability except something theoretical/religious.
The overloading of a registry with two different approaches would
concern me to. If we go forward with any of the new ideas, the use of a
single common registry would be something that would need to be thought
through.
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.
>
Indeed.
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?
It can parse as far as it is able to interpret (seeing the SDP would
help) - unless for example, it is encrypted.
I am still thinking: I think there *IS* still value in encrypted content
being assigned an appropriate midbox treatment (based on SDP and/or SC)
and then possibly also checking if it conforms to the expected
characteristics.
That would seem to suggest to me, that knowing traffic was being used
for benchmarking would be better than using a private SC. Clearly one
separate SC for each performance tool/technique would also be possible,
although in this case, I wonder if there is anything "more" in
benchmarking headers that it would be worthwhile to parse.
Eddie
Gorry
