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

["Spencer Dawkins" <[e-mail]>]

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

Yes, concerns about security morphed TRIGTRAN into ALIAS, IIRC. This was one 
of the reasons why TRIGTRAN concentrated on first-hop link changes - TTL=254 
made it a lot harder to spoof anything there.

One other security-related point I remember from TRIGTRAN - if you assume 
paths with NATs/FWs are interesting, you have to make a decision about 
whether you use a new protocol for signaling, or hack around using the old 
protocol (knowing that you can get the old protocol through the NAT/FW, so 
reusing a TCP segment as a hint would get you through the NAT/FW, too). At 
this point, I'm assuming TERNLI is willing to consider a new protocol.

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

Yes, IIRC, this was a Mark Allman point (shared by others) - reacting five 
times during one RTT probably isn't helpful. Of course, if you want to do 
better than what TCP would have done anyway, you have a small number of RTTs 
to achieve what you're trying to achieve, and if you don't achieve it by 
that small number of RTTs, you would have done better to let TCP figure the 
situation out end-to-end.

> 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