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

[Robin Whittle <rw@firstpr.com.au>]

Hi Iljitsch,

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

I agree, but I don't think that SHIM6 is a good solution anyway,
even if there was some centralised control of all the hosts.

> 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 is probably getting harder and harder to design anything simply
and still satisfy the increased number of people involved, or to
work properly in the variety of circumstances which exist.
Sometimes, in an effort to avoid overlapping enhancements to the
Net, we try to do several things at once.  This might be a good
thing if two birds really can be killed with one stone - but only if
the stone is not inordinately complex.

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

I am confused by this but it is probably not worth pursuing.


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

OK - if there was a temporary loss of connectivity, then this has
saved a lot of trouble.   However, if you want to use IMAP when the
connection for the last used address is down, then you have to wait
while your host's SHIM6 layer figures out it is dead and tries
another address instead.  With Ivip, there would be no such delay or
extra traffic testing connectivity etc, because the end-user
provided multihoming monitoring system would already have detected
the problem and fixed it already by changing the mapping.


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

OK - if it is a multihoming link failure, hopefully this won't
happen too often.


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

OK - this seems to be an example of it being desirable for the host
applications to know something about the network.

Still, for connectivity restoration in a multihoming link failure
situation, I still prefer the idea of the end-user having their own,
potentially highly customised, outage detection system with their
own preferred decision making system to restore connectivity with a
single action: changing the mapping to send packets to an
alternative ETR which is known to work.  I much prefer this fast,
end-user controlled, arrangement to having thousands of ITRs or
sending hosts mucking around, making their own probings and
decisions, all independently, with little or no ability of the
end-user network's administrator to control, view or debug these
actions due to the probe and decision algorithms being
monolithically encoded into the core-edge separation system.


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

Then it wouldn't so much resemble SHIM6 as Ivip's option for ITR
functions in the sending hosts!


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

Perhaps the fact that SHIM6 has not been widely supported is in an
indication that in the judgement of most end-user networks, it is
not and cannot be an adequate solution, or the best.


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

But those choices only make sense if SHIM6 is widely adopted.

I think there are a number of valid reasons for keeping the routing
system (broadly defined, including a future core-edge separation
scheme) doing its current job of giving each host a stable IP
address, rather than giving up on this and expecting hosts to
maintain reliable communications with other hosts in an environment
of multiple IP addresses, any one of which could become unusable
without prior notice.


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

For host A to be able to tell host B to send packets to host C,
based solely on host C's IP address is a perfectly simple and robust
technique - as long as host IP addresses are relatively stable.
With the non-PI approach of IPv6, which can only be made to work at
all with SHIM6 being widely adopted, you can only do this robustly
via either:

1 - A specifying C to B by way of C's DNS name.

2 - A specifying C to B by way of C's potentially multiple
    addresses, of which A may only know one.

Both are a lot more complex than using a single IP address - and for
any applications which use a single IP address now, there would have
to be significant application and protocol changes to handle either
of the two options above.   Also, option 1 assumes that C has a DNS
name.  Conventional IP address referrals work independently of DNS -
for any host at all.


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

Past redistribution attempts, of which I know little, were not
motivated by the increasing financial impetus to gain precious IPv4
space - so I expect there will be considerable business and
technical innovation in making the most of the increasingly
fragmented and populated IPv4 space, since IPv6 remains a bleak and
empty Internet for most end-users.

The most obvious technical solution is a core-edge separation scheme
which can slice and dice address space down to single IP addresses
in a scalable manner: LISP with PTRs or Ivip.  I think APT can only
do this if the current proposal is changed so there is a single APT
island - see: http://psg.com/lists/rrg/2008/msg02569.html .  I am
not sure how TRRP would support packets from non-upgraded hosts with
micronets longer than /24.


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

. . . such as innovation and trade . . .

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

I agree.  It is hard to predict how this will work out.


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

I still think we are a long way from this, and that in the meantime,
there will be an increasingly serious routing scaling problem in IPv4.

I don't have a clear idea about how many DFZ routes constitutes an
unworkable problem.  Probably there is no clear point where things
get unacceptably bad - it just gets more expensive and slows down
BGP, due to the increasing number of changed advertisements which
typically must be sent, received, interpreted and perhaps propagated
further (loosely speaking) whenever one link goes down, due to there
being far more prefixes advertised in total, than at present.

  - Robin


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