[rohc] Re: NBO- TCP/IP EPIC profile

Hi Mark,

concerning new EPIC-lite (01) draft is published, and it 
generally covers the TCP/IP profile published earlier, much of 
our discussion is obsolete.

About NBO issue, if it stays in (future) standard, it should be 
implemented for compatibility. "SWAP-LSB" approach needs much 
more effort and support to be adopted, and it doesn't seem to be 
possible at the moment.

However, the main idea of making the whole thing more simple 
must not be neglected. This concerns both "language developers" 
as well as "profile developers". Language is (almost) defined, 
and it should be complete. Now it is the responsibility of 
profile standardization process to find optimum between 
compression and computation efficiency.

Best regards,
Julije

West, Mark (ITN) wrote:

> 
> Hi Julije,
> 
> [much general agreement removed]
> 
>>
>>> - We cannot know in advance what proportion of packets will contain 
>>> byte-swapped values
>>
> 
>  >
> 
>> well, at least with same precision as all other probabilities in profile!
>>
> 
> 
> Hmmm.  Not quite!  If I took a single 'representative' flow and used it 
> to decide on the probabilities to assign to the various choices, I would 
> have to choose probabiliies of '0%' for all the swapped/non-swapped 
> versions (since this doesn't change within a flow).
> 
> Anyway, I don't think that we'll gain much more by discussing this issue 
> further.  And, if we really wanted to, we could settle it by comparing 
> implementations.  But I'd rather not...
> 
> 
>>> - The byte-swapping state will not change frequently
>>>   (and should only be sent when it changes)
>>
>>
>> it should not change for the flow, this is the strong point of the NBO 
>> approach!
>>
> 
> 
> Agreed!
> 
> 
>>
>>
>>> - SWAP-LSB lacks flexibility and forces the use of FORMAT, which is 
>>> undesirable
>>
> 
>>
>> it does not force the use of the format!
> 
> 
> 
> It doesn't force it, but it needs it for effiency.
> 
> 
>> NBO is "more flexible" when you need it, but that is also one more 
>> state for the context!
>>
> 
> 
> Agreed.  I don' think that the state is a high price to pay (ROHC has 
> it, for instance), but you are correct.
> 
> 
>>> - NBO is a flexible approach (equivalent to the NBO flag in RFC 3095, 
>>> but in a more generic way)
>>
>>
>> let it be part of the standard then, with syntax defined
>>
> 
> 
> Well, we haven't got a standard, yet ;-)
> 
> But, it's part of the current draft:
> 
> http://www.dmn.tzi.org/ietf/rohc/draft-ietf-rohc-epic-lite-01.txt
> 
> Enjoy..!
> 
> 
>>> If you want to change my mind, you will need to convince me of:
>>>
> 
> 
> [snip]
> 
>>
>> (it is, as you said, hidden NBO in ID_flags, but that is the function 
>> of ID_flags: to identify format)
>>
> 
> 
> Yes, this is true.  But if, as you agree, the NBO flag stays the same 
> for the whole flow, why encode it in every packet?
> 
> 
>>
>>> - How this approach can be extended to cover the other 4 methods that 
>>> are affected by byte ordering.
>>
>>
>> does it need to?
>>
> 
> 
> I think so.  But, as I said earlier, I'm biased!
> 
> 
>>> ok?
>>
>>
> 
>> OK ;-)
>>
> 
> 
> ok!
> 
> 
>> julije
>>
>> PS. anyway, we are going to do it NBO way, since it is in the standard 
>> (really, is it?)
> 
> 
> 
> *sigh*
> 
> If you're happy to do it this way, then I'm not entirely sure what we're 
> arguing about.  (Sorry - discussing!)
> 
> But I've enjoyed the debate..!
> 
> Cheers,
> 
> Mark.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> The information contained in this e-mail and any attachments is confidential to Roke 
> Manor Research Ltd and must not be passed to any third party without permission. This 
> communication is for information only and shall not create or change any contractual 
> relationship.
> 
> RMRL-Disclaimer.txt
> 
> Content-Type:
> 
> text/plain
> Content-Encoding:
> 
> 7bit
> 
> 

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