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

From: [email-masked]
Date: Tue, 3 Dec 2002 15:19:40 EST

In a message dated 12/3/2002 1:21:13 PM Eastern Standard Time, 
[email-masked] writes:

> 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).
> 

[MAP]
This is an interesting one. There's been a lot of talk about this idea in 
other places too. But let's examine it in reality.

If my application is handling my phone call, first, I don't know what 
functionality tells it about packet loss or latency or jitter at the other 
end, unless we add specific measuring protocols (which I thing are being 
worked on). If my application had a way to know about excess packet loss at 
the other end (presumably caused by there being too many other people trying 
to talk over the same link), what could it do about it? It could switch to a 
lower speed codec, thereby giving everyone a slighty lower packet loss ratio 
(including myself), but I would surely get worse quality from the lower speed 
codec. (If it were a better codec, I would have selected it in the first 
place.)

Or my application could switch to a higher bandwidth utilitzation, like 
adding more forward error correction to make up for the lost packets or to a 
higher rate codec that is less suseptable to packet loss, thereby giving 
everyone a slightly higher packet loss ratio (including myself), but I 
probably get better quality (at least as far as packet loss is concerned).

So which would you choose? Right! And everyone else would do the same (unless 
you're charged according to bandwidth) and the congestion and packet loss 
goes up and the net gain is negative.

This plan works if there is an intelligent entity in the middle that forces 
all users to switch to a lower rate codec (and accept lower quality). This is 
clearly not the answer in the Internet model.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 3 Dec 2002 16:57:37 -0500

On Tuesday, Dec 3, 2002, at 15:49 America/Montreal, Colin Perkins wrote:
> The hope is that we can apply clue to VoIP implementations,

Colin,

I share that hope. :-)

> although that may not be realistic without policing. Certainly the RFCs
> that describe FEC use with RTP talk about these issues.

For folks like me who aren't up on RTP, could you please list some
assigned-reading by listing the most relevant RFCs on this thread
(including the current incarnation of the base RTP spec) ??

Thanks,

Ran

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 03 Dec 2002 17:38:28 -0500

See http://www.cs.columbia.edu/~hgs/rtp for a reading list.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 4 Dec 2002 10:07:16 -0800

On Tuesday, December 3, 2002, at 12:19 PM, [email-masked] wrote:

> application software on either end of the actual VoIP session, *can* 
> and *do*
> of the above.  Having that knowledge, which is in the VoIP endpoints 
> not in the
> This is an interesting one. There's been a lot of talk about this idea 
> in other places too. But let's examine it in reality.
>
> functionality tells it about packet loss or latency or jitter at the 
> other end, unless we add specific measuring protocols (which I thing 
> are being worked on).

That thing is called RTCP and has been an integral part of RTP since 
its inception.

> If my application had a way to know about excess packet loss at the 
> other end (presumably caused by there being too many other people 
> trying to talk over the same link), what could it do about it? It 
> could switch to a lower speed codec, thereby giving everyone a slighty 
> lower packet loss ratio (including myself), but I would surely get 
> worse quality from the lower speed codec. (If it were a better codec, 
> I would have selected it in the first place.)

In the case of iLBC, you would consume more CPU on your phone or 
computer but your quality would improve (from loss concealment) more 
than it would deteriorate (from compression).   so it actually benefits 
you to switch, and it becomes even better if other switch as well.

thanks,
-rohan

> Or my application could switch to a higher bandwidth utilitzation, 
> like adding more forward error correction to make up for the lost 
> packets or to a higher rate codec that is less suseptable to packet 
> loss, thereby giving everyone a slightly higher packet loss ratio 
> (including myself), but I probably get better quality (at least as far 
> as packet loss is concerned).
>
> So which would you choose? Right! And everyone else would do the same 
> (unless you're charged according to bandwidth) and the congestion and 
> packet loss goes up and the net gain is negative.
>
> This plan works if there is an intelligent entity in the middle that 
> forces all users to switch to a lower rate codec (and accept lower 
> quality). This is clearly not the answer in the Internet model.
>
> Mike Pierce
> Artel
>
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 03 Dec 2002 15:49:47 -0500

--> [email-masked] writes:
>
>--part1_1a8.cf7fd2e.2b1e6bdc_boundary
>Content-Type: text/plain; charset="US-ASCII"
>Content-Transfer-Encoding: 7bit
>

If you implement RTP correctly, the RTP control protocol provides feedback
on the packet loss, latency and jitter at the other end [RFC 1889].

>goes up and the net gain is negative.

The hope is that we can apply clue to VoIP implementations, although that
may not be realistic without policing. Certainly the RFCs that describe FEC
use with RTP talk about these issues.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 03 Dec 2002 17:30:02 -0500

>(including the current incarnation of the base RTP spec) ??

There are three parts to the RTP framework:
 - The base RTP spec 
 - A set of profiles
 - A set of payload formats

The base RTP spec is RFC 1889, updated by draft-ietf-avt-rtp-new-11.txt
(the update has been approved for publication, and is currently winding
its way from IESG to RFC Editor). The base spec defines a data transfer
protocol (framing, timing, sequencing, payload identification, etc) and 
a control protocol (reception quality feedback, user identification and 
lip synchronisation). 

The profiles adapt RTP to particular environments. For voice-over-IP or
video teleconferencing, the appropriate profile is RFC 1890 (updated by
draft-ietf-avt-profile-new-12.txt, also on its way to RFC publication 
as a draft standard).

Payload formats define the mapping from particular codecs onto RTP. The
profile defines some payload formats (e.g. for G.711), others are defined
in separate RFCs (e.g. H.263 in RFC 2429, G.722.1 in RFC 3047). FEC is
either implemented as part of a payload format for a particular codec (e.g.
see the discussion in RFC 3267 for AMR audio) or as a standalone payload
format (e.g. RFC 2733 or RFC 2198). 

There are also guidelines for authors of payload formats in RFC 2736 that
may be of interest. 

This is all handled by the AVT group: http://www.ietf.org/html.charters/avt-charter.html

Cheers,
Colin