Subject: [rohc] RE: Local state advertisements and the implementer's guide

From: "Richard Price" <[email-masked]>
Date: Mon, 18 Sep 2006 16:05:28 +0100

>> My proposal for the implementer's guide is to clarify that:
>> 
>> *) For 'basic' RFC 3320 implementations locally available state is
>>    - not mapped to compartments
>>    - is local to the endpoint and persists for the duration 
>> of the compartment
>>    - does not impact compartment SMS
>> 

> I agree with this. Though I see it as a correction rather than a
> clarification. The concept of mapping locally available state items to a
> compartment is to my mind a mistake by the authors of RFC3320, a
> confusion of a possible private implementation strategies with
> definitions of externally visible behaviours.

It would certainly be nice if the storage of all locally available state
could be considered an implementation issue at the decompressor. In fact
this was exactly how early versions of RFC3320 were intended to work.

However, an objection was raised that memory-intensive mechanisms such as
shared mode would be throwing away a large amount of memory advertising
states that the remote endpoint might not even want to use. In response,
we added to RFC3320 a mechanism for storing locally available state inside
the UDVM's own per-compartment memory. This allowed implementations to
use mechanisms like shared mode without worrying about wasting memory
unnecessarily.

I don't think we can put the above into the implementer's guide as a
"clarification", as it would be a technical change to RFC3320 to delete
the ability to use the per-compartment memory to store locally available
states. But nothing stops us from getting rid of this mechanism in the
next version of RFC3320 if it is determined that implementers do not
wish to make use of it.

>> Finally, if this clarification is made in the implementer's 
>> guide, then it is only addressing general SigComp behaviour.  
>> If a stronger promise of keeping state is wanted (e.g. beyond 
>> the end of the compartment) then this can be specified in 
>> 'Sigcomp for SIP' or other equivalent documents in the same 
>> way as the minimum DMS or support of a dictionary is specified.

> Going a bit off topic here, I'd just add that the authors of such
> documents should not only specify requirements as to state items which
> must mandatorily be made available for specific environments, but should
> also make it clear whether or not those state items need to be
> advertised. E.g. "Sigcomp for SIP" says the SIP/SDP dictionary must
> always be available but it isn't stated whether or not it also needs to
> be advertised or whether its presence should just be assumed.

If an item of state is mandatory in a particular environment, its
presence can by definition be assumed by the compressor. So there's
no need to advertise the state - you can advertise it anyway but I
can't see any benefit to doing this.

Cheers,

Richard

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "John Barber" <[email-masked]>
Date: Mon, 18 Sep 2006 16:40:35 +0100

> -----Original Message-----
> From: Richard Price [mailto:[email-masked]] 
> Sent: 18 September 2006 16:05
> To: John Barber; Surtees, Abigail; [email-masked]
> Cc: Lajos Zaccomer (IJ/ETH); [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: Local state advertisements and the implementer's guide
> 
> >>    - is local to the endpoint and persists for the duration of the 
> >> compartment
> > clarification. The concept of mapping locally available 
> state items to 
> > a compartment is to my mind a mistake by the authors of RFC3320, a 
> It would certainly be nice if the storage of all locally 
> available state could be considered an implementation issue 
> at the decompressor. In fact this was exactly how early 
> versions of RFC3320 were intended to work.
> 
> However, an objection was raised that memory-intensive 
> mechanisms such as shared mode would be throwing away a large 
> amount of memory advertising states that the remote endpoint 
> might not even want to use. In response, we added to RFC3320 
> a mechanism for storing locally available state inside the 
> UDVM's own per-compartment memory. This allowed 
> implementations to use mechanisms like shared mode without 
> worrying about wasting memory unnecessarily.

I think this is unneccessary. An implementation would (even in the
absence of such a mechanism) be free to use spare per-compartment memory
for any purpose it sees fit, including shared-mode state items, so long
as it makes this usage transparent to the other end of the conversation.
Just because (for example) a SIGCOMP endpoint advertises 8K of SMS it
does not necessarily mean that it needs to allocate 8K of memory
permanently for each compartment and dedicate it exclusively to storing
state items at the request of the remote. I would in fact guess that
most implementations will choose to use a "new" or "malloc" for each
state item and manage the SMS limits by summing their sizes.

> 
> I don't think we can put the above into the implementer's 
> guide as a "clarification", as it would be a technical change 
> to RFC3320 to delete the ability to use the per-compartment 
> memory to store locally available states. But nothing stops 
> us from getting rid of this mechanism in the next version of 
> RFC3320 if it is determined that implementers do not wish to 
> make use of it.
> 
> >> Finally, if this clarification is made in the implementer's guide, 
> >> then it is only addressing general SigComp behaviour.
> >> If a stronger promise of keeping state is wanted (e.g. 
> beyond the end 
> >> of the compartment) then this can be specified in 'Sigcomp 
> for SIP' 
> >> or other equivalent documents in the same way as the 
> minimum DMS or 
> >> support of a dictionary is specified.
> 
> > must mandatorily be made available for specific environments, but 
> > should also make it clear whether or not those state items 
> need to be 
> > always be available but it isn't stated whether or not it 
> also needs 
> > to be advertised or whether its presence should just be assumed.
> 
> If an item of state is mandatory in a particular environment, 
> its presence can by definition be assumed by the compressor. 
> So there's no need to advertise the state - you can advertise 
> it anyway but I can't see any benefit to doing this.

I agree with this interpretation but would like to see it made explicit
in the relevant documents since I believe the contrary interpretation is
also possible and this could cause difficulties in interoperability.