Re: [rohc] A couple more thoughts on "semantically identical"

[Ghyslain Pelletier <pelle@cdt.luth.se>]

Paul Francis wrote:

> Sorry to come back to this topic...I know we need to get off of talking
> about terminology and start talking about technology, but...

I understand. I am of the belief that more are actually sorry about this as
well...

>
> It occurs to me that in not liking the phrase "semantically identical", I
> was focusing on the wrong word...that is to say, the problem is not in the
> word "semantic" but in the word "identical".

My personal opinion is that the focus is on something totally wrong. Semantics
relates to the meaning of the various elements of a protocol, and for a
well-designed protocol to work for the purposes it was created the semantics
cannot be else than exactly the same, i.e identical.

>
> My thinking had been that, if you've got an application that is working just
> fine (voice over gehco) and is robust (to changes in the decompressor due to
> mobility), then at a high level the "semantics" are working just fine.
> Therefore I thought we must not be interpreting the word "semantic" well.

It's probable that one can make an application work together with something that
changes, in part or altogether, the meaning of a protocol if the application is
made to deal with exactly that situation. You can't expect that to be true in
general. That's exactly the wrong way to do things.

Secondly, although I have been more or less following/involved in this
discussion (and not really interested in pursuing it either) I cannot find any
example of something that would work just fine in the context currently being
presented to me. Furthermore, I have read gehco (a few times as suggested) and I
tend to agree entirely with the content of L.-E Jonsson's mail of last Friday
(http://www.cdt.luth.se/rohc/msg02006.html). I'd actually invite you (and
others) to comment on his email. I'll even copy-paste that line at the end of
this mail.

Finally, "at a high level the "semantics" are working just fine" doesn't mean
much to me. What might be the application of "high level" and "low level" to
semantics?! Rhetorical question. Semantics are understood or they are not.

>
> Strictly speaking, though, I suppose that if compression really does
> occasionally mess up the RTP sequence number or the IP-ID, then by the
> letter of the law the result is not semantically identical, even if no
> application is hurt by it.

"even if no application is hurt by it". ?
I  have yet to see that statement proven. They will be hurt, as for RTP
applications the elements of the RTP protocol have a clear and  fixed meaning as
per RFC1889. One cannot just propose the abuse of a protocol and then claim that
applications will not be impacted without presenting the relevant homework (and
I do not believe it can be proven anyway).

>
> So I want to ask the following question to the group.  Say a middlebox is
> tweaking TCP sequence numbers so that it consistently adds 1 to every
> sequence number throughout the whole connection.  Is this semantically
> identical?  I would argue that it is, because the semantics of the TCP
> sequence number is "offset from the first sequence number", and in fact in
> this particular scenario every sequence number received by the destination
> does accurately represent the true offset.

My understanding is that TCP would just stop working, as this offset space would
only be understood at the receiver. I believe fast recovery and other
reliability mechanism would just not work nor be coherent anymore. Hence it is
not semantically identical as over the whole TCP connection loop this offset has
a different meaning. Hopefully I misunderstood your statement.

>
> If people out there agree that this is semantically identical, then I think
> we have a very strange situation.  Which is to say that none of us would
> agree with actually transposing TCP sequence numbers in a compressor because
> it would not be robust (with mobility).  Yet at least some of us would
> consider doing it for RTP, because the application can robustly survive a
> small amount of error.

I would not agree to both for other reasons. And so far I have heard only of one
proponent of this suggestion (besides the authors of gehco).

>
> In other words, I would not consider non-transparent TCP compression which
> in theory could be made semantically identical, and yet would consider gehco
> compression which, from a strict interpretation of the header field
> semantics (as opposed to the application semantics), is not semantically
> identical.

According to which theory can non-transparent TCP compression be made
semantically identical!?! What is the meaning of application semantics!?! A
protocol must be used as specified, otherwise one will break its implementation
by not respecting its semantics. It's either TCP, or it is something else that
is being re-defined. Non-transparency is not a mild thing to apply.

>
> Once again, I come to the conclusion that the phrase "semantically
> identical" is fraught with peril.

The personal conclusions I reach with this discussion is that there is a strong
need to keep this statement where it is (and tatoo it in our brain cells,
face-to-face with the intellectual process ; ).

>
> Anyway, getting back to my original point that the problem word is not
> "semantic" but rather "identical", I realized that what I really think the
> phrase needs to be is "semantically good enough"!  This of course gets back
> to the pliant/brittle distinction I was trying to get at earlier.  RTP is
> somewhat pliant, so one can get away with "semantically good enough",
> whereas with TCP you can't.

"Semantically Good Enough" does not actually mean anything to me.
"RTP is somewhat pliant" does not actually mean anything to me either.
"get away with"...

One would have to come to me with a clear description of which fields usage one
is considering to break, and a thorough analysis of the impactssssss this will
have on a protocol implementation. This being said, would this be possible,
would it not mean a flaw in the protocol itself was found or a suggestion for a
new protocol would be proposed...?

Once more, in my personal opinion, removing/modifying the requirement of being
semantically identical would be equivalent to allowing specific solutions to
particular cases through new protocols and signaling, and would bring us outside
the header compression topic and even outside the IP world.

"Semantically Identical" *is* meaningful to me.

Best regards,

/Ghyslain

>
> PF
>
> ps.  Still plan to take another whack at the requirements in a day or two
> here...
>

PS:  I have read gehco a few times and I tend to agree entirely with L.-E
Jonsson's mail of last Friday (http://www.cdt.luth.se/rohc/msg02006.html). I'd
actually invite you (and others) to comment on his email and try to close this
bleeding issue.

I told you I'd copy-paste it.

>
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
begin:vcard 
n:Pelletier;Ghyslain
tel;home:+46 920 23 13 95
tel;work:+46 (0) 70 609 27 73
x-mozilla-html:FALSE
org:Luleå Tekniska Universitet / Ericsson Erisoft AB;Computer science / Advanced Wireless Research
adr:;;;Luleå;;;Sweden
version:2.1
email;internet:pelle@cdt.luth.se
title:Electrical Engineer, Senior Researcher
note;quoted-printable:Email@LTU:   pelle@cdt.luth.se <br>=0D=0AEmail@E///:   ghyslain.pelletier@lu.erisoft.se=0D=0A=0D=0A"The opinions stated in this mail are my own, and may not reflect LTU's or Ericsson's"
fn:Ghyslain Pelletier
end:vcard