Subject: Re: PILC ASYM document

From: Vernon Schryver <[email-masked]>
Date: Wed, 1 Mar 2000 18:55:15 -0700 (MST)

> From: Hari Balakrishnan <[email-masked]>

> ...
> 3. But there are important, real cases when things aren't quite so simple:
>
>    (i) Media-access.  Many MAC protocols are RTS/CTS based,
> requiring a synchronization handshake before communication, with
> each failed RTS triggering an exponential backoff followed by retry.
> ...

I don't understand the a priori relevance of such considerations.
TCP is not a MAC protocol, and in general is supposed to be blithely 
ignorant of oddities in the link layer.

> ...
>    (ii) Bi-directional traffic.  I didn't think this was such a
> common occurrence, but I recently received this message from a DSL
> customer, which I repeat verbatim below.  (The customer recently
> graduated from MIT.)

> ...
> Except one problem - when someone is downloading a file off of
> my web server, saturating the 128kbits/sec upstream link, then all
> my performance goes to hell. Pinging the gateway takes 2 seconds
> round trip, ...

The problems there are irrelevant to the draft.  First, no matter what
you do, you can't get more than 128 kbit/sec from a 128 kbit/sec link.
Second, such experiences show that saturating a link with mixtures of
interactive and bulk traffic through with routers that no any notion of
priority queues is a bad idea, which is not exactly a new discovery.

>       One might think that this is an uncommon situation, but if you
> look at the way the Internet is evolving, nodes serving information from
> people's homes are becoming increasingly commonplace and are likely to
> dramatically increase in the next few years.  I predict that situations
> like Nelson's above will not be rare in the near future, when we start
> putting all our computers and myriad other devices in our homes on the
> Internet.

Those problems are not new.  In the good old days, many of us suffered
exactly such situations as Nelson's, except that our links were 10 or 50
times slower.  Please consider ancient asymmetric dial-up modems including
those from (I think) Courier and modems that were sort-of assymetric like
Telebits.

>    (iii) Loss rate asymmetry: Some of the techniques (e.g., sender
> adaptation) described in the draft handle this case as well, which
> is observed in many real systems including mobile ones where end
> stations transmit at much lower power and contend for reverse slots
> whereas the forward channel is from a high-powered base station
> and is therefore relatively loss-free.

That sounds like the old argument that the upper layers must be
modified for every new link layer that comes along, regardless of 
whether how different it really is (think about Telebits).  
Some people reflexively resist that argument.

> Given these situations, we believe that they are worth clearly
> documenting in a draft. ...

Anyone can write about almost anything in an offishal fur shure Internet
Draft, as demonstrated by draft-terrell-ip-spec-ipv7-ipv8-addr-cls-*.txt.
Besides, that draft-ietf-pilc-asym-00.txt exists is not controversial.
The interesting question is what happens to a draft after it has been
published.  How people are supposed to respond to this draft?  Is it
intended to become a Proposed Standard or a BCP?   Or would it become
just another Informational RFC?  Or is it a call to start some experiments?

It seems that draft-ietf-pilc-asym-00.txt has two parts.  One is a
discussion of various problems, and the other advocates several significant
de facto changes to TCP.  It's hard to argue with a discussion of problems,
but I'm not convinced of the wisdom of the advocated changes.  For example,
the document is not convincing about obvious worries about consequences
of reconstructing ACK's, such as distorting the RTT measurement.  (Yes,
I've read the end of section 5.2.2.)

For another example, I'm not convinced by section 5.1.5 that Acks-first
scheduling does not require the gateway to explicitly identify or maintain
state for individual TCP connections, if it wants to avoid re-ordering
TCP segments in a single stream that contain data and those that don't.

Please also note that the draft fails to mention by now ancient experience
with some of its advocated changes to TCP, changes that have not been
enthusiastically adopted.  (Yes, I'm once again for the umpteenth time
pointing at the ACK compression mechanisms used on a bunch of well known
cable modem systems with 10 Mbit/sec downstream rates and 10-30 Kbit/sec
upstream rates.)

Vernon Schryver    [email-masked]

---

From: Hari Balakrishnan <[email-masked]>
Date: Wed, 01 Mar 2000 22:07:58 -0500

Dear Vernon,

> ignorant of oddities in the link layer.

And indeed it is.  Making it robust to infrequent ACKs is an all-round win.  No 
one is suggesting any link-specific modification to TCP.

> priority queues is a bad idea, which is not exactly a new discovery.

Gosh, who said anything about interactive traffic!  This happens when you're 
doing bulk traffic in both directions.

The problems are quite relevant to the draft.

> those from (I think) Courier and modems that were sort-of assymetric like

Evidently you decided to do nothing about the problem then, same as now.  :)  
(Sorry, couldn't resist, given your general tone.)

> Some people reflexively resist that argument.

In general, reflexive reactions aren't well-advised in a scientific discipline. 
Furthermore, many of the solutions advocated in the draft are link-layer ones.  
The changes proposed to TCP itself are all ones that DO NOT degrade TCP 
behavior or performance over any other paths, and often, they improve them.

Ergo, I believe they are a good idea; the solutions are not of the form where 
they improve performance in one situation and degrade it in several other 
places.

> just another Informational RFC?  Or is it a call to start some experiments?

Frankly, whether or not the draft exists makes no difference to me personally.  
However, I think that not being aware of some important issues (not merely 
academic ones) that affect TCP performance over some classes of real networks 
is not a good situation.

It isn't a call for more experiments necessarily, although that would be 
welcome.  I assumed it would be informational.  I don't know for sure though, I 
suppose it also depends on the WG chairs.
 
Hari Balakrishnan
http://wind.lcs.mit.edu/~hari/