ietf-openproxy
[Top] [All Lists]

Re: CDT Comments on OPES

2001-08-15 11:37:44

John,

a few comments inline.

First, on the big picture question of whether OPES diminishes the
end-to-end principle, it is strained to suggest that OPES
transformations happens at an endpoint simply because one endpoint
has (in theory) authorized the transformation.  Almost by definition,
OPES will not be implemented at any actual endpoint, and in fact may
well be implemented by a regional ISP separated by a number of other
ISPs from actual end users.  OPES will move decision-making
intelligence away from actual endpoints and somewhat into the middle
of the network (albeit, certainly, fairly close to an endpoint).
This movement, as I understand it, is a movement away from the
end-to-end principle.

First, it is helpful to consider the different protocol layers when
talking about the end-to-end principle (thus, avoiding some
misunderstandings we had in the past).

From a network (or IP) layer point of view, OPES does absolutely NOT
diminish the end-to-end principle, as OPES devices are explicitly
addressed at IP level and terminate a transport connection (or act as
a final destination for UDP packets) in a normal way.

Possible (content) modifications are done completely at the
application level, somewhere between the content provider and the
content consumer. Clearly, doing this in a transparent way is
dangerous. Unfortunately, this is the way it is typically implemented
today, mostly using proprietary mechanisms that take any control away
from both, content provider and content consumer. OPES goal is to give
control over such modifications back to the two application endpoints
(i.e. content provider and content consumer) by defining a policy
framework and protocols that fit into this framework. While,
physically, there can be OPES boxes on the content path between
content provider and content consumer (e.g. for performance
improvements), logically the control of the content remains with the
application endpoints - which is an important goal of the end-to-end
principle.  

More important than whether a particular theoretical principle is
diminished, however, is the fact that OPES will continue a trend
toward giving larger, wealthier, corporate speakers significant
advantages in their ability to deliver content or services.
Michael's comments correctly assert that OPES is similar in concept
to content delivery networks such as Akamai, etc.  That, however, is
precisely one of the concerns about OPES.  Just as content delivery
networks raise serious questions about the historic relative parity
between large and small speakers (see http://
www.cfp2000.org/papers/morrisberman.pdf for a discussion of CDNs and
speech on the Internet), OPES will facilitate delivery of services by
those able to contract with CDNs or big ISPs around the country, to
the detriment of smaller or upstart service providers trying to
compete.

This is always a problem with advancements in technology. At the
bginning, new technologies are typically relative expensive and only
wealthy "speakers" can afford them. This is especially true if new
technologies are deployed in a proprietary way (as many CDNs are
today). Creation of open standards allows smaller players to enter the
market, thus opening competition and making new technology more
affordable to less "wealthy speakers".

So, in my view, the solution to this problem is NOT to reject
advancements in technology and ignore their benefits, but rather try
to allow competition by creating open standards that allow smaller
players to get into this area.

Taken together, these and other comments suggest that OPES will
involve a REAL TIME handshaking or negotiation process in which BOTH
the content provider AND the end user affirmately consent to the OPES
transformation.  I have not previously understood the OPES documents
to suggest such a real time negotiation.

Such a real time negotiation would answer many concerns raised by my
original comments.  Critically, both the content provider and the end
user would get notice of the proposed OPES transformation, and would
have the ability to opt out of such transformation.

This issue has been discussed on the IETF list in June this year. It
seemed that there are  services that do NOT require consensus from
BOTH parties, but only from EITHER of them.

For example, what about services that are executed only on behalf of
the content consumer? Virus scanning might be one example. Would you
expect that a content provider has to give permission for virus
scanning? This is certainly not the case today. Other examples might
be services that are authorized and performed on the REQUEST issued by
the content consumer (as opposed to the CONTENT itself). An example
might be a service that optionally removes (or replaces) the "referer"
header in a request to ensure the client's privacy. Would you expect
that such a service is authorized by content provider(s) and, if so,
by which content providers?

Of course, it seems that there are also services that have to be
authorized by both parties (possibly content adapation, for example).
But it's not clear to me whether this would require real-time
handshaking. For example, a content provider could a-priori authorize
specific adaptation for certain target bandwidths, so can the content
consumer. If there's a match, the adapation will be performed.

Certainly an issue that has to be considered.

[...] To the contrary, it is not clear in the
documents that an end user will even be notified that an OPES
transformation took place.  By the same token, it is not clear that a
content provider will be notified prior to a end user-requested
transformation.  Moreover, nothing in the OPES documents suggests
that the NON-requesting party will have the ability to give a "no
transformation" instruction.  If I am wrong about these, then some of
my concerns may well be misplaced.

It might be a good idea to include sort of a tracking/tracing feature
that would allow an application endpoint to identify the services that
have been performed on received content. This might also be very
helpful in debugging and failure tracing. Something that should be
discussed.

Whether or not OPES proceeds within the IETF framework, I am hopeful
that the specific concerns about its implementation can be considered
carefully during the design process.  I welcome the opportunity to
continue a conversation about these issues.

Constructive feedback, especially on privacy issues, is certainly
welcome. We also need to make sure that there are no more
misunderstandings left about OPES goals and intentions. Hope the email
exchange helped in clarifying issues.

Thanks,
  Markus

<Prev in Thread] Current Thread [Next in Thread>