Subject: Header Stripping in Cellular

From: Zoran Kostic <[email-masked]>
Date: Fri, 22 Oct 1999 12:37:29 -0400

Header Stripping in Cellular

This topic was touched on briefly before, and the consensus was
Do not allow it to be put into any standard !!

Let me be the devil's advocate, which does not mean that the principal
idea appeals to me any more than to anyone else on this list.

I am afraid that  header stripping will almost inevitably be included
at least as an option in standards that deal with cellular. And service
providers will probably choose that option as a default operation mode.

This is why:

* Cellular service providers have paid a LOT for bandwidth
* Improvements over current 2nd generation cellular systems consist
   to a large degree of improving spectral efficiency of cellular
   networks (bits/second/hertz/cell) - improving the capacity -
   improving the revenue flow
* Pretty much every single bit is accounted for in framing of RLPs,
   speech blocks etc...
* If there is even a remote chance that some bit does not have to be
carried
   over the air, it should not be carried over the air, because spectral

   efficienty suffers, cellular capacity gets hurt, revenue and profit
go down

The questions we have to ask us are:

1) What might be the highest compression rate achievable for TCP/IP
headers ?
    Even it is 10, I believe that stripping will be what service
providers
    would opt for. And can we even come close to 10 ?
2) If we buy into the argument that header stripping will be legitimized

    regardless of our opinion, what should IETF do about it ? Maybe
there
    should be something that from spectral efficiency mimicks header
    stripping but is more acceptable to this community (again I am not
    sure that compression will do the job).
3) Heretic thought: Cellular services are a kinda special, since the
base does many things
    for its mobiles anyway... do we have to be exclusive on the topic of
header
    stripping and recreation ? Maybe we should come up
    with recommnedations  on how should header stripping and recreation
    be done ??

Zoran

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 22 Oct 1999 18:22:26 +0100 (BST)

> Do not allow it to be put into any standard !!

Fortunately, pilc is only creating informational documents, otherwise
we'd be jumping up and down about all that layer-breaking ack-mangling
too.

I'm now wondering why I haven't heard the phrase 'tunnel stripping'
before.

L.

Begin with decades spent designing and building a robust internetwork.
Go on with decades optimising all robustness out of the internetwork.
Finally, the internetwork will break down and traffic will not flow.
We name this process 'progress'. But enough about the highway system.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Mikael Degermark <[email-masked]>
Date: Fri, 22 Oct 1999 20:39:19 +0200

Zoran, 

At the coming IETF in Washington DC, there will be a BOF discussing
robust header compression for cellular. One of the proposals to be 
presented at that BOF can compress RTP/UDP/IP down to 2 bytes (or
possibly less in coming releases!) even in the presense of substantial
loss on the link. 

Please come to the BOF. Even if we rehash this here, we will have to come
to some agreement as to what the IETF should do about header stripping 
and similar ideas. The BOF is a good venue to hash this out!

Cheers, 

Mikael Degermark (who will chair the BOF)

(I've commented your letter at some places below.)

>   improving the revenue flow

With suitable header compression it is possible to get within less than a
dB from circuit-switched voice. So the incentives aren't quite so large
as you say. 

>    would opt for. And can we even come close to 10 ?

Do you mean TCP/IP or RTP/UDP/IP?
For TCP/IP I find it difficult to go below 4 bytes. 
Which is 10.

For RTP/UDP/IP 2 bytes or less seems within reach (provided the UDP
checksumming issues can be resolved in a reasonable manner.)
Which would be 20. 

>    sure that compression will do the job).

Please come to the BOF!

>    with recommnedations  on how should header stripping and recreation

Perhaps if one could somehow view the cellular link as a kind of RTP mixer
it could be legal to fiddle with the IP/UDP headers. The RTP header must,
as far as I can see, be recreated *exactly*. 

One thing the cellular people seem to like is "All-IP" or "IP all-the-way"
which 
implies that the data is carried using IP end-to-end. If header stripping is 
used, that seems to be a mis-nomer. (Not that that would stop any marketing
people from using it...)

Personally, I believe it is possible to design a sufficiently good header
compression 
scheme that will satisfy both die-hard IP people and the spectrum-efficiency
hungry cellular people! 

Micke

---

From: Phil Karn <[email-masked]>
Date: Fri, 22 Oct 1999 11:19:10 -0700 (PDT)

Sorry, what do you mean by "header stripping"?

Phil

---

From: Greg Minshall <[email-masked]>
Date: Fri, 22 Oct 1999 11:57:56 -0700

> I'm now wondering why I haven't heard the phrase 'tunnel stripping'

you have.  it's called ``MPLS''.

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 22 Oct 1999 20:47:24 +0100 (BST)

> you have.  it's called ``MPLS''.

I don't believe so.

MPLS doesn't attempt to strip off IP headers and IP-in-IP headers and
then regenerate them at the other end from per-flow state information
to save bandwidth on intermediate low-capacity links. MPLS doesn't
compress[*] those headers, either.

MPLS merely adds one or more layer-2 encapsulating headers between
link and network headers in order to speed up processing and
decision-making for high-capacity links (although some people are
repeating that whole desktop-ATM thing and making noises about e.g.
encapsulations for Ethernet to pass signalling information onto
endhosts these days.)

An MPLS label stack looks awfully like a complex unstripped tunnel to
me; the semantics involved make IP-in-IP encapsulation look trivial.
I've yet to hear the phrase 'tunnel stripping' used in an MPLS
context, too.

Hmmm, but we were discussing cellular networks. MPLS in cellular
networks? I imagine that some existing-cellular-network-focused types
would be jumping up and down about MPLS, going 'Each label is an extra
32 bytes uncompressed! We can't afford that overhead!' and I would be
very surprised to learn that MPLS was being considered at this point
for e.g. some UMTS variant.

On the other hand, if you want your MPLS with some cellular wireless
network, there's a new preprint arguing the case for MPLS in satellite
constellation networks (which have cellular coverage) on my
publications webpage. It's hardly implementation, but hey, I'm still
just about on-topic. Thanks for that.

L.

[*] that's 'strip and replace with a token reliant on ordered flows' 
    for the most part, I think.

---

From: Greg Minshall <[email-masked]>
Date: Fri, 22 Oct 1999 13:43:45 -0700

well, i left off the "smiley".  but the fact is that you can look at MPLS as 
being a way of sending packets on a source routed path, with the MPLS label 
standing in for the encapsulating header, including source route options in 
the IP header (though i could probably think of nicer ways of doing this).

but      ;-)

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 22 Oct 1999 22:46:25 -0700

smileys or not, that's a good way to strip (so to speak) the
B.S. surrounding most of MPLS. the label (or label stack) is
simply a syntacticly compressed form of an IP header+possible
IP tunneling encapsulation with route options in the tunneling
header.

cheers,
gja

Greg Minshall wrote:
>   --------------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

-- 
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

---

From: Lloyd Wood <[email-masked]>
Date: Sun, 24 Oct 1999 02:55:30 +0100 (BST)

> IP tunneling encapsulation with route options in the tunneling

You're talking about encapsulating headers containing labels
semantically overloaded by multiple associations within the MPLS
network - a rather different thing. There's nothing in an IP header
that has to directly correspond to the stream that a label is chosen
to mark, what with downstream merge and all, so the analogy is
misleading.

Or about as dated as talking about TOS bits in diffserv, which
doesn't get e.g. the essential codepoint idea across at all.

L.

the thing I liked about IP was that the semantic overloading was
minimal and necessary - routing address/identity. Things were simpler
then.

---

From: Grenville Armitage <[email-masked]>
Date: Sun, 24 Oct 1999 11:46:59 -0700

> to mark, what with downstream merge and all, so the analogy is

I'm talking about the fact that an LSP provides the instantiation
of the edge to edge forwarding requirement of the associated FEC.
In the most general, purely IP connectionless equivalent form, this
forwarding would require encapsulating the IP packets at ingress
with a tunneling header (itself having source-routing options
options if we're emulating a constraint-routed LSP). Simple MPLS
networks are functionally equivalent to null tunneling encapsulation
in the connectionless version (aka regular IP forwarding). All
other forms of MPLS are functionally equivalent to permutations of
the general connectionless form I described.

Downstream merge doesn't change this analogy, since you dont
merge packets that would not otherwise have merged anyway based
on the FECs to which they belong.

The main reason any sensible people care about MPLS is exactly
because it allows traffic engineered backbones (for alls sorts
of meanings of 'engineered') without wildly inefficient IP-IP
tunneling. Just slightly inefficient IP-in-MPLS tunneling.

The comparison is quite apt.

gja

---

From: Mikael Latvala <[email-masked]>
Date: Mon, 25 Oct 1999 12:41:12 +0300

>scheme that will satisfy both die-hard IP people and the spectrum-efficiency

But not IPSEC people. 

Matter of fact, if e-commerce is the driving force which lures customers
into using mobile data services (as far as I know the only widely used
mobile data service today is GSM's Short Message Service (SMS) which has
nothing to do with the Internet) there is an immediate need for securing
those transactions.

If we agree that application level security is not a feasible solution then
IPSEC is the only way to go. And that pretty much invalidates most of the
work done with header compression. I assume here that the end-to-end
principle is applied also to the security aspects.

Mikael

P.S. I think it would be very useful if the coming BOF could get some of those
security bigots out of their foxholes (i.e. IPSEC related WGs) and make
them face the world in which their ideas are used.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 25 Oct 1999 13:24:27 +0100 (BST)

> principle is applied also to the security aspects.

...which is why application-level security is the only feasible
solution, yes?

L.

is wondering what an IPSec'd UDP lite is going to look like.

---

From: Mikael Latvala <[email-masked]>
Date: Mon, 25 Oct 1999 17:33:38 +0300

>...which is why application-level security is the only feasible

Yes, that's pretty much what is said in Saltzer, Reed, Clark paper. 

However, if you want to have the IP header/payload authenticated and the
TCP or UDP header/payload encrypted, something which security experts (I am
not one of those) consider a must, the network layer is the place to do
this. So from that point of view we could regard IPSEC as an application
(e.g. "bump-in-the-stack") which has been taken as high as possible in the
protocol hierarchy.

/Mikael