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

Re: draft-ietf-multi6-multihoming-requirements-06.txt

On Wednesday, Jun 11, 2003, at 22:53 Africa/Kampala, Randy Bush quoted:


Let's see: load balancing is not a realistic requirement.  For the
architecture to be automatic, we have to be dynamic and we've
proven that we don't know how to do that yet.
For load balancing to be possible, the architecture does not need to be fully automatic. Load balancing is perfectly possible today using automatic mechanisms which are tuned manually.

Even to give people
some tools seems to lead to abuse.
Some clarification on this sentence would be useful; I am struggling to understand it.

  Who controls the balancing?
The source?  The destination?  Don't say 'both'.  No packet can
serve two masters.
If I am multi-homed, then I control the relative egress loading on my various transit circuits by managing my exit selection policies to choose exits which tend to balance traffic in a way that makes me happy.

I control the relative ingress loading by supplying clues to my transit providers and thereby attempting to influence the exit selection policies of those transit providers, and so on for all inbound traffic through the chain of ASes which leads to its source.

Both ingress and egress loading policies are necessarily malleable, since policy in external ASes and traffic demands vary and circuit sizes often do not.

This is not a deterministic, calculable process, but it works sufficiently today that people do it. Removing the possiblity of load balancing means that N-way multi-homed ASes will suffer an increase in transit fees which approaches a factor of N, and this is not a reasonable compromise to expect people to make in the interests of architectural simplicity. Most of the world does not enjoy cheap external connectivity.

Performance.  Exact same arguments since the only way to affect
performance is to load balance.
In the context of current practices, the performance requirement is met by the ability of an AS to control its own exit selection policy.

Policy: so ill stated as to be meaningless.  If this is a call
for policy routing, that's fine, but it has nothing to do with
multihoming.
It is common practice in many ISPs to multi-home between a cheap, poorly-performing transit service and a more expensive, better-performing transit service (a common example is expensive terrestrial fibre vs. satellite).

By arranging for batch, non-interactive traffic (mail, usenet, HTTP from pre-fetching web caches, FTP mirror updates, etc) to use the satellite service, there is more of the expensive-but-better capacity left for interactive services, and the quality of the user's experience is increased. In other ISPs, customers are able to buy multiple grades of service, corresponding to the quality of the transit used for their traffic (for some convenient definition of quality).

Policy routing is one way to do this, but it assumes that the owner of the policy has administrative control of the router the other side of the satellite link (from the perspective of bandwidth-starved ISPs, problem traffic is inbound, not outbound). This is frequently not the case.

Another approach is to bundle endpoints for batch traffic into particular netblocks which can be advertised in such a way that their inbound traffic comes exclusively over the satellite. In the v4 world this involves multihoming policy.

In general, this requirement does not arrive unless the site is multihomed (since with only one transit path, there is no choice about shifting traffic according to protocol or other policy). The comment that this has nothing to do with multihoming is hence confusing.

Simplicity: motherhood, apple pie and chevrolet.
Perhaps there is some cultural reference I am missing, since this means nothing to me.

Transport survivability: Well, ok, but this is just a refinement
of the redundancy requirement.  How about we remove the redundant
redundancy
requirement?
They are not requirements, they're goals. It is reasonable to assume that there will be multihoming architectures which do not meet all these goals (that, after all, is why we were unable to shift a draft without removing the "requirements" word).

It is possible to gain protection for connectionless traffic in the case of single transit failure without providing protection for connection-oriented traffic.

Compatible with DNS: meaningless
I will interpret "meaningless" as "I do not understand this, and request clarification".

A multihoming solution which results in increased load on DNS servers by a factor of 10,000,000, or requires the behaviour of DNS servers to be modified (e.g. by requiring ordering of RRs in a reply to be modified according to source address for all multi-homed sites) is going to impose operational issues on the Internet. It does not seem an unreasonable goal to avoid such issues.

Packet filtering: meaningless
Unicast RPF checks are commonly applied to external interfaces on ISP routers, and these filters demonstrably drop a lot of unwanted traffic. A multihoming architecture which prevented unwanted traffic from being dropped would result increased junk traffic being carried around the Internet. Similarly, to my comment above, it does not seem unreasonable to want to retain the capability to drop junk traffic at the ingress point of your network.

Scalability: see simplicity

routers: create a new architecture, but don't change the routers, change
the hosts
The text says, in fact "the solutions may require changes to IPv6 router implementations".

hosts: create a new architecture, but don't change the hosts, change the
routers
The text says, in fact, "the solution should not destroy IPv6 connectivity for a legacy host implementing [list of RFCs]". It says nothing about not changing hosts.

Interaction between hosts & routers: tighter coupling between subsystems
has never been an architectural good idea. So let's do that and change
both.
I see no text which advocates tighter coupling between hosts and routers; I see text which does not require the coupling between hosts and routers to become looser.

O&M: see pie, apple.

multiple solutions: please don't give us one size fits all, that's
not confusing enough
In fact the text says "multiple solutions will incur a greater management overhead, however, and the adopted solutions should attempt to cover as many multihoming scenarios and goals as possible".

security: don't break security
If the anonymous observer thinks that the converse is more desirable, perhaps he or she could explain why.

Net:
The real requirements are:

	- Provide multihoming
	- Provide scalable routing
	- Transport survivability
Summary: the goals that the anonymous critic finds important are covered by the draft. Other goals that the anonymous critic hasn't thought of, or doesn't find important, are also covered.


Joe