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

Re: [RRG] Elegance and the rejection of SHIM6 host-based multihoming

On 23 sep 2008, at 5:27, Robin Whittle wrote:


it's unimportant whether this control is an inherent part of a
centralized design or is simply added to a decentralized design because 
it's an additional requirement. There is nothing stopping you from
coming up with a shim6 control protocol.



Adding a control protocol for altering the SHIM6 behavior of all
hosts in a network would be an extra layer of complexity - which is
important.
A good solution that is somewhat complex is still a good solution, especially if there's no good simple solution. Things like SNMP and IPsec are so insanely complex that the IETF really can't play the complexity card anymore. (It seems any protocol with the S for simple in its name is cursed in this regard...) 


It also avoids the need for continuous keepalives that is present in
many protocols.



But how could an application protocol know it is running over SHIM6
and therefore decide it doesn't need to use keepalives?


Applications don't need keepalives.


How could
SHIM6 know what level of continual probing to conduct in the absence
of actual traffic packets?
Why would you need to probe if there is no actual traffic? Suppose you have an IMAP session and you go drink coffee at 10 until 10.20 and there's no new mail in the interim. At 10.01 the connection goes down and at 10.19 it comes back up. Any time spent repairing that connection would have been wasted because connectivity wasn't necessary at that point.
The shim6 REAP protocol doesn't send keepalives when the session is progressing without trouble and it also doesn't send keepalives when the session is idle. So it basically only sends keepalives when there is only traffic in one direction or around the time a session transitions from active to idle. 


The recent paper:



 http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf
Hm, I'll have to read that when my connectivity comes back. (Things are rather quiet here at the university with the connection to the rest of the world severed...) 


the reachability problem is only discovered some time
after it occurs, when the sending host has data to send.


Right.


Then,
there would be seconds of delay while the application gets no
response and the SHIM6 layer somehow decides that the current
address doesn't work, before the application would try again (I
think this is how it would work) and the packet could be sent to
another address, via another ISP, which did work.
Right. Obviously it's always good if things can be fast but a few seconds delay in this relatively rare case isn't a problem, in my opinion. 


A system which completely isolates the hosts from multihoming,
portability etc. by providing them with a consistent IP address at
all times is arguably a lot simpler to run and debug than one which
pushes a lot of the complexity, responsibility and potential
problems into the host operating systems themselves.



Yes, but our architecture is such that it's impossible to communicate
this type of information between the network and the hosts, so a lot of information is lost if you take this functionality out of the host. We 
do congestion control in hosts for a reason.



I don't understand this.
In many cases it's better for higher layers to actually know what's going on than to just assume that everything is alright and get confused when it isn't. But on the other hand interfaces between layers, especially layers implemented in different systems, are rather expensive. For instance, congestion control works better if the routers and hosts have a common understanding of how much buffering will happen in the network, but there is no way to communicate this information so there is sort of an arms race between larger router buffers and larger send/receive buffers. 


shim6 just negotiates extra addresses and switches to a different one
when necessary. If you can boot strap the address negotiation without
requiring an initially working address pair then you could simply use
ULAs or some such as the identifiers. However, this would require an
id->loc lookup of some sort, which is something we were reluctant to
include in shim6.



I don't clearly understand this.  From all I know, SHIM6 does not
enable a network to have portable address space.  So moving to
another ISP requires changes to all DNS entries, and to any other
place where IP addresses are used.  This includes any ACLs, I guess.
Yes, that is correct for shim6 is it's currently defined. But you could easily (ok, maybe not so easily) add a mapping system to shim6 and then it COULD support all of this. 


Your approach is a retreat from the original division of labour in
the Net, on the basis that we can't possibly expect the "routing
system" to do this - therefore all hosts must change.
shim6 was created with MANY multihomers in mind (potentially all internet users). There is no way all of those people can run BGP or something like it. Now obviously there is a point at which shim6 starts becoming impractical. There is also a level of PI prefixes that the routing system can support without trouble. However, the current rules for PI don't take either of these boundaries into account so EVERYONE is going after PI which we know won't scale and the interest in shim6 has dried up so shim6 may not become available to those for which it would be the best solution, either. This is all a result of ARIN jumping the gun on IPv6 PI. 


Host
operating systems and applications must change so they can cope with
having a changed IP address at any time, or at least with
multihoming having two or more addresses, with no guarantee that all
of them will be reachable.
Get over it, this is a result of choices made in the IPv6 design a long time ago, regardless of the presence of shim6. 


This does involve application changes,
since with the approach you suggest, there can't be reliable
referrals via a single IP address, which is the current arrangement.
Since when are referrals reliable in the first place? They're a big, big mess and the IETF hasn't even considered starting a cleanup effort. 


The disruption will come to IPv4 as
it runs out of addresses. At that point there will be people who are on 
v4 and not of v6 and people who are on v6 but not on v4. That's not
good. People who add v6 today can keep running v4 so there is no
disruption.



I don't think there is going to be a sudden crunch with IPv4 - just
an increasingly high economic value placed on address space,
together with more economic pressure to use it efficiently, and to
trade it back and forth so none of it goes unused.
There is plenty of IPv4 address space for the forseeable future, it's just not distributed evenly. Redistribution efforts haven't had spectacular results in the past, and I don't expect them to be succesful enough in the future to continue to meet current demands after we run out of free IPv4 address space. So a crunch is coming. I agree that it's probably not going to be a very sudden one (although we can't rule that out, no telling what strange things people will do when crunch time arrives) but that doesn't really matter: as soon as the unused space is gone, it's a given that getting any non-trivial amount of IPv4 address space is going to be harder / more expensive every successive time. 


but I think we are a long way from a situation where
IPv6 is attractive to most end-users.
IPv6 is the ultimate NAT traversal mechanism. It will happen, especially as it becomes easier for end-users to run IPv6 because it's available in more of their equipment and even turned on by default. 

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg