Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

From: [email-masked]
Date: Tue, 3 Dec 2002 10:28:51 EST

In a message dated 12/2/2002 4:20:23 PM Eastern Standard Time, 
[email-masked] writes:

On Monday, Dec 2, 2002, at 12:54 America/Montreal, [email-masked] 
wrote:
> [MAP] I understand fully that the IP-layer is unaware of "calls" or 
> "voice packets". That wasn't the point. If some higher layer function 
> doesn't limit the setup of new calls (2. above) when it knows that 
> there are already too many being stuffed through a finite size link, 
> then the IP-layer would be overwhelmed with packets which it can't 
> handle (1. above).

[RJA] The IP-layer can be overwhelmed anyway since IP does not have any 
equivalent
to "call setup".  Even if SIP were informed (which it isn't) and had some way
to control the voice calls (which it doesn't since anyone on the Internet can
use any cooperating SIP server, not just the local one), other unrelated 
applications
like mail or ftp or http don't use SIP (and won't be using it in future).

[MAP] So this says that congestion can occur and there is no way for the 
application (SIP) to deal with it, like by restricting new call setups, so 
the IP-layer is left completely on its own to deal with it, and the only way 
it can is by discarding packets.

[RJA] Now one could use IP ToS bits to mark the packets from inside a domain 
for
the uplink router to prioritise, if the uplink router happened to have that
policy configured in it by the router's operator.  One could also put various
other policies into the router based on some combinations of (address, 
protocol, port),
if one did not want to use the IP ToS bits.  If the link is Ethernet, one 
could
use 802.1p.  If the link is something else, then one could use other 
link-specific
mechanisms (e.g. ATM has PSTN-like calls).

[MAP] I think we've agreed that packet "prioritization" of one voice packet 
before another is not feasible or a good idea, so I don't think you mean 
that. I can't imagine that handling of packets for priority calls could be 
done by putting specific addresses in the routers. (Sounds like "state" to me 
anyway.)

> [MAP] So I take that as an agreement with what I said, that in the 
> case of congestion, a lot of packets would be lost.

[RJA] No.  The number of packets lost would vary with (offered load, link 
capacity,
traffic pattern, packet memory depth on each side of the link).  In many cases
there is minimal or no congestion, because the router buffer is deep enough
to handle a trans-oceanic RTT, which in turn gives TCP or SCTP enough time
to reduce the transmission rate on existing sessions, which then leaves
enough room for the new traffic to be carried on the link.

[MAP] Your answer relates to elastic traffic, e.g., file transfers, where the 
buffer can be made as "deep" as you have memory available. The primary 
subject here is inelastic traffic (voice) in which there are relatively 
strict limits on the buffer length.

> [MAP] I'll repeat the question which I don't believe I've gotten any 
> concrete answer to: In the case above of the 10 callers from Nairobi, 
> if one of them was authorized to make emergency calls and the other 9 
> weren't, what specific standardized mechanism (not products) could be 
> used to provide the required service across the congested 384 kbit/s 
> satellite link? (The required service is that their call gets set up 
> and they can talk.) If you don't believe that 10 users would cause 
> congestion, then make it 20 or however many of the several thousand it 
> would take.
>
> I would find it hard to believe that there are no standardized 
> solutions to this. You're right, maybe there is no need for this WG, 
> but I haven't heard the solution yet.

[RJA] One could use IP ToS bits, link-specific ToS bits (802.1p in the case 
of Ethernet),
or some combination of (address/protocol/port) to tell the access router which
traffic to prefer from the site connected to that access router.  Preference 
can be
implemented using the CoS mechanism that Sprint is using, various flavours of 
which
are available from many vendors.  Whether that policy (either to obey ToS 
bits or to sort
based on the address/protocol/port) is configured into that router is a 
question
for whoever  owns/operates that access router.

If the offered load of preferred traffic exceeds link capacity, then packets
still will be dropped.

[MAP] Our goal is to point to a specific set of standards (or proposed) to 
describe how to provide preferential treatment. Can you point me to some 
specific ones? Os is it naive to think that it is as simple as referrencing 
EF or some such RFC?

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 3 Dec 2002 13:20:08 -0500

On Tuesday, Dec 3, 2002, at 10:28 America/Montreal, [email-masked] 
wrote:
> [MAP] So this says that congestion can occur and there is no way for 
> the application (SIP) to deal with it, like by restricting new call 
> setups, so the IP-layer is left completely on its own to deal with it, 
> and the only way it can is by discarding packets.

Hmm.  Almost, but not quite right.  The application end-points, that is 
the
application software on either end of the actual VoIP session, *can* 
and *do*
know that they are experiencing X% packet loss or that jitter is 
increasing
from W to Z, or that latency has increased from A to B, or any 
combination
of the above.  Having that knowledge, which is in the VoIP endpoints 
not in the
SIP server, the endpoints could react in any of several ways.  An 
example
that seems most obvious to me would be to switch from G.711 to a more 
robust
CODEC that consumes less bandwidth (e.g. some form of CELP).

Now I'm not an application-layer guy very often, so I don't know the 
details
of SIP or the details of how the voice is being sent (presumably over 
RTP/UDP/IP
somehow).  However, it is clear that protocol engineering could be done 
to add
this kind of capability (e.g. codec negotiation) if folks in that part 
of the
application community cared to do it.

> [RJA] Now one could use IP ToS bits to mark the packets from inside a 
> domain for
> if one did not want to use the IP ToS bits.  If the link is Ethernet, 
> one could
> [MAP] I think we've agreed that packet "prioritization" of one voice 
> packet before another is not feasible or a good idea, so I don't think 
> you mean that. I can't imagine that handling of packets for priority 
> calls could be done by putting specific addresses in the routers. 
> (Sounds like "state" to me anyway.)

In the text from me that you've quoted just above, one concept could be 
that
IEprep traffic (whether VoIP or other) *could* be marked using IP ToS 
bits
(either at origin, by first-hop router inside the domain, or by some 
other
router inside the domain) and (subject to local network operator's 
policy)
the IP ToS bits in each packet could be examined by the domain's uplink 
router
to give IEprep packets lower drop probability using some 
(policy-dependent)
queuing configuration inside the router (e.g. Sprint's CoS stuff, which
multiple router vendors support in COTS product today).

An advantage to this approach over a NSIS/RSVP-like approach is that one
has a relatively small amount of total state for the QoS, pre-configured
into the router, rather than adding router state for each additional
IP-layer flow that happens to be "preferred".  Basically it adds a small
amount of constant state to handle an unlimited number of concurrent 
flows,
rather than adding state for each additional flow that might be present.
The issue with state in routers is always how much one has.  This is an 
approach
to keep the total state related to QoS small regardless of traffic load 
or mix.

> [RJA] No.  The number of packets lost would vary with (offered load, 
> link capacity,
> [MAP] Your answer relates to elastic traffic, e.g., file transfers, 
> where the buffer can be made as "deep" as you have memory available. 
> The primary subject here is inelastic traffic (voice) in which there 
> are relatively strict limits on the buffer length.

Routers have no idea whether a packet is voice or file transfer.  The 
amount
of packet memory in the router is a property of what humans have 
physically
inserted.  So my comment quoted above is independent of what kind of 
application
happens to be running on the packets being buffered.

Variable latency is a fact of life in any packet network.  All 
Internet-based
applications, including voice, have to be reasonably tolerant of some 
amount
of jitter or they won't work at all.

An IAB comment by Sally Floyd at the IEprep meeting in Atlanta bears 
repeating.
Because the current VoIP stuff does not include congestion avoidance, 
the tendency
will be for the VoIP traffic to "crowd out" the congestion avoiding 
traffic
(e.g. anything running over TCP or SCTP).  This is a major problem.  
Somehow
the community needs to add congestion avoidance into the VoIP 
applications
protocols.

> [MAP] Our goal is to point to a specific set of standards (or 
> proposed) to describe how to provide preferential treatment. Can you 
> point me to some specific ones? Os is it naive to think that it is as 
> simple as referrencing EF or some such RFC?

If one wants to talk about standards-track QoS mechanisms, there are a 
wide range of
RFCs to choose from.  They each have different properties.  Each is 
suited for somewhat
different operating conditions.  There is no "one size fits all" RFC.

It is, however, important to keep in mind that IETF avoids recommending 
or dictating
that an operator deploy particular standards.  Whether an ISP chooses 
to deploy
anything (e.g. OSPF routing protocol vs IS-IS routing protocol vs 
some-proprietary
routing protocol) is *entirely* a decision of that ISP.

For many reasons, including some discussed by the IAB in RFC-2990, 
Sections 3.10
through 3.12, the deployment of inter-domain QoS is impractical and 
improbable
anytime in the near future.  So if one wants to offer a robust service 
over a
multi-domain environment, one would be well advised to focus on 
ensuring that
one uses robust applications (e.g. very thoughtful codec selection, not 
limited
just to ITU specs, in the case of VoIP applications).

Ran

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

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 4 Dec 2002 09:38:45 -0800

Hi,

Adding a bit of application-specific detail to Ran's comments...

On Tuesday, December 3, 2002, at 10:20 AM, RJ Atkinson wrote:
>> setups, so the IP-layer is left completely on its own to deal with 
>> it, and the only way it can is by discarding packets.
>
> Hmm.  Almost, but not quite right.  The application end-points, that 
> is the

A very good choice here is iLBC (Internet Low Bitrate Codec), a 
royalty-free low-bitrate codec designed for use on the Internet, and 
therefore very tolerant of loss, jitter, and delay.

> somehow).  However, it is clear that protocol engineering could be 
> done to add

It's already there.

>> other policies into the router based on some combinations of 
>> (address, protocol, port),
>> packet before another is not feasible or a good idea, so I don't 
>> think you mean that. I can't imagine that handling of packets for 
>> priority calls could be done by putting specific addresses in the 
>> routers. (Sounds like "state" to me anyway.)
>
> In the text from me that you've quoted just above, one concept could 
> be that
> the IP ToS bits in each packet could be examined by the domain's 
> uplink router
> The issue with state in routers is always how much one has.  This is 
> an approach
> to keep the total state related to QoS small regardless of traffic 
> load or mix.

> the community needs to add congestion avoidance into the VoIP 

Actually there is work now to do this. The goal is to run RTP and RTCP 
over DCCP (Datagram Congestion Control Protocol).

thanks,
-rohan

> It is, however, important to keep in mind that IETF avoids 
> recommending or dictating
> one uses robust applications (e.g. very thoughtful codec selection, 
> not limited

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Dec 2002 13:32:13 -0500

> therefore very tolerant of loss, jitter, and delay.

Thanks much.  Is there an I-D or RFC describing iLBC ?

>> this kind of capability (e.g. codec negotiation) if folks in that 
>> part of the

Thanks again.

Which RFC(s) is this documented in ?
And are there special phrases that one should grep for to find the 
right section ?

> Actually there is work now to do this. The goal is to run
> RTP and RTCP over DCCP (Datagram Congestion Control Protocol).

Once again thanks.
And same question, is there an I-D or RFC on this work in progress ?

Ran
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 04 Dec 2002 14:03:23 -0500

>Thanks much.  Is there an I-D or RFC describing iLBC ?

draft-ietf-avt-rtp-ilbc-00.txt
draft-ietf-avt-ilbc-codec-00.txt

>And are there special phrases that one should grep for to find the 

RFCs 3261 and 3264, amongst others.

>And same question, is there an I-D or RFC on this work in progress ?

Very much work in progress. The DCCP working group has a number of drafts,
but I don't think there is an I-D on RTP over DCCP yet. It's not clear, to
me, if the services DCCP provides are suitable for use in VoIP telephony
due to the limited scope for adaptation in common voice codecs (it is
clearly useful for streaming video).

Colin

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 4 Dec 2002 14:49:15 -0800

> Thanks much.  Is there an I-D or RFC describing iLBC ?

draft-ietf-avt-ilbc-codec-00.txt  describes the codec itself
draft-ietf-avt-rtp-ilbc-00.txt describes its use in RTP (the RTP 
payload format)

>>> of SIP or the details of how the voice is being sent (presumably 
>>> over RTP/UDP/IP

RFC3264 describes how this negotiation works in SIP.  In general, SDP 
(draft-ietf-mmusic-sdp-new-11.txt) describes how you can use its 
semantics to facilitate negotiation

almost the whole of both documents touch negotiation, but sections 5.1, 
6.1, 9, and 10.2 or RFC 3264 are especially relevant (and also pretty 
short).

>>> Because the current VoIP stuff does not include congestion 
>>> avoidance, the tendency

the charter is a good start.  it explicitly calls out the relationship 
with RTP which is nice.
http://www.ietf.org/html.charters/dccp-charter.html

draft-ietf-dccp-problem-00.txt  is self explanatory ;-)
draft-ietf-dccp-spec-00.txt is the proposed base spec (still way early)
draft-ietf-dccp-ccid3-00.txt  is the DCCP profile most suitable for RTP

hope this helps out.
thanks,
-rohan