Re: your mail

["Jon (Taz) Mischo" <taz@tazlore.com>]

On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote:

> Fair queuing says: If there are n customers, there is a scheduling
> algorithm that guarantees that each of these customer's traffic has a fair
> share of the link bandwidht. This means, an ISP can choose to set the
> weights for its n customers such that:
> a) each customer can inject no more than
> 1/n of the traffic into the outgoing link, no matter how much they try
> to pump via their respective access links, and
> b) the packet losses and delays suffered due to an increased load
> on one customer are restricted to that customer *alone*, and are
> *completely* invisible to the other customers---the other customers'
> traffic does not experience *any* increased delay or packet loss.

I know how fair queueing works.  What I'm saying is that if I'm
multihoming via tunnels like this, fair queuing is not what I'm paying
for...I'm paying for QoS beyond that.  Besides, FQ does NOT come into play
here.  If the router where the access link was is where you're tunneling
from, you may or may not be subject to fair queuing, just as your link
was.  However, through the rest of the network, fair queuing does not come
into play, as it would really mess things up.  Or, if it does, you're
still changing the characteristics of the network traffic.

The point here is traffic patterns.  You're arguing when I'm trying to
make it clear that you're missing the point.

> I don't think ISP2 and ISP3 have to *directly* peer---it is enough for
> each to be reachable from the other. The ISPs could be regional providers
> with no direct peering, while their parents can peer at some internation
> point, for example.

I can tell you this: if ISP2 and ISP3 aren't directly peered, they're
going to be paying for someone else's traffic.  So you're saying that to
multihome like this, if ISP2 and ISP3 aren't peers, the customer is going
to have to pay for 4 links instead of 2, because those two ISPs are going
to be buying extra transit to carry this.  You're not winning this
argument.

> Agreed, I made a mistake---ISP3 can figure out that the traffic originated
> in ISP2's network. But, then again, in the context of fair queuing above,
> I don't see why it is illegal for ISP2 to originate traffic for the site's
> border router (in fact, some of the traffic may have been originating from
> ISP2's customers).

Ummm...I'm sorry, but do you have operational engineering experience?  I
don't know a whole lot of people who do that would feel comfortable with
someone else causing a change in their provisioning and routing, even if
it was temporary, especially if they didn't trust those people.  I just
can't see it happening.

> > Again, they have to be peers or have a mutual trust relationship.  We're
> > right back to square one.  This can't work unless they cooperate.
> 
> One end of the tunnel terminates at the site's border router, the other
> end at one of ISP2's routers. ISP3 can choose not to participate in the
> tunnel creation, and can enforce bandwidth restrictions using FQ on this
> traffic as well.

In this case, though, you're still doing bad things.  See, now you're
saying that the tunnel can cause legitimate packets for that ingress point
to be dropped.  Furthermore, you've just taken control of any of that from
the router the tunnel is terminating on, and moved it upstream.  Do you
see what I'm getting at?  Now you're dropping the packets in the tunnel
AND the legitimate packets bound for that ingress point that DON'T have
problems.

You're making this assumption that everyone has dormant circuits laying
around with no traffic on them.  This is NOT the case.

> > Again, NO.  If you can't afford the bandwidth to do this, don't do it,
> > cause as a customer, I won't tolerate high packet loss.  Why bother at
> > that point?
> 
> If one of a site's two links breakdown, I don't see how the site can
> not expect to see performance degradation at all. Of course, we
> require, and enforce, that no other site's are affected by this
> degradation using FQ. Finally, there is no need for the tunnels to be

Ummmm...why are you so obsessed with fair queuing?  It is not God, I
assure you.  It won't be upset if you see that it has flaws.  If you
multihome a site properly and smartly, and have adequate bandwidth, you
don't have to take any significant performance hit.  However, if you do it
this way, you're breaking provisioning for everyone, cost everyone a lot
of money, and making it more and more unattractive.

When I first read this I liked the idea...you've made me see how ugly this
idea is, though.

> dynamically configured, although that facility will allow them to
> possibly withstand additional failures. Also, the tunnel is between
> ISP2 and the site, and does not need to have anything to do with ISP3
> at all.

Read my comments above.  I don't think you understand the issues involved
in doing this.  You're looking at certain pieces of the puzzle, but not
the big picture.  There has GOT to be a better way.

-Taz

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989