Subject: [rohc] Reordering Support in RoHC

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 9 Feb 2005 15:32:27 -0800

RoHC Experts,

We are interested in adding reordering support to the RTP profile of
RoHC. While RFC 3095 says that the 'p' value should be set to 1 (which
cannot handle reordering > 1), draft
(<draft-ietf-rohc-over-reordering-01.txt>) defines a template (Section
6.2.2.1) which suggests use of larger values of p on which new profiles
can be defined.
 
As the reordering draft mentions, there is an inherent trade-off between
RoHC's ability to handle reordering and consecutive dropped packets. Due
to this fact, setting 'p' to a very large value to support any kind of 
reordering may not be the best strategy since this can affect the
ability of RoHC to handle consecutive dropped packets. It would thus, be
of great interest to us if the 'p' value is negotiable (similar to the
way MAX_CID, PROFILES etc) are negotiated. This would allow the
compressor/decompressor to use the 'p' value most suited to their link
characteristics.
 
A second issue that interests us is adding support to the RTP profile of
RoHC to support constant (read 0) IP-IDs. Note that the IP profile of
RoHC (RFC 3843) already has support for constant IP-IDs. Such
functionality should thus be easy to add to the RTP profile of RoHC.
 
We would like to get comments from RoHC authors for the best way we can
support the above two issues. If, for supporting the above two issues,
we need to define a new profile, then that will be our approach. 
Alternatively, if at some later stage, such issues could be incorporated
as part of basic RoHC profiles (RFC 3095), then that would be useful
too.
 
Please give us ideas on the best way to approach this from an IETF point
of view.

Thanks,

Rohit Kapoor,

Qualcomm Inc.

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

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Fri, 11 Feb 2005 18:05:21 -0800

Lars-Erik,

Thanks for the prompt response. Please find my comments embedded.

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB)
[mailto:[email-masked]]
> Sent: Thursday, February 10, 2005 7:34 AM
> To: Kapoor, Rohit; [email-masked]'
> Subject: RE: [rohc] Reordering Support in RoHC
> 
> Hi Rohit,
> 
> >  We are interested in adding reordering support to the RTP profile
> >  of RoHC.
> 
> That is good news, as similar ideas have lately been expressed by
> various parties. Can you elaborate on the actual application you
> have in mind, is it multihop scenarios (like tunneling, MPLS, etc),
> or normal single link header compression?
> 

We are interested in single link header compression.

> > As the reordering draft mentions, there is an inherent trade-off
> > between RoHC's ability to handle reordering and consecutive dropped
> > packets. Due to this fact, setting 'p' to a very large value to
> > support any kind of reordering may not be the best strategy since
> > this can affect the ability of RoHC to handle consecutive dropped
> > packets.
> 
> True, although I would not say it is just a trade-off between loss and
> reordering robustness, but it is also a question of what compression
> efficiency should/can be offered for improved robustness. However,
> considering this from a 3095 point of view, it boils down to picking
> a proper value for p.
> 
> 
> > It would thus, be of great interest to us if the 'p' value is
> > negotiable (similar to the way MAX_CID, PROFILES etc) are
> > negotiated. This would allow the compressor/decompressor to use
> > the 'p' value most suited to their link characteristics.
> 
> Yes, to be able to handle reordering, one have to find a way to
> get a ROHC profile operating with a different p value. However,
> this can be achieved in several different ways. Link layer
> negotiation is one approach, but I am personally reluctant to
> go that way, as that would require a change to ROHC link layer
> mappings, which is something I believe should be avoided. If a
> link layer supports ROHC negotiation, it should be able to handle
> all ROHC profiles, in my mind. Anyway, there are several other
> ways to do this. One that still require link-layer changes
> without changing the actual link layer negotiation mechanisms is
> to require that link layer specifications specify a p value, and
> then have a default value to be used if no other value is specified.
> Other approaches, which I personally would prefer, are to either
> use different profile numbers to distinguish between different
> encoding strategies, or to use in band configuration within one
> single profile, i.e. explicitly transmit the p value within IR
> or IP-DYN headers.

As I see it (from yours and Carsten's descriptions), there are broadly
two ways to support negotiation of 'p':

1) Change link layer to support negotiation of p.
	Cons: Requires changes to link layers.
	Minor con: can only negotiate 'p' value per channel, not per
CID.

2) Do p value negotiation in-band using IR (RoHC context setup) packets.
	Pros: No change to link layer.
	Minor Pro: Can negotiate 'p' value per CID.

Based on these, it looks like 2 is the better option. It is also the
preferred option from our point of view.

> 
> > A second issue that interests us is adding support to the RTP
> > profile of RoHC to support constant (read 0) IP-IDs. Note that
> > the IP profile of RoHC (RFC 3843) already has support for
> > constant IP-IDs. Such functionality should thus be easy to add
> > to the RTP profile of RoHC.
> 
> See below...
> 
> 
> > We would like to get comments from RoHC authors for the best
> > way we can support the above two issues. If, for supporting
> > the above two issues, we need to define a new profile, then
> > that will be our approach. Alternatively, if at some later
> > stage, such issues could be incorporated as part of basic RoHC
> > profiles (RFC 3095), then that would be useful too.
> 
> In any case, we would have to define new profiles, as the 3095
> profiles do not have this support. The alternatives are really:
> 1) Define new 3095-based profiles with this support, and give
>    them new profile numbers
> 2) Incorporate these issues into the 3095bis work that the WG
>    is chartered to do, but which is on hold due to resource
>    limitations in the WG (focus is currently on finalizing
>    ROHC TCP).

Either of the above two options works for us. btw, what is the status of
3095bis as of today? Also, will it be quicker going with one alternative
as opposed to the other?

> Personally, I would prefer alternative 2), as I believe RFC
> 3095 is getting overloaded, and we have learned a lot since it
> was published, which means 3095bis will become a much simpler
> and more straightforward standard. The question is however when
> this will actually be needed, as only doing the tiny little fixes
> for reordering, IP-ID=0, etc, purely based on current RFC 3095
> will for sure be doable with a much more aggressive time plan.
> 
> So, one question in addition to the one about envisioned
> applicability is what kind of time plan you have in mind?

We are at the moment not too aggressive with our timeline, but at the
same time I'm not sure what "aggressive timeline" means in IETF terms.
If you could give us some idea about that, it would help us give a more
precise answer on this issue.

Thanks,
Rohit

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Mon, 14 Feb 2005 17:57:38 +0100

> preferred option from our point of view.

I also think that 2 is the better option.
Is there however a need to make it a negotiation?
Would it not be enough to only provide the capability for the compressor to signal a value for p explicitly to the decompressor, within IR and IR-DYN packets?
 
> 3095bis as of today? Also, will it be quicker going with one 

I would favor 2) as the best way to do things. I would be very reluctant to make minor updates to current profiles and give them new profile numbers only to support this, while we are already aware of a significant number of additional things that "should" also be done for 3095bis. But as you can guess, 2) is likely to take more time than 1) but it also depends on the level of involvement to actually do this work. So far, 2) hasn't really progressed much unfortunately.
 
/Ghyslain

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 15 Feb 2005 10:11:35 +0100

> We are interested in single link header compression.

Ok, excellent! Can you say something more about the actual link(s) you
are considering, what link-layer protocols that can be expected, etc?

> preferred option from our point of view.

I am not sure I would call it a negotiation when doing 2), it would
just be one of the control values explicitly communicated from the
compressor to the decompressor. 

Anyway, the most important question right now is not the technical
details, but the overall approach. 

> Either of the above two options works for us. btw, what is 
> the status of 3095bis as of today? Also, will it be quicker
> going with one alternative as opposed to the other?

The status of 3095bis is unfortunately that it has not started to
happen yet. We have lately been resolving important interoperability
issues, but right now we have no such issues open. Another reason
why the bis work has not yet happen is the slow progress with the
TCP profile work in ROHC. Only a small group of people do all the
ROHC work so we have had to let people focus on one thing at a time.

> If you could give us some idea about that, it would help us 
> give a more precise answer on this issue.

That is a hard question to answer. When there is pressure to get
things done within a given time frame, it is usually easier to 
actually get there. 

If we do not identify any more critical technical issues with 3095,
it should not be too tricky to make bis happen. Considering that we
got 3095 written almost from scratch in about 6 months, it seems
reasonable to assume bis could be done within a similar timeframe,
when it really get started.

/L-E

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 15 Feb 2005 14:15:29 -0800

Lars-Erik,

Please find my comments embedded.

> Sent: Tuesday, February 15, 2005 1:12 AM
> To: Kapoor, Rohit; [email-masked]
> Cc: Kretz, Magnus D.; [email-masked]

We are considering RoHC for EVDO RevA VoIP systems.

> details, but the overall approach.

I agree. Anyway, I was just using "negotiation" rather loosely; my
intent was really "communication of the p value from comp to decomp".

> when it really get started.

The timeline of approximately 6 months (or so depending upon when bis
work starts) mostly suits us. It would be great, of course, if bis work
could start sooner than later. Also, the next RoHC WG meeting is next
month, right? Any chance bis could get kick-started at this meeting?

One more thing, in the context of reordering and IP-ID = constant
support, would you require any input from us? We would happy to
contribute/help in these areas. 

Thanks,
Rohit

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 16 Feb 2005 08:48:13 +0100

Rohit,

> work starts) mostly suits us. It would be great, of course, 
> if bis work could start sooner than later. Also, the next RoHC WG
> meeting is next month, right? Any chance bis could get kick-started
> at this meeting?

The ROHC WG is not meeting at the Minneapolis IETF, as we did not see
any actual reason to meet, considering the work currently going on in
the WG do not really require face2face bandwidth at this point in time.
Next time ROHC can potentially meet face2face is thus in Paris this
summer, but as you may be aware, IETF WGs do not need face2face meetings
to initiate new work, our mail list is our meeting room, always open for
contributions. 
 
> contribute/help in these areas. 

That would be very much appreciated!

/L-E

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 16 Feb 2005 17:33:00 -0800

Lars-Erik,

> Sent: Tuesday, February 15, 2005 11:48 PM

We will start working on this document and provide a draft to you guys
as soon as possible. To make things easier, do you have any specific
template that the draft should follow?

Please keep me informed if any work starts on 3095bis.

Thanks,
Rohit

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 17 Feb 2005 08:17:03 +0100

> template that the draft should follow?

Please see: http://www.ietf.org/ietf/1id-guidelines.txt

Looking at lately published Internet-Drafts can also be helpful.

/L-E

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Thu, 17 Feb 2005 09:45:56 -0800

Lars-Erik,

One quick question: since 3095bis will define new profiles anyway,
should we just write a document which can later be merged into bis? Or
should we write these changes (for reordering and IP-ID) as a standalone
profile?

Thanks,
Rohit

> Sent: Wednesday, February 16, 2005 11:17 PM

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Thu, 17 Feb 2005 16:50:00 -0800

Lars-Erik,

Another quick question: so if I understand right, the work being done in
bis will define new profile numbers, right? This can have implications
on how our draft is written, so I'm asking.

Thanks,
Rohit

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 18 Feb 2005 08:09:32 +0100

Rohit,

I would suggest that you write a problem and requirements input document, i.e. do not go inte too much details of a potential solution at this point. We need a problem statement in some form to be able to discuss whether the WG should request a charter update to address new work.

First when we have that, we can really start working on this in the WG, and that is when we should start looking at technical solutions. 

To answer your other question, 3095bis will most probably define new profile numbers, but that is something we will see by the end of the bis process.

BR
/L-E

> From: Kapoor, Rohit [mailto:[email-masked]]
> Sent: den 17 februari 2005 18:46
> To: Lars-Erik Jonsson (LU/EAB); [email-masked]