Sorry for confusing you with a bad diagram. C_OPES1.1, 1.2 etc. represent the
end-to-end flows (sessions). The dotted lines that link the server, opes1, opes2
and the client are multi-hop networks (treat them as representing connections at
the IP layer).
If OPES1 knows it is talking to OPES2, and *not* the ultimate client of the
session, then there is * no* problem.
Don't bother reading the rest of this message. I was not sure if this is indeed
the case.
If this weren't the case, then there is a problem.
--------------------------------------------------------------------------
Let me try to explain the diagram in words :
In the absence of application level intermediaries, there would be only one
end-to-end flow between the origin server and the client. However, with opes
boxes in the middle, this connection is broken into two individual connections -
one between the server and an opes box, and the other between the opes_box and
the client.
There is an end-to-end flow, C_OPES1.1 between a streaming media server and
OPES1. The server is within OPES1's authoritative domain. So the server knows
full well that it is talking to an OPES box and that the content is likely to be
transcoded based on rules specified by the server.
There is an end-to-end flow, C_OPES1.2 between OPES1 and the client process.
However, the client authorizes OPES2, an opes intermediary within its
authoritative domain, to intercept packets destined towards the client, and
perform transcoding operations based on the status of the end-to-end goodput
between opes2 and the client.
Now, assume that the network throughput between opes2 and the client drops. This
will be recorded by opes2 and opes1 (since the path between opes2 and the client
is part of the end-to-end path between opes1 and the client). In response both
opes1 and opes2 will adapt the content.
- Jayanth
Hilarie Orman wrote:
I don't fully understand the diagram, in part because opes1 seems to have
end-to-end connections to opes2 and the client at the same time, and
opes2 is also connected to the client. Is the stream being served to
the client over both connections simultaneously? Or is the goodput
measurement being conducted over a channel (1.2) which is not
related to the actual delivery channel (bad idea, certainly)?
Opes1 should be using only opes2 to determine rate. Opes2 might want
to take the stream full-bore and portion it out to the client at a different
rate.
Hilarie
Jayanth Mysore <Jayanth_Mysore-CJM110(_at_)email(_dot_)mot(_dot_)com>
08/13/01 12:32PM >>>
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
--
Jayanth P. Mysore
Networks and Infrastructure Research Laboratory,
Motorola Labs
Phone : (847) 576-8561