Subject: RE: PILC ASYM document

From: Venkat Padmanabhan <[email-masked]>
Date: Thu, 2 Mar 2000 16:29:55 -0800

> >    (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.

Unless there are aspects of TCP that interact poorly with the
link's characteristics. Media access asymmetry is often a fundamental
artifact of the hub-and-spokes configuration of the network. It is
often a lot less expensive for the hub (e.g., a wireless base station 
or cable modem head-end equipment) to transmit packets to the (distributed)
end-stations than it is for the latter to transmit to the hub (due to
contention). In the context of a downstream TCP data transfer (i.e.,
in the direction from the hub to an end-station), this characteristic
of the link would make the transmission of ack packets by the end-station
expensive, regardless of the size of those packets.

Hari and I have observed this problem via simulations and actual
measurements of a packet radio network. (See sections 5 and 7.2 of
http://www.research.microsoft.com/~padmanab/papers/monet99-tcpasym.ps.gz).
We also have anecdotal evidence of similar problems in cable modem
systems. We were hoping to hear experiences of other people confirming
or refuting this. Barbed emails heavy in sarcasm unfortunately drown
out whatever technical point was sought to be conveyed.

Regarding your implication that TCP should be ignorant of the oddities
of the link layer, an analogy might illustrate why this argument isn't
necessarily right. HTTP/1.0 (an application-level protocol) ignored 
artifacts of the underlying TCP transport protocol (e.g., slow start)
and opened a new TCP connection for each request. Consequently, performance
suffered.

> 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.

I would second your remark about the 128 Kbps link, but I don't see
why it is relevant. No one is claiming that a 128 Kbps link could/should
be driven faster than 128 Kbps. The point is that congestion on the
128 Kbps uplink resulted in poor utilization of the 1.5 Mbps downlink.

> 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.

What we are talking about of here is not "mixtures of interactive
and bulk traffic". Rather it is the interference between the acks of
a downstream bulk transfer with data packets of an upstream bulk transfer.  

> 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.

I have no idea what Telebits is, but regardless we are not arguing 
that the upper layers must be modified for every new link layer.
Rather we have attempted to document a set of problems related to
asymmetry and an approach to addressing these that has a common 
thread: reducing the frequency of acks -- a generalization of
delayed acks, if you will -- and making the sender robust against
disruptions in the ack stream. These have been derived from our
experience/experiments with a few network technologies. Whether to 
turn any of this into a proposed standard would depend on whether 
there is a consensus on their relevance in a wider setting 

> 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?
> 

Good question. As Aaron states, the PILC WG's current charter precludes
turning this into a proposed standard (of course, I realize that this
technicality is not the only hurdle in the way!). If there is sufficient
consensus and supplementary/supporting evidence (e.g., experiences with
other network technologies), then (parts of) the document can
be turned into a BCP. If not, I guess it will be an Informational RFC.

Venkat Padmanabhan
Microsoft Research
[email-masked]
http://www.research.microsoft.com/~padmanab

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 3 Mar 2000 09:55:55 +0000 (GMT)

> and opened a new TCP connection for each request. Consequently, performance

That analogy is misleading.

HTTP _always_ runs over TCP, so there are widespread gains from
optimising interaction between the two. It's a global (a World-Wide,
even) optimisation with few tradeoffs.

TCP does not always run over e.g. some braindead ARQ-to-infinity link
layer. Optimising TCP for such a special case would prove detrimental
to interactions with other, different, link layers. It's a local
optimisation with many tradeoffs.

Making TCP independent of link layer oddities strives for the general
case of global optimisation. Vernon is correct.

L.

the Internet: increasingly a bunch of isolated local optimisations
with undesirable global interactions.

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

---

From: Dr G Fairhurst <[email-masked]>
Date: Fri, 03 Mar 2000 10:31:40 +0100

The well proven approach taken by Sally Floyd, et al (just using the name
quoted
on the list, no offence to Sally) is a good one for some problems.  But it
does not
always work.  The problem with PILC as a whole is that the issues being
discussed
are (as Phil Karn put it) from two different communities. The two need to talk
to
each other in moderate tones of voice, so that we understand what TCP is
actually
asking for. I disagree that TCP "works well" over all links.  If you define
"well" as
meaning doesn't fail to delivery (eventually) then that's OK, but normally
that's
not my thinking.  TCP is end-to-end, but link designers need to take on board
what is really happening.  Once the subnet designers document is clear, I
suggest
we will probably see the need for the ASYM document.

I'd like to see the ASYM draft opened up a little in terms of discussing
different
approaches... and getting a clearer problem statement, then input from the
cable
people, radio people, the DVB people, and anyone else.  My concern is, until
we get the first ID into some shape, we attract a lot of confusing comments
every
time something is mentioned (this isn't new/ this isn't needed/etc).

I recommend we keep the document as an ID and wait for the SUBNET DESIGNERS
draft to reach stability first (next draft?), then look discuss the approaches
in detail at Pittsburgh....

Gorry Fairhurst.

---

From: mukul goyal <[email-masked]>
Date: Fri, 3 Mar 2000 09:57:31 -0500 (EST)

> optimisation with many tradeoffs.

Lloyd, could you clarify this further? I think that draft talks about
ideas like restricting the number of packets sent in a burst and making
sure that window increase is independent of number of ACKs received. I
think it will be a _global_ optimization and not a _local_ one. I might be
missing something but can you provide some example scenarios where such a
thing will not be good.
  
> case of global optimisation. Vernon is correct.

I thought that's what draft talking about: making TCP independent of link
layer oddities.

Mukul

---

From: Cannara <[email-masked]>
Date: Fri, 03 Mar 2000 10:03:05 -0800

Good points Gorry.  We need to enter this millennium with a little less
bureaucratic defensiveness about the "existence proof" that is the current
Internet protocol/infrastructure.  Passing over its security pit, if we look
at TCP, in particular and in the light of day, we see a 'transport' that is
incapable of distinguishing important, performance-degrading effects.  For
instance, its response to packet loss being identical whether the packet was
errored or congested out of existence causes real, costly delays.  These
events increase as it is run more often over media for which it was never
designed.  The increasing dependence of real business, rather than subsidized
research, on the Internet is already revealing how influential the $ side of
the equation is becoming.  Engineering should follow this lead.

Alex

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 3 Mar 2000 19:08:44 +0000 (GMT)

Restoring cut text here. Venkat wrote:

| Regarding your implication that TCP should be ignorant of the oddities
| of the link layer, an analogy might illustrate why this argument isn't
| necessarily right. HTTP/1.0 (an application-level protocol) ignored 
| artifacts of the underlying TCP transport protocol (e.g., slow start)
| and opened a new TCP connection for each request. Consequently, performance
| suffered.

I responded: 
$ That analogy is misleading.
$
$ HTTP _always_ runs over TCP, so there are widespread gains from
$ optimising interaction between the two. It's a global (a World-Wide,
$ even) optimisation with few tradeoffs.

On Fri, 3 Mar 2000, mukul goyal wrote:
                          
> Lloyd, could you clarify this further? 

My comments are purely a response to Venkat's comments, and should not
be construed as comments on the contents of the draft.

> I thought that's what draft talking about: making TCP independent of link

what the draft and the list talk about can be very separate things.

L.