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