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

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

Hi Julije,

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


Probably a good idea!

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


[my last rant removed...]


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


Well, anything that does not just treat the field as an opaque bunch of 
bits (like IRREGULAR and STATIC) may be sensitive.  I'll give you  some 
specific examples towards the end of my response...

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

Right!  Any field for which the representation matters has a specified 
representation 'on the wire', which is NBO.  The IP ID is a slightly 
bizarre case, in that it is just a descriminator between packets.  It 
just happens that the easiest/most common way of implementing this is 
with a counter and we (try to) exploit that in header compression.

Having said that, just because it's rare doesn't mean that it won't 
occur in other protocols (or protocol implementations).

So, we accept (I think) that there may be some (very few) fields that 
are treated as 'numeric' and which may not have a well-defined 
byte-order.  Given  this, there has to be some way of handling it. 
Since EPIC is fundamentally trying to be protocol independent, it seems 
unwise to make this an IP ID *specific* feature.

Also, I don't follow why you claim that this is not a profile concern - 
  I tried to interpret this in the sense of, "we shouldn't concern 
ourselves with implementation dependencies like byte-swapping."
But 3095 does it and you're suggesting SWAP-LSB, rather than ignoring 
it.  So, I don't get it.  Sorry...

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


The essence of FORMAT is to allow different sets of encoding methods to
be applied, specifically where the format of the compressed packets 
changes.
However, looking at IP ID, if it behaves sequentially, then regardless
of the byte-order the same set of 'formats' will be used.  (That is, the
same number of bits will be used for LSB with the same interpretation 
interval).  So it's not really changing the format, is it?

Also, harking back to another point that you made previously, 
introducing 'FORMAT' here doubles the number of format sets (and 
consequently the total number of formats).

FORMAT also requires the use of IR-DYN packets, whereas NBO need not.
(Granted, it's very likely due to the low probability of a change, but
that's up to the packet generation)

If the use of FORMAT was able to avoid introducing a new method, then I
might concede the point.  However, since we have to add something 
(either NBO or SWAP-LSB or whatever), I don't see that making use of
FORMAT is necessary.

NBO is 'lighter weight' and more specific than FORMAT.  In this case, I
happen to think that this is good.


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


This is actually not true (in my opinion ;-)
NBO is effective for any encoding that makes use of arithmetic 
operations.  If you were to look at an RTP profile, for example, you 
will see that the IP ID is encoded relative to the master sequence 
number.  This is done through the INFERRED-OFFSET command (which is 
effectively a subtraction).  Clearly the base and the value to be 
encoded need to be in the same byte-order.  Thus, LSB is not the only 
method that benefits from NBO and, so, I stand by our claim that NBO is 
the most suitable solution...

(In passing, IRREGULAR-PADDED, VALUE and SCALE could also be argued to 
be byte-order dependent)


 > best regards,
 >
 > Julije, Maja and Tijana


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)