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

[Julije Ozegovic <[e-mail]>]

Hi Mark,

nice to hear from you ;)

As you can realize, the difference in our approaches is because 
you are doing top-down, while myself I am concerned with 
bottom-up design. This is why we give the same problem different 
flavors.

I can agree with all your writing, but also I have a strong 
feeling that the point is missed. What is of concern follows:

1. ALL fields are sent to the network in NBO
2. Only IP_ID can have ARBITRARY value
3. Only "some" hosts (not to mention which ones)
    reverse byte order for IP_ID

==> therefore, there is no possibility
     for NBO confusion except for IP_ID

4. IP_ID is sometimes generated randomly,
    and sometimes just incremented
5. Subsequent IP_ID numbers are assigned to packets
    which can belong to different data flows

==> We can expect IP_ID to be periodic to some extent,
     depending on the number of data flows
     and their respective rates at the sender

6. LSB coding is therefore optimal for IP_ID,
    RTP profile with INFERRED-OFFSET is possibly
    a misuse, however it is official.
    What I have proposed can be modified to

    IP_ID = LSB(70%,x,y) | SWAP-LSB(20%,x,y) | IRREGULAR(10%)

7. NBO() is ambiguous, the question is:
    how application can recognize swapped field?
8. of course, it is possible
    - to compare new value with the old one from the context
    - decide whether LSB coding is appropriate
    - if not, swap bytes
    - test LSB on swapped value
    - if not, it should be random
    - set NBO flag
    - communicate NBO flag through IR/DYN
    - send subsequent packets with swapped LSB
9. What if IP_ID is random?
    there is a possibility that LSB or NBO-LSB
    succeed on random IP_ID alternatively;
    in worst case random IP_ID will cause
    sequence of IR/DYN packets!

==> SWAP-LSB approach is optimal
     - it uses basic ID_bits mechanism,
     - it does not need separate NBO indicators

NBO-flag:

from proposed profile, as far as I can see, NBO-flag is passed 
as IRREGULAR through IR/DYN, and just tested STATIC in CO; 
therefore it has the same mechanism and importance of the format 
selector itself.

Now about format:

I did not propose SWAP-LSB to be used inside FORMAT, just said 
that it CAN be used, and that it is more format-friendly.

Format is mentioned because its main purpose is to generate 
separate format sets for differently behaving TCP/IP flows, and 
IP_ID behavior is an example of that. Why separate formats to 
sets? Just to make sure that some important formats of one type 
of flows will not be discarded because of low overall 
probability. That's why we can expect NBO/SWAP-LSB inside FORMAT.

What is of concern here, NBO inside FORMAT is double indication 
(format selector + NBO selector). It seem to be too complex for 
me, somehow makes me nervous (from the application point of view).

Finally, about IRREGULAR-PADDED, VALUE and SCALE:

I agreee that they are NBO sensitive, but whether that results 
with any practical consequence?

Best regards,
Julije



West, Mark (ITN) wrote:

> 
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc