Re: your mail

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

> On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote:
>
> > Which is why tools such as fair queuing and fair dropping exist--they give
> > you the perfect isolation and bandwidth management guarantees. And I think
> > they are present on most cisco's already on most high speed interfaces..
>
> I'm sorry, but as a customer, I wouldn't want my traffic dropped because
> someone else's OC-3 went down.


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.

Think of it FQ's role as being similar to a  virtual memory manager in
an Operating system. The customers would correspond to processes, and
the memory manager guarantees that no process can affect any other
processes in terms of access to memory pages, crashing via sigment
faulting, etc...

> > We are not requiring anybody to accept traffic from those they don't peer
> > with or have subscriber-provider relationships (and we don't require any
> > extra physical links):
>
> Yes, you ARE.  For it to work right, that's EXACTLY what you have to
> require.
>
> > D served by ISP2 and ISP3 that don't peer:
> >
> > Scenario A: (normal operation):
> > S-ISP1-Internet-ISP2-D.
> >
> > Scenario B: (failure-mode operation):
> > S-ISP1-Internet-ISP2-Internet-ISP3-D.
>
> ISP2 and 3 would HAVE to peer to do this.  I'm sorry, but as a provider I
> wouldn't want just anybody to be capable of building a tunnel.  Any
> potential tunnels of this sort I'd want to be pre-configured so there
> couldn't be abuse.  But who's to say it still won't be abused
> anyway?  What if ISP2 brings up the tunnel because of a low bandwidth
> situation?  As ISP3, I didn't sign up for that.

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.

>
> > How is B different than A, and how does ISP3 know the tunneled traffic
> > originated in ISP2 (without looking at the internals of the packet, which
> > can be forbidden by IPSec anyway)?
>
> You're missing the point.  ISP3 can see the tunnel originated at
> ISP2.  The tunnel would be from ISP2's router to ISP3's router.  Hard to
> miss.  And if I don't trust ISP2 as ISP3, I'm sure as hell not going to
> let them create a pipe and pour packets into my network.
>
> > If ISP2 and ISP3 cooperatate, the system as a whole can achieve a more
> > optimal operation point than if they don't. In both cases, however, it
> > continues to work.

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

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

 >
> > As an aside, should not one be first concerned that the Internet expects
> > end-to-end congestion control out of hosts who can directly collapse an
> > ISP if they are greedy? Because people got concerned about such problems,
> > they invented fair queuing, etc., that allow the ISP full control over how
> > to fairly manage traffic. These tools can be used in this scenario as
> > well, if required.
>
> 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 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.

thanks,
ramki