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

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Tue, 9 Oct 2001 10:01:22 +0200

Patrick and Andrew,

See my comments and questions below...

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

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

Yes, that was also my intention - for IPv4 streams only, the use of Twice should be disallowed in RFC 2507/08

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

This is a good approach, I just have a minor comment/question to your example below:
 
> 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.

What do you mean by Dropped here? Do you mean lost over the link? If so, how do the decompressor know this? RFC2507/08 do not assume that the decompressor get packet loss indications from the link. Can the decompressor rule not be formulized based on how Twice is normally applied, with an upper limit on the number of times Twice may be applied between ECU updates?

Once again, I think we are getting close to a solution and I hope we can fix this so that ECRTP can finally be completed. By the way, what happens to RFC2507/08? It should be time to take those to DS.

BR
/Lars-Erik

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

---

From: "Andrew Johnson" <[email-masked]>
Date: Tue, 9 Oct 2001 10:21:28 +0100

Lars-Erik

> See my comments and questions below...

Thanks for your comments, I have answered your question in-line below.

> What do you mean by Dropped here? Do you mean lost over the 
> link? If so, how do the decompressor know this? RFC2507/08 do 
> not assume that the decompressor get packet loss indications 
> from the link. Can the decompressor rule not be formulized 
> based on how Twice is normally applied, with an upper limit 
> on the number of times Twice may be applied between ECU updates?

The decompressor wouldn't know a packet was dropped until the
next successfully received packet was decoded.  Then the jump
in sequence number would show that Twice should be attempted.

> Once again, I think we are getting close to a solution and I 
> hope we can fix this so that ECRTP can finally be completed. 
> By the way, what happens to RFC2507/08? It should be time to 
> take those to DS.

The HDRCKSUM in the enhancements means we only have a problem
with IPv4 with UDP checksums.  Should any scheme like the above
be applied to all cRTP streams, or just IPv4 with UDP checksums?

Cheers

Andrew