Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-sno-00.txt

From: Joe Touch <[email-masked]>
Date: Wed, 04 Sep 2013 17:34:12 -0700

Hi, all,

Regarding the recent discussion on TCPMUX, we've revived some of our 
earlier work on portnames, focusing on just the ability to decouple the 
service identifier from the SYN destination port.

We have both Linux and FreeBSD implementations underway. A revised draft 
has just been submitted with the details, below.

I'm hoping to publish this as an independent submission, but if there's 
interest in running it through TCPM please let me know.

Joe

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcpm-sno-00.txt
Date: Wed, 04 Sep 2013 17:29:53 -0700
From: [email-masked]
To: Dr. Joseph D. Touch <[email-masked]>, Joe Touch <[email-masked]>

A new version of I-D, draft-touch-tcpm-sno-00.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Filename:	 draft-touch-tcpm-sno
Revision:	 00
Title:		 The TCP Service Number Option (SNO)
Creation date:	 2013-09-04
Group:		 Individual Submission
Number of pages: 19
URL: 
http://www.ietf.org/internet-drafts/draft-touch-tcpm-sno-00.txt
Status:          http://datatracker.ietf.org/doc/draft-touch-tcpm-sno
Htmlized:        http://tools.ietf.org/html/draft-touch-tcpm-sno-00

Abstract:
    This document specifies a TCP option for service numbers. The
    current SYN destination port is used both to indicate the desired
    service and as a connection demultiplexing field. This option
    separates those two functions, retaining the current destination
    port solely for demultiplexing and indicating the service separately
    in a service number option (SNO). By decoupling these two functions,
    SNO allows a larger number of concurrent connections for a single
    service, as might be useful between fixed addresses of proxies.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Rui Paulo <[email-masked]>
Date: Mon, 09 Sep 2013 11:57:17 -0700

On 4 Sep 2013, at 17:34, Joe Touch <[email-masked]> wrote:

> 
> Hi, all,
> 
> Regarding the recent discussion on TCPMUX, we've revived some of our earlier work on portnames, focusing on just the ability to decouple the service identifier from the SYN destination port.
> 
> We have both Linux and FreeBSD implementations underway. A revised draft has just been submitted with the details, below.
> 
> I'm hoping to publish this as an independent submission, but if there's interest in running it through TCPM please let me know.

>From a quick read, I only see one use case mentioned: proxy servers. Are there others?
Changing the TCP stacks of these endpoints just to accommodate a bigger number of connections seems like the wrong approach when you can rework the network architecture and add more proxy servers.

--
Rui Paulo

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Sep 2013 13:42:43 -0700

Hi, Rui,

On 9/9/2013 11:57 AM, Rui Paulo wrote:
>> Regarding the recent discussion on TCPMUX, we've revived some of
>> our earlier work on portnames, focusing on just the ability to
>> decouple the service identifier from the SYN destination port.
>>
>> We have both Linux and FreeBSD implementations underway. A revised
>> draft has just been submitted with the details, below.
>>
>> I'm hoping to publish this as an independent submission, but if
>> there's interest in running it through TCPM please let me know.
>

It could come anytime a single client has a large number of connections 
to a single server. The proxy-to-proxy case is the expected one, but 
that could happen anytime the per-connection rate exceeds a fairly small 
number (around 550/second).

> Changing the TCP stacks of these endpoints just to accommodate a
> bigger number of connections seems like the wrong approach when you
> can rework the network architecture and add more proxy servers.

This solves the issue regardless of how proxies are deployed. It may be 
the "wrong approach" to solve the problem, but arguably overloading the 
SYN destination port with two meanings was the wrong approach in the 
first place.

This is attempt to show how to solve the problem in a clean way. You can 
argue that it's not clean enough, but I'd then ask you to architect a 
solution and document it as an alternative.

FWIW, I doubt this will get a lot of use; it's currently targeted as 
experimental.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Sep 2013 04:31:36 -0300

>    service, as might be useful between fixed addresses of proxies.

Why use this instead of, say, DNS SRV records?

Services should be looked up elsewhere in a directory. Unless I'm
missing something, this proposal seems to be in the wrong layer.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 Sep 2013 10:14:17 -0700

> missing something, this proposal seems to be in the wrong layer.

It might be useful if you can explain your question in the context of 
the current document; this version of the idea doesn't use name strings.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Sep 2013 21:40:26 -0300

> the current document; this version of the idea doesn't use name strings.

The problem is not the namespace, but the function you're trying to
implement at the transport layer. It just doesn't belong there.

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 Sep 2013 19:18:51 -0700

> implement at the transport layer. It just doesn't belong there.

The function is already there. This only decouples the existing dual meanings.

Again, if you can explain vs the current doc it would be more useful.  

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Sep 2013 12:15:46 -0300

> The function is already there. This only decouples the existing dual meanings.

Well-known ports are a kludge that has been useful enough while there
was no complete directory service. The "function" you're referring to is
a "policy" in people's heads rather than a protocol feature. There's
nothing in TCP that says or requires that e.g. a web server must run on
port 80.

> Again, if you can explain vs the current doc it would be more useful.  

I will take a look at the I-D and comment, anyway.

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Sep 2013 09:41:39 -0700

On 9/11/2013 8:15 AM, Fernando Gont wrote:
> was no complete directory service.

Both endpoints need to agree on the service. Service identifiers need to 
be coordinated using a common representation. One is service strings; 
another is port numbers - either one is sufficient.

There is absolutely no reason that the mapping between the two needs to 
exist at all. The current doc focuses on port numbers and the previous 
one name strings, but either way there's no need for a "map".

There is also no reason why a third party - a directory service, as a 
separate service and/or on a separate machine.

> The "function" you're referring to is

If you think there's no need for such a thing, then there's no way to 
find the directory service.

Joe