[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: your mail
Hi,
>
> 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.
First of all, the site uses normal links if there are no problems. It only
switches to tunnels when there is are failures. I don't think it is fair
to say we are "multihoming via tunnels" in all contexts.
I may be missing something, but, as far as I know, FQ can provide the
strongest possible QoS guarantees as far as flow isolation, bandwidth
allocation, delay, and loss are concerned. It is not widely deployed so
far because of implementation complexities (lots of approximations exist),
and is currently being deployed at least in the sprint backbone.
I am interested in knowing what additional QoS you have on your mind.
> 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.
If an ISP guards its exits/entrances, it does not have to worry about
whether it changes the internal traffic patterns because FQ guarantees it
does not.
> 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.
Let us pick the following concrete example, count the extra packets, and
figure out who is paying the extra cost for whose failures:
D
|
|
/--+---\
// \\
| Internet |
\\ /
L7 / \------/ \ L6
// \\
/ \
// \
+--/---+ L1 +--\---+
| ISP4+--------------+ ISP3 |
| | | |
+--+---+ +--+---+
| |
L2 | | L3
| |
| +---+--+
+--+---+ | ISP2|
| ISP1 | | |
| | +---/--+
+------*\ //
\\ //
L4 \\ // L5
\\ //
+--\*--+
| |
| Site |
+---+--+
|
|
S
Suppose the multihomed site gets connectivity from regional ISPs, ISP1 and
ISP2 who
do not trust and peer with each other, while their parents, ISP4 and ISP3,
peer using link L1. The site has a host S that is talking to a destination
D on the Internet using the path: D-(Internet)-L6-ISP3-L3-ISP2-L5-S.
Suppose there is a major problem within ISP2, and link L5 goes down.
However, assume ISP2 is still partially functional, so assume L3 continues
to work. Packets would now follow the route:
D-(Internet)-L6-ISP3-L3-ISP2-L3-ISP3-L1-ISP4-L2-ISP1-L4-S.
The number of extra packets introduced on the inter-provider links is 4
(L3, L1, L2, L4).
However, consider the perspective of ISP1 and ISP4. Theoretically, the
destination D could have used the path through them (and this would be
true in any end-to-end failover rerouting scheme as well), meaning the
flow of packets would be:
D-(Internet)-L7-ISP4-L2-ISP1-L4-S.
This means that ISP1 and ISP4 are *not* taking any additional load in the
first case versus the second case---they are not resposible for the
problem, and they don't pay *any* extra price in terms of extra
packets than they would otherwise have had to.
The extra penalty is paid by ISP2 and ISP3, but because it is fault of
ISP2, it should be willing to bear this cost both for itself and its
transit provider.
The multihomed site does not have to pay any penalty because it is not its
problem.
If ISP3 had a problem, on the other hand, it alone would have had to pay
the extra bandwidth price, and would not burden ISP2 and the site. We
should not consider sending packets via L1-ISP4-L2-ISP1 a burden because
ISP3 is, by definition, allowed to send packets via L1 to ISP4.
It would be great if you can use this scenario to make your objections.
> 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.
I don't have operational experience, but I still think this is not a case
of changing provisioning as the same could have happened in a non-failure
mode scenario where the site simply stopped using one link and diverted
the entire traffic over the other link. And, I definitely don't see this
requiring any routing changes. I am interested in seeing what
other peoples' reactions are to this.
> 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.
I am just highlighting a technique that can be used to provide
worst-case guarantees. I think it is useful in general because
it is theoretically sound, backbone carriers (like Sprint) are
beginning to deploy it in their networks, and router implementations are
appearing for highspeed interfaces (an OC-48 channel can be split up
fairly between n customers, for example). It helps in strictly enforcing
SLAs.
thanks,
ramki