Subject: [Trigtran] DRAFT TRIGTRAN Minutes from IETF 55

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 4 Dec 2002 17:06:59 -0600

Hi, all,

We need to finalize our minutes for submission to the 
proceedings - we're still catching up with Karen, so our
notes may "grow" a bit. But here's what we have so far.

Please let us know if you have corrections or comments, and
clues about names and correct spellings are ALWAYS
appreciated.

Thanks,

Spencer, for Spencer and Carl

Triggers for Transports (trigtran) BOF

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

CHAIRS: 	Carl Williams <[email-masked]>
		Spencer Dawkins <[email-masked]>

Notes: 	
Thanks to Karen O'Donoghue for taking notes during the meeting.
Notes were also based on Jabber scribe and those taken by "Joseph".

Co-chairs put together the notes below based on Karen and 
Joseph notes as well as their own notes.

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: subscribe
Archives: www.ietf.org/mail-archive/working-groups/trigtran/current/maillist.html

Jabber log available at: (insert URL here)

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 RTTs, 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 - Perspective problem adjacent and layer problem.
  Separately where we are headed.

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

Gab Montenegro -  Tell difference between false positives.  
  What is the impact of false positives.

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.

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

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

-----------------------------------------------
6. Discussion of Goals
-----------------------------------------------
7. Open microphone

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

_______________________________________________
Trigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran