Subject: Re: PILC ASYM document

From: Sally Floyd <[email-masked]>
Date: Mon, 13 Mar 2000 22:11:34 -0800

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

Yes, I agree completely about the need for the ASYM document.  I
think the fact that TCP currently lacks congestion control for
traffic on the return path (for the case where the TCP flow's
traffic on the return path consists only of ACK packets) is a
significant weakness that happens to manifest particularly strongly
in the case of asymmetric links.  It seems to me that adding some
form of congestion control for this return-path traffic will at
some point become necessary.  I don't view congestion control for
ACK traffic as contorting TCP to accomodate the oddities of some
defective link layer.  I view it as addressing a fundamental
requirement of the transport protocol to have effective end-to-end
congestion control, as much as possible, for all of its traffic.

- Sally
--------------------------------
http://www.aciri.org/floyd/
--------------------------------

---

From: Cannara <[email-masked]>
Date: Mon, 13 Mar 2000 23:00:51 -0800

In general, we should not take a single transport protocol (TCP or any other)
out of any family of protocols that carry data, and give it the responsibility
of network "congestion control".  This was done historically because TCP was
dominant in the old Internet and so it could be used to effectively help
routers with their queueing, when it was apparent proper network-layer design
for high loads hadn't been done.  Today, the mix of traffic continues to
change in ways that increasingly expose this bandaid.  Addressing the real
problem at the network layer will be the key, as others have suggested.  

Imagining that TCP has an obligation and capability to control congestion
remains an engineering mistake.  The TCPs people actually use and see
operational every day are extremely inefficient, in comparison with what could
legitimately expect of the years of effort that went into its various
algorithimic components.  Part of this inefficiency is certainly laid to
default parameter settings (timeouts, etc.).  However, the fundamental flaw in
the logic is that TCP has insufficient information to make proper decisions
and is hampered further by provider policies on packet delivery.  The network
layer will need to manage its queues and drops and provide help to higher
layers, not depend on them.  Fortunately, the problems with TCP/IP's current
interwining become extremely evident on the kinds of links discussed here. 
That should be our impetus to deal with the problems effectively rather than
bureaucratically.

Alex