Subject: Re: Updates for ERROR after WG last call

From: Mark Allman <[email-masked]>
Date: Thu, 14 Sep 2000 10:46:23 -0400

Spencer-

I think most of the changes look good.  I'd still love to see the
tcp friendly equation in this document, much as it is in the LINK
document.  I.e., if the error rate is low enough for a given
available bandwidth throughput is not impacted and you don't have to
worry.

But, my real comment is about...

>    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.

I still don't understand how ABC limits burstiness.  I believe quite
the opposite, actually.  I threw the following slide up during the
tsvwg meeting in Pittsburgh on the disadvantages of ABC:

 .Assuming $L~=~2~MSS$, we see increased burstiness:
  -Micro-burstiness increase: The number of data segments sent in
   response to an ACK is increased by 1~segment.
  -Macro-burstiness increase: During slow start \textit{cwnd} is
   currently increased by roughly 50\% per RTT (assuming delayed
   ACKs) whereas ABC will cause an increase of roughly 100\% per
   RTT. 

I agree that ABC can help mitigate the window growth problem that
occurs when ACKs are lost (for whatever reason).  However, it does
so in a bursty fashion.  And, I believe it is *more* bursty than the
standard algorithm.  

I'd **really, really** like to see the above reworked in the ERROR
document.  (Or, be proven wrong...)

allman

---
http://roland.grc.nasa.gov/~mallman/

---

From: Cannara <[email-masked]>
Date: Thu, 14 Sep 2000 10:07:51 -0700

Mark, what is "low enough" and "given available" speed?  In my experience, <1%
pkt loss can have a 20% throughput hit for non SACK TCPs and a still-
noticeable affect on better ones. 

We need to start weaning ourselves of the misuse of "bandwidth", by the way.
It makes networking folks look like they don't understand signal theory and
things like modems and how they work.

Alex

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 14 Sep 2000 18:25:26 +0100 (BST)

> We need to start weaning ourselves of the misuse of "bandwidth", by the way.

when people say 'bandwidth', they're generally talking about link
speed, or about throughput, or about the maximum link capacity
required.

I see this month's IEEE Spectrum Sep 2000, the QoS article on page 57,
gets in a grumble about this term, too.

L.

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

---

From: Cannara <[email-masked]>
Date: Thu, 14 Sep 2000 13:36:17 -0700

Yes, and it's doubly wrong to use "bandwidth" as a proxy for baud, bitrate,
speed, capacity or throughput, as you say.  It does a disservice to students
and others new to networking.  The "bandwidth" of an ordinary phone line may
be 4kHz, but the imagination of modem engineers has improved the usable
"bitrate" of the link from 110b/s to beyond 56000, via canny use of symbol
definitions and signal theory.  So, I hope we can expunge the word from the
documents discussed and strive for correct terms.

Alex