On Thursday, July 26, 2001 @7:41 PM Reinaldo Penno wrote:
Hi Gary/Markus,
First of all this is good stuff, really a major rewrite. Here it goes my
comments on the new draft:
General:
First IMO the draft it too biased on "Content Networks". OPES can provide
"Content Services" to any network that provide content to the user.
If I am requesting content to a server directly, without any CDI
infrastructure in place, I can still benefit from OPES Services. Tying
OPES to Content Networks imply a coordination of devices following the CDI
model, in place, which may not be true and also makes the OPES more
restrictive. OPES exists independently of CDI.
Agreed. The intent is not to limit it to a CDI or even a CDN model. There
are many forms of "Content Networks", ranging from the simplest single
surrogate
or delegate to complex sets of them, including CDNs. I started out
documenting
them as we had done in CDI, but decided that it was a lot of information
that
isn't the essence of OPES work; thus I decided to reference the CDI document
that has already done a good job in presenting content networks. I for one
would like to see the WREC taxonomy updated to include the newer content
networking material. This would allow all of us to reference it in a
consistent manner.
Also, the term "content services" is a little bit vague. I believe that
different interpretations can be given to this term. I mean, is virus
scanning of email a content service? I believe the answer is yes, but
then I do not think CDN will be distributing emails, which goes back to
my first point.
I think this is an example of a content service. It should be possible
to put OPES on an email gateway, after all they are intermediaries.
The use of the term "overlay network" is also confusing. When I read
overlay networks I think of tunneling, MPLS VPNs, VR, etc. In other words
a overlay network is a virtual network that has a different IP addressing
scheme or purpose then the network used for transport. I hope I am not
getting too philosophical here.
The term overlay network doesn't have to be restricted to IP based overlays.
It is commonly used in other application domains, including CDN and in
several research papers on application overlays. We've tried to define it
in a manner that supports all of these types of overlay applications. Edge
Service Network was defined to be the type of overlay network OPES utilizes.
Content Path should be subdivided on in-path and out-of-path. When OPES
devices are in-path of the normal data flow, content path and data path are
the same. Otherwise they are out of path. OPES, differently from MIDCOM,
deals also with OOP devices, that's why the need of protocols like ICAP,
SOAP, etc
Is subdividing it really necessary for understanding? I'm curious to get
dialogue going on the whole content path concept. Is the remote call-out
server a part of the content path or not? The content path is a logical
abstraction that doesn't have to be bound to the underlying packet network
flow. Thinking about it some more, I can see arguing that remote call-outs
are
placed into the contet path by the OPES intermediary when their actions run.
As for MIDCOM, I think the key difference isn't out of path, but rather
operating on content itself.
Specifics.
Introduction, second paragraph:
In addition to talking about PDA, software upgrades, etc I think a good
straight to the point argument why we need OPES services is analogous to
why we need MIDCOM. In other words, this is a problem of intelligence,
where intelligence in the network will reside. In theory we could put all
kinds of funcionalities in routers or end clients, but this doesn't scale,
is not possible from a unique vendor perspective or some other reason.
Agreed. This paragraph needs some word smiting in order to convey the
broader applicability.
Section 4.1.1
Another scenario is where the OPES intermediary is owned by an access
provider, which resell its services to ISPs or enterprises. Very common
these days 'OPES Internmediary' is owned by an access provider: In this
case the access provider sell content services such as virus scanning and
URL filtering to the ISPs and enterprises that are connected to its
network.
Isn't this the same The Middleware Service Provider case?
Section 4.1.2
small typo: cahce
should be: cache
Got it.
Section 4.1.2.2
Saying that "Local operations typically run in the 'fast path' of the
'OPES engine', since they generally can be performed at 'wire speed'" is
not
correct. This depends on the application, operation performed on the
content,
device, etc, etc
Agreed.
'Fast path' definition and use in the text should be totally seprated from
the
fact if the operation is local or not. As you put more applications in-path
the
less likely you are going to be doing them fast and efficiently.
Agreed. Although there in a underlying assumption among many contributors
so
far that a number of services need the ability to run at or near wire speed
on an OPES intermediary. Some more word smiting is need to tease this out,
while at the same time not casting it upon local versus remote. I can see
some specialized remote device that has the potential with a hot call-out
protocol of being in the fast path.
Section 4.1.2.3, first paragraph
Again saying that "Remote operations run in 'slow path'..." is not correct.
I
might put a virus scanning engine local to the OPES intermediary and the
loose
peformance when compared if I offload it to a remote call-out server . This
slow and fast path is too dependent on several variables.
Agreed, but its hard to imagine the norm for remote call-outs really being
capable of being in the fast path. I think the example above illustrates
both
slow path local and slow path remote.
Section 4.1.2.3, second paragraph
"End-to-End encryption also precludes the use of any value-added services
through a 'remote call-out server'".
This has to be further expanded.
In end-to-end encryption, the 'edge services' network does not disapear,
it's
just moved near the IPsec termination device, and in this case user might
also
get value added services. I can use a IpSec client, connect to my company
in
the other side of the world and still get remote call out services such as
language translation and URL filtering.
This would be the "'OPES Intermediary' is owned by enterprise model" that
you
mentioned.
Of course if the OPES intermediary is between the IPsec end points then I
agree.
Agreed. This was an oversight. Surrogates terminating SSL/TLS and IPSec
termination by OPES Intermediaries clearly void this restriction.
Section 4.2
"..are usually employed in a OPES framework to either offload the OPES
Intermediary
for better scalability.."
This is good example of why the fast path vs slow path should be avoided in
regards of where the operation is peformed. If they scale better as you
said
then although they are out of the content path, they are in the 'fast path'
mode of operation.
Section 5.4, third paragraph
"If the coomunication channel between the OPES Intermediary and the remote
call-out server is snooped, the attacker may gain access to sensitive
information."
Information that will eventually be sent to the end user. So in this case
we
should also encrypt the traffic between the end user and the OPES
Intermediary,
which breaks the OPES model or require the OPES intermediary be a encrytion
device.
If information is really sensitive, it would be encrypted end-to-end and
the
only remote call out server which could insert/modify anything would reside
on
the companies network. IMO This goes back to the discussion on section
4.1.2.3
I agree in principle here. This is in the context of threat analysis, but
it
doesn't capture the dependency upon the communications channel being used
between the OPES intermediary and the client. How about we qualify it with
this dependency, that is to say something to the effect of, not compromised
beyond what is possible on the underlying content network flow?
hope this helps,
Reinaldo Penno
NortelNetworks
Thanks for all the comments.
Gary