Subject: more LINK editing

From: Phil Karn <[email-masked]>
Date: Fri, 6 Jul 2001 17:57:16 -0700 (PDT)

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: Lloyd Wood <[email-masked]>
Date: Sat, 7 Jul 2001 11:21:29 +0100 (BST)

> me uncomfortable. I propose deleting the paragraph. Any objections?

Yes. The paragraph itself is good and a nice intro for what follows;
it's the numbers that are questionable, since it's hard to have hard
numbers when the scenario is defined without numbers.

You could say 'Slightly increasing the link delay in order to decrease
packet loss across the link is often a worthwhile investment' and
leave the rest of the draft to give the idea of what kind of increases
are worthwhile.

L.

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 09 Jul 2001 12:24:54 +0100

> me uncomfortable. I propose deleting the paragraph. Any objections?

Agree - don't think the numbers did make make any sense in a RFC.

> (Revised text from Phil)
> 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.

Sounds better to me.

It would be nice to replace "delay" with end-to-end delay to reflect
what really matters, and set the "delay" in context.

"FEC, ARQ and interleaving" - these are EXAMPLES, so I guess it would be
better to say so, is it better to insert an e.g. somewhere?
(There are others, such as adaptive modulation, power control,  ....)

Best wishes,

Gorry

---

From: Phil Karn <[email-masked]>
Date: Mon, 9 Jul 2001 11:38:42 -0700

>(There are others, such as adaptive modulation, power control,  ....)

Well yes, but I don't think adaptive modulation and power control have
a significant affect on delay in the way that FEC, ARQ and interleaving can.

Phil

---

From: Phil Karn <[email-masked]>
Date: Tue, 10 Jul 2001 21:54:12 -0700

>leave the rest of the draft to give the idea of what kind of increases

I put in the following text:

Phil

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Jul 2001 09:14:33 -0700

>  balance through analysis and simulation.

Why does TCP performance worsen with increasing delay?
It doesn't care much about delay, so long as it's 
relatively static (and scaling is implemented, for
long delays).

I'm concerned about tweaking the link to TCP per se,
as well. There are (gasp) other protocols, some of which
are comfortable with high delay and low loss, others
want the converse.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 17 Jul 2001 17:24:00 +0100 (BST)

> relatively static (and scaling is implemented, for

Growing the TCP sender congestion window in slow start and during fast
recovery takes time; higher path delay decreases goodput and thus
performance. There's also a fairness issue, where TCPs with small ack
control loops react faster than a TCP flow with a longer path and a
longer control loop, squeezing it out.

Having said all that, pretty much all protocols improve with
decreasing loss and worsen with increasing delay, although
degree of tolerance varies across protocols. There's nothing
particularly TCP-specific about _that_.

(Even kickstarting a flow after an outage needn't be
TCP-specific; it's reasonable to expect all transport protocols to
cope with duplication in the network.)

I preferred the original text sans numbers; so much analysis and
simulation starts from unwarranted assumptions (of e.g. path delay)
making it useless.

L.

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Jul 2001 10:08:05 -0700

> particularly TCP-specific about _that_.

Not NTP, for an example. Systems that synch endpoints
where the latency variance is more significant than action variance
benefit from larger mean delays, if it achieves smaller delay variances.
Other examples include video and audio playback (e.g., of
recorded data).

Protocols and their parent application are affected 
in differing ways by delay or delay variance. It is
useful for the link layer to accomodate either choice.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 17 Jul 2001 18:55:41 +0100 (BST)

> Other examples include video and audio playback (e.g., of

large latency variation can be dealt with by buffering at the
receiver in a semi-intelligent transport. That will give you the
larger mean delay you desire, minimising the variation/delay ratio.

You can't do much about too-large mean path delay for interactive use.
If your delay budget has already been exhausted in propagation...

as for NTP - just use multiple sources to provide redundant
information that will allow you to figure out and cancel out the
effect of latency variation from individual sources. RFC1059 has
filtering algorithms, and the state of the art has moved on since
then. ho hum.

(examples of deployed protocols coping badly with loss variation are
 probably more interesting.)

> useful for the link layer to accomodate either choice.

endpoints can add buffering to decrease the effect of delay variance.

To accommodate either choice sensibly, the link layer must _know_ (not
guess) what is required, and layering and administrative
concerns get in the way of that.

I'd stress that it's important to design the endpoint protocols to be
as adaptable as possible, in the face of unknown conditions.

L.

thinks we should make all links 100% reliable just because tftp
doesn't have windowed error recovery. no, really.

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Jul 2001 12:39:50 -0700

> filtering algorithms, and the state of the art has moved on since

Presuming you have multiple sources, which isn't always the case.

...
> as adaptable as possible, in the face of unknown conditions.

Agreed - but it's also useful that the link not assume apriori
what the adaptation goal is.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 17 Jul 2001 20:47:10 +0100 (BST)

> Presuming you have multiple sources, which isn't always the case.

...on the Internet? You can even weight trust...

> what the adaptation goal is.

Yes - snooping protocol id and port nos and leaping to conclusions
about behaviour and requirements of the traffic is particularly bad.

L.

Judge it by what it does, not what it says.

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Jul 2001 12:53:01 -0700

> ...on the Internet? You can even weight trust...

Multiple sources over the same path with the same dominant
variations aren't more useful than a single source. 

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 17 Jul 2001 21:02:36 +0100 (BST)

> variations aren't more useful than a single source. 

More reliable, though. (Sources can fail.)

L.