Subject: comments on ASYM -04

From: Lloyd Wood <[email-masked]>
Date: Wed, 30 May 2001 20:30:03 +0100 (BST)

I got asked to cast a critical eye over -04 of the 'TCP performance
implications of network asymmetry' draft:
http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-04.txt

...which will hopefully provoke some on-list discussion. Although, judging
from the recent copious discussion resulting from allman's review of 
the 2.5g3g draft, I'm not holding my breath.

This notes only the more significant/open-ended stuff only; minor editorial
nits have already been sent to authors.

First off: title. Is this really network asymmetry? Link or path
asymmetries, I'd buy...

Second off: structure. The draft's intended for BCP, but spends an
awful lot of time and pages describing techniques that SHOULD NOT be
used in the Internet in their current form. So why describe it in a
document intended for BCP?

Wading through complex descriptions of techniques to then be told you
can't use them can be offputting; I'd suggest reorganising the draft to
present the summary of what can be used in an abbreviated
taxonomy/contents up front, followed by everything that may be used, with
everything that SHOULD NOT be used taking up the rear. Most (even
diligent) readers won't get to the SHOULD NOT stuff, and you'd be doing
them a favour by moving it to the end. And even reducing descriptions:
'The thing described in [blah] is bad. Don't do it.' Okay, perhaps that's
extreme, but as it is it's crying out to be turned into a survey paper and
published somewhere.

Third off, terminology: the multiple uses of 'bandwidth' to mean available
link capacity (referred to as 'capability' for some reason), bottleneck link
capacity, and flow capacity use confuses considerably, especially given the
discussion of wireless links - this impacts calculation of k. It would be
nice to see this term avoided in favour of clearer language. The assumption
that the upstream link is the bottleneck may not hold for a path experiencing
congestion elsewhere; a clear discussion/definition of bottleneck is
also needed.

delayed ack stretch factor d is defined, but isn't used in the document; k
is used instead - and the definition of that is in some hard-to-find
conference paper. Better to define k and drop d entirely.

And what's backpressure?

Section 4.1 discusses the principle of ack clocking preserving temporal
spacing. But since delayed acks are commonplace, the temporal spacing seen
in the return path is not the same as that in the forward path; similar
overall characteristics, but not the same spacing.

4.1 point 2. doesn't mention byte counting. byte counting crops up
later in section 5.7. Since RFC2581 is standards track and mentions
counting, giving an algorithm to boot, I'd expect some discussion of bc
here, or at least a forwards reference. (allman?)

Throughout, it is stressed that on wireless (MAC) links the problem is the
number of acks transmitted, and not their size. In several places this
underplays the overhead, which in most MAC schemes (where IP MTU size is a
multiple of frame carrier size) is a function of both number _and_ size.

section 5.3 - what does the choice of RED have to do with ECN, apart from
involving Sally? RED is surely not the only possible algorithm capable of
deciding to set an ECN bit, and the two are orthogonal.

that's it.

L.

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