Gorry Fairhurst wrote:
Eddie Kohler wrote:
<snip>
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".
>
OK, I'm suggesting:
"A Service Code of zero is "permanently reserved (it represents the
absence of a meaningful Service Code)" [RFC 4340]. This indicates that
no application information was provided. RFC 4340 stated that
applications MAY be associated with this Service Code in the same way as
other Service Code values. This use is permitted for any server port.
This document updates section 19.8 of RFC 4340:
"Applications SHOULD NOT use a Service Code of zero.
Application writers that need a temporary Service Code value SHOULD
choose a value from the private range (Section 2.3).
If the application requires a new Service Code, one may either be chosen
a value from the private range (Section 2.3), or a new Service Code may
be requested from the IANA."
Private Use range is intended for interim uses, before app gets a real SC from
IANA. I wouldn't specifically recommend it. Last P: "Deployed applications
requiring new Service Codes should request specific Service Code assignments
for their protocols from the IANA."
"MUST" or "MUST NOT" doesn't make sense to me.
I do not think this draft should revise RFC4340.
I still think that "updating RFC4340" is not really what this doc is doing, so
would cut the "This document updates", but am OK
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,
Seems good to me, updated text.
and (2) only the client generates data", would be OK.
But why this constraint No. (2)? - this seems odd: we could have a tool
in which only the server sends data... one in which the client responds
to each data packet with some response... They are all benchmarking.
SC defines protocol; protocol constrains messages in both directions. If a
benchmarking program generates one-way data, and the data has no meaningful
format, that seems like a "protocol" description to me, and I can't imagine a
middlebox meaningfully differentiating. If a benchmarking program DOES expect
server replies, well, that is meaningfully different, and I can imagine a
middlebox wanting to differentiate -- for example, by allowing one kind of
perftest and not the other
E
E
Gorry
