RE: [rohc] RoHCv2 and current mail discussions

["Ghyslain Pelletier (LU/EAB)" <[e-mail]>]

Hi Rohit!

As I think that you meant your answer to reach also the RoHC mailing list, I will reply with cc to the list as well!

Kristofer and myself did not have time to tackle the remaining issues with RoHCv2 since last year, but at this point I am interested in moving the work as fast as we can, so we can produce another update soon and send the draft to working group last call. Your help is appreciated!

See comments inline.

///Ghyslain 

Kapoor, Rohit wrote:
> Ghyslain,
> 
> I think both robustness and TBC are important and the right balance
> needs to be found. A couple of points below: 

What I read here is a mix of two different things: one is a property of the compression algorithm, the other is a specific encoding method to optimize a specific case.

My understanding wrt RoHCv2 (requirements) has always been that we need to maintain at least the same robustness properties as for RFC3095, and in addition to improve this robustness to handle better the case where there is reordering. Robustness is something that needs to be addressed in all aspects of the protocol, because the consequence of failing with robustness is protocol-induced packet losses.

Wrt to specific encoding methods, unless these address robustness (such as CRC or wlsb) then their use is related to compression efficiency. In this respect, what I believe is important is to look at the most frequently occuring case (what I refer to "steady-state", or "second order" compression) because this is where a gain in efficiency has the most impact.

Specific cases where one or two octets can be saved for a very few number of packets can be interesting, as long as these optimizations do not conflict with other more important properties, such as robutstness.

This is because we need to work with the general assumption that we can expect links where RoHC is applied to have the capability to handle 1, 2, 3 octets of variation in size above the minimal PT0 size. This also because of the fact that there is from time to time a need to use PT1 and PT2, purely because e.g. of the change patterns of the flow.

So, in this respect, I agree with you that both robustness and compression efficiency are important, but I would argue that not all aspects of compression efficiency have the same importance, and what is addressed by TBC does not weight as much as robustness properties IMO.

I would like to know what others think about this.
 
> 1) As far as robustness goes, even 5 bits provides a robustness of 32
> dropped packets, or if reordering (say 1/4 of INTERVAL) has to be
> supported, then 24 dropped packets and up to 8 reordering. 6 bits
> provides robustness of 16 reordering and up to 48 dropped packets. In
> most systems, I would argue that any service is unlikely to work at
> all if one had drops > 24. In fact, so much consecutive drops will
> likely lead to radio link failure, so why try to handle such packet
> loss at all? So, I am arguing that 5 bits is already very robust and
> 6 bits is overkill.        

I think the main issue here is not the number of consecutive losses, but the reordering depth that is possible.
 
> 2) Also, I think we should be clear when mentioning the gains of TBC.

I agree. IMO the gains should be discussed without any link-layer dependency, i.e. We should use a definition of the gain that cannot change depending on what link layer we use as exemple. The gains should be in "absolute" terms, otherwise we create ourselves a moving target in the discussions and we will never reach consensus this way. RoHCv2 is not designed to be specific to one single link technology, so I think that discussing gains in this way can be agreed?

> To say that TBC gains only one octet is not the complete story.

I interpret this as to that you agree that the absolute gain, i.e. The difference of the compressed header size with and without the use of TBC, is as described in my earlier mail?

> Typically, airlinks are configured to support certain transport block
> formats, and if say your upper-layer packet does not fit in one, then
> the next bigger one could be somewhat larger. So, the impact of 1
> byte larger header may be much more than that. As an example, in the
> DO Rev A standard deployed in the US, Korea and other countries, the
> impact of 1 extra byte could be as much as 32 extra bytes over the
> air. Similar arguments also hold for 3GPP standards such as HSDPA
> (depending upon how airlink is configured).         

I heard this argument before.

I copy-paste at the end of this mail an extract from the HSDPA MAC-HS specifications. It comes from Annex A: "HS-DSCH Transport Block Size Table for FDD" in 25.321.
ftp://ftp.3gpp.org/specs/archive/25_series/25.321/25321-740.zip

The table lists transport block sizes allowed in the in MAC-hsstandard, which lists the lower range of allowed sizes over the air. This clearly shows that for small frames, there is a spacing of 12 bits between each of the transport formats. This I interpret as meaning that adding one extra byte of ROHC header will at the worst case result in a padding of 12 bits.

Therefore, I would argue that your statement does not hold, at least with respect to HSDPA.

If your argument is that your statement is true based on how the link is configured, then I would assume that a proper configuration would be uses. However, this means that the configuration of the link has a also general problem with PT1 and PT2, isn't it so? IMU, these links will be configured to provide efficient means to carry PT1 and PT2 when those needs to be sent anyway. Or at least they should.
 
> As far as required jitter handing by TBC goes, pls keep in mind that
> on the airlink, the jitter is caused not only by the H-ARQ process.
> Some packets could even see a MAC-layer ARQ (which is like a
> higher-layer ARQ functionality). Thus, jitter could be higher than
> that produced only by H-ARQ.    

In 3GPP, that higher-layer ARQ is RLC ("mac-layer ARQ"). My understanding is that this outer ARQ is not meant for real-time services and that RLC AM will not be used for real-time services (I believe this is because the jitter/delay it can introduce goes beyond what the application can tolerate anyway).

> I think supporting 5 bits for TBC is much more important than
> supporting 6 bits for MSN, since 5 bits for MSN are already providing
> a lot of robustness (up to 24 consecutive drops and 8 reordering,
> with reordering = 1/4 INTERVAL).   

I would like to hear others in the working group on this, with technical arguments in favor of TBC. I think we can all agree that the absolute gain is very small, and that TBC is additional complexity.


I would personally favor not supporting it, and moving forward to resolve the other issues instead.

Cheers,

///Ghyslain

nr #bits 
 1   137 
 2   149 
 3   161 
 4   173 
 5   185 
 6   197 
 7   209 
 8   221 
 9   233 
10   245 
11   257 
12   269 
13   281 
14   293 
15   305 
16   317 
17   329 
18   341 
19   353 
20   365 
21   377 
22   389 
23   401 
24   413 
25   425 
26   437 
27   449 
28   461 
29   473 
30   485 
31   497 
32   509 
33   521 

 
> Thanks,
> Rohit
> 
> 
> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB)
> [mailto:[e-mail]] 
> Sent: Wed 6/20/2007 7:45 AM
> To: [e-mail]
> Subject: [rohc] RoHCv2 and current mail discussions
> 
> RoHCers,
> 
> Thanks for the recent discussions and feedback on the draft.
> I would like to find a way to resolve those at this point.
> 
> I see two main issues being discussed:
> 
> 1) Number of TBC and MSN bits in PT-0
>    This has implications on packet formats and robustness
> 
> 2) Two-step transition
>    This has implications on robustness of updating the control fields
> 
> I wil try to summarize these issues in two subsequent mails.
> 
> But first I'd like to point out that one of the issues is related to
> Timer-Based Compression (TBC ...) and I'd like to point out that I
> still do not think that there is a compelling case for including
> support for TBC in RoHCv2: the gain is at most one octet for OA
> number of packets after a "silence period", where the TS to SN
> function need to be adjusted. IMO, this is a very small gain in light
> of the additional complexity.      
> 
> I'd like to put some perspective on all this.
> 
> Please keep in mind that the main objectives of RoHCv2 are:
> A) increased robustness to packet reordering;
> B) similar performance as RFC3095 under similar conditions,
>    for the "steady-state" part;
> C) simpler to implement, simpler logic;
> 
> Basically, parts of A) is achieved in RoHCv2 by:
> A.1) configurable LSB interpretation interval for MSN
> A.2) special care to how control fields are updated
>     (see next mail about 2-step transition)
> 
> In essence, B) is achieved by defining a PT0 that is identical to
> UO-0. 
> 
> And finally, C) is partly achieved by using the operational logic of
> RoHC-TCP as the base, and augment it to handle reordering better. In
> addition, other simplifications have been made (list compression,
> etc.). Orignally, we felt that TBC was falling into this category (I
> still do actually).    
> 
> BUT, if TBC does not impact other features that have higher priority
> in the objectives of RoHCv2, then I might not mind that much that TBC
> gets included.  
> 
> In other words, we have no requirement or objective to optimize for
> specific events or link technology. We do it when it comes at no
> costs to other more important "features".  
> 
> And from my perspective, TBC is not more important IMO than
> robustness against reordering. 
> 
> Therefore, I would argue that we should either not include support
> for TBC, or include support for TBC but keep the packet formats as
> they are in the current draft intact, i.e. Keep 6 MSN bits in
> PT0-CRC7 and keep 4 bits for TS (TBC), as I think that robustness is
> more important.    
> 
> There are other aspects to this question, which I address in the next
> email. 
> 
> Cheers,
> 
> ///Ghyslain
> 
>  --
>  Ghyslain Pelletier, Dipl. Ing.
>  Senior Research Engineer
>  Wireless IP Optimizations
>  Ericsson Research, Corporate Unit
> 
>  Ericsson AB, Laboratoriegränd 11
>  Box 920, S-97128 Luleå, SWEDEN
>  Phone : +46 (0)  8 404 29 43
>  Mobile: [phone]
>  Ghyslain.Pelletier at ericsson.com
>  http://www.ericsson.com
> 
> --------------------------------------------
>  The opinions expressed in this message are
>  my personal opinions.
>  These opinions are not necessarily those of
>  my employer, unless stated otherwise.
> --------------------------------------------
> 
> _______________________________________________
> Rohc mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc


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