Re: Design decisions made at the interim SHIM6 WG meeting
marcelo bagnulo braun <marcelo@it.uc3m.es> Thu, 27 October 2005 16:17 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Thu, 27 Oct 2005 16:17:56 +0000
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Message-Id: <ac5bd204314577893aeb454c0a24bf09@it.uc3m.es>
Content-Transfer-Encoding: quoted-printable
Cc: shim6 <shim6@psg.com>
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: Design decisions made at the interim SHIM6 WG meeting
Date: Thu, 27 Oct 2005 18:17:26 +0200
To: Iljitsch van Beijnum <iljitsch@muada.com>
El 27/10/2005, a las 17:08, Iljitsch van Beijnum escribió: > On 27-okt-2005, at 15:29, marcelo bagnulo braun wrote: > >>> I don't think "decisions" is the right word here... These are more >>> like suggestions by the chairs. > >> sorry, but i disagree here. >> The points below were accepted by most of the people in the room (i >> certainly accepted most of them) > > 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? >>> The real point is what happens when the address pair selected by >>> either the application or RFC 3484 doesn't work. How do we handle >>> this case? > >> the idea, (and i think this is was this decision point is about) is >> that we need an update to rfc 3484 to deal with this. > > 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 > Any modifications to these won't help if an application, with help > from RFC 3484 or its successor, selects an address pair that isn't > reachable and then DOESN'T cycle through all source/destination > combinations. well, first of all, rfc3484 should state that the app should cycle not only through all the destination addresses but through all possible pairs of source destiantion address pairs available. This is the minimum change that rfc3484 would require of course i agree that we should do better and try to help with apps that don't cycle through all the possible address pairs > > 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.... i can think of soem difficulties, but i would like to see if we are considering the same problems here... > So either we have three choices: > > 1. adopt the "second shim" to do this for the application > 2. make it possible to repair the situation where there is no > reachability between the ULIDs from the start. > 3. update RFC 3484 and wait for all applications to be updated > > I believe 3. won't work in practice and if it did, it would be a huge > duplication of effort as all applications would have to implement the > same functionality. Remember that we chose to make the shim such that > unmodified applications can benefit from it. > Ok, let me explain how i see it: 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] - 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. 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) - 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. the main difficulty is how rfc3484bis can determine that a src address is working (in the previous approaches, this was left up to the app, which knew when a address pair was working and when it wasn't, it retried to send the packet again) In this case, the goal would be to leave rfc3484bis to determine when a src address (or an address pair) is working. I guess that if we assume that rfc3484bis will only handle bidirectional paths, we can assume that if we receive a packet with src address IP1 and dst address IP2m then we can say that the address pair with src=IP2 and dst=IP1 is working as an outgoing address pair. Using this, rfc3484bis can cache information about address pairs contained in received packets, to determine address pairs that are working. In this case, rfc3484bis would send a packet using a given address pair, and if no packets are received from this address pair in a given period, it could retry to send the packet using a different address pair until it finds one that receives traffic back, or it gives up 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. >>> I have no problem with a shim header for demultiplexing in cases >>> where demultiplexing would otherwise be very hard or impossible. For >>> instance, in the case of several extension headers, an explicit shim >>> header makes it possible to indicate which headers see modified >>> addresses and which headers see unmodified addresses unambiguously. > >>> However, I think it's a very bad idea to have a shim header in EVERY >>> packet with rewritten addresses, because there are cases where the >>> shim context can be determined from information that's already in >>> the packet unambiguously so an extra header is unnecessary. > > [...] > >> this is the point of debate: whether this extension should be >> mandatory in the base spec or not. > >> my opinion about this, is that this would be indeed quite complex. > > 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 > Deciding when a host can safely set this option is more complex of > course, but THAT part can be an experimental extension. (I'll write a > draft shortly.) However, it's essential that the capability to > suppress the shim header is in there from the start, or implementing > the logic to enable this capability will be so hard to get off the > ground (then both ends would need to be updated rather than just the > receiver) that probably nobody is going to bother etc etc. > >> I mean i like the idea but i am afraid that when we try to define the >> details, the result will be complex. If not i would certainly support >> this > > 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) > That would be after Vancouver, though. > >>>> 4. Use a 32 bit context field with no checksum, and 15 reserved >>>> bits and a >>>> 1 bit flag to indicate control / payload. Note potential DOS >>>> risks > >>> If we know there are risks today, maybe it makes more sense to make >>> the tag variable size (to be negotiated between the peers) rather >>> than fixed? > >> what about making it fixed of 47 bits from the start? > > Then there is no room for extensions, and some implementations may be > more confortable with 32 bit math. > >>>> * 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) >>> Forking is a bad idea, it increases the complexity of the shim >>> manifold while pretty much the same functionality can also be >>> provided in a different way. > >> i guess it depends on how you handle it... i mean for me, i see it >> just as multiple contexts with the same ulid pair, but with different >> context tag. In this view, it doesn't seems very complex, it is just >> multiple contexts..., am i missing something? > > With forking, a context is no longer uniquely identified by a ULID > pair. right, ulid pair plus context tag defines the context > This means the context id must be carried along everywhere. not sure what you mean by everywhere... packets do you mean? > 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) >>>> 18. Use a statically specified in the initial protocol >>>> specification of >>>> (10) seconds. > >>> This means that senders must transmit something (data, keepalive) >>> every 10 seconds, right? So the receiver needs to wait a bit LONGER >>> than 10 seconds to time out. > >> as i recall it, 10 seconds was the time of 3 packets i.e. a node is >> expected to send packets every 3 seconds, so if 3 packets are >> missing, then we have a problem detected. > > I think every 3 seconds is excessive. So in my draft I just wait 12 - > 15 seconds at the receiver (10 seconds that the sender uses + margin > for RTT and jitter), and then initiate the full reachability > exploration. This will first do a packet with the currently used > address pair but after a very short timeout it will start to explore > alternate address pairs. > > This means the full exploration may be triggered when omly two packets > are dropped, which is a bit aggressive, but on the other hand it means > only an FBD keepalive every 10 seconds rather than every 3 seconds so > I think this makes sense. > 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... regards, marcelo
- Re: Design decisions made at the interim SHIM6 WG… Paul Jakma
- Re: Design decisions made at the interim SHIM6 WG… marcelo bagnulo braun
- Re: Design decisions made at the interim SHIM6 WG… marcelo bagnulo braun
- Re: Design decisions made at the interim SHIM6 WG… Pekka Savola
- Re: Design decisions made at the interim SHIM6 WG… marcelo bagnulo braun
- Re: Design decisions made at the interim SHIM6 WG… Erik Nordmark
- Re: Design decisions made at the interim SHIM6 WG… Iljitsch van Beijnum
- Re: Design decisions made at the interim SHIM6 WG… Iljitsch van Beijnum
- Re: Design decisions made at the interim SHIM6 WG… marcelo bagnulo braun
- Re: Design decisions made at the interim SHIM6 WG… Iljitsch van Beijnum
- Re: Design decisions made at the interim SHIM6 WG… Iljitsch van Beijnum
- Re: Design decisions made at the interim SHIM6 WG… Erik Nordmark
- Re: Design decisions made at the interim SHIM6 WG… marcelo bagnulo braun
- Re: Design decisions made at the interim SHIM6 WG… Erik Nordmark
- Re: Design decisions made at the interim SHIM6 WG… Jari Arkko
- Re: Design decisions made at the interim SHIM6 WG… Erik Nordmark
- Re: Design decisions made at the interim SHIM6 WG… Brian E Carpenter
- Re: Design decisions made at the interim SHIM6 WG… Geoff Huston
- Re: Design decisions made at the interim SHIM6 WG… Geoff Huston
- Re: Design decisions made at the interim SHIM6 WG… Jari Arkko
- Re: Design decisions made at the interim SHIM6 WG… Geoff Huston
- Re: Design decisions made at the interim SHIM6 WG… Erik Nordmark
- Re: Design decisions made at the interim SHIM6 WG… Spencer Dawkins
- Design decisions made at the interim SHIM6 WG mee… Geoff Huston