RE: [rohc] Requirements for IP/UDP/RTP header compression

[Mikael Degermark <micke@cs.arizona.edu>]

At 02:10 PM 3/30/00 -0600, christopher.clanton@nokia.com wrote:
>Hi Mikael,
>
>I have a few comments/questions on the draft requirements document.  Can you
>elaborate?
>
>- Does the handoff requirment intend to allow for loss due to the header
>compression scheme (i.e., in addition to the normal 'break' that you have
>during cellular handoff).

No. It is explicitly stated that that is not allowed!

>- The packet loss requirement was omitted; why?  Is it otherwise clear that
>loss prior to the compressor should be handled efficiently?

Yes. By the Multiple Links requirement. 

>- Why has mention of timing jitter been removed? 

At the time of writing I wasn't sure what that was supposed to prevent, exactly. 
I am willing to be convinced otherwise. 

>- Packet Misordering requirement has been changed to say 'moderate'
>reordering.  Is there a reason to attempt to quantify the amount of
>misordering in this way?

Two reasons. Misordering will be small or else you don't have good voice service, 
since misordering implies that at least one packet is significantly delayed. 
Moderate misordering (a few packets) is not uncommon in the Internet, but large
misordering is. Given that there is a cost related to dealing with misordering, I don't
see a good reason as to why ROHC should try to deal *efficiently* with more than
moderate misordering. 

>- Complexity requirement has been omitted; but it seems like it should be
>there, for sake of simple/cheap mobiles if nothing else.

Seems to be covered by the Processing Delay requirement. 

>- Generic Applicability requirement has been omitted, but it would seem that
>this requirement is directly in line with the charters intention to support
>various radio technologies.

I believed, at the time of writing, that that is covered on several places where
"expected operating conditions" and similar language is being used. See for
example Performance/Spectrum Efficiency, Link delay. 

>- "Compatibility with Other Schemes" requirement has also been omitted?
>Why?

I didn't see that it is a requirement on the protocol, but rather on how it is incorporated
in a system and on particular implementations, something which is out of scope for 
ROHC. I'm willing to be convinced otherwise, though. What kind of protocol features
or behavior do you envision this requirement to exclude?

>- Error Propagation definition has been changed to refer specifically to
>error propagation due to the 'the link'; what is 'the link'?  Is it only the
>compressor/decompressor link, or is it the link between the RTP source and
>destination?

The former. I though (at 3 O'clock in the morning) that the previous language was 
unclear on precisely this point. It can be made clearer, I guess, but "the link" cannot
refer to "the link between RTP source and destination", since that is not a *link*. 
That is a path which will typically have more than one hop (i.e., more than one *link* is involved.)

>Chris Clanton
>Nokia Research Center - Dallas
>Mobile Networks Lab