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

[Gorry Fairhurst <[e-mail]>]

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

On 9/12/04 10:18 am, "Magnus Westerlund" <[e-mail]>
wrote:

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

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

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

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

> See further below.
> 
> Gorry Fairhurst wrote:
>> 
>> 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.
>> 
> 
> I don't the text in section 4.4.2.1 that you quote is contradicting
> 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
> 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.
> 
This was what I thought, so that is good.

> 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.
> 
Yes.
> 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.
> 
This sounds like the correct thing to do.
> 
>> 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?
>> 
> 
> 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.
> 

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.

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

Exactly:-)

> Please provide more feedback if such a change is appropriate.
> 
> 
> Cheers
> 
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> 

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

Gorry



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