[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] Updating the Formal Notation draft
Hi,
Thanks for all of these comments - hopefully I managed
to take them into account in the updated version of the
notation draft. I've added a few clarifications inline,
particularly regarding the scope of ROHC-FN (where more
discussion is clearly required).
Regards,
Richard
> -----Original Message-----
> From: Lars-Erik Jonsson (EAB)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: Friday, February 28, 2003 3:14 PM
> To: 'rohc@ietf.org'
> Subject: RE: [rohc] Updating the Formal Notation draft
>
>
> Richard,
>
> In general, I think we should not make any changes to the
> actual notation at this point (although the draft might be
> updated for other reasons), as we do not have a common view
> either of how to proceed with this, or for example if we
> should do this "Haskell"-step, or something similar using
> another functional language. We need to discuss this more,
> then we can get a stable ground for the content before we
> do the changes.
Absolutely - there's no need to update the syntax of the
notation at this stage. It's more important to clarify the
scope of the notation draft, and to make sure that we
understand how it fits into the overall ROHC solution.
> However, we might want to update it just to change the title,
> and maybe some of the "environmental texts". I've provided
> some comments on this below.
>
> BR
> /L-E
>
>
> > Section 4.6 on "control fields" is redundant given the
> > information contained in <draft-ietf-rohc-tcp-03.txt>.
>
> Well, it might be worth mentioning that information that
> can be noted is either original header fields, or additional
> control fields introduced by the compression scheme.
Ok, I mentioned this briefly in the updated draft.
> > I propose to leave the ROHC-TCP draft as it is and delete
> > Section 4.6 from the formal notation.
>
> Of course, the TCP control field can not be discussed as
> part of the general notation.
Good point - Section 4.6 talks about specific control fields
such as the "Master Sequence Number", which is used exclusively
by ROHC-TCP. So it's definitely out of scope of the formal
notation draft.
> > Conversely, one issue that the current draft doesn't explain
> > very well is the scope of the formal notation - what it does,
> > what it doesn't do, how it relates to the ROHC framework and
> > to ROHC profiles etc.
>
> This is indeed very important, and should be done before we
> go much further. However, I do not think we do have a common
> understanding about that, as it has never been settled.
I think that the first step is to explain the scope of the
current notation draft. Once we've clarified this, we can
decide whether the scope is correct, or whether it's too broad,
too narrow etc.
> > I'd like to add a new section to clarify this issue:
> >
> > 3.X. Scope of ROHC-FN
> >
> > The following section describes the scope of ROHC-FN, and
> > explains how it relates to the overall ROHC framework and to
> > specific ROHC profiles.
> >
> > The ROHC framework is common to all profiles, and provides
> > generic features such as padding and segmentation of the
> > compressed packets (useful if the link layer can only handle
> > a limited range of packet sizes).
>
> Well, the framework provides the base for all ROHC compression.
> It defines the profile concept, which makes ROHC a general platform
> for compression schemes. It sets link layer requirements, and
> especially negotiation requirements for all ROHC profiles. It
> defines a set of common functions, as segmentation, CID's, and
> padding. It also defines common packet formats (IR, IR-DYN, Feedback,
> Short-CID expander, etc), and it defines a generic, profile
> independent, handling of feedback. One can also say that it defines
> the general principles for doing ROHC compression.
>
> > A ROHC profile is a description of how to compress a certain
> > protocol stack over a certain type of link. For example, ROHC
> > profiles are available for RTP/UDP/IP and many other protocol
> > stacks.
> >
> > Each ROHC profile can be further subdivided into the following
> > two components:
> >
> > a) Packet formats for compressing and decompressing headers
>
> I would say "compressed packet formats"
As I'm not 100% sure what exactly is meant by a "packet format"
(compressed or otherwise), it might be useful to capture in more
detail what information needs to be defined to get interoperable
ROHC profiles:
What we're really trying to define is a *function*, whose inputs are
the uncompressed header and the context, and whose outputs are the
compressed header and a (possibly updated) version of the context:
function
uncompressed header <--------------> compressed header
context updated context
So, as well as specifying which fields are in the compressed header,
we also need to define how to map between the uncompressed version
and the compressed version of each field. For example, if a
particular field is compressed using LSB encoding, then we need to
to define the interpretation interval, whether the field is
compressed as an offset from a different field etc. We also have to
define whether each field updates the context or not.
Does the term "compressed packet formats" cover all of the above
information? If so, then great! If not, then a different term might
be more appropriate.
> > b) State machine
>
> I am not sure "state machine" captures all the rest that is there,
> but I'll think more about this.
Again, it would be useful to capture exactly what needs to be
defined, so that we can see whether the term "state machine" is
appropriate or whether another term would be better.
I think that the following features are needed in conjunction with
the ROHC framework and the above "compressed packet formats":
1. Deciding when to delete context entries from the sliding window
(e.g. optimistic approach, ACKs etc.)
2. Deciding when the context needs to be refreshed (e.g. timeouts,
NACKs etc.)
3. How to recover from decompression failure
4. Context replication
I'm not sure whether context replication is within the scope of
the state machine - perhaps a more general term that captures all of
the above would be "context management" issues?
> > ROHC-FN is designed to help provide the packet formats for use
> > in new ROHC profiles.
>
> It is a notation form for the information to compress, it is not clear
> to me at this point how far you really get with the notation.
A description of, say, TCP/IP in the formal notation will give you
exactly what is defined in a) above. You get a function whose inputs
are the uncompressed header and the context, and whose outputs are the
compressed header and a (possibly updated) version of the context.
I suspect that more explanation of how exactly the notation defines
this function would be useful - I'll have a go at providing this in
a separate post.
> > Comments on the above text would be much appreciated!
>
> This is a good start, as I think it is essential that we try to define
> what the notation is, what it will be used for, and how it fits in
> the "big ROHC picture".
>
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc