Re: [rohc] TCP/IP EPIC profile

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

Hi Qian,

Qian Zhang wrote:

> Mark,
>  
> I do agree that there are different meaning and different application 
> scenarios for 'A_and_B' and FORMAT encoding methods.
> 
> (Actually we need to add an encoding method to efficiently represent the 
> 'A_and_B' case).
> 


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?

 
> 
> However, it is arguable whether we need to adopt the 'A_and_B' method or 
> the FORMAT method to compress the seqno and ackno in TCP flow.
> 
> I roughly list the pro-con by using FORMAT method:
> 
> Pro:
> 
> In some cases, the compression efficiency can be increased since less 
> encoding methods need to be supported in seqno_and_ackno.


Also, you can have different groups of encodings, tailored to particular 
types of flow behaviour.


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


> ·           Before the decision had been made, should we use a default 
> format that can support all the three types of traffic as the encoding 
> methods?
> 


It's up to the compressor.  Provided the compressor and decompressor 
agree (which they will, since the compressor signals this to the 
decompressor!), it doesn't matter.


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


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


> o        If we do make this assumption, then that may be un-efficient to 
> handle some cases. For example, during a web connection, the user can 
> upload a bulk data to the server during the first part of delivery, and 
> then switch to download a bulk data from the server during the rest part 
> of delivery.
> 


We *must* have transparency.  This method also allows for the encoding 
to be efficient.  However, the degree of efficiency may depend upon the 
implementation at the compressor.


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


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)

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

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)