[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 addresses 


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 (destination) addresses. 



Section 2 states that:

   Well-behaved applications SHOULD iterate through the list of
   addresses returned from getaddrinfo() until they find a working
   address.
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...



right


- 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.


Right.
And the next logical step is to do the same thing for the destination address. 



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 simple way 

:-)
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


Great.


(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 format 
       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 shim6
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 compatibility.
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 used 


regards, marcelo