Light-Weight IP Protocol Design BOF Beijing IETF79 Chairs: Bob Hinden Zhen Cao Minutes taker Behcet Sarikaya Zhen Cao WEDNESDAY, November 10, 2010 1510-1610 Afternoon Session II, Valley Ballroom A **Agenda** Bash Agenda, chairs (5 Minutes) Introduction and problems statement - Hui Deng (15 Minutes) Lightweight TCP/IP Considerations - David Borman (15 Minutes) Discussion - Bob Hinden (25 Minutes) ----------------------------------------------------------------------------------------- Brain Carpenter: (Clarification question) Which version of IP, v6? Hui: Yes (expected to be v6) Spencer: Q1, This is lightweight IP&TCP, any interest on other protocols? Bob Hinden: Yes, I think so, if interested. (Jari is coming to the MIC) Jari: Yes, this work is a little cross area, at least transport and internet areas. Some other intersting topics might include routing protocols, how to implement them on the surprising lightweight devices, some profiles might be appropriate there also for how to do that most efficiently. Spencer: Q2, confused about if you guys are going to - document techniques that come from working group participants, or - document techniques that are in existing implementations, whether the implementers are participating or not, or - develop new techniques that are not yet implemented and document them Bob: I would like to answer yes if we can get people to come and provide information, work on document and so forth. Jari: I think the primary goal probably is collecting existing guidelines, why not add something new as well. I also want to make a point we have been contacting these people behind the stacks. We know that they are interested in participating in this work although they don¡¯t happen be this room today. Spencer: Ok, great. Ralph: (As Internet area director) Documenting bad ideas could be probably good as well. Muthu: a quick question. I understand the motivation fro LW-TCP, but LW-IP confused. what kind of changes in lwip? BOB: Not much to take out for lightweight IP, for example, options and extension headers, avoid fragmentation/assembly if packets are below 1280 in IPv6. I think there are still a lot of things to look at. Jari: Adding to that. Not that much, but 50% kind of obvious as said. Taking the other version as example, some considerations realted to when can you do that and when not. Zhen: For lightweight IP, we do not have much to do with the protocol, but could document some implementations techniques there, as software infrastructure as in David Bormann pointed out. Muthu: just follow, what to do with e.g. DHCPv6 Bob: I think those are good topics, though we do not have answers yet for how to do everything. Muthu: what I want to get is we have some general consensus we could start with. Bob: It is to try to document how to minimize implementation size. Depending on your environment, you can decide if you need DHCP for configuration. Spencer: Edge routers would need a different kind of guide, do we need two different guidelines? How many environments do you envirsion? If you have enough environments, we will end up with a realy complex set of profiles, then concern about how helpful these set of these guidelines are. Bob: you might be able to do that. It is not supposed to define environments but asking if your environment has used this, then you need this and if it doesn¡¯t, you don¡¯t. Ralph: Optimizations may go in a bunch of different dimensions of directions, over memory size, code size vs RAM size, speed and power consumption. Those are different environments as well. Bob: one of thing that is included charter but not talked much here is the power consumption, which is not related to code size, but to the number of packets you send and receive. You know transmission is more expensive than reception then how you might optimize that. This is also about whether we can get people who have expertise in this to participate in this working group. Spencer: The first working group I chaired in IETF is PILC (Performation Implication of Link Characteristics), that started after TCP-over-Satellite and someone else requested a working group for TCP-over-wireless for cellular phones, and Vern Paxson thought there would be no end to requests for specialized TCPs. We ended up with a working group for a few types of performance problems, no matter what the environment was (slow, long latency, errors), and I suspect something like that is needed here. How many attributes are you guys talking about optimizing for? If it's four, that might be doable. If it's 32, that's less doable. I'd encourage you to look at that early in the process. Hu ?? (Bitway): have some experiences on embedded linux and vxworks, and now trying to run TCP/IP stack on sensors, but more difficult. Thought there are some open source projects, it is still to port this to our platforms because they are ad-hoc environments. The challenges include how to manage the buffer and how to do cross-layer optimizations, and how to make it energy efficient. I think LWIP is very important and we can benefit from it, and currently the urgent thing is the guideline document. Dave Thaler: One clarification question for Zhen and have some comments and suggestions on topics Dave (Dave Borman) covered. What do we mean by different profiles, because ¡°profile¡± has different meanings in different communities and different contexts? Zhen: for example, home network scenario, what kind of functionalities are needed and what else are optional, and this is the profile, such document. Dave Thaler: Trying to summarize David¡¯s presentation into three high level bullets. The first category is, you do not have to do any optimization; the second category is optimization that are no way wire visible, memory management and timer management; the third one is wire visible, avoid fragment, 1280 MTU and etc. Each of this would be discussed separately. First one is the just general guidance that hopefully people should know. And second category is not wire visible, I think that¡¯s good stuff, could be document somewhere else, but not in IETF. IETF should focus on the category three, which is the affects of following certain MAYs and not following certain MAYs as the impact on inter-operability. I think the third category should be discussed instead of the other two. Bob: explanantion works for me. Dave Borman: just some quike comments. The world of engineering and softwares has just explored so much, you cannot do everything. Use cases are very useful to focus discussion. If we take the home router scenario as an example, and then talk about the implication, it helps us to understand what to focus on. Add some concrete cases instead of sort of generic on how to optimize TCP and implementation. There are probably a lot of things we could spend time on, that are benefitial for everybody. So use the usecases in the scenario that help focus. Zhen: we will work on this, definitely. JP Vasseur: I just want to support, which is in light of the charter. If we work on advices in IETF and feedbacks to existing working groups, it will be benefitial for a lot of working groups, on which options will cost what, would be useful. Peng Yang: I do think this work is very valuable. China has deployed quite a lot of smart objects in M2M service. When we want to have some kind of TCP/IP optimization, we find that we do not have many useful guidelines, so this fits well. I have another question on what¡¯s the optimization¡¯s impact on socket interface. BOB: IETF does not get into APIs but an interesting point Hui Deng: not only for China Mobile but also benefitial for people who are not familiar with IP technologies. In China, there are a lot of implementers, many are not IP based. They will benifit from these guidelines. We already have many experienced implementers in IETF, and if they can be really helpful to contribute, that will be really benefitial. Carsten Bormann: we have three WGs protocols that focus on constrained nodes and networks, and one wg chair has already expressed support. As co-chairs of the other two WGs, I also would like to express support for the following reasons. I met two different groups of people, protocol designers and system designers. And these two groups of people have big problems to hit with each other. Protocol designers do not know what¡¯s the cost on constrained nodes because they do protypes, and system designers would do not know how to use this on my nodes, and protocols designers may say you may leave this and that. So I think it is really important to have this communication going on. Pilc WG (Spencer chaired) is one of the most successful working groups in IETF. I pointed to milions of people to RFC3819. If we can generate some documents like RFC3819, that would be very useful. Spencer: Thank you. ???: I am an engineer in a communication company, I support this work. I think we need a guideline for similified implementation, on which functions can be disabled and which are MUST. Second, we need profiles for different scenarios, applications and different set of protocols. However, we must have some further discussion on security. Tina: not a bad idea, why do not we just work to reduce TCP/IP on constrained devices which we do not enough power, computing and memory. Have a potential working group to look at things from point view of basic protocols. Tao Sun: a very hot topic, other SDO like 3GPP are also working on optimizing protocols, and it is valuable to do some work here. On one hand, we should cover some scenarios, and on the other hand, some generalization of this work is also useful, in the sense that we can provide guidelines to implementers for interoperable. Gang Chen: for the operator¡¯s view, the working group can help survey various scenarios, and most importantly faciliate the Internet of Things, and so I support. Zach Shelby: I do support this effort. At first time I was not sure if this would be a working group. Looking at the current scope, it actually could one document, why do we need a WG? Now we could see some interest and chances of recharter and do some more work. Bob : the reason that we need a working group is that there is no one person who knows all about this. Zach Shelby: the second point is that implementors are not here, how we can get them? There are a lot of people who have proprietary stacks but would not tell you the secret, so we need some of the open projects guys. I have been asking around, and the response was positive and they would come to IETF more if there will somethings like this. The third point, problem statement as a working item is not needed. Do we need the guideline different from the profile? Probably two work items could be enough. I would like to see 6lowpan mentioned in the charter, and profiles should be defined in charter, otherwise we would spend the next year working on it. Robert Cragie: we have been trying to develop a LWIP stack in Zigbee alliance, and we have experience. And based on some comments earlier, I think optimizations and profiling are important to us. I fully support this working group going forward. Efforts refining which options are required in the actually specs, that sorts of efforts are useful for both this working group and to Zigbee for example. For software engineering parts, I am not sure about it. Feng Liu: the requirement of LWIP is very explicitly, it is suitable of doing this in IETF Dapeng Liu: it is useful, interesting and helpful for operators; and the IETF is the right place to do this because we have many experts in IP protocols. Ning Kong: co-author of the ps draft, very interesting work, and guiding implementors is need in the Internet of Things. Personally I am interested in naming services for Internet of Things. Samita: guideline document for lightweight IP implementation is useful which points to other exisiting solutions in IETF, but do not think profiling definition should be part of IETF charter. And believe a formal definition like a shim layer on top of TCP/IP could be useful but not very clear how to do that. Jari: many positive coments, and many questions. (1) we need to work the scope on/off the list; (2) we need implementers and experts to come, that is the main message to decide if we could go ahead; (3) some questions to ask the audience. Jari asked if in favor : many (not counted) those not in favor: 4 5-6 people not decided yet Ralph: ask how many people interested in doing the work (documents): 6-7, people with implementation experience (6-7)