Minutes of the ROHC WG sessions at IETF 53 ========================================== Hilton and Towers Hotel, Minneapolis,MN Tuesday morning and afternoon, 2002-03-19 Reported by: Lars-Erik Jonsson Note takers: Christian Schmidt, Hans Hannu, Mark West and Jonathan Rosenberg Slides are available at http://www.dmn.tzi.org/ietf/rohc Morning session, 0900-1130 -------------------------- * WG admonishments (Bormann) Carsten reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. People are encouraged to read RFC 2026 and RFC 2418, which define our processes. We are here to make the internet work, and we use rough consensus and running code instead of voting. The ROHC WG is chaired by Lars-Erik Jonsson and Carsten Bormann, with support from our area directors, Allison Mankin and Scott Bradner. Note that the real work is done on the mailing list, although face-to-face meetings can sometimes help the progress. Finally, Carsten stressed the RFC 2026 IPR policy, which says that any contribution must identify whether the contributor(s) is(are) aware of any IPR issues related to the contribution. * Agenda bashing (Bormann) Carsten presented the proposed agenda, which was accepted without modifications. * WG status (Jonsson) Lars-Erik reviewed WG goals and milestones. The RTP part is done, while most of the other work is started, although we do not yet have WG documents for all items (SCTP profile, UDP-Lite profiles, and LLA implementation examples are so far only discussed in individual Internet Drafts). SigComp was due in January, according to the milestones, and is thus late. However, the work is now progressing quickly, and should soon be finalized. The SigComp security evaluation, currently listed as a separate WG document, will go into the base SigComp document. Finally, the preparation for RFC 3095 draft standard has not yet started. * Document status (Jonsson) RFC 3095 and RFC 3096 are the only WG RFC's published, so far. Three more documents, "ROHC over PPP", "0-byte requirements", and "LLA RTP profile", have been approved and are currently in the RFC-editor's queue. Two documents, "RTP lower layer guidelines", and "LLA RTP R-mode", have been submitted to the IESG, passed IETF last-call, and are now awaiting IESG approval. Drafts: draft-ietf-rohc-over-ppp-04.txt draft-ietf-rohc-rtp-0-byte-requirements-02.txt draft-ietf-rohc-rtp-lla-03.txt draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt draft-ietf-rohc-rtp-lla-r-mode-02.txt * New mailing list (Jonsson) The ROHC mailing list had lots of spam, and in the process of taking actions against that, it was decided to move the list to "ietf.org". The old list, rohc@cdt.luth.se, is now closed, and all subscribers have been moved to the new list, rohc@ietf.org. The new list is subscriber-post, with other messages moderated by Lars-Erik, who checks incoming mails and filter Spam. This was applauded by the working group! * Signaling compression - Introduction (Bormann) Carsten reported that there had been an ad-hoc meeting on Sunday evening with SigComp authors, ROHC chairs, and various 3GPP people. The intention with that meeting was to exchange information, and make sure we have not missed anything or made assumptions that are not valid. The material presented there has been updated with inputs from that meeting, and will be the basis for the following meeting discussions at this session. We are doing this work mainly to minimize connection setup delay, and that is different from previous work, which was motivated by bandwidth saving needs. To deal with middle call interrupts is a secondary goal. Focus is on compression of SIP and SDP, but the solution should be generic so that it can be used for e.g. RTSP, and possibly also for DNS and RSVP. Details may of course be different when considering new protocols. Motivations and objectives for the work are discussed in the requirements document. When we started to look at this issue, we found that it would not be a simple task to choose a compression algorithm, since there are hundreds of them and they are all different. To select one or two standard algorithms had been one way, but especially IPR issues would make that a hard thing to do. Therefore, we started to look at the possibilities to let the compressor completely control the decompressor. We have designed a universal decompressor virtual machine (UDVM), which gets an executable decompressor uploaded from the compressor. There are therefore no compression schemes in the standard and any compression algorithm can be implemented by a compressor. The UDVM can be visualized in two ways - like an adaptive version of Deflate, or like a Java virtual machine, but much simpler and optimized for compression. The available instruction set is designed for its specific purpose, and selected for minimum code size. Simple algorithms would require about 50-70 bytes, while more complex ones gets slightly bigger. In general, an algorithm should require 50-200 bytes to be uploaded from compressor to UDVM. - Overview (Bormann) SigComp has been envisioned as a shim layer between the application layer and the transport layer. However, although this is where it is located in the architecture, to call it a shim layer might not be quite correct, since the interface from SigComp towards the application is more complicated than with a normal shim. Anyway, it is independent from the underlying transport protocol, and therefore supports arbitrary transports, such as per packet compression for e.g. UDP, and per-stream compression for e.g. TCP. Compression is either done per-message, or by using state references, and the decompression algorithm to use is either uploaded by the compressor, or an already present one is referenced. Since stateless, per-message, compression is not as efficient as dynamic compression, it is beneficial if previously established state can be referenced for improved compression. There are several ways to know which states have been established at the decompressor. A compressor can utilize application knowledge, usually referred to as implicit acknowledgements, or rely on explicit acknowledgements, state announcements, sent from the decompressor for each state established. Further compressed messages can then refer to these established states. A compressor can thus itself decide if dynamic compression should be implemented, and in such case also which mechanisms for dynamic compression to use, which seems to be a useful flexibility since there is potential IPR concerns with these mechanisms. For various reasons, including security aspects, state identifiers are cryptographic hashes over the state information. To reference a state, the compressor thus needs to be able to build a crypto hash over the state, which is equivalent to saying the state must be known by the compressor. Further, state must never be saved by a decompressor without permission from the application to do so. The UDVM approach with possible state references means that there is no need to negotiate anything. A sender must know that the other end supports compression, but the rest of the information used to optimize things comes in the ways of announcements of additional capabilities, and/or available states. One end can tell the other end that it has the Deflate algorithm, and that would be done with a state announcement. It should be noted that the usefulness of such state announcements is questionable, since it is very efficient to upload an algorithm. As an example, Deflate requires about 66 bytes to be uploaded, so considering also the additional rtt required for announcements, announcements may cost more bandwidth than what they can save. The initial compression ratio can be significantly improved with a mandatory, application-specific, state. Such a mandatory static dictionary should be defined, initially for sip. This predefined sip dictionary would be selected and basically fixed forever, otherwise we would be back to the negotiation issue. Note however that this is an application specific item, and outside of scope for the SigComp protocol. It had been suggested to do this work within the sipping wg, with a small design team of sip, rohc, and 3GPP aware participants. Goal should be a small but useful and reasonably future-proof dictionary for sip/sdp. - SigComp documents (Bormann) Currently, we have five WG SigComp documents available from the ID archives, but two of them, sigcomp-udvm and SigComp-algorithm are old. Requirements are in draft-ietf-rohc-signaling-req-assump. The base SigComp document is now draft-ietf-rohc-SigComp, which defines framework and UDVM, transport plus per-message compression. A second document, draft-ietf-rohc-sigcomp-extended, describes in more detail how to implement enhanced mechanisms, such as stateful compression based on sharing and reusing state in each direction. This latter document is informative, since implementation is done in the compressor only, so the material has been kept out of the base SigComp. Also, there are known IPR concerns with these enhanced implementation mechanisms, so it is nice to have it in a separate document. In this way, we get a basic solution which is, to our knowledge, IPR free, and an enhanced version which has known IPR claims, especially covering implicit and explicit acks. Note that although we are currently not aware of any IPR on the base solution, we can not know if there are IPR's anyway. The extended operations is only informative, but we need to finish it together with the baseline SigComp, to make sure the base specification has everything to make the extended operations implementable. A forth document is planned, but does not yet exist as an Internet Draft. The document is intended to be an informative user guide, making life easier for implementers of SigComp. There are already many ideas for what should be in this document. One is an assembly language for interchanging UDVM code. It could further include some example decompressors, such as lz77 simple, deflate, lqx, etc. Other items that have been brought up as potential content for this document are text on what needs to be done to put SigComp in a new environment, for RTSP guys when they come along, and various hints for UDVM implementors. There have been many good mails on the list regarding efficiency, and these should be captured. Drafts: draft-ietf-rohc-signaling-req-assump-02.txt draft-ietf-rohc-sigcomp-05.txt draft-ietf-rohc-sigcomp-extended-02.txt - SigComp architecture issues (Bormann) Four different, but to some extent related, architectural SigComp issues have been under discussion, and are more or less solved. 1) Discovery vs. SigComp 2) Multiplexing (compressed vs. Uncompressed) 3) Integration into an application protocol 4) What is needed to interface with an application (1) SigComp discovery The issue of how to invoke the SigComp shim, including how to discover that the other end supports SigComp and how to indicate that messages are compressed, has been discussed several times before. We started out waving our hands, and the issue has been "solved" many times. However, this turns out to be much harder than we have thought. We must find a solution that fits into the existing application discovery architecture, this is not only about SigComp. The old tricks may not work that well anymore. We used to overload schemes, http port 80 became overloaded by https by assigning a new port 443. Different ports have been used for different things, but we are now running into a combinatorial explosion, and there are many things you may want to do. There might be many versions of both security and compression, and other shim layers may turn up. Since there is only 2^16 ports, one can not get a port for each, so a new architecture is thus needed, says the IESG. We cannot go ahead with a scheme that tries to perpetuate this. This is hard, and there really are no pre-cooked answers. For the immediate pressing issue, SigComp in 3GPP release 5, this should not be a big issue, since they have discovery for pcscf already, and it should be quite easy to put SigComp in there as another item to discover. To get done in time for 3GPP, and since the general issue is hard to solve, the proposal is to not at all solve the discovery issue in SigComp. Keith Drage pointed out that in 3GPP, both UE and proxy will simply have to support it, and thus its not even needed in discovery. Carsten responded that using 0 bit discovery is ok, thus mandating SigComp. Lars-Erik pointed out that it still does not mean the use of SigComp is mandated in 3GPP, only the support for it in all entities. (2) Multiplexing mechanisms When leaving discovery out of SigComp, and especially when it might be avoided by making SigComp support mandatory in certain environments, we need a way to distinguish compressed messages from uncompressed messages, which works independent of whether external multiplexing mechanisms are present or not. Current text says you can use different ports, but that assumes an external mechanism we can not expect to have available. We have therefore discussed to make SigComp messages self-describing. So, if there is no port or other external multiplexing mechanism, one can look at the message itself and figure out if it is a compressed message or not. It has been proposed to use the initial 5 bits for this, with 11111xxx for SigComp compressed messages. Ascii start with zero, and this also works for utf-8. Further, it will make sure underlying RTP rohc can distinguish SigComp messages from RTP when initiating compression profile (10xxxxxx is normally treated as potential RTP). The proposal is thus to provide the above multiplexing mechanism within SigComp, but also allow other external mechanisms to be used, such as port multiplexing, since its related to discovery. (3) Integration into an application protocol SigComp currently has a number of application dependent parameters, to be defined for each application of SigComp, e.g. for SIP over SigComp. However, we expect to be able to reduce the number of parameters significantly by coupling them together, and/or by defining default values or default minimal values for them on a general SigComp level. If there are any parameters left after that, we must now at least define values for them for the SIP case. More discussions on this followed when the UDVM was discussed. One application-specific parameter that we should define for the combination of SIP and SDP is a static dictionary, since that would significantly improve the compression efficiency, at least for the initial messages. However, this should really be static, and must not be changed every week. It should thus be about as static as port numbers. Although the compression efficiency might deteriorate over time as new things are added, this should be a negligible problem. Questions were raised about various upcoming or future additions that we might want to include. Carsten responded that if sip uses FLOP in two years, we should add that now. But, we do want to keep the dictionary small. If it is too large, we would increase minimum size of certain parameters. When talking about 2kb UDVM implementations and a 1500 byte mtu, dictionary more than 1500 bytes would be a problem. Jonathan Rosenberg proposed to have dynamic dictionaries, but that is still possible to have in addition to the static dictionary. The point with a static dictionary is that it does not have to be uploaded over the air, and it can be used immediately, without any announcement. Carsten concluded that we will build a design team to define a static dictionary for SIP/SDP, and the AD's have suggested to do this within the Sipping WG. Richard and Carsten will participate from the ROHC side, and we will figure out who to get from the sip/sdp side. (4) Interfacing the application The state management assumes that for each incoming message with state creation, the application will be able to tell if message had enough merits to allow creation of state. This implies a stronger coupling between application and compression than we initially had envisioned, and it gets worse. When the application allows a state to be saved, it must provide an endpoint identifier for the sender of the message, which can be used by the SigComp entities to control state memory allocations. How to find unique identifiers is a difficult issue, although it is outside the scope of SigComp itself. Further discussions were deferred to the mailing list. - Timeline and document dependencies (Bormann) 3GPP is urgently waiting for this work to finalized, so important questions are when we expect to be done and which document dependencies we have. Although it is only informational, the extended operations document must be available at same time as base draft, since that is the only way to verify completeness of the base draft. The requirements document should also be simultaneously published. but the user guide will wait for various reasons. First of all, it is not yet started, further it will benefit from more implementation experience and become more useful when more complete, but will take some time to grow. As an informative document, it will also be useful already while its an Internet Draft, since there is no need for last call before you can use it. It is thus ok to leave it for much later, and have it live as a Internet Draft for a while. The authors believe we can have an updated (-06) version of SigComp on April 5, along with an updated (-03) version of the extended operations document. Hopefully, the documents are then ready for WG last call. Keith asked when this means we can see a last call, and Carsten deferred that question to Lars-Erik's summary of the procedural issues, to follow in the end of the SigComp session. - The universal decompressor and the state handler (Price) Richard went through the changes since Salt Lake City, and the open issues identified on the base SigComp draft. Basic SigComp is really about three things, the compressor, the decompressor (UDVM), and state handling. The compressor basically does not need to be covered, since its implementation is a local decision. Simple compression algorithms can be programmed directly, while more complex ones would require a compiler to generate the byte code, to be uploaded to the decompressor (UDVM). Byte code compilers may be subject to IPR, as well as the algorithms themselves might be. News in SigComp -05 were then discussed. Variable length encoding for operands has been added, and this resulted in a reduction on the byte code size, e.g. from 96 to 47 for lz77, and from 132 to 66 for lzw. The ability to decompress stream data has also been added, and a number of new UDVM instructions have been included, such as instructions for saving and retrieving state, for bit manipulations, and for initialization. To simply the scheme, it would be desirable to fix several of the application dependent parameters currently listed, and there is probably no need to specify most of those on a per-application basis. Richard suggested to remove the max-expansion-size parameter, since the first message might possibly be expanded a lot. The buffer-size and udvm-memory-size parameters are correlated, and the minimum values for compressed and uncompressed data should be based on the udvm-memory-size parameter, which will then be the only of those parameters left. Further, we should remove minimum-hash-size, and make it be a decision made by the compressor. Cycles-per-message could also be removed by fixing it to 1000 for all SigComp usages. Carsten suggested to change some fields in the decompressor announcements so that maximum-state-size could be announced. In case an endpoint can not save state, it would announce it is stateless. The cycles-per-message parameter should also be fixed for SigComp. Further, Richard wondered whether any UDVM instructions should be added. Carsten proposed to add SHIFT and MODULO, since if we do not do it now, it will never happen. Jonathan pointed out that the UDVM could be upgraded later, but it was agreed that upgrading the UDVM is undesirable since it requires announcements of enhanced versions. It would thus be great if we could include full instruction set already in the initial version of the UDVM. Richard asked if more CRC's should be added, and Carsten proposed to add a UDVM parameter for the CRC polynomial. Finally, it was discussed how many values there should be for UDVM parameters. The proposal was to fix e.g. six or seven values for UDVM memory size, which was also agreed. Overall, the impression was that the open UDVM issues are minor, so we could consider that part as more or less finished. The second part covered by Richard was the state handler, which is a new functionality added after the Salt Lake City meeting. State can be saved, but only with permission from the application. State is saved and referenced using a hash, so a malicious user cannot access state without knowing it. It was proposed to make state identifiers flexible in size when referencing them. A decompressor would always save them as 16 byte hashes, but a compressor could choose to reference with any size between 6 and 12 bytes, depending on collision probability. Currently there is a minor problem with the acknowledgement schemes defined in the extended operations document, which are caused by the way the base SigComp/UDVM works. The problem is that if e.g. sip messages are used as implicit acknowledgements, it is the compressor that decides to initiate it, but with explicit acknowledgements, the decompressor decides. This can be solved by letting the compressor initiate also explicit acknowledgements by combining appropriate UDVM instructions, and such a solution should be possible to allow for in the base SigComp without stepping on any known IPR. There were therefore no objections to do so. Some additional issues were then discussed. The first one was whether it should be possible for the compressor to choose which hash to use. UDVM instructions could be provided for md5 and sha1, and since there seems to be no security risks with that approach, this was agreed to be a useful feature. The rest of the discussions were about state creation, state deletion and priorities for states. There were some questions on whether state-free can be made secure, and Jonathan suggested to keep things simple and leave things out that are not obviously needed. Carsten responded that we have done a lot of trimming from -04 to -05, and that was the major difference between the two versions. It was then agreed to add the above mechanisms for state control. - SigComp extended operations (Hannu) Hans Hannu gave a quick update and status presentation for the SigComp extended operations document, which is an informational document describing how various enhancements can be implemented based on the mechanisms provided by the basic SigComp and the UDVM. This material has been placed in a separate document because it is pure informal, describing special implementation tricks, but also because there seems to be potential IPR's associated with these implementation tricks. The most important mechanisms described in the document are explicit acknowledgements, which enables dynamic compression based on previously compressed messages, shared compression, making it possible to share compression states between compressor and decompressor, and state management methods, such as state rollback. Since Salt Lake City, the document has been synchronized with the SigComp document, and they do now fit together. An architectural description of explicit acking has been included, and some additional mechanisms have been added. Since the current draft was announced, some modifications have been agreed, such as the way explicit acking is enabled, which now does not require extensions to the announcement format of SigComp. The code for enabling these mechanisms are now fully controlled by the compressor. The open issues with this document were previously discussed as UDVM issues, since most of them relates to which instructions are needed to implement these mechanisms. UDVM byte code for implementing extended operations was shown, and is rather short, although it has not yet been fully verified. - Security aspects (Bormann) Carsten gave a presentation on the security concerns with SigComp, and how these issues have been addressed. The security goals are simply to not create any new risks, worsen security of existing application protocols, or hinder deployment of application security. For confidentiality, i.e. snooping into state of ther users, the use of cryptographic hashes as state identifiers with a minimum length of 6 bytes is expected to provide a sufficient protection. Longer identifiers of up to 12 bytes are recommended, depending on the risk of state collision for each specific environment. Snooping of state identifiers should not at all be a problem, since one could not get any more knowledge from that than by looking at the message itself. For integrity of messages, SigComp itself will not help, but might jeopardize it. An obvious attack would be to fake state or make unauthorized changes to state. However, state can not be destroyed or changed by a malicious sender, it can only add new state. Fake state should only be a problem if memory limitations would cause losses from FIFO, making this a DoS problem rather than an integrity problem, and we rely on endpoint identifications provided by the application to avoid this. When considering other DoS attacks, there are a number of aspects to consider. SigComp only generates one decompressed message for each incoming message, so the usage of SigComp does not change the vulnerability of the application in that regard. SigComp could potentially make messages larger and an attacker could then send small packets that are decompressed to large ones, which is a risk the application must be aware of. Considering attacks on SigComp itself, the obvious attack would be to fill it with state, but that can only be done with consent of the application. SigComp should therefore not add any such vulnerabilities, compared to those present for the application itself. Finally, another potential attack on SigComp itself would be to send messages with "looping code". To avoid this, we will define an upper limit for the number of "CPU cycles" that can be used, e.g. 4 cycles per bit plus 1000 cycles per compressed message. The problem would still be there, but be limited, and this is true for any decompressor that can receive packets from anywhere. Carsten concluded that we are in rather good shape regarding the security aspects. We have gotten special competence involved to look at this, and no missing pieces have been identified so far. - Implementation status (Bormann) Carsten reported that there are currently three implementations in progress at Dynamicsoft, Roke Manor Research, and TZI: (www.dmn.tzi.org/ietf/rohc/UDVM). The assembler is 205 lines, and the UDVM currently about 520 lines of perl code (estimated to be around 750 lines when completed). Implementers have started to interchange code, to verify correct decompresses, which so far has been successfully done for lz77, deflate, and lzw. What has not been done so far is testing of state management interoperability, and testing in real setting. This is still just the start of the story. However, the UDVM seems to work and it is worth the effort. Carsten's perl implementations, although not complete, were written within one day. - What now? (Jonsson) Lars-Erik summarized the status based on previous discussions and issues raised. Discovery is left outside of SigComp, and we only provide methods to multiplex compressed and non-compressed messages. In 3G systems, that should be enough for now if they mandate support for SigComp. The discussion of a static dictionary for SigComp concluded that this will be defined for SIP in a cooperation between ROHC and SIPPING, and will be done quickly to meet the 3GPP release 5 together with SigComp. However, this is independent of SigComp itself and does not affect our progress in ROHC. To summarize, there seems to be only cosmetic discussions left for the UDVM, the security issues have all been addressed and we do have running code. If all issues raised on the list can be tracked, solutions provided and agreed, and updated drafts submitted on April 5th, it would potentially be possible to issue a WG last-call for these documents on April 8th. This would be a normal 2-week WG last-call, which, if successful, would be followed by the normal IESG process, including a 2-week IETF last-call. Afternoon session, 1545-1800 ---------------------------- * Role of EPIC-Lite in the ROHC work - Architectural role and naming (Jonsson) Lars-Erik summarized previous conclusions and agreements about what EPIC is. As pointed out by Mark West in his Salt Lake City presentation, EPIC is not a complete compression scheme, but a compressed header format generator, making it possible to avoid the hard work of creating the compressed header formats by hand. We have previously agreed to look at EPIC for this purpose, but it has not been completely clear exactly how to use it in the WG, or how it would fit together with the ROHC framework. The intention is now to not only summarize the current status, but also to outline a way forward with this work. - A simple RTP profile example (West) As suggested in Salt Lake City, an EPIC-based RTP profile has been defined to provide an understandable example. This way, we might get a better understanding of EPIC Lite, and even of the TCP-work. This is not a complete solution, only a limited example, but it does define mechanisms such as CSRC-list compression, for comparison with the RFC 3095 RTP profile. The profile is not compatible with the one in RFC3095, but provides similar performance. With this profile, it has been shown that it is possible to write an RTP profile based on the EPIC tools, which is essentially equal to ROHC RTP. This is useful for further discussions, and to tune the tradeoff between efficiency and complexity. Draft: draft-surtees-rtp-epic-00.txt - EPIC-Lite, news & open issues (West) Mark gave a quick update on the EPIC-Lite draft. The core concept, definition and pseudo code are stable, and there are now more than one implementation coming up. One important issue that is currently being addressed is the complexity of profiles, and also they are trying to get the whole thing more easy to understand through an improved structure and comments in the pseudo code. One thing that should be removed is the stack manipulation approach, which is a little bit strange, and unnecessary complicated. Draft: draft-ietf-rohc-epic-lite-01.txt - Way forward (Jonsson) Lars-Erik finally summarized the EPIC issues on a high level, explained how the chairs see this as part of the ROHC work, and outlined their proposal for how to progress. There have not been much discussion about EPIC on the mailing list, and there seem to be difficult for people to get involved, which is an essential key to be able to go further. To both simplify discussions and clarify how this fits into the ROHC work, we should take it into pieces, since there are more than one component in this. It is a tool for compressed header format generation in profile standardization, but it consists of at least two parts. First, it has a generic notation language to describe the header fields that are compressed, and how to compress each fields. Secondly, there are one or several encoding methods that can be used to generate the actual compressed header formats. Any such encoding would take as input the compression description for a profile, based on the generic notation language, and generate compressed header formats, which would differ depending on the encoding method used. The proposal is to write a new working group document, covering only the generic notation language. This is completely independent of the encodings, and should for completeness be evolved concurrent with various profile standardizations. Mark West has agreed to serve as editor for this document, and we should be able to see a first embryo within about one month. Encoding methods should be discussed first later on. In the end, this will give us a toolbox to use when we standardize future ROHC profiles. Qian asked whether this might delay the TCP work, or if we should reconsider using this toolbox for the TCP profile. Lars-Erik responded that we are not really in any urgent hurry to finalize the TCP profile, and Carsten further pointed out that this might instead accelerate the progress, since we can now focus on each separate part, and only the notation is relevant for the profile work. Further, if we get this tool right, we would simplify the profile development work by avoiding hand-made compressed header formats, which would be much more complicated for TCP than it was for RTP. * TCP profile - Requirements and field behavior (West) Mark gave a quick review of the TCP requirements and field behavior documents. Requirements are rather stable and will finally be called for freeze. As usual, we will keep the requirements in the WG until we have a solution ready. The field behavior draft, currently an individual draft, will be re-submitted as a WG document when the internet-drafts open after Minneapolis. Also the behavior document seems to be stable, although it would probably benefit from more review by TCP experts. Drafts: draft-ietf-rohc-tcp-requirements-03.txt draft-west-tcpip-field-behavior-01.txt - News & open issues (Qian) Lately, there have been some constructive discussions about the TCP profile on the mail list. Qian summarized the outcome from those discussions, of which the most important conclusion probably is to make the window estimation an implementation issue only, and not build the TCP profile on it. When talking about modes for TCP, Lars-Erik asked whether there are different packet formats for U and B modes. Qian answered that this is currently the case, because the Master Sequence Number (MSN) not needed in both modes. Lars-Erik explained that this means we need four-way handshakes as in the RTP profile, and expressed concerns about this unnecessary complexity of mode transitions. It was agreed to use the same formats U and B mode to keep the uni-/bi-directionality aspects as simple as possible. Currently, there is a non-official draft update for the TCP profile circulating out there. Lars-Erik asked Qian to submit the draft now without editing, to avoid confusion of which draft that is "valid". Then we should be able to continue the work. Draft: draft-ietf-rohc-tcp-00.txt * SCTP profile - Requirements, news & open issues (Schmidt) Christian gave a short update on the SCTP compression requirements, but there have been no major changes. Lars-Erik asked whether there had been any comments on the list, but unfortunately not. People are therefore encouraged to send comments to the list, if they are interested in SCTP compression. Lars-Erik further pointed out that the requirements will stay in the WG until we have a scheme ready, and we can not consider it ready either, without more discussions and comments. Draft: draft-ietf-rohc-sctp-requirements-00.txt - A first profile attempt (West) Mark continued with a few words about his first SCTP profile attempt. It is a starting point, showing that it is possible to compress SCTP, but currently not much more. Lars-Erik asked if he had any ideas how much we could potentially reuse from TCP when we do SCTP. Mark answered that he has not yet looked at that, but most likely there will be at least something that can be reused. However, SCTP has quite a different structure than TCP and RTP, so there is probably a need to invent some completely new mechanisms. Carsten finally asked if anyone in the room cares about SCTP compression? The audience answered with silence. Draft: draft-west-sctp-epic-00.txt * RTP issues - Implementation & impl. guide (Jonsson) The implementers guide for ROHC RTP has been updated with new stuff, corrections, and improved clarifications. The improved procedure for mode transitions has been corrected, and is also both better described and motivated. Further has it been clarified what is initially needed before mode transition (to O or R mode) can be initiated. RFC 3095 has some unclear words about this only in the R-mode section, but this is a general thing. Mode transition can never be initiated before the decompressor has received and correctly decompressed at least one packet. This should be obvious if one consider that modes is a per-profile thing, and so are the feedback packet bits that are used to signal mode transition. First when a packet has been correctly decompressed and the context has been established, the decompressor knows which profile it is operating according to, and thus which modes are available. Lars-Erik further raised a question about a statement in the draft concerning the use of Extension-3 with UO-1* packets. The statement says that "it might not make sense to use these packets", and the point was that such statements should not be made if we do not have specific reasons to do so. Mark agreed that the implementers guide should not make moral judgements, and it was decided to keep the clarification, but not say whether use of UO-1* with Extension-3 is a good or bad idea. Draft: draft-ietf-rohc-rtp-impl-guide-00.txt The next RFC 3095 interoperability test will take place in Lulea Sweden, April 17-23, hosted by Ericsson. Lars-Erik pointed out that newcomers are more than welcome, since it would be useful to get some fresh code and new problems to play with. - MIB, news & open issues (Quittek) Juergen reported on the MIB progress, which unfortunately has been less than we expected in December. One difficult thing is that the architecture of ROHC is not on solid ground, and this complicates the MIB development. Changes from the first version is mainly a new chapter stating architectural assumptions, a merge of the interface and header groups, and some new basic properties, such as version and manufacturer. The statistics group must be considered further to find out what things are useful there. Carsten pointed out that header types might not be a very good measure, since with TCP we might have hundreds of header types, and even with RTP the same header could be used with various options. It was suggested to have this as an action point for the next ROHC interop. Implementers should report what counters and information they collect in their implementations. There was a question about the grouping of the statistic counters. Juergen answered that this is due to restrictions from the MIB structure, one cannot put everything in the same table. Some statistics are outside of the statistics group, which only holds sophisticated counters. Regarding the architectural assumptions, Lars-Erik pointed out that a minimal instance is a compressor or a decompressor, which is not obvious from the current MIB. Juergen answered that an instance could be either a compressor, a decompressor, or both, and this will be made clearer in the next version. Lars-Erik is planning to write an architectural document for ROHC, and that might simplify these discussions. The next question was whether we plan to have MIBs for TCP or other compression protocols as well. The answer is yes, but we have to start with RTP. However, it would probably be a good time to start discussing a possible MIB structure and prepare for integration of other protocols as well. Carsten noted that understanding of the ROHC standard increases when doing the MIB, and the understanding will also increase when RFC 3095 is divided. Finally, Juergen asked if anyone is planning to implement the MIB, but there were no answers from the room. Carsten pointed out that someone will have to implement this, and encouraged people to go home and see who needs a MIB. Network builders will most likely need the MIB. Draft: draft-ietf-rohc-mib-rtp-01.txt - LLA, implementation examples (Pelletier) During the LLA development, a draft was written to illustrate how the LLA profile could be implemented in a typical environment, such as CDMA2000. It was then agreed to produce an Informational RFC based on this material, enhanced with more examples. Currently, the original draft has expired and we still have no WG draft for this, basically because the LLA incorporation in CDMA2000 has not yet been finalized. However, that work is now almost completed and we should soon expect to get a first version of this draft as a WG document. - UDP-Lite profiles, initial discussions (Pelletier) Ghyslain Pelletier held an initial discussion about profiles for UDP-Lite, based on his new draft. The current draft does not provide a complete solution, but is more about motivating and suggesting a direction for the work. There are no profile details, such as packet structures, included yet. The difference between UDP and UDP-Lite is that the length field of UDP has been replaced with a checksum coverage field, indicating how much of the payload has been covered by the checksum. It thus affects both the length/coverage field and the checksum field. For header compression, this means we get a new field that can not be inferred (length could be inferred from link layer, coverage could probably not). UDP-Lite has been defined to provide more flexibility to choose the level of protection provided by the transport layer, which is often desirable for applications such as conversational audio/video. In IPv4, the UDP checksum can be disabled, but that is not the case for IPv6. The reason for that is to guarantee protection for the headers, and therefore UDP Lite require, as a minimum, the header part of the packet to always be covered by the checksum. Depending on how the coverage field is set, one can identify typical scenarios for UDP-Lite usage, and the basic idea is to provide different compression approaches for different usage scenarios, making it possible to optimize compression for certain cases. A discussion followed about the possible common coverage for codec payloads such as AMR and EVRC, whether the payload header will be covered, and maybe even parts of the payload itself. Another question was whether this can change on a per-packet basis, and in such case how frequently? There was no real conclusion, more than that the coverage might vary on a short term basis, and that it is reasonable to believe one wants to protect at least the payload header. This should be subject for further investigation. The UDP-Lite profile will of course have to handle all possible UDP-Lite usage scenarios, but the proposal is to optimize for some cases that can be optimized for. The suggestion is to allow removal of the UDP-lite checksum at the compressor, with recalculation at the decompressor, for these specific cases. The use of this optimization would be limited to e.g. when only the packet headers were covered by the checksum, but could give a substantial performance gain. This would allow us to potentially compress as efficient in IPv6 as in IPv4 (where the checksum might be disabled). A discussion followed about the end-to-end consequences of this approach, how useful this would be since normally also the payload will be covered, etc. Stephen Casner argued that this breaks the end-2-end meaning of the UDP checksum, while Ghyslain answered that this is not completely true and the draft motivates why. There were no real conclusions, but more discussions and explanations were requested. Carsten Bormann said he wanted to explain why he allowed this to be brought up at all. UDP-Lite is not UDP, but was created with the purpose of playing with checksums. UDP-lite is necessary, because of the defect of IPv6 not allowing the UDP checksum to be disabled, and UDP-lite exists to fix this. Therefore it is good to look at options in the compression of UDP-lite. There was a question on what the minimal compressed header size would be, which Ghyslain answered would depend on the size of the CRC used, and so on. Another question asked about the relationship to 0-byte compression, which we already have. Why do we need this? Ghyslain answered that LLA doesn't work with v6, and this is targeting a different particular need - dealing with UDP-lite. Lars-Erik suggested there should be comparisons to the IPv4 case, where the header checksum is taken away in ROHC. The IPv6 header has no checksum, instead the UDP checksum is mandated. What would be the difference between these cases? This is an interesting analogy, and Carsten suggested it should be taken up in the draft. Lars-Erik pointed out that independent of which approach we finally go for, with or without certain optimizations, we are chartered to do profiles for UDP-Lite. This is therefore a good starting point for discussions. Finally, Stephen Casner suggested to investigate whether the coverage field could potentially be inferred from the link layer. To make a difference with UDP-Lite, link layers would also have to provide for partial protection, and that should then be utilized. Draft: draft-pelletier-rohc-rtp-udp-lite-00.txt