Re: [dccp] New draft :draft-ietf-dccp-serv-codes-01.txt

[Eddie Kohler <kohler at cs.ucla.edu>]

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