[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting
(sorry for belated reply)
On Mon, 31 Oct 2005, marcelo bagnulo braun wrote:
this, by itself would be enough to provide multihomed hosts some
mechanism to be able to establish new communications after an
outage in one of their ISPs i.e. rfc3484 bis, agree?
Yes, I agree.
but in this would the app the one that triggers the shim? or would
be the shim that detects when there is a problem?... i don't see
how this works...
I'm not sure, but I was under the impression the plan was for shim6
to be able to determine independently of the application whether
failover was required, possibly using transport protocol hints.
I am not sure if you are considering the case where the app selects
the source address (uses bind()) or not... i asume that the source
address is not set by the app.
Ah, well things get tricky if the application specifically selected
an address. It might not even be wise to try shim such a socket,
often applications which do this, do so because they expect that it
will limit which interface(s) packets will arrive or exit from.
Breaking that might not be a good thing.
The vast majority of applications do not bind to a source address.
Most which do are listening and do so at administrative behest.
Senders which bind are rare, ones I can think of which sometimes do,
do so to:
- have their address be independent of any physical interface
(loopback attached address)
- control which interface(s) the packets will exit from (in
conjunction with some other administrative action. E.g. routing or
firewalling rules)
- sending to multicast address
(kernel picks interface according to source, unless application
uses some other mechanism to indicate output interface)
others?
So, the app tries to establish a communication. suppose that there
is a failure in one of the isps. the app tries to establish a
communication without specifying a source address, and rfc3484
selects the address associated to the isp that is down.
Now, the packet with that src address never make it, so who detects
that there is a problem?
The shim, that's its job surely. ;)
The shim? how is this done? i mean, the shim cannot know if there
is an reply packet expected, since it is not aware of the app
protocol.
Well, the idea is to have it possibly hook-in to transport notions of
progress, no? Or even have transports poke shim6.
In the worst case for datagramme protocols where connection state, if
any, is wholly within the application, shim can do its own probing,
for some unspecified time after the last packet is sent. There may be
other sources of information. Seems to me a shim could draw from a
variety of information sources:
- using Shim6 side-band probing, if other side can co-operate.
- fallback to "dumb" probes, e.g. ICMP based.
- unspecified local information (e.g. link-state)
The other option would the app, to notify the shim that something
is wrong and to try fix it... This would require a modification to
the app and would only make sense of the other end supports the
shim. As i understand it, this is what we called "shim API on
steroids" which would allow an app to tell the shim "i want to
connect to hostX, you find a working pair for me"
Maybe. A libshim would be useful actually, possibly in conjunction
with a shim daemon. For both prototyping and deployment on legacy
hosts without a native shim.
This is good, but it does not work with legacy hosts (that don't
support the shim), it imposes a shim negotiation upfront. I like
your point that this could be done only when the initial contact
fails though (but i am not sure how to detect this failure)
Well, shim will have its own control path no? So at least for
communications between two shim aware hosts it will be possible to
have an independent way to test viability. For paths to non-shim
aware hosts you'll have to fall-back to monitoring TCP state (for
TCP).
Transports where all the flow-state is in the application - no idea.
Passive observation and maybe some dumb ICMP probes is best you'll
likely do - hack, but something. But, really that's a *miniscule*
fraction of inter-AS traffic.
Whatever else, the 99% case is that packets flow back and forth and
shim literally would need to do nothing but observe. For the 1% of
time where there is a failure, it doesn't matter if shim6 is not
perfect and can not provide near-perfect detection for all protocols
- because if it can cover even 80% of that 1%, then that's *way*
better than what we have today.
(and I think it's a very safe bet that more than 80% of inter-site
traffic is TCP, hence more state information available close to
hand).
If Shim6 is good and useful, more and more hosts will implement it -
even if it isn't perfect (and btw, lots and lots of complexity to try
cover that last 10% or less of 'difficult' cases like opaque user
protocols and make shim 'perfect' might be counter-productive if it
makes Shim far more difficult to implement). The more hosts implement
it, the more you'll have the more reliable 'shim6' methods available
to monitor reachability, hence slowly providing coverage for that
last 20% of that 1%.
So, as i see it: - the API on steroids is a good feature that we
want to have
- we need a rfc3484bis at least to support communications with non
shim hosts and maybe it would be good to deal with the problem for
communications between shim hosts, depending on the result
please check draft-ietf-shim6-proto-02 there you will find that the
shim6 protocol rqeuires a 4 way exchange to establish the shim
context, that needs to be done before the shim translation between
locators and ulids can be done
Yes, but isn't there another discussion ongoing here to try optimise
this?
There isn't a good reason to delay packets because of shim6, is
there? You can send the first packet on without setting up two-way
shim, just do an "opportunistic" mapping (the NULL mapping likely),
let the packet go on its way and then also start Shim6 in parallel
(be it by piggy-backing a shim6 setup message onto this first packet,
or as a seperate packet). Typically there are no failures and all
sources are valid, so typically any source will work.
I.e. at "initial contact", the shim can opportunistically startup and
at least determine whether the other side is a shim6 capable host. If
progress is obviously being made by ULP, shim6 can stay quiet.
I think in terms of the protocol, this means that shim6 could send
the I1 message in parallel with the "initial contact" by ULP
(possibly by piggy backing the I1 on the same packet as an optional
header, Iljitsch, Pekka, etc. were discussing that I think).
This is the "deferred handshake" part of the Shim6 protocol, I think.
right. 3 comments:
- this is only for initial contact (so no problem with breaking tcp
connection because using a different address, since the communication is
being established at this very moment)
- this assumes bidirectional working address pairs, (i.e. a single address
pair is used in both directions of the communication)
- it does not require special support from the peer (it works with non-shim
nodes)
In this other case, we are dealing with a different problem: how to
cope with failures during the initial contact?
Ah, got ya.
however, it seems that there are apps that select the source
address they want to use using bind().
Right, see above.
For this it makes sense to provide some guidance of how this needs
to be done
I am not saying that this is the only mechanism that we need to
deal with this, but what i am saying is that IF apps are going to
select the source address, we need to provide guidance so that they
do it properly taking into account that different source addresses
need to be tried in case of a failure
Right, but the thing is, if an application is one of those rare apps
which deliberately sets its source address - ask yourself "why is it
doing that?", the reasons for doing so possibly are fundamentally
incompatible with cycling through addresses for redundancy..
There's no point changing an RFC to add source address cycling, if
the only apps picking source addresses are doing so because of
multicast or explicit administrative action. ;)
That leaves the other set of apps, ones which do not bind() to any
explicit address. I don't see then why apps then have to get into
details of SAS - the whole point of shim6 is to handle that.
Needs consideration at least.
well, rfc3484 state for instance that the app should iterate
through all the list of available destination addresses until one
that is working is found. This is why it seems that rfc3484bis
should be the place to state that in the case that multiple source
addresses are available, the app that decides to set the source
address using bind() should iterate through all available source
addresses until it finds one that is working
Maybe, but see above.
do you have any idea you could share?
Write a connection setup / management library to handle
multi-dest/source addresses nicely. This library could even take care
of handling reconnects nicely. Further discussion is a bit out of
scope (and I don't have any immediate interest in it ;) ).
weel this is just another way to put it, right? whether you call it
shim without the shim protocol or rfc3484 bis, they would be local
mechanisms for identifying non working source addresses and
selecting those that are working, right?
Well, no. RFC3484 would affect *everything. Specifying as part of
shim would only affect shim. As part of RFC3484, you'd be
fundamentally changing how applications work today, e.g:
- SAS today assumes applications generally don't specify
source-address, but if they do so it's for
exceptional/administrative reasons - not overriden. You'd have to
consider all those exceptional/administrative reasons..
- SAS today assumes routing policy has a strong influence (SAS is
typically done after the output route is known). Applications
however generally are not aware of routing. Seems a big change.
I think possibly it might be better to confine this to Shim6
initially, where its application is more obvious.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Mathematics deals exclusively with the relations of concepts
to each other without consideration of their relation to experience.
-- Albert Einstein