Re: A tunneling proposal

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

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

> On Tue, 17 Jul 2001, Ramakrishna Gummadi wrote:
>
> > > Furthermore, it is more complex for the customer and providers. I
can
> > easily
> > > envision scenarios where one provider will refuse to create a tunnel
to
> > > certain other providers based on politics or even internal lack of
> > capacity.
> >
> > Internal lack of capacity seems a valid technical reason; this should
be
> > addressed in the SLA between the provider and the subscriber. Note,
> > however, that we
> > are not asking one provider to carry traffic, tunneled or otherwise,
that
> > *exceeds* the subscriber connectivity bandwidth. The amount of traffic
> > would in no (significant) way be altered if the multihomed subscriber
> > became singlehomed, and received/sent all the traffic along the
original
> > line.
>
> 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.

Like I said before, how is this case different than the one where the
subscriber cancels the service from the other provider, due to which the
load on the first provider would be increased anyway? Remember that we
are not even requiring the first provider to participate in the tunnel
setup...

> > > Customers will be forced to multihome only with providers who have
> > agreed to
> > > work together;
> >
> > This is a difficult question for me to answer. But what kinds of
> > arrangements are drawn up for carrying multicast traffic, where these
> > kinds of political problems are potentially more severe?
>
> Multicast traffic is a whole other ball of wax.
>
> > Also, I am not sure if this wg should outlaw any proposals based on
> > political reasons alone...If so, we probably should have the rough
> > guidelines rewritten down in the requirements document.
>
> This isn't based on political reasons, but feasibility reasons, and we
> don't outlaw, we just decide what we predict will be best.

Well, there is an easy, although socially questionable, answer to
that---use IPSec on the tunnel so that the provider can not find out
anything about the payload...

Once again, I don't see how doing this, while suboptimal and probably
unfair, is going to violate the contract between the provider and the
subscriber. All the provider would see is a surge in the traffic for the
subscriber, and he will probably use the usual tools (fair queuing,
increased latency and drop rate, etc. ) to deal with them...

thanks,
ramki