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

["West, Mark (ITN)" <[e-mail]>]

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.


-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone [phone]   Fax  [phone]

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)