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

Re: Design decisions made at the interim SHIM6 WG meeting

On 27-okt-2005, at 18:17, marcelo bagnulo braun wrote:
It's important that the wg participants that weren't at the interim meeting determine the merit of all of these points themselves so the wg can come to rough consensus rather than just say "well most people that were in Amsterdam agreed so it must be the right decision". 


absolutely agree
but we do agree that most people that were in amsterdam agreed on this points, right?
I assume the people in Amsterdam agreed if they didn't say anything to the contrary... 


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


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


  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.


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


  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. 


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. 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.
I think compatibility with regard to how the two work together is much more important than sharing the same basic header format. 


 This means the context id must be carried along everywhere.



not sure what you mean by everywhere...
packets do you mean?


Everywhere in the IP stack.
One place where this is inconvenient is between the application, that specifies certain ToS requirements, and the shim. The transport protocol that sits in the middle must now somehow "color" all packets with the right context information so the shim knows what to do with the packet. IIRC there are also signalling complexities.
right but this is what it seems that apps want, right? the capability of selecting the locator pair to be used for carrying the traffic (at least this is what i understood this was all about)
Wouldn't it make more sense to do this by selecting ULIDs rather than by selecting locators? This has the added advantage that it also works regardless of whether the shim is available.
i think that 10 sec was just a value that was somehow appropriate.. i don't have a problem with 15 or 20 secs neither...
I have no problem with 10 as long as this doesn't require sending packets every 3 seconds, and I don't see why it would have to.