Current Meeting Report
Slides
Jabber Logs


2.8.23 Triggers for Transport(trigtran) Bof

Current Meeting Report

Triggers for Transports (trigtran) BOF

Wednesday, November 20 at 1300-1500
===================================

CHAIRS: 	Carl Williams <carlw@mcsr-labs.org>
		Spencer Dawkins <sdawkins@cynetanetworks.com>

Notes: 	
Thanks to Karen O'Donoghue 
<odonoghuekf@nswc.navy.mil> 
	for taking notes during the meeting.
Notes were also based on Jabber notes taken by 
	Joseph Ishac <jishac@grc.nasa.gov>
Co-chairs included their own notes as well.

General Discussion: trigtran@ietf.org
To Subscribe: trigtran-request@ietf.org
In Body: subscribe
Archives: 
  
www.ietf.org/mail-archive/working-group
s/trigtran/current/maillist.html

Jabber log available at: 
  
http://www.ietf.org/proceedings/02nov/jabbers/trigtran.html

AGENDA

1. Agenda Bashing				5 minutes
	(Carl and Spencer)

2. Overview of Problem Statement 	20 minutes
	(Spencer and Carl)

3. Perspectives				30 minutes
	(Sally Floyd, Tom Hiller, Dave Meyer)

4. Protocol Considerations 		10 minutes
	(Alper Yegin)	

5. Where might this path lead?	10 minutes
	(James Kempf)

6. Discussion of Goals 			5 minutes

7. Open microphone			25 minutes

8. Assess interest/next steps		15 minutes


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

1. Agenda Bashing				

The agenda was actually bashed - we moved James Kempf in front of 
Discussion of Goals.

We also did "things to remember":

- TRIGTRAN trigger delivery not guaranteed

This is actually a good thing - it accommodates incremental 
deployment scenarios.

- TRIGTRAN triggers are advisory

End-to-end transport mechanisms are still present, and act as a "safety 
net".

- TRIGTRAN isn't L2Triggers

The TRIGTRAN latency goal is to beat RTT-based feedback mechanisms, not to 
accomplish millisecond-sized handoffs.


-----------------------------------------------
2. Overview of Problem Statement

Reading: 
draft-dawkins-trigtran-probstmt-00.txt

John Wroclawski - "end-to-end works fine!" An alternative model is to have 
one endpoint send this information to the other endpoint.

Spencer Dawkins - yes, but at least one of the cases we're talking about is 
the inability for one endpoint to send packets to the other endpoint. At 
least in this case, we still need help.

S.Tavari (SUN)- hard to detect what messages are real/waranted.

Karen (missed last name, sorry)(MIT)- Pricing question: Triggers on how 
pricing may have changed? 

Sullivan - The pricing model may be out of scope as it is likely to be 
applicable past the Transport layer.

John Wroclawski - Separate out adjacent router problem.  Adjacent router 
problem should have higher priority over more general case. Do we plan to 
handle both scenarios? 

Spencer Dawkins - Defer to Alper's presentation. What does that do to 
requirements and solution.

Gab Montenegro - What is the impact of false positives?

Comment made:  Are we going to look at several triggers going to the same 
host, concatenated triggers? 
	
Comment made:  Doesn't see how the triggers would really be used on the 
trigger receiving side. 

John Wroclawski  -   99% of the benefit could be derived from 
notifying the host on the left and letting it talk to the host on the 
right, don't need a protocol. 

John Wroclawski - One end device link not working and then works;  other end 
sleeps - that can be fixed.  Right thing to happen is to get other side 
working.  IETF problem.


-----------------------------------------------
3. Perspectives

- Sally Floyd

Sally reminded us that we need to decide whether we're thinking about 
generic transport, or only TCP. Are there other transports that would find 
TRIGTRAN triggers interesting?

TCPs just can't assume losses aren't congestion without help, and it can't be 
end-to-end help.

Sally suggested modifying MTUs based on errors reported by triggers as one 
non-"link up/link down" use of TRIGTRAN.

Sally pointed out that ECN is an important thing to keep in mind.

Sally pointed out that many of the examples we're talking about are 
classical wireless applications, but they don't have to be - she 
suggested SCTP path switching on multi-homed hosts based on TRIGTRAN 
link-down notifications and talked about BGP4 adjacencies over 
satellite links as an example where knowing that a link is 
temporarily unavailable is useful.

- Trigtran in Application community :  Tom Hiller 

Tom was unable to attend (AAA conflict), but provided a slide on 
feedback from Alan Hameed's presentation of the TRIGTRAN problem 
statement to the Open Mobility Alliance meeting the previous week. Alan's 
report was that there was some interest from this community in having 
TRIGTRAN triggers, but more interest in having transports react to these 
triggers than in having transports provide visibility to these triggers to 
applications, which may then react.

John Wroclawski -  can predict the application community will say "wow, 
it's wonderful", but may be more difficult to get across the cost 

Comment made:  Interested in cases where applications would behave 
differently if this information is available

Allison Mankin - implicitly they already understand that they have a cost. 
Tunnel is an interesting case.  TCP does the right thing when the link goes 
away, it isn't clear that it does the right thing when the link comes 
back.

Sally Floyd - assumption isn't that the good info is valid.  Cost of 
checking good information with a single packet may be worth it. 

- Trigtran in the operational community :  Dave Meyer

Dave was unable to attend (emergency), but provided feedback to Spencer and 
Carl before the BoF on operational aspects of TRIGTRAN. Dave's 
principal concerns were

- per-connection state in a router ("PLEASE, no...")

- essentially unbounded memory requirements - number of connections 
determined by host processing capability, not by link bandwidth

- the need for operators to deploy something they don't get paid to 
deploy


-----------------------------------------------
4. Protocol Considerations

- Alper Yegin

Alper's presentation covered a broader scope than the problem 
statement presentation - including possibilities like explicit 
registration procedures and TRIGTRAN notifications for links that aren't 
first hops. This presentation intimidated Spencer into dropping many of 
these possibilities, which were included in the first version of the 
problem statement draft!
  
Aaron Falk - What happens when your access router changes? Alper - this is 
two events, not just one, but we do need to think about this. And NEMO is 
less straightforward.

James Kempf - Multihop networks really do have errors with minimal 
congestion.

Geoff Huston - What about false positives?

Allison - we're getting pretty deep into the solution space here - too deep 
for a BOF. Could you just highlight the issues from your slides?

Spencer - Carl and I have already benefitted from seeing Alper's 
presentation - we're leaning toward limiting the scope to first-hop 
access routers, for instance.  Let's view the presentation through those 
lenses - look for complexities we don't want to bite off.


-----------------------------------------------
5. Where might this path lead?

- James Kempf

James pointed out that TRIGTRAN sprang from work with L2 triggers and 
handovers on wireless links, allowing for fast handovers coupling L2/L3, and 
fast IP handover at L2 speed, and expressed his opinion that IETF should not 
pursue L2 triggers further as protocol implications are 
questionable

James believes one obstacle is that IETF's architecture does not include 
access points as (more than) IP devices.

James asked how TRIGTRAN routers know where to send triggers, but raised a 
larger issue - what about environments where most of the losses on a 
network are due to transmission errors, and not to congestion?

(Missed name - sorry) - As we move to higher frequency bands, we should 
expect to see more non-congestion losses. My home network has a 
satellite link that hits 10-percent non-congestion losses when clouds are 
over it, and TCP behaves incorrectly in this environment.

James - PHY Guys always talking about providing upper layers more 
information. 
  Transport and sources of packet loss
  TCP, SCTP, and (soon) DCCP assume packet loss is due to congestion

Melinda Shore, Cisco - APs as recognized IP entities - she thinks that 
argument is bogus layer violations create topology problems 

Mike Patton - lots of noncongested loss, transmission loss not 
congestion loss, does notice TCP often doing the wrong thing


-----------------------------------------------
6. Discussion of Goals

-----------------------------------------------
7. Open microphone

Geoff Huston - trying to understand a few basic assumptions, how do you 
tell the difference between false positives, how do you understand the 
impact of false positives on a real congested link

John Wroclawski - Would like to fix "ICMP Encourage", but am concerned that 
we immediately fall off a cliff.  We're changing the way the Internet 
works. This isn't a single IETF working group, and is probably IRTF work.  
And please don't start with explicit triggers!

Sally Floyd - for "link up" notification, it may be sufficient to notify one 
end, and let one end notify the other end. There's nothing that we're 
discussing that would lead to congestive collapse.

(sorry, I missed the name, from Microsoft) - what about explicit 
guidance on window size?

Pat Thaler - concerned that routers and switches don't have the kind of 
information we're thinking they can provide. CRC errors are a special 
problem, because you can't trust the address/port information, to know 
who's affected.

Spencer Dawkins - there are situations where this is true, but cellular 
systems, for instance, may know who is affected based on link 
information and be able to correlate. But it's a good point, and we need to 
keep it in mind.

Randall Stewart, the SCTP guy - "link up" is very relevant, 
especially in multipath, as well as "link down". The case for link 
bandwidth changes is less clear. 

Randall Stewart, back to his day job - concerned that we are thinking 
about too much state and too much processing in "the middle of the 
network".

Andrew - Multihop wireless links are slow, compared to memory.  Could 
TRIGTRAN be stateless?

John Wroclawski - Queuing packers IS a trigger! And this is source quench 
all over again - routers can't send it to the right place. We've failed at 
this before, with Path-MTU discovery.  John also noted that TCP doesn't do 
what you want, but that can be fixed.  

Richard Nelson - Not convinced - wireless APs need to be cheap.

Ted Hardie - John and James are both right. Reality has changed.  Links 
aren't wires. Since reality has changed, what new questions should we be 
asking?

Carl Williams stated that there was some low hanging fruit and ask BOF 
members to come to the microphone for the final 10 minutes to discuss what 
work can be engineered now.

Sally Floyd - One last statement in support of "link up"/"link down".  Is 
the limitation to first-hop necessary for us to have low-hanging fruit? 
Sending old packets as implicit triggers assumes that the packet's 
content is interesting, as well as the trigger.  It may be, but it may not be 
so.

Gab Montenegro - Limiting to first-hop router - does this help with 
security/authentication?

Samita Chakabarti - Noted that we should explore more how TRIGTRAN will 
help other transports (SCTP, UDP, etc...).


-----------------------------------------------
8. Assess interest/next steps

Allison Mankin expressed satisfaction with the discussion at this BOF, and 
asked that a follow-on document be published to capture the comments and 
questions (she didn't say this, but "and answers").

We'll continue to work on the "low-hanging fruit" on the TRIGTRAN 
mailing list (if we can't do "link up"/"link down", we can't do 
anything useful).

Slides

Agenda
Wireless Transport Issues and OMA
Triggers for Transport: a transport view
TRIGTRAN Futures?
TRIGTRAN Protocol Considerations
TRIGTRAN Problem Statement