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

["Kapoor, Rohit" <[e-mail]>]

Kristofer,

Thanks for the detailed reply. Based on your reply, it seems to me that
the best course of action for 3GPP2 companies is to make a completely
separate draft which handles the reordering issues. Some 3GPP2 companies
are now working on such a draft.

Also, I have a couple of other comments on the v2 draft:

--- I agree with Aniruddha's comments on support of timer-based
compression. Since timer-based is optional anyway, I think it does not
hurt to have it included in the v2 profiles. This way, systems that can
gain from the use of timer-based are free to do so.

--- The v2 profiles have 2 bits for representing the reordering choice,
i.e., the p value can be 1/4, 1/2 or 3/4 of the interval. I think it may
help to have a little more granularity in representing the reordering
choice. It will help to really optimize the use of RoHC over air
interfaces whose behavior in terms of reordering and packet drops is
well understood. Also, since headers carrying the "reordering choice"
bits will likely not be sent too frequently, adding a bit or two for
"reordering choice" should not add much to average compressed header
size.

Look forward to comments.

Thanks,
Rohit 



> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB)
[mailto:[e-mail]]
> Sent: Friday, June 30, 2006 1: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