Subject: [rohc] TCP/IP EPIC profile

From: "Maja" <[email-masked]>
Date: Mon, 4 Mar 2002 17:33:29 +0100

Hi all,
some points in the latest TCP/IP Header Compression for ROHC (ROHC-TCP) 
draft from January are not clear (OK. Not clear to me ).

First is the definition of the U ( ) method called for TCP options, for example:
 
  tcp-options-co  =    ROTATE(3,1) ; get TCP data offset 
                        LIST(4,1,32,-160,8, 
                           U(OPTIONAL(tcp-sack-co)), 
                           U(OPTIONAL(tcp-timestamp-co)), 
                           U(OPTIONAL(tcp-mss)), 
                           U(OPTIONAL(tcp-end)), 
                           U(OPTIONAL(tcp-wscale)), 
                           U(OPTIONAL(sack-permitted)), 
                           U(OPTIONAL(tcp-generic-co)), 
                           U(OPTIONAL(tcp-generic-co)), 
                           5,8,2,0,3,4) 
 
We couldn't find it in none of the EPIC or ROHC drafts.
And the second point is why is it, in the method LIST, twice included tcp-generic-co ( OR for IR/DYN tcp-generic-dyn).
We suppose that is the method which is called if the value in 8 bits is none of 6 values stated at the end of method, but why twice?
 
Cheers,

Maja & Ivana

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 4 Mar 2002 17:26:54 -0000

Hi Maja,
 
Thanks for your email.  The U method is a new one which is defined in the latest version of the EPIC-LITE draft.  This can be found at http://www.dmn.tzi.org/ietf/rohc/draft-ietf-rohc-epic-lite-01.txt <http://www.dmn.tzi.org/ietf/rohc/draft-ietf-rohc-epic-lite-01.txt> .
 
You are correct tcp-generic-co is called that because it isn't defined by any of the 6 values so it can be any other tcp option.  Each item in LIST can only occur once so if there were to be 2 tcp options which weren't any of the specified 6 then 2 generic option items are needed.  A similar thing happens in the LIST for sack blocks.
 
I hope this answers your questions.
 
Regards,
 
Abbie

-----Original Message-----
From: Maja [mailto:[email-masked]]
Sent: 04 March 2002 16:33
To: rohc
Cc: Surtees, Abigail; West, Mark (ITN)
Subject: TCP/IP EPIC profile

Hi all,
some points in the latest TCP/IP Header Compression for ROHC (ROHC-TCP) <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
draft from January are not clear (OK. Not clear to me ).

 
 
Cheers,
 
Maja & Ivana

---

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Fri, 8 Mar 2002 09:44:24 +0800

> From: Hongbin Liao (Intl Staffing) [mailto:[email-masked]] 
> Sent: Friday, March 08, 2002 9:41 AM
> To: West, Mark (ITN)
> Cc: Qian Zhang; Julije Ozegovic; rohc
> Subject: RE: [rohc] TCP/IP EPIC profile
> 
> 
> Hi, Mark
> 
> 	Please see my comments.
> 
> Thanks
> 
> Hongbin L.
> 03/08/2002
> 
> 
> > From: West, Mark (ITN) [mailto:[email-masked]]
> > Sent: Thursday, March 07, 2002 6:27 AM
> > To: Hongbin Liao (Intl Staffing)
> > Cc: Qian Zhang; Julije Ozegovic; rohc
> > Subject: Re: [rohc] TCP/IP EPIC profile
> > 
> > 
> > 
> > Hi Hongbin,
> > 
> > Ok - when you choose the encodings, you need to build up some
> > indicator 
> > for the selected set of encodings.  These need to be mapped 
> > to a node in 
> > the Huffman tree (at the compressor).
> > 
> > In the ideal case, you'd be able to do the mapping in constant time
> > (that is a pair of tables, indexed on 'format identifier' and 
> > 'prefix'). 
> >   Naturally this would take too much memory, so is not really 
> > practical.
> > 
> > However, suitable constructs like hash-tables should be able
> > to do the 
> > mapping in very near to constant time.
> > 
> 
> It's not so clear to me. Suppose there is the same situation as
> previously described, there are 30 fields and each field has 
> 2 choices.
> If all prefixes must be stored at the compressor/decompressor, there
> will need at least 2*30 bytes (1GB!). Clearly, it's impractical.
                     ~~~~
		Sorry, it should be 2**30

> However, I am not clear how hash-tables can alleviate such a 
> situation.
> Would u give me some examples and time & space requirements for such a
> situation?
> 
> Moreover, if you restrict the formats generated from a profile to
> MAX_FORMAT. How to get the prefix (or flag) in such case? Would u give
> me more example? Also, the time & space requirements.
> 
> 
> > At the decompressor, you need to be able to go from a prefix 
> > to a tree 
> > node and, hence, to a format indicator (and set of encodings).  The 
> > decoding of the Huffman prefix is linear with respect to 
> the range of 
> > prefix lengths.  That is, if there are prefixes of 1 bit to 10 bits 
> > long, then it will take at most 10 comparisons to identify 
> the node. 
> > Also, in this case, the shorter prefixes are more likely, and more 
> > efficient.
> > 
> 
> Hi Julije, it seems that you are implementating EPIC-LITE, 
> would u give
> us something, the time & space requirements, for a profile? 
> It's really
> helpful for us to understand it well. Thanks.
> 
> 
> > With regard to the mappings, there is some degree of space/time 
> > trade-off.  However, there is no obvious area of inefficiency.
> > 
> > I can give more detail, if this would help?
> > 
> > Cheers,
> > 
> > Mark.
> > 
> > 
> > Hongbin Liao (Intl Staffing) wrote:
> > 
> >  > Hi, Mark
> >  > 	The overhead (time and space) of encoding a compressed packet
> >  > can be splitted into two parts. One part is encoding for 
> > each fields,  > and the other part is the overhead of 
> > selecting the indicator (or flag)  > to indicate the encoding 
> > methods of all fields. Clear, the overhead of  > the former 
> > should be linearly to the number of fields. However, how  > 
> > about the overhead of the later part or the overhead of 
> > determining  > which Huffman prefix (function 
> > 'get-indicator-flags' in ROHC-LITE)  > should be used in the 
> > compressed packet?  >  > Hongbin L.  > 03/06/2002  >  >  >  
> >  >>From: West, Mark (ITN) [mailto:[email-masked]]
> >  >>Sent: Wednesday, March 06, 2002 8:01 AM
> >  >>To: Qian Zhang
> >  >>Cc: Julije Ozegovic; rohc
> >  >>Subject: Re: [rohc] TCP/IP EPIC profile
> >  >>
> >  >>
> >  >>
> >  >>Hi Qian,
> >  >>
> >  >>Thanks for these comments, which raise some important and  
> > >>interesting issues.  I've added some comments of my own!  
> > >>  >>Cheers,  >>  >>Mark.  >>  >>  >> >  >> > [Julije] 
> > Detailed profiles tend to result in complex  
> > >>applications/protocols.  >> >  >> > [Mark] I'd have put 
> > that the other way around (complex  >>protocols =>  > 
> > detailed profiles), but I think I agree...  >  >> > [Julije] 
> > The purpose of this posting is to point out the  >>complexity 
> > of  > whole thing, regarding the fact that almost  >>every 
> > line of profile ends  > up with (at least) one data  
> > >>structure in end user application.  >  > [Mark] Yes, it is  
> > >>quite complex.  So is RFC 3095 ;-) I would agree that  > it 
> >  >>is more 'dense' than RFC 3095, for example, as most of the 
> >  >  >>information is packed into the profile.  >  > Certainly 
> > every  >>field (or meta-field) requires a data-structure.  
> > Again,  >  >>I'm not sure how this is different from any 
> > other header compression  >>scheme?  >> >  >> > [Qian] I 
> > agree that the complex protocol such as TCP/IP  >>will cause 
> > a  > detailed profile. What I would like to point  >>out is 
> > that the compressed  > format generation should be a  
> > >>tradeoff between the efficiency and the  > complexity.  >  
> > >  >>Mark, would you please comments on the complexity about  
> > >>generating a  > compressed format based on the input 
> > profile.  >>Suppose there are 30  > fields need to be 
> > considered, each  >>field may have two choices, how about  > 
> > the complexity for  >>determining the compressed format?  >>  
> > >>I assume that you are referring to the complexity in the  
> > >>compressor, rather than in the off-line processing to build 
> >  >>the Huffman prefixes (which is obviously not so 
> > time-critical)?  >>  >>Overall, I would suggest that the 
> > complexity of compression  >>(and this is a general statement 
> > about header compression) is  >>broadly linear with respect 
> > to the number of fields: double  >>the number of fields - 
> > double the complexity.  >>  >>Taking your more specific 
> > example, let's assume that we have  >>30 fields with 2 
> > choices.  (It's worth pointing out that this  >>is a slightly 
> >  >>unusual case in that a number of fields are likely to only 
> > have a  >>single, fixed encoding and others will have more 
> > than 2.  >>However, as an  >>example to discuss the issue it 
> > works just fine, of course)  >>  >>One of the important 
> > pieces of information that needs to be  >>factored in, 
> > though, is the relative likelihood of the  >>various choices. 
> >  I generally assume (though this may not  >>always be true) 
> > that encodings are tested in decreasing order  >>of 
> > probability.  After all, if one encoding is likely to be  
> > >>used 99% of the time, it's probably best to try that one 
> > first!  >>  >>Anyway, back to the example.  >>  >>In the best 
> > case, you will test 30 encodings (one per field)  >>to end up 
> > with the compressed packet.  >>  >>In the worst case, you 
> > will test 60 encodings (2 per field).  >>It is also likely in 
> > this case that you will have to send an  >>IR-DYN packet.  
> > With typical probability values, the least  >>likely format 
> > is really very, very unlikely (think 1%^30...)  >>  >>The 
> > average case depends upon the probability bias, but in  
> > >>general is going to be quite low.  (In this case, perhaps 
> > an  >>average of 1.1 encodings per field, or around 33 
> > overall?)  >>  >>Since it is clear that the number of fields 
> > is important, we mustn't  >>lose sight of the fact that in 
> > addition to the defined fields in a  >>protocol header, there 
> > are a bunch of additional meta-fields used for  
> > >>compression.  (For example, RTP TS scale factor, IP ID NBO  
> > >>flag, etc...)  >>  >>Something else to bear in mind is that 
> > some of the encodings  >>are more complex than others.  
> > VALUE, for example, is very  >>simple since there is no 
> > context history to worry about; only  >>a simple test between 
> > two values.  STATIC is simple, but is  >>still requires 
> > checking the context history.  >>  >>Anyway, this all leads 
> > me to suggest that the complexity is based on:
> >  >>- the  number of actual fields, plus the number of meta-fields
> >  >>- some factor to indicate the average search depth per field
> >  >>- a factor based on the depth of the context
> >  >>
> >  >>(I should point out that you can describe ROHC RTP in this 
> >  >>way and perform a similar analysis)  >>  >>For anyone who 
> > hasn't had a look, we have submitted an I-D  >>that contains 
> > an EPIC profile corresponding to (a subset of) ROHC RTP:  >>  
> > 
> >>http://search.ietf.org/internet-drafts/draft-surtees-rtp-epic-00.txt
> >  >>
> >  >>You may like to see how the description in the profile 
> > maps  >>onto the description of the field processing in RFC 
> > 3095.  >>(3095 is a little more verbose; the draft is 
> > somewhat terse,  >>but anyway...)  >>  >> >  >> > I would 
> > like to raise a discussion on the rough number of  
> > >>compressed  > formats that plan to support for TCP/IP  
> > >>compression. Considering the  > complex behaviors for 
> > TCP/IP  >>protocol itself, personally, I think we may  > need 
> > more  >>formats than RFC 3095. However, considering that the  
> > >  >>compression ratio is not the only target for TCP/IP 
> > header  >>compression,  > we also may not need to generate 
> > too much  >>kinds of format.  >  >>  >> > Can we come out a 
> > reasonable number of the max_formats for  >>the TCP/IP  > 
> > compressed header and provide a simpler profile  >>to 
> > describe the behavior  > of each field?  >  >>  >>This is an 
> > interesting question.  >>  >> From our perspective, if you 
> > build the compressed packet up  >>by processing on a 
> > field-by-field basis (as described in the  >>draft), then the 
> > number of formats is not a very important  >>issue.  (Rather, 
> > it is possible to support a very large  >>number of formats). 
> >  >>  >>RFC 3095 has very few basic packet formats.  However, 
> > once you start  >>factoring in the extensions and the 
> > variability in extension  >>3 (plus the  >>additional flags), 
> > there are actually quite a lot of formats.  >>  >>We should 
> > bear in mind that the compressed packets are  >>generated by 
> > an algorithmic process -- each packet does not  >>have a 
> > separate encoding  >>function.  >>The mapping between 
> > selected encodings and packet format (and vice
> >  >>versa) should be simple and equally quick for all formats. 
> >  >>The quantity of data required to describe a profile (and the
> >  >>formats) to a compressor/decompressor is minimal.
> >  >>
> >  >>(I'm at home at the moment, and don't have any numbers to  
> > >>hand, but I'll  >>send some figures when I'm next in the 
> > office)  >>  >>What is interesting to note is that the 
> > predicted benefit of  >>adding more formats decreases as the 
> > number of formats gets larger.  >>  >>It is, however, clearly 
> > an issue that we will have to decide  >>with regard to the 
> > TCP profile.  I think that this requires  >>us to start 
> > getting an idea of the probabilities that should  >>be 
> > assigned to encodings.  This lets us have some indication  
> > >>of the effect of adding (or removing) formats.  >>  >>
> >  >>--
> >  >>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)  >>  >>  >>  >
> > 
> > 
> > -- 
> > 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)
> > 
> > 
> > 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Fri, 8 Mar 2002 16:00:39 +0100

Hi again,

> In ROHC-TCP, EPIC-Lite can be viewed as a tool to generate the
> compressed header format. It is independent with the state machine
> of ROHC-TCP. 

This is how we have envisioned how EPIC-Lite would be used in ROHC,
not only for the TCP profile, but for any future profile build in
this way. What we should start thinking of is an appropriate name
for this "generic compressed format generator" for use in ROHC
profile standardization. Both current and future work would benefit
from getting a good name for this "tool" ASAP.

> The state machine part will take care of the context updating, 
> compressor/decompressor states and modes management. The
> interaction between state machine and compressed format generation
> is that the estimated congestion window or link feedback obtained
> by state machine is the control parameter for format generating.

To use congestion window estimation as a basis for sending an
appropriate number of bits for some compressed fields is just
one possible implementation strategy (as we discussed and agreed
in SLC). This is thus not a normative functionality that should 
affect the protocol specification.

> I would like to raise a discussion on the rough number of 
> compressed formats that plan to support for TCP/IP compression. 

Since this is a parameter that can easily be adjusted during our
prototyping work, this is probably the last thing we have to set
before we submit a new profile specification. Of course, it is fine
to start looking at this already at this stage, but I think there
are still other more urgent issues to solve.

Rgds,
/L-E

---

From: "Qian Zhang" <[email-masked]>
Date: Thu, 14 Mar 2002 18:16:26 +0800

Hi Per,
 
Please see my comments inline...
 
Regards,
Qian

-----Original Message-----
From: Per Synnergren (EPL) [mailto:[email-masked]] 
Sent: Thursday, March 14, 2002 3:38 PM
To: [email-masked]'
Subject: RE: [rohc] TCP/IP EPIC profile

Hi all, 

A question "out of the blue"...

Hongbin Liao wrote:

	1. whether can TCP/IP EPIC profile correctly describe the
behavior of TCP? Or, whether EPIC is powerful enough to describe the
complicated behavior of TCP/IP?
	
	    In EPIC, fields are assumed to be independent from each
other. Once each field's behaviors are described well, the whole
protocol's behaviors are also well-studied. However, in practice, fields
in a protocol may not behave independently completely from each other.
There may be some connections (or causality) among several fields. For
example, most TCP traffics only contain one-way traffic (WWW browsing,
FTP downloading, etc.), i.e., only SEQ changes on the forward path (from
server to client) and only ACK changes on the backward path (from client
to server). The ACK on the forward path and SEQ on the backward path
remain constant. However, in TCP/IP EPIC profile, the probabilities for
SEQ and ACK are specified seperately:

	It is obvious that knowledge about "TCP inter-field correlation"
could be useful in order to increase the performance of the header
compression. 

	[Qian] Since there exist the "inter-field correlation" in TCP
protocol (actually in other protocols, such as SCTP and RTP, there also
such correlation), we need to represent those correlations accurately
for compression efficiency.

	Has anyone heard of/or performed thorough studies of the
cross-correlation between TCP-fields?  

	[Qian]  Interesting! As we discussed before in the mailing list,
there are several TCP options that will only occur in SYN packet. Of
course, that is an example for cross-correlation. For example, as
defined in [RFC2018], the Sack-Permitted Option "may be sent in a SYN by
a TCP that has been extended to receive (and presumably process) the
SACK option once the connection has opened. It MUST NOT be sent on
non-SYN segments.". 
	 
	As Mark mentioned in his email, more detail analysis about TCP
behavior can be found in
http://search.ietf.org/internet-drafts/draft-west-tcpip-field-behavior-0
1.txt
<http://search.ietf.org/internet-drafts/draft-west-tcpip-field-behavior-
01.txt>  and ROHC-TCP draft. We are refining this now, any comments are
welcome.

---

From: "Qian Zhang" <[email-masked]>
Date: Mon, 18 Mar 2002 12:14:12 +0800

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.

---

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Mon, 18 Mar 2002 23:12:01 +0800

Hi, Mark
	See my comments inline.

Yours truly
Hongbin Liao
03/18/2002

> Sent: Friday, March 15, 2002 10:59 PM
> To: Qian Zhang
> Cc: Hongbin Liao (Intl Staffing); rohc
> 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).
previous
> > 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.

or
> 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.
> 
> 
change
> We don't make that assumption.  We assume that it is very unlikely to

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

format
> > 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.
> 
> 
> >
> >
had
need
This
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.

and
LSB
> this case, you are sending a 1-bit indicator in *every* packet to pick
[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.

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