Subject: Re: Header Stripping in Cellular

From: Vernon Schryver <[email-masked]>
Date: Sat, 23 Oct 1999 08:53:29 -0600 (MDT)

> To: Vernon Schryver <[email-masked]>, [email-masked]
> From: Mikael Degermark <[email-masked]>

> I agree that header stripping, as I understand it, should not be called
> TCP/IP.
> (And, btw, I fail to see how TCP headers can be stripped off while the
> needed semantic information is being maintained. I've been working
> with header compression stuff for a number of years, so I am intimately 
> familiar with the issues there. In fact, I've never heard of header
> stripping being
> proposed for TCP. Only for RTP/UDP. And I never saw a worked-out proposal.)
>
> I do not see that header stripping has *anything* to do with UDP Lite.
>
> Therefore I must protest that you, in your recent email, associate UDP Lite
> with
> header stripping. There is no ground for such an association. 
> Please do not confuse the issues.

No, you should please stop taking observations of the fact that UDP Lite
is not UDP as pejorative, and please concentrate on the technical issues
more than the politics and marketing pressures for calling whatever is
done for some mobile phone datagram traffic ""UDP-something" when it is
not UDP.   Instead of making the mistake made in the IEEE on 100 Mbps and
1000 Mbps LANs, let's put technical considerations before political
packaging and names for the market.  The marketeers will call whatever is
done on the phone links "UDP" and "TCP" regardless any and all technical
facts, so we don't need play name games.

That one thing is not something else does not make either thing necessarily
better or worse than the other.  While UDP Lite is a less radical change
to UDP than header stripping is to TCP, both UDP Lite and the TCP header
stripping abandon the end-to-end reliability of UDP and TCP on the grounds
that the bandwidth or latency costs are too high for mobile phone radios.
Reasonable people (as well as people like me) can and do disagree about
whether those costs really are too high and so whether using protocols
other than TCP/IP and UDP/IP is justified.  Intellectual honesty requires
that we all admit that UDP Lite is not UDP.  It also requires admitting
the nature of the reasons for not talking about whatever is done as
terminating the UDP stream or TCP/IP connection at the radio tower and
then doing something that differs in name and not just in fact on the
radio links.  The nature of those reasons is not technical.

For example, UDP Lite could be done between the tower and the mobile phone,
with the tower converting the headers and checksums.  The result would be
technically almost identical to the UDP Lite proposal.  The special, error
tolerant UDP streams would occur between exactly the same pairs of
applications/hosts as UDP lite.  Exactly as many application programs
would know they are using the error tolerant mechanism.  Even the same
datagram header could be used to encode the restricted checksum.

(By "converting the checksum", I mean the tower could in the Internet-to-
phone direction check the classic UDP checksum on the whole packet, count
and discard the packet if the classic checksum is bad, and subtract the
checksum of the UDP payload from existing good checksums.  It would do the
obverse in the other direction.)

Vernon Schryver    [email-masked]

---

From: Mikael Degermark <[email-masked]>
Date: Sun, 24 Oct 1999 18:39:25 +0200

I agree that UDP Lite is not UDP.  It is a superset of UDP. Classic UDP is 
one way, and should be the default way, to run UDP Lite. In that case the
UDP and UDP Lite headers are syntactically as well as semantically 
identical. 

The UDP Lite checksum can optionally cover less than the entire payload,
and in that case UDP Lite is not semantically equivalent to classic UDP.
The coverage is determined on a packet-by-packet basis by the sender, 
and must at least cover the headers. 

>obverse in the other direction.)

That might work. But now you need a way to transfer the information about what
part of the payload needs protection when going in the Internet-to-phone
direction. Would you use some kind of signalling for that?

Cheers, 

Micke