Subject: POS flow control: draft-tsenevir-ppp-flow-00.txt

From: James Carlson <[email-masked]>
Date: Mon, 30 Apr 2001 17:14:44 -0400 (EDT)

Has anyone else looked at this individual submission?

It is defining new LCP options to negotiate a SONET-and-802.3x
specific flow control mechanism for PPP, plus a new control protocol
to actually signal flow control.

This doesn't sound like a good thing to me.  Implementations are
typically expected to buffer as much as practical for expected bursts
(250ms+, usually), and to drop otherwise.  Adding flow control in here
makes a bad situation worse -- it pushes the buffering back into the
network rather than in the hosts where it belongs, and presents TCP
with more delay variance.  It sounds like the result of a
misunderstanding of how IP-based congestion control works.

Is it possible that the original authors just need bigger buffers
and/or RED?

I know it's not a working group draft, but ...

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 30 Apr 2001 17:08:53 -0600 (MDT)

> From: James Carlson <[email-masked]>
> To: pppext <[email-masked]>
> Cc: [email-masked], [email-masked]

> Has anyone else looked at this individual submission?

yes, from the title and before reading it, I guessed it might be
another aspect of the strange world of SONET.

> Is it possible that the original authors just need bigger buffers

Yes, contrary to the thesis of the Internet Draft, dropping packets is a
good thing and putting a flow controlling protocol such as TCP above a
second flow controlling protocol like x.25 or this SONET proposal is a
quite bad thing except in some special cases.
The problem is that there is no way for link layer flow control to signal
the real source of data, the distant TCP state machine.  If one end of
a link adds buffers, then the distant TCP state machine is supposed to
put more data in flight and fill up the extra buffers.  This desirable
process is described in many textbooks and now in in various RFC's.

The bad things that happen with too-smart-by-half link layers are evident
if you run TCP/IP/PPP/{rlogin,telnet}/TCP/IP (say for testing).

Similar bad things happen with necessarily smart link layers such as
TCP/IP/wireless-modems, where the wireless links do retransmissions.
There are Internet Drafts that discuss these issues in
http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.txt and
http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-05.txt
While the focus of those drafts is on very low speeds, the issues are
not related to speed itself.

The flow control in 802.3 networks referred to in the proposal
involve another special case, and generally involve protocols other
than TCP/IP and sometimes misunderstanding by link layer designers
of overall network issues.

> I know it's not a working group draft, but ...

Doesn't the IESG supposed to listen to the relevant WGs when it comes
to publishing a draft as an RFC?  The danger with this draft is that
unlike others, it is seems reasonable and plausible if you don't know
about TCP versus smart link layers.

Speaking of other kinds of I-D's, was I specially blessed by recently
receiving a missive informing me personally and others of an unspecifed
group that we "have the foundation for enumeration in the Binary System
wrong" and that "the Foundation of the entire Mathematical Field is
wrong too" and containing an encrypted (as a base64 .zip file) copy
of an expired draft?

Vernon Schryver    [email-masked]