Subject: [AVT] Action item #2: handling IP ID in crtp-enhance

From: Stephen Casner <[email-masked]>
Date: Fri, 21 Sep 2001 16:29:44 -0700 (PDT)

There are a few items for which the AVT meeting minutes say "this
issue needs to be resolved on the mailing list."  This is one of
them.

The question: Is it acceptable for RTP header compression to
potentially not maintain the integrity of the ID field in the IPv4
header when the "twice" algorithm is used?

In that algorithm, when a compressed packet is lost, the decompressor
tries applying the delta values to the saved context twice and then
determines success by verifying the checksum of the result against the
UDP checksum in the compressed packet following the loss.  The problem
is that the IPv4 ID field is one of the delta fields, but it is not
covered by the UDP checksum.  If it changed by an amount other
different from the stored delta, then the discrepancy would not be
detected.  Note that fragmented packets are never compressed, and the
ID field has a specified function only for fragmented packets.

This is a flaw in CRTP as specified in RFC 2508.  However, on
low-delay, low-loss links it is not necessary to use the "twice"
algorithm, so it's not too big a problem.

The question arises in the context of "enhanced CRTP" as specified in
draft-ietf-avt-crtp-enhance-02.txt.  This draft enhances CRTP for
improved performance under conditions of higher delay and more packet
loss than RFC 2508 can accommodate.  It does so by adding redundancy
and depending heavily on the "twice" algorithm.

During my presentation of "drafts possibly ready for last call", I
described the simplifications made in the latest revision of the
crtp-enhance draft to reduce complexity and focus on those functions
needed for use with RTP multiplexing via Tunneled, Compressed RTP as
described in draft-ietf-avt-tcrtp-04.txt.  One of the simplifications
was to delete the enhancement in which the ID field of the IPv4 header
would be added to the UDP checksum by the compressor and subtracted
from the checksum by the decompressor.  This operation would allow the
"twice" algorithm to verify that the ID field was being recovered
correctly along with all the other delta fields.

I stated in my presentation that there seemed to be less concern now
than there had been before about maintaining the integrity of the IPv4
ID field.  I based that on my interpretation of events in the ROHC WG,
but that interpretation may have been wrong.  In the AVT meeting,
Lars-Erik Jonsson said the ROHC protocol does maintain the ID with a
header checksum and that the proposed zero-byte compression is not
allowed to be used when the ID would not be maintained.  Lars-Erik
said he thought it was not acceptable for enhanced CRTP to not
maintain the validity of the IPv4 ID.  He also thought it would be
best not to "disturb the end-to-end semantics" of the UDP checksum and
suggested that other possible mechanisms be considered for ECRTP, but
I countered that it would be better not to add any bits to CRTP.

So, to repeat, the question for the group is:  Is it acceptable for
the IPv4 ID field to possibly not be maintained when packets are lost?

If not, we propose to put back the function of adding the IPv4 ID
field into the UDP header while the packet is compressed.  We removed
it because it is a little quirky, but it would do the job efficiently.
I claim that it does not, in fact, disturb the end-to-end semantics of
the UDP checksum because the checksum is restored, not regenerated.

Opinions?
							-- Steve

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