Subject: [tcpm] TCP port / service names

From: Mark Butler <[email-masked]>
Date: Fri, 14 Apr 2006 19:13:27 -0600

After a quick review of the TCP portnames draft, I have a couple of 
comments / questions:

1. I think the idea of accepting requests for a service on an arbitrary 
port number is an outstanding idea.

2. The nomenclature could use some clarification.  In particular the 
term "port name" in this context is confusing, when a port name can be 
distributed across an arbitrary number of numbered ports. Is there any 
particular reason why "service name" shouldn't be used instead?

2. Is the intent that a port name be a service instance specifier in 
addition to a service type specifier? If just a service type specifier, 
why not just adopt the 32-bit service codes being standardized for 
DCCP?  If both, why not use a DCCP style service type code, plus an 
additional service instance code?

3. Using a name string instead of binary numeric identifiers seems 
unnecessarily expensive.

I would like to see a scheme exactly the same, except have the SYN 
option carry a DCCP compatible service type identifier, plus an 
additional 32 bit service instance identifier, where instance N means 
the Nth instance of the specified service type.

 - Mark B.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Apr 2006 22:01:03 -0700

Hi, Mark,

> particular reason why "service name" shouldn't be used instead?

The difference is that service names appear in many contexts - DNS SRV
records, IANA's keywords, etc. I.e., it's already backwards (service
names already mean port numbers).

That said, if there's a groundswell, we could rename this a "service
option" etc... throughout.

> addition to a service type specifier?

The instance is completely specified by the connection, i.e., by the
socket pair already; having a further specifier would require the option
 in subsequent segments and would unnecessarily complicate all segment
processing, rather than just SYNs and SYN-ACKs. (at least if I
understand what you're suggesting)

> If just a service type specifier,
> DCCP?  

It's redundant to reserve a service name and a service code; we already
do that for port numbers in IANA, and avoiding that sort of thing is
part of what this option was motivated by (see the discussion in the
IETF mailing archives). The strings are sufficient, and not necessarily
less efficient.

> If both, why not use a DCCP style service type code, plus an

I don't see the reason for an instance code here. The goal is to
separate the existing socket pair instance specifier from the service
specifier only.

> 3. Using a name string instead of binary numeric identifiers seems

Considering that more than a few common services are a three characters
long, there's no difference. They're easier to debug. And again then we
have to reserve two things when one will do.

And if we have a set of numbers, we're back to probably deploying a
lookup function again. Part of this was motivated by decoupling the
service name from a set of numbers.

> the Nth instance of the specified service type.

We don't necessarily want to propagate DCCP's notion of service code
groups or instances.

Joe

---

From: Mark Butler <[email-masked]>
Date: Sat, 15 Apr 2006 02:02:17 -0600

Hello Joe,

>names already mean port numbers).
Service names currently _translate_ to port numbers.  That is a big 
difference to being equivalent to port numbers. If the latter were the 
case we would call them "port names", a term which furthers precisely 
the association we should be trying to avoid.

>understand what you're suggesting)
Say you have multiple web servers on the same machine.  Currently one 
specifies which one to connect to by changing the port number.  Now with 
an extension like this a web server can listen on all ports 
simultaneously and the TCP stack will associate incoming connections 
with a web server process by matching on the "port name". So if you want 
to run two different web servers on the same IP address, each one will 
have to use a different port name, i.e. the port name will have to carry 
both service type and instance information.

>separate the existing socket pair instance specifier from the service
There is some confusion about the sense of service instance here.  I 
mean a logically independent provider of network services, and you 
appear to mean a connection over which services are provided.

>long, there's no difference. 
>
If you want to store them in structures, there is a considerable 
difference, because arbitrary length strings generally have to be 
dynamically allocated.  If in a hashed lookup process, every entry in 
the same hash chain has to be strcmp()'d to check for a match, when a 
simple integer comparison or two would otherwise do nicely

>They're easier to debug. And again then we
The service instance number is logically equivalent to the use of the 
port number in a URI like:

http://plasma.example.com:8000/

except they would be much smaller, similar to the digit in "www1", 
"www2", "www3" and so on. Databases like Oracle and DB2 support multiple 
server instances on the same machine and use instance identifiers as 
selectors, both over the network and with environment variables like 
ORACLE_SID and DB2_SID.

Service instance identifiers would not need to be looked up.  
Non-default values would be rare, and used only in cases where more than 
one service process of the same type run on the same IP address.

They could be used more pervasively, e.g. to do NAT dispatching, or to 
reduce the number of IP addresses required in virtually hosted 
environments, but that would require something comparable to SRV 
records.  That is not such a bad option - a DNS lookup generally occurs 
already, and one can get the extra information in the same 
request/response turnaround, right?  All that can be done with ports 
now, but would not be able to be done with the proposed extension unless 
"port names" can include both service type and service (logical 
provider) instance information.

So if the option is a string the question is what standard format should 
it have, or should it be anything goes with a few well known defaults?

>We don't necessarily want to propagate DCCP's notion of service code
I think with service [type] codes the DCCP folks had firewalls more in 
mind, e.g. to support policies where a party is trying to keep a 
particular protocol from being run on any port.  I am told that PPIDs 
were added to SCTP in an attempt to achieve a similar objective.  Any 
standard service naming scheme is likely to contain similar information.

DCCP service instances are an artifact of the way DCCP uses ports, not 
anything designed in, as far as I can tell.  I am just saying that a 
widely used capability should not be thrown away.  IP addresses are hard 
to come by, and a  more extensive use of instance identifiers is one way 
to conserve the IPv4 address space. i.e. a company could adopt a scheme 
where interior nodes are assigned instance identifiers. 

Then the proper instance identifiers for something to establish a 
connection to something like an SIP telephone number could be listed in 
an externally visible DNS zone, and a remote caller could look up the 
public IP address of the NAT box, and the instance number associated 
with the interior node, and establish an inbound connection throught the 
NAT without ridiculous workarounds. No media gateways required either - 
the instance identifier could identify a specific phone, just like a 
telephone extension number, except transparent to the caller.

 - Mark B.

---

From: Joe Touch <[email-masked]>
Date: Sat, 15 Apr 2006 08:31:03 -0700

Hi, Mark,

> Hello Joe,
...
> Say you have multiple web servers on the same machine.

Ah - sorry; now I get the issue:

Then:
a) run a single web server and demux in the service protocol. Originally
web servers couldn't do this because the GET target had the host ID
stripped off; the protocol was changed to include the host ID to support
this.

b) get another IP address; what you're doing by running them on
different ports is overloading the Internet concept of a 'service' and a
'host', IMO.

The issue is one of info and how it is known/shared. See the end for why
(b) is probably what you want for a transport protocol, IMO.

A host on the Internet already needs to know the name and service of the
other host it is contacting, i.e., out of band, in order to establish a
connection.

The current method of "run multiple servers on different port numbers"
is basically equivalent to "run HTTP on what everyone else thinks is a
DNS port".

I.e., the strings are meaningful as service IDs - they've never been
semantic anyway.

There's no reason that a web server MUST bind to a port that says
"HTTP.80", or even "HTTP.53".

If you extend the string to include a service instance, it _must_ be
known by the other end a-priori. There's no difference between:

	"HTTP.3.80" and "HTTP.4.80" (explicit instance IDs)
and
	"HTTP-3.80" and "HTTP-4.80"
or even
	"HTTP.80" and "HTTQ.80"

In all three cases, the service is to the left of the ".80". What it
means is up to the two parties at the ends.

> Currently one

That's one way, as per above. Another is to push the info to the port
number side, i.e., not to listen on all ports, just as we do today:

	HTTP.80 and HTTP.81 could be two different instances

This lets you run 65,536 web servers using today's technique, but allows
you to still run other services on all those ports.

Again, since the origin needs to know - either the service name has
changed on a per instance basis or the port number is specific - why
bother with putting the instance number anywhere that misleads the
designer into thinking otherwise?

> appear to mean a connection over which services are provided.

Agreed; I think I answered your original question above now.

> simple integer comparison or two would otherwise do nicely

Looking 16-bit numbers up in a table is fast and comparatively compact.
Looking 32-bit numbers up in a table is insane - it's far too sparse to
be efficient; you're back to hashing.

Looking up strings can be done quickly and compactly - use a dictionary
tree.

> "www2", "www3" and so on. 

OK - and that works fine as a portname.

> Databases like Oracle and DB2 support multiple

Why is that a problem?

> it have, or should it be anything goes with a few well known defaults?

It's meaningful only between consenting endpoints; the latter seems fine.

> widely used capability should not be thrown away.

It's hard to argue that a technique designed for a fairly recent
protocol is 'widely used'.

> IP addresses are hard
> to conserve the IPv4 address space.

I *REALLY* don't think this is a valid argument in favor of instances.
Instances basically mimic the notion of a host ID; instance IDs are
hidden IP addresses. If that's what you want, then open a connection
with a tunneled IP packet and let the inner tunnel address be your
'instance' demultiplexer'.

I.e., this is solving a problem that is NOT TCP's, which is why I don't
think it belongs at the transport layer.

> i.e. a company could adopt a scheme

---

From: Mark Butler <[email-masked]>
Date: Sat, 15 Apr 2006 22:43:52 -0600

Hello Joe,

>stripped off; the protocol was changed to include the host ID to support
This is fine as long as the ULP supports this, and you have no need to 
run different versions or configurations of the same server software for 
testing purposes or to work around various limitations.  To always run a 
web service using the same service identifier would require a higher 
level demultiplexer akin to a reverse proxy, and there is certainly no 
ULP independent means of doing that.

>different ports is overloading the Internet concept of a 'service' and a
Admittedly, if everyone was running IPv6 this wouldn't be needed very 
much, except to say that process required to safely and effectively 
assign a new service instance id is much simpler than doing the same 
with a separate IP address, and has less internal overhead (ARP, send 
address ambiguity, etc.).   It is also simpler, more reliable, and more 
"portable" than the current process of assigning a non-standard port.

That is just incidental use where IP addresses of the necessary scope 
are actually available. Where they are not easily available, overloading 
on port reaches its logical extreme with NAT - which in practice is 
nothing other than a stand-alone _transport_ layer de-multiplexer.  
Dispatch based only on service type would not allow for the equivalent 
of port forwarding, i.e. a NAT device that implemented solely that 
method would be even less capable of handling inbound connections than 
existing implementations.   On the other hand, a standard service type / 
service instance split would allow a NAT device to de-multiplex inbound 
connections very cleanly.

>is basically equivalent to "run HTTP on what everyone else thinks is a
That is a bit of an overstatement - there are plenty of port numbers 
that have no standard association.

>known by the other end a-priori. There's no difference between:
For non-incidental use, yes.  For pervasive use the service instance 
would have to be looked up using a directory service, just like a phone 
number extension.  There is no hard and fast reason why a service 
endpoint has to be identified by (network address, service type).  
(network address, service type, service instance) is much more flexible.

>means is up to the two parties at the ends.
It is helpful of course to be able to do that at all, but ignoring the 
issue is likely to lead to incompatible adhoc formats.  Say the HTTP 
people wanted to preserve the equivalent of the port selector in the 
current standard URI format, they would necessary have to prescribe the 
way that is formatted in the port name string.  HTTP is particularly 
relevant case because it is extremely common to run multiple HTTP 
speaking "web server" processes on the same host.  Everyone and their 
dog has their own web based configuration interface and there is no 
standard way to get them to share the same port on the same host.  A 
typical server might have half a dozen...

With proper DNS support (a la SRV) the URI issue would go away, but the 
service instance selection issue would remain and would require 
standardization on at least on a ULP by ULP basis.

>designer into thinking otherwise?
Requiring port numbers to be used to be able to do service instance 
selection preserves everything that is wrong about the status quo.  The 
objective here is to use port numbers solely for connection 
disambiguation, right?

>be efficient; you're back to hashing.
I am not talking about linear lookup tables, but rather the cost of hash 
key comparisons on the collision chain, as well as the cost of 
dynamically allocating variable length identifiers.

>Looking up strings can be done quickly and compactly - use a dictionary
Implementing a relatively exotic kernel data structure in an efficient, 
SMP safe manner is not something to be taken lightly.  No one does 
filesystem lookup or caching that way, for example.

>>provider) instance information.
Standardization and efficiency (or rather the lack thereof).

>protocol is 'widely used'.
Instance selection at the transport layer is not something that was 
designed into DCCP.  It is a universal practice with TCP and UDP that is 
an artifact of the way ports are used. That is the widely used 
capability I am speaking of.

>'instance' demultiplexer'.
Network layer tunneling is an enormously complex solution for such a 
simple problem, and would be borderline impossible to implement for 
publically available services in the contemporary environment.

>think it belongs at the transport layer
>  
>
The popularity of NAT devices indicates that something that needs to be 
done at the transport layer. Failure to anticipate this real world 
requirement is *precisely* why NAT is such a ridiculous mess today.   I 
agree in a perfect world this could all be done at a lower or higher 
layer.  In the world as it exists today, however, the problem is most 
easily solved at the transport layer.   That is why everyone uses NAT 
boxes instead of either (1) paying to have their ISP configure and route 
a larger IP address block or (2) running application layer proxies 
exclusively.

 - Mark B.

---

From: Joe Touch <[email-masked]>
Date: Sat, 15 Apr 2006 22:30:46 -0700

> ULP independent means of doing that.

The question is whether that is sensible. If you want to run a web
service on all incoming ports AND all incoming addresses, then that's
what you get, and perhaps that what you should get.

> connections very cleanly.

This is a mechanism to forward on services rather than just ports, which
can help some NAT-created problems. It is NOT a mechanism to reimplement
numbering at the transport layer so that multiple hosts behind a NAT can
now become visible.

NATs create that latter problem, and will ALWAYS end up with it, because
once service names exist they will start remapping those as well.

> typical server might have half a dozen...

A standard way is to run a single web server with multiple 'roots' and
to overload the DNS in the forward direction, i.e., multiple DNS names
that map to a single IP address.

What you're trying to support is running multiple services with the same
name on all incoming ports, where the name is the same and the 'all
ports' is the same and the IP address is the same, but somehow something
is different.

That's not something TCP is designed to address. It's been hacked by
moving services from well-known ports to other ports; that's still
supported here. It can also be supported by overloading the meaning of
the service name.

Since which of the two methods is used is a matter ONLY for the
consenting parties (i.e., the site running the web server and the URLs
it serves), why does it matter?

There are multiple ways of skinning this cat today:
	- DNS overloading with multiple roots on a single server
	- multiple IP addresses
	- separate IP ports

This solution isn't going to get rid of any of these necessarily, nor is
it intended to.

> standardization on at least on a ULP by ULP basis.

The doc discusses why DNS support for SRV records is a non-starter. I
may be given a DNS name by my ISP, but they don't give me permission to
insert a SRV record, nor do I suspect that's in the future.

> objective here is to use port numbers solely for connection

It's to separate service from port. It's not to separate instance from
service or instance from port; separating service from port does NOT
preserve the status quo, even without addressing instance, either.

> filesystem lookup or caching that way, for example.

Dictionary trees aren't exotic; more complex structures are used already
for IP address lookups; SYN matching (and this is ONLY for SYN packets)
doesn't need to happen on a very fast timescale, either.

> capability I am speaking of.

Instance selection can be done in various layers; this doesn't preclude
any of them. It doesn't focus on that as a specific capability, either.

> publically available services in the contemporary environment.

Similar assertions were once made about packet remapping (e.g., NAT),
and about IP forwarding at line rate.

> done at the transport layer.

Actually, it indicates that whatever we do someone will try to undo it,
IMO. Even if we put instances in the service name, someone will decide
that everything behind a NAT ought to look like the same instance.

> Failure to anticipate this real world
> requirement is *precisely* why NAT is such a ridiculous mess today.  

This mechanism can't fix what's broken with NATs, nor will instance numbers.

> I
> layer.

It can and should be done at a lower or higher layer, and still can be
with this mechanism. There's nothing here that undoes existing methods
to get around the problem NATs create. That's why there's no reason to
address that issue specifically.

Joe

  In the world as it exists today, however, the problem is most

---

From: Mark Butler <[email-masked]>
Date: Sun, 16 Apr 2006 01:27:07 -0600

>that map to a single IP address.
Running multiple web sites on the same web server is not equivalent to 
running multiple web server instances, as far as the host operating 
system is concerned.  DNS based solutions do not solve the problem - 
there is a very long list of practical reasons why multiple independent 
web servers get installed on the same machine - often with completely 
independent code bases and supporting infrastructure.  Suppose I install 
Samba or CUPS - each has its own administrative web service that is 
independent of the main web server installation.  Should I have to get 
new IP addresses just for that?  Or should HTTP be moved down into the 
kernel and a new kernel interface created just so that independent web 
services can share the same transport layer port or service id?

>ports' is the same and the IP address is the same, but somehow something
That is rather misleading.  There is no mystery here - the only 
difference is that a name would be replaced by a (service type, service 
instance) pair. 

>supported here. It can also be supported by overloading the meaning of
So what?  The question ought to be: "what should it be designed to address?"

>it serves), why does it matter?
All network protocols are practically speaking simple a matter of 
agreement between consenting parties. Why standardize anything, 
especially to fine levels of detail?  The more particular answer here is 
a transport layer dispatch is simple and ULP independent.  The fact that 
a solution works with HTTP under appropriate conditions does not 
conclude the general argument.

>This solution isn't going to get rid of any of these necessarily, nor is
- DNS overloading only works with HTTP with a shared instance - i.e. it 
doesn't address the instance selection problem at all.
- multiple IP addresses are either impossible or expensive to come by in 
many cases, and surely assigning multiple addresses from the same subnet 
to the same host is at least as decidedly unnatural as using service 
instance identifiers as the transport level.
- Requiring separate port numbers defeats the purpose of making an 
extension like this at all. You end up with a bizarre architectural mess 
actually worse than what we have now, because the old practices can 
never be deprecated.

>insert a SRV record, nor do I suspect that's in the future.
Changing a DNS server entry is much simpler than getting, configuring, 
and likely renumbering additional IP addresses.  Most people do not use 
their ISP to host their DNS services anyway - they either use their 
registrar or run their own DNS server - something they can do with a 
single address.  If I were an ISP providing DNS services however, I 
would much rather upgrade my DNS software to allow common web based DNS 
configuration than assign and configure new customer IP address blocks.  
The latter is a royal pain in the neck (speaking from experience here).

>preserve the status quo, even without addressing instance, either.
Agreed.  But that begs the question of what should an option like this 
_should_ do.  Has the working group previously agreed to solve just that 
problem and disregard related ones?. 

>and about IP forwarding at line rate.
I am not talking about efficiency per se. Sure it can be done a good 
clip.  However, if tunnelling were a simple solution to say the inbound 
NAT connection problem for publically available services (i.e. not VPNs) 
it would very likely have been done by now.  One has to define and 
advertise a new embedded IP address space to the rest of the world. 
Proper support for that would require an extensive list of 
infrastructure changes that would be hard to implement and deploy.

If would be much cleaner to go all the way and extend socket interfaces, 
name service protocols, and ULPs for variable length network addressing, 
say by constructing an extended network address in the form of a stack 
of IPv4 addresses, adding a new IP subheader to hold the full VLA, and 
substituting the "next hop" IPv4 address in the main header whenever 
switching from one IPv4 domain to another.  NATs do the same thing 
already, just in a completely opaque and transport protocol / ULP 
hostile manner.

>that everything behind a NAT ought to look like the same instance.
I think that is unnecessarily cynical.  The impetus to NAT for example,  
is as much an artifact of the fact that network addresses have to be 
administered across organizational boundaries with considerable 
transaction costs, as it is a consequence of the pending IPv4 address 
shortage.  ISPs do not generally run NAT, their customers do to work 
around the ISPs.  Unless one wants to run more than ~4 billion services 
of the same type behind the same address, I can't see the motivation.

>This mechanism can't fix what's broken with NATs, nor will instance numbers.
I think I have given several good example of how instance numbers could 
be used to mitigate the most common problem with NATs - at least for 
connection oriented protocols.

 - Mark B.

---

From: "Caitlin Bestler" <[email-masked]>
Date: Sun, 16 Apr 2006 16:29:04 -0700

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Fri 4/14/2006 10:01 PM
To: Mark Butler
Cc: [email-masked]
Subject: [tcpm] Re: TCP port / service names
 
Hi, Mark,

----------

There are actually three layers of identification relevant here:
the class of the service ("http"), the instance of the server
("http://mydomainname.com/") and the instance of the
connection.

The last is clearly identified by the existing tuple. Distinguishing
between the first two is an interesting question. Certainly the
IP address of the destination is the preferred method, but there
are already complex schemes used by load-balancers to identify
a specific instance of a server based on information that is not 
present in the SYN packet.

That is actually a very key point. The advantage of this proposal
over solutions like TCPMUX or the SDP portmapper is that it allows
more precise control over connection establishment without being
forced to parse payload. After all, a portmapper alone is sufficient
to allow any one IP address to offer 48K distinct services from a
potentially limitless set of possibilities, but that sort of mapping
would be hidden from gatekeepers, or at least hard to access.

The utility of having this information in the SYN packet is exactly
there is need for caution, however. There are only so many option
bytes available. It may be worthwhile to compare and contrast
versus other options that would be desirable to enhance connection
setup to see if they can blend with this or if they are in competion
for the last bytes available that won't interfere with existing equipment.

The most obvious one to me is that if you are going to define new
TCP options to enhance connection setup you should start with
a full Conneciton Cookie scheme, along the line of SCTP, rather
than having to make do with abusing the Initial Sequence Number.
Definitively knowing when a packet was a third handshake would
also be a major benefit for routing traffic when an IP address
has multiple processing elements implementing it.

Should the work group take this on by expanding the charter to
deal with "enhanced connection establishment" in general?

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2006 08:14:57 -0700

> services can share the same transport layer port or service id?

Regardless of how it's supported, the app/user needs to know something
in advance to reach those. I.e., by adding multiple instances on the
same machine you're creating a multiple-virtual host issue.

Using multiple IP addresses is one way to solve this; so is using
specific ports. However, the last solution you suggest is probably the
best - each server should register with the primary server software on
the system; this doesn't require a new kernel interface so much as a new
application interface where virtual servers can register on-the-fly.
Let's call this "dynamic sub-server registration" (DSSR), so I can refer
to it later in this post...

The most important observation, however, is that this is NOT a transport
layer problem.

> difference is that a name would be replaced by a (service type, service

The mystery is why a transport protocol should need to know what an
'instance' is as different from either the service type or host address.

> So what?  The question ought to be: "what should it be designed to address?"

Perhaps the question ought to be "why can't you get another address?" or
"why aren't these all running off of one service and demuxing there?"
There are many good questions, the key is which one to address. ;-)

> conclude the general argument.

It does beg the question: what is the goal of multiple instances?

There are two reasons:
	- coordinate apps that should be coordinating at the app
	layer but currently do not (e.g., HTTP with DSSR)

	- emulate virtual hosts without additional IP addresses

Those are insufficient reasons, IMO. If there are others, they should be
considered, but so far the reasons to support multiple instances are
reminiscent of the reasons for NATs: because the current architecture
isn't convenient, even though the solution isn't part of the current
architecture.

This document is intended to be consistent with the current
architecture, not to solve these new problems. An 'instance option'
could do that in two bytes, which is roughly what it would take anyway.

> doesn't address the instance selection problem at all.

It lets the solution be solved at the app layer, albeit assuming DSSR as
noted above.

> instance identifiers as the transport level.

It depends on what you're doing. If these are all web control interfaces
for different services on the same host, then they ought to sit on the
same IP address. But then you're *really* arguing that portname "DNS"
ought to take both protocol=DNS and protocol=HTTP to allow (e.g.) HTTP
configuration of the DNS server.

That really begs the issue of DSSR; one example might be:
	http://yourhost:portname1/portname2

Where portname1 is the NAMESTRING of the portname option, and portname2
is just the front of the URL and used by DSSR to demux the request to
the right sub-server.

---

Side-note: the use of multiple web servers to control services on a
machine is like running multiple SNMP servers, one for each host
interface. There's no real reason to do this.

> actually worse than what we have now, because the old practices can

The 'old practice' is to using port numbers to indicate service
instances too. DSSR is a way to avoid that, and should be encouraged,
perhaps by NOT supporting this in a new option.

HOWEVER, as noted above, if you want an option for service instance,
propose that separately. It ought NOT be in this one, IMO.

> single address.  

Most people don't manage their address in a DNS entry anywhere. They're
dependent on what their ISP already provides (or doesn't).

> If I were an ISP providing DNS services however, I

Most ISPs will decide that users CAN'T register certain services,
notably ones they think they can charge commercial rates for (e.g., web
servers, mail servers, etc.).

> problem and disregard related ones?. 

This isn't a WG item; it would be useful to review the discussion on the
IETF list to see where this came from and what problem it solves, if
that isn't already sufficiently explained in the document itself.

> it would very likely have been done by now. 

That's basically where HIP and SHIM6 are heading; they just don't 'call'
what they do tunneling.

> One has to define and

Just as one would have to advertise the service instance numbers.

> infrastructure changes that would be hard to implement and deploy.

Again, why isn't this the case for service instance numbers? How do you
know the service instance for your DNS configuration server, vs. the one
that monitors your printers software, vs. the one used to configure your
mail server?

> already, just in a completely opaque and transport protocol / ULP

Perhaps, but service instance IDs are equally opaque.

> around the ISPs.

ISPs include cable companies, telcos, etc. And many provide service only
behind NATs.

> Unless one wants to run more than ~4 billion services

The motivation for ISPs to defeat this is their charging model - which
is one of the reasons they promoted NATs in the first place. It's easier
to serve addresses behind a device you CAN'T run a server on than to
monitor who runs a server so you can charge them more.

> connection oriented protocols.

They may mitigate some things, but they require coordination of the
service instance numbers, which puts us back at square one architecturally.

I think the way to proceed here is to have a separate option for service
instances; they have nothing to do with portnames (or service names) per se.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2006 08:16:35 -0700

Caitlin Bestler wrote:
...
> deal with "enhanced connection establishment" in general?

IMO, that's probably a lot broader than 'minor maintenance'.

Joe

---

From: Mark Butler <[email-masked]>
Date: Mon, 17 Apr 2006 12:57:53 -0600

Joe Touch wrote:

>  
>
> <>Regardless of how it's supported, the app/user needs to know something 

> <>in advance to reach those. I.e., by adding multiple instances on the
This is an important issue - see below.

>'instance' is as different from either the service type or host address.
It is no more mysterious than a transport protocol needing to have the 
concept of service type at all.  TCP currently makes no such distinction 
- the concept of service instance simply flows from introducing service 
type semantics where previously there were none.  The only way to avoid 
the problem is to say that this name string is a dispatch specifier with 
arbitrary semantics. 

No matter what is done there has to be a quasi standard way of binding a 
higher level application to a transport protocol endpoint.  That is not 
strictly speaking a TCP or transport protocol function at all, it is 
just traditionally implemented in the transport layer. The problems are 
sufficiently independent that the semantics of name strings could be a 
completely independent specification, possibly even a layer unto itself, 
in the same sense that say ARP is an independent layer.

>configuration of the DNS server.
Having two protocols like that is unnecessary, cumbersome, and 
confusing.  It doesn't matter what you are configuring (at least not to 
anything at the transport or HTTP layers).  "www1" or "www2" is a more 
accurate reflection of what is going on, except split into two numeric 
fields - e.g. service type=HTTP, server instance=2.

>interface. There's no real reason to do this.
Doing SNMP properly on a general purpose operating system requires 
something comparable to DSSR. As far as there are no established 
standards for doing that - i.e. distributing the SNMP "name" space 
across multiple server processes.

>perhaps by NOT supporting this in a new option.
I like the idea of DSSR internal to a host, for ULPs that can support 
it.  However, DSSR on a NAT is the equivalent of running an application 
layer proxy for each ULP, generally on an underpowered external box that 
is difficult to upgrade.

>dependent on what their ISP already provides (or doesn't).
Every IM or VoIP network has some sort of name service. The main 
practical difference is that most such systems use dynamic registration 
(especially of the current IP address or 'locator' to be used for a 
particular name), where public DNS generally has static entries.  
Neither the user nor the ISP needs to do anything.

> <>

Fair enough.  My point is that the two problem are closely associated 
because of the way ports are currently used, and this is a particular 
point of concern if new APIs are going to be established.  Socket APIs 
should be transport protocol independent as much as possible.

> <>
The SHIM6 people are working on solving the NAT problem?  I thought they 
were working on solving the multihoming problem, in a manner similar to 
SCTP except implemented in layer 3.  I thought they concluded that a 
ULID was going to be one of the existing IP addresses of the system, 
i.e. neither to establish another global layer of address indirection, 
nor to extend the existing address space.

>Just as one would have to advertise the service instance numbers.
The real problem is not advertising -  it is the fact that a tunneled 
address space is fundamentally dissimilar to an extended address space.  
You cannot use tunnels to replace service instances  without dynamically 
numbering or renumbering everything on at least one end on a connection 
by connection basis.  That is what Network Address Translation attempts 
to do already - adding a tunnel is superfluous.

>  
>
>> <>Again, why isn't this the case for service instance numbers? How do you
Current software generally has some non-default port number that you 
must include in the URL. An instance number could be included the same 
way, although registering the instance number with a local name service 
would be the proper way to solve the problem.  The difference between 
that and "DSSR" is that DSSR requires ULP specific name and dispatch 
services, where instance number registration is ULP independent, just 
like SRV.

>Perhaps, but service instance IDs are equally opaque.
No more opaque than telephone extension numbers.  Service instance IDs 
would be statically assigned.  The major problem with NAT is that 
externally visible port numbers are not only not statically assigned (in 
general), they are not readily available.

>ISPs include cable companies, telcos, etc. And many provide service only
They are certainly in a small minority.  .The main reason for an ISP to 
deal with the hassles of running a large customer base behind NAT would 
be a severe address shortage. I can see that condition prevailing for 
various practical reasons in parts of Asia, but in general I don't see 
ISPs having any problem getting at least one address per customer.  DHCP 
is one thing, but NAT creates more problems than it solves at the ISP 
level - especially in terms of customer traceability. 

>monitor who runs a server so you can charge them more.
No amount of architecture can prevent ISPs from doing stupid things, 
unfortunately.  They are the literal "men in the middle" after all.  
Someday, unfortunately, goverment regulation will likely be required to 
set limits on what an ISP can and cannot do in terms of interfering with 
their customer's traffic.  Bills are already before Congress to give the 
FCC explicit authority to do this in the U.S..  So far just the ad hoc 
threat of more extensive regulation seems to be helping.

Promoting NAT is not an effective way to keep users from running 
"servers".  The common method is to block incoming SYN packets - a 
classic example of ISP interference of the type that should be outlawed, 
interference that doesn't stop much more resource intensive P2P use, NAT 
or no NAT,  at all.

>service instance numbers, which puts us back at square one architecturally.
I would say that it lays the foundation for incrementally deployable 
changes that have the potential to solve the major problems with NAT.

>instances; they have nothing to do with portnames (or service names) per se.
That is certainly reasonable.

 - Mark B.

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2006 13:16:29 -0700

Mark Butler wrote:
z...
> layer proxy for each ULP, generally on an underpowered external box that

Isn't that basically where BEHAVE is going?

(or a WG precursor thereto?)

> nor to extend the existing address space.

I'm thinking more of how their solutions include tunneling-like
services; having SHIM6 terminate at the NAT would support the
multihoming behind the NAT.

...
> services, where instance number registration is ULP independent, just

How does the source know it wants instance 2 vs. instance 3?

Right now, it knows because it uses a different port number. However,
the service number space needs to be fairly large to avoid collisions
(i.e., as is done in the port number space by picking from among 'large'
values).

> No more opaque than telephone extension numbers.

Those are a good example of extending the address space using in-band
data. As automated local exchanges have become more prevalent, the use
of extension numbers has decreased over the years.

I.e., the 'right' way to solve that problem was to use the phone number
space. While I agree that might not be a viable alternative for TCP,
that is only because we're in IPv4. Further support at the transport
layer for the lack of IP addresses is a bad idea.

> Service instance IDs
> They are certainly in a small minority. 

I'm on Verizon DSL. My modem is a NAT - I didn't ask for it; that's what
I get.

Anybody else want to report on experience with their "minority" telco or
cable company?

> The main reason for an ISP to
> be a severe address shortage.

1. address shortage
2. limiting services users can run
3. using commodity boxes for multiple hosts, e.g., via wireless
	(even if they have multiple addresses, wireless boxes support
	NAT more than they support managing multiple real addresses)

Depending on who you ask, you'll get a different answer, of course. I
believe it has more to do with their business model, since even those
who assign real IP addresses spin them periodically and won't allow you
to control the reverse DNS name of them.

> I can see that condition prevailing for

Some NATs are at the head-end, some are in registered boxes at the customer.

> interference that doesn't stop much more resource intensive P2P use, NAT

Incoming SYNs block only TCP traffic.

Joe