ietf
[Top] [All Lists]

Re: WG Review: Open Pluggable Edge Services (opes)

2001-06-19 15:30:03
Lee,
        The debate does have a blend of technology, religion, business
interest, and historical allusion.  At its core, though, is a serious
question: does the desire for a mechanism for calling services that
operate on application level messages at an intermediary outweigh the
desire to maintain an application infrastructure that mirrors the
end-to-end datagram model of the underlying routing system and, if so,
does the fulfillment of that desire require an interoperable standard?
(I said it was a serious question, but I didn't promise it was one
that you could get out in one breath).
        As someone who worked for a long time in content negotiation
(as chair of CONNEG in the IETF and, for a short time, as a
contributor to the CC/PP effort in the W3C), I am well aware of the
existing intermediaries in the system.  The application infrastructure
is already using systems which do not mirror the end-to-end routing
system (and the end-to-end routing system has multiple address realms
now as well, but that is a different kettle of fish).  As you note,
the question about these intermediaries is not whether they exist,
but it also not whether or not there are standards.  The question
is how they interact with the applications which pass traffic through
them.
        OPES makes no claims in this regard and that, I suspect, is a
large part of the problem the readers of this list have with its
charter.  OPES proposes to standardize an enabling protocol with no
definition of what it might enable.  From a practical standpoint, the
arbitrary nature of the services which OPES might enable creates the
need for an enabling protocol of extraordinary flexibility, where the
IETF has historically done better biting off rather small problems.
Hilarie Orman noted earlier in this thread that OPES "is motivated by
notions of dynamic content and the notion of distributed semantic
evaluation.  It is a logical general of caching....The OPES
architecture and protocols go a long way towards building an
application friendly Internet by developing standards for a coherent
substrate for scalable application deployment.  This allows caches and
gateways to provide the services needed for rich content."  I think "a
coherent substrate for scalable application deployment" is a pretty
big chunk, and not one that many IETF working groups would likely get
through.
        From an architectural standpoint, it is absolutely impossible
to tell what applications might be broken, transformed, or improved
once OPES's enabling protocol is in place.  Frankly, that's pretty
scary, as having an interoperable enabling protocol may not do us much
good if it enables things that break the applications themselves.  The
charter acknowledges some of these fears; it specifically rules out
the possibility of a "transparent" service (for which read
"interception proxy"): "Intermediary services provided in this way are
not transparent: Either the content requestor or provider will be
aware that a tranformation has been performed."  This doesn't handle
the problem, though, it merely improves debugging.  To handle the
problem, the working group would have to define either an architecture
which ensured that the applications worked correctly whether the
intermediary services were called or not (not likely to cover
"arbitrary" services, and very dependent on specific applications) or
one in which the availability of services is not dependent on the
network path taken by the application layer message.  Both of those
seem outside the task the working group has set itself.
                                regards,
                                        Ted Hardie






 This debate over OPES appear sto have a blend of technology
religion, business interest, and even some hand-waving or other
failures to communicate at its core.  I, too, can quibble with the
proposed charter but there is a need for a standard mechanism for
calling services that operate on http (and possibly rtp) messages at
an [application-level] intermediary.  In general, the technical and
industry requirements can be demonstrated by the fact that there are
emerging w3c standards and implementations for constructing
distributed applications by calling web services and, specifically
with respect to edge services, by the fact that there are
edge-of-network implementations that provide various transform
services, e.g., virus scan, language translation, and, yes, content
adaptation based on device and network capabilities.  These aren't
layer violations, some of these applications are, however, aware of
the protocol layers much the way a management application can be
layer-aware.  These intermediaries exist and they will continue to
do so.  The only question is are there standards.  The requirement
for doing this at an application intermediary in a standard way is
the usual requirement for standards: the industry serves its
customers best when products interoperate.  Standards for selecting
the services to be called (rules) and how to call them (service
bindings and protocols) will provide interoperability in
constructing those distributed applications.  One of the areas for
investigation in the working group (assuming it gets chartered) is
whether we need something unique to edge services (a la icap) or
whether something more general is appropriate (a la soap).  I,
personally, don't think the applications need to justify themselves
against a model; rather, models may provide insights in the presence
of reality.  The problem is fundamentally one of scaling.  How do we
distribute the work load, provide an improved user experience and do
so with an authenticated and authorized set of rules?  If OPES can
help answer those questions, I'm not sure what the problem is.
There may well be "better" ways of building these distributed
applications, but the market has chosen these application
intermediaries as an evolutionary step.  It would be a mistake for
the IETF to abdicate its responsibility here.  Lee M. Rafalow Voice:
1-919-254-4455, Fax: 1-919-254-6243 IBM Internet Technology
Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709
USA Alternate email: rafalow(_at_)us(_dot_)ibm(_dot_)com Personal email:
lrafalow(_at_)mindspring(_dot_)com



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