Subject: FW: PILC minutes from IETF-47

From: "Falk, Aaron" <[email-masked]>
Date: Fri, 7 Apr 2000 10:16:05 -0400

-----Original Message-----
From: Markku Kojo [mailto:[email-masked]] 
Sent: Friday, April 07, 2000 9:19 AM
To: [email-masked]
Subject: PILC minutes

Aaron,

please find attached the pilc wg meeting minutes that Jim 
and I gathered. Just got an email from Jim saying he is 
still in Australia, so  I am sending these to you. Some 
comments were probably not captured, but I think most
are there.

Rgds,

/Markku

---

From: Jamshid Mahdavi <[email-masked]>
Date: 07 Apr 2000 11:04:48 -0700

Additional notes on ERROR.  I noticed in the meeting comments about
errors in section 2.2 and sure enough there are some.  Here is some
proposed revised text:

Old text:

   After a fast retransmit, a sender invokes the fast recovery
   [RFC2581] algorithm, whereby it invokes congestion avoidance,
   but not slow start from a one-segment congestion window. This also
   saves time.

   It's important to be realistic about the maximum throughput that
   TCP can have over a connection that traverses a high error-rate
   link. Even using Fast Retransmit/Fast Recovery, the sender will
   halve the congestion window each time a window contains one or
   more segments that is lost, and will re-open the window by one
   additional segment for each acknowledgement that is received. If
   a connection path traverses a link that loses one or more segments
   during recovery, the one-half reduction takes place again, this time
   on a reduced congestion window - and this downward spiral will
   continue until the connection is able to recover completely without
   experiencing loss.

   In general, TCP can increase its congestion window beyond the
   delay-bandwidth product. In links with high error rates, the
   TCP window may remain rather small for long periods of time
   due to any of the following reasons:

...

New Text:

   After a fast retransmit, a sender invokes the fast recovery
   [RFC2581] algorithm.  This allows it to remains in congestion
   avoidance, rather than falling back to slow start from a
   one-segment congestion window.  This also saves time.  TCP
   implementations which follow these algorithms as specified in
   RFC2581 are genericly referred to as Reno TCP implementations.

   It's important to be realistic about the maximum throughput that
   TCP can have over a connection that traverses a high error-rate
   link.  Even using Fast Retransmit/Fast Recovery, the sender will
   halve the congestion window each time a window contains one or more
   segments that is lost, and will only re-open the window by one
   additional segment for each subsequent window of data that is sent
   and acknowledged.  For most Reno TCP implementations, multiple
   losses within a single window are very likely to result in a
   retransmission timeout, resulting in further performance
   degradation.  Further, if a connection path traverses a link that
   loses segments in several consecutive windows, the one-half
   reduction takes place each time once for each window of data which
   includes a loss.  This causes a downward spiral which will continue
   until the connection returns to an error-free state, at which time
   it can begin to increase the congestion window at the rate of one
   additional segment per window of data sent and acknowledged.

   In general, TCP is able to increase its congestion window beyond
   the delay-bandwidth product for the connection path.  However, for
   paths with high error rates, TCP's congestion window may remain
   rather small for long periods of time due to one or more of the
   following reasons:

...

---

From: Jamshid Mahdavi <[email-masked]>
Date: 07 Apr 2000 11:16:45 -0700

I hope this doesn't too thoroughly annoy anyone.

Suggested text for items 2 and 3 under section 2.2 in ERROR.

Old Text:

      2. TCP's congestion avoidance strategy is additive-increase,
      multiplicative-decrease, which means that if additional
      errors are encountered during recovery, the effect on the
      congestion window is a "downward spiral" - "reduce by 50 percent,
      recover by 20 percent, reduce by 50 percent due to the next
      error ...".

      3. Often small socket buffers are recommended with high
      error-rate links in order to prevent the RTO from inflating.

New Text:

      2. As described above, TCP's congestion avoidance strategy
      treats packet loss as an indication of congestion.  In links
      with frequent errors (which result in packet corruption/loss),
      this can effectively clamp the window at a low value.

      3. In some cases, links with high error rates are also
      low-bandwidth links.  People may mistakenly believe that by
      reducing socket buffer sizes, they will improve overall
      performance by preventing the RTT from rising (due to
      buffering).  See the <SLOW> document for more details on these
      practices.

I've got several comments on SLOW which this point is tied to.  I plan
to write these up today also.

--Jamshid