Subject: Re: Correcting LINK (Advice for Internet Subnetwork Designers)

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 25 Jan 2001 17:43:57 +0000

I was re-reading the Advice for Internet Subnetwork Designers
edited by Phil Karn, and noted the following two issues with the current ID:
	
1) TCP Performance Characteristics
		 Analysis of Link Layer Effects on TCP Performance

   There is still a subtle error in the specification of the 
   packet error rate in the wireless example, point 2,3 :
	
   p = 1 - ([1 - BER]^[MSS * 8]) - Not quite so.
   
  MSS should be MSS+(IP HEADER including IPSEC If used)
     +(Cumulative link overhead in bytes)

  Where the culmulative link header includes one subnet link
  header, CRC fields, and any adaption layers.
  (or N times this, if the the IP datagram were segmented by
  the subnetwork into N transparent fragments).

2) CRCs, Checksums and Error Detection.
  
  I suggest it may be useful to add a sentence here to say 
  that link layer error checking is normally provided only 
  within the transmit and receive processing.  Errors may be introduced
  by subnetworks while processing a packet pending transmission 
  or already received via a link. These errors are not discovered by 
  a link CRC check, and may not be detected by TCP/UDP checksums. 
  Errors of this sort do occur, and need to be minimised! 
  
  See also J. Stone & Craig Partridge in SIGCOMM 2000, 
    p309-321 (ACM CCR 30(4)). 

3) Calculations of predicted throughput.

   I wonder whether there is a case for omitting or perhaps moving to
   an appendix?  These calculations are illustrative and subject to 
   change or clarification.  

Gorry Fairhurst.

-- 
------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: Phil Karn <[email-masked]>
Date: Thu, 25 Jan 2001 10:29:17 -0800

Thanks for the comments. I'm planning a revision of the document soon, and I'll
put your changes in if the group concurs.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 25 Jan 2001 20:16:12 +0000 (GMT)

>      +(Cumulative link overhead in bytes)

This still suggests that TCP is only sending MSS-sized segments (as
opposed to segments up to and including MSS size - think telnet vs ftp
data, or acks vs everything else), and that the packet isn't further
tunnelled with additional IP headers (as in a number of cellular
network designs, e.g. GPRS.)

Since packet size varies with payload size up to MSS+headers (and path
MTU discovery is an imperfect beast), p is a distribution of values,
not a single fixed value, or...

         p = 1 - ([1 - BER]^[packet_size * 8])
where 

    packet_size = f(segment_size) + overhead/headers(IP and down)

and
         f(segment_size) is 20 <= segment_size <= (path MSS)

and f() is likely asymmetric (for your ack stream on the backchannel)
to boot. 

Yes, as stated in the draft, you're simply giving an upper bound on
TCP performance - actually goodput. But due to the MSS limit, the
probability of corruption p is itself an upper bound, rather
than a single fixed value; that probably should be stated (and
gets in the way of a 'upper bound on throughput'-MSS relationship.)

Suggested text changes/additions:
   
   p is itself an upper bound, as TCP may be communicating using
   packets carrying segments smaller than path MSS, with a resulting
   decreased probability of packet error. A flow of small TCP acks can
   be expected to be slightly more reliable than a stream of larger
   TCP data segments.

(...which is probably a good thing congestion-wise if you've got
multiple lossy links in series. can't think of a glib way to
visualise, describe or summarise the resulting complex effects on
goodput as segment/packet size varies for a middling to high BER.)

[..]

   *If* there were a uniform random distribution of
   errors, then the probability of a packet **carrying the largest
   permitted TCP segment** being corrupted would be:

[..]

   3.  Note that the packet size plays an important role.  **Allowing
   larger maximum** packet sizes will allow for **larger TCP
   segments and increased TCP throughput** at the same *packet loss*
   rate.

since it goes on to discuss error distributions under FEC, something
on packet size distributions and any clear relationship with BER
would be a nice addition.

L.

winces whenever he sees 'packet size' with 'TCP' in the same sentence.

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