Subject: [Tsvwg] update on abc

From: Allison Mankin <[email-masked]>
Date: Fri, 29 Nov 2002 00:32:54 -0800

Hi, 

draft-allman-tcp-abc-04.txt passed the IESG in our telechat this week,
having passed TSVWG WGLC before Atlanta.  

It was deemed during the IESG discussion that the spec should have an
note about the the intent to go towards standards track.  This is to
be an RFC Editor note (not requiring a revision of the i-d), developed
before the approval will be announced.  The IESG is reviewing a draft
of the note, and we thought TSVWG should review the draft note too.

Also, we have appended a couple of reviews that came out of the OPS area
directorate...they were positive, supporting the result.

   Statement of Intent

   This specification contains an algorithm improving the performance of
   TCP which is understood to be effective and safe, but which has not
   been widely deployed.  One goal of publication as an Experimental RFC
   is to be prudent, and encourage use and deployment prior to publication 
   in the standards track.  It is the intent of the Transport Area to 
   re-submit this specification as an IETF Proposed Standard in future 
   after more experience has been gained.

Comments?

Allison and Scott

----------

Reviews:

> TSV TCP Congestion Control with Appropriate Byte Counting (Experimental)
> draft-allman-tcp-abc-04.txt </internet-drafts/draft-allman-tcp-abc-04.txt>

Overall, this seems like a reasonable experimental document.

Summary: this is an alternative interpretation of the mandated VJ
congestion control algorithms, which appears to be consistant with
what Van said to do, but which differs in small but significant ways
from the slightly lame way in which some stacks chose to implement
Van's algorithm.

Caveat: it's been a -long- time since I understood this part of TCP
well enough to touch code without spending a day or two refreshing my
memory of how works, and I never worked on the BSD reference
implementation (the latter could be construed as a feature in this
context).  If you want a real opinion on this doc, ask Van or Sally.

What I think is going on here: the fundamental unit in the algorithms
specified in [Jac88] is the octet (the basic unit in the sequence
acknowledgement space), but some TCP implementations really prefer
only to think about segments (packets), and don't want to have to
calculate the congestion window (cwnd) in terms of individual octets
(understandable, since one really wants to stick with fixed point
arithmetic, and since there are other reasons why one would prefer
never to send a shorter-than-maximum TCP segment anyway).  So some
implementations apparently approximate the octet-based algorithm by
assuming that all segments are full sized and that each ack of new
data thus indicates that a full-sized segment has made it through,
thus allowing the sending TCP to crank up cwnd another notch.

The above is hypothetical, because the TCP implementation that I used
to work on actually counted the octets, which is also allowed.  The
slightly lame kludge described above is inferred from documents that
post-date both [Jac88] and the relevant code in the (non-BSD)
implementation I worked with.

At any rate, the current draft describes several sort of bad things
that happen as a result of this hypothetical lame implementation
kludge, and suggests that a particular form of counting the actual
octets would be a better solution.  The Appropriate Byte Counting
algorithm by itself is not completely in accordance with [Jac88], but
I think that the L=2*SMSS cap specified in section 2.3 takes care of
this problem and brings the algorithm back into line with [Jac88].

So the rest of the document appears to be talking about ways in which
the capped ABC algorithm, while conformant to [Jac88], would still
behave in ways that might surprise analysts who expect the behavior
displayed by the slightly lame segment-counting hack.

Nit:

SHOULD/MUST in an experimental document?

and another ops-dir member responds

randy

---
> Overall, this seems like a reasonable experimental document.

By the way, the mechanism it proposes has been fairly extensively studied
in the research world, and is viewed as appropriately conservative.

> At any rate, the current draft describes several sort of bad things
> that happen as a result of this hypothetical lame implementation
> kludge

(It's in fact the kludge used by BSD TCPs, so widespread.)

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg