Re: rohc over... dvb?

[Carsten Bormann <cabo@tzi.org>]

I have attached an excerpt from the minutes of the Atlanta IETF, where 
we had an extensive discussion on ROHC over 802.
You can find more information at 
http://www.ietf.org/proceedings/02nov/231.htm -- in particular, the 
slides (they are called "Agenda" in the proceedings, but they include 
all slides used -- start at slide 58).

I believe some of the points made here can be discussed with different 
results in the specific context of DVB, but it is important to note 
that it is not just a simple matter of doing "ROHC over Ethernet".

Gruesse, Carsten

* ROHC over Wireless Ethernet Media

 - Motivation and possible approaches (Kris Fleming)

Kris Fleming gave a presentation of the motivation for and high level
technical content of the "ROHC over Wireless Ethernet Media" draft. 
WLAN and
WPAN links are often bandwidth limited and would therefore benefit from
header compression. They have also typical loss and delay patterns that
would motivate the use of ROHC in such scenarios. Since voice over IP 
is and
will be commonly used in these networks, header compression will
continue to be useful. If a generic solution for applying ROHC in these
environments could be defined independent of the physical layer
technology, that would simplify both standardization and
implementation. Such a generic solution should in that case be defined 
by
the IETF.

Solutions that have been considered are ROHC over PPP over Ethernet, 
since
both ROHC-over-PPP and PPP-over-Ethernet already exist. The drawbacks of
combining these two into a complete solution are the unnecessary
overhead, and the unnecessary complexity. The advantage is of course 
that
all components already exist. Another potential approach that has been
considered is to reuse an existing protocol for negotiation, but define
something new for encapsulation. For IPv6, neighbor discovery could
potentially be used for negotiation, but it is not really intended to
discover link layer capabilities.

The proposed "ROHC over WEM" defines a simple negotiation protocol, and 
an
encapsulation. Kris gave a quick overview, and then asked whether there 
was
any interest in doing this in ROHC.

Carsten commented that a key question is where in the protocol stack it
would make sense to do this. In the original ROHC work, Ethernet was
completely ignored since adding header compression to it was
considered to be of less value, e.g. due to the minimal frame size.  In
802.11, the headers are rather large and are sent at a lower rate than 
the
data. The gain from header compression could then be questioned. Greg
Daley noted that with Mobile IP we might get lots of tunneling headers, 
and
that would increase the gain from header compression.

Draft:
draft-fleming-rohc-wireless-ethernet-med-01.txt


 - ROHC over Ethernet issues (Carsten Bormann)
 
Carsten had prepared some discussion material on this issue. We have a
pretty large design space here, and before we do anything we must
explore it so that we know what we are trying to invent.

First of all, there is the issue about which negotiation protocol to 
use, if
we would have to invent a new one. For IPv6, neighbor discovery (ND) 
seems to
be an obvious choice. For IPv4, one could think of using ARP, but that
sounds difficult at this point in the evolution of this protocol. If 
PPPoE
was used, we would get lots of unnecessary things and still have to
invent a new encapsulation. One could also potentially think of using ND
also for IPv4.

Secondly, we have the encapsulation issue. Ethernet requires padding,
which is neither needed nor desired over the wireless links. If we do
compression over the whole Ethernet, bridges between the wired and
wireless parts must know about the padding scheme and translate or strip
padding. This will easily get complicated. It might make sense to do 
this in
the wireless access points instead, but then we would not get a generic
scheme and it would be very unclear whether this would be a ROHC WG
issue.

A long discussion about the architectural placement of compression in
these scenarios followed. Pat Calhoun suggested that this should be 
done by
other bodies, for the links that would really benefit from header
compression. Kris argued for doing a general solution and avoid having 
to do
the work over and over again, while others then noticed that link
specific solutions would probably give better gain, and we should
remember that not all link layers would at all benefit from using
compression. Carsten concluded that all comments just indicate that we 
do
not have a clear architectural choice, there are several possible
options. It is also very unclear whether this is appropriate work for 
the
IETF and the ROHC WG. We will have to continue these discussions on the
mailing list.