Kristofer,
These are good questions, let's see if we can figure out
answers to them, it might be necessary to clarify some of
these in the implementer's guide.
Example 1:
A ROHC compressor is running in O-mode on context #1 (say for
example IPv4/UDP/RTP, profile 1), when it decides to reuse
this this context for a completely different flow (say
IPv6/UDP/RTP, profile 1). The compressor will of course have
to send an IR packet to the decompressor, but what mode must
it set in the IR packet? Do I inherit the mode of the old
flow or do I go back to U-mode?
My spontaneous answer would be, "it's a new stream, and a new
context, you must start in U-mode". Does this answer fly?
Let's see...
RFC3095 Section 4.4.1. "Unidirectional mode -- U-mode" says:
Compression with ROHC MUST start in the Unidirectional mode.
Does this mean that the compressor starts in U-mode "when the
channel is set-up" or "whenever the compressor re-initializes
a context"?
If I interpret it as the latter, then the decompressor will
see an IR with U-mode while being in O-mode, i.e. a mode
change occurs without the 3-way handshake.
Yes, but this should work when it is initiated by the compressor,
right? The 3-way handshake is there in **->U-mode because one
must ensure that the compressor will not continue to rely on
feedback.
Example 2:
The compressor has received the CONTEXT_REINITIALIZATION
signal (section 6.3.1), but the channel is kept up and
running. Then it seems most likely that compression must
start in U-mode since you are supposed to re-establish
everything (true?). The decompressor is in O-mode in this
example as well. So it seems we cannot completely avoid
a situation where the compressor could be forced to send
U-mode IRs to an O-mode decompressor.
True, but that should not be risky, as long as it is done
on initiative by the compressor (i.e. the compressor knows
it is operating in U-mode), as all U-mode packets have a
CRC, errors can thus be avoided and would be resolved.
"Bonus questions":
* How does this work in profiles 2 & 3 where there is
no mode parameter to send in the IR packets? Do I
inherit "current mode" or do I inherit "initial mode"?
In the same way, I think it should be "initial mode", but
a compressor implementation that does this must of course
be very careful ensuring the decompressor will interpret
the packets correctly.
* If I reuse a profile 1 context in R-mode and make it a
profile 0 or TCP profile context (these do not have R-mode),
what does my compressor send? I cannot inherit
"current mode" (R-mode), since it does not exist, and it
seems like inheriting "initial mode" for the selected
profile would be the only choice here.
Yes!
/L-E
-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57
My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. At the
end of this message, my employer might have automatically inserted
a stupid disclaimer. This nonsense is out of my control and should
simply be ignored.
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc