Subject: Re: more LINK editing

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 7 Jul 2001 6:24:09 -0500

I think the paragraph is fine (but other people may disagree) but the delay numbers are not. My own design decision would be that the added delay should be factored as either being low when compared to the end to end delay, absolutely necessary so that while the throughput is maintained the goodput does not go to zero and congestion piles up elsewhere. Maybe just take the number away?

Marie-Jose
> 
> From: Phil Karn <[email-masked]>
> Date: Fri, 6 Jul 2001 17:57:16 -0700 (PDT)
> To: [email-masked]
> Subject: more LINK editing
> 
> I'm currently doing a complete wordsmithing pass through LINK. In this
> paragraph:
> 
>    Increased delay decreases the overall performance of TCP at a given
>    loss rate.  A good rule of thumb is to recognize that you can't do
>    anything about the laws of physics, so you can't change the
>    propagation delay.  Many link layer designers are likely to face the
>    following tradeoff: using additional delay to reduce the probability
>    of packet loss (through FEC, ARQ, or other methods).  Increasing the
>    delay somewhat in order to decrease packet loss is probably a
>    worthwhile investment, either up to doubling, or in the case of very
>    low delay pipes, adding 10-20 msec won't have much effect on a
>    typical Internet path.
> 
> The numbers here (10-20ms or 2x) seem a little ad-hoc, and that makes
> me uncomfortable. I propose deleting the paragraph. Any objections?
> 
> Phil
>

---

From: Phil Karn <[email-masked]>
Date: Sat, 7 Jul 2001 10:18:52 -0700

>I think the paragraph is fine (but other people may disagree) but the
>delay numbers are not. My own design decision would be that the added
>delay should be factored as either being low when compared to the end
>to end delay, absolutely necessary so that while the throughput is
>maintained the goodput does not go to zero and congestion piles up
>elsewhere. Maybe just take the number away?

Okay, I've replaced that text with the following:

 Many subnetwork designers have opportunities to reduce the probability
 of packet loss through FEC, ARQ and interleaving at the cost of
 increased delay. TCP performance improves with decreasing loss but
 worsens with increasing delay, so it is important to find the proper
 balance through analysis and simulation.