Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 02 Oct 2000 15:32:45 +0200

Hello,

The payload format is designed with IP networks in mind. The problem we see is
that IP is transported over a wide range of different links with different
behavior, e.g. different radio and wireline links. Radio and wire do not have
the same error characteristics. AMR will be widly used over wireless links and
on these links bandwidth efficiency is extremely important. This lead to the
bitwise sorting. Octet sorting needs octet alignement for each block of the
payload, i.e. padding at the end of each block. Which we considered to be to
expensive. The optional sensitivity sorting facilitates the use of different
error robustness schemes. The need for different robustness enhancing schemes
may depend on the application and the lower transport layers. The application
can be for example conversational speech or streaming. Lower layers are here
layer 1 and 2.

Regards

Magnus W.

Qiaobing Xie wrote:

> Magnus,
>
> Correct me if I am wrong, but I find hard to understand your reasoning.
>
> What you are saying is basically that, in order to make the current
> payload format design general enough and flexible enough to be used "for
> a wide range of networks and applications" and with "any mechanism that
> exploit" unequal bit sensitivity, you've chosen to compromise the
> implementation efficiency and performance (and even some functionality)
> for AMR over RTP/whatever-partial-checksum-UDP/IP.
>
> I think it should be the other way around - the AMR payload design
> should primarily focus on finding the optimal solution for
> AMR/RTP/UDP*/IP. It doesn't sound right to me for IETF AVT WG to design
> something that is meant for a wide range of networks but is
> suboptimal/compromised (even functionally handicapped) for IP networks.
>
> Regards,
> -Qiaobing Xie
>
> Magnus Westerlund wrote:
> >
> > Dear Qiaobing, everyone,
> >
> > The unequal error protection/correction scheme is not designed just for
> > UDP-Lite. Any mechanism that can exploit the fact that the data is
> > sorted in sensitivity order is possible to use, e.g. a partial FEC
> > scheme based on the same techniques as RFC2733.
> >
> > We have made some design choices that makes the payload format flexible
> > and bit efficient, i.e. usefull for a wide range of networks and
> > applications.
> >
> > Best regards
> >
> > Magnus Westerlund
> >
> > Qiaobing Xie wrote:
> >
> > > Hello, everyone:
> > >
> > > I have some serious concerns on the design of the AMR payload format as
> > > defined in <draft-ietf-avt-rtp-amr-00.txt>. In brief, the design seems
> > > very limiting in terms of taking advantage of the error tolerant
> > > features built into the AMR codec algorithm. Also, it seems that not
> > > enough consideration has been given to implemenation efficiency and
> > > performance.
> > >
> > > Since my concerns are rather fundamental to the design, the email is a
> > > little long, please bear with me..
> > >
> > > 1) Basic idea
> > >
> > > The basic idea of the draft is to transport AMR frames over IP in an RTP
> > > payload, i.e., AMR-frame/RTP/UDP/IP. I have no problem with that.
> > >
> > > Therefore, the packet *passed to the UDP layer* will contain three types
> > > of bits:
> > >
> > >    +--------------+
> > >    | header bits  |
> > >    +--------------+
> > >    | Class A bits |
> > >    |    and/or    |
> > >    |  other bits  |
> > >    +--------------+
> > >
> > > Here, the "header bits" will include all the AMR speech frame control
> > > bits (ie., frame header), the RTP payload header bits, and the RTP
> > > header bits.
> > >
> > > "Class A bits" is the most sensitive coded speech data bits, as defined
> > > by the AMR codec. The "other bits" (also called Class B and C bits in
> > > AMR terminology) are less sensitive coded speech data bits.
> > >
> > > 2) Problems with the current AMR payload format design
> > >
> > > The design in the current draft apparently was guided under the
> > > misconception that the "Class A bits" of an AMR speech frame need to be
> > > delivered error-free, and if that part of the frame is corrupted the
> > > whole frame should be tossed. This is not correct.
> > >
> > > What the AMR codec really wants from the transport is: "if Class A bits
> > > is found corrupted in a frame, raise a Bad Frame flag but still pass the
> > > whole frame to the decoder since the decoder still may want to use Class
> > > B and C bits to help error concealment." The purpose of the flag is to
> > > tell the decoder that Class A bits are bad and do not use them.
> > >
> > > However, the draft seems to suggest on the use of a partial checksum
> > > (such as the one provided by the proposed UDP-lite) to protect the
> > > "header bits" AND the "Class A bits" at the transport leverl. This means
> > > if Class A bits have any error, the whole packet will be tossed by the
> > > transport. Even worse, if the packet is a compound payload, you will
> > > have all the AMR frames tossed by the transport if a bit error occurs in
> > > the Class A bits of any one of the enclosed frames.
> > >
> > > It becomes more problematic when, in order to support multiple AMR
> > > frames in a compound RTP payload and to use
> > > the partial checksum, a *very ugly* bit-wise shuffling scheme is
> > > proposed to copy (bit by bit) all the "Class A bits" of each enclosed
> > > AMR speech frame to the front of the packet!! The hugely computational
> > > intensive operation is required no each RTP packet on both ends of the
> > > RTP session.
> > >
> > > 3) A better way to do it:
> > >
> > > To get what AMR codec wants, we should only checksum the "header bits",
> > > and carry an 8-bit CRC in the AMR frame header to cover the "Class A
> > > bits" of the frame. This CRC is for the RTP receiver (that is above the
> > > transport) to verify the integrity of the Class A bits and to raise the
> > > Bad Frame flag before passing the AMR frame to the decoder.
> > >
> > > In other words,
> > >
> > >  1. Partial checksum at the transport level to cover all the "header
> > >     bits" -- if checksum fails, toss the whole packet.
> > >  2. CRC in AMR frame header to cover the "Class A bits" -- if CRC fails,
> > >     raise the bad frame flag.
> > >  3. No error checking on the "other bits".
> > >
> > > When bundling multiple AMR frames in one RTP packet (the compound
> > > payload), we should use a table of contents (TOC) structure to avoid
> > > bit-wise copying (AMR frames are bit-stuffed to byte boundary). and then
> > > use the transport level checksum to cover the header bits and TOC bits
> > > only (the Class A CRC of each AMR frame is in the TOC).
> > >
> > >    +------------------+
> > >    | RTP header bits  |  -- RTP and payload headers
> > >    +------------------+
> > >    | Table of Contents|  -- list of frame headers of the
> > >    +==================+ \   included AMR frames
> > >    | Fmr1 Cls A bits  |  \
> > >    +------------------+  |
> > >    | Fmr1 Cls B bits  |  |
> > >    +------------------+  |
> > >    | Fmr1 Cls C bits  |  |
> > >    +==================+  |
> > >    | Fmr2 Cls A bits  |   > not covered by transport level chksum
> > >    +------------------+  |
> > >    | Fmr2 Cls B bits  |  |
> > >    +------------------+  |
> > >    | Fmr2 Cls C bits  |  |
> > >    +==================+  |
> > >    | Fmr3 Cls A bits  |  /
> > >    +------------------+ /
> > >          .....
> > >          .....
> > >
> > > This way, you get what the AMR codec asks for and yet avoid bit-wise
> > > copying.
> > >
> > > ===============================================================
> > >   Qiaobing Xie, Ph.D
> > >   Principal Staff Engineer
> > >   Network Architecture & Technology
> > >   Motorola, Inc.
> > >   TEL: (847) 632-3028
> > > ===============================================================
> >
> > --
> >
> > Magnus Westerlund
> >
> > Audio Technology, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson Radio Systems AB  | Phone +46 8 4048287
> > Torshamsgatan 23           | Fax   +46 8 7575550
> > S-164 80 Stockholm, Sweden | mailto: [email-masked]

--

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 02 Oct 2000 18:49:07 -0500

Hi, Magnus,

See my comments below....

Magnus Westerlund wrote:
> expensive. 

This further convinces me that the current design presented in the AMR
draft is a radio-link-centric design, which is wrong in my opinion,
because:

1) bandwidth efficiency over wireless links is more of a concern for 
ROHC working group. Architecturally, it should be delt with below IP by
header compression/stripping, as being worked upon in rohc. It doesn't
belong to RTP payload layer (unless it is something facilitating the
underlying header compression/stripping).

2) AMR itself is not specfic to radio links, it is a general purpose
codec. It is in the best interest of the AVT working group to define a
*general* RTP payload format for carrying AMR speech over any IP
connection, not something optimized for radio links only. This is why I
am against the bitwise sorting - it may be inevitable for a radio link
(even for radio links, it is expensive and often done at a lower layer
by DSP or with hardware assistance), but it is a magnitude more
expensive than byte-oriented handling to most applications running on a
general purpose machine.

> The optional sensitivity sorting facilitates the use of different

Since the bitwise sorting is so expensive, I think it is more than
necessary that you justify it by showing exactly what "robustness
echancing schemes" you have in mind and exactly how they would work
together.

Here you also brought out another concern of mine: the current design
put no consideration on frame quality classification support (you would
need CRC and bad frame indicator to do so, as I pointed out in my
original email). Is this because you assume those functions are provided
by "the lower transport layers", such as by the Iu-UP protocols defined
in 3GPP? Unfortunately, in a general IP network, there is no such
support from the transport layer. In order to make the AMR over IP work
effectively over any IP connections (not only for a 3GPP Iu-UP
interface), you will need to support those functions in your RTP 
payload format.

regards,
-Qiaobing

---

From: Krister Svanbro <[email-masked]>
Date: Wed, 04 Oct 2000 17:05:26 +0200

Qiaobing, Magnus and others, 

I am Krister Svanbro and work mainly in the ROHC WG. 
I noticed that the ROHC WG name was mentioned below and 
thought I perhaps could bring some information from a ROHC point of
view, which might help somewhat in this issue.

The ROHC WG has spent year 2000 on mainly developing a robust header 
compression scheme for RTP/UDP/IP. We have also created a framework 
based on compression profiles to enable development of other 
compression profiles such as compression of TCP/IP the coming year.

The term robust origins from that fact we realised that we need to 
design header compression schemes more robust to make them cope with 
the relative large amount of packet loss that occur in e.g. cellular 
systems. That does not, however, preclude in any way the usage of 
the ROHC scheme in other types of (possible error prone) 
environments.

We have to this date not looked upon compression of RTP 
payloadformats and we do not plan to that either. I also think that 
there should not be any need for compression of payloadformats. They 
should be as efficient as possible from the beginning. AMR is 
certainly a highly interesting codec in usage together with ROHC 
to enable VoIP to a mobile, hence it is important that the 
AMR format is efficient and does not waste any bits.
It becomes kind of strange if we in the ROHC WG maximize compression
efficiency with rather sofisticated methods to enable to go down
to a compressed header size of 1 byte for the IP/UDP/RTP header, and 
then is 1 byte extra used for the RTP payloadformat only.

Hence, I would like to encourage you to keep efficiency in mind 
when developing this payload format. I look forward to see the 
results of this work.

Cheers, 

/ Krister

---

From: Mikael Degermark <[email-masked]>
Date: Wed, 04 Oct 2000 23:23:19 +0200

ROHC WG co-chair speaking.

I have a couple of comments to this letter:

>> ROHC working group.

That statement is too general. ROHC deals with the efficient transmission of 
the RTP/UDP/IP header. The payload format is NOT a concern of the ROHC WG.
If a payload format is to be efficient over a wireless link, it must be made so by
others than ROHC. 

>>         Architecturally, it should be delt with below IP by

Architecturally speaking (and here I remove my ROHC chair hat), bandwidth
efficiency over wireless links will best be obtained by 

a) having an efficiently compressed payload, which might be somewhat resilient to 
errors introduced by the wireless link.

b) compressing the RTP/UDP/IP header robustly and efficiently.

ROHC deals with b). Others, perhaps you people, need to deal with a). 
The best result will be obtained if a) is done close to the application,
i.e., above the IP layer. a) is certainly not the task of ROHC, and neither should
it be.

The IETF should not worry ONLY about wireless, of course, but it certainly
seems appropriate to ensure that things work over wireless as well as over
the rest of the currently largely wired Internet.

Cheers, 

Mikael Degermark

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 04 Oct 2000 17:41:11 -0500

Mikael and Krister (and other ROHCers on the list):

Ok, I know I was getting myself in trouble when I mentioned the
"dreadful" word ROHC :-) :-) 

Mikael Degermark wrote:
...snip...
> i.e., above the IP layer. a) is certainly not the task of ROHC, and neither should

I think we are in "violent" agreement here :) 

The point I was trying to make is, when you are looking at optimizing
the bandwidth efficiency over a *link* with a unique error
characteristics, the framework/approach used by ROHC is more
appropriate, which is to look for header compression/stripping solutions
below the IP layer. This matches your b) above. 

But if you are designing an RTP payload format, which is meant to be
sent end-to-end over a routable IP connection, it does not make much
sense to optimize the payload format design according to the error
characteristics of any one type of the link which, after all, may or may
not be present in the connection. 

I have not problem with a) and I think it is in deed the job of AVT WG.
No doubt that it is universally desirable to design any protocol message
as compact and as compressed as possible (as Krister said: not to waste
a bit)  But in reality, you often have to make trade-off between saving
a bit in the message and the associated processing cost, especially when
the processing is done in a higher stack layer. The error resilience
part (or the lack of it) in the current AMR draft is exactly one of my
big concerns as I talked about in my first email. 

Cheers,
-Qiaobing

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 05 Oct 2000 04:30:33 +0200

At 05:41 PM 10/4/00 -0500, Qiaobing Xie wrote:
(snip)

>not be present in the connection. 

If one expects that a common case will be that the payload is sent across
such links, it may make a lot of sense. But this is of course difficult to 
predict. 

>the processing is done in a higher stack layer. 

The tradeoff is between the cost of sending the bits across the link and
the processing cost at the sender/receiver. As the end user will ultimately 
pay for both, one has to consider the relative costs.

When the amr format is used for voice, it seems that either of two
scenarios will occur:

1) users use some sort of mobile terminal.
2) users use stationary terminals.

For 1, the cost of bandwidth is very likely to be higher than the processing cost
if the mobile uses cellular radio.

For 2, the cost of bandwidth is very low, but on the other hand 
the incremental processing cost is zero when something like a PC is used
as the stationary terminal. 

So this very simple analysis does seem to favor a high degree of compression. 

>The error resilience

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Oct 2000 10:23:37 +0200

Hello everyone!

We agree with the comments from Mikael Degermark, and would like to address some
issues raised in the last days:

1) AMR is of course suitable for a multitude of applications. We know
that it will be used for wireless and also over internet. The wireless
case is important and in this case saving an octet per packet is very
desirable. Therefore, bandwidth efficiency should be prioritiesed.

2) The IAB supports, as I see it, the design of bandwidth efficient
solutions, see e.g. section 3.8 in
http://www.ietf.org/internet-drafts/draft-iab-wirelessws-01.txt .

3) What is to complex? We have compared the payload packetization with
the speech codec.  We are using the optimized official ETSI/3GPP
floating point AMR codec and an unoptimized payload packetizer. The load
is expressed in percent of an Windows NT machine with a Pentium III 500 MHz
processor.

Speech encoder: 7.1%
Payload packetizer: 0.058 %
Payload depacketizer: 0.058 %
Speech decoder: 1.1%

All figures are for the AMR mode with the most complex packetization and
the least favorable number of frames per packet, i.e. worst case for
the payload packetizer.

The data bits are already reshuffled bitwise in the speech encoder. If the robust
sorting is done in conjunction with the reshuffling in the speech encoder the extra
complexity would decrease.

Note also that the default operation is the simple and not the robust sorting.

4) UEP/UED schemes under development that can utilise the fact that the payload is
sorted in error sensitivity order.

The UDP Lite Protocol,
http://search.ietf.org/internet-drafts/draft-larzon-udplite-03.txt

An RTP Payload Format for Generic FEC with Uneven Level Protection,
http://search.ietf.org/internet-drafts/draft-li-ulp-00.txt

An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia
Streams, http://search.ietf.org/internet-drafts/draft-lnt-avt-uxp-02.txt

Best regards

Magnus Westerlund