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

From: [email-masked]
Date: Thu, 1 Mar 2001 05:02:01 -0600

One thing that this discussion is forgetting is that in fact errors are not
realy independant and tend to cluster even if there are link level FEC
applied over the (segmented or not) IP packet. The assumption of
independance is ok to evaluate a bound or a first approximation of what the
behaviour is but cannot be be considered as more than an approximation. This
said larger packets will be better over smaller ones because it will be
easier to ensure end to end integrity by using more powerful encoding
techniques over the noisy link (more powerful codes, self-interleave etc.).

Marie-Jose 

-----Original Message-----
From: ext Joe Touch [mailto:[email-masked]]
Sent: Wednesday, February 28, 2001 9:54 PM
To: Phil Karn
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Correcting LINK (Advice for Internet Subnetwork Designers)

Phil Karn wrote:
> 
> Hi all,
> 
> I'm confused by this section still in the LINK draft:
> 
> Assuming constant, uniform bit-errors
> (instead of packet errors), and assuming that the BER is small enough
> for the approximation [p=BER*PACKET_SIZE] to apply, a simple
> derivation will show that larger packet sizes still result in
> increased TCP performance.  For this reason (and others) it is
> advisable to support larger packet sizes where possible.
> 
> To derive this, simply plug in p = BER*PACKET_SIZE into the simple
> formula for performance.  The result is p = O(sqrt(PACKET_SIZE)),
> providing larger performance for larger packet sizes.
> 
> If the approximation p = BER*PACKET_SIZE breaks down, and in
> particular if the BER is high enough that BER*PACKET_SIZE approaches
> (or exceeds) 1, the packet loss rate p will tend to 100%,
> resulting in zero throughput.
> 
> (end of excerpt)
> 
> I can't see how this can be true. Yes, if the *packet* loss
> probability is independent of packet size, clearly it's better to send
> large packets. But if the packet loss probability increases with size
> (as it would with independent bit errors), then I don't see how large
> packets could still be better.

Packet loss probability would have to be linear (or worse)
to size; anything less would justify larger packets.

One reason this can occur is because doubling the transport
PDU doesn't quite double the bits on the wire. Network and link
bits aren't doubled, so the resulting packet is somewhat smaller
e.g., for 512 byte payloads:

	original packet (e.g.)		doubled transport
	512 data			1024 data
	20 TCP				20 TCP				
	20 IP				20 IP
	14 ethernet			14 ethernet
	---------------------		---------------------
	566 bytes on the wire		1078 bytes on the wire
	
	2 packets = 1132 bytes, nearly 5% larger (thus 5% more likely
	to be hit by independent bit errors, right??)

Granted, 5% is small, but the smaller the packet, the larger that gets.

(hmmm - almost sounds a paper for next years' Sigcomm ;-)

PS - let me know if I've missed something; this is somewhat outside my
sphere...

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Mar 2001 10:31:22 -0800

> techniques over the noisy link (more powerful codes, self-interleave etc.).

Whether link erros are independent or pseudo-independent seems like it
would be heavily dependent on the link technology _and_ on what
timescale the errors are examined. 

Also, the encoding techniques applied depend on the _link_ level PDU,
not the transport PDU. There's nothing stopping the link from gathering
a few packets together to increase its ability to support FEC.

What the transport cares about is:

	- are transport PDU losses correlated
		regardless of whether the link
		gathers and scatters packets, when an
		error occurs, how many app PDUs are affected?
		is it worse than if the app PDUs were
		NOT gathered?

	- is data loss correlated to PDU loss?
	  if making the packet larger makes the PDU loss
	  go down, that's a win, e.g.

		apps (and nets, and links) should avoid 
		schemes that increase the probability _OR_
		correlation of loss.

Joe

---

From: Phil Karn <[email-masked]>
Date: Thu, 1 Mar 2001 13:16:03 -0800

>applied over the (segmented or not) IP packet. The assumption of

Good point. I'll add language to clarify.

Phil

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Mar 2001 11:00:40 -0800

> techniques over the noisy link (more powerful codes, self-interleave etc.).

Yes, but larger packets mean the hit is worse when it occurs, and that
errors are not individually recoverable (SACK).

I'm not sure there is a general rule-of-thumb here. Packet size depends
on latency requirements, the probability of error (distribution and
value), and the effect of an error (is it just ignored, retransmitted,
etc.), and overhead (BW and processing).

The only simple rules I can think of are:

	large packets when latency isn't a big problem:
		app is willing to wait OR errors are rare or ignored
		AND overhead is of concern

	small packets when latency is critical
		app is NOT willing to wait AND errors are common or expensive
		overhead is not of concern

Joe