Subject: RE: Bypassing

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 3 Oct 2003 13:10:23 -0400

Tracing can be used to detremine if non-blocking was performed or not.

abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Friday, October 03, 2003 1:06 PM
> To: OPES WG (E-mail)
> Subject: RE: Bypassing
> 
> 
> 
> On Fri, 3 Oct 2003, Abbie Barbir wrote:
> 
> > IAB used non-blocking as a means to find corrupted imtermediaries.
> 
> I disagree. In general, one cannot find corrupted 
> intermediaries by any programmatic means. One can bypass 
> corrupted imtermediaries, once they are found, using 
> programmatic means such as bypass. IAB was concerned that if 
> OPES intermediaries become ubiquitous, then corruption of a 
> small number of unimportant services will lead to essential 
> information being unavailable to Internet users (humans and machines).
> 
> This is similar to the current wildcard DNS mess: Verisign 
> does OPES-like transformations on DNS messages, but DNS does 
> not have a bypass feature so many users (humans and machines) 
> get "blocked".
> 
> > > Even today, content is being composed from dozens of sources and 
> > > pieces. An all-or-nothing approach would more and more often mean 
> > > "nothing". Not just will you strip the ad or weather 
> info. You will 
> > > not get the news page at all. The URI-based approach lets you get 
> > > the page you want, with some missing information.
> >
> >
> > So, what is the point. if non-blocking means nothing, then 
> that is the 
> > non-opes version.
> 
> The point is that with a more flexible bypass interface you 
> can bypass _corrupted_ intermediaries (and get the content 
> rather than nothing). With a wildcard interface you can only 
> bypass all intermediaries which will most likely leave you 
> without any content or without bypass.
> 
> BTW, this brings up an important question: What should an 
> OPES system return if there is no non-OPES content and bypass 
> was requested. IMO, it should return an error of some sorts 
> rather than OPES content. Otherwise, it would be impossible 
> to determine whether bypass was processed or ignored. 
> Returning OPES content instead of an error would also make 
> bypass a lot less effective: imagine a situation where a 
> corrupted (but unimportant) portion of a web page (e.g., some ad
> applet) crashes your browser...
> 
> > Design issue here. A system that requires you to go through 
> 100 hops 
> > before determing that you have taken the wrong pass is not optimal.
> 
> It is not up to us to decide what is optimal in an OPES 
> system. I can easily come up with a realistic case where 
> checking for bypass at the first hop is actually much worse 
> than checking at the 100th hop, especially if bypass 
> instruction is an exception rather than a rule.
> 
> > So simply, keep the non-blocking header in the flow until 
> it reaches 
> > the first processor that is capapble of handeling it.
> 
> Even simpler and more general:
> 
>     bypass instruction semantics is end-to-end and not hop-by-hop
> 
> (not all application protocols have headers AND just because 
> a processor is capapble of handeling an instruction, does not 
> mean it is authorized to remove it).
> 
> > > Agreed. That minimum, for me, is a URI-based interface with a 
> > > wildcard option and appropriate defaults.
> >
> > So what do u mean by a URI-based approach?
> 
> Something along these lines, if you wish:
> 
>     A bypass instruction contains a URI that identifies an OPES
>     entities or a group of OPES entities to be bypassed. An
>     instruction may contain more than one such URI. A special
>     wildcard identifier can be used to represent all possible
>     URIs (i.e., all possible OPES entities).
> 
>     The recipient of a bypass instruction containing a URI
>     that identifies a known-to-recipient OPES entity MUST ...
> 
>     The recipient of a bypass instruction containing a URI
>     that identifies the recipient itself MUST ...
> 
>     The recipient of a bypass instruction with a URI that does
>     not identify any known-to-recipient OPES entity MUST ...
>     (treat that URI as a wildcard identifier?).
> 
>     Bypass instruction semantics is end-to-end and not
>     hop-by-hop. The recipient MUST forward bypass instructions to
>     the next application hop provided that next hop speaks
>     application protocol with OPES bypass support. This
>     requirement applies to all bypass instructions, including
>     those that identify known-to-recipient entities.
> 
>     Application-specific bindings MUST map the above bypass
>     mechanism to their application protocol. An explicit
>     declaration of no bypass support is an acceptable mapping.
> 
> 
> HTH,
> 
> Alex.
>

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 3 Oct 2003 11:18:32 -0600 (MDT)

> Tracing can be used to detremine if non-blocking was performed or not.

Not exactly (depending on what you mean by "perform"). Tracing can be
used to determine whether OPES is still in the loop. The trace does
not tell you whether bypass was considered but no non-OPES version of
the content was available (and so you should stop trying) or whether
bypass instruction was ignored (and so you might be lucky if you try
again, perhaps using a different path through OPES).

This is an important distinction to document. I do not know whether
it is important enough for us to require that the trace includes
"I tried but could not bypass" info.

Alex.