Re: [RRG] Are host-stack modifications allowed or disallowed ?

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Robin,

On 2008-02-21 13:59, Robin Whittle wrote:
> Hi Brian,
> 
> You wrote, in part:
> 
>> However, all hosts are not created equal. If a solution required 
>> a specific type of host to be updated, that might be quite well 
>> linked to economic incentives and therefore deployable. I'm
>> thinking of a solution that needed host updates only in servers
>> that are globally visible (typically those in DMZs), but not in
>> client or generic p2p hosts. Since it is those globally visible
>> servers that are the main customer base for PI multihoming, they
>> might well be incented to update their stack to support some form
>> of loc-id solution.
> 
> 
> Assuming we are discussing only the goal of multihoming and TE for
> hosts which are public servers (and therefore not concerned about
> other goals related to routing-addressing, such as improving IPv4
> address utilization), then for your suggestion to work, I think:
> 
> 1 - You would need to show that the multihoming and TE could
>     be achieved without changes to the client hosts or the
>     networks those are located in.  Therefore you need to achieve
>     multihoming and TE purely with new software in the server hosts,
>     or together with some routing changes in their network.
> 
>     This has to be done in parallel with deploying a map-encap
>     scheme, with its ITRs, ETRs and mapping database distribution
>     system.

I'm thinking that there may be a class of solutions which will
work as far as aggregation and scaling are concerned without
any host modifications, but would allow host modifications to
have substantial impact on traffic engineering for the benefit
of sites hosting major server farms. This type of site cares
about traffic engineering to improve its own performance and
reliability, quite independently of ISP concerns about traffic
engineering. I could imagine a server farm dynamically adjusting
its loc-id mapping as the work load shifts around between
phsyical servers, or as it observes performance changes
from one ISP or another. I would expect this would need tight
interaction between host virtualisation software and the
routing system.

> 
> 
> 2 - To be incrementally deployable, the benefits would need to
>     ensue pretty directly and immediately to the people who run
>     these servers and/or the networks they are in.  Or do you mean
>     some external incentive scheme to encourage server operators to
>     change their operating system (and perhaps application?)
>     software?
> 
> 3 - Also, I think you would need to show that this subset of
>     address usage being used in the new way would make a big
>     enough impact on the routing scaling problem for it to be worth
>     the trouble - ideally sufficient to solve the problem
>     indefinitely without having to take other measures.

No, only that it would make a big enough impact on the major
hosting sites that they would pay for it.

> 
> 4 - I also think you would need to get consensus that the
>     dichotomy you are implying about networks with public
>     server hosts and networks without is valid and will
>     remain valid for some decades to come.

My personal feeling is that this will persist and even
increase, but of course the technology available and the
business models in use have a circular relationship, so
prediction is quite uncertain.

However, the fact that sites use DNS and BGP4 to attract
traffic to particular prefixes today strongly suggests that
they will use any deployed loc-id mapping system the same
way.

> Do you have any possible approaches which would pass all of these tests?

No, except to suggest that hosts MAY particpate in updating
the loc-id map.

> 
> LISP-NERD, APT and Ivip don't need any host upgrades at all, since
> there is no delay problem or any other difficulty which needs to be
> solved at the hosts on either end of the communication.
> 
> I think the only reason people are thinking of host upgrades now is
> to make hosts somehow cope better with the initial packet delays
> which look like they will be inevitable often enough to be a problem
> with LISP-ALT or TRRP - the two pure-pull systems currently under
> discussion.  You could do this for servers, to help in some way with
> the server-client response communication, but your proposal doesn't
> allow for upgrading hosts which are clients, so they still suffer
> delays and any host stack complications which result.
> 
> It is not clear to me how host changes could make these initial
> packet delays much less of a problem, other than to tweak existing
> protocols so they didn't make such a mess of themselves when such
> delays occurred.  

Yes, teaching transport protocols to tolerate a larger initial
delay seems possible if it had to be done.

> The delays will still add up and the end-users
> will still be affected - making this form of address space suck, or
> at least be widely regarded as being second-rate and best avoided.

At the risk of repeating an argument already made, I don't think that
users would even notice a few hundred ms in addition to currently
experienced start-up delays, as long as the transport behaves
gracefully.

    Brian
> 
> The others tests look pretty challenging too.
> 
>  - 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