Subject: draft-ietf-pilc-asym-00.txt comments

From: Lloyd Wood <[email-masked]>
Date: Tue, 5 Oct 1999 19:38:48 +0100 (BST)

http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-00.txt

This draft gave pause for thought, smart quotes and
apostrophes apart.

I don't see how 'forward direction' necessarily corresponds to the
dominant direction, since that's usage-dependent; preferred direction,
certainly.

3. characteristicsare - needsspace.

4.1 - raw bandwidth ratio is something nearer 205. Okay, less
overheads - but once you do that on both it probably goes up.

4.1.2 - Handley et al's congestion window validation work is relevant
and could outdate comments here, although it's early days. See top
of:
http://www.aciri.org/floyd/tcp_small.html

4.2 - RTS/CTS seems remarkably choice-of-MAC-specific; half the draft
is things-with-modems-or-US-only-Ricochets. Generalising this
without lapsing into platitudes does seem difficult, though.

5.1.1 - 'twice'? Which RFC?

5.1.2 - is the third paragraph talking about ACKs or reverse data
packets in general? Ugh, breaking layering; impacts on TCP RTT
estimations, too (discussed later in 5.2.1).

5.1.4 - talking about not-yet-deployed-unless-I'm-Rip-Van-Winkle ECN
without a reference for same? (Okay, so Word trashed the references
too, including [11]. Hurrah.) Not sure how you can be informational
about stuff not yet available, particularly since ECN needs end-to-end
internetwork support which is well outside the scope of the PILC
design problem.

5.1.5 - in bidirectional transfers, data as well as ack packets
compete for resources in _both_ directions, with the reverse direction
likely to act as the constraint.

Hmmm, no discussion of ACK compression (spacing) by name, or of ACK-
handling methods favouring small-RTT TCPs over long-RTT TCPs - some
knock-on internetwork effects worth discussing there, I expect.

6. - I have trouble understanding the last paragraph; ACK filtering
and reconstruction do rather more than just alter packet headers.

Copyright statement at end is interesINCOMPLETE.

cheers,

L.

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

---

From: Daniel Senie <[email-masked]>
Date: Wed, 06 Oct 1999 13:22:06 -0400

> dominant direction, since that's usage-dependent; preferred direction,

My sentiments as well when reading this draft. Talk about the link
directions based on the speed and other characteristics which make one
direction asymmetric vs. the other. Talking about "forward" and
"reverse" gets into questions of expected traffic flows for particular
applications. While a given environment may have been designed with some
preference toward a particular type of application (e.g. web browsing),
I'd rather see us stay away from implying how links will be used when
describing effects of asymmetry.

> without lapsing into platitudes does seem difficult, though.

This one sure stuck out... Many radio applications use CSMA/CA
(collision avoidance, rather than collision detection) due to the
inability to transmit and receive at the same time. RTS/CTS signalling
is hardly the issue in a general case. Talking about tranceive
environments where collision detection is unavailable makes more sense.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com