On 7/26/07, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
On 25/7/07 12:32, "Mark Handley" <M.Handley@xxxxxxxxxxxx> wrote: > OK, here's a draft draft on the issue. I think this is in keeping > with your mail, but provides background too, and I think changes how > IANA allocates DCCP ports. Comments? Flames? > > Shall I turn this into a proper draft, or is there disagreement on this? > > Cheers, > Mark Thanks for the text. The SC draft can be cleaned-up a lot on the basis of this and the discussions from this IETF. The history gives a useful summary of how things evolved, and seems consistent with my recollections. I'll rewrite with this and what you said at the Mic in the meeting.
I think this is a superset of what I said at the Mic. At least that's the intent.
My understanding was that the section on "Sockets, Ports and Service Codes" reflected what was written in SC draft - although I'd be keen to rework the text.
Probably - when I started out I wasn't clear whether I was writing a separate draft, or text for the existing draft or what. In the end I effectively wrote a new draft, so it does duplicate information you've already got, but that was necessary for it to present a reasonably complete and coherent picture. I also started out to write something that was Informational, and ended up with something that would need to be standards-track. That was a surprise, but I think that's how it is.
" or example DTLS connections and unencrypted connections for the same application will normally use different service codes to distinguish them, but as it is the same application, it makes sense to use the same port." - seems OK (if the receiver OS supports this). You then say: "The requirement on the host stack would be that the service code of the incoming connection request can be made available to the application, so that the application can correctly process the data without requiring some application-specific method to distinguish the two types of data." And "A DCCP implementation SHOULD provide a way for the application accepting the connection to discover the service code used in the DCCP-Request packet." - Are you suggesting that after the socket has been opened, the application THEN should call down to the protocol control block to figure out what SC was received?
Yes. Actually I'm not specifying an API, but merely functionality that such an API needs to provide. You could for example provide this information in the upcall that indicated an incoming connection if you have such an API. The protocol spec shouldn't fixate on a sockets API, so I tried to avoid using the term socket where I could.
- or the API requires the application to associate a single SC with EACH listening socket?
If you could have multiple listening sockets on the same app bound to the same port with different service codes, then this would also satisfy the API requirements, as above. But it's not perhaps the simplest API. Again, we need to conceptually separate APIs and protocol requirements. This is about protocol requirements. I was trying to avoid discussing sockets. Perhaps we really have two drafts here: - mine or one based on it that discusses protocol behaviour (standards track) - a second that discusses how sockets implement this behaviour (informational) Mixing the two up would be a bad idea because sockets are not required to implement DCCP (and perhaps aren't even a good API for DCCP).
"We revise RFC 4340 as follows: IANA should allocate well-known DCCP ports on demand to anyone to applies, without requiring a specification or additional justification. Each well-known port request MUST be for a specific registered DCCP service code. IANA should use an allocation policy that attempts to minimize server port collisions, but it is expected that the same well-known port will sometimes be allocated to more than one service code. " - I need to think on this.
Yes, this is more radical - basically saying you can get a well-known port *trivially* easily rather changes the concept of a well-known port. As does expecting collisions. But that is the inevitable consequence of service codes if they are to solve the problem they're intended to solve. - Mark
