Subject: Re: SCTP congestion control questions

From: Mark Allman <[email-masked]>
Date: Tue, 06 Feb 2001 13:43:34 -0500

> The root cause is that bursting is the result of implementation
> decisions that are not otherwise prohibited by the protocol.

Right.  Why not fix these bad decisions?  (Yes, there is a good
chance this is simply philosophical).

allman

---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Feb 2001 10:46:52 -0800

> chance this is simply philosophical).

Depends on what is 'wrong'.

If it is the behavior that is wrong (bursting), then 
fix the behavior (burst limit).

I'm not clear there is a fundamental reason behind
causing a burst; it's a symptom, and it seems 
appropriate to treat the symptom.

Otherwise we're back-tracking 'intent' - anything that _might_
result in an implementation that _might_ end up bursting is
deemed 'wrong'.

Sometimes cold medicine is exactly what you want.

Joe

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 06 Feb 2001 15:25:26 -0600

Mark/Joe:

One thing to remember on this "burst" is the
fact that this all supposedly occurs (if I remember
right from reading Rob's work... Rob help my
feeble overloaded mind here :->) .. is it
occurs in one RTT. So, thinking on it, none
of the reductions  may have taken place.. but of
course you would have to have a very strange occurance
in that 

A) The application would not have more data to clock
   out (as you point out Mark).

and

B) Just has the FR's ACK arrives the application would
   have to have this "Burst" of new data. 

These two things seem to me to be unlikely but I don't
see how other than by having a maxBurst you can gate
this strange behavior....

And I am sorry Joe, I have not read your draft :< I have
pulled it down.. but alas  I fear it will be a while before
I can spare the cycles ...

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Feb 2001 13:48:33 -0800

> this strange behavior....

FWIW, maxburst limits per-event - which means a 
bad implementation can have the application keep
doing send calls, each of which can burst.

The idea of BOL was to gate the behavior with more
of a leaky-bucket - refilled when an ACK arrives, 
and drained when packets are sent. 

There are subtle differences, but they
are basically similar in how they gate things,
and both are proactive, not reactive.

Joe