RE: [rohc] TCP/IP EPIC profile

["Qian Zhang" <[e-mail]>]

Hi Mark,

More comments inline ...

Regards,

Qian

> 
> Sorry, I don't understand this point.  The example I quoted in
previous
> e-mails is a useable representation of this case.  Can you give me an
> example to explain the need for another encoding method?
> 
Maybe I have not expressed myself clearly enough. Actually we can try to
use the current encoding method to represent the 'A_and_B' method.
However, the representation may become quite complex when we need to
consider the case that each field may have several encoding methods
(such as seqno and ackno). I will come to this point later.

> >
> > Con:
> >
> > a. The compressor needs to distinguish whether bulk-data, bulk-ack,
or
> > interactive format should be used for a certain flow.
> >
> > *           How to make this decision and the cost for making this
> > decision should be considered.
> >
> 
> 
> One of the points that I have being trying to stress is that this is
> always an issue for the compressor, for any decision.


Although we can assume that this can be an issue for the compressor,
however, if the compressor at least needs to send more IR (IR-DYN)
packets by using this method, then we need to be very careful.

> 
> > *           Can we make an assumption that the format will never
change
> > during a TCP flow?
> >
> 
> 
> We don't make that assumption.  We assume that it is very unlikely to
> change during a flow.

Agree.

> 
> 
> > o        If not, then we need to make the decision and change the
format
> > during the whole delivery process. Then the performance will be
> > decreased due to the issue discussed in Con.b.
> >
> 
> 
> But if you use the 'A_and_B' style notation, you are making this
> decision for *every* packet.  (I'll return to this point, later)
> 
This decision is just as ordinary prefix selection for each packet.
However, for FORMAT decision, there need be another cost to decide which
FORMAT should be adopted besides which prefix should use. 

> >
> > b. Sine the format selector should be put in IR-DYN packet, then the
> > compressor need to get sufficient confidence that the decompressor
had
> > successfully received this IR-DYN before it select a certain format.
> > Considering the robustness requirement, then several IR-DYN packets
need
> > to be delivered, which will decrease the compression performance.
This
> > will significantly decrease the performance of the short-lived
transfers.
> >
> 
> This is only an issue if the FORMAT changes, though.
> 

If I understand correctly, the compressor may work in the following way:
(please point out if I had made mistake)
Consider for short-lived transfers, to make the first decision about
which FORMAT should be adopted, the compressor should at least process
two data packets to get the traffic pattern (e.g., seqno changes and
ackno does not change). After that, it will add the FORMAT selector
information in the IR-DYN packet, and to make sure that this information
had been successfully delivered, several IR-DYN packets need to be
delivered. If that is the case, then the performance for short-lived
traffic will significantly decrease.


> 
> Let me try and pick up some of these points.  I'll go back to the
> slightly simplified example that I've used before for the TCP case:
> assume that we are only concerned with a choice between 'bulk-data'
and
> 'bulk-ack' flow.
> 
> If I understand you correctly, you are suggesting that I use:
> 
>    seq-and-ack = bulk-data(50%) | bulk-ack(50%)
> 
> 
>     bulk-data = bulk-data-seqno
>                 bulk-data-ackno
> 
>     bulk-ack  = bulk-ack-seqno
>                 bulk-ack-ackno
> 
> 
> (where the encodings bulk-xxx-seqno/ackno are the familiar lists of
LSB
> encodings)
> 

Considering that each field in EPIC-LITE is encoded independently, the
dependence between seqno and ackno still hard to represent in
bulk-xxx-seqno/ackno. Maybe we need to represent the seqno and ackno as
follows:

Seqno_and_ackno = seq_ack_1 (20%) | seq_ack_2 (15%) | ... ...  

seq_ack_1 = seq_1
            ack_1

seq_1 = LSB (14, 0, 100%)
    
ack_1 = STATIC (80%) | LSB (10, 0, 15%) | LSB (16, 0, 5%)

seq_ack_2 = seq_2
            ack_2

seq_2 = LSB (16, 32768, 100%)
    
ack_2 = STATIC (80%) | LSB (10, 0, 10%) | LSB (16, 0, 10%)

... ... 

The profile writer needs to list maybe more than 10 seq_ack_? to
represent the dependency clearly enough. That may be quite complicate to
the profile writer which I mentioned at the beginning.

> I have the following observations regarding this example:
> 
> 
> - how do you know what probabilities to put on the encoding choice in
> the 'seq-and-ack' method?
> 
> - it is likely that both branches will actually be capable of encoding
> an arbitrary packet in a flow, although one will be a 'better' match
> than the other.  This means:
>     * you are making a decision about the encoding for every packet
>     * efficiency is directly affected by how well you make that choice
>       (i.e., exactly the same as for FORMAT)
> 
> - the decision on the 'seq-and-ack' method needs to be encoded so, in
> this case, you are sending a 1-bit indicator in *every* packet to pick
> the encoding type

In this case, there is no need to add this 1-bit indicator. The packet
format selection can be determined by prefix generate by EPIC-LITE.



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