Subject: Re: Header Stripping in Cellular

From: Vernon Schryver <[email-masked]>
Date: Fri, 22 Oct 1999 19:55:14 -0600 (MDT)

> From: Zoran Kostic <[email-masked]>

>   * There are channels similar to the category of
>     dedicated packet channels that maintain
>     the link between the base and the mobile
>     even in the absence of actual packet transmissions
>     (for power control, ...) 
>   * These channels look like circuit switched 
>     channels
>   * Proponents of "header stripping" argue that
>     new TCP segments hitting these
>     channels are going to a single mobile. Many 
>     of these (or all) could have the same header.
>     Why transmit the header more than once when
>     possible ? That is to say, let's do header stripping
>     at the transmit side and recreation (reappending) 
>     at the reciver side of the wireless link.

In other words, terminate the TCP connection at the radio tower and do
something completely different on the radio link.  I think it's better to
call a spade a spade, and not call such radio links TCP/IP.

] From: Phil Karn <[email-masked]>

] ...
] So how does this differ from, say, VJ TCP/IP header compression?

The goal of VJ header compression was to maintain the TCP/IP end-to-end
connection sematics.  This  aint TCP/IP.   While they they deny it
vehemently, they simply do not want to or cannot use TCP/IP
end(mobile-phone)-to-end(mobile-phone)

] ...
] If, on the other hand, you terminate the TCP connection at a gateway,
] stripping out *all* of its header info, and passing just the user data
] into a newly originated connection of some sort, you have violated the
] end-to-end sematics of TCP and you should have your hand slapped. That
] is apparently what WAP (Why Another Protocol?) does, and why it's such
] a bad idea.

Is it a bad idea?  I don't know, but those who own the raw bandwidth
clearly think it is not just a good idea but necessary.

As with UDP-Lite, they're bound and determined to do the moral equivalent
of not running TCP/IP or UDP/IP on their radio links on the grounds that
the bandwidth and/or latency too valuable.  They're also bound and
determined to call what they're doing TCP/IP.

I think IEEE-802.3 made a big mistake in applying the Ethernet label to
things that have nothing to do with Ethernet except that MAC header and
usually the maximum packet length.  For mere marketing and inter-standards
committee political reasons (e.g. against ANSI x3t9.5 and IEEE 802.12),
they applied the Ethernet name to the differnet FDX 100BASE-T and then
GBethernet.  Maybe the costs in 100BASE-T and GBEthernet were worth it,
but those costs were high.  By insisting that GB Ethernet is Ethernet,
GBethernet stuck with the incredibly bad max payload size of 1500.  1500
bytes at 1,000,000,000 bits/sec!  If they'd called it something else,
they might have used one of the alternatives for getting within an order
of magnitide or two of a reasonable packet size.  The Ethernet label both
improved the market and kept them from making it harder to bridge.

I hope (or wish) the IETF does (did) not have similar political pressures.
Calling the radio links TCP/IP when they are not will force that protocol
to be not as good for radio links as it might otherwise be.  If you sat
down to design a transport layer for a radio link, you wouldn't merely
compress, fold, spindle, and mutilate the TCP/IP header.  You'd design a
header that does what you really need, including accomodating a good
connection to a TCP/IP connection terminated at the radio tower.

} From: Gabriel Montenegro <[email-masked]>

} ...
} it's interesting to go read good ol' rfc1144 (vj compression) appendix C
} on "More Aggressive compression". footnote 50 condemns compressing
} the tcp checksum, but vj himself admits eliding it towards the end of
} appendix C for a special case. 
}
} it does seem awful risky, though.

Everything is risky.  The question is whether it's worth it.  I'm sure I
understand the constraints well enough even to phrase the question
properly.  I'm also sure the new extremely mobile data people (i.e. mobile
phone people) will decide it is worth it in the expectation or need of
selling the bits saved on one subscriber's TCP/IP headers and error
recovery to another subscriber as data, and/or saving on latency.  UDP-Lite
shows they've already decided as much for at least some things.

I think the IETF should insist that such things that are not TCP/IP not
carry the label, but I also dislike many other kinds of political
correctness.

Vernon Schryver    [email-masked]

---

From: Mikael Degermark <[email-masked]>
Date: Sat, 23 Oct 1999 09:46:43 +0200

Hi Vernon,

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.

Cheers,

Micke