Re: your mail

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

On Wed, 18 Jul 2001, Jon (Taz) Mischo wrote:

> On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote:
>
> > On Wed, 18 Jul 2001, Jon (Taz) Mischo wrote:
> >
> > > Yes you are.  You are asking a provider to take all traffic destined for a
> > > specific egress point and re-route it through their network to a peering
> > > point.  You are *DOUBLING* the traffic they are carrying for that
> > > subscriber.
> >
> > I am sorry, but I may be missing something here---true, the traffic is
> > doubled, but how to deal with the doubled traffic should be a decision
> > between the provider and the subscriber according to the SLA. Increased
> > load could cause higher packet loss, greater latency, etc. Indeed, if the
> > provider were using fair queuing, this would what happen, without
> > affecting any other customers of the provider.
>
> The last sentence is what's wrong.  A single router does not a backbone
> make.  You seem to forget that a tunnel is not a wormhole.  Packets don't
> enter a tunnel in one router and magically appear at the other end.  The
> still traverse the network, following a different path than the one they
> would normally, messing up a LOT.

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

> > that---use IPSec on the tunnel so that the provider can not find out
> > anything about the payload...
>
> I fail to see how IPsec is going to get you around the problem.  The
> problem isn't, "Oh, I see that's tunnelled data, I'll drop it!"  It is, "I
> see that packet is coming from someone I don't peer with.  I'll drop it."
>
> The main problem here is that some providers won't peer with others.  I
> can guarantee that those same two providers won't configure their routers
> to automatically build tunnels to each other.

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

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.

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

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.

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.

Finally, I don't see how any other multihoming scenario (end-to-end
solutions included) that has to
provide failure protection can behave significantly better---after all,
the goal is to redistribute the load onto working links, with a possible
degradation in performance.

thanks,
ramki