Subject: Re: [RAM] be afraid...

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 Feb 2007 09:48:39 +0100

On 31-jan-2007, at 22:56, Andrew Lange wrote:

>> For instance, for VoIP it's important to give VoIP traffic a  
>> higher priority than some other types of traffic.

> This point is often made, but without too much consideration as to  
> where prioritization is useful.  Priority schemes are useful ONLY  
> when there is contention for resources on the line.

Very true.

> A network is usually designed to handle peak loads without  
> congesting (mother's day load in the US voice networks), after all  
> a carrier does not want to turn away business if they don't have to  
> do so.

That's nice in the phone world where every call makes you money, but  
not so much in the IP world where revenue and traffic aren't related  
for large classes of customers. (I.e., a residential user pays the  
same whether they only check their email once a day or run BitTorrent  
24/7.)

Also, many kinds of IP traffic take as much bandwidth as they can.  
For those applications, there must be a bottleneck or other limiting  
factor somewhere as long as they're transferring less than a gigabyte  
per round trip.

First Law of Van Beijnum: there is always a bottleneck.

In more concrete terms: the link from a customer to an ISP is very  
often a bottleneck, even if only intermittently. Bottlenecks inside  
ISP networks and in the interconnection between different ISPs are  
relatively rare but happen.

> In the most usual state the network will have resources available  
> in most places.

Very reassuring.  :-)

>> For outgoing traffic this is easy to do by looking at port numbers  
>> or diffserv code points, but for incoming traffic that's much  
>> harder: essentially, you need to tell an ISP how to deal with  
>> different kinds of traffic in a great amount of detail.

> The issue here is not a technical one, it is an issue of trust.

No, it's not a question of trust. If you trust your ISP enough to  
give them your money then that part is taken care of. The issue is  
one of transferring and maintaining detailed state. ISPs don't like  
this because it makes their equipment more expensive and it requires  
complex protocols (intserv anyone?).

> Does your operator trust you to mark your VoIP packets correctly,  
> and in a way meaningful to that operator?  If your operator is like  
> those I have experience with, then the answer is no.

If I want to do this for incoming packets, that means I must push out  
filter rules to my ISP so they can color the packets correctly before  
they hit a bottleneck. This isn't easy to do.

For outgoing packets, I don't necessarily see a problem. If I were an  
ISP, I would probably like a model with three traffic classes:

- bulk: all you can eat, but I'll drop packets when and where I want
- best effort: I won't arbitrarily drop these packets, no metering  
but fair use policy: if you do too much traffic of this type I may  
bump down your priority to bulk
- high priority: gets preferential treatment but billed per megabyte

This way, users can decide how important packets are, and I take my  
cues from them so no distrust is required.

>> Maybe others have a better view of this, but it's completely  
>> unclear to me how real time traffic over the internet is going to  
>> play out in the future.

> There will be a network of bilateral peering arrangements between  
> networks

Bilateral doesn't scale.

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: [email-masked]
Date: Thu, 1 Feb 2007 11:40:33 +0100

Iljitsch:

See my comments inline.

Regards,

Iljitsch van Beijnum <[email-masked]> escribió el 01/02/2007 09:48:39:
> (deleted)

I think it's a question of service definition: an ISP could
provide a data service of up to 2Mb/s with a maximum of
128Kb/s of priority traffic. This doesn't require a complex
configuration but only to configure the traffic conditioning
for the offered data service.

Then, when you exchange priority data with another user the
quality of the service that you experience will depend on
whether the other user has paid its ISP for a data service
with a priority bandwidth or not.

> they hit a bottleneck. This isn't easy to do.

If the other user has paid for a data service as the one
I mentioned before, there is no need for you to push any
filter rule because your ISP will deliver priority
traffic according to your contract.

> > There will be a network of bilateral peering arrangements between

I don't see why the kind of bilateral data service contracts
that I explained above would not scale.

Regards,
Juanjo

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 1 Feb 2007 05:16:13 -0800

On Jan 31, 2007, at 2:48 PM, Roland Bless wrote:

> So I know at least one provider that introduced prioritized
> VoIP traffic in order to protect it against congestion
> caused from "normal" traffic, e.g. caused during DDoS flooding
> attacks (congestion may be caused in the direction
> towards access networks, i.e. when descending the bandwidth
> hierarchy). This makes sense to me...

Yes, this is pretty much the only application of QoS to flooding  
attacks which isn't self-defeating, assuming you've fixed endpoints  
to deal with, assuming you've implemented antispoofing, and assuming  
the systems for which you've reserved said bandwidth aren't  
themselves compromised.  If all of the above aren't true, then the  
QoS can be self-defeating as the bad 'reserved' traffic chokes out  
the good.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

           The telephone demands complete participation.

                       -- Marshall McLuhan