Re: [MOBILE-IP] Comments on PILC draft

[Andrew Worsley <epaanwo@asac.ericsson.se>]

  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.

> 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 includethe
> 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.

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

      see http://www.ietf.org/html.charters/rohc-charter.html
> 
> 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.

   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.
> 
> Does this fall into the PILC or Mobile-IP scope or somewhere else?
> I am not sure.
> 
> Thanks,
> 
> Phil QA2757@email.mot.com
> 847-632-4118

  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