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

[Joe Touch <[e-mail]>]

Michael Welzl wrote:
>> 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.

Is the network giving this to the transport, or the link? The former
seems OK, but the latter not (direct link-transport was - I thought -
the thing that this effort would try to avoid).

>>>     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.

It's useful to the network layer, but irrelevant to the transport.
Modulation is a link property, not a path one.

>> "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.

Requesting a reprobe is telling the network layer what to do, and
implies that the link knows what the network wants. It seems more useful
to say "link state changed" and let the network decide whether it cares
about that on a path level.

...
> 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, 

or the network layer (or is that out of scope - sorry, I wasn't a the
meeting, so I don't have that 'state').

> so thinking
> of possible actions is probably the right way to come
> up with a useful data set for the messages.

Agreed, but 'just the facts' is the right way to report those messages.
I agree that it's useful to avoid making actionable recommendations, but
definitely useful to consider them as motivation.

IMO, the most interesting question is "why are you saying this", and "is
this the right information to pass between these two layers". The
network can't care that the modulation changed (that's a link/physical
issue), but it can care about what that means (latency changed, error
rate changed, etc.).

Joe


Joe