Subject: RE: [rohc] Comments on ROHC-GN...

From: "Qian Zhang" <[email-masked]>
Date: Mon, 24 Jun 2002 13:51:58 +0800

Hi Mark,

Thank you for your comments.
Please find my comments inline as usual...

Regards,
Qian

> 
> (I should probably point out that we have been working on a notation
> draft, as agreed at Minneapolis.  [Yes, I'm behind schedule, but
that's
> fairly normal for me!]  Since it's just about done, I hope you won't
be
> too dismayed when we submit it?  There's a large degree of
commonality,
> but also some issues that need to be discussed...)

[Qian] We do know that you had already been appointed to be the editor
for WG document about generic notation. What we had submitted is only an
individual draft. As I mentioned in the email that I send to you before
this submission, we just want to have a document to clarify the
discussion held in the mailing list, especially the part related to the
notation about the uncompressed packet (the structure of the
uncompressed packet).

As we agreed at the Minneapolis meeting, we will use the generic
notation for various profiles, such as TCP/IP. SCTP/IP, etc. I am now
refining the WG document for ROHC-TCP and plan to deliver a new version
soon. However, seems that it is hard to write the TCP/IP profile without
the basic notation. That is why we submit this draft for generic
notation first. Actually we are looking forward to seeing the notation
you proposed soon.

> Anyway, I have (you may be unsurprised to learn) a few comments.  So,
> here goes:
> 
> Can you clarify the nature of the mathematics that underly ROHC-GN?
> 
> I'm not quite sure why there is an example of the description of an
IPv6
> header in the 'original' EPIC-lite input language?

[Qian] As we agreed in last meeting, the new generic notation will based
on the EPIC-LITE that your group proposed before. Actually, our
individual proposal is also based on you work, as we mentioned in the
draft, 
"Similar as the one proposed in EPIC-LITE [EPIC], the language is
designed to be flexible but at the same time easy to use without
detailed knowledge of the mathematics underlying ROHC-GN." 
The difference is that we want to separate the uncompressed structure
description from the compression notation. In this way, we can obtain
the reference/or label functionality, which was implemented by rather
complex stack management proposed by EPIC-LITE before.

> Shouldn't most of the references to EPIC-lite be to an arbitrary set
of
> 'encoding rules' (except as an example)?  My understanding is that the
> notation is supposed to be independent of the encoding rules...

[Qian] We do agree that notation is independent of encoding rules.
However, it should indicate "how various fields are compressed,
including the encoding methods used for each field, thus the information
to transmit in compressed headers." as Lars-Erik pointed out in the
mailing list.

> I still don't believe that we've reached any consensus on the separate
> structure/encoding information, as (initially) described in section
4.7.
>   Personally, I find things like having VALUE in the structure and
> encodings section very confusing.
> 
> Section 5.1 seems to be entirely about the encoded structure of the
> header and, as such, I don't think belongs in a document about
notation.

[Qian] As I explained in the above and in our draft, "the notation of
uncompressed headers is used to clarify the terms and relations among
different fields in the protocol headers. It also provides the way how
to refer uncompressed fields".

> Regarding the encoding methods:
> 
> When you say that the OFFSET method encodes the difference (via the
3rd
> parameter), do you mean that this is treated as LSB encoding of the
> difference?  Could you clarify this?
> 
> The 'SCALE-FACTOR' and 'SCALE-REMAINDER' encodings take a scale-factor
> as a parameter.  Where does this parameter come from?
> 
> I don't really understand how you can just have an 'INFERRED'
encoding;
> surely we would need to define what this actually meanes?
> 
> In the SUB-TREE-0 example, the example is a bit odd!  The TCP options
> are bounded by the 'data offset' field.  The options *may* have an end
> flag, but don't rely on it...

[Qian] We had noticed that the TCP options can be bounded by the 'data
offset' field. However, as defined in RFC793, "End of Option List: This
option code indicates the end of the option list.  This might not
coincide with the end of the TCP header according to the Data Offset
field.  This is used at the end of all options, not the end of each
option, and need only be used if the end of the options would not
otherwise coincide with the end of the TCP header." That is why we had
introduced three notations, SUB-TREE-0, SUB-TREE-N, and SUB-TREE-LEN to
represent how to compress a sequence of records.

> I notice that another old favourite of past discussions, FORMAT, has
> gone.  It's not immediately clear to me how you handle the sort of
> scenarios it was designed to cope with: e.g. UDP checksum?

[Qian] Thanks for pointing out this. We can add this one. Moreover, we
can add the list notation also, although we can use SUB-TREE-X to
represent the list.

> Regarding the example TCP profile:
> 
> (I suspect that this needs a bit more tweaking, so I'll confine myself
> to a few of the more obvious points...)
> 
> There seems to be a signficant element of repetition in this.  Take
for
> example the TCP sequence number.
> Let me see if I follow this...
>    1/ The seqno is specified as a number of bits in the header
>    2/ All the encodings for seqno are listed and given probabilities
>       (possibly in combination with other fields)
>    3/ All the discrete encoding choices for seqno are listed
>       (presumably this is basis on which the encoding choice is made?)
> [I assume that the parameters for (2) and (3) have to agree?  i.e.
> LSB(tcp.seqno,20,16384) has to appear in both lists?]
> Is that about right?

[Qian] As I clarified before, the seqno is not only specified as a
number of bits in header. The key is to represent the position of the
sequence number field in the TCP/IP header. Using our notation, we can
easily refer to different field in the header, which was implemented by
stack management before.
I am not very quite clear about the question raised in 2/ and 3/. Would
you please clarify this again? 

> There seems to be some inconsistency about the position of the
> percentage in the P() method.  (And I'm afraid that I still don't
think
> I understand the use of P(x%) on its own..!)

[Qian] Good point. Thanks for pointing out this. We will refine this. We
define this notation just to clarify the notation with the indicator
generation methods.
One thing we would like to clarify is that, P(x%) is used to indicate
the probability of other cases which are not listed in the OR-list of
P(<encoding-method>, x%). One can assume the following translation
between P(<e>, x%) | ... | P(?,?) and if-else statements:
	1. P(A,n1%) | P(B,n2%) | P(C,n3%)
		if (A) {		// n1%
		} else if (B) {	// n2%
		} else if (C) {	// n2%
		}
	2. P(A,B,n1%) | P(C,n2%) | P(D,n3%)
		if (A && B) {	// n1%
		} else if (C) {	// n2%
		} else if (D) {	// n3%
		}
	3. P(A,B,n1%) | P(C,n2%) | P(n3%)
		if (A && B) {	// n1%
		} else if (C) {	// n2%
		} else {		// n3%
		}

> Personally, I don't believe that the security considerations are
> inherited from ROHC (or rather, ROHC has many more concerns than the
> notation).

[Qian] Thanks for the comments. I will think it further.

> BTW - I think that it's only fair to add Richard Price's name to the
> acknowledgements at the very least, don't you..?

[Qian] Actually our proposal is based on EPIT-LITE. So we acknowledge
all the contributors for EPIC-LITE by default. Here, I would like to
re-emphasize my acknowledgement for all the great work done by EPIC-LITE
again.

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Mon, 24 Jun 2002 08:45:12 +0100

Hi Qian,

Thanks very much for these clarifications!  Some of my comments were 
clearly based on mistaken assumptions.  A couple more points in-line...

Cheers,

Mark.

 >
 > [Qian] We do know that you had already been appointed to be the
 > editor for WG document about generic notation. What we had
 > submitted is only an individual draft. As I mentioned in the email
 > that I send to you before this submission, we just want to have a
 > document to clarify the discussion held in the mailing list,
 > especially the part related to the notation about the uncompressed
 > packet (the structure of the uncompressed packet).
 >

That makes sense -- certainly this strikes me as one of the unresolved 
questions that we need to address.

 >
 >
 >> Shouldn't most of the references to EPIC-lite be to an arbitrary
 >> set of
 >> 'encoding rules' (except as an example)?  My understanding is that
 >>  the notation is supposed to be independent of the encoding
 >> rules...
 >>
 >
However,
 >  it should indicate "how various fields are compressed, including
 > the encoding methods used for each field, thus the information to
 > transmit in compressed headers." as Lars-Erik pointed out in the mailing
 >  list.
 >

I think that I'd like to draw a distinction between how fields are 
compressed (e.g. LSB encoding) and how the bits that result from that 
are represented 'on the wire'.  Maybe this is just a terminology 
problem, but I think of EPIC-lite as being fundamentally about the 
latter.  (Which I guess is partly why we're splitting off the notation 
to avoid confusion!)

 > represent how to compress a sequence of records.

This isn't really directly relevant to a discussion of the notation, so 
we should probably take this thread elsewhere!  However, I don't think 
that you can bound the option list with the 'End of Option List' code.

 > you please clarify this again?

I probably ought to go and think about this some more, but:

All I'm really saying is that it appears, from the example, that the 
encodings for the TCP sequence number appear both with and without a P() 
wrapper method.  I was just trying to work out what the difference was 
between these two cases...

 > between P(<e>, x%) | ... | P(?,?) and if-else statements:

Ok, thanks for the clarification.

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