Subject: RE: [rohc] Synchronization of ROHC compressors forsinglefrequencynetwork operation

From: "West, Mark" <[email-masked]>
Date: Thu, 24 May 2007 09:52:34 +0100

I suspect that you would also need to ensure that exactly the same sequence of packets is received at each compressor... any loss or difference in loss patterns at compressors could throw synchronisation out.

If you require absolutely bit-identical packets with no constraints on the behaviour of the RTP source, and an arbitrary distribution network then I think that *may* be possible (i.e. have a non-zero probability of success).  But only 'maybe'...

Cheers,

Mark.

> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB)
> [mailto:[email-masked]]
> Sent: 24 May 2007 07:53
> To: Kumar Vinod-A20689; Ghyslain Pelletier (LU/EAB)
> Cc: [email-masked]; West, Mark; [email-masked]
> Subject: RE: [rohc] Synchronization of ROHC compressors
> forsinglefrequencynetwork operation
> 
> 
> Hi Vinod,
> 
> comments inline.
> 
> Kumar Vinod-A20689 <mailto:[email-masked]> wrote on 
> den 24 maj
> 2007 07:25 :
> 
> > 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? 
> 
> 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
> > 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.
> 
> 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
> > 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.
> 
> 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.
> 
> > 
> > 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. 
> 
> 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.
> 
> > 
> > The fact that we are interested only in U-mode may also 
> mean that the
> > 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
> 
> > 
> > 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,
> > 
> > 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
> > 
> > 
> > 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: Thu, 24 May 2007 11:33:51 +0200

I agree with Kristofer here. And I will freely interpret Mark's as usual
very careful way of wording his opinion using "(i.e. have a non-zero
probability of success)" as being in agreement with Kristofer as well ;
)

This type of synchronization would require some RoHC-related centralized
functions in any case, implying an interface in between and some
duplication of functions/state. Some of this would be framework-related,
others would be profile-specific. All this with less compression
efficiency than for a deployment where RoHC is centralized above eNBs.
Simplicity and achievable efficiency both seem to hint in favor of a
centralized RoHC deployment for MBMS SFN operation, and actually I fail
to see any problems with the centralized approach with the scenario that
was described.

> And you need a communication protocol gateway <-> compressor that
> passes these values inside messages every time you have a change in
> any of them

This "communication protocol" would have to be 100% reliable, and would
require that there is no reordering possible between user data and the
information sent from GW to eNB. And garanteed in-time delivery if the
synchronization has to be timing based.

> implementation is not a small change as described above.

I think the more we'd look into this, the more problems we would find.

///Ghyslain 

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

I suspect that you would also need to ensure that exactly the same
sequence of packets is received at each compressor... any loss or
difference in loss patterns at compressors could throw synchronisation
out.

If you require absolutely bit-identical packets with no constraints on
the behaviour of the RTP source, and an arbitrary distribution network
then I think that *may* be possible (i.e. have a non-zero probability of
success).  But only 'maybe'...

Cheers,

Mark.