Subject: [AVT] draft-ietf-avt-rtp-amr-bis-00.txt

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 08 Dec 2004 19:10:50 +0000

I've just been doing a little reading of drafts from other WGs and had some 
questions about the design rationale of the above ID:

I notice that in section 4.4.2.1, it says:

    "The frame CRC, when used, MUST be calculated only over all class A
     bits in the frame.  Class B and C bits in the frame MUST NOT be
     included in the CRC calculation and SHOULD NOT be covered by the
     transport checksum."

I wonder if this could be justified?

At first read, this seems to go exactly the opposite way to what was written 
in UDP-Lite [RFC3828], section 4.

    ...."For a link that supports
    partial error detection, the Checksum Coverage field in the UDP-Lite
    header MAY be used as a hint of where errors do not need to be
    detected.  Lower layers MUST use a strong error detection mechanism
    [RFC-3819] to detect at least errors that occur in the sensitive part
    of the packet, and discard damaged packets."

So my take on this was, UDP-Lite says you MUST perform a check on the IP 
headers, and any fields covered by the Checksum coverage, but that you MAY 
relax this to only cover the Checksum coverage for UDP-Lite frames. If we're 
changing the recommendation, then this introduces new issues that really need 
to be discussed.

Later, the ID also says:

    "Packets SHOULD be discarded if the transport layer checksum detects
     errors."

- Is there any justification why that is not a MUST be discarded, since the 
check indicates the header IS mangled, and therefore there is little 
confidence in using the packet header? Again it seems the opposite to 
envisaged with UDP-Lite. Where UDP-Lite says, section 6:

    ..."Corruption of any bit within
    the protected area will then result in the IP receiver discarding the
    UDP-Lite packet."

I'm not sure if this was a mistake or a design strategy. Can you tell me?

Best wishes,

Gorry Fairhurst

(please cc me directly as well as via the list - so I can pick up the thread).

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 09 Dec 2004 11:18:16 +0100

Hi Gorry,

I hope that you are aware that this draft is an update of RFC 3267, 
which mainly intends to fixes the lack of an offer-answer section. 
However if we conclude that any of these normative text is wrong we 
should definitely consider changing it. But any backwards compatibility 
issues must be considered. The payload format is rather well deployed, 
however I think the CRC mode is very seldom or may be not at all used. 
Both the robust sorting and the CRC mode are specifically designed for 
UDP-Lite type of partial checksums.

I would also note that this format was finished long before UDP-Lite was 
approved and went through the last round of changes.

See further below.

> changing the recommendation, then this introduces new issues that really 

I don't the text in section 4.4.2.1 that you quote is contradicting 
UDP-Lite at all. The CRC mode is specifically designed for partial 
checksums from the beginning. The bits in a AMR audio frame is sorted in 
sensitivity order, with the most sensitive bits first and the least 
last. This is utilized in circuit switched channel coding to provide 
three levels of protection A, which are so sensitive that any errors 
results in those bits not being used. A class B that has less protection 
but still needs lower bit-error rates than the class C bits that use the 
channel as is. The channel error rates are of course tuned to what the 
codec can accept in both bit-errors and frame erasures. Also if the 
class A bits are damaged as detected by the CRC (present also in the CS 
transport) some of the class B and C bits are used.

Due to this characteristics of the codec, the CRC was included to 
provide maximum performance for RTP payload with multiple AMR frames. 
The per frame CRC allows the complete section of data frames to be 
unprotected by UDP-Lite. Bit-errors in the sensitive class A bits are 
detected by the CRC, and in that case the frame is marked as damaged and 
some of the B and C bits for that frame are used in concealment.

The intention of the CRC mode compared to Robust sorting was to reduce 
the part that needs strong protection when aggregating multiple frames 
into a packet compared to the Robust Sorting mode. In the robust sorting 
mode, the complete payload data part is sorted byte-wise into decreasing 
order of sensitivity to bit-errors. In Robust sorting mode the intention 
is to cover the class A bits with the UDP-Lite checksum instead.

In conclusion I think this can be motivated.

> I'm not sure if this was a mistake or a design strategy. Can you tell me?

I am not certain why it says SHOULD rather than MUST. It was probably a 
case of given a little to much freedom to the implementors. In fact 
there are basically no fields where a bit-error could be present without 
resulting in serious problems for the playing application. Some 
bit-errors would result in inconsistent payload forcing one to discard 
it anyway. Others would result in misinterpretation of the result. For 
example a timestamp error would place the frame wrongly in time, which I 
consider quite serious. The backwards compatibility issues with changing 
this seem to be almost non-existent. If someone actually has taken on 
all the hassle to make an implementation that accept UDP-Lite packets 
with failed checksum and handles it correctly, fine they can keep it 
without affecting some else. The effect of the change would also only 
give the implementors a clearer implementation statement.

A better proposal may be to rewrite that sentence to simple note that 
any packets with errors detected by the UDP-Lite checksum or lower layer 
in that part will be discarded and never delivered.

Please provide more feedback if such a change is appropriate.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 09 Dec 2004 16:50:38 +0000

I've numbered the issues, to try to help us quickly agree on what the
problem is/was.

> which mainly intends to fixes the lack of an offer-answer section.

Yes - and it seems a good application for UDP-Lite, which was what
interested me.

> approved and went through the last round of changes.

Yes - and if so, then it explains the differences.

On looking through your response, I wonder how much of my response is due to
there being two types of "frames" link-frame and payload-codec-frames, each
with their own CRC's. Normally I'd not expect RTP documents to mention link
frames, but use of UDP-Lite naturally leads to comments on link frames. If
this differentiation can be clearer, then the issues can be localised to
section 3.6.1 (which seems perhaps to be the correct place to discuss IP,
Link and UDP-Lite).

> UDP-Lite at all.

OK - if that's the case, we can agree.

1) There's a subtle difference between what is expected Link behaviour as
described by UDP-Lite, and what this ID seems to suggest at the moment. This
lies in whether the Link-Layer does full frame protection; unequal
protection; or NO protection.

Experience with SLIP, etc, showed that NO protection of IP and transport
headers was bad - I would expect the concerns to be greater with IPv6 (where
there is no IP checksum), cite RFC3819 on use of link CRCs?

One thing I'd propose is to recommend a mode were all protocol headers up to
and including the class A bits in the frame are protected by a link-frame
CRC; you could cite UDP-Lite as clarification?

Would this impact any known usage? - Or is it only a clarification?

Of course, it is in practice hard for the IETF to mandate use of partial
(unequal) CRC protection at the link layer, never-the-less in my opinion, it
would be very wrong to encourage use of links with NO protection for IP.

2) Looking back, the current text in 3.6.1 seems to have a focus on RTP
issues (it is an AVT draft), but also touches on the implications for IP
networks. Perhaps a little more clarity here would prevent confusion (at
least for me). 

Suggestions are: Be clear which types of frame is being mentioned. It would
be good  to mention  the network and transport (i.e. UDP/UDP-Lite) headers
explicitly in your discussion. For example:

   "  1) Utilizing a partial checksum to cover headers and the most
       important speech bits of the payload."

Could become:
   "  1) Utilizing a partial checksum to cover protocol headers (i.e., IP
network headers, UDP/UDP-Lite transport headers; RTP headers; and RTP
payload headers) together with the most important speech bits of the
payload."

Etc.

Is this what was meant?

> The CRC mode is specifically designed for partial
This was what I thought, so that is good.

> some of the B and C bits for that frame are used in concealment.
Yes.
> In conclusion I think this can be motivated.
This sounds like the correct thing to do.
> give the implementors a clearer implementation statement.

3) Looking at the ID, I think the problem I had actually was in section 3.6
which speaks (I think) about Link-layer frames. If this was to be made
clear, then this section could refer back to it (and remove the potential
for confusion).

 " The frame CRC, when used, MUST be calculated only over all class A
    bits in the frame."

- Which "frame" is this about? - I think this is the payload-codec-frame of
RTP?

4)  A correct UDP-Lite implementation MUST discard these packets (this is
also the way DCCP is expected to behave when using partial checksum
coverage).  Of course AMR can also be used over non-IP transports, and then
you rely on their multiplexing and control functions to supply the bit
stream that AMR uses.

The rationale for IP transport was that allowing these packets to pass up
the stack with no verification of the IP header (in IPv6) or UDP-Lite header
(IPv4,IPv6), could result in cases of mis-delivery of arbitary corrupted
packets to *any* port, and applications do not generally have an ability to
handle such events robustly (with serious implications). So, unless there is
a strong argument, I'd recommend that if you use an IP network, you MUST use
a transport layer checksum.

> in that part will be discarded and never delivered.

Exactly:-)

> Multimedia Technologies, Ericsson Research EAB/TVA/A

I'm relieved we were closer than I thought... Are there still points of
disagreement?

Gorry

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Dec 2004 07:36:47 +0100

Hi Gorry,

Thanks for this review and discussion. Comments inline.

> On 9/12/04 10:18 am, "Magnus Westerlund" <[email-masked]>

[snip]

> section 3.6.1 (which seems perhaps to be the correct place to discuss IP,

Yes, all talk about the frames apply to the AMR audio data frame I 
think. We never intended to discuss link layer frames. From AVT's 
perspective this is all packets. However in relevant section where we 
discuss checksum, I could try to clarify the language.

[snip]
> Would this impact any known usage? - Or is it only a clarification?

If this applies to the statement for robust mode, I would agree. However 
I would like to avoid to put normative requirement on link-layer design 
here. I think we should limit ourselves to talk about the transport 
protocols partial coverage length. Possibly with a suggestion that this 
preferable applies also to link-layer checksums.

Yes.

[snip]
> - Which "frame" is this about? - I think this is the payload-codec-frame of

Yes, it is the audio codec's frame.

>  > in that part will be discarded and never delivered.

Then I propose that the next version of the draft will try to address this.

Conclusion:

This discussion suggest that the following changes should be applied to 
draft-ietf-avt-rtp-amr-bis-00.txt

- Clarify in the unequal protection chapters that we are talking about 
audio frames (sections 3.6 and 4.4.2.1).
- Change the "Packet with errors in protected headerparts SHOULD be 
discarded" to a more inforamtive text that this is assumed to happen.
- Expand in Section 3.6.1, bullet 1 that we also IP and transport 
protocol headers are assumed to be protected by transport level checksum.

I think these are all clarifications and alignments with the published 
specifications. I do not see any backwards compatibility issues.

Does anyone protest against the outline changes?

Cheers

Magnus Westerlund