Subject: [codec] updated charter proposal

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Oct 2009 15:42:49 -0600

Per recent list discussion...

######

Proposed Charter for Codec WG
Last Updated: 2009-10-20

Problem Statement

There are no standardized, high-quality audio codecs that are optimized
for use in interactive Internet applications and that can be widely
implemented and easily distributed among  application developers,
service operators, and end users.  This gap in the Internet protocol
stack has hindered protocol designers from being able to specify
mandatory-to-implement codecs in their protocols for the sake of
interoperability, developers from building innovative, interactive
applications, service operators from deploying affordable, high-quality
services, and end users from enjoying an optimal user experience.
Because the Internet Standards Process defines an open, transparent
process for technology standardization, a wide range of codec experts
have committed to actively working on such codecs within the IETF.
The Codec WG provides a structured forum for these efforts.

Objectives

The goal of this group is to develop one or more high-quality,
widely-distributable audio codecs that is optimized for use over the
Internet. Core considerations include but are not necessarily limited
to the following:

1. Use in interactive applications (examples include but are not
limited to point-to-point voice calls, multi-party voice conferencing,
telepresence, teleoperation, in-game voice chat, and live music
performance)

2. Addressing the real transport conditions of the Internet as
identified and prioritized by the group

3. Ensuring interoperability with the Real-time Transport Protocol
(RTP), including secure transport via SRTP

4. Ensuring interoperability with Internet signalling technologies such
as Session Initiation Protocol (SIP), Session Description Protocol
(SDP), and Extensible Messaging and Presence Protocol (XMPP); however,
signalling-dependent codecs are out of scope

Codecs optimized for very low bit rates (typically below 2.4 kbps) and
codecs for non-interactive audio are out of scope because they might
necessitate specialized optimizations.

Although the codec(s) produced by the group might be used as
mandatory-to-implement technologies by designers of particular Internet
protocols, it is explicitly not a goal of the group to produce a codec
that will be mandated for use across the entire IETF or Internet community.

The group might produce only one codec or it might produce multiple
codecs; however, to reduce confusion in the marketplace it shall
endeavor not to function as a "codec factory" that produces a large
number of codecs.

Work processes and technical requirements for achieving the foregoing
objectives are outlined in draft-valin-codec-guidelines and
draft-valin-codec-requirements respectively; these documents will form
the starting point for working toward consensus and will be refined by
the group in accordance with the usual IETF procedures.

Intellectual property rights (IPR) issues will be handled in accordance
with BCP 78 and BCP 79. Many existing codecs with the technical
attributes listed above are encumbered with licensing fees and other IPR
claims that make royalty-free and wide distribution and use across the
Internet community difficult.  The group will try to standardize codecs
that can be relatively freely and easily distributed, and employed as
much as possible. In doing so, it will adhere closely to these BCPs.
More specifically, "In general, IETF working groups prefer technologies
with no known IPR claims or, for technologies with claims against them,
an offer of royalty-free licensing."  Note that in accordance with BCP
79, the group will not explicitly rule out the possibility of adopting
technology that does not meet these IPR requirements; such decisions
will be made in accordance with the rough consensus of the group.

Deliverables

1. Guidelines that define the work process of the group, using
draft-valin-codec-guidelines as the starting point for working toward
consensus. This document shall be Informational.

2. Detailed technical requirements, using draft-valin-codec-requirements
as the starting point for working toward consensus.  This document
shall be Informational.

3. Specification of one or more codecs that meet the agreed-upon
requirements, in the form of Internet-Drafts that define the codec
algorithm and source code for a reference implementation. The text
description of each codec shall indicate which components of the encoder
and decoder are mandatory, recommended, and optional.  It is envisioned
that each such specification shall be a Proposed Standard document.

Milestones

Mar-2010: WGLC on Codec Standardization Guidelines
May-2010: Codec Standardization Guidelines to IESG (Informational)
May-2010: WGLC on Requirements
Jul-2010: Requirements to IESG (Infomational)
Mar-2011: WGLC on codec specification(s)
Jun-2011: Submit codec specification(s) to IESG (Standards Track)

---

From: "rontlv" <[email-masked]>
Date: Wed, 21 Oct 2009 01:03:29 +0200

Hi,
I did not have time to review the charter proposal being on vacation.

I would like to bring my major concern about 
" The goal of this group is to develop one or more codecs" . My view is that
the one of the major reason for lack of deployment of wideband is that there
are too many wideband codecs.
For example in high quality video conferencing you may need to support G.719
and flavors of AAC full band codecs to interoperate at full band with all
the current products.
I also find it strange that the timeline has one date for all codecs that
will be developed since I do not see any synchronization process between all
the codecs that will be approved if a WG is formed.
I think that having the right to do multiple codecs as part of the charter
will cause the group to approve all proposed codecs probably rubberstamping
them instead of going to collaboration on one good codec. I think that the
initial charter should have one codec and if later there will be a need
there should be a re-charter.

A minor comment is on 
"Because the Internet Standards Process defines an open, transparent process
for technology standardization, a wide range of codec experts have committed
to actively working on such codecs within the IETF.
The Codec WG provides a structured forum for these efforts."
I am not sure why this text is part of the charter. 

Being a little sarcastic about the commitment, I did not see the flexibility
of the experts when they needed to devote time for the IETF meeting.
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Tuesday, October 20, 2009 11:43 PM
> To: [email-masked]
> Subject: [codec] updated charter proposal
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkreLtkACgkQNL8k5A2w/vwxcACeOQvIqWty+cUynAc3d3h8XbMA
> /eoAoNomjEgkTahDyFLfIFH+zTxYSWGI
> =MT0M
> -----END PGP SIGNATURE-----
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4527 (20091020) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4527 (20091020) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: Brian West <[email-masked]>
Date: Tue, 20 Oct 2009 18:34:07 -0500

G.719 will never take off unless Ericsson gets off their part of the  
IP and actually will disclose the licensing details without having to  
sign an NDA.

/b

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 21 Oct 2009 10:22:46 +0200

Hello,

> and flavors of AAC full band codecs to interoperate at full band with all
...
> there should be a re-charter.

I have to agree to Roni Even. This sentence and also the entire paragraph
remain unclear. I have understood that the questions on how many codecs and
on which to select are going to be solved by rough consensus. However, till
now I do not see in the charter any consensus nor statements on high level
selection or merging criteria. How could you decide on a codec in short
time, when you cannot agree on general selection statements?

In my previous email on the charter I try to address this point with the
statement that "The codec(s) shall address a large range of typical
transmission conditions on the Internet." However, maybe there is a
consensus on the statement: "Every offered codec is selected" following the
old Roman saying "Don't look a gift horse in the mouth". Or on some beauty
contest... Whatsoever, the paragraph remains too vague for me.

Christian

> __________ Information from ESET NOD32 Antivirus, version of virus
signature

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Oct 2009 13:07:09 +0300

Hi,

the current charter text is starting to look OK. I'd like to raise one  
point below where I think we're missing a requirement.

To put this in perspective: I'm still not convinced that the IETF  
should actually start this work until we've clarified with the ITU-T/ 
3GPP/MPEG/etc. how this intersects with their work. But that's an  
orthogonal issue. If we were to start work, the current charter is  
looking reasonable. Maybe modulo what I'm going to say next...

> signalling-dependent codecs are out of scope

The Internet uses a distributed congestion control mechanism built  
around the notion that when a flow observes packet loss, it is suppose  
to reduce its sending rate in some form over some time, in order to  
take load off a congested path. This behavior is something that I (as  
a transport guy) would see as a key differentiator between an  
"Internet codec" and a "telco codec", and I'd like to suggest that we  
reflect this in the charter in some form.

We can certainly argue about how useful this behavior would be in a  
low-bitrate voice codec. But it's my understanding that this effort  
isn't really targeting those, but is instead looking at wideband  
codecs - maybe ones using substantial levels of redundancy in the  
encoding - that can consume some noticeable amount of bandwidth. For  
those sorts of voice codecs, and even more so for video codecs, which  
have been brought up as the next logical thing for a potential CODEC  
WG to target, some sort of congestion-responsiveness is important when  
they are sharing path capacity over the Internet.

See for example http://tools.ietf.org/html/draft-westerlund-avt-ecn-for-rtp 
  for ongoing work related to exposing congestion information to media  
streams earlier than through packet loss (i.e., using ECN).

To be perfectly clear: This is NOT about enforcing TCP-friendliness or  
forcing the resulting codecs to conform to some other strict behavior  
under congestion. Due to the complexities of each coding scheme, how  
soon and by how much it can react to path congestion will be extremely  
codec-specific. But the idea is to recommend (or maybe even require)  
for "Internet codecs" to react appropriately to path congestion when  
they can.

Thoughts?

Lars

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 21 Oct 2009 04:40:13 -0700

Hi Lars,

On 10/21/09 3:07 AM, "Lars Eggert" <[email-masked]> wrote:

> [...]

The traditional solution to achieve network-dictated (or suggested) bitrate
adaptivity is a scalable bitstream.  G.729.1 would be one example in the
audio space, and the SVC profiles of H.264 one in the video space.

The result of dropping layers in a scalable codec is reduced fidelity.
Whether users accept such a reduced fidelity depends IMHO mostly on the
application.  

To make one audio-centric example, in cheap/free desktop (video)
conferencing, dropping from wideband audio to telephony band speech in case
of congestion seems entirely reasonably, and is implemented in several
products I'm aware of.  For a music streaming/distribution service, the
story would be very different.  That is, in part, why those services put
heavy FEC on their unelastic media streams (quite to the contrary of the
intention of congestion control), or fall back to TCP transport with
multisecond buffers.

Adding scalability support to the requirements (perhaps at "SHOULD" level)
may make sense.  Or, at least, other ways of supporting network-dictated
variable bitrates, for example in the way the quantizer in MPEG'solder audio
codecs work (not that a lot of people use those mechanisms for bandwidth
adaptivity...).  Both ways lead into patent minefields, though.

In video, in contrast to audio, a real-time encoder has an ample number of
parameters to vary the outgoing bandwidth.  Most encoders operating under
real-time constraints play with those parameters constantly in a mechanism
that is commonly known as rate control.  They have to, because without rate
control the outgoing bitrate is variable over several orders of magnitude,
depending on content complexity.  Adding a network-dictated, pseudo-variable
target bitrate to the list of input parameters a rate control has to obey is
almost trivial.  Implementing something along these lines is common for
point-to-point video with real-time encoders.  Still, if that bitrate is too
low, your quality goes down into an unacceptable range.  But then, if you
get excessive losses due to congestion, your quality sucks, too.

When operating with non real-time encoders, or in multipoint scenarios
without transcoding, scalability is the technology of choice for bandwidth
adaptation.  All modern standardized video codecs offer scalability in one
form or another.  The SVC payload format draft contains quite a few words on
this subject.

Regards,
Stephan

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 21 Oct 2009 13:45:55 +0200

Dear Lars Eggert,

> See for example
http://tools.ietf.org/html/draft-westerlund-avt-ecn-for-rtp
> for "Internet codecs" to react appropriately to path congestion when

Since months I am raising this point on this mailing list. I suggested to
establish a procedure on how transport and codec expert should work together
to address these issues. 

However, based on the comments on this mailing list, I have the impression
that this is not wanted. I just remember some statements such as that we are
"only interested in a narrow area." 

I do have the impression that it is not intended to address the fundamental
problems of frequently bad VoIP quality or to enhance the Quality of
Experience - which would require to consider transport issues - but only in
making codecs. Hopefully, my observation is wrong.

With best regards,

 Christian Hoene

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Oct 2009 14:56:59 +0300

Hi,

> establish a procedure on how transport and codec expert should work  

I'm sorry if I missed this - I cannot follow this email list very  
regularly.

Lars

---

From: "Slava Borilin" <[email-masked]>
Date: Wed, 21 Oct 2009 15:57:18 +0400

Stephan,

You are absolutely right on scalability and its benefits - that's what
we are doing in SPIRIT IP-MR codec
(http://tools.ietf.org/search/draft-spiritdsp-ipmr-00) for many years
already.

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephan Wenger
Sent: Wednesday, October 21, 2009 3:40 PM
To: Lars Eggert; Peter Saint-Andre
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Hi Lars,

> for "Internet codecs" to react appropriately to path congestion when

The traditional solution to achieve network-dictated (or suggested)
bitrate
adaptivity is a scalable bitstream.  G.729.1 would be one example in the
audio space, and the SVC profiles of H.264 one in the video space.

conferencing, dropping from wideband audio to telephony band speech in
case

Adding scalability support to the requirements (perhaps at "SHOULD"
level)
may make sense.  Or, at least, other ways of supporting network-dictated
variable bitrates, for example in the way the quantizer in MPEG'solder
audio
codecs work (not that a lot of people use those mechanisms for bandwidth
adaptivity...).  Both ways lead into patent minefields, though.

In video, in contrast to audio, a real-time encoder has an ample number
of
parameters to vary the outgoing bandwidth.  Most encoders operating
under
real-time constraints play with those parameters constantly in a
mechanism
that is commonly known as rate control.  They have to, because without
rate
control the outgoing bitrate is variable over several orders of
magnitude,
depending on content complexity.  Adding a network-dictated,
pseudo-variable
target bitrate to the list of input parameters a rate control has to
obey is
almost trivial.  Implementing something along these lines is common for
point-to-point video with real-time encoders.  Still, if that bitrate is
too
low, your quality goes down into an unacceptable range.  But then, if
you
get excessive losses due to congestion, your quality sucks, too.

When operating with non real-time encoders, or in multipoint scenarios
without transcoding, scalability is the technology of choice for
bandwidth
adaptation.  All modern standardized video codecs offer scalability in
one
form or another.  The SVC payload format draft contains quite a few
words on
this subject.

Regards,
Stephan

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 21 Oct 2009 06:13:15 -0700

This proposed charter for the Codec WG is indeed fine tuned to the needs of the Internet and its users.
IMO it should be left as it is.

No doubt, the opposition to the Internet codecs concept will continue, so let's insure not to allow it being a distraction from moving on with the actual work on the codec architecture, hopefully one or more reference implementations and reports on test results - far more productive than endless mail discussions.

So can we now please move on to the actual design documents?
Design proposals and reference code enhancements instead of objections?

Are any of the codec designers willing to set up a web site as is usual for OS projects?
Should an Internet codec development web site (or more than one) be sponsored by the proposed WG?
Conceptual precedent: SIP Forum and its SIPit interoperability testing events - the codec web sites will obviously be different, but the intent can be similar.

My strict personal 2 cents, including the naïve questions,

Henry

On 10/20/09 4:42 PM, "Peter Saint-Andre" <[email-masked]> wrote:

######

Problem Statement

Objectives

Deliverables

Milestones

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 21 Oct 2009 09:27:29 -0400

Hi,

Lars Eggert wrote:
> to reduce its sending rate in some form over some time, in order to take 
> load off a congested path. This behavior is something that I (as a 
> transport guy) would see as a key differentiator between an "Internet 
> codec" and a "telco codec", and I'd like to suggest that we reflect this 
> in the charter in some form.

I totally agree that the bit-rate should adapt to network congestion. This 
is why the requirements draft includes "Having the possibility to use 
smooth bit-rate changes with one byte/frame resolution". This means that 
the codec can produce any rate that is needed to avoid congestion (not just 
a few pre-selected ones). Now, we must be careful to assign issues to the 
correct "layer" in the VoIP stack. I do not believe it is the codec's job 
to *decide* which bit-rate to select. This should be left to another 
component of the application (the RTP stack?), which can then tell the 
codec what bit-rate to use.

If there are more features that the codec can add to help with congestion, 
this is certainly something we can add to the drafts. Scalable codecs have 
also been discussed. I don't like the word because people seem to use it 
for different meanings. In one meaning it is simply the ability to use any 
rate, which is addressed above. In the other meaning, it means having 
layers that can be stripped off. I believe this can be a useful feature 
(which *is* listed in the current drafts), but mostly for conferencing, 
rather than congestion. The point of layered codec for congestion in 
particular is that a router in the middle can reduce the bit-rate to adjust 
to congestion. However, I see two problems here: 1) most routers does not 
(and should not have) knowledge of the codec and thus cannot change the 
rate; and 2) layers are usually larger than a single byte per frame so 
relying only on a layered approach might compromise the idea of having 
small bit-rate increments. But as I said earlier, I'm not opposed to 
layered codecs because they have other uses. This is something that would 
have to be carefully analysed during development.

> codec-specific. But the idea is to recommend (or maybe even require) for 
> "Internet codecs" to react appropriately to path congestion when they can.

OK, I may be wrong here, but my understanding is that how much the rate 
should change depending on congestion is actually not that codec-specific. 
I get the impression that the tough part is figuring out what rate you can 
use without causing packets to be dropped. Once you figure this out, you 
can just tell the codec to use that rate. On top of that, the codec may be 
able to do a bit better by providing a "service" to the other layers. On 
example here (also included in the draft) is VBR, which means that the 
application specifies an average rate and the codec decides how to vary the 
rate to achieve that (subject to some rate control constraints). Would 
other such mechanisms be useful to deal with congestion?

Cheers,

	Jean-Marc

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 21 Oct 2009 09:57:15 -0400

All,

Just a thought for everyone. Prior to the last BoF I posted email that
suggested that the codec should have an ability to change encoding rate
as a function of some form of congestion intelligence (perhaps through
an API, perhaps a hint at the RTP layer, perhaps on a congestion
indication, etc.). That "should" was not necessarily a "must" because a
given application may tell the codec to go full steam ahead anyway
because what it knows about the transport environment. And I think that
wording has been accommodated.

Consider Jean-Marc's words: "I get the impression that the tough part is
figuring out what rate you can use without causing packets to be
dropped."

Indeed.

Consider the case where the bottleneck link for your end-to-end codec
application (where most of your packets are being dropped) is such that
all the UDP traffic (e.g., your VoIP and other UDP applications) is a
minority traffic. That is, the majority of traffic is TCP-friendly (TCP,
SCTP, etc.). And that the bandwidth of this link is large relative to
your VoIP stream. Now suppose that this link is someplace in one of the
middle hops of your end-to-end flow.

That link is being "filled up" (and causing drops for your flow)
according to the TCP dynamics of the other TCP traffic. Virtually
NOTHING YOU DO ON YOUR FLOW will have a significant impact on your
packet drop performance! Any bandwidth you "vacate" by reducing your
rate becomes "absorbed" (in a sense) by the TCP flows sharing the
remainder of the bandwidth.

If your application somehow (magically) knew this was the case, perhaps
it would NOT reduce rate. Now that isn't TCP friendly. And some codec
designs actually increase rate in those cases (by reducing rate all they
can - but then adding FEC bandwidth to the lowest rate).

I think the best we can do here is to design in the knobs to have the
codec change rate (or add FEC if that is a codec capability) to
accommodate scenarios such as the above.

Michael Ramalho

PS - As a side note, if the bottleneck link had majority traffic
consisting of similar VoIP flows - the correct behavior would be to
reduce rate as TCP does. That is why the answer for a link dominated by
ITSP traffic would be to reduce rate. And this is why the VoIP
application ideally would benefit from "other intelligence" regarding
congestion properties.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jean-Marc Valin
Sent: Wednesday, October 21, 2009 9:27 AM
To: Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Hi,

> to reduce its sending rate in some form over some time, in order to
take 
> in the charter in some form.

I totally agree that the bit-rate should adapt to network congestion.
This 
is why the requirements draft includes "Having the possibility to use 
smooth bit-rate changes with one byte/frame resolution". This means that

the codec can produce any rate that is needed to avoid congestion (not
just 
a few pre-selected ones). Now, we must be careful to assign issues to
the 
correct "layer" in the VoIP stack. I do not believe it is the codec's
job 
to *decide* which bit-rate to select. This should be left to another 
component of the application (the RTP stack?), which can then tell the 
codec what bit-rate to use.

If there are more features that the codec can add to help with
congestion, 
this is certainly something we can add to the drafts. Scalable codecs
have 
also been discussed. I don't like the word because people seem to use it

for different meanings. In one meaning it is simply the ability to use
any 
rate, which is addressed above. In the other meaning, it means having 
layers that can be stripped off. I believe this can be a useful feature 
(which *is* listed in the current drafts), but mostly for conferencing, 
rather than congestion. The point of layered codec for congestion in 
particular is that a router in the middle can reduce the bit-rate to
adjust 
to congestion. However, I see two problems here: 1) most routers does
not 
(and should not have) knowledge of the codec and thus cannot change the 
rate; and 2) layers are usually larger than a single byte per frame so 
relying only on a layered approach might compromise the idea of having 
small bit-rate increments. But as I said earlier, I'm not opposed to 
layered codecs because they have other uses. This is something that
would 
have to be carefully analysed during development.

> codec-specific. But the idea is to recommend (or maybe even require)
for 

OK, I may be wrong here, but my understanding is that how much the rate 
should change depending on congestion is actually not that
codec-specific. 
I get the impression that the tough part is figuring out what rate you
can 
use without causing packets to be dropped. Once you figure this out, you

can just tell the codec to use that rate. On top of that, the codec may
be 
able to do a bit better by providing a "service" to the other layers. On

example here (also included in the draft) is VBR, which means that the 
application specifies an average rate and the codec decides how to vary
the 
rate to achieve that (subject to some rate control constraints). Would 
other such mechanisms be useful to deal with congestion?

Cheers,

	Jean-Marc

---

From: Brian Rosen <[email-masked]>
Date: Wed, 21 Oct 2009 10:04:50 -0400

Please keep in mind that depending on the characteristics of the codec, you
don't want a lot of rate changes because it annoys the user.  I've had one
codec designer claim users weren't annoyed with relatively frequent changes
in rate (and thus audio quality), but I've never tested one that didn't.

Usually, if you encounter congestion, you can ratchet down, and then you
roughly never go back up.

When in doubt, run usability tests.  Easy to run, and gets you a solid
answer of what the codec ought to do.

Brian

---

From: Christian Hoene <[email-masked]>
Date: Wed, 21 Oct 2009 17:05:22 +0200

> codec what bit-rate to use.

Reading these statements, I would recommend to read the DCCP charter
http://www.ietf.org/dyn/wg/charter/dccp-charter.html and especially the
document http://www.ietf.org/rfc/rfc4828.txt

 Christian

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 21 Oct 2009 19:12:53 +0200

Hello Brian,

> in rate (and thus audio quality), but I've never tested one that didn't.

Some years ago, we have done some tests with AMR. The distortion caused by a
change of the coding rate is roughly as large as the distortion caused by a
frame loss
(http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/hoene_paper21
b.pdf). Consequently, frequent (multiple per second) mode switches are not
possible with AMR. However, frequent mode changes may be triggered by
transport protocols, which change their frame rates typically after a round
trip time.

The ITU-T G.718 codec was designed to allow frequent mode switched without
causing annoying artifacts. A similar requirement is missing in the current
draft-valin-codec-requirements document. I did not read any argument on why
it was not included.

> roughly never go back up.

TCP does increase linearly after an ECN notification or a frame loss event.
Depending on the selected algorithm, DCCP does behave similar.

 Christian

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 21 Oct 2009 14:04:14 -0400

> transport protocols, which change their frame rates typically after a round

 From what I've been told (haven't verified myself), the AMR-NB modes are 
more like a set of independent codecs put together with duct tape, rather 
than one codec with 8 rates. This is probably what explains the switching 
artefacts.

> draft-valin-codec-requirements document. I did not read any argument on why

The requirements draft (both versions) currently includes the following text:

    "This means that the codecs have to be able to vary their output
    bit-rate dynamically (in real-time), without requiring an
    out-of-band signaling mechanism, and without causing audible
    artifacts at the bit-rate change boundaries."

I think "without causing audible artifacts" is a good description of what 
we want here. Or do you have something else to suggest?

	Jean-Marc

---

From: Gregory Maxwell <[email-masked]>
Date: Wed, 21 Oct 2009 11:36:05 -0700

So— I think this is really just an argument for codecs designed for the internet…

Consider these examples:

CBR CELT (git) running at 48000, 256 sample frames, 21 bytes/frame (31500 bits per second which is a bit too low for good music quality with this small framesize)
http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21bytes.wav

CBR CELT (git) running at 48000, 256 sample frames, 43 bytes/frame (64500 bits per second)
http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/43bytes.wav 

CELT (git) 48000,256 ramping with from 43-21-43 in one byte per frame increments:
http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-ramp1-43bytes.wav
(i.e. the frame sizes sizes are 43,42,41,40...22,21,22,23,24...)

Same ramping pattern, but sending 8 frames at each size:  i.e. 43,43,43,43,43,43,43,43,42,42,42....  or roughly 42ms per rate change and  one second per complete cycle: 
http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-ramp8-43bytes.wav

Also,
Hard switching every other frame: 43,21,43,21,43,21....
http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-mod2-43bytes.wav

And every 4th frame: (43,43,43,43,21,21,21,21,43...)
http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-mod4-43bytes.wav

While it would be very interesting to use a blind listening test to objectively characterize the impact of changing rates,  I believe that a casual listen shows conclusively that for CELT a change in rates is nothing at all like a packet loss (or, perhaps you have very high expectations of what 50% loss sounds like!).

I would I expect reasonable rate control implementations to have some degree of filtering to limit rate oscillations and using the codec in VBR mode and simply slewing the target is likely to be far less harmful, but I think that these simple examples show that aggressive adaptation is possible without a ruinous effect to quality.

If anyone has profiles of what kind of rate adaptation patterns I could expect (i.e. from DCCP) I'll gladly generate test cases and can probably arrange for a small/casual blind listening test.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christian Hoene [[email-masked]]
Sent: Wednesday, October 21, 2009 6:12 PM
To: 'Brian Rosen'
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Hello Brian,

 Christian

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 21 Oct 2009 21:03:59 +0200

Hello Jean-Marc,

> than one codec with 8 rates. This is probably what explains the switching

Yes. This might be the reason for this. The AMR standards were stating that
state switching is seamlessly. I never tested CELT.

> we want here. Or do you have something else to suggest?

No, you are right. I missed it. Sorry.

 Christian

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 21 Oct 2009 21:06:20 +0200

Hello Gregory,

> While it would be very interesting to use a blind listening test to
> objectively characterize the impact of changing rates,  I believe that a
> casual listen shows conclusively that for CELT a change in rates is
nothing at
> all like a packet loss (or, perhaps you have very high expectations of
what
> 50% loss sounds like!).

Fine! Well done!

May I ask another question? What does happen if you switched between CELT
and SILK or any of the other codecs?

> I would I expect reasonable rate control implementations to have some
degree
> of filtering to limit rate oscillations 

Yes, they have. The DCCP algorithms change less frequent and less severe
than TCP.

> and using the codec in VBR mode and
> simply slewing the target is likely to be far less harmful, but I think
that
> these simple examples show that aggressive adaptation is possible without
a
> ruinous effect to quality.
> 
> If anyone has profiles of what kind of rate adaptation patterns I could
expect
> (i.e. from DCCP) I'll gladly generate test cases and can probably arrange
for
> a small/casual blind listening test.

Allow me address another issue. The RFC4828 document discusses the tradeoff
between bit rate and frame rate. To what extend is this tradeoff currently
considered in the requirements draft?

With best regards,

 Christian

> From: [email-masked] [[email-masked]] On Behalf Of
Christian
> Hoene [[email-masked]]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 13:34:00 -0600

> and flavors of AAC full band codecs to interoperate at full band with all

At the Stockholm BoF, people raised concerns about saying that the WG
would limit itself beforehand to defining one and only one codec ("too
restrictive!"). They also raised concerns about the WG becoming a codec
factory that would produce lots of codecs ("too permissive!"). The
current text attemps to address both concerns by expressing a preference
for one codec while recognizing that it is possible the WG would produce
more than one codec (albeit a very small number of codecs).

> there should be a re-charter.

That seems acceptable.

> I am not sure why this text is part of the charter. 

That text is true, but you are right that it is not properly part of the
problem statement.

> of the experts when they needed to devote time for the IETF meeting.

Your sarcasm is appreciated.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 13:53:23 -0600

>> there should be a re-charter.

Well, the charter currently includes the following text:

Perhaps that could be modified to more clearly express a strong
preference for producing one codec:

   The group might produce only one codec or it might produce multiple
   codecs; however, to reduce confusion in the marketplace it shall
   endeavor to produce only one codec if possible, and in any case shall
   not function as a "codec factory" that produces a large number of
   codecs.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 14:00:53 -0600

> making codecs. Hopefully, my observation is wrong.

It's not clear to me why the Codec WG would focus on transport issues.
Certainly it should coordinate with transport WGs (AVT, DCCP, etc.),
just as it should coordinate with WGs and experts from RAI, Apps,
Security, architecture (IAB), etc.

Do you think that the charter text needs to be updated to express the
fact that the Codec WG would need to coordinate with other groups within
the IETF? Typically that is part of normal cross-area review, but
perhaps the extraordinary impact on the Codec WG of considerations that
are properly the focus of other groups necessitates more intensive
interaction here. I'm not convinced of that yet, but adding some text
about this in the charter might be appropriate if we think it is needed.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 21 Oct 2009 16:17:07 -0400

> and SILK or any of the other codecs?

(my answer is based on CELT and SILK but it would be about the same for any 
two codecs that are sufficiently different)
If done in a simple (dumb) way, it would insert a glitch that would be 
comparable to a lost packet. If done a bit smarter, it would merely require 
  a slight increase in bitrate at the boundary frame along with a careful 
overlap of the audio. If the codecs were designed jointly, then it *may* 
also be possible make the bit-rate increase pretty small (or zero).

	Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 22 Oct 2009 00:18:50 +0400

sorry i am not getting the idea WHY you should switch codecs during the call?
i understand the idea os changing bitrate on-the-fly, but why renegotiate and change codec on the fly? only in a rare case of call transfeerring to a different device- but in this case you have a delay of switching which makes such change unnoticable anyway.
am i wrong?

________________________________

От: [email-masked] от имени Jean-Marc Valin
Отправлено: Чт, 22.10.2009 0:17
Кому: Christian Hoene
Копия: [email-masked]
Тема: Re: [codec] updated charter proposal

        Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 21 Oct 2009 16:29:02 -0400

Quoting Slava Borilin <[email-masked]>:

> i understand the idea os changing bitrate on-the-fly, but why renegotiate and
> change codec on the fly? only in a rare case of call transfeerring to a
> different device- but in this case you have a delay of switching which makes
> such change unnoticable anyway.
> am i wrong?

You are perfectly right here, I was just answering the question from a
theoretical perspective. At this point, I do not see a reason for changing
codec on the fly, or at least not without some kind of exceptional event
happening (e.g. call transfer) -- in which case a single glitch wouldn't be a
problem.

Cheers,

   Jean-Marc

> ïÔ: [email-masked] ÏÔ ÉÍÅÎÉ Jean-Marc Valin
> ïÔÐÒÁ×ÌÅÎÏ: þÔ, 22.10.2009 0:17
> ëÏÍÕ: Christian Hoene
> ëÏÐÉÑ: [email-masked]
> ôÅÍÁ: Re: [codec] updated charter proposal
>
>
>
> Christian Hoene wrote:

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Oct 2009 21:50:34 +0100

...
> signalling-dependent codecs are out of scope

Most recent codecs are dependent on some form of out-of-band  
signalling to negotiate various options and parameters. Prohibiting  
any dependence on the signalling seems extreme. You might wish to say  
something like:

4. Ensuring interoperability with Internet signalling technologies such
as Session Initiation Protocol (SIP), Session Description Protocol
(SDP), and Extensible Messaging and Presence Protocol (XMPP) by  
defining the parameters that must be negotiated to support the codec;  
the result should not, however, depend on the details of any  
particular signalling protocol

-- 
Colin Perkins
http://csperkins.org/

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 21 Oct 2009 16:58:18 -0400

> Most recent codecs are dependent on some form of out-of-band signalling 
> to negotiate various options and parameters. Prohibiting any dependence 
> on the signalling seems extreme. You might wish to say something like:

IIRC, the intent was just to clarify that the codec wouldn't be tied to SIP 
  or XMPP for example. However, your point about out-of-band signalling is 
actually a valid one. We will probably need some amount of out-of-band 
signalling, but I think it should be simple enough and it should fit well 
within SDP (this should probably go in the requirements draft).

> (SDP), and Extensible Messaging and Presence Protocol (XMPP) by defining 
> the parameters that must be negotiated to support the codec; the result 
> should not, however, depend on the details of any particular signalling 
> protocol

Sounds good.

	Jean-Marc

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 21 Oct 2009 14:03:43 -0700

You could change codecs "on the fly" using in-band signaling, the same way
as (some have argued) AMR-WB does.  This is mostly a question of
terminology: when you switch between two distinct coding technologies that
are a) specified in the same standard, b) mandatory to implement, and c)
in-band signaled, do you then switch codecs or modes of the same codec?

(Whether a specification like this makes a lot of sense in our environment,
is, IMHO, very questionable.  A lot of codec standards of this type exist,
but they are often at least in part the result of a political process and
not necessarily only motivated by objectively justifiable technical design
choices.)

(OTOH, I personally prefer a clean single-mechanism spec, over a monster
spec with everything mandatory, over a pick-and-choose spec---and the latter
over lots of individual specs.  That is, of course, on the grounds of
interoperability.)
Stephan

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Oct 2009 22:04:19 +0100

On 21 Oct 2009, at 21:00, Peter Saint-Andre wrote:
...
> It's not clear to me why the Codec WG would focus on transport  
> issues. Certainly it should coordinate with transport WGs (AVT,  
> DCCP, etc.), just as it should coordinate with WGs and experts from  
> RAI, Apps, Security, architecture (IAB), etc.
>
> Do you think that the charter text needs to be updated to express  
> the fact that the Codec WG would need to coordinate with other  
> groups within the IETF? Typically that is part of normal cross-area  
> review, but perhaps the extraordinary impact on the Codec WG of  
> considerations that are properly the focus of other groups  
> necessitates more intensive interaction here. I'm not convinced of  
> that yet, but adding some text about this in the charter might be  
> appropriate if we think it is needed.

That sort of text is relatively common in charters (for example, the  
AVT charter says "in collaboration with the MPLS and ROHC WGs, to  
develop a solution for header compression of RTP across MPLS networks  
that avoid decompression and compression at each MPLS node."), and  
would seem to be appropriate here. The key points would seem to be to  
work with AVT and TSVWG to understand the degree of rate adaptation  
desirable, and to attempt to reflect that in the design of a codec  
that can adjust its transmission in a way that minimises disruption to  
the audio. The technical details of how that might be done - in terms  
of the congestion control or the codec - are likely out of scope for  
the charter.

-- 
Colin Perkins
http://csperkins.org/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 16:09:28 -0600

On 10/21/09 2:58 PM, Jean-Marc Valin wrote:
> IIRC, the intent was just to clarify that the codec wouldn't be tied to
> SIP  or XMPP for example. However, your point about out-of-band
> signalling is actually a valid one. We will probably need some amount of
> out-of-band signalling, but I think it should be simple enough and it
> should fit well within SDP (this should probably go in the requirements
> draft).
> 

Yes, that's better, thanks.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 16:31:46 -0600

On 10/21/09 3:04 PM, Colin Perkins wrote:
>> fact that the Codec WG would need to coordinate with other groups
>> within the IETF? Typically that is part of normal cross-area review,
>> but perhaps the extraordinary impact on the Codec WG of considerations
>> that are properly the focus of other groups necessitates more
>> intensive interaction here. I'm not convinced of that yet, but adding
>> some text about this in the charter might be appropriate if we think
>> it is needed.
> 
> 
> That sort of text is relatively common in charters (for example, the AVT
> charter says "in collaboration with the MPLS and ROHC WGs, to develop a
> solution for header compression of RTP across MPLS networks that avoid
> decompression and compression at each MPLS node."), and would seem to be
> appropriate here. The key points would seem to be to work with AVT and
> TSVWG to understand the degree of rate adaptation desirable, and to
> attempt to reflect that in the design of a codec that can adjust its
> transmission in a way that minimises disruption to the audio. The
> technical details of how that might be done - in terms of the congestion
> control or the codec - are likely out of scope for the charter.

That seems reasonable.

To capture all the integration points that have been mentioned on the
list, we could include in the charter text such as this:

***

In completing its work, the group should collaborate with other IETF
working groups to complete particular tasks.  These might include but
would not be limited to the following:

- - Within the AVT WG, define the codec's payload format for use with the
  Real-time Transport Protocol (RTP).

- - Collaborate with the AVT WG and TSV WG to understand the degree of
  rate adaptation desirable, and to reflect that understanding in the
  design of a codec that can adjust its transmission in a way that
  minimizes disruption to the audio.

- - Collaborate with the SIPCORE WG and XMPP WG to ensure that information
  about the codec can be easily represented at the signalling layer.

- - Collaborate with the AVT WG and DCCP WG to identify important
  aspects of packet transmission over the Internet.

***

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 22 Oct 2009 09:18:43 +0200

Hi Cristian, Jean-Marc

Some comments to the comments on AMR

I have not had time to read the report in full but I reacted on he
comment below (figure 5 in the report). 

AMR rate swithing _is_ seamless. As far as I can recall rate switching
was part of the codec characterization in 3GPP, in addition, rate
control in circuit switched networks (which is faster than the rate
control in packet switched networks will ever be) would be impossible
without seamless switching. So I am a bit surprised that you get these
results. 
Did you do a listening test as well ?, I wonder if there is a flaw in
the PESQ model.. What kind of input stimuli did you use ?. I actually
had to make a testrun where I switched between AMR102 and AMR122 every
20ms and I did not hear any swithing artifacts. I even asked another
listener at the office (with better ears than mine) to listen and he
wasn't able to hear any switching artifacts either.

And finally 
AMR is _one_ codec, not a selection of 8 codecs. The modes share the
same framework but of course the quanitizer resolution (LSP, adaptive
CB, fixed CB) depends on the bitrate + that there are a few extra
features added for a few modes.  
Some of the AMR modes are compatible with fixed rate codecs, AMR122 is
compatible with the EFR codec, AMR67 is used in a Japanese cellular
system, still AMR is one codec.

Regards
/Ingemar

> From: Christian Hoene [mailto:[email-masked]] 
> Sent: den 21 oktober 2009 19:13
> To: 'Brian Rosen'
> Cc: [email-masked]
> > Please keep in mind that depending on the characteristics of the 
> > codec,
> you
> > don't want a lot of rate changes because it annoys the 
> user.  I've had 
> > one codec designer claim users weren't annoyed with relatively 
> > frequent
> changes
> Some years ago, we have done some tests with AMR. The 
> distortion caused by a change of the coding rate is roughly 
> as large as the distortion caused by a frame loss
> b.pdf). Consequently, frequent (multiple per second) mode 
> switches are not possible with AMR. However, frequent mode 
> changes may be triggered by transport protocols, which change 
> their frame rates typically after a round trip time.
> 
> The ITU-T G.718 codec was designed to allow frequent mode 
> switched without causing annoying artifacts. A similar 
> requirement is missing in the current 
> draft-valin-codec-requirements document. I did not read any 
> argument on why it was not included.
> 
> > Usually, if you encounter congestion, you can ratchet down, 
> and then 
> > you roughly never go back up.
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Oct 2009 10:44:06 +0300

Hi,

> codec what bit-rate to use.

RTP doesn't do congestion control either. DCCP would, but nobody's  
using it currently, mostly due to NAT traversal issues and lack of  
implementations.

Also, what we've learned from media over DCCP is that if you don't  
involve the codec in some form, performance/quality will be bad. Some  
codecs need time to adjust the rate. Some can only adjust it in pretty  
coarse steps. Etc. If you let DCCP adjust the rate blindly, without  
involving the codec in some form, you might get very good TCP  
friendliness, but maybe quality will suffer.

(And there is always the ramping up part - congestion control will  
never attempt to probe for more capacity unless the codec generates  
more data, and why would the codec do that if it's converged to  
transmit at some lower rate.)

> The point of layered codec for congestion in
> small bit-rate increments.

By no means should routers have to understand codec formats! Routers  
drop or mark IP packets. It is up to the application sending those IP  
packets to react appropriately to the marks or losses. In other words,  
a layered codec will see losses/marks to packets sent on all layers,  
and will then need to figure out whether to strip off a layer or not  
in response to whatever congestion level those losses/marks indicate.

> should change depending on congestion is actually not that codec- 

It *can* be non-codec-specific, see DCCP for example. But quality will  
suffer IMO.

> use without causing packets to be dropped.

Most Internet congestion control is based on *creating* losses/marks  
to determine capacity. People have tried to create congestion control  
schemes that avoid causing losses (delay-based schemed, for example),  
but they are perceived to be more fragile.

> Once you figure this out, you
> can just tell the codec to use that rate.

It's not that easy, because rates in the Internet are never stable -  
the rate computation is usually clocked by the RTT. You can obviously  
dampen this somehow, but you can never say "now I have found a rate  
that I can safely use forever."

> On top of that, the codec may be

I'm not sure this would work, because congestion control will  
basically change the VBR input parameter continuously.

Lars

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 22 Oct 2009 09:44:30 +0200

Hello Ingemar,

I made the tests some years ago. The raw data and the measurement scripts
are already on backup CDs. I will revive it. Please allow me some time
before I can send it to you. 

With best regards,

 Christian

--------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: Thursday, October 22, 2009 9:19 AM
> To: Christian Hoene; Jean-Marc Valin
> Cc: [email-masked]; Brian Rosen; Ingemar Johansson S
> Subject: RE: [codec] updated charter proposal
> 
> Hi Cristian, Jean-Marc
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Oct 2009 10:52:51 +0300

Hi,

> Security, architecture (IAB), etc.

I'm not saying it should focus on transport issues. I'm saying that  
because this effort is trying to spec "Internet codecs", these codecs  
should be better integrated with Internet transports than those done  
elsewhere, esp. when it comes to congestion response. The idea is that  
through that integration (or at least awareness) it should be possible  
to arrive at better quality under loss while still doing an  
appropriate congestion response.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Oct 2009 10:56:12 +0300

Hi,

...
>  aspects of packet transmission over the Internet.

Minor nit. I'd change both TSV WG and DCCP to TSV area, since it's not  
clear which WG this would land in (and there is a chance that DCCP  
will close soon).

Lars

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 22 Oct 2009 10:01:13 +0200 (CEST)

On Thu, 22 Oct 2009, Lars Eggert wrote:

> Most Internet congestion control is based on *creating* losses/marks to 
> determine capacity. People have tried to create congestion control 

I don't know exactly how the information should be handled at each layer, 
but taking into account jitter, delay, packet loss, ECN-bits set etc, the 
congestion signals seen by TCP should be available via similar mechanisms 
to a sound transport solution. I initially thought that the near constant 
rate over time nature of a sound transport stream (compared to the often 
bursty nature of TCP) would mean that it should "stand its ground", but I 
have now changed my opinion and I do think that the bitrate should be 
lowered when adverse network conditions are seen, even if it's only done 
in a few steps (low/mid/high or something like that).

This would mean that when links are filled with just sound streams, they 
can adapt when this link goes full by adapting the rate, and in case of 
congestion where there is a lot of TCP streams, at least we can play a 
little friendly by lowering the bitrate, even though it wont make much of 
a difference overall.

Also, it might make a big difference for a link that has a lot of voice 
traffic, if the packet per second rate could be decreased, so if the 
default is one packet per 20ms, going to one packet per 40ms halves the 
pps and lowers the bandwidth used because of less packet overhead (on a 
DSL link where it might be VoiceinRTPinIPinEthernetinATM, the overhead 
might well be hundreds of percent). So if the initial 50pps meant 16 bytes 
of voice per packet (which might in worst case conditions mean 3 ATM cells 
per packet), increasing this to 32 bytes at 25pps will decrease the 
bandwidth seen on the ATM layer from 63 kilobits/s to 32 kilobits/s (if 
the new packet still fits in 3 cells, otherwise it'll be 42 kilobit/s (4 
cells per packet)).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 22 Oct 2009 13:37:19 +0200

Dear Mr. Colin Perkins,

> any dependence on the signalling seems extreme. 

Some time ago, Alexander Chemeris was raising this issue.
http://www.ietf.org/mail-archive/web/codec/current/msg00508.html
He was complaining that there is a violation between transport and signaling
"layer" (or better plane) for some modern codecs - especially if the
signaling protocol has to store states about the negotiated coding mode.
This might causes problems if the signaling engine must renegotiate
transmission connections or if connections are to be forwarded. He was
telling me that the signaling part of a call forwarding engine must include
codec specific extension and that this should be avoided.

I have to admit that I did not fully understood his use-case but having a
clear split between signaling and transport states seems to be a good
approach to reduce system complexity.

With best regards,

 Christian

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Oct 2009 13:26:51 +0100

On 22 Oct 2009, at 12:37, Christian Hoene wrote:
>>> 4. Ensuring interoperability with Internet signalling technologies
>>> such as Session Initiation Protocol (SIP), Session Description  
>>> Protocol (SDP), and Extensible Messaging and Presence Protocol  
>>> (XMPP); however, signalling-dependent codecs are out of scope
>>
> He was complaining that there is a violation between transport and  
> signaling "layer" (or better plane) for some modern codecs -  
> especially if the signaling protocol has to store states about the  
> negotiated coding mode. This might causes problems if the signaling  
> engine must renegotiate transmission connections or if connections  
> are to be forwarded. He was telling me that the signaling part of a  
> call forwarding engine must include codec specific extension and  
> that this should be avoided.

RTP transport fundamentally relies on out-of-band signalling for some  
codec parameters.  That's unavoidable, but doesn't need to be a great  
source of complexity.

In the message you reference, Alexander's main concern seems to be  
that the RTP payload formats for AMR and AMR-WB rely on complex out-of- 
band signalling, while he would prefer in-band signalling with fewer  
options. It's true that those payload formats do make extensive use of  
out-of-band signalling, and suffer some complexity as a result, but  
this was very much an intentional design choice:

- There was a desire to support several different modes of operation,  
optimised for different use cases, which required incompatible packet  
formats, where the overhead of in-band signalling was considered too  
high.

- There was a desire to allow some end-points to not implement certain  
features and options of the payload format, and this required out-of- 
band signalling to determine end-point capabilities.

You may disagree with those design choices, but the working group was  
aware of the issues and the complexity of the out-of-band signalling  
at the time, and didn't believe that in-band signalling was  
appropriate. Some other payload formats have made different choices,  
and chosen a different trade-off; it depends on the codec, and the  
design of the RTP payload format.

-- 
Colin Perkins
http://csperkins.org/

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 22 Oct 2009 09:45:25 -0400

> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just want to be 
careful not to include in the codec things that don't belong there (e.g. a 
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will never 
> attempt to probe for more capacity unless the codec generates more data, 
> and why would the codec do that if it's converged to transmit at some 
> lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to 
probe for more capacity, then you tell the codec that it can use a higher 
rate. Now, if there's a special way in which you want to ask the codec, 
then maybe that can become an additional feature for the codec.

> packets to react appropriately to the marks or losses. In other words, a 
> layered codec will see losses/marks to packets sent on all layers, and 
> will then need to figure out whether to strip off a layer or not in 
> response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is 
why I was saying that IMO layered codecs aren't too useful for congestion 
control (though they have other uses). If there's nothing in the middle of 
the network to strip off the layers, then you might as well not have layers 
at all. All you need is to ask the sender to reduce the rate. You don't 
need layers to have a multi-rate codec. Layering just means that you can 
strip off bits and still have the result sound OK.

> It *can* be non-codec-specific, see DCCP for example. But quality will 

Well, we need to figure out the aspects that should be codec-specific and 
implement just those. Does anyone have a list of the issues codecs should 
be aware of?

> but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

> It's not that easy, because rates in the Internet are never stable - the 
> rate computation is usually clocked by the RTT. You can obviously dampen 
> this somehow, but you can never say "now I have found a rate that I can 
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that you 
can have one module that determines in real-time the best rate to use at 
that moment and then it tells the codec what to use. If it needs help from 
the codec, then we can define special functionality.

> I'm not sure this would work, because congestion control will basically 
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just means 
that you'd like to have an average of N kb/s for now, but you're OK if 
there are variations from frame to frame.

	Jean-Marc

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Oct 2009 08:53:38 -0600

On 10/22/09 1:56 AM, Lars Eggert wrote:
> clear which WG this would land in (and there is a chance that DCCP will
> close soon).

Done in my working copy. I'll post a revised version later today.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 22 Oct 2009 22:23:19 +0400

I am not that sure that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why
not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can
be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery? 

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered
nature, and router "has the right" to strip out layers in certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just want to
be 
careful not to include in the codec things that don't belong there (e.g.
a 
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never 

Well, the codec transmits at the rate you ask it to use. If you want to 
probe for more capacity, then you tell the codec that it can use a
higher 
rate. Now, if there's a special way in which you want to ask the codec, 
then maybe that can become an additional feature for the codec.

a 

> response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this
is 
why I was saying that IMO layered codecs aren't too useful for
congestion 
control (though they have other uses). If there's nothing in the middle
of 
the network to strip off the layers, then you might as well not have
layers 
at all. All you need is to ask the sender to reduce the rate. You don't 
need layers to have a multi-rate codec. Layering just means that you can

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and 
implement just those. Does anyone have a list of the issues codecs
should 
be aware of?

> Most Internet congestion control is based on *creating* losses/marks
to 

the 
> this somehow, but you can never say "now I have found a rate that I
can 

Oh, I never said we should set a rate forever. I was just saying that
you 
can have one module that determines in real-time the best rate to use at

that moment and then it tells the codec what to use. If it needs help
from 
the codec, then we can define special functionality.

> I'm not sure this would work, because congestion control will
basically 
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means 
that you'd like to have an average of N kb/s for now, but you're OK if 
there are variations from frame to frame.

	Jean-Marc

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 22 Oct 2009 12:09:51 -0700

Slava,

>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only one application.

Henry

On 10/22/09 1:23 PM, "Slava Borilin" <[email-masked]> wrote:

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 22 Oct 2009 23:12:57 +0400

Henry,

With all of my respect (you know) - this is too high-level consideration
and too generic statement which doesn't answer MPLS issue for example.

best regards,

Slava Borilin

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, October 22, 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Slava,

>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it
knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its
only one application.

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 22 Oct 2009 12:13:42 -0700

> not to leave this freedom to router as this may be more efficient for

The most obvious internet friendly way of accomplishing this would be to place separate layers in separate packets with distinct TOS markings so that they may be differentially dropped.  This would work on already deployed networks and networking equipment. 

However, even ignoring the problems created by the effect of independent jitter on these distinct flows,  the typical ratio of bitrates to packet rates for acceptable latency means that even with a single 'layer' the packets already have a lot of overhead (25% for 48kbit/sec into 20ms for IPv4). I would not expect doubling the packet rate (and overhead) just to achieve differential dropping to be a much of a win, compared to an alternative like sending every packet twice by including the previous packet in each frame.  

Client protocol RFCs which have expected widespread changes to infrastructure packet processing have not had a recent history of good success  (I.e. my ECN enabled client still hits problems accessing websites).

Expecting the general packet forwarding infrastructure to gain the ability to twiddle the codec bits is pretty much the opposite of what I would expect to do in a codec intended for the internet.

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 22 Oct 2009 12:18:22 -0700

Are there standards showing the linkage between MPLS and specific application components, such as codecs?

Henry

On 10/22/09 2:12 PM, "Slava Borilin" <[email-masked]> wrote:

Henry,
With all of my respect (you know) - this is too high-level consideration and too generic statement which doesn't answer MPLS issue for example.

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 22 Oct 2009 23:22:44 +0400

Again - my point is that router does NOT have to know that something specifically is the codec, or specific codec- the only goal is to let router aware that the stream (and every packet) is LAYERED, and that it is legitimate to strip out some layers if necessary due to congestion.

The content of such "layered" can be any - voice codec, video codec, audio codec, any type of content.

And I agree with Gregory - that having current infrastructure using layers in separate streams will require too much overhead (packets) which does not make sense as well - and I am thinking about one stream of packets comtaining all the layers, which, however, can be modified on the fly "in the middle".

So we may think about more generic concept of "declared layered content" which does NOT loose the information (well, most of it) by stripping out portions of the packet and reducing the traffic, so router can strip out any type of layered content, without going deep into specific codec.

Again- this is "naïve" suggestions from me (very limited engineer) - and definitely I am looking for objections even more then for agreement - for the sake of either finding the idea useful or making judged deny of it, and I agree that this concept is only one possible way of working with congestion.

best regards,

Slava Borilin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Slava Borilin
Sent: Thursday, October 22, 2009 11:13 PM
To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Henry,

best regards,

Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 22 Oct 2009 15:45:16 -0400

Hi Slava,

Slava Borilin wrote:
> Again - my point is that router does NOT have to know that something 
> specifically is the codec, or specific codec- the only goal is to let 
> router aware that the stream (and every packet) is LAYERED, and that it 
> is legitimate to strip out some layers if necessary due to congestion.
> 
> The content of such “layered” can be any – voice codec, video codec, 
> audio codec, any type of content.

One of the issues here is that not only does the router not know about the 
codec, but most (all?) routers don't even know about anything other than 
layer 3 (IP). It doesn't even know whether the packet transports UDP or 
TCP, much less whether there any media or anything. Routers are several 
orders of magnitude too dumb to strip some bits off a codec payload.

Cheers,

	Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 22 Oct 2009 23:49:10 +0400

Sure this is what we have now.
Question is when it comes to congestion - it is worth "teaching
routers", or this does not make sense from overall economy.

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 11:45 PM
To: Slava Borilin
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Hi Slava,

> audio codec, any type of content.

One of the issues here is that not only does the router not know about
the 
codec, but most (all?) routers don't even know about anything other than

Cheers,

	Jean-Marc

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Oct 2009 12:52:50 -0700

Jean-Marc Valin wrote:
>> router aware that the stream (and every packet) is LAYERED, and that
>> it is legitimate to strip out some layers if necessary due to congestion.
>>
> the codec, but most (all?) routers don't even know about anything other
> than layer 3 (IP). It doesn't even know whether the packet transports
> UDP or TCP, much less whether there any media or anything. Routers are
> several orders of magnitude too dumb to strip some bits off a codec
> payload.

Right, but one can imagine an IPv6 header that contains one or more offsets
related to the payload that would let a router aware of this extension that it
can shorten the packet to one of this offset if needed.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Oct 2009 21:15:42 +0100

Slava,

RTP has the concept of a translator, which performs the functions  
you're looking for in an application-layer middlebox, where it can be  
part of the signalling and/or security context. This is not something  
a router should do.

Colin

On 22 Oct 2009, at 20:22, Slava Borilin wrote:
> specifically is the codec, or specific codec- the only goal is to  
> let router aware that the stream (and every packet) is LAYERED, and  
> that it is legitimate to strip out some layers if necessary due to  
> congestion.
> And I agree with Gregory – that having current infrastructure using  
> layers in separate streams will require too much overhead (packets)  
> which does not make sense as well – and I am thinking about one  
> stream of packets comtaining all the layers, which, however, can be  
> modified on the fly “in the middle”.
> So we may think about more generic concept of “declared layered  
> content” which does NOT loose the information (well, most of it) by  
> stripping out portions of the packet and reducing the traffic, so  
> router can strip out any type of layered content, without going deep  
> into specific codec.
>
> Again- this is “naïve” suggestions from me (very limited engineer) –  
> and definitely I am looking for objections even more then for  
> agreement – for the sake of either finding the idea useful or making  
> judged deny of it, and I agree that this concept is only one  
> possible way of working with congestion.
>
> best regards,
> Slava Borilin
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf OfSlava Borilin
> With all of my respect (you know) – this is too high-level  
> consideration and too generic statement which doesn’t answer MPLS  
> issue for example.
>
> best regards,
> Slava Borilin
> >> able to do a bit better by providing a "service" to the other  
> layers.
> On

-- 
Colin Perkins
http://csperkins.org/

---

From: Thorvald Natvig <[email-masked]>
Date: Thu, 22 Oct 2009 22:25:11 +0200

Hi,

The problem with congestion control protocols is that they have limited 
implementation on consumer level hardware.

We've tried something as simple as setting the IP TOS byte to try to 
prioritize voice packets, and in practice very few home routers honor 
it, and there are quite a few wireless routers which silently discard 
frames with the TOS byte set. The reason we even tried this is that 
there is nothing we can do about our own stream to help the latency or 
congestion; the problem is usually that the user is also uploading quite 
a few torrents, so their uplink is completely full.

For most networks, the bottleneck is that first/last hop; it's the home 
users DSL/Cable connection, or a WiFi connection that has to compete 
with other networks on the same channel, or it could be the mobile 
users's connection to the tower. Beyond that point there is usually 
sufficient bandwidth that congestion doesn't occur.

I don't think this problem is going to improve; I can't think of any 
congestion control which can make my neighbour's WiFi network back off 
when I want to transmit high priority packets. So, while interfacing 
with congestion protocols and teaching routers about codecs may be 
something we'd like in an ideal world, it's more important to create a 
codec that will work in real world networks, which are congested and 
buggy, and are configured and used by non-technical people.

Best Regards,
Thorvald

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Oct 2009 07:49:39 +0200 (CEST)

> routers", or this does not make sense from overall economy.

IP was successful because the "network" didn't need to handle 
applications. Getting application specific tech into routers is a 5+ year 
waiting period (ECN still isn't there, and that's quite simple) and the 
direction routers are taking right now is bigger, faster and simpler, not 
the other way around.

So any proposal that relies on "the Internet" doing something special to 
your packets outside of what it already can do and what's in the pipe, 
will delay deployment for a long time.

Relying on ECN (optionally) for congestion signals might work though, 
that's been in the pipe for 5+ years and some adoption might happen.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Oct 2009 10:34:18 +0300

Hi,

On 2009-10-22, at 23:25, Thorvald Natvig wrote:
> prioritize voice packets

please understand that setting or honoring DSCPs is *not* congestion  
control. Congestion control requires a sender to lower the rate of a  
flow when that flow experiences packet loss (or ECN marks).

Lars

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 23 Oct 2009 07:22:13 -0700

>So any proposal that relies on "the Internet" doing something special to your packets
>outside of what it already can do and what's in the pipe, will delay deployment for a long time.

Actually for ever. See the Internet stats and the link to the NANOG presented slides:

http://www.telco2.net/blog/2009/10/perhaps_the_most_important_cha_1.html

Henry

On 10/23/09 12:49 AM, "Mikael Abrahamsson" <[email-masked]> wrote:

---

From: "Roni Even" <[email-masked]>
Date: Sat, 24 Oct 2009 11:54:08 +0200

Slava,

In SVC the terms for it is media-aware network elements  (MANEs) so adaption
can be done by the source, destination or by MANEs. Note that they need to
understand the structure of the payload and relations between the layers to
strip the right ones.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Slava Borilin
Sent: Thursday, October 22, 2009 9:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Again - my point is that router does NOT have to know that something
specifically is the codec, or specific codec- the only goal is to let router
aware that the stream (and every packet) is LAYERED, and that it is
legitimate to strip out some layers if necessary due to congestion.

The content of such “layered” can be any – voice codec, video codec, audio
codec, any type of content.

And I agree with Gregory – that having current infrastructure using layers
in separate streams will require too much overhead (packets) which does not
make sense as well – and I am thinking about one stream of packets
comtaining all the layers, which, however, can be modified on the fly “in
the middle”.

So we may think about more generic concept of “declared layered content”
which does NOT loose the information (well, most of it) by stripping out
portions of the packet and reducing the traffic, so router can strip out any
type of layered content, without going deep into specific codec.

Again- this is “naïve” suggestions from me (very limited engineer) – and
definitely I am looking for objections even more then for agreement – for
the sake of either finding the idea useful or making judged deny of it, and
I agree that this concept is only one possible way of working with
congestion.

best regards,

Slava Borilin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Slava Borilin
Sent: Thursday, October 22, 2009 11:13 PM
To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Henry,

With all of my respect (you know) – this is too high-level consideration and
too generic statement which doesn’t answer MPLS issue for example.

best regards,

Slava Borilin

  _____  

Slava,

>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows
nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only
one application.

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4532 (20091022) __________

http://www.eset.com

---

From: Koen Vos <[email-masked]>
Date: Sun, 25 Oct 2009 06:38:46 -0700

At a given quality level, the bitrate for encoding speech/audio with  
layers is typically 10~50% higher than without layers.  So layered  
coding may in fact cause congestion, and reducing the bitrate at the  
encoder is probably better.

koen.

Quoting Slava Borilin:

> And I agree with Gregory - that having current infrastructure using  
> which does not make sense as well - and I am thinking about one  
> modified on the fly "in the middle".
>
> So we may think about more generic concept of "declared layered  
> content" which does NOT loose the information (well, most of it) by  
> Again- this is "naïve" suggestions from me (very limited engineer) -  
> agreement - for the sake of either finding the idea useful or making  
> Behalf Of Slava Borilin
> With all of my respect (you know) - this is too high-level  
> consideration and too generic statement which doesn't answer MPLS  
> issue for example.
>
>
>
> best regards,
>
> Slava Borilin
>

---

From: Jozsef Vass <[email-masked]>
Date: Mon, 26 Oct 2009 10:55:47 -0700

I do not like the idea of sending multiple layers in a packet either. I feel very uncomfortable of routers modifying packets. It is OK not to deliver, but delivering semantically modified packet is not expected.

Using layers for video totally makes sense where the rates are much higher and layers can be transported in separate packets.

Jozsef

________________________________
From: Slava Borilin [mailto:[email-masked]]
Sent: Thursday, October 22, 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

best regards,
Slava Borilin

Henry,

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 26 Oct 2009 11:15:00 -0700

I think that we have a terminology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is
they don¹t modify IP packets.  Boxes that look deep into the IP packets, and
(potentially) modify them, are higher layer devices.  After long discussions
in AVT at the time, RFC 3984 and its successors call those boxes ³Media
Aware Network Elements², MANEs.  MANEs modify packets at the application
layer, for example to remove layers, re-package H.264 NAL units to adapt to
different MTU sizes, and do all kinds of other things that violate the
end-to-end principle.  A MANE has business in looking into, and potentially
modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it¹s IMO totally acceptable (from both an
abstract layering theory viewpoint and in practice) that packets are being
opened and the content is repackaged.  It¹s actually common practice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <[email-masked]> wrote:

> I do not like the idea of sending multiple layers in a packet either. I feel
> very uncomfortable of routers modifying packets. It is OK not to deliver, but
> delivering semantically modified packet is not expected.
>  
> Using layers for video totally makes sense where the rates are much higher and
> layers can be transported in separate packets.
>  
> Jozsef
>  
> 
> 
> aware that the stream (and every packet) is LAYERED, and that it is legitimate
> to strip out some layers if necessary due to congestion.
> The content of such ³layered² can be any  voice codec, video codec, audio
> And I agree with Gregory  that having current infrastructure using layers in
> separate streams will require too much overhead (packets) which does not make
> sense as well  and I am thinking about one stream of packets comtaining all
> the layers, which, however, can be modified on the fly ³in the middle².
> So we may think about more generic concept of ³declared layered content² which
> does NOT loose the information (well, most of it) by stripping out portions of
> the packet and reducing the traffic, so router can strip out any type of
> layered content, without going deep into specific codec.
>  
> Again- this is ³naïve² suggestions from me (very limited engineer)  and
> definitely I am looking for objections even more then for agreement  for the
> sake of either finding the idea useful or making judged deny of it, and I
> agree that this concept is only one possible way of working with congestion.
>  
> 
> best regards,
> Slava Borilin
> 
> 
> With all of my respect (you know)  this is too high-level consideration and
> too generic statement which doesn¹t answer MPLS issue for example.
>  
> 
> best regards,
> Slava Borilin
> 
>

---

From: "Slava Borilin" <[email-masked]>
Date: Mon, 26 Oct 2009 23:58:58 +0300

Well, if we change "routers" to MANEs, the whole story of layering start to make more sense?

best regards,

Slava Borilin

From: Stephan Wenger [mailto:[email-masked]] 
Sent: Monday, October 26, 2009 9:15 PM
To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: Re: [codec] updated charter proposal

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is they don't modify IP packets.  Boxes that look deep into the IP packets, and (potentially) modify them, are higher layer devices.  After long discussions in AVT at the time, RFC 3984 and its successors call those boxes "Media Aware Network Elements", MANEs.  MANEs modify packets at the application layer, for example to remove layers, re-package H.264 NAL units to adapt to different MTU sizes, and do all kinds of other things that violate the end-to-end principle.  A MANE has business in looking into, and potentially modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it's IMO totally acceptable (from both an abstract layering theory viewpoint and in practice) that packets are being opened and the content is repackaged.  It's actually common practice.

Stephan

 
 
Jozsef

 

best regards,
Slava Borilin

Henry,

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: Jozsef Vass <[email-masked]>
Date: Mon, 26 Oct 2009 14:09:01 -0700

In rfc 3984 processing packets by mane has some clear benefits, e.g., discarding packets that the decoder would describe anyways (section 7.3), dropping packets in case of congestion, etc.

Here, we mostly talking about reducing packet size, and I am not sure how beneficial it is regarding the overall system. Consider speex. Quality level six, wideband and narrowband encoder produces 52 bytes and 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 bytes. Since packet rate is the same, I do not think it will affect congestion too much. Please also consider that processing packets by intermediary, adds additional delay.

Jozsef

Sent: Monday, October 26, 2009 11:15 AM

Stephan

Jozsef

best regards,
Slava Borilin

Henry,

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Tue, 27 Oct 2009 00:13:46 +0300

Speex is not layered, isn't it?

best regards,

Slava Borilin

From: Jozsef Vass [mailto:[email-masked]] 
Sent: Tuesday, October 27, 2009 12:09 AM
To: Stephan Wenger; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: RE: [codec] updated charter proposal

Jozsef

Stephan

 
 
Jozsef

 

best regards,
Slava Borilin

Henry,

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: Jozsef Vass <[email-masked]>
Date: Mon, 26 Oct 2009 14:23:31 -0700

>From speex manual (http://www.speex.org/docs/manual/speex-manual/node4.html#SECTION00410000000000000000):
Integration of narrowband and wideband using an embedded bit-stream

Jozsef

________________________________
From: Slava Borilin [mailto:[email-masked]]
Sent: Monday, October 26, 2009 2:14 PM
To: Jozsef Vass; Stephan Wenger; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: [email-masked]
Subject: RE: [codec] updated charter proposal

best regards,
Slava Borilin

Jozsef

Stephan

Jozsef

best regards,
Slava Borilin

Henry,

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Tue, 27 Oct 2009 00:26:56 +0300

I also think that we are talking not only about packet size, but only packet rate as well?

best regards,

Slava Borilin

Jozsef

Stephan

 
 
Jozsef

 

best regards,
Slava Borilin

Henry,

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 26 Oct 2009 14:28:44 -0700

I think that these arguments boil down to the discussion of measurement of
congestion in the packet count domain or in the bitrate domain.  I don¹t
think there¹s a verdict yet which of the two are really important.  It may
very well depend on your viewpoint and on what your company makes money of.

When operating in low delay environments (as it is the assumption here), I
agree that there is not much point in attempting to reduce the packet
count---doing so would increase delay and would presumably be unacceptable
to the application.  Therefore, congestion friendliness, when congestion is
measured in the packet count domain, seems to be independent from the codec
characteristics; as long as the codec is optimized for low delay.

However, if we start from the assumption that congestion is measured in the
bitrate domain, then the ballgame is somewhat different.  Yes, when we drop
a layer from a hypothetical layered audio codec, we would not safe a lot of
bits in absolute numbers, and yes, the percentage would be even more
disappointing considering the packetization overhead.  But still, we would
reduce the overall bitrate.  If you have thousands or millions of sessions
on the same fiber, dropping layers could be argued to make a difference.

Stephan 

On 10/26/09 2:09 PM, "Jozsef Vass" <[email-masked]> wrote:

> In rfc 3984 processing packets by mane has some clear benefits, e.g.,
> discarding packets that the decoder would describe anyways (section 7.3),
> dropping packets in case of congestion, etc.
>  
> Here, we mostly talking about reducing packet size, and I am not sure how
> beneficial it is regarding the overall system. Consider speex. Quality level
> six, wideband and narrowband encoder produces 52 bytes and 28 bytes of
> payload, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68
> bytes. Since packet rate is the same, I do not think it will affect congestion
> too much. Please also consider that processing packets by intermediary, adds
> additional delay.
>  
> Jozsef
>  
> 
> 
> Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is they
> don¹t modify IP packets.  Boxes that look deep into the IP packets, and
> in AVT at the time, RFC 3984 and its successors call those boxes ³Media Aware
> Network Elements², MANEs.  MANEs modify packets at the application layer, for
> example to remove layers, re-package H.264 NAL units to adapt to different MTU
> sizes, and do all kinds of other things that violate the end-to-end principle.
> A MANE has business in looking into, and potentially modifying, IP/UDP/RTP
> packets, a router has not.
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 26 Oct 2009 17:30:17 -0400

Speex has an embedded bit-stream with a narrowband base and a wideband
"layer" on top. However, it is not possible to change the rate of the
narrowband or wideband "layers" by removing bits. It is only possible to
remove the entire wideband layer. This has the advantage of not
introducing a large cost in terms of bit-rate, while still making it
easy to decode a wideband stream in narrowband mode. That being said,
I'm aware that SILK (and probably IP-MR and BV32, but I haven't heard
samples) out-perform Speex in terms of quality vs rate.

	Jean-Marc

Slava Borilin a écrit :
> Speex is not layered, isn’t it?
> 
>  
> 
> best regards,
> 
> Slava Borilin
> 
> ------------------------------------------------------------------------
> 
> *From:* Jozsef Vass [mailto:[email-masked]]
> *Sent:* Tuesday, October 27, 2009 12:09 AM
> *To:* Stephan Wenger; Slava Borilin; Henry Sinnreich; Jean-Marc Valin;
> Lars Eggert
> *Cc:* [email-masked]
> *Subject:* RE: [codec] updated charter proposal
> 
>  
> 
> discarding packets that the decoder would describe anyways (section
> 7.3), dropping packets in case of congestion, etc.
> 
>  
> 
> Here, we mostly talking about reducing packet size, and I am not sure
> how beneficial it is regarding the overall system. Consider speex.
> Quality level six, wideband and narrowband encoder produces 52 bytes and
> 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from
> 92 bytes to 68 bytes. Since packet rate is the same, I do not think it
> will affect congestion too much. Please also consider that processing
> packets by intermediary, adds additional delay.
> 
>  
> 
> Jozsef
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Stephan Wenger [mailto:[email-masked]]
> *Sent:* Monday, October 26, 2009 11:15 AM
> *To:* Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars
> Eggert
> *Cc:* [email-masked]
> *Subject:* Re: [codec] updated charter proposal
> 
>  
> 
> they don’t modify IP packets.  Boxes that look deep into the IP packets,
> and (potentially) modify them, are higher layer devices.  After long
> discussions in AVT at the time, RFC 3984 and its successors call those
> boxes “Media Aware Network Elements”, MANEs.  MANEs modify packets at
> the application layer, for example to remove layers, re-package H.264
> NAL units to adapt to different MTU sizes, and do all kinds of other
> things that violate the end-to-end principle.  A MANE has business in
> looking into, and potentially modifying, IP/UDP/RTP packets, a router
> has not.
> 
> When MANEs are in the picture, it’s IMO totally acceptable (from both an
> abstract layering theory viewpoint and in practice) that packets are
> being opened and the content is repackaged.  It’s actually common practice.
> 
> Stephan
> 
> I do not like the idea of sending multiple layers in a packet either. I
> feel very uncomfortable of routers modifying packets. It is OK not to
> deliver, but delivering semantically modified packet is not expected.
>  
> Using layers for video totally makes sense where the rates are much
> higher and layers can be transported in separate packets.
>  
> Jozsef
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Slava Borilin [mailto:[email-masked]]
> *Sent:* Thursday, October 22, 2009 12:23 PM
> *To:* Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
> *Cc:* [email-masked]
> *Subject:* Re: [codec] updated charter proposal
> 
> which does not make sense as well – and I am thinking about one stream
> of packets comtaining all the layers, which, however, can be modified on
> the fly “in the middle”.
> portions of the packet and reducing the traffic, so router can strip out
> any type of layered content, without going deep into specific codec.
>  
> definitely I am looking for objections even more then for agreement –
> for the sake of either finding the idea useful or making judged deny of
> it, and I agree that this concept is only one possible way of working
> with congestion.
>  
> 
> best regards,
> Slava Borilin
> 
> ------------------------------------------------------------------------
> 
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Slava Borilin
> *Sent:* Thursday, October 22, 2009 11:13 PM
> *To:* Henry Sinnreich; Jean-Marc Valin; Lars Eggert
> *Cc:* [email-masked]
> *Subject:* Re: [codec] updated charter proposal
> 
> Henry,
> With all of my respect (you know) – this is too high-level consideration
> and too generic statement which doesn’t answer MPLS issue for example.
>  
> 
> best regards,
> Slava Borilin
> 
> ------------------------------------------------------------------------
> 
> *From:* Henry Sinnreich [mailto:[email-masked]]
> *Sent:* Thursday, October 22, 2009 11:10 PM
> *To:* Slava Borilin; Jean-Marc Valin; Lars Eggert
> *Cc:* [email-masked]
> *Subject:* Re: [codec] updated charter proposal
> 
> Slava,
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: Jozsef Vass <[email-masked]>
Date: Mon, 26 Oct 2009 14:28:02 -0700

Sorry, my link was stripped. As per speex documentation and my experience, one of the features of speex is "Integration of narrowband and wideband using an embedded bit-stream"

Jozsef

best regards,
Slava Borilin

Jozsef

Stephan

Jozsef

best regards,
Slava Borilin

Henry,

best regards,
Slava Borilin

Slava,

Henry

best regards,
Slava Borilin

-----Original Message-----

never

a

to

the

basically

        Jean-Marc

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Mon, 26 Oct 2009 17:48:53 -0400

Stephan Wenger wrote:
> to the application.

If decreased packet count is necessary in order for my VoIP session to
work on the connection I'm using, then of course I want my client to
reduce the packet count.  Increased delay is better than no connection.
As is usual on the internet, graceful degradation is almost always
preferable to terminating a session and throwing up a

"WARNING: Latency guarantee could not be satisfied."

> If you have thousands or millions of sessions

Again, you don't seem to be talking about the public internet.  Even on a
private network, I still don't see much of an argument for layering.  The
bitrate reduction could more easily be achieved at the encoder.  Moreover,
layered encoding is typically less efficient than "unlayered" encoding at
any particular bitrate.

The only sensible argument I'm aware of for layered streams is in
heterogeneous multicast networks.  We can revisit this issue if multicast
ever becomes widely available on the public internet

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Oct 2009 12:57:50 +0200

Hi,

On 2009-10-26, at 23:28, Stephan Wenger wrote:
> I think that these arguments boil down to the discussion of  
> measurement of congestion in the packet count domain or in the  
> bitrate domain.  I don’t think there’s a verdict yet which of the  
> two are really important.  It may very well depend on your viewpoint  
> and on what your company makes money of.

FYI, http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest  
discusses byte vs. packet congestion in more detail. It talks about  
the generic data transport case and not specifically media traffic  
though.

> When operating in low delay environments (as it is the assumption  
> here), I agree that there is not much point in attempting to reduce  
> the packet count---doing so would increase delay and would  
> presumably be unacceptable to the application.  Therefore,  
> congestion friendliness, when congestion is measured in the packet  
> count domain, seems to be independent from the codec  
> However, if we start from the assumption that congestion is measured  
> in the bitrate domain, then the ballgame is somewhat different.   
> Yes, when we drop a layer from a hypothetical layered audio codec,  
> we would not safe a lot of bits in absolute numbers, and yes, the  
> percentage would be even more disappointing considering the  
> packetization overhead.  But still, we would reduce the overall  
> bitrate.  If you have thousands or millions of sessions on the same  
> fiber, dropping layers could be argued to make a difference.

Lars