Subject: RE: [rohc] Question on state retention priority

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Wed, 1 Oct 2003 10:11:43 +0200

Hi Robert,

see comments inline.

BR,
Jan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: den 30 september 2003 12:45
To: [email-masked]
Cc: [email-masked]
Subject: [rohc] Question on state retention priority

Hi ROHCers,

 During implementation we bumped into the following problem:

 If the user wants to save an already saved state with a different state retention priority, what should the state handler do?

According to the RFC:

      If the state creation request contains a state_identifier that
      already exists then the state handler checks whether the requested
      state item is identical to the established state item and counts
      the state creation request as successful if this is the case.  If
      not then the state creation request is unsuccessful (although the
      probability that this will occur is vanishingly small). 

IMHO, possible options are:

1. State save successful with the new retention priority
2. State save successful leaving the old retention priority
3. State save unsuccessful

What do you think?
[JC] I clearly think that (1) is the right thing to do. Leaving the old retention priority (as in (2)) seems strange as changing the priority is probably the reason for the state save. To count the state creation request as unsuccessful (3) definitely is against the RFC since the state item is identical!
I think that the RFC3320 is not really clear enough on this issue. To me it seems to leave room for different interpretations which is not a good thing. Once this question is settled I think it should be documented in the Implementers guide.

 Another question: What if a user saves a state that already exist as a locally available state? Should this count against the SMS?
[JC] Since the state is saved in the state memory, it should count against the SMS.

BR,
Robert

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

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 6 Oct 2003 10:50:41 +0100

Hi Robert, Jan,

See comments inline.
>  If the user wants to save an already saved state with a different state
> retention priority, what should the state handler do?
> 
> According to the RFC:
> 
> [JC] I clearly think that (1) is the right thing to do. Leaving the old
> retention priority (as in (2)) seems strange as changing the priority is
> probably the reason for the state save. To count the state creation
> request as unsuccessful (3) definitely is against the RFC since the state
> item is identical!

[AS] I agree with Jan that the retention priority should be the new one.  

There are two issues to clarify with regard to this issue: 

1) 	That the retention priority should be associated with the compartment.  I.E. if endpoint A creates a piece of state with retention priority 1 and endpoint B creates exactly the same state with retention priority 2, there should be one copy of the actual state but each compartment should keep its record of this piece of state with its own priority.  (If this did not happen then the state may be kept for longer than A anticipated or less time than B anticipated depending on which priority was used.)

2)	If the same piece of state is created within a compartment with a different priority, then one copy of it should be stored (with the new priority) and it should count only once against SMS.  (I believe this was the conclusion of a discussion a while ago, but was never documented.)

> I think that the RFC3320 is not really clear enough on this issue. To me
> it seems to leave room for different interpretations which is not a good
> thing. Once this question is settled I think it should be documented in
> the Implementers guide.
> 

Good idea.  Once we have agreement I will add a section to the implementers guide.

>  Another question: What if a user saves a state that already exist as a
> locally available state? Should this count against the SMS?
[AS] Agreed.  Any request for state creation made by the compressor should count against SMS because the compressor will be expecting it to do so.  Otherwise compressor and decompressor could get out of sync.

Best regards,

Abbie