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.
Yes.
* Which set of ports do you expect SC=0 to be valid for? All?
Welllllll --- I'm not sure what you mean by "valid for". I do not intend for
any Port Number registration to explicitly list SC=0. But implementations are
NOT expected to check Service Code associations against the Port Number
registry. In that sense, SC=0 can be valid for any port, just as ANY valid
Service Code is valid for any port. I hope this is clear.
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.
I don't know what you mean by "useful".
SC=0 allows Unix-like implementations to associate a valid Service Code with
every socket, without changing the procedure used for opening sockets (i.e.,
without adding extra setsockopt calls or adding members to struct sockaddr).
Linux for a time used SC=0 this way; it may still do. Linux could use a
Private Use service code, such as SC=?LNX, to get the same effect; an explicit
service code for "no information about the application" seems cleaner.
I am happy for the draft to say "SHOULD NOT use SC=0". "MUST" or "MUST NOT"
doesn't make sense to me.
I do not think this draft should revise RFC4340.
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.
OK. Well, I think the common registry has huge advantages. The arguments for
a different allocation strategy do not convince me. I don't see what
practical problem is solved by a different allocation strategy, especially
when we have Service Codes to disambiguate multiple registrations on a port.
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.
If you have several benchmarks in mind with incompatible headers, then add
multiple registrations for them to this draft. Those registrations will act
as guides for other developers. A catchall SC for "other undefined
benchmarking programs", with a note about "Any particular benchmarking program
that sends specifically formatted SHOULD allocate its own Service Code; this
Service Code is intended for use by benchmarking programs where (1) the
contents of any Data packet is meaningless, and (2) only the client generates
data", would be OK.
E
