[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design decisions made at the interim SHIM6 WG meeting
El 27/10/2005, a las 21:37, Iljitsch van Beijnum escribió:
What RFC does is two things:
1. select source and destination addresses
2. tell application programmers to cycle through all destination
kind of agree...
i would say that rfc3484 does:
- it passes an ordered list of destiantion addresses to the app and
requires that the app should cycle through all of them until finds
one that is reachable
- it selects a source address for a given destiantion address when
the app does not select one
Actually, looking over the RFC very quickly, it doesn't look like RFC
3484 requires applications to cycle through all available
Section 2 states that:
Well-behaved applications SHOULD iterate through the list of
addresses returned from getaddrinfo() until they find a working
Most IPv4 applications don't cycle through all destination
addresses, and a significant number of IPv6 applications doesn't
either. I don't see applications cycle through all source/dest pairs
because that's very hard to do right.
not really understand what is the part that you think it is hard....
Specifying an address with bind() is of course not problematic. The
trouble is maintaining an up to date list of available addresses in
the system. Since this list is subject to change applications would
have to query all available addresses prior to any TCP session
establishments and the like. Also, when the application has this list
of addresses, it somehow needs to go back to the system to have RFC
3484 policies applied to the source/dest pairs.
right this is what rfc3484bis needs to specify how is done
I think we could have 3 approaches (which can be complementary i.e.
does not have to be one or the other)
- first approach is to let the app take care of everything
i.e. inform the app about all src and dst address and let
the app try all the possible combinations.
This is the minimum change to rfc3484 bis, i.e. state that
apps SHOULD retry with all possible src,dst pairs
A possible optimization for this, would be that the rfc3484
delivers an ordered list of address pairs (similar than current
rfc3484 delivers a ordered list of dst address, the rfc3484bis
would deliver to the app an ordered list of address pairs (based
on rules for prefering one address pair over the other)
[an alternative to this that would be more compatible with current
rfc3484 would that for a given dst address, rfc3484bis would
provide an ordered list or src addresses for this dst address]
I suppose this is possible although I don't find it very desireable.
If applications have to be changed anyway, why not come up with an API
that REALLY solves all of this?
but i think that we need to support the case where the app want to
select addresses (src and dst) that i wants to use. In this case, it
would make sense to allow rfc3484bis to provide some guidance about:
- that the app should retry using not only different dst addresses but
also different src addresses
- some guidance about which pair of src, dst address would be better to
try first i.e. an ordered list of address pairs or at least for each
dst address listed in the ordered list of dst address, provide an
ordered list of src addresses to try.
This of course is not opposed to other approaches as the ones mentioned
below. I think that we are just dealing with different scenarios, with
progressive app involvement:
- in this case, the app wants to select the address pair to use, so
let's allow rfc3484 bis to provide some guidance
- in the next case, the app will retry (i.e. determine when the packet
didn't make it) but will let rfc3484 bit to select the source address
- in the last case, rfc3484bis handles the full retrial process,
determines when a retrial is needed and selects the src address for it
- a second approach would be similar to the current case where the
app does not select the src address. In this case, the rfc3484bis
src address selection mechanism would need to use a different
src address each time the apps retries.
Yes, this is absolutely essential because consistently selecting a
non-working address is the worst possible outcome.
right, and always retrying using different dst address but always the
same non-working src address seems a bad scenario
In this case the responsible for retrying is still the app, and
the app needs to be informed that it needs to retry several
times with the same dst address, so that the rfc3484bis would
use different src address for this dst address. In order to
do this we could define an notification at the api level
to allow rfc3484bis mechanisms to inform the app that no more
src addresses are available to retry with and that we will be
recycling to ones that have already been tried (so that the
app can give up or use a different dst address)
Also API + application changes...
- a third approach would be to allow rfc3484bis to handle
retrials itself when the src address is left unspecified by the app
In this case, when an app tries to open a socket with an
unspecified src address, rfc3484bis would try to send packets with
different src addresses until it finds one that it is working.
And the next logical step is to do the same thing for the destination
but this would imply too much changes at this stage....
i mean, you can do this by connecting by name, in which case, there
shouldn't be much problem, but if you want to support this when
connecting by address, then you will need something like the shim to be
negotiated upfront, before the communication even starts. this also
requires support from both ends. I don't think this is the goal of
rfc3484 bis, but rather the goal of the extension that we discussed in
the ams meeting about the API on steroids for the shim.
So, i see this as different issues:
-on one hand we have rfc3484bis, that provides guidance to apps about
which address pairs to use, and
- tries to select a reasonable src address when the app leave it
unpsecified and perhaps,
- it retries using different src addresses
while otoh, we have shim+API on steroids, that given a ulid pair (or an
dst ulid) it attempts to establish a connection using perhaps
alternative locators, in a transparent fashion to the app. In addition,
the shim through this API on steroids, it can inform that there are not
working locators for this dst ulid, and that it may make sense to try
with an alternative dst ulid (because the shim knows that there are
working locators for this ulid). Perhaps, we could even allow the shim
to provide an enhanced connect by name service
but i would suggest to do this separation about what is done by
rfc3484bis and what is done by the shim + API on steroids
the main difficulty is how rfc3484bis can determine that
a src address is working
For TCP it's simple: connect() fails = retry with a different address.
For UDP a packet coming back with src addr as dest addr, src port as
dst port etc is a reasonable indication that things are going well.
right, but for this second case, this may lead to erroneous
conclusions, which may be a big problem, since rfc3484 bis would be
stubbornly using a given src address while this may not be working (for
that particular app)
Now, this third approach is at best very debatable.
I think that the first two approaches make sense and that it would be
useful to incoporate information about incoming address pairs as a
hint to select outgoing address pairs that are working.
Is RFC 3484 ipv6 wg domain? In that case I think we may want to see
what that wg has to say.
right. the approach proposed in ams was for me to write a memo
describing the limitations of rfc3484 for multihoming support and a
descriptions of the possible changes to rfc3484 to produce rfc3484 bis
that deals with this.
i am on it, and i was thinking to include the points that i mention
above, that i why this feedback is so important to me
I suspect they'll be less than thrilled with API/applications.
[suppressing shim header]
As I've explained before: this can be exceedingly simple. We just
need signalling message, or a field in an existing signalling
message, so that a host can tell its correspondent that it doesn't
want to see the shim header for packets with rewritten addresses
within this context. If the sender simply honors this option then
we're done in the base spec.
i guess that the point is that we don't want to include this bit
unless we know that we know how to make this extension work in a
How about this: I'll write the draft about how this would work in
practice (i.e., when a host can demultiplex without the shim header)
and after that we make the final decision?
this works perfectly for me
(also i would be glad to work in the draft with you if you want)
Ok I'll contact you when I have my initial thoughts laid out.
* Adopt HIP parameter format for options; HIP parameter
defines length in bytes but guarantees 64-bit alignment.
I don't want this alignment. It wastes space, it's an
implementation headache and it buys us nothing.
i think that this is a small price to pay to allow future
convergence with hip that is anther protocol somehow related with
No, I don't see how this makes sense. It just makes the decision
making much more complex as the needs of two different mechanisms
must be aligned first.
not sure i understand what you mean here...
in the meeting we agreed that this is basically all that was to be
done in order to provide hip compatibility (no other consderations
will be made w.r.t. hip compatibility afaiu)
The problem here is that now the protocol layout is limited by the
requirements of both HIP and shim, and if either of these requires
some change, there must be extensive negotiations to maintain
no, we agreed that this will be the only effort to provide hip-shim
compatibility. no common option type name space nor similar will be