Subject: RE: [tcpm] Re: TCP port / service names

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 17 Apr 2006 16:25:05 -0700

Mark Butler wrote:
> Joe Touch wrote:

> 
> 
> 	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.
> 
> 
> 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.
> 

Actually a major benefit of of enhancing connection setup
options would be to enable a middlebox to act as a traffic
cop *wihthout* acting as an application layer proxy. As you
point out, it is not well designed for that purpose, and
middleboxes looking at TCP payload is inherently unclean
and risky.

I would agree that there is not much of a benefit of
a middlebox doing multiplexing of logical websites
when all of them are delivered to the same daemon
on the same processor anyway. But allowing a virtual
host that is implemented by a cluster of devices
to do its first step filtering of connection setup
*without* having to look at TCP payload would be
a major benefit both for performance and architectural
integrity.

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

---

From: Mark Butler <[email-masked]>
Date: Mon, 17 Apr 2006 19:24:18 -0600

Caitlin Bestler wrote:

> <>
Compared to payload inspection techniques, absolutely.  Enhanced 
connection options of the sort we are talking about will require per 
flow state to do protocol level traffic shaping though, because each 
packet will no longer carry even weakly ULP identifying information.

>a major benefit both for performance and architectural
I can see how enhanced connection options this might be used internal to 
a cluster, but not how it would help on the client facing side.  A 
virtual host is completely accessible through a single HTTP/1.1 
connection right?

 - Mark