Performance Implications of Link-layer Characteristics (PILC) Minutes August 2, 2000, Pittsburgh, PA Reported by Jim Griner (jgriner@grc.nasa.gov) Edited by Aaron Falk (aaron@panamsat.com) Charts and documents are available from the PILC Web page at http://pilc.grc.nasa.gov ************ Aaron Falk opened the meeting at 3:30pm and reviewed the agenda, Agenda bashing, with no comments milestones & status TCP over Wireless draft. The working group charter specifies that PILC will produce a 'TCP over Wireless' RFC that is a meta list of the existing PILC recommendations. This was reported in Adelaide as being completed in October 1999 because Aaron had confused it with the LTN draft. Actually, it requires some work. Gabe Montenegro has volunteered to sync up with the WAP forum to see if we can build this document on a work in progress that already exists in that body. The document should be only 3 or 4 pages long and should go to wg last call by January 2001. Gabe noted that there is currently no buy in by the WAP forum as yet, he will attend a forum meeting in September and try to resolve. Several members of WAP were in the room and volunteered to assist if needed. ERROR draft. A rough poll was taken indicating the group felt ERROR was ready for wg last call. SLOW draft. One of the SLOW authors wanted to incorporate some additional comments before submitting the draft for wg last call. When polled, there was no clear consensus of the group. Will see what comments come up on mail list during last call. Last call should take place in September. There was some discussion about interactions between slow and errored networks and that there should be a way to document interactions when you have multiple characteristics in a network. In particular, it was pointed out that these interactions are not well understood. However, most of the understood ones exist in some of the PILC documents (ERROR, SLOW, and LINK). It was suggested that appropriate cross references be added to ensure readers of one document are aware of relevant interactions described in another document. Suggested this issue gets raised on the list to see if there are interactions that need to be captured somewhere. (Some interactions were captured in RFC2488 but these are appropriate for all environments since that document focuses on long delay links.) Updated Working Group Milestones Aug 2000: ERROR (BCP) to working group last call Sep 2000: SLOW (BCP) to working group last call PEP (Informational) to working group last call Nov 2000: LINK (BCP) to working group last call Jan 2001: TCP over Wireless (BCP) to working group last call Note: ASYM is in limbo right now until we get an updated draft. Phil Karn - LINK document status Placing emphasis on end-to-end model. The multicast section is still incomplete. Didn't add much to this revision of the document. Assymetry section overlaps with asym draft. May rip out section on QoS because there may not be much well understood advice that can be given. Document still needs text on: o) delay interaction with tcp o) link layer retransmission o) does the subnetwork need its own routing mechanism? o) security Comments: Dan Grossman thinks there is some parts of QoS that are not overlapping with diff serv, and will provide some text. John Border - PEP document status Didn't receive many comments on -02 draft. Draft-03 released prior to this meeting. A disclaimer was added to say it is an overview document and does not include all PEP mechanisms. Document needs text on: o) section 3.6 on protocol boosters o) section 4.4.1 pep scalability implications o) section 4.4.2 and 4.4.3 multi-homing (maybe delete these section if no input received) o) add DoCoMo examples section, from DoCoMo draft o) W-LAN section needs text Plan next release (-04 draft) at end of September Aaron - PEP comments PEPs are being used in many environments, and we ignore them at our peril. One reason this document is being written is that we need to show what the downsides are to using peps. Outside organizations who are using these types of mechanisms (such as WAP) are being directed to pilc by the IESG so that they can understand how the IETF views these mechanisms. The PEP document is the place to show the problems of using PEPs. We need more information from members of the working group to add to the document. Specifically, we have not received adequate comments from an architectural perspective. Geoff pointed out that things like multi-homing are being used as a surrogate for reliability. Joe Touch suggested to limit PEP document to IP layer discussions, rather than the link layer problem. John Border noted that we were deferring link layer mechanisms to the link document, due to the scope of pep. There was also a comment mentioning that PEPs are being used to put QoS in wireless links, and maybe need to include this in PEP. Discussion on DoCoMo draft (draft-inamura-docomo-00.txt) Aaron noted that DoCoMo would like to publish this as informational RFC, but we don't want to get in a mode of publishing RFCs each time someone does this and requested input from the group. A speaker noted that the recommendations are pretty generic and suggested the working group use this as a starting point for the TCP over wireless document, or as an appendix to this document. Aaron suggested it might be necessary to take the simulation results out in order to use this document for the TCP over wireless document. Another speaker suggested using path MTU discovery instead of fixing it at 1500. Question: Maybe your tcp stack in the Opnet simulator is not the best TCP. Have you run this on real stacks, rather than on a simulator. Imaura - yes they have, but no published results. Aaron noted that another alternative was that the DoCoMo would be sent forth as informational, and would not be a recommendation. Tim Shepard asked why would one want to disseminate this information? Doesn't seem to make sense to have multiples of TCP/some link technology. Is this advice on how to tune TCP for the handset? Response from author: yes. Comment: This shows that tcp stack works over wireless error prone links. Comment: Doesn't think these results are any different from what a modern TCP stack does anyway. Gabe: This is similar to what was done in ecn document Comment: Thinks this should be published in academic journals, and not as an RFC Question: What bandwidth was used in the simulations? Imaura: 384kbs Comment: Doesn't think this is realistic, since this is only the rate if you are the only one in the cell. WAP is designed to use slower links. Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt) Comment: this is probably not a good idea -- leads to ICMP flooding. Also, if there is a long outage you do want to go through slow start again, because the network has changed. There are better link level solutions to this problem. Question: Why do you need a proxy and not just use end-to-end signaling? Response: The supervisor is in a better position to determine if there is an interruption. Response: In this case you need a proxy, and can't do it end-to-end.