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

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Mon, 1 Oct 2001 16:37:13 +0200

Stephen and others,

Since I requested this to be brought up on the mailing list I should probably at least contribute with my current view of this. Personally, I do not have extremely strong opinions about it, but I have some and I hope others do too.

The question we are discussing is how to handle the problem of IP ID not necessarily being correctly decompressed when the Twice algorithm is used. Twice may be used in IP-HC (RFC-2507), CRTP (RFC2508) and in E-CRTP, and the "flaw" comes from Twice relying on the UDP checksum for verifying correct decompression of sequencing information and fields inferred from sequencing (including IP ID). Unfortunately, since the UDP checksum does not cover the IP ID field, an incorrect value will not be detected. 

I can see (at least) 4 possible solutions to this:

1) Change nothing:
     This means that using Twice may result in incorrectly
     decompressed IP ID values.

2) Disallow the use of Twice:
     With this approach, it will not be possible to do local
     "context repair" at the decompressor. Packet losses
     will thus be translated into loss propagation. This 
     may however not be a major problem for normal usage
     of CRTP and IP HC as mentioned by Stephen (see below).

3) Add IP ID to the UDP checksum transmitted over the link:
     According to the previous E-CRTP draft, the ID field
     of the IPv4 header would then be added to the UDP
     checksum by the compressor and subtracted from the
     checksum by the decompressor. The problem with this
     approach is that it may be seen as breaking the
     e2e properties of the UDP checksum.

4) Add information to the compressed header:
     This problem can of course be solved by adding new
     information to the compressed header in some way.
     The obvious drawback would be a slightly larger
     header, but that is not necessarily a problem.

We must find a suitable solution both for the new E-CRTP when brought to PS, and also for CRTP (RFC 2508) and IP-HC (RFC 2507) when taking these to DS. I would prefer the following:

- For CRTP & IP HC PS we should do 2), since it is simple, it does not change any semantics, and it solves the problem completely. The drawback (no robustness to losses) should not be a significant problem as mentioned by Stephen (see below).

- For E-CRTP, I would prefer to see a solution based on 4), since we are defining a new protocol and have the possibility to do a more explicit solution. If that for some reason is not possible, we could consider 3), but I would then like to see some positive comments on this from the community.

Cheers,
/Lars-Erik

> -----Original Message-----
> From: Stephen Casner [mailto:[email-masked]]
> Sent: September 22, 2001 01:30
> To: AVT WG
> Subject: [AVT] Action item #2: handling IP ID in crtp-enhance
> 
> 
> 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
> 

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

---

From: Patrick Ruddy <[email-masked]>
Date: 08 Oct 2001 18:08:55 +0100

> - For E-CRTP, I would prefer to see a solution based on 4), since we are defining a new protocol and have the possibility to do a more explicit solution. If that for some reason is not possible, we…
Hi

I would tend to agree with this analysis - we have been through option 1
many times before and have always erred on the side of keeping ID
consistent end to end. 3 would seem to be a bit of a hack causing
possible backwards compatibility problems. 

We put our heads together here and came up with the following

2 should be modified to allow twice to be used with 2508 and IPv6 as
IPID is not a problem with v6.

For option 4 the enhancements could negotiate number (num_id_trans).
num_id_trans would be one more than the max number of dropped packets
before the use of twice is disallowed and would be in the range 2-16. If
this number was set then the use of twice would be enabled otherwise it
would be disallowed. Then if IPID changes an extended COMPRESSED_UDP
packet would be sent  with absolute IPID num_id_trans times.

an example follows with  num_id_trans set to 4

Packet ID       Compressor                 Decompressor    

1000            Send ECU F=1 I=1 1000      ID 1000, delta ?
1001            Send ECU F=1 I=1 1001      ID 1001, delta 1
1002            Send ECU F=1 I=1 1002      ID 1002, delta 1
1003            Send ECU F=1 I=1 1003      ID 1003, delta 1
1004            Send CR                    ID 1004, delta 1
1005            Send CR                    ID 1005, delta 1
1007            Send ECU F=1 I=1 1007      ID 1007, delta 2
1008            Send ECU F=1 I=1 1008      ID 1008, delta 1
1009            Send ECU F=1 I=1 1009      Dropped
1010            Send ECU F=1 I=1 1010      ID 1010, delta 1
1011            Send ECU F=1 I=1 1011      ID 1011, delta 1
1012            Send CR                    ID 1012, delta 1
1013            Send CR                    Dropped
1014            Send CR                    ID 1014, delta 1
1015            Send CR                    Dropped
1016            Send CR                    Dropped
1017            Send CR                    Dropped
1018            Send CR                    Dropped
1019            Send CR                    Dropped
1020            Send CR                    Dropped
1021            Send CR                    ID ????, lost too many.

cheers

paddy and Andrew ([email-masked])