Subject: Re: [core] Proxy versus Gateway

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

I hope nobody minds, but I've transplanted this back to the original thread,
with my original argument below.  Though my corrections to Klaus's summary
of what I said may be accurate, I'd prefer to not depend on that.  Please
refresh your memories of what I wrote last month, as I have done.  (In
particular, I don't want to lose my subtle other suggestion which is that
"cache" needs to be refined, not just use of "proxy" and "gateway".
Personally I'd like to see the entire semantic description of CoAP caching
pulled out to another document, as I believe is being done in HTTPbis,
leaving base CoAP to describe the generic encoding and method-independent
transaction details.)

Matthieu:  All your cases are gateways.  A gateway can operate at any level
in the OSI stack.  Those that operate at the application (CoAP) level may
end up doing a translation that involves initiating a new CoAP request,
potentially to a completely different URI, even one with a non-CoAP scheme.
Such a node is a gateway because the authority part of the URI led the data
flow to it.  In my mind, there's no implication that a gateway is restricted
from inspecting or manipulating other parts of the URI in order to fulfill
its responsibilities (Fielding's list of gateway purposes should not be read
as exhaustive).  Do you feel that a further refinement to characterize types
of gateway would improve an understanding of CoAP?

Anders: As I suggested in my specific response to caching, neither the
client nor the server should be aware that there are gateways between them,
at least not at the REST level.  Any such knowledge introduces coupling, and
limits the ability of organizations to restructure their networks while
providing the same resources via the same URIs.

Peter

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

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

On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot <[email-masked]> wrote:

> I and others have been somewhat confused by the CoAP terms "proxy" and
> "cache", which unless clarified actually mix several concepts.  I found
> enlightenment in section 5.2.3 of Fielding's dissertation<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_3>
> :
>
> Intermediary components act as both a client and a server in order to
> forward, with possible translation, requests and responses. A proxy
> component is an intermediary selected by a client to provide interface
> encapsulation of other services, data translation, performance enhancement,
> or security protection. A gateway (a.k.a., reverse proxy) component is an
> intermediary imposed by the network or origin server to provide an interface
> encapsulation of other services, for data translation, performance
> enhancement, or security enforcement. Note that the difference between a
> proxy and a gateway is that a client determines when it will use a proxy.
>
> I had been misled because the non-technical use of the term "proxy" is
> appropriate for several key roles in a CoAP system, including that entity
> which serves as the intermediary for sleeping nodes.  The correct term for
> this function is "gateway", as most clients need not be aware that they are
> acting through an intermediary.
>
> CoAP's use of the term "proxy" is inconsistent with these definitions:
>
> 5.3.  Proxying   A proxy is defined as a CoAP end-point which services cached requests
>    on behalf of other CoAP end-points.  Any node in a CoAP network may
>    act as a proxy, although in general the node between the constrained
>    network and the Internet at large SHOULD always support proxy
>    functionality.
>
> This is misleading because it focuses solely on caching, leaving aside the
> other reasons why a proxy might be necessary.   As an example, many
> constrained nodes  will not support DNS, and therefore cannot translate an
> ASCII authority found within a URI to a network address.   Similarly,
> constrained devices are unlikely to have the computational resources
> necessary to support public key cryptography.   It would be better to say
> that a proxy is an intermediary explicitly selected by the client as its
> agent when dealing with any transaction it is unable to perform directly.
>
> This is an important but currently implicit role in a CoAP system.  As with
> the traditional use of proxy in web browsers (back before desktops became
> full participants in the Internet), a CoAP client should need only one proxy
> to which it can delegate all CoAP transactions it can't do itself.
> Configuration of this proxy for a particular node is an administrative
> function outside the scope of CoAP as an on-wire protocol.  (If multiple
> proxies were expected at a client, there would have to be some way of
> selecting which proxy to use for which operation, an unnecessary
> complication that could easily be supported by delegation.)  CoAP need
> merely provide a mechanism by which the full information required to
> delegate the transaction can be conveyed, which it does.
>
> I encourage use of the term "gateway" when referring to an entity that
> supports sleeping nodes, coordinates group activities, or performs 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.
>
> If it's not too late to make so major a change in terminology and concept,
> I would encourage a rewrite of section 5 to make clear that proxies,
> gateways, and caches are independent functions.  I would contribute text for
> this if the editors would find that helpful.
>
> Peter
>

---

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

>Anders: As I suggested in my specific response to caching, neither the client nor the server
>should be aware that there are gateways between them, at least not at the REST level. 
>Any such knowledge introduces coupling, and limits the ability of organizations to restructure
>their networks while providing the same resources via the same URIs.

Agreed!

________________________________

Fra: Peter Bigot [mailto:[email-masked]]
Sendt: ti 23-11-2010 06:13
Til: core; [email-masked]; Klaus Hartke; Anders Brandt
Emne: Re: Proxy versus Gateway

I hope nobody minds, but I've transplanted this back to the original thread, with my original argument below.  Though my corrections to Klaus's summary of what I said may be accurate, I'd prefer to not depend on that.  Please refresh your memories of what I wrote last month, as I have done.  (In particular, I don't want to lose my subtle other suggestion which is that "cache" needs to be refined, not just use of "proxy" and "gateway".  Personally I'd like to see the entire semantic description of CoAP caching pulled out to another document, as I believe is being done in HTTPbis, leaving base CoAP to describe the generic encoding and method-independent transaction details.)

Matthieu:  All your cases are gateways.  A gateway can operate at any level in the OSI stack.  Those that operate at the application (CoAP) level may end up doing a translation that involves initiating a new CoAP request, potentially to a completely different URI, even one with a non-CoAP scheme.  Such a node is a gateway because the authority part of the URI led the data flow to it.  In my mind, there's no implication that a gateway is restricted from inspecting or manipulating other parts of the URI in order to fulfill its responsibilities (Fielding's list of gateway purposes should not be read as exhaustive).  Do you feel that a further refinement to characterize types of gateway would improve an understanding of CoAP?

Anders: As I suggested in my specific response to caching, neither the client nor the server should be aware that there are gateways between them, at least not at the REST level.  Any such knowledge introduces coupling, and limits the ability of organizations to restructure their networks while providing the same resources via the same URIs.

Peter

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

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

	> 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

	I and others have been somewhat confused by the CoAP terms "proxy" and "cache", which unless clarified actually mix several concepts.  I found enlightenment in section 5.2.3 of Fielding's dissertation <http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_3> :

	Intermediary components act as both a client and a server in order to forward, with possible translation, requests and responses. A proxy component is an intermediary selected by a client to provide interface encapsulation of other services, data translation, performance enhancement, or security protection. A gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an interface encapsulation of other services, for data translation, performance enhancement, or security enforcement. Note that the difference between a proxy and a gateway is that a client determines when it will use a proxy.

	I had been misled because the non-technical use of the term "proxy" is appropriate for several key roles in a CoAP system, including that entity which serves as the intermediary for sleeping nodes.  The correct term for this function is "gateway", as most clients need not be aware that they are acting through an intermediary.

	5.3.  Proxying

	   A proxy is defined as a CoAP end-point which services cached requests
	   on behalf of other CoAP end-points.  Any node in a CoAP network may
	   act as a proxy, although in general the node between the constrained
	   network and the Internet at large SHOULD always support proxy
	   functionality.
	This is misleading because it focuses solely on caching, leaving aside the other reasons why a proxy might be necessary.   As an example, many constrained nodes  will not support DNS, and therefore cannot translate an ASCII authority found within a URI to a network address.   Similarly, constrained devices are unlikely to have the computational resources necessary to support public key cryptography.   It would be better to say that a proxy is an intermediary explicitly selected by the client as its agent when dealing with any transaction it is unable to perform directly.
	
	This is an important but currently implicit role in a CoAP system.  As with the traditional use of proxy in web browsers (back before desktops became full participants in the Internet), a CoAP client should need only one proxy to which it can delegate all CoAP transactions it can't do itself.  Configuration of this proxy for a particular node is an administrative function outside the scope of CoAP as an on-wire protocol.  (If multiple proxies were expected at a client, there would have to be some way of selecting which proxy to use for which operation, an unnecessary complication that could easily be supported by delegation.)  CoAP need merely provide a mechanism by which the full information required to delegate the transaction can be conveyed, which it does.
	
	I encourage use of the term "gateway" when referring to an entity that supports sleeping nodes, coordinates group activities, or performs 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.
	
	If it's not too late to make so major a change in terminology and concept, I would encourage a rewrite of section 5 to make clear that proxies,  gateways, and caches are independent functions.  I would contribute text for this if the editors would find that helpful.
	
	Peter

---

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

Hi Peter
 
<Quote>
...A gateway can operate at any level in the OSI stack.  Those that operate at the application (CoAP) level may end up doing a translation that involves initiating a new CoAP request, potentially to a completely different URI, even one with a non-CoAP scheme.  Such a node is a gateway ...
</Qoute>
 
You are getting to some important detail here. And I agree with you that terminology is extremely important.
 
What I think (speaking for myself at least) is causing us to avoid the "gateway" term is exactly the inherent
understanding that it translates my application content.
What if my device is completely transparent to all application payload, but just does a bit of caching and buffering?
Everytime I say "gateway" to a customer I will have to explain that this particular gateway does not
do any translation - it just enables connectivity via standard frame formats.
 
New term wanted!
 
- Anders

Peter

	

	
	Regards,
	Matthieu

	

	5.3.  Proxying

	

	
	Peter

---

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

We need to correct that understanding, then.  Personally, I got thrown
somewhere in this email chain by an offhand reference to "the default
gateway", meaning where to send IP packets that have a destination address
not in the routing table.  ("What 'default gateway'?  CoAP doesn't define a
... oh, that kind of gateway.")

Notwithstanding, I think "gateway" is the right term.  You could use "CoAP
gateway" to distinguish it from "IP gateway", leaving "gateway" to be left
generic or determined by context.

There's going to be ambiguity; we can't help that.  Any other term is either
going to be unrecognized and have to be constantly explained, or already
means something else (like the original CoAP use of proxy encompassing only
a cache) resulting in latent misunderstanding.

Though if you have a specific term in mind, and its use can be traced to a
definition like I did with gateway and proxy, my position could change.

Peter

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

>  Hi Peter
>
> <Quote>
> ...A gateway can operate at any level in the OSI stack.  Those that operate
> at the application (CoAP) level may end up doing a translation that involves
> initiating a new CoAP request, potentially to a completely different URI,
> even one with a non-CoAP scheme.  Such a node is a gateway ...
> </Qoute>
>
> What if my device is completely transparent to all application payload, but
> just does a bit of caching and buffering?
> ------------------------------
> *Fra:* Peter Bigot [mailto:[email-masked]]
> *Sendt:* ti 23-11-2010 06:13
> *Til:* core; [email-masked]; Klaus Hartke;
> Anders Brandt
> *Emne:* Re: Proxy versus Gateway
>
>  I hope nobody minds, but I've transplanted this back to the original
> thread, with my original argument below.  Though my corrections to Klaus's
> summary of what I said may be accurate, I'd prefer to not depend on that.
> Please refresh your memories of what I wrote last month, as I have done.
> (In particular, I don't want to lose my subtle other suggestion which is
> that "cache" needs to be refined, not just use of "proxy" and "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.
>> 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
> On Sat, Oct 23, 2010 at 5:55 AM, Peter Bigot <[email-masked]>wrote:
>
>> This is an important but currently implicit role in a CoAP system.  As
>> with the traditional use of proxy in web browsers (back before desktops
>> became full participants in the Internet), a CoAP client should need only
>> one proxy to which it can delegate all CoAP transactions it can't do
>> itself.  Configuration of this proxy for a particular node is an
>> administrative function outside the scope of CoAP as an on-wire protocol.
>> (If multiple proxies were expected at a client, there would have to be some
>> way of selecting which proxy to use for which operation, an unnecessary

---

From: [email-masked]
Date: Tue, 23 Nov 2010 18:30:01 +0100

Peter

>Matthieu:  All your cases are gateways.  A gateway can operate at any
level in the OSI stack.  Those that operate at the application (CoAP) level
may end up doing a translation that involves >initiating a new CoAP
request, potentially to a completely different URI, even one with a
non-CoAP scheme.  Such a node is a gateway because the authority part of
the URI led the data flow to it.
>In my mind, there's no implication that a gateway is restricted from
inspecting or manipulating other parts of the URI in order to fulfill its
responsibilities (Fielding's list of gateway purposes should not >be read
as exhaustive).  Do you feel that a further refinement to characterize
types of gateway would improve an understanding of CoAP?

I fully agree that they are all gateways. I just wanted clarified that the
gateway could perform different roles with the same authority part. The
Authority part guide the data flow through the gateway but the exact action
to be taken depends on the full URI.
And I don't think we need further refinement. It may help to understant
what's behind the scene to implement the gateway but it would not necessary
improve an understanding of CoAP.

Matthieu