RE: [rohc] TCP/IP EPIC profile

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

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc