Subject: RE: Congestion avoidance Re: [Ieprep] draft-ietf-ieprep-framework -02.txt

From: "Nguyen, An" <[email-masked]>
Date: Wed, 6 Nov 2002 14:07:42 -0500

Bill,

As of now there are no automated ways of increasing bandwidth to combat
congestions. But capabilities to do it might be available later. 

I still have concerns with emergency traffic when congestions occur on
access and egress nodes if it does not get any preferential treatment. I
agree with you that IP voice packets are small compared to others. But when
it comes to congestions small and/or large packets have to get in line to go
through queue(s). If the queue is full, I am afraid that emergency traffic
packets would be dropped. Another (maybe related) issue is that when large
packets (e.g., data, streaming, etc.) are ahead of voice packets in the
queues, then the QoS (Jitters, delays) for voice would be affected because
it would take longer to process large packets.

Regards,

An

-----Original Message-----
From: Bill Woodcock [mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 12:51 PM
To: Nguyen, An
Cc: [email-masked]
Subject: RE: Congestion avoidance Re: [Ieprep]
draft-ietf-ieprep-framework -02.txt

      On Fri, 1 Nov 2002, Nguyen, An wrote:
    > Are you saying if there is any problem with the access node, the
network
    > operators will solve the problem by throwing more equipment at it? The
    > question is that how dynamic is that bandwidth increasing in response
to
    > congestions?

Not exactly...  If there's a congestion problem within a customer network,
ISPs are not able to resolve that problem.  ISPs cannot autonomously
increase the capacity of a customer tail-circuit, since the customer-owned
CPE must be simultaneously upgraded, nor can ISPs implement QoS on
customer-owned devices, even if it were the case that QoS were beneficial.

Fortunately, none of that is an issue, since the demands which VoIP places
on the network are so small.

                                -Bill

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

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 6 Nov 2002 16:53:25 -0500

> congestions. But capabilities to do it might be available later.

I think Bill wasn't talking about automation, but about the fact that
the size of the access link from ISP to customer is controlled by the
customer's willingness to pay for a larger pipe.  That is, if customer
packets are congested on the access link then it can only be true
because the customer *chose* not to have a faster link (or the ISP
doesn't offer a faster link, which is pretty uncommon -- and might
mean it is time to change ISPs).

> it would take longer to process large packets.

Bill's other point is that even if the ISP were to configure (some kind
of) QoS on its side of the access link, it won't help packets 
originating
on the customer side because the congestion/buffer issue would live in
the customer-premise router not the ISP router.  It varies whether the
ISP manages the CPE router, but in Bill's text he implies that the 
customer
might be managing their own CPE router (so the ISP could not enable QoS
on that box or otherwise alter its configuration).

Finally, Bill seems to be saying that in his operational experience, 
such
congestion either does not occur or it occurs in so modest a manner that
it does not adversely affect VoIP traffic.  It might be helpful to 
understand
more about the configuration of Bill's VoIP application-layer gorp,
since he seems to have a setup that works reasonably well.

The experience of former colleagues running voice/IP/HF Radio (which is
often congested because HF radio is very low bandwidth) was that if one
had the right vocoder, one didn't have any problems.  If one did not 
have
the right vocoder, nothing could fix the problems.  I'm not a vocoder
expert, so can't comment myself on which ones worked better/worse.

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 8 Nov 2002 00:26:32 -0800 (PST)

> congestions. But capabilities to do it might be available later.

This has been tried in the past, but with limited success...  The problem
is that there is a high cost in the capacity of the local loop and CPE,
and even if all of the upgrade procedure can be automated, no customer
will willingly pay for the unused capacity of the headroom in the local
loop.

For example, let's say that a customer has an average of 300kbps of
traffic, and peaks at about a megabit.  They're obviously going to buy a
single T1.  What's their upgrade path?  Normally it would be a second T1,
generally to a different provider, if possible.  But hypothetically, you
could have provisioned that T1 as a channel of a DS3, and when they needed
more bandwidth (perhaps their average utilization had exceeded a megabit
for ten days out of the prior fourteen, or something like that) you could
have dynamically negotiated the turn-up of a second channel.

The problem is that the customer would have to be paying for the entire
DS3, and amortizing a DS3-capable router, in order for that instantanaity
to be possible.  That's a twenty-fold increase in both the one-time and
recurring costs.  All being paid for capacity which is by its very
definition unused.

Outside of the DoD, there aren't too many customers who snap up deals like
that.  :-)

    > When it comes to congestions small and/or large packets have to get
    > in line to go through queue(s). If the queue is full, I am afraid
    > that emergency traffic packets would be dropped.

Perhaps you might acquaint yourself with the infrequency with which this
happens, and thereby reassure yourself in this regard.

    > Another (maybe related) issue is that when large packets (e.g.,
    > data, streaming, etc.) are ahead of voice packets in the queues,
    > then the QoS (Jitters, delays) for voice would be affected because

This is quite true as well...  There's no argument over whether jitter
exists in the network, just as there's no argument over whether congestion
exists in the network.  What operators are telling you is that it's so
far from being a problem as to be utterly unworth anyone's attention, much
less that of smart people who could be using their intelligence to solve
problems.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Nov 2002 09:45:45 -0500

> will willingly pay for the unused capacity of the headroom in the local

The exception to this is when one has fibre-to-the-{home,office}.
I'm aware of MAN operators in a few parts of the US, many parts
of Sweden, and many parts of Japan, who are using GigE as the
last mile.  The operator purchases equipment capable of performing
traffic shaping on the GigE interface that connects to the customer,
then sells "bandwidth on demand".  The customer can increase the
provisioned capacity up to the physical limit via a web page
(and is billed for the time * provisioned-capacity).

Obviously there is a cap at the max deployed link bandwidth,
but deploying GigE is not a lot more expensive than 100 Mbps
Ethernet once the fibre is in place.  Right now, 10 GigE is
a whole lot more expensive than GigE (mainly due to cost of
optical components), but even that should improve with time.

FTTH/FTTO is not that common in the US today.  It is not uncommon
in some other countries.  It is very uncommon in most countries.
So it is not a general solution to the issue, but rather an
interesting special case.

Ran