Subject: [core] Proxy and server on the same port

From: Klaus Hartke <[email-masked]>
Date: Tue, 16 Nov 2010 18:08:21 +0100

Terminology:
- server: an end-point that serves resources;
- proxy: an end-point that can be tasked with retrieving/manipulating
remote resources on behalf of a client;
- gateway: an end-point that looks/feels/smells like a server, but
forwards requests to one or more servers and/or handles requests on
behalf of them.

During the Beijing plugfest, I noticed that requests to my
implementation (which runs a server and a proxy on the same port)
repeatedly got stuck in an infinite loop.

Before we had mandatory Uri-Authority, my implementation simply did this:

    if Uri-Authority is present:
        resolve Uri-Authority to IP address
        forward request to resolved address
    else:
        serve resource

Now, my implementation does this:

    if Uri-Authority in { [::1]:61616, 127.0.0.1:61616,
localhost:61616, coap.no-ip.org:61616, 92.224.240.96:61616,
g224240096.adsl.alicedsl.de:61616, [2002:5ce0:f060::5ce0:f060]:61616
}:
        serve resource
    else:
        resolve Uri-Authority to IP address
        forward request to resolved address

This makes the proxy forward requests to itself when a client knows an
authority for the server which the server/proxy doesn't know about
(e.g., because it's behind a NAT, there are additional A/AAAA records,
etc.)

Is this a bug in my implementation? Do we need to change the protocol?
Or are proxy and server on the same port generally discouraged?

Klaus

(For reference, I'd expect a gateway to operate like this:

   if Uri-Authority == server1:61616:
        forward request to IP address configured for server1
   elif Uri-Authority == server2:61616:
        forward request to IP address configured for server2
   elif Uri-Authority in { [::1]:61616, 127.0.0.1:61616, ... }:
        serve resource
   else:
        return 404
)

---

From: Zach Shelby <[email-masked]>
Date: Wed, 17 Nov 2010 09:24:42 +0200

> forwards requests to one or more servers and/or handles requests on

Yep.

> Or are proxy and server on the same port generally discouraged?

To me the answer is discouraging (forbidding?) running a proxy and a server on the same port. Running a proxy and a server on the same port is not common practice with HTTP servers either as far as I know.   

Zach

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 17 Nov 2010 15:27:02 +0100

> To me the answer is discouraging (forbidding?) running a proxy and a server on the same port. Running a proxy and a server on the same port is not common practice with HTTP servers either as far as…

What about this: A proxy runs on [2001::xx:1]:61616. A client believes
that [2001::xx:1]:61616 is a server (for example, because
[2001::xx:1]:61616 actually was a server like half an hour ago). The
client sends a request for coap://[2001::xx:1]:61616/resource to
[2001::xx:1]:61616. The proxy begins to retrieve
coap://[2001::xx:1]:61616/resource on behalf of the client. Because it
cannot retrieve the resource immediately, it ack's the client's
request. While the client has no reason to not believe the remote
end-point is a server and will return the requested resource in a few
moments, the proxy will forward the request to itself, which will
cause it to forward the request to itself, which will cause it to
forward the request to itself, ...

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 22 Nov 2010 15:29:09 +0100

Proposal: We resurrect the Uri-Scheme Option, but without a default
value. The rules are:

* If an end-point is configured to make the request though a proxy,
the end-point must include the Uri-Scheme Option in the request.
* If an end-point is not configured to make the request through a
proxy, the end-point must not include the Uri-Scheme Option in the
request.
* If an end-point receives a request with Uri-Scheme Option but isn't
a proxy, it must send a 4xx response.
* If an end-point receives a request with Uri-Scheme Option and is a
proxy, it forwards the request according to the first two rules.
* If an end-point receives a request without Uri-Scheme Option but
isn't a server, it must send a 4xx response.
* If an end-point receives a request without Uri-Scheme Option and is
a server, it handles the request.

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Mon, 22 Nov 2010 08:38:19 -0600

Back on 23Oct, I sent an email entitled "Proxy versus Gateway" that proposed
clarifying some terminology.  Nobody responded, but I see it's become ticket
#72.  I would like to see some discussion before taking on any
responsibilities associated with that ticket.

If what I proposed is to be adopted, much of this confusion may go away.
Putting a proxy on the same port as a server is unnecessarily confusing in
that situation.  They really are completely different applications, used in
different ways.

Peter

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 22 Nov 2010 17:09:36 +0100

> responsibilities associated with that ticket.

I think it makes a lot of sense to distinguish between end-points that
act on behalf of a client and those that act on behalf of a server.
Not sure what needs to be discussed (apart maybe from the actual terms
used for the two roles).

> that situation.  They really are completely different applications, used in

Exactly.

My proposal makes the intended meaning of a request explicit and
leaves no room for uncertainty, regardless of whether there is a proxy
and server on the same port or not.

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Mon, 22 Nov 2010 10:53:54 -0600

> Not sure what needs to be discussed (apart maybe from the actual terms

Just that I proposed completely rewriting section five to get CoAP to use
specific terms in the way I described in my email, which would result in a
significant change (clarification) to what "proxy" means, and a separation
of it from the concept of a "cache".  Your comment above is not the same
thing, and since nobody else has commented I don't think my email should be
the basis of a ticket.

In what I proposed, a client is specifically configured to use a (single)
proxy, and that proxy is providing specific enhanced services on behalf of
the client.  With that model it makes little sense to accommodate placing
the proxy at the same end-point (port) as a normal server.

However, if there's no buy-in for that change, and there's some compelling
reason why we should accommodate two applications at a single port, I
suppose a set of rules to use UriScheme values as a cue to whether a request
might have been intended for a proxy or a server could be made to work.
"Don't do that" seems like a better approach, in my opinion.

Peter

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 22 Nov 2010 18:22:28 +0100

> thing, and since nobody else has commented I don't think my email should be

I thought my comment above would capture the essence of your email,
but apparently it didn't. So here's an attempt at a more complete
summary of your email:

* Intermediary CoAP end-points act as both a client and a server in
order to forward, with possible translation, requests and responses.

* A proxy is an intermediary selected by a client. A client can
delegate all CoAP requests it can't do itself to a proxy.
Configuration of this proxy for a particular node is an administrative
function outside the scope of CoAP.

* A gateway (a.k.a., reverse proxy, big brother, ...) is an
intermediary imposed by the origin server to support sleeping nodes or
perform any other role that might be hidden behind the authority part
of a URI.

* Caching in turn is a function that may be paired with a proxy or
with a gateway, but is not inherently coupled to either one.

Please correct me if I'm missing something essential.

> "Don't do that" seems like a better approach, in my opinion.

There are two things:

1. Does it make sense to run a proxy and a server on the same port?

The answer is probably: No.

2. What to do when a client thinks an end-point is a server when it's
actually a proxy?

The solution is to have the client say what it thinks, so that its
wrong assumption can be pointed out by the recipient.

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Mon, 22 Nov 2010 11:53:30 -0600

On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke <[email-masked]> wrote:

> but apparently it didn't.

Sorry,  I didn't read it that way.

> So here's an attempt at a more complete
> summary of your email:
>

OK.

> function outside the scope of CoAP.

Yes.

> perform any other role that might be hidden behind the authority part

 Almost; the origin server may be unaware of the presence of a gateway.  The
network may impose the gateway.

> with a gateway, but is not inherently coupled to either one.

Yes.

> Please correct me if I'm missing something essential.

Not at first glance,

So you do agree with what was in that email?  I assumed the complete lack of
response meant nobody thought it relevant.

> The answer is probably: No.

Good.

> actually a proxy?

Ah.  I lost the context from the earlier parts of the thread, and assumed
your proposal was a way to allow dual-use.  In fact, your rules seem to be a
complete workable solution that does allow dual use.  Nice.  That's not what
raised my hackles.

> wrong assumption can be pointed out by the recipient.

That is a good solution.  But in the details, I think it would be more clear
if the client does say what it thinks (that it's talking with a proxy),
rather than creating complex rules on how to interpret Uri-Scheme to infer
that it thinks it's talking with a proxy.  So use a new option named
Uri-Proxy with no value, the presence/absence of which indicates the
client's expectations.  Don't overload Uri-Scheme to mean something weird
that could conflict with future use, e.g. putting a coap and a coapm
(multicast) service on the same port.

Change Uri-Scheme to Uri-Proxy in your proposal and you've got a solution
that allows disambiguation while at the same time allowing both functions to
occur on the same port and not muddying what Uri-Scheme means.  That's the
sort of approach I like: one technique that solves multiple problems
without introducing new ones.  Barring some undiscovered flaw, I'd support
that.

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 22 Nov 2010 19:27:43 +0100

> network may impose the gateway.

Oh, that's what "imposed by the network" means. Good.

> So you do agree with what was in that email?

Yes. That's why there's a ticket which consists of a link to your email. :-)

> occur on the same port and not muddying what Uri-Scheme means.

Works for me. I just know Zach's dislike for new options, and
Uri-Scheme seemed to be used only in proxy (not gateway) scenarios so
far.

Klaus

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 23 Nov 2010 09:31:22 +0100

> So you do agree with what was in that email?  I assumed the complete lack of response meant nobody thought it relevant.

Actually, this thread is very relevant.
I am currently investigating CoAP multi-subnet environments with sleeping nodes and I am very much in favor of a precise terminology.
 
Unfortunately I am still not 100% up to speed on CoRE. What is the preferred way of indicating that a node (typically the default gateway) provides caching on behalf of other servers in the same subnet? and in another subnet?
 
Thanks,
  Anders

________________________________

Fra: [email-masked] på vegne af Peter Bigot
Sendt: ma 22-11-2010 10:53
Til: Klaus Hartke
Cc: core
Emne: Re: [core] Proxy and server on the same port

	

OK. 

Yes. 

 Almost; the origin server may be unaware of the presence of a gateway.  The network may impose the gateway.

Yes.

Not at first glance,

So you do agree with what was in that email?  I assumed the complete lack of response meant nobody thought it relevant.

	There are two things:

Good.

Ah.  I lost the context from the earlier parts of the thread, and assumed your proposal was a way to allow dual-use.  In fact, your rules seem to be a complete workable solution that does allow dual use.  Nice.  That's not what raised my hackles.

That is a good solution.  But in the details, I think it would be more clear if the client does say what it thinks (that it's talking with a proxy), rather than creating complex rules on how to interpret Uri-Scheme to infer that it thinks it's talking with a proxy.  So use a new option named Uri-Proxy with no value, the presence/absence of which indicates the client's expectations.  Don't overload Uri-Scheme to mean something weird that could conflict with future use, e.g. putting a coap and a coapm (multicast) service on the same port.

Change Uri-Scheme to Uri-Proxy in your proposal and you've got a solution that allows disambiguation while at the same time allowing both functions to occur on the same port and not muddying what Uri-Scheme means.  That's the sort of approach I like: one technique that solves multiple problems without introducing new ones.  Barring some undiscovered flaw, I'd support that.

	Klaus

---

From: Zach Shelby <[email-masked]>
Date: Tue, 23 Nov 2010 10:51:07 +0200

> Yes. That's why there's a ticket which consists of a link to your email. :-)

I also agree with the improved definitions for Section 5. We are talking with Brian about how to make those changes. This will need changes to Section 7 on HTTP mapping as well.

> Uri-Scheme seemed to be used only in proxy (not gateway) scenarios so

;-) Sorry for playing option police, but someone has to do it. Adding a Uri-Proxy option would not bother me, as this is only needed by a proxy or a client using it.

Regarding Uri-Scheme I am becoming less convinced that we need that at all with the Chapter 5 terminology improvements and a Uri-Proxy option (not sure if the name is perfect). But that is a different thread. 

Zach

---

From: [email-masked]
Date: Tue, 23 Nov 2010 09:57:19 +0100

> Almost; the origin server may be unaware of the presence of a gateway.
The network may impose the gateway.

I'm sorry but I can't catch the exact meaning of "any other role that might
be hidden behind the authority part
of a URI".
A gateway acting as a reverse proxy could for example implement a cache for
sleeping nodes. The reverse proxy can map the sleeping nodes into its own
namespace. In that case it's not just the authority part of the URI but the
full URI that is used to decide what should be done.
coap://bigbrother1.example.org/sensor1/ is actually redirected to
coap://sensor1.example.org/
coap://bigbrother1.example.org/sensor2/ is actually redirected to
coap://sensor2.example.org/

Or maybe you want to separate the different functions of the gateway into
different domain names that resolve to the same IP?
coap://cache.example.org/ implements the caching feature
coap://http.example.org/ implements HTTP translation
coap://6to4.example.org/ implements IPv6 to IPv4 translation
But then I suppose it could also be defined like that:
coap://gateway.example.org/cache/
coap://gateway.example.org/http/
coap://gateway.example.org/6to4/

On the other hand a gateway acting as a transparent/interception proxy will
use some IP magic to answer on the behalf of the origin server. In that
case the gateway only uses the authority part of the URI (or the
destination address). But transparent proxying requires some advanced IP
stack features that are not always available:
   1. Redirect sessions destined to the outer network to a local process
using a packet filter rule.
   2. Make it possible for a process to listen to connections on a foreign
address.
   3. Make it possible for a process to initiate a connection with a
foreign address as a source.

Could you please tell me if something is wrong with my reasoning?

Regards,
Matthieu

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 23 Nov 2010 11:01:54 +0100

Matthieu,
 
Very good points!
 
<Quote>
On the other hand a gateway acting as a transparent/interception proxy will use some IP magic to answer on the behalf of the origin server. In that case the gateway only uses the authority part of the URI (or the destination address). But transparent proxying requires some advanced IP stack features that are not always available:
1. Redirect sessions destined to the outer network to a local process using a packet filter rule.
2. Make it possible for a process to listen to connections on a foreign address.
3. Make it possible for a process to initiate a connection with a foreign address as a source.

</Quote>
 
This is one component I would actually expect to see in CoRE environment, exactly because I do not want the Clients to be bothered by the network topology. 
But what would we then call this beast?
 
A "caching gateway" - or just a "gateway" and then indicate in an option that it performs caching? 
 
And something related but slightly different:
How do I represent my advanced powerstrip device: Global on/off + on/off per outlet   ?
Depending on imlementation, such multichannel devices may have one master IPv6 address + one IPv6 address per outlet - or
it may have only address and you access it via
coap://bigbrother1.example.org/output/ <- master on/off 
coap://bigbrother1.example.org/1/output
coap://bigbrother1.example.org/2/output

in the latter case, this is already supported by coap - but if you have individual IPv6 addresses, as in the first example,
then I suppose that your device is a server (the master on/off function) AND a gateway for the other IPv6 addresses?
 
coap://bigbrother1.example.org/output/ <- master on/off 
coap://bigbrother1-1.example.org/output
coap://bigbrother1-2.example.org/output

One could argue that this is just a multihomed server - but in order to present these functions as one physical instance
in a management tool, my discovery process needs to understand that there is a tight connection. 
While the URIs above might suggest that there is such a connection, it is not explicit.
 
Is this a gateway at all - or do we need a third type: "MultiChannel server", where the master address advertizes the other ones?
 
Thanks,
  Anders

Fra: [email-masked] på vegne af [email-masked]
Sendt: ti 23-11-2010 01:57
Til: Peter Bigot
Cc: [email-masked]; core; Klaus Hartke
Emne: Re: [core] Proxy and server on the same port

> Almost; the origin server may be unaware of the presence of a gateway.  The network may impose the gateway.

I'm sorry but I can't catch the exact meaning of "any other role that might be hidden behind the authority part
of a URI". 
A gateway acting as a reverse proxy could for example implement a cache for sleeping nodes. The reverse proxy can map the sleeping nodes into its own namespace. In that case it's not just the authority part of the URI but the full URI that is used to decide what should be done.
coap://bigbrother1.example.org/sensor1/ is actually redirected to coap://sensor1.example.org/
coap://bigbrother1.example.org/sensor2/ is actually redirected to coap://sensor2.example.org/

Or maybe you want to separate the different functions of the gateway into different domain names that resolve to the same IP?

On the other hand a gateway acting as a transparent/interception proxy will use some IP magic to answer on the behalf of the origin server. In that case the gateway only uses the authority part of the URI (or the destination address). But transparent proxying requires some advanced IP stack features that are not always available:
1. Redirect sessions destined to the outer network to a local process using a packet filter rule.
2. Make it possible for a process to listen to connections on a foreign address.
3. Make it possible for a process to initiate a connection with a foreign address as a source.

Regards,
Matthieu

---

From: Peter Bigot <[email-masked]>
Date: Tue, 23 Nov 2010 06:46:55 -0600

>From my perspective: why do you need to know?

The client should transmit a request for data from a URI to some other node
(either a proxy, or an end-point extracted from the URI authority).  If it
has "freshness" needs, it should incorporate a Max-Age option.  Whether the
response comes from the origin server or a cache somewhere between the
client and the origin server should not be detectable by the client.

An alternative model is to allow applications to be made aware of something
that caches resource values and provides access to them through a different
URI; e.g. if the client thinks that coap://bigben/temperature is too far
away, it might GET coap://chicagocacher/bigben/temperature.  Then the issue
is how does it find out that chicagocacher exists and supports this sort of
operation.  That's a service discovery and resource discovery issue.

Peter

On Tue, Nov 23, 2010 at 2:31 AM, Anders Brandt <[email-masked]> wrote:

>  > So you do agree with what was in that email?  I assumed the complete
> lack of response meant nobody thought it relevant.
> I am currently investigating CoAP multi-subnet environments with sleeping
> nodes and I am very much in favor of a precise terminology.
>
> Unfortunately I am still not 100% up to speed on CoRE. What is the
> preferred way of indicating that a node (typically the default gateway)
> provides caching on behalf of other servers in the same subnet? and in
> another subnet?
>
> Thanks,
>   Anders
>
> ------------------------------
> *Fra:* [email-masked] på vegne af Peter Bigot
> *Sendt:* ma 22-11-2010 10:53
> *Til:* Klaus Hartke
> *Cc:* core
> *Emne:* Re: [core] Proxy and server on the same port
>
> So you do agree with what was in that email?  I assumed the complete lack
> of response meant nobody thought it relevant.
>
>
> That is a good solution.  But in the details, I think it would be more
> clear if the client does say what it thinks (that it's talking with a
> proxy), rather than creating complex rules on how to interpret Uri-Scheme to
> infer that it thinks it's talking with a proxy.  So use a new option named

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 23 Nov 2010 14:16:16 +0100

Hi Peter
 
> From my perspective: why do you need to know?

One one hand I agree with you. When rootcausing an issue in my network I may like to know...
I imagine my gateway just returns "/caching=TRUE" (Zach may come up with a one-letter code for this standard path)
The example of going to coap://chicagocacher in a sort of redirect was not what I was looking for. My main intention is (as stated in the CoAP spec): 1) to save network bandwidth, 2) discover sleeping nodes
 
>...  Then the issue is how does it find out that chicagocacher exists and supports this sort of operation. 
> That's a service discovery and resource discovery issue.
 
Agree 100% 
My main reason for responding is exactly discovery.
For achieving a plug-and-play experience across subnets I have a need for identifying gateways and asking them what interfaces they have on their other side. Then I can go ask these interfaces to report local CoAP hosts, and so on. Every time, these hosts may be cached or discovered on demand via multicast if relevant.
This can be done in a hierarchical, de-centralised fashion where no gateways have to store any information
that is already stored in other gateways.
Only the client running the discovery will get the full picture of all nodes in all subnets.

Do you follow me?

Thanks,
  Anders

Fra: Peter Bigot [mailto:[email-masked]]
Sendt: ti 23-11-2010 05:46
Til: Anders Brandt
Cc: Klaus Hartke; core
Emne: Re: [core] Proxy and server on the same port

>From my perspective: why do you need to know?

The client should transmit a request for data from a URI to some other node (either a proxy, or an end-point extracted from the URI authority).  If it has "freshness" needs, it should incorporate a Max-Age option.  Whether the response comes from the origin server or a cache somewhere between the client and the origin server should not be detectable by the client.

An alternative model is to allow applications to be made aware of something that caches resource values and provides access to them through a different URI; e.g. if the client thinks that coap://bigben/temperature is too far away, it might GET coap://chicagocacher/bigben/temperature.  Then the issue is how does it find out that chicagocacher exists and supports this sort of operation.  That's a service discovery and resource discovery issue.

Peter

	

	Thanks,
	  Anders

		

	OK. 

	Yes. 

	Yes.

	Not at first glance,

		There are two things:

	Good.

	

		Klaus

---

From: Peter Bigot <[email-masked]>
Date: Tue, 23 Nov 2010 07:51:43 -0600

To help people tracking this in the email archive three years from now:
Please see response in the "Proxy versus Gateway" thread.

Peter

On Tue, Nov 23, 2010 at 2:57 AM, <
[email-masked]> wrote:

> use some IP magic to answer on the behalf of the origin server. In that case
> the gateway only uses the authority part of the URI (or the destination
> address). But transparent proxying requires some advanced IP stack features
> that are not always available: