Subject: RE: [rohc] Implementer's guide - it's that time again

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 16 Feb 2006 12:49:30 -0000

Hi All,

I didn't receive any issues by Feb 10th, however, I do have a couple to
raise myself:

Feedback:

SigComp states "Moreover, the responsibility for ensuring that feedback
data arrives
   successfully over an unreliable transport lies with the sender.  The
   receiving endpoint always uses the last received value for each field
   in the feedback data, even if the values are out of date due to
   packet loss or misordering."

I assume that when an endpoint receives a valid message, it updates the
feedback data for that compartment.  The endpoint should then set this
feedback on every message sent within the compartment until it receives
another valid message that updates the feedback.

However, what happens if a message is received in between but has one of
the following:
	requested_feedback_location = 0
	requested_feedback_location != 0, but Q = 0?

For each case there appear to be 3 possibilities:
 1) the existing feedback data should be left untouched
 2) the existing feedback data should be overwritten to be 'no feedback
data'
 3) the behaviour is undefined

Presumably, at the moment the answer in both cases is 3) undefined.  The
question is, should it be clarified as 1) or 2) in the implementer's
guide?

Packet re-ordering:

SigComp doesn't mention re-ordering apart from in the text quoted above.
It does, however, state that "The compressor MUST ensure that the
message can be decompressed using the resources available at the remote
endpoint."  which of course means that it is up to the compressor to
ensure that it takes account of re-ordering in any messages it sends.

Depending on the compartment definition, re-ordering is more likely than
one might think.  TCP promises in order delivery.  Given the nature of
SIP dialogs, the likelihood of re-ordering over UDP within a SIP dialog
is relatively unlikely.  However, for a compartment in which dialogs or
transactions can be interleaved and can be over different transports,
there is a significant risk of re-ordering occurring between packets
sent over UDP and over TCP.

Proposal:  To add a statement to the implementer's guide reminding the
implementer that this is an issue for the compressor.

State advertisements:

When using the list of partial state identifiers in returned SigComp
parameters, what is the sender actually saying about the states
identified?  In particular, where are they stored and how long will they
be available?

Section 3.3.3 discusses locally available state items as ones that have
not been requested by the remote endpoint.  The types of states
discussed are bytecode and dictionaries that would presumably be
available to all compartments and therefore not stored within the SMS of
any one compartment.  The implication of this is that, once advertised,
the state is always available for the duration of the compartment
(unless the I flag is used).  

Section 9.4.9 says nothing about them other than the structure of the
identifier list within the UDVM.

RFC3321 discusses their use in two ways:

Section 5.1.2 - local endpoint initiated acks.  An endpoint can
advertise back a piece of state that the remote end has just requested
to be created.  Presumably, this state will be pushed out of the
compartment by any new requests the remote endpoint makes.  How does
this fit with advertising locally available state as discussed in
section 3.3 of rfc 3320.

Section 5.2 - shared compression.  The use of state at priority 65535
for shared mode is fairly clear - it can be pushed out of the
compartment by requests made by the remote compressor.  This has to be
the case for a shared mode enabled endpoint to be able to able to
communicate with a non shared mode endpoint.  [I think, with the
clarification that is already in the implementer's guide, shared mode is
clear and does not add to the confusion.  I include it here for
completeness.]

I think section 5.1.2 of 3321 confuses the statements in 3.3.3 and could
do with clarification. 

What does anyone else think, on any of these issues?

Best regards,

Abbie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Surtees, Abigail
> Sent: Thursday, February 02, 2006 11:54 AM
> To: [email-masked]
> Subject: [rohc] Implementer's guide - it's that time again
> 
> Hi All,
> 
> The implementer's guide expired in January so it's time to update it
> again.  There's one comment outstanding about clarifying section 3.2
> MULTILOAD
> (http://www1.ietf.org/mail-archive/web/rohc/current/msg03949.html).
> 
> Are there any other issues that should be clarified in the 
> implementer's
> guide?  If so, please raise them on the list by Friday Feb 10th.
> 
> 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
> 

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

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 22 Feb 2006 14:45:46 +0100

> sent over UDP and over TCP.

cristian: hi! do you want to suggest here that the _same_ compartment
from a certain peer should be able to receive messages _at the same_
time on both tcp and udp (or any other transport protocol)?? can a
compartment in a peer communicate to more than 1 compartment in other
peers?

could you please provide an example of a (SIP) configuration/scenario when
something like this happens?...

thanks.
bye now!
cristian
-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc