Subject: Comments on PILC draft

From: Phil Neumiller <[email-masked]>
Date: Tue, 04 Apr 2000 16:17:30 -0500

Folks,

Disclaimer:  I have not read through all 800+ messages in the
PILC archive.  That will take some time.  There are some subjects
of interest to Mobile-IP folks, that is why I cross posted.

I have read through the PILC draft.  It suggests many different 
proven methods for link layer adaptation to IP.  I found errors
of omission rather than of commission.  What could be done
is to expand the current draft (or introduce a new draft) that
specifically addresses problems faced by the implementors of
"wireless Internet".  This document was very TCP specific and
the wireless world is also concerned about RTP among other
things.

I believe that wireless links are sufficiently different (not
to mention increasingly prevalent) that they deserve their own
set of "standard" link layer adaptation techniques.

I suggest that we (enhance the existing) or prepare a draft that
defines "Canonical Wireless Link Layer Adaptation for IP".  In this
draft the important issues of QoS, AAA, and handover could be
addressed in an abstract way, suitable and useable by Wireless LANS
(femto, pico, nano-cellular) and conventional macro-cellular (i.e.
2G, 2.5G, 3G).  I am also hoping that the proposed Bluetooth BOF
planned for Pittsburgh could be generalized in scope to include the
more generic notion of "personal area networking" rather than being
just a link adaptation fest for Bluetooth.  Other link layers such
as 802.11a, 802.11b, HomeRF, Hyperlan, and Hyperlan2 must be
considered world players as well and the more commonality the
better.

I would also hope that the MWIF contribution could be combined with
a previously proposed BOF for open base station protocols.  It is my
hope that the IETF can help unify wireless access by providing
specific link layer hooks that are universal across diverse radio
access networks.

Does this fall into the PILC or Mobile-IP scope or somewhere else?
I am not sure.

Thanks,

Phil [email-masked]
847-632-4118

---

From: Andrew Worsley <[email-masked]>
Date: Wed, 05 Apr 2000 09:08:33 +1000

I am not posting this follow up to mobileIP but to the two groups that I
  think it is most relevant to, rohc and pilc. Hand over issues are being
  discussed in the mobileIP group but link layer stuff isn't. My comments are
  about IP over link layer issues. I am quoting the article in full because
  it was not originally posted to these groups.

> planned for Pittsburgh could be generalized in scope to includethe

   These issues are being addressed by the Robust header compression working
   group.

      see http://www.ietf.org/html.charters/rohc-charter.html
> specific link layer hooks that are universal across diverse radio

   This sounds like a worthy goal and I believe some what compatible with
   rohc groups agenda which covers giving guidelines to link layer designers
   and defining compression schemes for specific link technologies.
> Phil [email-masked]

  The ROHC group's work so far is mainly for RTP and not so much support is
  provided for TCP.

  Correct me if am wrong but the ROHC schemes assume that the packets sent
  have little or no error detection in them but that is how things are wanted
  for Voice over IP over the air as they would rather have corrupted data
  than have the whole packet dropped.

  The draft-jonsson-robust-hc-04.txt working document spells out having
  checksums only of the headers and presumably only dropping packets whoose
  header is corrupted (when it's compressed to a few bytes this is likely to
  be rare). Presumably corrupt packets with good headers are better than no
  packets.

  One question I have about that is that UDP for IPv6 requires mandatory
  checksums. Does this imply that the implementation would still try to use
  the failing packets? It's not clear to me that exactly how this is going to
  work.

  Finally I would like to suggest that a reliable profile transfer where
  there is bidirectional links be produced using a simple Nack
  (Negative acknowledgement) scheme like that described by Phil Karn
  in his paper:

  	http://people.qualcomm.com/karn/papers/usenix.ps.gz
    
  I suggest segmentation using small segments and Nacks.

  There must be a large amount of theory on this and some formulas about it.
  I did some maths and found that surprisingly low segmentation numbers for
  even quite modest BER values.

  I assumed packets were segemented into segements of size f with with two
  bytes of overhead per segment (1 byte CRC and 1 byte count?),
  ignored the Nack traffic (as it's in the other direction?) and got
  for the average amount transmitted (in the one direction) for a packet of
  length D:

  T = ((D/f)+1)*(f + c)/p

    where f = segement size (I called it fragment)
          c = size of segement overhead 
	  p = probability of segment transmission, assuming a constant BER.
	      i.e.  p = 1 - (1 - BER)**(f+c)

    and I assume the last segment is truncated to only contain the remaining
    data, if not you need an upper bound on the segment size say 50 bytes.

    For c = 2, D = 640
    Optimal values for f were:

    BER = .01 	f = 4 p = 0.617290  efficiency = 2.430
    BER = .001 	f = 16 p = 0.865825 efficiency = 1.299
    BER = 0.0001 f = 50 p = 0.959251 efficiency = 1.084
    BER = 1e-05 f = 150 p = 0.987914 efficiency = 1.026

      (efficiency is how much data is transmitted in the one direction
      divided by the size of the original data)

   Admittedly my maths may be off but although surprisingly low, I think it's
   about right. 

    I also came up with the following approximation for the ideal segment
    size :

    	sqrt(c**2 + c/8e)

	which depends only on the segment overhead and the BER value (e).

    The formula appears to work pretty good from my simulation data.
    
    I think that the ROCCO system could use this for TCP support.  I think
    the ideal fragment size calculation could be done on the number of
    packets lost over a period. The result from this calculation could
    be used to update the size of the segement size used.  This would
    allow the system to migrate to an appropriate value for the link
    dynamically as the environment changes. With f values < 200 this
    might only take a few seconds between adjustments.

    It needs a lot of work to turn the idea into a practical scheme, but the
    basic principle seems sound to me. e.g. Issues of frame size, handling
    sequence count wrap around and so on.

    Admittedly a lot of assumptions are made about the distribution of error
    bits but the general principal of using moderate segment sizes and Nacks
    seems to be a very robust approach. i.e. Erring on the side of small
    segments allows people to use large MTUs on their link (to avoid IPv4
    fragmentation problems) and minimise the damage that long or short error
    bursts will do.

    This scheme might actually be useful with some UDP systems. Possibly
    the sending of a packet over this profile as opposed to another more
    lossy profile but lower latency profile could be chosen on a packet stream
    basis?  i.e. Using QoS or protocol TCP vs UDP.

    Finally the selection of what to send over such a reliable profile needs
    to be judged based on the latency of the Nacks. If segments are small
    enough and Nacks can be returned quickly enough then the scheme would
    be practical for time constrained media like voice.

    	Andrew Worsley

---

From: Mikael Degermark <[email-masked]>
Date: Wed, 05 Apr 2000 04:41:30 +0200

>   and defining compression schemes for specific link technologies.

The "guidelines for link layer designers" document developed by ROHC is ONLY 
intended to provide guidelines on what properties the link layer must and should
have in order to run ROHC header compression over it. It is emphatically 
NOT a general-purpose guideline document for wireless link-layer designers.

>  have little or no error detection in them

No, that is not an assumption. We do, however, want (some instance of) the ROHC
schemes to work IF there isn't strong error detection on the link layer.

>  but that is how things are wanted

>  than have the whole packet dropped.

Some voice coders want that, yes. Not all, but some that some people care about. 

>  be rare). Presumably corrupt packets with good headers are better than no

1. The ROCCO checksum covers the original header, before compression. Its
primary purpose is to allow dependable verification of correct decompression.

2. Using that checksum to detect corruption of compressed headers as well will
weaken it for its original purpose. That may or may not be acceptable depending on
a) how resilient the scheme needs to be against production of erroneous headers, and 
b) the error properties of the link. 

>  the failing packets? It's not clear to me that exactly how this is going to

1. Even if UDP prevents the packet to be delivered to the application, it will
enhance performance it the header decompression module sees it. 

2. The reason that IPv6 mandates using the UDP checksum is that IPv6 does
not have a header checksum, so in order to ensure correct delivery for UDP, IPv6
had to mandate turning the UDP checksum on. That gives some assurance that
the UDP payload is delivered to the app it is intended for.

3. Applications that want to have corrupted payloads delivered to them, 
clearly cannot use UDP with an enabled checksum to do so. Thus they cannot use
UDP over IPv6. 

4. A transport protocol that optionally allows such applications to receive corrupted

payloads is UDP Lite, but it remains to be seen whether it is acceptable to the IETF.
UDP Lite might be presented to the transport area WG and will be discussed on its
list sometime before the next IETF meeting. 

This is clearly out of scope for the ROHC WG. People who want to discuss issues
related to UDP and UDP Lite should do so on the Transport Area WG mailing list:

General Discussion: [email-masked] 
To Subscribe:  [email-masked] 
In Body: subscribe email_address 
Archive: ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/ 

>  I suggest segmentation using small segments and Nacks.

For TCP and most of the non-audio and non-video UDP, I agree that 
the link should be almost error-free. This will be achieved 
by some some combination of (channel) FEC and ARQ. Most links that
ROHC is explicitly intended for can be run in such a mode.
The price paid for this is delay, but that is ok for TCP and some UDP. 

NOTE that the added delay does not primarily come from the ARQ scheme,
but from the increased interleaving needed to make the FEC work well. 

>  even quite modest BER values.

< deletion of some theory...>

>   Admittedly my maths may be off but although surprisingly low, I think it's

I am not surprised. This suggests that performance-enhancing ARQ schemes
over the link should use frames significantly smaller than typical TCP segments. 

<more stuff deleted> 

>    might only take a few seconds between adjustments.

It seems like a tall order for the ROHC WG to develop an ARQ scheme given that
the radio links explicitly mentioned in the charter already have such schemes. But, 
if the WG so desires, we can ask the ADs to add it to our charter. I would hesitate
to do so before we're done with the tasks currently at hand, though.

>    basis?  i.e. Using QoS or protocol TCP vs UDP.

I agree that different packet streams need different service from the 
radio system. The dividing line is not primarily UDP vs TCP, but rather
interactive audio & video    vs.  traditional TCP & UDP. I also expect that 
some games and other interactive apps will prefer low delay to error-freeness. 

>    be practical for time constrained media like voice.

For the links explicitly mentioned in the ROHC chater, the delay budget for 
interactive voice will not tolerate using such a nack scheme. That is the primary
reason for doing the ROHC work in the first place.

Moreover, if the delay budget allowed using the nack scheme, it would almost
certainly be a better overall system trade-off to improve the performance
of the channel coding by adding interleaving than to deploy the nack scheme.

Mikael Degermark

>    	Andrew Worsley
>---
>Mailing list for Robust Header Compression WG
>Archive: http://www.cdt.luth.se/rohc/
>