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

From: "Garces, Rodrigo" <[email-masked]>
Date: Fri, 2 Mar 2001 13:40:31 -0800

Joe I agree fully with your definition. If the environment is a nasty
environment usually 
it is wise to go with smaller packets. The drawback is the overhead, But all
this is very 
network, protocol and environment dependent. Your rules sound to me like a
good rule of thumb.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Friday, March 02, 2001 11:01 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Correcting LINK (Advice for Internet Subnetwork Designers)

[email-masked] wrote:
> 
> 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.).

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

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 05 Mar 2001 18:42:14 +0000

The issue being discussed here is also evident in "draft-ietf-pilc-2.5g3g-00".

See draft-ietf-pilc-2.5g3g-00  Sections 3.1.3/3.1.4

This draft appears to recommend the use of level 2 ARQ.  This being so,
it seems strange that there should be a need for a smaller MTU.  It is
said this reduces the chance of corruption - but actually the converse
is usually the case: a smaller MTU forces more IP/TCP overhead per byte,
and therefore increases the volume of bits sent per actual byte of
payload transferred, and therefore the probability of loss (assuming
that size is, in some way, related to probability of loss - not always
the case).

The main issue is that it link performance with ARQ is likely
to depend on "the unit of link retransmission".

Overall throughput per bit sent at the physical layer benefits
from a larger MSS at the transport layer.

A larger TCP packet is more likely to be efficiently segmented into link
(or physical layer) PDUs, and will probably require less overhead
or padding at these lower layers.  

Gorry

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Mar 2001 13:24:28 -0800

> that size is, in some way, related to probability of loss - not always

Yes, but the probability that the WHOLE data segment is corrupted 
decreases.

> to depend on "the unit of link retransmission".

This assumes a reliable link is sufficient; the unit of
application retransmission is also a factor when it is not
(and, E2E, it is not).

> or padding at these lower layers.

Using small packets increases the overhead from headers, 
but decreases the overhead from retransmission typically.

Large packets, esp. at the link layer, also increases
the per-hop forwarding latency (excepting cut-through designs,
which, AFAIK, aren't that common).

Joe