RE: [rohc] Reordering Support in RoHC

["Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson at ericsson.com>]

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


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

/L-E

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