Re: [TERNLI] Notes from tonight's ad hoc

[Michael Welzl <[e-mail]>]

> On Fri, Jul 28, 2006 at 08:56:08AM -0400, Mark Allman wrote:
> >
> > I guess I see the signals as either ...
> >
> >   + Giving the transport something it can directly use.  E.g., the
> >     available bandwidth just increased from 2Mbps to 11Mbps.  E.g.,
> >     the flow experienced congestion.  E.g., some probability of the
> >     fraction of losses due to corruption.
> >
> >     These are different from less-directly-useful information like
> >     "switched to a new AP" or "am now using a different coding /
> >     modulation scheme" which are much less directly applicable.
> >
> >   + Giving a generic signal that *something* has changed and it likely
> >     matters and so the transport should re-init itself (e.g., forget the
> >     SRTT, RTTVAR, cwnd, ssthresh, MTU value, etc.).
>
> Is it possible to generalize this to say that signals should either
> carry specific actionable information or request specific types of
> actions?
>
> This means:
> "Modulation changed" is a bad signal to implement.
>
> "Available capacity changed from X to Y, please probe" is a good signal
> to implement, and could be generated in response to a change in
> modulation or any number of other things.
>
> "Registering a new Mobile IP CoA" is a bad signal to implement.
>
> "Please reprobe path state" is a good signal to implement, and could be
> generated in response to a MIP CoA update or several other events from
> mobility or multihoming mechanisms.

I think this is still going in the right direction, but
I would omit the action semantics (like "please reprobe") -
one reason is that we shouldn't restrict future protocol
designers to (thinking of) just this type of action because
the message says so. Another reason is implicitly embedded
in one of the examples you've given: "Available capacity
changed from X to Y, please probe".

A congestion control mechanism always probes - telling
it to probe therefore doesn't make a lot of sense. Right
now, TCP doesn't have/utilize capacity information - but
other congestion control mechanisms have shown that this
type of information can be useful. In any case, if we'd
decide to include capacity notifications, we wouldn't have
a good idea regarding the specific action to recommend.
Thus, it's better to leave it open.

The reason why I said that this is going in the right
direction is that the information should indeed lead to
some kind of action at the transport layer, so thinking
of possible actions is probably the right way to come
up with a useful data set for the messages. And you're
absolutely right about the bad examples ("modulation changed" etc).

Cheers,
Michael