RE: [rohc] TCP/IP EPIC profile

["Hongbin Liao (Intl Staffing)" <[e-mail]>]

Hi, Mark
	See my comments inline.

Yours truly
Hongbin Liao
03/18/2002


> -----Original Message-----
> From: West, Mark (ITN) [mailto:[e-mail]]
> Sent: Friday, March 15, 2002 10:59 PM
> To: Qian Zhang
> Cc: Hongbin Liao (Intl Staffing); rohc
> Subject: Re: [rohc] TCP/IP EPIC profile
> 
> 
> 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.
> 

[Hongbin Liao] 
I guess your method may look very like conditional probability. Suppose
there are two fields A and B, A has 3 encodes, a1, a2, a3 and B also has
3 encodes, b1, b2, b3. A and B are not independent. In theory, to give
the correct behavior of A and B, you have to list all possible
combinations of A and B, totally 9 cases. In EPIC-LITE, this may be
expressed as follows:

AB = A1B(N1%) | A2B(N2%) | A3B(N3%)		; N1+N2+N3 = 100

; give the conditional probabilities of b1, b2, b3 under a1
A1B = a1(100%)
	A1Bx
A1Bx = b1(N11%) | b2(N12%) | b3(N13%)	; N11+N12+N13 = 100

; give the conditional probabilities of b1, b2, b3 under a2
A2B = a2(100%)
	A2Bx
A2Bx = b1(N21%) | b2(N22%) | b3(N23%)	; N21+N22+N23 = 100

; give the conditional probabilities of b1, b2, b3 under a3
A3B = a3(100%)
	A3Bx
A3Bx = b1(N31%) | b2(N32%) |  b3(N33%)	; N31+N32+N33 = 100

If there are more encoding methods for a field or more fields, there
will be a very complex, at least not human-readable, profile. Also,
there are (lots of) cases ignorable. However, profile writer have to
write all of them out.

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

[Hongbin Liao] 
If I don't misunderstand, a profile using FORMAT encoding method will
have two decisions to be made. One is to determine which Huffman prefix
to be used for a packet; another is to determine which FORMAT to be used
with the flow. They are not the same one, to determine which FORMAT the
flow is, you can not check only one packet to make the decision, you
have to check several packets to do that. However, when using A_and_B,
the compressor only need check which Huffman prefix to be used. There is
no extra introduced by FORMAT encode.

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

[Hongbin Liao] 
If so, the compressor have to continually check which FORMAT should be
used to the flow and use several IR/IR-DYN packets to make sure the
decompressor keep consistent with it. For robustness, it's not an
efficient way.

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

[Hongbin Liao] 
However, if you don't assume the format never changes during a TCP
session (above in your replies), it's really an issue. FORMAT is used
extensively in EPIC-LITE TCP/IP profile for several fields; it's really
an issue for robustness.

> 
> 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
> 
[Hongbin Liao] 
If you use Huffman code, 1 more decision don't always add 1-bit overhead
in average. Even there is extra 1-bit in average, it doesn't mean the
frequent case uses more Huffman prefix. So, 'seq-and-ack' and FORMAT are
only debatable for flow with continue changing traffic patterns.
However, FORMAT have to use several IR/IR-DYN packets to synchronize
decompressors. For robustness, again, FORMAT is not an efficient encode.

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

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