Subject: WG last call for ERROR

From: "Falk, Aaron" <[email-masked]>
Date: Mon, 14 Aug 2000 10:23:11 -0400

The document "End-to-end Performance Implications of Links with Errors" is
ready for working group last call. Please send comments to the PILC mail
list. 

A current version of the draft can be obtained from
http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-04.txt

---

From: Dan Grossman <[email-masked]>
Date: Tue, 15 Aug 2000 16:21:37 -0400

I have a few nits about the introductory text:

   It has been axiomatic that most losses on the Internet are due to
   congestion, as routers run out of buffers and discard incoming
   traffic. This observation is the basis for current TCP
   congestion avoidance strategies - if losses are due to congestion,
   there is no need for an explicit "congestion encountered"
   notification to the sender.
This is revisionist history.  In the early days of the ARPANET, there were 
significant numbers of losses which resulted  from errors in the voice-grade 
and group band leased circuits and modems that made up the backbone.   At the 
time that IP was invented, the need for congestion control was poorly 
understood, and congestion control was retrofitted in what was beleived to be 
the least disruptive fashion, i.e., by overloading the semantics of a dropped 
packet.   By then, the T1 backbone was running, and access was largely over 
DDS.

   Quoting Van Jacobson in 1988: "If packet loss is (almost) always
   due to congestion and if a timeout is (almost) always due to a
   lost packet, we have a good candidate for the `network is congested'
   signal." [VJ-DCAC]
With due respect, Van is a prominent and knowledgeable contributor to the work 
of the IETF, not the fitting object of a cult of personality.  I should hope 
that he would find this sort of thing more than a bit embarrassing.

   This axiom has served the Internet community well, because it
   allowed the deployment of TCPs that have allowed the Internet to
   accomodate explosive growth in link speeds and traffic levels.
No, this represents a design decision which more-or-less worked, from among a 
number of other possible design decisions which might have worked as well or 
better.

Suggested replacement text for the first 4 paragraphs:
-----------------
Congestion control in the Internet is based on an assumption that most packet losses are due to congestion.  TCP participates in a congestion avoidance strategy which treats a lost packet as a congestion signal.  This has worked well since it was introduced in 1988 [VJ-DAC], because most links and subnets have relatively low error rates in normal operation.   However, links and subnets that do not enjoy low uncorrected error rates are becoming more prevalent in parts of the Internet.  These particularly include terrestrial and satellite wireless links.  Users served by these kinds of links may see poor performance because their TCP connections are spending excessive time in congestion avoidance and/or slow start procedures triggered by transmission errors.
----------------

Add toward the bottom of section 1:
----------------
This memo is based on the explicit assumption that major changes to the entire installed base of routers and hosts are not a practical possibility.  This constrains any changes to routers and hosts that are directly affected by errored links.  
-----------------

Page 8:
 congestion has to take precedence over quickly repairing
   transmission error. This means that the best that can be
                     ^
                     s.
   achieved without new feedback mechanisms is minimizing the

Appendix C:
Memory fails me:  did the Transport Area WG decide to move ABC to "Proposed" or to "Experimental"?

Dan

---

From: Dan Grossman <[email-masked]>
Date: Tue, 15 Aug 2000 16:52:51 -0400

> time that IP was invented, the need for congestion control was poorly 
understood.  After the ARPANET congestion collapses of the mid-1980s,  
congestion control was retrofitted in what was believed to be

---

From: Dan Grossman <[email-masked]>
Date: Tue, 15 Aug 2000 18:22:17 -0400

It has been pointed out to me that the following could be misread as a 

> that he would find this sort of thing more than a bit embarrassing.

If others have read it this way, I apologise.  No offense was intended.

Rather, I wished to point out that this is a case of an I-D getting carried 
away in reverence for an individual who has made a significant contribution to 
the community. 

Readers from outside the community (for whom this draft is in part intended) 
would find this construction to be at least odd.   Nor is it necessary to the 
purpose of the document.

Dan

---

From: Alex Cannara <[email-masked]>
Date: Tue, 15 Aug 2000 23:01:36 -0700

Very good Dan.  Agree 100%.

Alex

---

From: William D Ivancic <[email-masked]>
Date: Mon, 21 Aug 2000 15:09:51 -0400

I suggest it may be good to time-stamp a section of the revision so that if or
perhaps when wireless channels become less loss due to errors the reader will
understand that was not always the case and therefore have an appreciation for
the design decisions made at that time.

>I have a few nits about the introductory text:
........
>Congestion control in the Internet is based on an assumption that most 
>packet losses are due to congestion.  TCP participates in a congestion 
>avoidance strategy which treats a lost packet as a congestion signal.  This 
>has worked well since it was introduced in 1988 [VJ-DAC], because most links 
>and subnets have relatively low error rates in normal operation.   However, 

as of 2000, 

>links and subnets that do not enjoy low uncorrected error rates are becoming 
>more prevalent in parts of the Internet.  These particularly include 
>terrestrial and satellite wireless links.  Users served by these kinds of 
>links may see poor performance because their TCP connections are spending 
>excessive time in congestion avoidance and/or slow start procedures 
>triggered by transmission errors.

*********************************************
William D. Ivancic
NASA Glenn Research Center
21000 Brookpark Rd.   MS 54-8
Cleveland, Ohio  44135
USA
Phone:   1 216 433 3494
FAX:     1 216 433 8705
Email:   [email-masked]
             [email-masked]      
http://ctd.grc.nasa.gov/5610/5610.html  
*********************************************