Subject: [rohc] Shared mode

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 2 Nov 2004 17:26:19 -0000

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.

All comments are appreciated.  If I don't hear anything by Nov 19th (1 week
after Washington) then I'll take this as consensus and propose some text for
the implementer's guide.

Best regards,

Abbie

Abbie Surtees
Senior Engineer
Roke Manor Research Ltd
Old Salisbury Lane
Romsey, SO51 0ZN
Tel:   +44 (0) 1794 833131

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Nov 2004 19:44:27 +0100

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

---

From: "West, Mark" <[email-masked]>
Date: Tue, 2 Nov 2004 22:51:59 +0000 (GMT Standard Time)

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 <[email-masked]>
> To: "Surtees, Abigail" <[email-masked]>
> Cc: Carsten Bormann <[email-masked]>, [email-masked]
> Subject: Re: [rohc] Shared mode
>