Re: [Trigtran] TRIGTRAN Nextsteps ("let the games begin")

I'd like to understand what can go wrong with these signals,
and therefore what constraints we need to introduce.

I would like to see a "threat" analysis that looks at the 
implications of "Forged, malicious trigtran reports"
and also "erronous" reports taht do not reflect actual
path status. 

Here's some first thoughts:

Perhaps we could look at how these sort of things impact:

	1) The network path from the reporting device to end host.
	i.e., the signalling cost itself.

	2) The impact on the recipient - of retransmission, cwnd
	management, etc.

	3) The rate/burst characteristics of the traffic on the 
	network path from the sending end-host that arises
	after trigtran processing.

It could be useful to look at scenarios which produce 
confusing indications:

	1) Alternate paths - one reporting, one not....

	2) Effect of two reporting devicec, with differing path 
     delay (possibly on the same path?) ...

	etc.

Any ideas???

Gorry Fairhurst

Sally Floyd wrote:
> 
> Spencer -
> 
> (Getting to things a little late...)
> 
> Here are a few things to add to the outline...
> 
> >Possible Trigger Responses (choice of response depends on trigger)
> ...
> >       Slow Start
>         (Modify the slow-start threshold ssthresh.)
>         Sending a trial packet, without waiting for the retransmit timer to
>            expire.
> 
> ...
> >Major Challenges
> ...
>         Forged, malicious trigtran reports.
> 
> - Sally
> _______________________________________________
> Trigtran mailing list
> Trigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/trigtran
_______________________________________________
Trigtran mailing list
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran