[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: General Feedback on Requirements
Hi Margaret,
On Wed, Apr 11, 2001 at 04:46:19PM -0400, Margaret Wasserman wrote:
> I sent feedback on the requirements very early on, and I
> guess that I was not specific enough about the changes
> that I feel are required, since the authors did not think
> that changes were warranted. So, let me be more specific.
I will go dig it out. Sorry if I didn't give it the attention it
warranted at the time.
> Although the document gives a nice definition of multihoming
> and provides a good explanation of the reasons why someone
> might want to multihome a site, it is not very explicit
> in stating the requirements for an IPv6 multihoming solution.
> In fact, it does not list many actual requirements.
The structure of the document certainly has scope for improvement;
as we were writing it in Minneapolis we tried harder to describe
the circumstances by which people are currently motivated to
multi-home than we did to the framework on which we were hanging
the words.
> When the document does list requirements, it is not rigorous
> enough. It doesn't define its terms or make it clear what
> is required.
I think you are right.
Vijay sent out some clarification on this shortly after the document
was released: the approach we took was that any solution which didn't
support everything people do today with IPv4 is doomed to become an
interesting ivory tower; the current motivations and characteristics
of multi-homing act in that context to design a base set of requirements
for multi-homing in v6.
> I don't think that we could reasonably use this document as
> a litmus test for IPv6 site multihoming proposals.
I think you are right; it certainly needs to be tightened up in many
areas.
> > Additionally, during failure events described above, multihoming
> > solutions must provide re-routing transparency for applications;
> > i.e. exchange of data between devices on the multi-homed network and
> > devices elsewhere on the Internet may proceed with no greater
> > interruption than transient packet loss during the re-routing event.
>
> As mentioned before, this paragraph implies a routing solution.
Yes, that's unfortunate. "re-homing event" might be a better way of
putting it.
> That aside, I think that it is trying to say that TCP sessions must
> be able to survive a failure? I'm not sure, though. The definition
> of this requirement is not rigorous enough to determine whether a
> potential solution does or does not meet it.
I wrote that paragraph, and take full blame for it :)
My intention was to be more general than listing a set of particular
protocols and the tolerance they each might have to network interruption
(e.g. tolerant of end-address change, tolerant of packet loss, etc).
With IPv4, since re-homing occurs by re-routing, and end-point addresses
survive, applications do not see the details of the underlying topology
changes (they just see a damaged network, hopefully temporarily). The
intent of that paragraph was again to promote IPv4 characteristics from
the application's point of view as a base requirement for a v6 solution.
> I believe that we explicitly want to state that an IPv6 site
> multihoming solution must allow TCP connections to survive when
> a link to the IPv6 Internet goes down, at long as at least one of
> the site's links to the IPv6 Internet remains up. This
> functionality can require changes to the IPv6 host stack.
I am not convinced that our requirement should really be defined in
terms of TCP.
> We also need to state that existing IPv6 implementations should
> be able to establish new connections, and Brian stated so well.
Yes. That is an important point.
I have commented on your other points, below; however, the basic
answer to "where is the requirement here?" in all cases is encapsulated
in the point I mentioned earlier, that we should provide the
functionality currently available in v4 multi-homing if we expect a
new multi-homing architecture to be accepted by operators. This is the
key point to debate, I think; the points below are really just
illustrations of the v4 functionality.
> >3.2 Load Sharing
> >
> > Load sharing is distributing traffic across multiple links. Reasons
> > for load sharing include but are not limited to:
> >
> > o Performance,
> >
> > o Cost, and
> >
> > o Availability of Infrastructure.
>
> This section contains no requirements. Are there any requirements that
> follow from this section? Are we requiring that an IPv6 site multihoming
> solution provide mechanisms for load sharing when more than one link is
> "live"? Or just that it not interfere with existing mechanisms? If
> the latter, which mechanisms should it fail to interfere with?
>
> I think that we should state that an IPv6 site multi-homing solution
> must not interfere with existing load balancing solutions, such as ??
Yes, that's a better way of putting it. "There are expectations that
multi-homing will allow load-sharing to happen, and we had better not
destroy those expectations if we expect people to multi-home in a new
way".
> >3.3 Performance
> >
> > One of the reasons for multihoming with two providers is poor
> > connectivity between them. For example, customer C is buying transit
> > from ISP A, and there is long term congestion between ISP A and ISP
> > B. To improve connectivity to ISP B, customer C buys transit from
> > ISB B, thus bypassing the congestion and improving the performance
> > between C and ISP A.
> >
> > Some operators have requirements to provide different grades of
> > connectivity to customers based on network reach, and achieve this
> > objective by grouping customers of similar service grades together,
> > and advertising their networks over separate transit circuits. The
> > result is multihoming for the purpose of transit capacity
> > segregation.
>
> Another good reason to multihome, I guess, but there aren't any requirements
> in this section either. Are you implying a requirement that an IPv6
> site multi-homing solution provide a mechanism for "transit capacity
> segregation", or only that it will not interfere with existing mechanisms?
> If the latter, which mechanisms? I don't really understand this section
> very well -- is the differentiation happening within the site, or
> within the ISP?
Suppose I have two sets of customers -- one premium set, who pay high
fees, and one basic set, who pay me low fees. I wish to differentiate
between the service they each enjoy such that the premium customers
get better performance.
Traffic characteristics between the internet and all customers in
this example is skewed such that inbound (towards the customer)
is much higher than outbound (away from the customer).
I obtain two transit circuits. Over one transit circuit, I advertise
just the premium customers' networks; over the other circuit I
advertise the customers' networks.
I size each circuit according to the demand presented by the network,
and the performance expectations of each customer set (i.e. the
"premium" transit circuit is proportionally bigger than the "basic"
transit circuit).
Again, this happens today, and we had better not break it. There are
ISPs who have based their entire business model around being able to
do this.
> >3.4 Cost
> >
> > A provider may choose to multihome for financial reasons. For
> > example, customer C homed to ISP A may wish to shift traffic of a
> > certain class or application, NNTP, for example, to ISP B because
> > ISP B charges less for traffic. Any future multihoming proposals
> > must provide support for multihoming for financial reasons.
>
> The last sentence would appear to be a requirement, but it doesn't say
> what the requirement actually is... Would a multihoming proposal need
> to include a mechanism for shifting specific traffic between ISPs when
> more than one is available?
Yes, I believe so.
> Or, just not interfere.
>
> Also, when one connection goes down, does the multihoming solution
> need to provide some way for the site admin to configure whether the
> NNTP traffic (for example) would be re-routed through another
> provider or dropped on the floor? The customer might prefer that
> NNTP sessions fail, rather than paying the higher rate.
That can be done today, as long as you can segregate your non-critical
services (news servers, freebie accounts) into a network which can be
advertised separately (or not, in the event of a failure, as you
suggest).
> >3.5 Availability of Infrastructure
> >
> > Sometimes it is not possible to increase transit capacity to a
> > single provider, because that provider does not have sufficient
> > spare capacity to sell. In this case a solution is to acquire
> > additional transit capacity through a different provider. This
> > scenario is common in bandwidth-starved stubs of the network where,
> > for example, transit demand outpaces under-sea cable deployment.
>
> I asked my questions about this one before... So, what should an
> IPv6 multihoming solution do about this? Is this a requirement for
> some sort of configurability? Or what?
This is another motivation for load sharing.
> >3.6 Simplicity and Scalability
> >
> > As any proposed multihoming solution must be deployed in real
> > networks with real customers, simplicity is paramount. The current
> > multihoming solution, despite its drawbacks, is quite
> > straightforward to deploy and maintain.
>
> Does this paragraph mean to state that a new mechanism must be
> no harder to deploy and maintain than an existing mechanism? Or
> is this paragraph proposing an heuristic to select between
> proposals that meet all of the other requirements. If the former,
> it needs definition. If the latter, it should be in a different
> section.
>
> I think that we have discussed several heuristics for a good
> design that could be placed in a separate section:
>
> - Simplicity (as above).
> - Minimal impact on existing host implementations.
> - Ability to converge on a new information quickly.
> - Others?
Good idea.
> > Unlike the current solution, however, new solutions must provide for
> > scaling of the number of multihomed sites many orders of magnitude
> > larger than are currently deployed. The limitations for scalability
> > with the existing solution and current protocols are outlined in
> > Section 4.
>
> This is a good requirement, but should probably be more rigorously
> defined.
>
> I would also add another major requirement:
>
> Compatibility
>
> The current IPv4 multihoming mechanisms have been widely deployed
> because they are compatible with existing IPv4 networking
> implementations and practices. (Compatible: The implementation
> or practice works at least as well in the presence of multihoming
> as it does in a singly-homed site).
>
> IPv6 site multi-homing must be compatible with (see definition
> above):
>
> Existing IPv6 host implementations, including
> - IPv6 host autoconfiguration
> - IPv6 over PPP?
> - DHCPv6 configuration?
> IPv6 Transition Mechanisms
> - Bump-in-the-Stack
> - Bump-in-the-API
> - NAT-PT
> - Tunneling mechanisms?
> - Others?
> Existing host-based transport layers:
> - TCP, UDP, etc.
> - SCTP?
> - Others?
> Existing IPv6 Routing Protocols?
>
> I don't have all of the information at my fingertips to generate
> this list in real-time, but I'd be happy to work with someone to
> put it together.
>
> We have spent 10 years (well, I've only spent 6 years, myself)
> developing IPv6, and I think that there are parts of it that we
> want to preserve. We need an IPv6 site mutlihoming solution, and
> we are willing to make routing and limited host changes to get one,
> but I think that there are things that we are not willing to
> sacrifice. Let's list them!
I have spent zero time developing IPv6 :) I do have experience of how
and why organisations currently multi-home in the v4 world, however.
The compatability requirement looks like an important one. Send code.
> Again, no offense is meant, and I hope that none will be taken.
> But, I think it is important that we do a good job of rigorously
> defining our requirements before we begin to evaluate solutions.
I agree! Thanks for all your comments.
Joe