RE: [rohc] TCP/IP EPIC profile

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

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.

>