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

[Gorry Fairhurst <[e-mail]>]

Lars Eggert wrote:
> Hi,
> 
> On Jul 29, 2006, at 3:23, Joe Touch wrote:
> 
>> Right. I like the idea of "only give info that you think the next  layer
>> can use", but not "tell the next layer what you want it to do". Also,
>> the information passed ought to be something that makes sense in the
>> context of the next layer, e.g., tell the network layer about a path
>> property, not about a link technology, etc.
> 
> 
> this is probably one of the most precise - and concise - descriptions  
> of the idea we've been kicking around I've see so far.
> 
> Also, we've so far mostly thought about the network/transport  interface 
> and what additional information could be passed across it  that would 
> allow some new response mechanisms at the transport layer  to improve 
> performance. However, the principle of extending  interfaces in this way 
> - as you've summarized above - can also be  applied to the link/network 
> and transport/application interface. The  link/network part is to some 
> degree looked at by mobopts (although  maybe not following the approach 
> identified above). I'm unaware of  extensions to the transport/app 
> interface.
> 
> Finally, this discussion has mostly talked about moving information  of 
> a certain kind up the stack in a certain way. Someone (Mark  Handley?) 
> had pointed out that the reverse direction may also be  important to 
> look at. Your text above can be read to apply to both  directions, which 
> is nice.
> 
> Lars

I'm still not yet convinced we understand exactly what the TRANSPORT can 
usefully utilise, and which it can rely upon to make safe decisions.

* One issue that came up time and again in the previuous BoFs - how does 
the tranport entity KNOW the signal is from a node on the path, and how 
much do you wish to continue the idea of "fate-sharing" and "alternate 
paths" - in which it's hard to know if link characteristics really 
impact flows.

* If you know that some of the packets in the flow have been through the 
device, do you trust it? There's DOS opportunities here, and also issues 
of trust between ISPs and Core providers.

* Finally, in the TrigTran BoFs, I also recall some discussion of 
time-scales, what seems like a "timely" event at the physical layer, may 
not be of interest to the transport layer (working on a timescale of 
several Path RTTs).


I and others have said these sorts of things several times (sorry), and 
it would be really good to capture exactly which signals are 
trust-worthy and useful to a transport entity.

In the other direction: What are the things the transport enities could 
tell the link/phy? and how will it know to use these? WE already have 
QoS and QS/XCP type signals, what are the additional features desired?

I think if we understand the usefulness, we can make progress. One 
example of "something that changed" is advice that the link RTT is large 
(or has just become large) could be  useful. For this, it's wise to make 
transport protocols that don't rely on exact timing (which is good 
practice and we're doing this), so simply bumping up the stored RTT 
seems plausible (and then letting the transport reprobe to confirm 
this). I think Mark (?) queried whether we need to be exact about what 
changed has... could it be that any path change would sensibly lead to 
the same sort of re-probe to confirm RTT, MTU, etc?

Gorry