[rohc] RE: Questions on Context Replication

["Cho Chia Yuan" <[e-mail]>]

Hi Ghyslain,
 
A big thank you for your detailed reply.
 
My suggestion (of MUST instead of SHOULD) is one of many possible solutions to the problem of base contexts deemed valid at the compressor but actually not present at the decompressor. Regardless of the solution, my concern is that some non-implementation-specific mechanism to deal with the above problem should be in place?
 
Maybe I should first establish the existence of this problem - can base contexts deemed valid at the compressor be in non-existence at the decompressor?
 
As you have mentioned in section 3.3.3.1 (starting from "Note however... "), this problem probably exists, however remote it is. I believe the key, then, lies in its significance - it is a non-problem in current ROHC mechanisms without context replication, because even without feedback, periodic downwards transition to IR state is guaranteed to resynchronize the decompressor context. If we add in context replication, then without feedback, we may find that periodic downwards transition to IR-CR state is not guaranteed to resynchronize the decompressor context, because all base contexts deemed valid at the compressor may be in non-existence at the decompressor.
 
That's why I think context replication needs a reverse feedback channel (other than using it to verify contexts to become base contexts) for some kind of compulsory feedback, either upon success, or failure, and feedback is perhaps more important with context replication than without.
 
Regards,
Chia Yuan Cho
National University of Singapore
/Institute for Infocomm Research

	-----Original Message----- 
	From: Ghyslain Pelletier [mailto:[e-mail]] 
	Sent: Wed 12/3/2003 11:00 PM 
	To: Cho Chia Yuan 
	Cc: [e-mail]; [e-mail]; [e-mail] 
	Subject: Re: Questions on Context Replication
	
	

	Hi,
	
	Thanks again for your comments. Hopefully I can clarify this issue,
	otherwise please correct me if I misunderstand your point.
	
	I think that the concerns you have regarding the challenges a compressor
	is facing when selecting a base context and the differences between IR
	and IR-CR are already summarized in the draft, in section 3.3.3.1. (see
	text from "Note however that" of the first paragraph up to the end of
	the second paragraph of the same section). I believe this is what you
	are referring to.
	
	> Let's say for a particular new flow, the compressor chooses from a
	> pool of suitable base contexts for context replication, but all their
	> equivalents at the decompressor have been overwritten/discarded,
	> without the compressor's knowledge. Naturally, at the decompressor,
	
	Secondly, your concerns seem to make some assumptions regarding context
	management at the compressor. I believe somes assumptions are
	inaccurate. Recall that CIDs with ROHC are "managed" by the compressor,
	i.e. the CID is always choosen by the compressor when initiating a new
	context for a new flow. Overwriting of a CID is thus always known by the
	compressor - as it is the compressor decision to do so by reusing a CID
	when initializing a new context - otherwise the CID state is expected to
	be kept in memory at both ends. This is also true with context
	replication.
	
	However, one could think that a decompressor implementation could be
	optimized to cleanup the memory space allocated for a CID associated to
	a connection-oriented flow (e.g. such as TCP) when it detects that the
	connection has ended (e.g. FIN bit set plus some additional time wait).
	In such case, there is a possibility that the compressor could select a
	context as a base context for which the decompressor is not maintaining
	state anymore - I believe this is your concern, and this is what is
	explained in section 3.3.3.1.
	
	My view is that doing such an optimization at the decompressor is not
	what is expected of a ROHC  decompressor implementation. Therefore, my
	opinion is that such an "optimization" is an implementation design
	decision, and hopefully implementers will understand the "risks" being
	taken so that such an implementation *will* send STATIC-NACK.
	
	Hovewer again, removing CID state from memory without this state being
	explicitly overwritten by the compressor selection of the context
	identifier is not the expected behaviour, therefore I believe the
	sending of STATIC-NACK being a SHOULD in the draft is the appropriate
	wording.
	
	> My point is that when verification from IR-CR fails, a STATIC-NACK
	> MUST (instead of SHOULD) be sent to notify the compressor that the
	> base context it used is invalid, otherwise the compressor will
	> continue using it unknowingly. A side point is that use of IR-CR
	
	As said, not sending feedback in such case would be a very poor
	decompressor implementation considering that IR-CR can only be sent if
	there exist a feedback channel between decompressor and compressor.
	However, this does not make it a MUST. The occurence of such problem
	would be due to a decompressor behavior that is not expected by the
	compressor (otherwise decompression of an IR-CR has little other reasons
	not to succeed). Such a failure would be the result of an implementation
	"optimization" that is not performed consequently if no STATIC-NACK is
	sent upon receiving an IR-CR using a base context that has been removed
	from the state managed by the decompressor.
	
	> A side point is that use of IR-CR
	> packets to refresh contexts in optimistic mode cannot be guaranteed
	> to be a success(unlike IR packets), because the equivalent of the
	> compressor's base context may no longer be kept by the decompressor.
	
	But it is guaranteed that failures will be detected, and if the context
	is no longer kept this is an unexpected behavior for the decompressor.
	
	> However, IR-CR packets may still be used for context refreshing in
	> optimistic mode, as long as STATIC-NACKs are compulsory instead of
	> optional, which is what my first point is about.
	
	Recall also that it is the decompressor that chooses the mode of
	operation (unidirectional, bidirectional optimistic). The requirements
	for the compressor to be allowed to use IR-CR implies also that the
	decompressor as the possibility to send feedback.
	
	Finally, I would like to remind the distinction between "SHOULD" and
	"MUST" from RFC2119:
	
	// 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
	// definition is an absolute requirement of the specification.
	//
	// [snip]
	//
	// 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
	// may exist valid reasons in particular circumstances to ignore a
	// particular item, but the full implications must be understood and
	// carefully weighed before choosing a different course.
	
	I thus think "SHOULD" is appropriate. However, I could modify the text
	to reflect better the possible "implications" of not doing so.
	
	/Ghyslain
	
	Cho Chia Yuan wrote:
	>
	> Hi Ghyslain,
	>
	> Thanks for your reply. I understand that the reverse feedback channel
	> must be present for context replication, or else contexts at the
	> compressor cannot be verified to become potential base contexts.
	>
	> However, can you elaborate more on the other issue - why is it that
	> STATIC-NACK SHOULD be sent when the decompressor fails to validate
	> the context after IR-CR packet decompression? (My question is, why
	> SHOULD instead of MUST?)
	>
	> As mentioned in my earlier mail, if sending back STATIC-NACKs are
	> optional instead of compulsory, then IR-CR packets uniquely face a
	> danger not encountered by IR packets. The following is my argument
	> for it, rephrased:
	>
	> Let's say for a particular new flow, the compressor chooses from a
	> pool of suitable base contexts for context replication, but all their
	> equivalents at the decompressor have been overwritten/discarded,
	> without the compressor's knowledge. Naturally, at the decompressor,
	> verification after IR-CR decompression fails. Since sending back
	> STATIC-NACK is optional, it is not sent. The compressor, kept in the
	> dark, continues in optimistic mode, and periodically transits
	> downwards to IR state, depending on it to refresh the context at the
	> decompressor. However, in IR state, since seemingly 'valid' base
	> contexts are present, the compressor proceeds to send IR-CR packets
	> instead... ... At the decompressor, the entire flow has been
	> gibberish, and no data gets sent.
	>
	> My point is that when verification from IR-CR fails, a STATIC-NACK
	> MUST (instead of SHOULD) be sent to notify the compressor that the
	> base context it used is invalid, otherwise the compressor will
	> continue using it unknowingly. A side point is that use of IR-CR
	> packets to refresh contexts in optimistic mode cannot be guaranteed
	> to be a success(unlike IR packets), because the equivalent of the
	> compressor's base context may no longer be kept by the decompressor.
	> However, IR-CR packets may still be used for context refreshing in
	> optimistic mode, as long as STATIC-NACKs are compulsory instead of
	> optional, which is what my first point is about.
	>
	> Hope my question is clearer now. Please correct me if I'm wrong :)
	>
	> Chia Yuan Cho
	> National University of Singapore
	> /Institute for Infocomm Research
	>
	> -----Original Message-----
	> From: Ghyslain Pelletier [mailto:[e-mail]]
	> Sent: Mon 12/1/2003 7:24 PM
	> To: Cho Chia Yuan
	> Cc: [e-mail]; [e-mail]; [e-mail]
	> Subject: Re: Questions on Context Replication
	>
	> Hi,
	>
	> Thanks for your comments. Hopefully the following will properly address
	> them.
	>
	> > -The above suggests that the feedback channel is compulsory?
	>
	> The presence of an established feedback channel is compulsory for a
	> compressor to have the capability to initiate context replication for a
	> new flow (CID), otherwise no base context (BCID) can be selected as the
	> base for replication.
	>
	> > -Since reverse (positive and negative) feedbacks are all optional,
	> > does it mean that the feedback channel is optional?
	>
	> The usage of feedback from decompressor to compressor for a particular
	> replicated context (CID) is optional. In such case, the compressor is
	> "forced" to operate in a unidirectional manner and the newly replicated
	> context (CID) cannot be used as the base context (BCID) when performing
	> the periodic "refreshes" for that flow (CID).
	>
	> To answer your questions in more details:
	>
	> > 1) Is the reverse feedback channel a compulsory pre-requisite for
	> > context replication or is it optional?
	>
	> The phrasing of the requirement for selecting a base context for
	> replication could be improved. The text in section 3.3.3.1 will be
	> updated to reflect that only a context for which all static information
	> has been acknowledged can be selected as a base context for replication.
	>
	> Thus the requirement does mean that the presence of a feedback channel
	> between decompressor and compressor is compulsory - otherwise a
	> compressor cannot initiate context replication as no context could meet
	> the requirement for a base context.
	>
	> > 2) When the decompressor validation of the context following
	> > decompression of an IR-CR packet fails, is the STATIC-NACK sent back
	> > to the compressor optional or compulsory?
	>
	> Sending feedback (such as STATIC-NACK) is always optional (however it
	> SHOULD be used) for context replication. If the decompressor chooses not
	> to provide feedback for the newly replicated context (thus forcing a
	> unidirectional type of operation), then the compressor will have to
	> periodically transit back to a lower state (IR or IR-CR state) to
	> "refresh" the context.
	>
	> When refreshing the context, the compressor can only use an IR-CR packet
	> if the requirement for the use and selection of a base context is met.
	> In particular, if the original base context previously used does not
	> meet anymore the above requirement, the compressor will have to select
	> another context as a base context. Similarly, as the newly replicated
	> context has not been acknowledged, it cannot either be used as a base
	> for that IR-CR packet.
	>
	> I hope this answers your concerns - otherwise don't hesitate to let me
	> know, also if you have further questions or comments.
	>
	> Best regards,
	>
	> /Ghyslain
	>
	> Cho Chia Yuan wrote:
	>>
	>> Hi Ghyslain,
	>>
	>> I have a few questions regarding
	>> <draft-ietf-rohc-context-replication-01.txt>:
	>>
	>> 1) Is the reverse feedback channel a compulsory pre-requisite for
	>> context replication or is it optional?
	>>
	>> 2) When the decompressor validation of the context following
	>> decompression of an IR-CR packet fails, is the STATIC-NACK sent back
	>> to the compressor optional or compulsory?
	>>
	>> The nature of my questions arises from the following:
	>> (3.3.3.)
	>>    Context replication is designed to operate over links where a
	>>    feedback channel is available. This is necessary to ensure that
	>>    the information used to create a new context is synchronized
	>>    between the compressor and the decompressor. ...
	>>
	>> -The above suggests that the feedback channel is compulsory?
	>>
	>> (3.4.3.)
	>>   Specifically, when the decompressor fails to validate the context
	>>   following the decompression of one or more initial IR-CR packets,
	>>   it MUST invalidate the context and remain in its initial state. In
	>>   addition, the decompressor SHOULD send a STATIC-NACK.
	>>
	>> -Since reverse (positive and negative) feedbacks are all optional,
	>> does it mean that the feedback channel is optional?
	>>
	>>
	>> My opinion is that the reverse feedback channel must be present for
	>> context replication, so that STATIC-NACKS are sent back to the
	>> compressor when context validation fails upon decompression of an IR-
	>> CR packet. IR-CR context validation failures must be communicated
	>> back to the compressor. This is because 'valid' base contexts at the
	>> compressor may be already invalidated at the decompressor.
	>>
	>> The case for this - suppose the reverse feedback channel is not
	>> present (or STATIC-NACKs are not sent back upon context validation
	>> failure at the decompressor), and furthermore the decompressor has
	>> discarded/overwritten all the valid base contexts still kept by the
	>> compressor. Then, the compressor has no way of knowing the truth.
	>> After upwards transition from the CR state in optimistic mode, the
	>> compressor periodically transits downwards to IR state, in which it
	>> finds seemingly 'valid' base contexts, transits to CR state, and
	>> after a period of time optimistically proceeds to the 'Higher Order
	>> State', .. , and all the time nothing has been received successfully
	>> at all.
	>>
	>>Thus, I think STATIC-NACKs for IR-CR packets should not be optional,
	>> because an avenue for fallback to IR packets, in the event of
	>> failure, must be provided.
	>>
	>> Furthermore, if the policy enforced is such that the most recent
	>> valid base context is chosen for replication always, then maybe it
	>> can be assumed that if context validation for an IR-CR packet fails
	>> at the decompressor, there is no need for the compressor to attempt
	>> context replication from another base context? Thus, can the
	>> decompressor simply send back a STATIC-NACK to signal fallback to
	>> conventional context initialization? This may mean that the sending
	>> of STATIC-NACK would be MUST instead of SHOULD in the above section.
	>>
	>> Chia Yuan Cho
	>> National University of Singapore
	>> / Institute for Infocomm Research
	>>         --
	>  Ghyslain Pelletier, Dipl. Ing.
	>  Wireless IP Optimizations
	>  AWARE - Advanced Wireless Algorithm Research
	>  Ericsson Research, Corporate Unit
	>  Ericsson AB, Laboratoriegränd 11
	>  Box 920, S-97128 Luleå, SWEDEN
	>  Phone : [phone]
	>  Mobile: [phone]
	>  [e-mail]
	>  http://www.ericsson.com
	>  I have a new mail address: [e-mail]
	>  My old e-mail address will function until 2004-06-01.
	>  Please change my address in your personal address book.
	>
	
	--
	Ghyslain Pelletier, Dipl. Ing.
	Wireless IP Optimizations
	AWARE - Advanced Wireless Algorithm Research
	Ericsson Research, Corporate Unit
	
	Ericsson AB, Laboratoriegränd 11
	Box 920, S-97128 Luleå, SWEDEN
	Phone : [phone]
	Mobile: [phone]
	[e-mail]
	http://www.ericsson.com
	
	I have a new mail address: [e-mail]
	My old e-mail address will function until 2004-06-01.
	Please change my address in your personal address book.