headers
Lars-Erik Jonsson (LU/EAB | 2 Nov 2004 09:09
Picon
Favicon

Agenda for the ROHC WG <at> IETF61

Robust Header Compression WG (rohc)

Monday, November 8 at 09:00-11:30
=================================

CHAIRS: Carsten Bormann <cabo <at> tzi.org>
        Lars-Erik Jonsson <lars-erik.jonsson <at> ericsson.com>

AGENDA:

0900  Chair admonishments and agenda bashing          (Jonsson)   10
  - NOTE: It is assumed that people have read all drafts

0910  WG and document status update                   (Jonsson)   20
  - Published:
         RFC 3095, RTP
         RFC 3096, RTP requirements
         RFC 3241, ROHC over PPP             
         RFC 3242, LLA                       
         RFC 3243, 0-byte RTP requirements   
         RFC 3408, LLA R-mode                       
         RFC 3409, ROHC RTP lower layer guidelines   
         RFC 3320, Signaling Compression (SigComp)
         RFC 3321, SigComp - Extended Operations
         RFC 3322, SigComp Req's & Assumptions
         RFC 3485, SigComp SIP/SDP static dictionary
         RFC 3486, Compressing SIP with SigComp      
         RFC 3759, ROHC Terminology & channel mapping examples
         RFC 3816, Definitions of managed objects for ROHC
         RFC 3843, A ROHC profile for IP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Surtees, Abigail | 2 Nov 2004 18:26
Picon

Shared mode

Hi All,

Before and at San Diego there was some discussion about a potential problem
with shared mode as it's currently defined in 3321.  For the gory details of
the discussion see
<http://www1.ietf.org/mail-archive/web/rohc/current/msg02384.html> and
subsequent messages.

In summary, if compressor A creates a second piece of shared mode state
there is potential for loss of synchronisation between endpoints A and B
(e.g. if the second shared mode state pushes the first piece of shared mode
state out but the message that does this does not reach B).

Our proposed solution is that the creation of only one piece of shared mode
state is allowed by any compressor (and the corresponding decompressor at
the other endpoint).  However, this has to be agreed by all SigComp
endpoints otherwise there is still possibility for loss of synchronisation
(see earlier messages).

Do others agree 

a) that there is a problem,
b) that allowing only one piece of shared mode state is a suitable solution,
c) that some text for this solution should be put in the implementer's
guide?

I understand that most of the above was agreed in San Diego, however, we
require consensus on the list in order to put the text in the implementer's
guide.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carsten Bormann | 2 Nov 2004 19:44
Favicon
Gravatar

Re: Shared mode

On Nov 02 2004, at 18:26 Uhr, Surtees, Abigail wrote:

> allowed

I have a small problem with this word -- 3321 is not normative, and 
neither is the implementer's guide.
A compressor may have other means to ascertain it can place more than 
one piece of shared mode state, so I wouldn't "prohibit" this.
Apart from that, I agree that "don't do that" 
[http://www.jargon.net/jargonfile/d/Dontdothatthen.html] was the 
resolution of the discussion.

Gruesse, Carsten
Permalink | Reply | 1 comment |
headers
West, Mark | 2 Nov 2004 23:51
Picon

Re: Shared mode


Hi Carsten,

Given that you must be on at least your third cup of coffee by now... :-)

Insofar as this issue relates to 3321, then it is clear that we cannot
'prohibit' this usage.  However, there is a slight twist to this, isn't
there?  3320 is the minimal, clean, normative bit.  All the messy
remainder went into 3321 or elsewhere.  But the '65535' priority was
motivated, basically, by shared-mode.  (This is not saying that there
mightn't be other games that one could play with such a state-priority;
just that shared-mode exists because of this contrivance).  The problem
that exists, then, is actually caused by the interaction of the altered
state-creation rules for state of this priority.  As defined in 3320...

Honestly, though, this is probably just Devil's advocacy on my part.

So long as, when a message fails to decompress, we've documented a
possible cause that would otherwise have been thought to be implausible
(i.e. an action by the peer compressor), I'm happy!

Cheers,

Mark.

On Tue, 2 Nov 2004, Carsten Bormann wrote:

> Date: Tue, 2 Nov 2004 19:44:27 +0100
> From: Carsten Bormann <cabo <at> tzi.org>
> To: "Surtees, Abigail" <abigail.surtees <at> roke.co.uk>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lajos Zaccomer (IJ/ETH | 3 Nov 2004 08:13
Picon
Favicon

RE: Shared mode

Hi,

I completely agree with bullets a and c, on the other hand, with the proposed solution, SigComp will make fun
of itself. Dying from the first lost message will prove to the potential customers that this is a week protocol.
To make it a bit clearer for possible newcomers: the problem is not that a second shared state pushes out the
first one when the compressor of A saves it. It is that B saves a dynamic state on A, which would push out the
first shared state. Now, if the message advertising the second shared state is lost, B is in trouble not
knowing the first shared state is gone.
Note that compressor A is not allowed to save a new shared state if another state should be deleted as it is
pointed out in RFC 3321 5.2:
  "Note that new shared state items must not be created
   unless the compressor has made enough state memory available (as
   decompression failure could occur if the shared state pushed existing
   state out of the state memory buffer)."
So, what is the problem here? I don't think it's the shared compression, but the state handling algorithm
used by endpoint B. If an endpoint will not mix shared and dynamic compression, this will not happen.
Basically, it is an endpoint responsibility not to use it, so in my opinion, there should be nothing but a
warning in one of the guides that this mixed mode should be used with much care or avoided if possible.

br/Zacco

-----Original Message-----
From: rohc-bounces <at> ietf.org [mailto:rohc-bounces <at> ietf.org]On Behalf Of Surtees, Abigail
Sent: Tuesday, November 02, 2004 6:26 PM
To: rohc <at> ietf.org
Subject: [rohc] Shared mode

Hi All,

Before and at San Diego there was some discussion about a potential problem
(Continue reading)

Permalink | Reply | 3 comments |
headers
Surtees, Abigail | 3 Nov 2004 18:03
Picon

RE: Shared mode

Hi Zacco, All,

Thanks for your feedback:
> 
> I completely agree with bullets a and c, on the other hand, 
> with the proposed solution, SigComp will make fun of itself. 
> Dying from the first lost message will prove to the potential 
> customers that this is a week protocol.
> To make it a bit clearer for possible newcomers: the problem 
> is not that a second shared state pushes out the first one 
> when the compressor of A saves it. It is that B saves a 
> dynamic state on A, which would push out the first shared 
> state. Now, if the message advertising the second shared 
> state is lost, B is in trouble not knowing the first shared 
> state is gone.
> Note that compressor A is not allowed to save a new shared 
> state if another state should be deleted as it is pointed out 
> in RFC 3321 5.2:
>   "Note that new shared state items must not be created
>    unless the compressor has made enough state memory available (as
>    decompression failure could occur if the shared state 
> pushed existing
>    state out of the state memory buffer)."

You are right, apologies for my confusing summary.  (There are some message
flows in previous mails on this subject which are clearer than words - for
more details see these
<http://www1.ietf.org/mail-archive/web/rohc/current/msg02384.html>)

> So, what is the problem here? I don't think it's the shared
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Roach | 3 Nov 2004 18:51
Favicon

Re: Shared mode

Lajos Zaccomer (IJ/ETH) wrote:

>I completely agree with bullets a and c, on the other hand, with the proposed solution, SigComp will make
fun of itself. Dying from the first lost message will prove to the potential customers that this is a week protocol.
>  
>

By the way, the ability to recover from these kind of situations was one 
of the strong motivations for the NACK document. If this is a truly rare 
occurrence, then I think the current situation combined with the use of 
NACKs is probably a suitable solution.

/a
Permalink | Reply | 2 comments |
headers
West, Mark | 4 Nov 2004 02:28
Picon

Re: Shared mode


Adam,

We probably should have brought NACK into this sooner...  you're quite
right in suggesting that NACK is a way of recovering in the event of this
problem occuring.

A few comments, though:

- it's still worth (I think) documenting that a NACK based on failing to
find shared-mode state *probably* indicates a confusion of the form
described [for a well-behaved compressor].  (and, as a consequence,
shared-mode should no longer be used in this compartment)

- a communication involving a SigComp 'v1' endpoint will not be able to
take advantage of the NACK mechanism, so it would be nice to offer some
explanation of how to behave?

I still have a nagging doubt, though (and I'm sure you'll tell me if you
just think I'm being paranoid!) -- even with NACK, it is up to *my*
compressor to determine its risk level.  If I'm feeling conservative, then
I'll act in a way that tries to avoid NACKs.  This problem kind of
undermines that, I think.  If I don't know how your endpoint will behave,
my only prudent course of action is to not use shared-mode, except in
direct response to a received message.  If I can believe that your
endpoint will be more circumspect, then I can be more relaxed about using
shared-mode.

Having written and re-read this, I guess what I'm saying is that we need
to make a decision about what model we want for shared-mode.  There seem
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carsten Bormann | 4 Nov 2004 07:46
Favicon
Gravatar

Re: Shared mode

Mark,

your message confuses me.

When you say "the WG needs to choose" -- are you talking about changes 
to normative documents, or are you talking about the recommendations we 
are making for compressor implementers?

Gruesse, Carsten
Permalink | Reply | 0 comments |
headers
Lars-Erik Jonsson (LU/EAB | 4 Nov 2004 08:27
Picon
Favicon

RE: Shared mode

Carsten and others,

I think we are all aware we are talking about functionality
defined in an informative document. However, since we have now
provided non-normative suggestions for how to implement, we
should also provide clarifications to what might be misleading
in that informative document, as well as recommendations for
how to actually implement. Personally I believe the impl.
guide is the right place to put such clarifying text, and of
course the WG will have to decide what we think are the proper
suggestions to put there.

/L-E

> -----Original Message-----
> From: rohc-bounces <at> ietf.org [mailto:rohc-bounces <at> ietf.org]On Behalf Of
> Carsten Bormann
> Sent: den 4 november 2004 07:47
> To: West, Mark
> Cc: Surtees, Abigail; Carsten Bormann; rohc <at> ietf.org; Adam 
> Roach; Lajos
> Zaccomer (IJ/ETH)
> Subject: Re: [rohc] Shared mode
> 
> 
> Mark,
> 
> your message confuses me.
> 
> When you say "the WG needs to choose" -- are you talking
(Continue reading)

Permalink | Reply | 0 comments |

Gmane