Subject: RE: [rohc] TCP/IP EPIC profile

From: "Qian Zhang" <[email-masked]>
Date: Fri, 15 Mar 2002 17:04:53 +0800

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

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. 

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. 

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

*           Can we make an assumption that the format will never change
during a TCP 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.

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. 

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.

Regards,

Qian

> [Mark wrote:]

> No, the above approach cannot usefully encode the flow behaviour in
this

> way.

> There are different types of correlation, where the probability

> distribution is:

> - random, but known

> - stable, but unknown

> Something like the 'marker bit + timestamp' of the RTP profile fall
into

> the former category -- you can think about putting a rough probability

> on the marker bit being set.

> This is notated as the 'A_and_B' example above.

> However, the TCP flow behaviour is a higher level dependency which

> should remain stable for the duration of the flow (or for significant

> proportions of the flow).

> This uses the FORMAT construction.

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Fri, 15 Mar 2002 14:59:02 +0000

Hi Qian,

> (Actually we need to add an encoding method to efficiently represent the 

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?

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

> ·           How to make this decision and the cost for making this 

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 

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.

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

> then switch to download a bulk data from the server during the rest part 

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.

> 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 +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)