Subject: ROHC and ULE

From: [email-masked]
Date: Fri, 27 Oct 2006 10:05:40 +0200

Dear Gorry and ipdvb members,

We, at Alcatel Alenia Space, are indeed interested in this topic.
The I-D appears as a good starting point we would like to comment.

Support of mulitcast / broadcast traffic
In section 3.3 it is mentioned that the proposed scheme will not support
multicast or broadcast traffics.
From our point of view, we would like to reconsider this, provided that
group services may be of importance in DVB systems such as satellite
networks.
Now, how having a multicast addressing to work  with ROHC remains an open
issue, but at least a basic solution would be the use of unidirectional
mode (no need to acknowdege)

(The same question of multicast has already been raised in the ip-dvb
archive (05/05), apparently without any answer ...)

Negociation of parameters between compressor and decompressor
This point does not appear to be address in the document yet, but how to
make the negociation is a real issue for the implementation of ROHC over
ULE. Probably some propositions should be discussed here ? (e.g. use of
default parameters according to the type of DVB network ? PPP replacement ?
use of SI tables ? etc...)

ROHC recommendation
We strongly believe that one of the output of the task shall be ROHC usage
recommendations. This can be either parameters values proposition or
analysis of the best suited mode  depending on different scenarios (namely
unidr system, satcom systems with a return link, in both mesh and star
topologies)

ROHC adaptation
A interesting point to investigate can be ROHC adaptation to fit the
satellite systems and the ULE stack. Two approaches can be foreseen. The
first one is dedicated to simplification of the compression scheme, and the
second one to the optimisation of ROHC in this context.

ULE over ROHC ?
This has never been proposed, but maybe the compression gain could be
pushed a little more, if new ROHC profiles integrating ULE (i.e.. x/IP/ULE)
were supported ? What would be the main barriers for such an approach ?

ROHC and GSE
Another important point is to take into account GSE in order to prepare
future work on the GSE/ROHC topic (How to support ROHC in DVB-S2 / GSE
could be investigated in another I-D taken into account the work done in
this task, as the GSE standardisation process is on-going).

Best regards

Cédric Baudoin and Fabrice Arnal

Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 6817  /  Fax : +33 (0)53435 5560
Porte : W218  /  E-Mail : [email-masked]

This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. ALCATEL ALENIA SPACE (and its subsidiaries)
shall (will) not therefore be liable for the message if modified.

Ce message et toutes les pieces jointes (ci-apres le "message") sont
etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce message non conforme a
sa destination, toute diffusion ou toute publication, totale ou partielle,
est interdite, sauf autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, ALCATEL ALENIA SPACE (et ses filiales)
decline(nt) toute responsabilite au titre de ce message, dans l'hypothese
ou il aurait ete modifie.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Oct 2006 17:53:19 +0200

Hi Cedric,

a couple of comments.

I have made a couple of proposals at previous IPDVB meetings how to  
integrate ROHC into ULE.
E.g., see http://www3.ietf.org/proceedings/05mar/slides/ipdvb-0.pdf
The most important input that would be useful at this point is how  
ROHC will be used in actual systems, see below.

> mode (no need to acknowdege)

ROHC works fine in U-mode on unidirectional channels.
On a satellite link, the high delay for a context repair may actually  
make this the best mode to look at.

> use of SI tables ? etc...)

We could probably come up with some default values.  You would still  
need to look at capacity points such as number of CIDs.
These could be "announced" (as opposed to "negotiated").

> unidr system, satcom systems with a return link, in both mesh and star

I'm happy to do this work if enough people are interested.

> first one is dedicated to simplification of the compression scheme,

Actually, we have just done that:

draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt

"...The RoHCv2 specification introduce a number of
     simplifications to the rules and algorithms that govern the  
behavior of the
     compression endpoints..."

> and the

see above/below...

> were supported ? What would be the main barriers for such an  

These would probably be easy to add to ROHCv2.

Gruesse, Carsten

---

From: John Border <[email-masked]>
Date: Mon, 30 Oct 2006 12:59:20 -0500

Preliminary to my embedded responses...  I think there are two 
parts.  The first is a mechanism to indicate when the payload contains a 
packet which has a compressed header.  This is the problem we ran into 
with MPE which made us take a look at ULE.  The second is whether or not 
we need to specify a means for the compressor and decompressor to 
communicate or we just assume an out of band mechanism (which is likely 
to be using other IP messaging)...

>mode (no need to acknowdege)
The draft is currently only referencing a mechanism to signal that 
something has a compressed header.  In that context, there is really no 
reason not to support multicast.  (I had already made a note to myself 
to fix this.)

I think synchronizing multiple decompressors with a compressor may be 
challenging.

>use of SI tables ? etc...)
To get things started, the draft just currently assumes out of band.  
But, this is what I really wanted to see discussed.  My own opinion is 
not well formed yet...

>second one to the optimisation of ROHC in this context.
We were trying to make the mechanism independent from the specific 
algorithm(s).  On the other hand, some ROHC usage recommendations re ULE 
would be very useful. 

>ou il aurait ete modifie.
John Border
Hughes