Subject: RE: [rohc] Synchronization of ROHC compressors for singlefrequencynetwork operation

From: "West, Mark" <[email-masked]>
Date: Wed, 23 May 2007 10:03:23 +0100

Surely you would need other constraints too:
 
* restricted subset of packet formats to avoid ambiguous compressor choices
 
* identical packet losses prior to the compressor 
  - to ensure synchronised down/up transitions
  - to ensure identical packet formats
 
I agree with Kristofer.  Even if such synchrony were possible, it would add a lot of complexity and fragility -- ROHC was never designed to support this kind of usage.
 
Cheers,
 
Mark.

-----Original Message-----
From: Biplab Sarkar [mailto:[email-masked]]
Sent: 23 May 2007 09:57
To: Kristofer Sandlund (LU/EAB)
Cc: [email-masked]; Kumar Vinod-A20689
Subject: RE: [rohc] Synchronization of ROHC compressors for singlefrequencynetwork operation

Vinod/Kristofer,

Might be by enforcing extra constrains one might achieve this to some extent.

Constraints like:
[1] No feedback.
[2] Only WLSB based encoding
[3] No packet out of order delivery at the input of the compressor.
[4] Same set of attributes to control the different compressors.

Keeping all these restrictions will keep the compressors to run in unison 

Thanks
Biplab

On Wed, 2007-05-23 at 10:12 +0200, Kristofer Sandlund (LU/EAB) wrote: 

Hi Vinod,

I do not consider it feasible to have multiple independent ROHC

implementations produce bitwise identical output

(even if there are *no* losses before the compression point(s)).

The ROHC standard leaves a lot of flexibility up to the 

implementation and therefore you can *never* guarantee that two

ROHC compressors will behave identically even when they get

identical input.

All you can know is that they will interoperate, but not more

than that.

BR,

   Kristofer

Kumar Vinod-A20689 <mailto: [email-masked]> wrote on den 23 maj

2007 07:09 :

> Hi All,

> 3GPP, as part of its long term evolution (LTE) work,  is

> currently discussing single frequency network (SFN) operation

> for offering multicast and broadcast multimedia services

> (MBMS) . In SFN operation, all the eNBs (base stations) of

> the SFN area transmit identical content of an MBMS service

> over identical air interface resources (i.e., on identical

> time-frequency slots). The clocks at all the eNBs of the SFN

> area are synchronized.

> One of the issues is the location of ROHC for SFN operation.

> For MBMS, U-mode is currently the preferred mode of

> operation. If ROHC compressor is placed in a centralized node

> above the eNBs, then all the eNBs will receive identical

> packets so that content synchronization over-the-air can be

> achieved. However, if ROHC compressors are located at the

> eNBs, then it is important to ensure that all ROHC

> compressors in the SFN area choose identical packet types

> with identical content at all times. Note that packet losses

> may occur over the backhaul where some eNBs may receive a

> particular packet while others do not receive it. During such

> occurences, the ROHC compressors must continue to choose

> identical packet types for subsequent packets. In other

> words, the ROHC compressors must operate synchronously at all times.

> I would like to know if synchronizing the ROHC compressors

> (with potentially different implementations) for U-mode is

> feasible. If yes, are there some good solutions?

> Thanks,

> Vinod

_______________________________________________

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: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 23 May 2007 15:20:22 +0200

Hi Vinod,

I very much agree with both Kristofer and Mark here.

My understanding is that this type of synchronization, where multiple
compressors would operate in unidirectional mode (no feedback) and be
required to produce bitwise identical output (or nothing, if a packet is
lost before the compression point) would require that:

1) the selection of compressed header format be made deterministic for
  the same uncompressed input (one-to-one mapping between input/output),
  including what optional fields and extensions are used in formats;
2) the context management be rigorously specified, i.e. That a
  specific sequence of uncompressed packets leaves the exact same
  state for any implementations, as one of the inputs to compression

One aspect of the  above point is the impacts of the sequence/order of
uncompressed packets to the context ... which must be exactly the same
for all compressors OR that corrections can somehow be applied to the
context of the compressor that did not get the packet (how this would be
achieved is beyond my understanding)

Another aspect of point 2) is flow classification, and how CIDs would be
associated to different flows. All flow classifiers would have to
produce the exact same CID/flow associations, otherwise the output would
not be bit-wise identical. Also, for UDP flows, profile switching would
have to be synchronized. Also, if reordering and/or losses before the
compression point occurred after or before the break-out point (e.g. The
MBMS-GW) would have to be detected, and the list of issues would just go
on ...

All of the above (i.e. packet selection, context management and flow
classification) is explicitely outside scope of the RoHC specifications.
These specifications rather strive to ensure interoperability and make
it possible for different implementations define their own level of
robustness.

More specifically, RoHC defines interoperable encoding methods and
compressed header formats. More than one format may be applicable for
the same uncompressed input. What format is the most appropriate depends
on how the compressor manages its context. While this may be affected by
losses/reordering before the compression endpoint, this is not the
factor that determines what packet is selected by a compressor. RoHC
does not define how the compressor manages its context, and it does not
define how the compressor selects what compressed header to use.

With this in mind, it should become clear that synchronized compression
as described in your mail does not go very well hand in hand with RoHC.

On the other end, for the scenario that you describe, it seems that
locating the header compression endpoint centrally above the eNBs would
make perfect sense from a RoHC perspective.

///Ghyslain

-----Original Message-----
From: West, Mark [mailto:[email-masked]] 
Sent: den 23 maj 2007 11:03
To: [email-masked]; Kristofer Sandlund (LU/EAB)
Cc: Kumar Vinod-A20689; [email-masked]
Subject: RE: [rohc] Synchronization of ROHC compressors
forsinglefrequencynetwork operation

* restricted subset of packet formats to avoid ambiguous compressor
choices

I agree with Kristofer.  Even if such synchrony were possible, it would
add a lot of complexity and fragility -- ROHC was never designed to
support this kind of usage.
 
Cheers,
 
Mark.

	-----Original Message-----
	From: Biplab Sarkar [mailto:[email-masked]]
	Sent: 23 May 2007 09:57
	To: Kristofer Sandlund (LU/EAB)
	Cc: [email-masked]; Kumar Vinod-A20689
	Subject: RE: [rohc] Synchronization of ROHC compressors for
singlefrequencynetwork operation

	Vinod/Kristofer,
	
	Might be by enforcing extra constrains one might achieve this to
some extent.
	
	Constraints like:
	[1] No feedback.
	[2] Only WLSB based encoding
	[3] No packet out of order delivery at the input of the
compressor.
	[4] Same set of attributes to control the different compressors.
	
	Keeping all these restrictions will keep the compressors to run
in unison 
	
	Thanks
	Biplab
	
	On Wed, 2007-05-23 at 10:12 +0200, Kristofer Sandlund (LU/EAB)
wrote: 

		Hi Vinod,
		
		I do not consider it feasible to have multiple
independent ROHC
		implementations produce bitwise identical output
		(even if there are *no* losses before the compression
point(s)).
		
		The ROHC standard leaves a lot of flexibility up to the 
		implementation and therefore you can *never* guarantee
that two
		ROHC compressors will behave identically even when they
get
		identical input.
		All you can know is that they will interoperate, but not
more
		than that.
		
		BR,
		   Kristofer

		Kumar Vinod-A20689 <mailto:[email-masked]>
wrote on den 23 maj

---

From: "Kumar Vinod-A20689" <[email-masked]>
Date: Thu, 24 May 2007 13:24:49 +0800

Hi Ghyslain, Biplab, Kristofer, Mark, and All,

Thanks for your responses. I understand that synchronizing the
compressors at all eNBs is complex. However, as Biplab suggested, by
enforcing certain constraints on ROHC behavior, wouldn't it be possible
to achieve this? Of course, the set of rules that we define can
trade-off compression efficiency to some extent. For example, we can
limit the number of packet types (and extensions) that can be chosen by
ROHC compressor. In addition, one can mandate that the timers for state
transitions in U-mode be specified in units of time (e.g., in seconds)
rather than in terms of number of packets. This can ensure that all
compressors move between higher and lower compression states at exactly
the same instant independent of the number of packets they have
transmitted.

I would also like to point out that in 3GPP LTE MBMS, there is a control
entity called the Multicast Coordination Entity (MCE) that is currently
responsible for configuring the RLC and MAC layers at all the eNBs. One
can imagine that this entity can also be used to configure all relevant
ROHC parameters such as CID, timer values, etc. at all the eNBs. In this
fashion, it can be ensured that all ROHC compressors begin with
identical contexts and parameters.

It will be useful to understand the feasibility of defining such
behavioral rules for ROHC compressors even if this leads to compromising
on compression efficiency to a reasonably small extent. In the most
straightforward realization (and obviously with really low compression
efficiency), we can just have IR and IR-DYN packets with the compressors
making transitions between these two packet types at periodic time
intervals. Hopefully, we should be able to do better than this. 

The fact that we are interested only in U-mode may also mean that the
impact on current ROHC implementations is minimized.

Regards,
Vinod 

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]] 
Sent: Wednesday, May 23, 2007 6:50 PM
To: Kumar Vinod-A20689
Cc: [email-masked]; West, Mark; [email-masked]; Kristofer
Sandlund (LU/EAB)
Subject: RE: [rohc] Synchronization of ROHC compressors
forsinglefrequencynetwork operation

Hi Vinod,

///Ghyslain

-----Original Message-----
From: West, Mark [mailto:[email-masked]]
Sent: den 23 maj 2007 11:03
To: [email-masked]; Kristofer Sandlund (LU/EAB)
Cc: Kumar Vinod-A20689; [email-masked]
Subject: RE: [rohc] Synchronization of ROHC compressors

 

Cheers,
 
Mark.

	-----Original Message-----
	From: Biplab Sarkar [mailto:[email-masked]]
	Sent: 23 May 2007 09:57
	To: Kristofer Sandlund (LU/EAB)
	Cc: [email-masked]; Kumar Vinod-A20689
	Subject: RE: [rohc] Synchronization of ROHC compressors for

	Vinod/Kristofer,

	Constraints like:
	[1] No feedback.

	Thanks
	Biplab

		Hi Vinod,

		
		BR,
		   Kristofer

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Thu, 24 May 2007 08:53:15 +0200

Hi Vinod,

comments inline.

Kumar Vinod-A20689 <mailto:[email-masked]> wrote on den 24 maj
2007 07:25 :

> to achieve this? 

I guess anything is _possible_, but if you were to do this,
you would pretty much have to implement half of ROHC in the 
gateway node in order to do this. More on this below.

>Of course, the set of rules that we define can
> rather than in terms of number of packets.

First of all, the "timers" etc for state transmissions are not normative
in a ROHC implementation. How/when/why any compressor decides to move
to an upper/lower state is completely up to the implementation and
the text in 3095 about timers is just an example. It is a very frequent
misunderstanding that all the "k out of n", the timers/periods described
in 3095 are actually normative.
So if you would try this, you would have to change the logic in
all existing implementations.

> This can ensure that all
> entity called the Multicast Coordination Entity (MCE) that is
> currently responsible for configuring the RLC and MAC layers at all
> the 
> eNBs. One

Which is not enough.... As Ghyslain pointed out, there's a lot more
than "initial state" that decides the behavior. Let's take some examples
(note that this is a non-exhaustive list, this is just a subset
of the problems you would have to face).

- The gateway would have to do flow classification and profile
selection.
So quite a bit of the ROHC implementation is duplicated into the
gateway.
How to do classification is far from trivial. 
- The gateway has to decide all the control fields, TS_STRIDE,
IP-ID behavior etc. And the gateway has to also update these values when
there are changes in the flow (or when it made the wrong initial guess.
This means a lot of the ROHC logic is again moved up to the gateway. 
And you need a communication protocol gateway <-> compressor that passes
these values inside messages every time you have a change in any of them
- For non-RTP profiles, you need to make sure all compressors use the
same
sequence number even if you have losses or reordering on the transport
network (you probably need to set this in the gateway and pass it for
every packet)
- You would have to make sure all compressors use the exact same
updating
logic for list compression (w.r.t. reference-based or not).
You would have to make sure that the compressors map _each_ item in both
the extension header and CSRC schemes to the exact same indices and that
they are maintained for the same time (and that you use the same
generation
IDs and....). 
And the list compression updating logic does not necessarily follow the
normal optimistic approach, so here are more preconfiguration issues.
So much of the list compression implementation goes up into
the gateway (and therefore into the new protocol gateway<->compressor)
- You would have to assure that all compressors contains the exact same
logic with how it defines its logic and selects reference values for
_every_
field in the packet stream. Means you pretty much have to DEFINE how a 
ROHC context looks and how it behaves for every type of input.
This is not a trivial change to an implementation or not a small thing 
to specify either.
- Assume you're starting transmissions in a new cell after the other
cells
are already operating. How do you pass over the exact state of the other
compressor's contexts? The context is as previously stated not defined
by
the ROHC specifications. Does your gateway ask one of the compressors to
pass its context to the new compressor?

So basically, you would have to implement half of ROHC in the gateway,
you would need to have a message-passing protocol between gateway and
compressor. So why not put the entire ROHC into the gateway instead? It
would save you a lot of trouble down the line.

> behavioral rules for ROHC compressors even if this leads to
> compromising on compression efficiency to a reasonably small extent.
> In the most straightforward realization (and obviously with really
> low compression efficiency), we can just have IR and IR-DYN packets
> with the compressors making transitions between these two packet
> types at periodic time intervals. Hopefully, we should be able to do
> better than this. 

Even a simple IR/IR-DYN scheme has most of the issues above since all
the robustness concens and logic is up to each implementation.
Especially list compression will give you trouble.

> impact on current ROHC implementations is minimized.

Trying to mandate a bitwise-identical behavior on any ROHC
implementation is not a small change as described above.

BR,
   Kristofer

> Sandlund (LU/EAB) Subject: RE: [rohc] Synchronization of ROHC
> compressors forsinglefrequencynetwork operation
> 
> Hi Vinod,
> 
>   the same uncompressed input (one-to-one mapping between
>   input/output), including what optional fields and extensions are
> used in formats; 2) the context management be rigorously specified,
>   i.e. That a specific sequence of uncompressed packets leaves the
>   exact same state for any implementations, as one of the inputs to
> compression 
> 
> classification) is explicitely outside scope of the RoHC
> specifications. These specifications rather strive to ensure
> interoperability and make it possible for different implementations
> define their own level of robustness. 
> 
> With this in mind, it should become clear that synchronized
> compression as described in your mail does not go very well hand in
> hand 
> with RoHC.
> 
Sent: 23
> 	May 2007 09:57 To: Kristofer Sandlund (LU/EAB)

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Thu, 24 May 2007 23:50:15 +0200 (CEST)

Hi Vinod,

If I understand correctly, a more general form of the question you're 
asking is if a near-identical input stream is put into multiple ROHC 
compressors, could there be identical output from each of them.

Currently, even if an identical stream is fed into a single 
RFC-compliant compressor repeatedly, the output of each iteration need 
not necessarily be identical.

If the identcal stream is fed into multiple identical-implementation 
compressors on different hardware, it's even less likely each output 
be identical.

Adding to the complexity of this scenario, and probably closer to what 
you're asking: Can we get identical output streams, when non-identical 
input streams are fed into independently implemented compressors 
running on different platforms? I would say that this may *not* be 
possible (i.e. have a near-zero probability of success :-)

Note that the output of the compressors in all cases would be 
ROHC-compliant -- just not identical.

Regards,
vick