[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

john.loughney@nokia.com wrote:

What it seems is that we need to have 3 states for an address pair (I'm sure we could come up with better names, but just humor me):

 1) Fully - Working for all ULPs
 2) Partial - Working for one (some) ULPs
 3) Failed - not working for any ULPs

So, in a scenario, you start your browser and a shim context is created
for an interface that's behind a firewall/web proxy. Connecting to the
web succedes and this shim context is marked 'Fully' since 'all' of
the ULPs using this shim context is working. However, when
you click on a streaming link & your media player starts using this shim context, the streaming media fails since its blocked by the firewall,
so the shim context could be marked as 'Parial.'

I guess we could wrap this around some sort of multiple interface scenario
like you started with a GPRS connection, but (corporate) WLAN comes available,
so you re-home because you prefer a speedy connection, but the WLAN connection
is firewalled. 

Still, what I'm wondering is how does the shim layer know that an address
pair failed because of something like this, or because of some other
reason, like a streaming server became unavailable, etc. etc.

In addition to that issue, there is also the issue whether the shim would be able to know how many ULPs (really, how many different users above it might provide advice) are in play.
I don't see how it can know this, since it can't know when ULP endpoints (such as TCP connections, or some form of associations built on top of UDP) come and go, unless we assume that all the ULPs are modified to provide this.

So I think one would need a much more complex way to deliver advice to venture in this direction.

And as you point out, it might be intractable to do anything useful in the shim even if we had the 3 different states.

   Erik