Spencer, for Spencer and Carl ------------------------------------ Triggers for Transport BOF (trigtran) Thursday, March 20 at 0900-1130 =============================== CHAIRS: Carl Williams <carlw@mcsr-labs.org> Spencer Dawkins <spencer_dawkins@yahoo.com> Thanks to our minutes-takers: Kevin Fall <kevin.fall@intel.com> Tom Hiller <tomhiller@lucent.com> Revisionism - Carl and Spencer were experimenting with the terms "connectivity interrupted" and "connectivity restored" in the framework draft and in the BoF, because "link down" and "link up" didn't map cleanly onto multi-hop subnetwork technologies, but we're going back to "link down" and "link up" as "clear enough" - and these terms will be used in the BoF minutes. BoF Coordinates: 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 BOF agenda and description: http://www.ietf.org/ietf/03mar/trigtran.txt Final Agenda: - Introductions, Scribes, Jabber Scribes, Agenda-Bashing - Status Update and Strawperson Statement of Work - Issues identified in Framework draft - Questions leading to a WG charter - Next Steps to a TRIGTRAN working group? Status Update and Strawperson Statement of Work ----------------------------------------------- There are two current Internet-Drafts produced by Carl and Spencer as straw-person proposals on a problem statement and a framework. These drafts are draft-dawkins-trigtran-framework-00.txt draft-dawkins-trigtran-probstmt-01.txt This BoF is a "second BoF". The first TRIGTRAN BoF was held at IETF 55, and focused on the problem statement; this BoF focused on what we learned from doing a framework proposal and on next steps to chartering TRIGTRAN as a working group. Spencer made the canonical TRIGTRAN disclaimers: - TRIGTRAN isn't L2 triggers - TRIGTRAN trigger delivery not guaranteed - No notification ACKs; partial deployment scenarios The framework draft considers 3 canonical triggers: - Link up - Link down - Packet Discarded by subnetwork, not due to connection "Link Up" seems easier in the short term. There is some previous thinking on it: see Phil Karn's posting on "Kicking TCP" on PILC list 3/2000m available at URL: http://pilc.lerc.nasa.gov/pilc/list/archive/0691.html As for "Link Down", this notification "should" make sense. It does make sense intuitively. The problem is that the response might be application-specific - some TCP senders might wait longer to close a TCP connection, while others might give up sooner. Is there a canonical response? We need to understand the applications better before we can posit how to respond to this notification. As for "Packet Discarded", we've realized that in a cellular environment this notification may result from a handoff - if so, the TCP sender would already have received a Link Up indication from the TCP receiver over its new connection path. Conceptually, a TCP sender should slow-start when path bandwidth changes, but if the mobile has merely moved from a lightly loaded cell to another lightly loaded cell, TCP could just continue in its current state without going to slow start. The new cell is as likely to be less congested as it is likely to be more congested, so ignoring the handoff, as TCPs do today, is still a reasonable strategy. Would telling the transport really help? Spencer summarized a private conversation with Mark Allman as, "Gee, maybe TCP does pretty well often times on its own. You may be able to find cases where you could do better with notifications, but by the time you make sure the response to a notification doesn't have undesirable side effects in other cases, TCP doesn't look so bad" Co-chair summary Link Up seems ready for prime-time, Link Down may be in the near future; Packet Discarded seems less ready. Spencer (and Carl) proposed a strawperson Statement of Work: - spin up working group and do 'link up' Specify response for dup pkts during RTO Safe, good consensus - investigate 'link down' semantics What should transport do here? - investigate explicit mechanisms Can we send OOB signals in the Internet in 2005? - build consensus on wish list for IAB/IRTF investigation? Horizontal handoff, non-congestion loss, corruption Send wish list to Leslie and Vern and ask for help (this is something mobileIP and others are doing) -- Q and A -- Sally Floyd: terminology: why "connectivity restored" vs "link up"? One link up might not have anything to do w/e2e connectivity Spencer: You're right the previous 'link up' term is more appropriate Bernard Aboba: need to be clear about the meaning of notifications. There's a distinction between link 'up' vs 'fully functional' - a link can be "up" but may not provide very useful connectivity. It can be quite tricky as to just when you send the trigger. Spencer: Would notifications about nominal BW changes be useful? Bernard: I was just thinking re link up; but if I was told of a rate change that doesn't seem so obviously relevant Kevin Fall: you may have cases in which the link is 'up' but error rate is rather too bad to be very useful. This has been explored some time ago in SCPS. Phillipe Gentric: knowing a rate change could be quite helpful for streaming media Spencer: Maybe a bandwidth change would be some form of maximum [a speed limit through a link], so the indicator is essentially saying you might as well not go faster than that to the transport. Allison Mankin: maybe we are out of scope here; we don't really have links that tell us their max bandwidth at the moment Sally: It's not obvious what scope should be; some things have been investigated but others haven't been. At a minimum, maybe TRIGTRAN could write a problem statement. This group could define the trigger; sending the entire problem to a research group may not be enough, but a problem statement might well be appropriate. Eg. DCCP partial checksum issue came up. Should you allow corrupted data to be delivered to apps [or to lower layers]. Or should it be marked somehow as corrupted. Where would this sort of issue be addressed? perhaps here, or perhaps somewhere in IRTF. Another: as we build transport protocols robust to re-ordering, [and there is no reason they couldn't be]--- would you want a way for the transport to tell some lower layer that it robust to re-ordering so feel free to re-order. So, I don't know. Not clear where speculative, fleshing-out activities should take place. Spencer: We have been trying to maximize the amount of sanity we appear to have. We were trying to stay grounded in minimal notifications, not to spend time thinking about what to usefully speculate about. Now that we've been through a strawperson framework, maybe it would make sense now to add some of these speculative things to the discussion topics. Mark Handley: Various forms of these issues have arisen over the years. We don't have good institutional memory. If we investigate why *not* to do something, we should write this down somewhere, so we can remember why we *don't* do things. Spencer: Yes, I found some things like this looking over older discussions. Allison Mankin: We have a group of community members in the IETF who are largely not researchers; there are some interesting questions (e.g. how long to wait, what to do, is it really up or down, etc). Just getting this right is useful there is engineering to do with issues like "link flapping". We aren't inventing a research group here. I'm trying to not sound too 'top down' here. We would not want to include the researchy stuff in the charter. Probably having a wish list possibly for another group might be good, but we should not be doing work such as congestion handling here. Bernard: The more I learn, the more I would like to have a document that describes the general characteristics of various links. A link tutorial for the group would be useful. Of the existing literature, what are the results and conclusions? These are not static characteristics but dynamic ones. I take this to mean a survey document. This would be the first item of order to complete. It's not exactly the same stuff that PILC did. Maybe different than PILC because here we are concerned with signaling, which is more dynamic. Allison: You are suggesting a sort of survey doc? That would be part of the charter[?] hmmm. Spencer: TCP-SAT WG produced a doc that summarized the research topics. Allison: yeah, maybe ok. We would like to have a well and narrowly focused group. This is my answer to Sally. Now we have Bernard's suggestion. Spencer: Maybe we could do this in parallel [both the research and engineering-ish documents] Aaron Falk: [former chair of TCP-SAT] I'm not sure that the research doc was so useful. I wouldn't be opposed to seeing it again, but wouldn't want to take WG resources away from other tasks. There are all sorts of subtleties. The charter must be narrow and well focused. I would rather go deep than broad. I don't see that a TRIGTRAN research mechanisms document is a great investment of resources. Gorry Fairhurst: there are many things we could signal, but we don't know what we would do. I think doing a big survey would unearth lots of stuff we probably don't want to deal with. Spencer: Doing the framework revealed a fairly rich set of things that come up. Bernard: Given a media, how reliable is an indication? This sort of documentation could be quite useful. So, a [control] system observing an indication has to have some understanding of what to believe. This applies to rates also. The question is how reliable is it, how much skepticism should be applied when receiving a trigger. Spencer: Carl and I were assuming it would be helpful to know what different subnet technologies had the capability to send. Bernard is perhaps stating that the mapping of link condition to trigger could be more formal than we had been thinking. Hmmm. Allison: Maybe an appendix could include examples that could be cautionary or provide examples. Gathering those would be good. The working group could contribute these. Vince Park: I agree w/Bernard. It is difficult to decide what to take as an indication and how to interpret it. Probably a good idea. Has come up in mobileIP, MANET, and others. Ultimately you have to decide how to map L2 type information into a higher-layer indicator. May be bigger scope than TSV-only. Ethan Blanton: for some triggers we aren't sure we need a *protocol*. Not sure it is worth putting that much energy into a protocol until we are sure we need one. Aaron Falk: We're not just talking about the format of "bits on the wire". We need to define the semantics of what notifications you get and how you respond. None of that stuff has been hashed out. I believe some of these things may be valuable, but maybe there are cases where there are problems. There is work to do there. Ethan: I didn't mean to indicate that we shouldn't do this work. Just maybe a first-order item may be not to define the protocol, but whether or not a small subset of triggers are needed given certain links. Spencer: I would like to agree. The mechanism appropriate for link up is different from every other notification we've talked about. If all we have to do is link up, we don't need the whole framework. Is this responsive to your question? Ethan: yeah, I think so. If you carve out a space that doesn't need a protocol, you could still be concerned with what to do. Rick: from Mobile IP, we have been playing w/L2 triggers. Getting their semantics sorted out is important. We may need them for all sorts of things. Mark Allman: I'm not so concerned about 'link up' per-se, but exactly what you should do with it should be taken with some caution. (e.g. DCCP with this indication would do what exactly?) Spencer: We've been encouraged to look at other transports (e.g. SCTP). Now that DCCP seems to exist, we should be looking there too. Sally: I agree the question is open as to implicit vs explicit signals and that we need definitions for explicit ones and descriptions for implicit ones. Explicit signals might not be the right answer. Mark Handley: Does the sender of the signal need to know about all future transports? This is a complex spaceinteractions with lots of things [tunnels, security whatever]. Need to be careful. Spencer: My experience is that transport area is cautious. Randall Stewart: I also don't know what I would do on link-up in SCTP stack. Other than (some) relationship to heartbeats, I'm not sure how useful this is. Spencer: I had thought TCP people want link up and SCTP people want link down, based on conversations at IETF 55. Randall: I feel somewhat uncomfortable with link down given the possible DoS issues. --- Issues in the framework draft Aaron Falk suggested that we focus this discussion on Link Up, because we haven't gotten consensus on another notification that's compelling Spencer: link-up needs very little framework, and other stuff isn't baked yet. The framework document is not really a completed framework. We are exploring an approach. Aaron: Spencer, I'd like to suggest that we might have a consensus in the room that there is strong support for link-up and maybe some opposition to others. If you accept that, the framework is somewhat superfluous in the context of just doing link-up. Take a poll of the room to see. --- Agenda and WG charter and scope issue --- Spencer: I appreciate your suggestion re going forward on link-up. Aaron: What might be an acceptable scope of work for this WG is the question. Spencer: How about link-up? Is there is consensus that working on link-up would be just fine? *** Room Consensus was that Link Up is just fine *** Aaron: Does anyone this think would be a *bad* idea? Spencer: Yes, and please tell us why? Spencer: If we charter as a WG, I'm looking at whether this would be in scope. Joe Zebarth: It appears to be premature if this will move beyond a BOF. Spencer: What questions remain to be answered? Joe: Are you proposing a new protocol or mod to existing one? If I'm sending UDP say do I get one of these triggers? Are we modifying TCP or doing a new protocol or what? We need more info to agree or disagree for a WG formation. William Ivancic: There are unanswered questions regarding the usefulness of link-up. This isn't IETF-ready yet. Spencer: The criteria for having an item in the WG charter is not that we already know the answer, but that we are pretty sure we could come up with one. Dick Knight: I'm still confused. What is the clear problem statement? Most of this link layer stuff will sort itself out. I'm not sure why you are working this problem. Is this going to work in an MPLS network? Reiner Ludwig: To those people who said 'no', people aren't convinced we have a problem. Various people don't know what to do with it. I don't think people in this room are convinced there is a problem. Aaron: I think part of the problem is that not all these people have been at the places where this has come up before and that the drafts don't fully capture these experiences. E.g. the reference to Phil Karn's stuff in PILC. The people here that are familiar with the PILC document are not the ones that have objected [except Reiner]. Responding to Reiner in particular, there are some questions regarding SCTP, DCCP, and TFRC. One way to go is to take the suggestion from the PILC doc that you re-transmit packets at the routers [which doesn't require changes in end stations]. Part of the problem here is not everybody understands all the issues. We may need to talk about thisthere isn't a consistent sense as to what is on the table. 2 pieces of the problem: should IETF be trying to solve this, should the IETF try to solve this and what is the form of the solution so people can see it is not dangerous. Spencer: I do have a couple of slides here to present that might help. Phil Karn's proposal is best described in a posting on the PILC list from 3/2000. Mark Handley: Trying to summarize. A general strategy used in many of our transport protocols is exponential backoff. You would like to not have to wait for exponential backoff if you know the link has actually failed. Spencer: So, like in TCP, this could be quite some time [to wait]. Bernard: I think there is some problem getting the timer to the right point. Eg. There can be rate changes between media [e.g. between 802.11 and GPRS]. Question is how long it takes to adjust. Also, sometimes the adjustment can be 2-3 orders of magnitude. The first thing you need is a well-defined problem; next is what does the literature say? Does this literature solve the problem, or is something else needed? If you go through this logically, then get to the end and figure out whether you have solved it [or not]. Then you have a logical problem statement and you figure out what is left. (e.g. if the receiver changes rate dramatically, does or how does the sender know)? Spencer: First thing I'm going to show you now is generally about the framework; next is more specific to TCP {"kicking" TCP}. Kicking TCP doesn't appear to be so difficult, but I'm afraid if we go beyond this we need much more organizational machinery. Mark Handley: please don't talk only about TCP; the exponential backoff is ubiquitous for other transports too. {Explanation of slides lots of details here, see the slides, in particular the one titled "If we really 'kick TCP". Phil Karn, "Kicking TCP" March 2000 PILC list posting reference appears at the top of these minutes} Sally Floyd: I would feel more comfortable with a problem statement before the framework. Basically what Bernard has suggested. I would feel much more grounded to start there. Spencer: I agree completely. We did some problem stmt work up front; it would be appropriate to continue from there. Bernard: these indications have effects on things other than TCP. For example, maybe I need to update my address lease. So, that would certainly change things if I lost my address! Allison: This is the third in a series of BOFs that seems to be trying to not generalize the overall triggers problem. Is this part of the Internet area; seems that it isn't happening there either. Nobody seems to want to own it. I have a general question I should ask "how pressing is this problem"? How often do we get caught in this state? Maybe this inconvenience isn't worth the effort [like building the WG]. Maybe we should take a poll as to whether you have this problem? Spencer and Carl: Hand poll was maybe 30 people or so that felt they had this problem. Reiner: I'm looking at TCP over wide-area wireless networks (cellular 2.5G/3G, mostly GPRS and WCDMA; not SAT though) for a couple of years now, and I know of many real world measurements, not all of which have been made public. But, the problem of a TCP sender that is stuck with a backed-off RTO due to some transient link outage is rare in these environments. It does happen occasionally, though. Bernard: it isn't a big problem on 802.11, and again you have to be really careful about how you treat the indications [what sort of filter you use] Allison: so we might say don't do this for 802.11. Now I think we take a charter proposal, unless there is some objections? Alex Audu: is there an option to do both link up and down? Spencer: Well, no, not yet Alex: Are we going to ask this question? Carl: Does anything other than link-up make sense for a charter? Kevin: there is an observation that these indications can affect other layers of the stack. If we charter narrowly, where will this be addressed? Tom Hiller: there is some advantage to link down in 3GPP Spencer: We have been assuming these indications are pretty much un-authenticated. So therefore what they can indicate is limited. So we have been living under this constraint. William: but can't I have similar issues with link up? Spencer: I wasn't so concerned with getting a link up than a link down. It doesn't seem as risky as link-up - the network effect of link up is the same as an RTO timer popping. Mark Allman: it's all in how you scope the response to an indication. Link-up could be dangerous if you blast. Not if you are conservative, I would think. Spencer: Comments on sending some of this to the IRTF? Kevin: Who covers things covering various layers? Is it possibly IRTF? Aaron: Kevin, maybe this could be a result of just doing it. The process can be adapted. I'm an advocate of being closed and well defined. I'm increasingly unhappy with how long the turn around time is on documents. Spencer: Is it worth talking about "non-engineering" things here? Sally: It seems like there are architectural issues here. Having an IRTF home for this seems perfectly plausible to me. Whether it is an IRTF group or just a bunch of people doesn't seem so important. Spencer: What we are talking about is can we discuss things that might be outside the WG? ?? I know we've talked about link up and link down. What, in total, are we talking about? Spencer: In my complete list, including researchy topics, I had described link up, link down, packet discard, possibly horizontal or vertical handoff, and maybe indication of corruption losses Sally: I think a group of people writing about particulars could also write about more arch/speculative things too Gorry: We touched on timescales; we've moved to link up/down, ok. There is a semantic gap to what the link understands and what we are looking for. But we need to understand the filtering better. There is work to do that is technology dependent. Allison: This WG is not going to spend lots of cycles trying to have architectural discussions. It is going to spend its time working on the work. Spencer: yes Allison: It's going to do the work, right? Don't spend too much time carefully placing the work [that we don't intend to do here] somewhere else. Spencer: Allison, can we go forward? Allison: I'm going to wait for a charter proposal from you. It should include milestones, etc. I think we have gone as far as we can go so far. No further progress can be made without the proposal. My sense of the room is that the work is compelling. I don't need any more info. That was the last question I needed to answer to proceed. Spencer: Are we going the right direction toward a charter? Allison: You need to say this is a real-world problem. Scope the work carefully. Charters are contracts. Want to make sure the folks here are committed to doing engineering work on the problem. Mark Handley reminded me that in the PILC Advice to Internet Subnetwork Designers (LINK) Internet-Draft there is (almost) a BCP how routers might use link indications to hold packets when links go down. Be careful about security considerations and scope. There has been a lot of chatter in small groups regarding lightweight semi-secure mechanisms for protection w/out full crypto. Then we show a WG charter proposal to IAB/IESG, chairs participate in this discussion, then to the full IETF. Then we have consensus of everybody, then we have a contract. Then we hold to it very closely. By then it has IAB review and IESG approval and is advertised to others. This then might involve liaison with other standards bodies (IEEE in this case seems interested). Spencer, after closing remarks: Has anyone looked at the purpose built keys (PBK) draft? |