← Back to team overview

rohc team mailing list archive

Re: Ethernet Transport app for ROHC pkts

 

Hi Didier,

 Please share your thoughts on this with me, to take it further.

regards,
Raman

On Mon, Feb 11, 2013 at 1:19 PM, Raman Gupta <ramangupta16@xxxxxxxxx> wrote:

> Hi Didier,
>
> > That's one point, however the counterpart is that you have to twice
> more work to add the feature to the 2 programs...
> Yes, maintaining the two apps can be challenging. So you can merge the two
> into a single app.
>
> >Indeed, the programs provided with the ROHC library are small, simple
> >programs that help testing it. A larger, more complex program will
> >probably require dependencies on external libraries/programs at some
> >time in the future. Adding external dependencies to the library for one
> >of its program seems too cumbersome for the library itself.
>
> A common question that I have seen here is the need for a complete ROHC
> application which is way beyond simple testing apps. The application should
> be easy to use, configure and quick-to-go(live). That kind of application
> will find many takers and widespread use of ROHC library. I have listed a
> few basic features of such an application, but many more will be needed to
> make it production ready.
>
> So I agree with your opinion to have ROHC application code in a separate
> code base but based on this ROHC library. Do we need a separate repository
> for this, or can it be a sub-component of existing ROHC library. I don't
> have much idea about maintaining a separate code repository, releases,
> version numbers etc.
>
> regards,
> Raman
>
> On Thu, Feb 7, 2013 at 11:36 PM, Didier Barvaux <didier@xxxxxxxxxxx>wrote:
>
>> Hi Raman,
>>
>> > The Ethernet based transport application for ROHC pkts is very
>> > similar in concept and implementation to rohctunnel app, because I
>> > wanted to keep error simulations, stats collection and usage same.
>> > However it uses link layer Ethernet transport instead of IP/UDP. Aim
>> > was to provide similar and easy alternate to someone looking for a
>> > link layer transport to conserve more bandwidth by avoiding UDP/IP
>> > header overhead e.g. over point to point links without gateway/router
>> > in between.
>>
>> OK.
>>
>>
>> > Merging the two will complicate the code and confuse usage. Keeping
>> > them separate will help them evolve independently without fear of
>> > breaking the other.
>>
>> That's one point, however the counterpart is that you have to twice more
>> work to add the feature to the 2 programs...
>>
>>
>> > Examples of evolving the apps, that I am thinking are :-
>> >
>> > 1) ROHC multiplexing to combine multiple ROHC pkts in single
>> > transport pkt to conserve more bandwidth.
>> > 2) Keep Alive msgs between Compressor and Decompressor so as to clear
>> > the context or restart when other side restarts or crashes.
>> > 3) Service monitoring.
>>
>> Hmm, your idea are very interesting, however I think the ROHC library's
>> source code is not the best place for that. To my opinion, the program
>> that would result from the current ROHC tunnel and your ideas is a
>> project on its own.
>>
>> Indeed, the programs provided with the ROHC library are small, simple
>> programs that help testing it. A larger, more complex program will
>> probably require dependencies on external libraries/programs at some
>> time in the future. Adding external dependencies to the library for one
>> of its program seems too cumbersome for the library itself.
>>
>> What do you think about this?
>>
>> If you agree, we could host your code on Launchpad aside the repository
>> of the ROHC library.
>>
>> Regards,
>> Didier
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~rohc
>> Post to     : rohc@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~rohc
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>

Follow ups

References