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

Hi!

West, Mark (ITN) wrote:

> I'm going to try something dangerous and summarise:
> 
> - IP ID is one concrete example of a field that does not have a defined 
> representation and so, because of implementation issues, may have a 
> byte-swapping problem

ok

> - It is necessary to account for this in an EPIC profile

ok

> - The encodings used for the normal and byte-swapped representations are 
> (ignoring the byte-swapping) the same

ok

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

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

> - There are at least two candidate encodings (LSB and INFERRED-OFFSET)

ok

> - Any solution must look at the historical values of the field and 
> decide whether or not it is considered byte-swapped

ok

> Regarding the solutions (my opinion, of course ;-)

of course!

> - SWAP-LSB lacks flexibility and forces the use of FORMAT, which is 
> undesirable.

it does not force the use of the format!

NBO is "more flexible" when you need it, but that is also one 
more state for the context!

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

> If you want to change my mind, you will need to convince me of:
> 
> - How SWAP-LSB can be used *without* FORMAT and without reducing the 
> encoding efficiency

just using common OR functionality

> - How SWAP-LSB's decision on byte-swapping is different from (more 
> importantly, better than) the NBO approach

again, just using common OR functionality:
try one, than another, use first that succeeds

(it is, as you said, hidden NBO in ID_flags, but that is the 
function of ID_flags: to identify format)

> - How this approach can be extended to cover the other 4 methods that 
> are affected by byte ordering.

does it need to?

> ok?

OK ;-)

julije

PS. anyway, we are going to do it NBO way, since it is in the 
standard (really, is it?)

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