RE: [rohc] Short summary of the new ROHCv2profiles:draft-pelletie r-rohc-rohcv2-profiles-00.txt

["Trabelsi, Chokri (Chokri)" <[e-mail]>]

Hi,

After reading the draft, I have the same impression as Rohit. The new draft includes a quite a bit of changes, although most of these changes will make ROHC implementation more Robust and simplify the specification as pointed out by Kristofer, however these changes will affect significantly the current ROHC implementation based on RFC3095 and this could have several impact to different 3GPP2 companies. From that perspective I would like to join Rohit and point out my concern and ask if possible to address this issue and make the changes simpler for those who have already implemented ROHC based on RFC3095. For someone who invested a lot of development and testing resources to develop ROHC based on RFC3095, may not need to implement all these changes at least in initial phase and therefore we support the idea of having an additional profile (in addition to the proposed one in the current ROHCv2 draft) with a necessary changes just to support reordering (which is the main issue!
  for 3GPP2) among few other important things as addressed in RFC4224 but not as large as in the current ROHCv2 draft. 

A side note: For the UO-1-TS replacement, pt_1_seq_ts, I am wondering why the timestamp has been changed to 4 bits. If Timer-based compression will be supported, 4-bits will not be enough! This needs to be looked at when the faith of  Timer-based compression will be decided.

Regards

Chokri Trabelsi

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:[e-mail]]
Sent: Fri, June 30, 2006 4:40 AM
To: Kapoor, Rohit; Ghyslain Pelletier (LU/EAB); [e-mail]
Subject: RE: [rohc] Short summary of the new
ROHCv2profiles:draft-pelletier-rohc-rohcv2-profiles-00.txt


Hi Rohit,

thanks for the feedback on the draft. Below, I try to summarize what
I belive of the issues you describe.

The ROHCv2 draft has never been intended to just be a quick-fix
for reordering, it is designed based on what has been agreed by the
WG in draft-ietf-rohc-rfc3095bis-improvements, which of course means
that there will be quite a bit of changes from 3095.
IMO, The main reason for v2 has been to simplify the specification to
get out of the interop problems and unneeded complexity that 3095 has
suffered from (I think that the size of the impl-guide is quite a 
definite proof that this has been and still is a bit of an issue). 

Regarding making 3095-profiles handle reordering, it seems like a
lot of people assume that we just have to change the p-value
and things will work fine. The p-value issue is just one part
of the problems we described in RFC4224 (the p-value is really just
section 5.1.1. of the problem statement) (*). 
To handle the rest of the "reordering issue", a number of the other
"features" that cause reordering-problems with 3095 
(e.g. R-mode, reference-based list compression) should also be changed.
So, I do not think that a "small change" is possible when it comes to 
make 3095 truly tolerant to on-link reordering. For the same reason, I
also think  that trying to include an extra set of profiles in v2 that 
are "backwards-compatible" with 3095 is not the correct way forward 
since those profiles would have different reordering-issues to adress 
than the v2-profiles and therefore fit better in its own document.
If 3GPP2 feels an absolute need to add such a set of profiles, I think
the best way forward is if you make a completely separate draft for 
this and try to adress all the problems described in RFC4224. And as
I said, that will require a certain amount of changes; maybe not as
large as the current v2-profiles, but still more than just variable
p-values.

Also, the ROHCv2 profiles are implementation-wise a lot simpler 
than the profiles in 3095 since we have removed the corner-case
optimizations that are what causes the implementation and 
testing of 3095 to be such a difficult thing. So I still belive that 
the ROHCv2 profiles that we are suggesting are the correct way forward,
but of course it is interesting to discuss this further.

(*) I think that even v2 still needs a bit more text on this subject,
but that will come in the next revision if I can convince my
co-author :)

BR,
   Kristofer Sandlund

Kapoor, Rohit wrote:

> Ghyslain, Lars-Erik,
> 
> Thanks for producing this new RoHC profiles draft, which adds
> efficient support for reordering, among other changes.
> 
> Having read the draft, I realize that it contains substantial
> changes from the 3095 profiles, key among these being:
> 
> --- Efficient support for reordering is added.
> --- Packet structures are different from the 3095 profiles.
> --- Decompressor state logic is somewhat different.
> --- Timer-based compression is not supported.
> 
> Please note that some 3GPP2 companies have already invested
> resources in implementing and testing 3095 profiles and were
> looking for only small changes for support of reordering.
> From this point of view, these new profiles are a substantial
> change and will require that a lot of resources be re-invested.
> 
> I just wanted to point out this concern to see if we can find
> some way to address this in the new profiles. One option may
> be to add a section in the new draft for profiles that
> inherit all the functionality of the 3095 profiles with the
> only change being efficient support for reordering (of
> course, these profiles would also need new profile IDs). If
> required, we would be willing to contribute such a section.
> 
> I look forward to your comments.
> 
> Thanks,
> Rohit
> 

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

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