Thanks Ian,
This seems a useful start. I'm not sure what we could do
about the
proliferation of varients of Service Code registrations, but
at this
time I observe more of a drought than a storm of
registrations.
I have been collecting information to improve my
understanding of how
servcie codes should/could work, and how to use them. I'll
try to
collate my own understanding soon and get back to the list,
best wishes,
Gorry
Ian McDonald wrote:
> 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 erg.abdn.ac.uk> 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-port
names-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.
>>
>>
>
>
|