Triggers for Transports (trigtran) BOF Wednesday, November 20 at 1300-1500 =================================== CHAIRS: Carl Williams Spencer Dawkins Notes: Thanks to Karen O'Donoghue for taking notes during the meeting. Notes were also based on Jabber notes taken by Joseph Ishac 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-groups/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).