Subject: RE: Updates for ERROR after WG last call

From: "Dawkins, Spencer" <[email-masked]>
Date: Mon, 18 Sep 2000 10:43:44 -0500

Mark -

I agree about including the tcp friendly equation in ERROR, and I'll try to
steal the right words from LINK, where we've already discussed it, before
submitting the IESG last call version of ERROR. And this is something I
agreed to do a long time ago, before aborting the transfer!

But my real comment is about Appropriate Byte Counting.

I've changed mail systems since we had this conversation, but I believe that
the paragraph you're looking at dates from an early conversation we had
about ABC, that wasn't comparing ABC to standard TCP, but to previous
flavors of byte counting like "limited byte counting", which I remember you
characterizing as "slightly too aggressive". So I'm pretty sure the text
that's giving you heartburn may be taking this conversation out of context.

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!

Spencer

> -----Original Message-----
> From:	Mark Allman [SMTP:[email-masked]]
> Sent:	Thursday, September 14, 2000 9:46 AM
> To:	Dawkins, Spencer
> Cc:	'PILC Mailing List'
> Subject:	Re: Updates for ERROR after WG last call 
> 
> 
> 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: Dr G Fairhurst <[email-masked]>
Date: Mon, 18 Sep 2000 20:57:31 +0100

"Dawkins, Spencer" wrote:

> ...

> Does this sound familiar to you? If so, I need to rework this paragraph!

Sounds plausible, although the rework is probably wise now. I was re-reading
the paragraph and became muddled.  I finally came to the same conclusion: that
you were saying ABC is one of the "best" of the byte-counting algorithms.

The other schemes mentioned at the end of the paragraph, such as
sender pacing and network/receiver modifications to the ACK rate seem to
provide
more  direct support for the reduction of bursts of data segments from ACK
Compression or opening of cwnd. (There's also a cwnd modification by Packeteer
where the network changes the cwnd value in forwarded ACKs - but this
may be patented - and could be thought of as somewhat similar to ACK rate
control).

Gorry Fairhurst

--
------------------------------
http://www.erg.abdn.ac.uk/users/gorry