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

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 13 Dec 2002 17:07:53 -0600

At the IETF 55 TRIGTRAN BoF, Allison Mankin asked us to put 
together a document based on the BoF conversations. 
We would like to do this as a "next steps" document.

The following is our proposed outline for such a document. 

We are looking for 

- comments on the outline (throw this in, throw that out)

- volunteers to contribute text (think in terms of a few paragraphs)

Please send comments and text to the TRIGTRAN mailing list.

Thanks!

Spencer, for Spencer and Carl

-----------------------------

Problem Re-statement 
	with smaller, first-hop-only scope, as we presented in Atlanta
	Position as protocol definition follow-on to PILC BCPs 
	(PILC being the best that can be done without protocol changes)

Justifications
	Long RTT (painful end-to-end)
	Errors versus Congestion
	Unreachability versus Unavailability
	Interface state changes versus RTO events

Why TRIGTRAN is Different
	From Source Quench
	From P-MTU Discovery
	From Explicit Congestion Notification

Trigtran Applications
	SIP/SIMPLE/Jabber over wireless (out of coverage)
	TCP over wireless (out of coverage)
	TCP over wireless (link errors)
	SCTP multi-path hosts (link down)
	BGP4 over satellite link adjacencies (link down)

Low-hanging Fruit
	Link Up
	Link Down

Possible Trigger Responses (choice of response depends on trigger)
	Reduce congestion window
	Don't reduce congestion window
	Slow Start
	Congestion Avoidance
	Reduce advertised window
	Reduce MTU/MSS size
	Notify applications

Protocol Considerations
	TRIGTRAN Router Discovery
	Requesting triggers
	Delivering triggers
	Explicit versus Implicit Signaling
	False Positives

High-hanging Fruit
	Path change (generic "handoff")
	Link bandwidth change
	Loss due to verified link error

Major Challenges
	Per-connection router state
	Explicit triggers through firewalls, NATs

Reasons to Deploy

Security
	Threat Models
	Trust Relationships
	Available mechanisms
_______________________________________________
Trigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 17 Dec 2002 10:55:34 +0200

Hi,

> 	Link Down

Inspired by the earlier discussions on this list, what would you think 
of having some kind of "Link State Change" as a possible candidate 
trigger? This could be a hand-off, significant change in available 
bandwidth, or something else. These cases were listed as "high-hanging 
fruits", but I was thinking of something more general. This could just 
be an advise for the TCP sender to re-establish its congestion control 
state. In addition, there could be some hints about how to set ssthresh.

Of course, as it was stated, there are a number of potential problems 
with firewalls, malicious hosts, possibly synchronized slow start 
effects, etc., but I'd like to think they are solvable, assuming that 
this would be an optional add-on mechanism to the existing protocols.

- Pasi