Subject: Updates for ERROR after WG last call

From: "Dawkins, Spencer" <[email-masked]>
Date: Tue, 12 Sep 2000 13:45:20 -0500

These are the changes that I'm looking at, after the comments received
during WG last call.

Section 2.1, second bullet:

Was:

      - During slow start, the sender increases its window in
        units of segments. This is why it is important to use an
        appropriately sized MTU - and less reliable link layers
        often use smaller MTUs.

Suggested:

      - Less-reliable link layers often use small link MTUs. This slows
        the rate of increase in the sender's window size during slow
        start, because the sender's window is increased in units of
        segments. Small link MTUs alone don't improve things unless
        Path MTU discovery is also used to prevent fragmentation.
        Path MTU discovery allows the most rapid opening
        of the sender's window size during slow start, but a number of 
        round trips may still be required to open the window completely.

(editorial) Section 2.2, second paragraph, first line has an extra "when" at

        the end of the line - needs to be removed.

Section 2.2, seventh paragraph:

Was:

   Not all causes of small windows are related to errors. For
   example, HTTP commonly closes TCP connections to indicate
   boundaries between requested resources. This means that these
   applications are constantly closing "trained" TCP connections
   and opening "untrained" TCP connections which will execute slow
   start, beginning with one or two segments. This is true even
   with HTTP1.1 in spite of its support for persistent connections.

Suggested:

   Not all causes of small windows are related to errors. For
   example, HTTP/1.0 commonly closes TCP connections to indicate
   boundaries between requested resources. This means that these
   applications are constantly closing "trained" TCP connections
   and opening "untrained" TCP connections which will execute slow
   start, beginning with one or two segments. This can happen even
   with HTTP/1.1, if webmasters configure their HTTP/1.1 servers to
   close connections instead of waiting to see if the connection will
   be useful again

Section 2.3, fourth paragraph:

Was:

   In low-speed, high error-rate environments (for example, the
   wireless WAN environment), TCP windows are much smaller, and
   burst errors must be much longer in duration in order to damage
   multiple segments. Accordingly, the complexity of SACK may not
   be justified.

Suggested:

   (delete this EXCELLENT paragraph, which was written so long
   ago that SACK was controversial...)

Section 4.0, third paragraph:

Was:

   Losses that take place on the ACK stream, especially while a TCP
   is learning network characteristics, can make the data stream
   quite bursty (resulting in losses on the data stream, as well).
   "Appropriate Byte Counting" [ALL99] has been proposed as a
   way of limiting this burstiness.

Suggested:

   Losses that take place on the ACK stream, especially while a TCP
   is learning network characteristics, can make the data stream
   quite bursty (resulting in losses on the data stream, as well).
   Several ways of limiting this burstiness have been proposed,
   including "Appropriate Byte Counting" [ALL99], TCP transmit
   pacing at the sender, and ACK rate control within the network.

Section 4.1, first paragraph:

Was:

   The recommendations described in this document will aid TCPs in
   injecting packets into ERRORed connections as fast as possible,
   but no faster. The goal here is to optimize the use of available
   bandwidth in a way that does not destabilize the Internet.

Suggested:

   The recommendations described in this document will aid TCPs in
   injecting packets into ERRORed connections as fast as possible
   without destabilizing the Internet, and so optimizing the use of 
   available bandwidth.

Appendix A, third paragraph:

Was:

   Delayed dupacks makes very little assumptions about the TCP
   implementations. If, however, one assumes that the
   implementations support TCP timestamps, then other schemes are
   possible. For example, the Eifel algorithm [LK00] uses
   timestamps to eliminate the deleterious effect of a spurious
   timeout on TCP performance.  Additionally, Eifel uses two of the
   currently unused bits in the TCP header and makes certain
   assumptions about the link-layer being able to treat flows that
   benefit from reliable service differently from real-time flows.

Suggested:

   Delayed dupacks makes very little assumptions about the TCP
   implementations. If, however, one assumes that the
   implementations support TCP timestamps, then other schemes are
   possible. For example, the Eifel algorithm [LK00] uses
   timestamps to eliminate the deleterious effect of a spurious
   timeout on TCP performance.

Appendix C, second paragraph:

Was:

   This proposal is still at the experimental stage, but implementors
   may wish to follow this work, because the effect is that cwnd is
   opening more aggressively when ACKs are lost during the initial
   slow-start exchange, but this aggressiveness does not act to the
   detriment of other flows.

Suggested:

   This proposal is still at the experimental stage, but implementors
   may wish to follow this work, because the effect is that the congestion
   window is opening more aggressively when ACKs are lost during the 
   initial slow-start exchange, but this aggressiveness does not act to the
   detriment of other flows.

Meta-comments: 

- I've gotten a couple of questions about whether the appendices are
  really necessary. My inclination is to leave them in, but I could be
  wrong.

- I've gotten a couple of questions about using contractions in formal
  specifications. A quick content search says the contraction "don't"
  appears in RFCs from RFC 2 to RFC 2906, including 52 with Jon
  Postel's name on them, so I'm not sure this is a bad thing.

Thanks to all who read this draft.

Spencer

---

From: Mark Allman <[email-masked]>
Date: Mon, 18 Sep 2000 12:16:10 -0400

> I believe the most recent conversation we had about ABC was that
> ABC helped to deal with application protocols like SMTP, that
> follow a couple of short packet exchanges ("enter userid", "enter
> password") with full-length packets as actual transfers start to
> take place - so that a standard TCP implementation would be
> happily thinking "well, I could send two (short) packets, so let's
> crank the window").
> 
> Does this sound familiar to you? If so, I need to rework this
> paragraph!

Ah, yes!  Thanks for the kick.  Obviously in that case ABC does, in
fact, limit bursts as it only allows you to raise cwnd based on the
actual number of bytes transmitted (i.e., the validated network
capacity).  The paragraph should be changed to make this a little
more clear, though.

Thanks!

allman

---

From: "Al-hussein Abou-zeid" <[email-masked]>
Date: Mon, 18 Sep 2000 18:52:29 GMT

With all due respect for the utility of the equation, I think we need to 
remember what it actually provides. It does not provide an upper bound, nor 
does it provide a lower bound. Thus, speaking of a bound seems to be an 
obvious mistake (at least to me!). It does provide a _reasonable_ estimate 
of the throughput of bulk TCP-like transfers in _certain_ situations. Thus, 
in my opinion, the mention of the equation should reflect that, and the 
guidelines the equation provides can be, at most, as loose as the 
assumptions made when deriving it. Overstretching the results in this case 
can be quite a risk.

Best regards,

Hussein.

>From: Cannara <[email-masked]>
>Reply-To: [email-masked]
>CC: "'PILC Mailing List'" <[email-masked]>
>Subject: Re: Updates for ERROR after WG last call
>Date: Fri, 15 Sep 2000 10:48:37 -0700
>
>Mark, I see what you're trying to accomplish and maybe the approach should 
>be
>to describe two possibilities:  a) newer transports that handle error loss
>reasonably; and b) older TCPs that create large delays in retransmission.  
>You
>needn't parameterize the quations beyond this.  Then emphasis should be on
>what error rate is then 'bad' for each of these two situations, since 
>there's
>not one answer, even within a factor of 5.
>
>Alex
>
>
>Mark Allman wrote:
> >
> > > Certainly there's a big, easily observed difference between older
> > > and newer (e.g., SACK) TCPs -- order of magnitude differences in
> > > delays to get good data through (Throughput).
> >
> > I agree.
> >
> > > So, the equation needs some TCP parameters and there needs to be a
> > > way for the user to decide how to set them, including the likely
> > > possibility for end-end mismatch in version.  This would qualify
> > > as a "first cut", in my opinion.
> >
> > I disagree.  I don't think we need to make this all that
> > complicated.  I think it is enough to put the appropriate caveats
> > around the current TCP friendly equation.  It is true that the
> > equation does not model every TCP.  But it is a decent projection of
> > TCP as it is currently being deployed and will be even stronger in
> > the future as SACK-based stacks become even more prevelant (which is
> > the trend).
> >
> > Is there a better way to give folks an idea about whether they
> > should consider their link ERRORed or not?
> >
> > allman
>
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.