Folks, I've decided to put together a few random thoughts about service codes together in response to people's pleas to discuss this. Service codes How do applications work today? ------------------------------- Today applications work by using ports to signify the protocol that they are using. Or that is what they are "supposed" to do and there is a list of well known ports. This generally works fairly well on a company internal network but less so on connections to the Internet. Newer applications such as Skype tend to try and use whatever ports they can to beat restrictions imposed by network administrators and/or ISPs. Overall there seems to be a trend to use port 80 and 443 for everything regardless of whether it really is HTTP/S or not. Potential of service codes --------------------------------- I can see the potential for service codes where the user says I want to connect to Skype, or I want to connect to a video conference. I think the main reason for this is that currently applications don't use the ports for the purpose that they were intended. I don't think that they can either due to the way networks today are constructed (firewalls in particular) and the fact that ports are only 16 bits and there are more than 65536 applications on the Internet. Howerver if we go down this path we do have to think carefully. I could see here some balkanization of service codes going on here which would make clients more complicated - e.g. we might get Microsoft Exchange SMTP, Exim SMTP etc which would mean the users would need to know more what they are connecting to. Compatiability with current applications -------------------------------- To implement service codes you would need to either listen on a well known port and then ask for the service code you need or alternatively accept connections on any port, the service code is requested and then ports are then negotiated. Either way applications will need to be altered and the socket calls in glibc (or the equivalent for other OSes) would need to be changed/extended. At present in Linux it is done as a socket option but it should really be done earlier as the connection is already open at that point. The code wouldn't be hard to put in the application as on the client side it only affects socket creation. I think there will be a tendency to use service code 0 for applications as this means in effect bypassing service codes. My personal opinion is that if service codes are seriously intended to be used that this should be removed as an option. If people don't want to register a service code they can use private service codes. I don't think we should underestimate the effort to change APIs around etc as it involves changing the likes of glibc, Python libraries, Java system calls, individual applications for example. Complications with service codes -------------------------- One of the reasons mentioned for using service codes is so that middle boxes can manage traffic. Software such as Skype, P2P will still have an incentive to cheat in the way they bypass ports today if ISPs or firewalls impose restrictions on them. I suspect they will just use service codes that they know will get favoured. My personal opinion on this is that any attempt to try and improve QoS on the Internet for public use is next to useless due to the abuse that goes on. On the Internet I think it is better to treat all traffic equally. On an internal network the story is quite different where it makes sense to favour VoIP or video conferencing and have lower priority for file transfers. This is where service codes could prove quite useful. However one could argue quite validly that this is what ports were for! Conclusion --------------- I am still struggling to see the point of service codes. I think the biggest use will be for corporate networks where it will take the load off middleboxes and they won't have to use such deep packet inspection as they do today (until somebody abuses it). The biggest thing I can see is that it is a chance to start again and use them how ports were intended to be used. This isn't bad in itself as ports are only 16 bits and can't easily be redeemed or extended. Maybe somebody else could come up with an example of how this would all work in the real world and change my slightly pessimistic viewpoint. Ian On 11/2/06, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
We need as a WG to understand what it means to use "Service Codes" - how these should be used by applications, how midboxes may leverage them, and what are the implications of allowing flexible assignments (more opportunities for applications to pretend to be what they are not??) There was not much response to Tom's message - so I'd like to re-start this debate in the WG meeting next week with the aim of getting a sensible and useful outcome which we can put in the User Guide. Gorry ---- Some other reading material, that mentions related topics: RFC4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP). March 2006. Procedures for SCTP, TCP, and UDP Port Assignments by IANA draft-lear-iana-no-more-well-known-ports-02.txt A TCP Option for Port Names (expired) http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt ---- Phelan, Tom wrote: Hi DCCPers, In Montreal, we had a discussion about what service codes should be used by apps using DTLS over DCCP. The discussion was inconclusive, and we decided to continue it on the list, so let's do it :-). Remember that the Service Code is a field in DCCP-Request packets that "Describes the application-level service to which the client application wants to connect." (from RFC4340). This is complicated because we're moving from a world where apps are identified by ports to a world where they're identified by service codes -- and just what do ports mean in this world?. Well-known ports are useful; they allow you to connect without some sort of extra lookup. But if you have a well-known port for an app there's going to be the tendency to identify it by that. And what's the difference between a well-known port and a well-known service code? Why do we have ports? Personally, my view is that service codes should identify apps, and ports allow you to run multiple instances of an app on a server or client. Then there's the question of whether App A running over DCCP is different from App A running over DTLS/DCCP. My conclusion is that they are different, because the app over DTLS/DCCP can offer more services/functions (confidentiality and authentication) than the app over just DCCP (unless these functions were built directly into the app, and then why bother with DTLS?). HTTP and HTTPS (and SIP and SIPS) use different URIs because they offer different services -- similar, sure, but different in some details. I would expect apps that use DCCP to similarly offer different URIs for DTLS or not. So given that, here's some proposed text as a straw man: "An application using DTLS over DCCP MUST register a new service code for the combination." Tom P.
-- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
