[rohc] NBO- TCP/IP EPIC profile

[Julije Ozegovic <[e-mail]>]

Hi Mark,

let's go on one question at the time, it became hard do read 
everything in one single mail :)


>>
>> ** NBO:
>>
>> can we introduce something like SWAP-LSB in the toolbox and let normal 
>> method choice take place, e.g.:
>>
>>    IP_ID = LSB(80%,x,y) | SWAP-LSB(20%,x,y)
> 
> 
> 
> Are you saying that you would like to have a 'SWAP-' version of *every* 
> method in the toolbox?  Isn't this adding just a little more complexity 
> than a simple, in-place transformation?  The whole point is that the 
> byte-swappedness of a field is orthogonal to the encoding method. That's 
> why it got split from the INFERRED-SCALED method in the first place.
> 
> In fact, your example perfectly illustrates that orthogonality.  It is 
> clear that the IP ID is going to use LSB encoding.  However, you are 
> saying that (a priori) you know that 20% of the IP ID values will be 
> byte swapped and 80% will be in NBO.  My crystal-ball gazing just isn't 
> that good at predicting what's going to appear as input ;-)
> 
> Contrast this with our current suggestion:
>     foo = byte-swap
>           encode-foo
>               encode-swap-flag
> 
>     byte-swap = NBO(16)
>     encode-foo = LSB(...)
>     encode-swap-flag = STATIC(99%) | IRREGULAR(1,1%)
> 
> What I am saying here is that the field is put into NBO.  Then I encode 
> the (NBO'd) field with LSB (or whatever).  Then I encode the swap-flag. 
>  Now, what I saying here is that the probability that the byte-swap 
> state *changes* is 1%.  This is very different from saying that the 
> probability of byte-swapping *is* 1%, for example.
> 
> I can be confident that the byte-swap state won't change frequently.  I 
> have no idea what the ratio of byte-swapped to non-byte-swapped values 
> will be...


ok, BUT!

please, tell me about any other METHOD that is byte-order 
sensitive, except LSB. Remember "msb" function mentioned in 
EPIC-lite draft, which does almost the same thing.

Besides, it seem that all fields of the TCP/IP header are sent 
to the network with EXACTLY SPECIFIED byte order, NBO anyway. 
The only exception is IP_ID, which "some" hosts send in reversed 
order. Than, if NBO for all fields except IP_ID MUST be 
followed, it means that internal byte order is implementation 
specific, and is NOT needed to be concerned with profile.

Moreover, it seem to me that it is unnecessarily complicated to 
use NBO() inside the FORMAT, SWAP-LSB is much more 
"format-friendly". That means that structure like:

     IP_ID = FORMAT(LSB(100%,x,y));(SWAP-LSB(100%,x,y))

can be more effective than NBO approach. This is the essence of 
FORMAT usage: to split processing of differently behaving TCP flows.

Conclusion is: NBO is effective for LSB coding only, and can 
optimally be processed with SWAP-LSB (ok, in my opinion :)

best regards,

Julije, Maja and Tijana


_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc