Subject: Re: ECM last call for draft-balakrishnan-cm-02.txt to Proposed Standard

From: Vern Paxson <[email-masked]>
Date: Sun, 09 Jul 2000 01:22:44 PDT

> > Reminder, the last call closes this Friday, July 7th.  So far there haven't
> > been any comments.  If you've already reviewed it and are satisfied with it,
> > please send me a note to that effect (or post to the list), so I can gauge
> > the degree of support for the document.
> 
> What is under last call-
> 
> 	draft-balakirshnan
> 
> 	draft-ietf-ecm-cm

It's now the second of these (as Hari noted).  But the second is just a
revision of the first, renamed to reflect the fact that it's a WG document
and not an individual submission.  I asked Hari to do this when submitting
a revision incorporating the earlier comments.

> The latter appeared only today; given the differences, if it is the
> latter that is proceeding in the WG, perhaps it would be possible to
> extend the last call a week?

Extending a week runs into the pre-Pittsburgh I-D IETF deadline.  I think
we can extend it until say Tuesday at noon PDT, though, seeing as how
currently no further revisions are needed.

Also, a reminder: as noted above, please send me a note if you've reviewed
it and are satisfied with it, I've heard very little back on this.

		Vern

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Jul 2000 11:48:53 -0700

Some brief comments before last call closes:

Sec 4.2
	ALF != dynamic content
	although ALF can be dynamic and can affect content,
	there are other application dynamic content responses
	that aren't ALF-based

	Is it absolutely necessary that each MTU require a separate
	CM call or callback? This could severely affect performance.

	cm_request should be able to pass a requested number of bytes,
	either an upper bound or an estimate, e.g., for cases where
	the application is NOT sending an MTU. E.g - for realtime apps,
	it would prevent waiting for permission to send a full MTU
	when only a few bytes are being sent. (preferably, this could be
	cm_request(K,size) where K is the number of packets to be sent 
	and size is the max size of each packets, again to allow amortization.

	the downcall (cm_data?) appears to be referred to but not defined in
	the discusion of synchronous calls

As suggested at the BOF earlier, all reasonable parameters should
include variances.
This includes cmapp_update's rate value. Just as RTT includes a
deviation, rate should be an
upper bound or average with some variance as well.

All variance information should have a way to control and read the
averaging interval,
(and possibly to get a token indicating the averaging algorithm). Some
parameters of 
the algorithms (decay rate, averaging window) may need to be in the
interface in the future.

4.3 - application notification

	the use of CM_PERSISTENT and CM_TRANSIENT requires the application to
infer,
	rather than report.

	it would be safer to report explicit issues:

		timeout_loss

		sequence_loss

		reported_loss

	these should be a bit-vector, because there could be combinations of
some kinds
	of loss (e.g., reported sequence loss from the other end, etc.)

	cm_notify should have a MUST to call cm_notify(stream,0) if the app has
no immediate
	data to send. that would make it consistent with the subsequent claim
that the controller
	be robust and fix apps that don't report it correctly (i.e., when the
app has an error).
	I.e., if it's just a should, why is the CM doing cleanup? should the CM
do cleanup at all?
	(It doesn't matter which - but the two appear inconsistent)

4.5 get/set macroflow
	these routines lack an interface to set sharing policy. the entire
mechanism underspecifies
	this property, and currently assumes that streams are shared 1/N. that
is only one choice

	in the second paragraph, destination = destination IP address

Security considerations

	there are quite a few issues to consider, many of which were discussed
in Touch97.
	in particular, the CM opens attacks to siblings of a vulnerable stream
on a single machine,
	or (if macroflows span sets of hosts) across machines.

I would very much like to see some of these issues addressed 
before this protocol goes to proposed standard.

Joe