RE: [rohc] Reordering Support in RoHC

["Kapoor, Rohit" <rkapoor at qualcomm.com>]

Lars-Erik,

Please find my comments embedded.


> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB)
[mailto:lars-erik.jonsson at ericsson.com]
> Sent: Tuesday, February 15, 2005 1:12 AM
> To: Kapoor, Rohit; rohc at ietf.org
> Cc: Kretz, Magnus D.; cabo at tzi.org
> Subject: RE: [rohc] Reordering Support in RoHC
> 
> > > >  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.
> 
> Ok, excellent! Can you say something more about the actual link(s) you
> are considering, what link-layer protocols that can be expected, etc?

We are considering RoHC for EVDO RevA VoIP systems.


> > 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.
> 
> 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.

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


> > 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.
> 
> 
> > 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.
> 
> 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.

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

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc