Subject: [rohc] EPIC-lite (and related) open issues...

From: "West, Mark (ITN)" <[email-masked]>
Date: Tue, 19 Mar 2002 18:07:52 +0000

Hi ROHCers,

A bit of a mixed bag, here, but that should come as no great surprise!

- RTP profile for EPIC(-lite)
The whole thing is a bit of an open-issue, really!  However, there are a 
few aspects of the profile that are probably worth contrasting with RFC 
3095...

- EPIC-lite issues
Many of these stem directly from discussions with Qian, Hongbin and 
Julije on the LIST.  Some of them have been resolved (more or less) and 
others are less clear.
* interaction between EPIC-lite and other header compression components
   (includes support for context replication?)
* use of FORMAT encoding (why would you use it and where?  And how?)
* use/efficiency of LIST encoding (partly a TCP-profile issue and partly 
a question about the encoding efficiency)
* use of additional encodings (why would we add them, and how...)
* profile complexity (the complexity / efficiency trade-off)

- TCP requirements and field behaviour
Well, I hope that the requirements are stable!  I don't think that 
there's anything particular to pick-up on there.
I'm not aware of any new questions raised by the behaviour draft 
post-Salt Lake City.  I think that the points raised here are largely 
common with others:
* robustness (what does this mean and how to specify it)
* short-lived connections (crosses-over with Qian's point)
* implicit acknowledgements (how useful are they?)
* use of a master sequence number (again, picked up by Qian)
* re-ordering channels (from the requirements)
(The latter is perhaps the most interesting issue that we haven't really 
gone into yet)

- SCTP profile
Again, it is an open issue simply by its very existence!  So, it's 
really just worth running down the basic philosophy behind it and what 
we're trying to do with it...

See you later..!?

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)