In response to Jayanth's mail below, let me take the following stance and
see what others have to say in this regard:
Terminology clarification: The term "end user", as used below, stands for
the destination of conetnt delivered from an origin server/content provider.
(1) OPES boxes are not "inserted" ad hoc in the "data path" - these boxes
are trusted intermediaries that are placed in the data path by someone
authorized to do so (i.e, someone on behalf of the content provider/origin
server or someone on behalf of the end useror someone on behalf of a service
provider acting on behalf of the either content provider or end user).
(2) OPES boxes act on messages that pass through them, based on their
inspection of the contents/header/metadata and hence, can decide to do the
appropriate transform as needed by their "client" - this client could be the
end user or the content provider or a service provider acting on either's
behalf.
Given the above, I see little need for to discover each other. This is not
to say that we need "registries" or "admin domains" that clearly register
and track all the OPES boxes; it is just to state that there seems to be no
necessity for an OPES box to be "dependent" on another box in any way to do
its function.
Comments?
- Rama
**********
-----Original Message-----
From: Jayanth Mysore
[mailto:Jayanth_Mysore-CJM110(_at_)email(_dot_)mot(_dot_)com]
Sent: Monday, August 13, 2001 11:33 AM
Cc: ietf-openproxy(_at_)imc(_dot_)org; Jayanth.Mysore
Subject: Edge to edge discovery
My understanding is that the OPES box is an application level intermediary,
that terminates connections from/to the origin server and the client.
Further there isn't anything that prevents multiple such boxes to be in the
path between the origin server and the client.
If my understanding is correct, I believe it will be important for OPES
boxes that are involved in a given session to discover each other and have
an understanding of what each is doing to the content. This will be
especially important in long running streaming media sessions where
"end-to-end" feedback is used by a source to dynamically readjust its
rate/the content's format etc. Consider the following scenario :
<- -C_OPES1.1--> <-------C_OPES1.2----->
(origin server)---(opes1)-------(opes2)-----------(client)
<-----------C_OPES2.1------> <--C_OPES2.2-->
opes1 : An OPES intermediary in the origin server's authoritative domain
opes2: An OPES intermediary in the client's authoritative domain
C_OPES1.1 : An "end-to-end" connection between the origin server and opes1
C_OPES1.2: An "end-to-end" connection between opes1 and the client
In this scenario,let's say opes1 measures the goodput of C_OPES1.2 and uses
this estimate to transcode the stream. Likewise, opes2 modifies the stream
based on the goodput estimate on C_OPES2.2. Each of the OPES boxes could
independently transcode the stream resulting in unstable operation in the
worst case and super-degradation of the content quality in the best case.
Am I getting something wrong here ?
- Jayanth
--
Jayanth P. Mysore
Networks and Infrastructure Research Laboratory,
Motorola Labs
Phone : (847) 576-8561