[e2e] a few questions on TCP mechanism

Zaphod Beeblebrox label_label_label_label at yahoo.com
Wed Sep 15 01:18:03 PDT 2004

--- Lloyd Wood <l.wood at eim.surrey.ac.uk> wrote:

> On Mon, 13 Sep 2004, Craig Partridge wrote:
> > Someone wishing to be anonymous wrote:
> > >b. If the only source of feedback is the
> destination
> > >point, how is it possible for me to:
> > >1. adjust my window size in T < RTT
> >
> > In general, you shouldn't.  As I understand
> control theory, if you adjust
> > in times smaller than the RTT, your control loop
> is unstable.
> [Looks up from paging through Kuo's Automatic
> Control Systems, 5th Ed.]
> As I understand control theory, if you adjust in
> times smaller than
> the RTT, you're simply overdamping. That is not
> quite the same thing
> as having an unstable control loop where damping is
> negative overall.

If one defines unstablity as the equivalent of a
"pole"/infinite oscillation condition, this is correct
I guess.

However I am not too sure what classifies the system
as  over/under or critcally damped

     |          |

O(z)=I(z).H(z)/(1+G(z)H(z)) and all relevant equations
are valid if it was a node by node window and not an
end to end window. 
It is very easy to come to an equation of critical
damping for the above.

Can you tell me what exactly makes you say that this
is an overdamped system if T<RTT ?

As I understand, an overdamped system would be
classified by simply looking at the roots of the
denominator in the above equation and their complex
and real parameters.

The other way to see the problem is that if the window
size shoots up in some single intermediate packet/RTT
drops etc, you are underdamping?? So how do you know
which way it is going?

Simply given the fact that the feedback comes in
T<avg(RTT ) is in no way relevant to the convergence
parameters of the system. Correct?

As I said, in all cases the window is end to end, so
yes the above diagram may not be valid for TCP flows.

> Oversampling and input to a control system to do
> overdamping is not in
> itself a bad thing. But the math does seem to be a
> little bit more
> involved than the arithmetic done at discrete
> arrival events by TCP
> endpoints, and proving stability becomes a little
> harder.
I agree, RTT may vary, an ACK may drop etc, Is this
what you are trying to convey?

Do you Yahoo!?
Declare Yourself - Register online to vote today!

More information about the end2end-interest mailing list