Subject: Re: ECM WG last call for draft-floyd-cong-01.txt as BCP

From: Vern Paxson <[email-masked]>
Date: Sat, 11 Mar 2000 17:55:18 PST

>    The document looks just fine, but I don't see how we can call it a BCP.
> It really doesn't describe any "practice".

Seems to me in fact it does: the practice is that transport protocols
must include congestion control.  Compare with the recent ingress filtering
BCP, directed broadcasts (RFC 2644), or how to enhance TCP for satellites
(RFC 2488).

>    BCPs, in my experience, have been a temporary terminal point: we
> know a problem exists; we don't feel any progress is imminent; and
> we want to publish how we deal with it, because that way seems "good
> enough".

I view them differently - they are closer to statements of current IETF
policies & recommendations.  The "current" is because policy/recommendations
can change, not because we don't expect things to change any time soon.

I've cc'd Scott Bradner, as ECM AD, and also author of RFC 2026 (which
defines BCP) for his hit on this.

		Vern

---

From: Paul Krumviede <[email-masked]>
Date: Sun, 12 Mar 2000 09:03:18 -0800

--On Saturday, 11 March, 2000 17:55 -0800 Vern Paxson <[email-masked]> 
wrote:

>>    The document looks just fine, but I don't see how we can call it a
>>    BCP. It really doesn't describe any "practice".
>
> must include congestion control.

Perhaps this statement should be made more explicit? The closest
I see is "the continued use of end-to-end congestion control by best-effort
traffic is critical for maintaining the stability of the Internet."

There have been occasional arguments that certain applications need
new transport protocols, and some of these discussions have featured
claims that they will be for low traffic volume applications, and thus 
don't
need congestion control (e.g. RADIUS). A more explicit statement,
along the lines of Vern's statement above, might be desirable if we are
making a statement about practices.

-paul