Last Modified: 2005-02-09
| Done | Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard | |
| Done | Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard | |
| Done | Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard | |
| Done | Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard. | |
| Done | submit revised ID for ECN to IESG for consideration as a proposed standard | |
| Done | submit ID on UDP-lite to IESG for consideration as a proposed standard | |
| Done | TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard | |
| Done | Submit ID for SCTP unreliable transport mode to IESG for consideration as a Proposed Standard | |
| Mar 04 | Submit early retransmission to IESG for consideration as Experimental | |
| Mar 04 | Submit SCTP Implementer's Guide to IESG for consideration as an Informational RFC | |
| Apr 04 | Submit Eifel response to IESG for consideration as a Proposed Standard | |
| Jun 04 | ECN Nonce procedure submitted to IESG for consideration as Proposed Standard | |
| Sep 04 | Submit ID for SCTP API for consideration as an Informational RFC | |
| Sep 09 | TCP-Friendly Variable Rate Control unicast congestion control submitted to IESG for consideration as a Proposed Standard |
| RFC | Status | Title |
|---|---|---|
| RFC2861 | E | TCP Congestion Window Validation |
| RFC2883 | PS | An Extension to the Selective Acknowledgement (SACK) Option for TCP |
| RFC2988 | PS | Computing TCP's Retransmission Timer |
| RFC3042 | PS | Enhancing TCP's Loss Recovery Using Limited Transmit |
| RFC3168 | PS | The Addition of Explicit Congestion Notification (ECN) to IP |
| RFC3309 | PS | Stream Control Transmission Protocol (SCTP) Checksum Change |
| RFC3390 | PS | Increasing TCP's Initial Window |
| RFC3436 | PS | Transport Layer Security over Stream Control Transmission Protocol |
| RFC3448 | PS | TCP Friendly Rate Control (TFRC):Protocol Specification |
| RFC3517 | PS | A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP |
| RFC3522 | E | The Eifel Detection Algorithm for TCP |
| RFC3649 | E | HighSpeed TCP for Large Congestion Windows |
| RFC3708 | E | Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions |
| RFC3742 | E | Limited Slow-Start for TCP with Large Congestion Windows |
| RFC3758 | Standard | SCTP Partial Reliability Extension |
| RFC3782 | Standard | The NewReno Modification to TCP's Fast Recovery Algorithm |
| RFC3828 | Standard | The UDP-Lite Protocol |
| RFC4015 | Standard | The Eifel Response Algorithm for TCP |
|
Transport Area WG (tsvwg)
Monday, March 7 at 1530-1730 ============================= CHAIRS: Allison Mankin <mankin@psg.com> Jon Peterson <jon.peterson@neustar.biz> Matt Zekauskas acted as scribe and produced these minutes. Thank you to Matt for the usual excellent reporting. A prize to the first person who finds the message about Paris hidden in the minutes below (by this co-chair). AGENDA Charter Discussion (chairs) Quickstart Update (Sally Floyd) (5 mins) draft-amit-quick-start-04.txt RSVP over MPLS-TE/DS-TE (Bruce Davie) (10 mins) draft-lefaucheur-rsvp-dste-01.txt RSVP IPSec (Bruce Davie) (10 mins) draft-lefaucheur-rsvp-ipsec-00.txt SCTP Chunk Authentication and Threats (Michael Tuexen) (20 mins) draft-tuexen-sctp-auth-chunk-03.txt draft-stewart-tsvwg-sctpthreat-02.txt SCTP Implementer's Guide (Randall Stewart) (10 mins) draft-ietf-tsvwg-sctpimpguide-13.txt TCP MIB (Matt Mathis) (10 mins) draft-ietf-tsvwg-tcp-mib-extension-06.txt Real-time Congestion Notification (Jozef Babiarz) (10 mins) draft-babiarz-tsvwg-rtecn-03.txt Diffserv Service Class (Kwok Ho Chan) (10 mins) draft-ietf-tsvwg-diffserv-service-classes-00.txt Diffserv Service Class Aggregation (Kwok Ho Chan) (10 mins) draft-chan-tsvwg-diffserv-class-aggr-01.txt MLPP Update (Fred Baker/James Polk) (15 mins) draft-ietf-tsvwg-mlpp-that-works-00.txt draft-ietf-tsvwg-mlef-concerns-00.txt draft-ietf-tsvwg-rsvp-bw-reduction-00.txt draft-baker-tsvwg-vpn-signaled-preemption.02.txt Quickstart Update (Sally Floyd) Sally quickly reviewed Quickstart. Quickstart IP option, requested rate & TTL in SYN. Routers may decrement request, and decrement RTT if they understand. SYNACK has RTT measurement and rate. The sender knows if all routers approve of the rate request. There were three main changes: the addition of a citation (discussion of router algorithms), and a discussion of misbehaving middleboxes, and a section on attacks on quickstart. The citation is for a paper that evaluates a whole range of router algorithms, from a minimum algorithm, to "extreme Quickstart", as well as a discussion of how to size your bandwidth request at the start. The attacks on Quickstart include attacking a router by bombarding it with many packets with Quickstart requests (router can rate-limit); Attack Quickstart itself by sending many requests that are not used (again, the router must have a mechanism to limit requests); won't hurt folks that don't want to use Quickstart. If have a misbehaving middlebox, something that rewrites the IP TTL, it will interfere with Quickstart (you can't tell if all routers agree to the request). There's no good answer to this one, it's just noted in the draft. Sally asked for feedback, and thinks it can be WGLC as experimental. There were a couple of "ship it"s from the audience. Jon said that if no other feedback, will issue WGLC. Allison said that they would like to see a couple of reviews from the WG during WGLC on the mailing list. Please contribute to the value of the WGLC. RSVP over MPLS-TE/DS-TE (Francois LeFaucheur) (10 mins) The key change to the draft is a closer alignment with the LSP hierarchy draft in the MPLS WG, which we agreed to do at the last meeting. They requested feedback from MPLS WG. They got some feedback, but at this stage, mostly suggestion for clarifications, nothing major. An appendix was added for informational purposes. A use case, how the aggregation solution can fit together with a VOIP architecture. The authors want to have accepted as a WG document; they feel it is pretty stable now. Jon asked for opinions. Fred Baker and James Polk both said they thought it should be a WG document. Jon asked for a hum. In favor of adopting: <major> opposed: <fewer> Jon declared a consensus to adopt this document as a working group item. Francois asked what were the concerns of those opposed. Joe Touch said that given silence of the room, individual submission seems in order instead of a working group submission. It's hard to say the document came out of the WG, if there is no support. Jon felt that there was substantial enough response to the hum that it should be a WG item. Any other opinions? Joe commented that the apathy is deafening. Allison proposed making a review group for RSVP. TSVWG is a big catch-all group, and so there can be a majority that doesn't care. However, we don't want to do a lot of work in an ad-hoc manner. RSVP also has some legacy issues, and Allison isn't comfortable spinning up a WG for this. In the use of this review group, we can do better than the not long enough face-to-face meeting sessions and times. Presentations have been more devoted to discussion of apathy than necessarily getting at the needed comment and review so one hopes that a review group will elicit the in depth consideration that is sought, while also sending onto the mailing list the public results in summary, very promptly. If this is useful, we might choose to create in addition review groups for other topics, for instance for the next up SCTP implementation guide. Rsvps for rsvp group a moi... People that are interested in working on RSVP should send a message to the chairs. There are a lot of RSVP workers around, some from NSIS. This is not the best environment for active discussion, and we need to improve. So identify yourself in person over the next few days or by email to the chairs. The chairs will name an RSVP review group of the active RSVP people, and get you activated. Melinda Shore said that she wasn't apathetic; wasn't sure what to say except "uh huh". She thinks this work should be done. Why? To get through IESG, has to go through WGLC. There were calls of "not trues" from audience. Joe wanted to know if there were any standards here, or was this document informational? He thought Allison's point was well taken; get a group of people, and show that there is energy. if so, then we can make a decision about it being a working group document. If no one reads it except the authors, and there is no one to review the document it shouldn't be here. Tom Phelan said that he was not apathetic, not an author, and has given lots of feedback to the authors. Like Melinda, he didn't know what to say except uhhuh. Francois noted that many others outside group have read the document and commented on it. Allison noted that there has been discussion both in past meetings and on the mailing list. There are a lot of different topics in the group, and an a RSVP discussion group is one way to move forward; she didn't think there was a big problem. RSVP IPSec (Francois LeFaucheur) (10 mins) See slides. Looking for aggregation solutions for RSVP, in the context of IPSEC VPNs. Hide and aggregate reservations on IPSEC tunnels, given a core cloud that supports diffserv. We want end-to-end RSVP reservations. These must be hidden in core inside IPsec tunnels. But once you hide them, to support right e2e reservation, need to reserve resource for aggregate traffic carried over the IPsec tunnels. They thought problem was solved with existing RFCs - 2207 & 3175. Looking harder, that is not the case. 2207 is RSVP extensions for IPSec flows, but it doesn't address aggregation. 3175 describes aggregation of RSVP. However, it doesn't support IPSec between aggregator and deaggregator. This draft: do both at same time. Francois showed a picture, and a new packet format that has both bits of information necessary. (See slides.) The remaining open items: * Add text delineating the responsibilities of aggregators & deaggregators. There are no specific issues, there is only some explanation needed. * Add text about how to handle dynamic updates of security associations. There may be an elegant solution: change the SPI to renew the association. Give a mechanism to do it without deallocating and reallocating resources. Right now there is a discussion in the middle of the security section, and it needs to be moved. This is new work, the authors would like feedback. They would also like to progress the work, hopefully here. Allison asked if the authors had ever viewed the RSVP security analysis document from the NSIS group. They should review it, and look at the security piece. 2207 was done a while ago, and it's security review might not be good enough. Allison asked for the issues to be put onto the mailing list, and get discussion going. SCTP Chunk Authentication and Threats (Michael Tuexen) (20 mins) The origin of document is a paper by T. Aura P. Nikander and G Camarillo analyzing SCTP from protocol point of view, and looking at implementations. Given that paper, we changed some things in the protocol, and listed these threads in the ID, and added some other possible attacks. Michael then went through the threats at high level. * Address camping or stealing. Attacker guesses port number the victim will use next, and the victim must be multihomed. Path verification procedure in the implementation guide will prevent, and random port number selection makes it harder. * Association hijacking. Attacker must take over IP addresses. Gets a VTAGs in cookie according to the original RFC 2960. Implementer's guide now requires what is in cookie are random numbers, not real tags, so vtags still protect against blind attacker. * Association hijacking #2. If application doesn't pay attention to restart, it doesn't realize endpoint may have changed. Pay attention to notifications. * Bombing attack (1). Trick server into sending packets to a victim. Only works if victim doesn't understand SCTP. (If it did, it will send an ABORT.) Server isn't paying attention to ICMP. Attacker is also spoofing acknowledgements. The implementer's guide now says how to handle ICMP messages. If you get acks for data you have never sent, abort the association. Finally, do the path verification procedure to make sure the IP address is correct. * Bombing II. Send INIT give address of victim. Get cookie that you send to endpoint. Now the path verification mechanism is itself used as an attack. Have a low number of heartbeats that send at any time. Want a high number for preventing attacks, but here want to limit. The Implementer's guide says to limit the hartbeats to a "maxburst" parameter. * Association redirection. Same info in two different places in the packet... but some implementations only use the common header. Can get receiver of the packet into an unstable state. The implementer's guide says to drop the packet if the numbers don't match. In summary, some attacks are not possible if you implement new procedures. Some can be limited in time by tuning appropriate parameters. The authors are interested in if someone has more attacks or ideas...such that we can list and analyze. They are not interested in attacks against implementations (bugs) all protocol related. any questions... Jon asked if Gonzalo (who has written a lot on SCTP) thinks it is good. He gave it a thumbs up :) Next Michael turned to the chunk authentication draft. An SCTP extension on dynamic IP (LIP) has been stable for 2 years, but not progressed due to security concerns. This draft is the missing security part. With LIP one can change the address of an association. This draft provides a mechanism to ensure that chunks have been sent from an endpoint that you think they came from. At the beginning of the SCTP association, exchange some material so can verify. This does not address man-in-the-middle attacks from the beginning of the connection (but that is true without LIP too). LIP will be required to use this extension. (See slides.) Michael asked if we can we adopt this draft. It is needed to progress the other document. There were no comments. Jon asked for a hum, in favor of adoption as an official working group document. <moderate> opposed? <none> Jon declares consensus (within room) to adopt. SCTP Implementer's Guide (Randall Stewart) (10 mins) There are two outstanding issues. First, one that is just on the implementer's list: PPID field, and text change for byte order. There was lots of discussion, and we have a wording proposal. Second, Armando and Randy (Stewart) were supposed to put in a note regarding Karn's algorithm and RTT. Doing that now. After both of these go in it's ready for WGLC. It is an informational document. Original idea with Scott Bradner, is that it's a way forward to get a 2960bis. Start up a bis once this gets into the RFC Editor's queue. We'd like to set up some RFC2960bis ground rules. It's up to the ADs, but what we'd prefer, is that when we open up the bis (after the implementer's guide is in the RFC Editor's queue), only changes in the implementer's guide are applied to 2960. E.g.: wording, missed references to adler-32 checksum. But no field day on let's add "X". At end result would be obsolete 2960 and 3309 (the checksum change), and the new draft would cycle back at Proposed. We would move it forward after a couple of more interops (but not until the implementer's guide is in the RFC Editor's queue). Jon felt that, speaking personally, it was a well thought out way to go forward. Randy said he had lived through three WGLC and three IESG LC, and he doesn't want to do it again. Jon said that if there are any outstanding issues, get them to Randy quickly. TCP ESTATS MIB (Matt Mathis) (10 mins) Matt reviewed the motivation for the MIB. TCP already measures lots of stuff, and knows where bottlenecks are. We added explicit instrumentation on what causes TCP to stop sending data controls to support useful workarounds. The big motivation is a hard end-to-end diagnostic problem. With TCP, symptoms scale with RTT. Tests in local paths pass, move to longer paths and they can fail. This leads to false logic and lots of "buck passing". The ESTATS MIB would let you rescale properties of short path to longer path. (See slides for details.) The latest revision is 06. We haven't changed details of objects, but did change the structure of the MIB. There are three sets of required variables: * state vars * performance instrumentation * first tier diagnostic instrumentation There are also three sets of optional variables (focus on where problems are). * path (loss, reordering, dup, etc) * stack (impact and state of control algs) e.g. for cwnd validation * app (is app stalling or tcp?) And a little table of writeable controls * limit cwnd and limit rwind: can do instead of starving tcp for buffer space. (starving: interferes with recovery alg, retrans, and app that doesn't have stable perf (eg disk seeks causing dry spells) * ssthresh: for slow-start. like limited sstart. The TCP roadmap was helpful in this rewrite. The big open tech issue: there have been two Industrial implementers looking at the MIB. They have commented that there is too much required, that may make it unimplemented in practice. It's easy to juggle variables between tables. There are also SMI representation issues. We need help - the duration object has proven problematic. Want high precision for short flows. MIB uses 0 based counters. All counters start at O; can always look at stats, but then need duration object, which could be around for weeks and months. Need more than 32 bits of microseconds, anyway. We also want to delta on duration, so compute rates. That means no time-of-day numbers in duration... because of discontinuities in clock adjustments. Allison: do you have an SNMP expert? Should we ask for volunteers here? Dan Romascanu volunteers. In addition, big worry is if we have overlooked something obvious. 65 page MIB, and description is terse. Allison mentions that Dan Romascanu has experience writing for extension in the future. Fred Baker noted that he doesn't know anything about mibs, but if you have a 65 page MIB, and descriptions are terse, this causes concern. If I can think of algorithm that can be described, and want... can mail in object. Find myself wondering how many objects are specific to one implementation or another, and not general. Matt said they are pretty careful about that. My background is BSD, and this was done with Linux, so we believe it can be done at least twice. As much as possible, objects are described in terms of standards (RFCs) or TCP state vars. Fred said that older TCPs had SRTT... more recent ones keep mean RTT and variance in RTT. There are differences in way mean and variance are calculated. Start high and average down, or start at initial RTT of SYN/ACK, and end up with different things. He's concerned. How standardize something like that? The RTO calculation is on standards track, the MIB refers to that RFC. Ones that do something different are not compliant. Matt is getting tired of this project; he will get more implementer's experience, and get MIB doctor review, and hopes to have WGLC sometime this summer. Allison thought that we need MIB advice right now. We've go a volunteer to help with MIB formalisms; do that in parallel with additional implementers and researchers. There is a formal thing called "MIB doctor review", which happens after WGLC; a second round. So, take Dan's advice now, and go through a round of MIB formalism first. There were no other comments. Real-time Congestion Notification (Jozef Babiarz) (10 mins) Jozef started with a quick status update. Sally is reviewing. The semantics have been changed to align with 3168. Added a token bucket example, but it is an example; vendors are free to use whatever they want for marking. A description of ECN marking behavior has been added. A description of mis-marking or cheating detection was added. Jozef then compared 3168 semantics to what is proposed in this draft. (See slides.) Two levels of congestion versus 1 level in 3168. Use a real-time measurement technique to detect congestion, versus AQM in 3168. The next steps include cleaning up the text so that ECN semantics are uniformly described; describe how ECN capable and non-ECN capable endpoints interact; address how real-time inelastic ECN-capable flow will react when it encounters a non-diffserv router that supports 3168. Looking for feedback and comments. David Black volunteered to be a reviewer. This draft is related to trouble he's making in NSIS. NSIS has draft that is proposing to signal and react to congestion. He thinks the use cases are RT, but it's not clear. ECN is a candidate mechanism for what they want to do, and this may be related. The draft is the RMD draft in NSIS. Look for the congestion signaling support in it. Second Sally's comment: figuring out how this works when you have just 3168 in a router is crucial. Sally followed up, and said she needed to get back to an old chore, writing an ID for requirements for alternate semantics to ECN. There have been a number of proposals. Think that the requirements are one of (1) only deployable in closed environment (and not safe for general use) (2) provide some mechanism that makes sure that traffic that requires alternate ECN semantics only encounters routers that support semantics (perhaps something like Quickstart) (3) if traffic happens to encounter older router 3168... that the end node response is TCP-friendly. Colin Perkins noted that a companion draft was mentioned that tried to define an RTP payload format for ECN. Will that go to AVT, or discuss here. Jozef was not planning to bring the draft forward at this time; he wants to "socialize it" and decide. If there is interest, let's talk offline. Colin mentioned that he was AVT co-chair. He wanted to make sure that it was reviewed by people that understood RTP as well as the TSV community. Brian Carpenter, as the guardian of the "diffserv flame", said that way the draft is written it is not immediately apparent that it is intimately associated with diffserv; but the draft only makes sense in a diffserv context. The presumption is that EF DS is being used for this traffic. That's part of the mechanism for knowing that it is not regular ECN. However, it could also could be a new PHB (association of a diffserv codepoint with the new ECN behavior). The discussion of that issue should be in this draft, and if you can run this simultaneously with EF PHB and no ECN. It gets complicated needs a discussion. Also realize that we mucked around with transport philosophy in DS... the TOS byte doesn't exist. If David becomes a reviewer, he would find that. Gorry Fairhust didn't quite get a strong case for 2 levels, which seems to be main point. Is there a use case? Jozef said that the companion draft describes how to use it for admission control. There are a bunch of uses: admission control, calls with high precedence, preemption, ... and we felt that 2 levels would address. Perhaps we need text to say how someone would use this if they only want one level. Fred Baker asked if Jozef had followed a comment related to this that he made on the mailing list. Jozef said that he got part, had a partial response, and wanted to talk. Fred said that he was wondering how to use this in a world with different people having different policies. It gives us a measurement, but what do we do with the measurement. It may be that someone else needs to do something -- a different SIP proxy, or in some different space. It's not clear how the application can be depended on to handle that. This is something that draft needs to go into, and not just say "application's problem". Jozef asked if it's more appropriate for a separate draft, describing use. There is mechanism here. Policy will depend on the application, and how to use. This needs to be stated and guidance given, but a separate draft seems more appropriate. Fred thought that might be, but RFC 3247 has updates to EF to make it predictable. If traffic is experiencing marks, predictability goes away. Perhaps a different draft, or an appendix, but there must be guidance for real applications. James Polk agreed. You've mentioned that one or more of these indications could provide for session pre-emption. How? Jozef stated that the marking is passed to the end points. They can send to the network manager controlling preemption. Flows indicate that they have reached the 2nd level of congestion. The manager can select those flows, and check policy. If they can be preempted, then they can be removed. James asked if a interface has 1000 flows, and reaches capacity, is this second level? If all those flows are marked, all endpoints may react at the same time. Tell server to tell router? Jozef says that one way with a centralized manager that gets all these, and it can then decide which to kill. David said that is exactly where NSIS RMD is headed; we need to rationalize and do it once. Stephen Norys from BT had another question about 2 levels. In particular, how do you cope with toggling between levels? If the algorithm is vendor dependent; different vendors could produce different answers, and the stream may switch back and forth between the two levels. Think you want some kind of ramp effect, rather than just 2 levels. Georgios Karagiannis, an author of the NSIS draft resource management in diffserv: Related to David's remark... on Thursday we will discuss different alternatives, only one of them is this one. Allison noted that it is reasonable for people to go to NSIS on Thursday. It would be good to have more discussion. This is only part of the RMD work. Resolved: Jozef and the RMD folks are to talk about their work's potential overlap. Diffserv Service Class (Kwok Ho Chan) (10 mins) This is the fourth version, but first as WG item. The notion of administrative service classes has been removed; the network control class (because of the first change) is now just routing and network control, everything else is just a standard class; the multimedia conferencing discussion changed from "elastic flows" to rate-adaptive flows, since they are really inelastic flows that can change rate; the ring clipping discussion has been moved to the appendix. Updated references. The authors feel all outstanding issues have been resolved, and would like to start WGLC. No comments. Allison asked for the opinion of group on this, by a hum. Jon and Allison reserve right to review it prior to WGLC, because they haven't done the chairs' review yet. Those that support WGLC at this time for this document, which has been at four or five meetings now, please hum: <loud> Those that don't support, or oppose it, please hum: <none> Allison declares consensus towards moving to LC good. Will review it, and look towards moving it forward. Diffserv Service Class Aggregation (Kwok Ho Chan) (10 mins) This is an extension of the last draft: how to aggregate service classes if you don't need detail. Want to allow less-granular treatment where not needed, but preserve end-to-end notion of service requirements that application wants. After discussions, think four treatment aggregates are the right number. Network control, real time, assured elastic, and elastic. Would like feedback on the number, and the names. The draft would provide guidance as to how perform aggregation, and could be used as a foundation for indications between providers. Not sure how yet... See slides for detail. Next steps are to cleanup guidelines on aggregation, and add a discussion about using MPLS to express aggregates. We would like comments back. Jon said it would be good to see mailing list discussion. MLPP Update (Fred Baker/James Polk) (15 mins) Four drafts. First, the MLEF concerns draft has been posted as a WG document pursuant to discussion last time. This changed the draft handle only. Second, our MLPP proposal which is RSVP based. We did a minor update and submitted as a WG draft. There were errors in the appendix with respect to SIP call flows; they have been fixed. Other than that it's the same. Third, at last meeting, James talked about RSVP bandwidth reduction thing. This identified a bug in RFC 3181 when it comes to dealing with aggregate reservations. If I need to preempt call within reservation, it has me tear down and set up with new number. This has a giant hole...this draft suggests that one simply reduce bandwidth. "accept if doesn't exceed X", and the endpoint changes codec or whatever is the right thing. This draft considers backwards compatibility. Fourth, the last draft, is a use case for bw reduction thing. A VPN network with multiple levels of VPNing. This is still an individual submission. The draft posits that VPN router might be two boxes. Talk about what crosses the private interface between them. The other 3 pretty sure about. This one needs work; dinner tomorrow night is a discussion of this draft with others that are interested. we want: We want the first three to move forward. mlef-concerns -> informational mlpp that works: informational or BCP bw-reduction -> proposed. it's a protocol. As to the last one... If the way we get people to read & comment is to go to last call, I would like to go to last call. We want people to read & comment. So LC to informational? Mike Pierce: object vehemently to MLEF concerns going anywhere. The MLEF concerns document is to object to and provide comments on draft that myself and Steve Silverman wrote on MLEF. We have seen it..and responded to it two years ago. We have made changes. To show you how bad it is... look in the draft reference section. It references the Jan. 2004 version that has concerns with. However, the MLEF document has been revised twice, and this draft doesn't reference updates, much less recognize modifications made to MLEF. The MLEF concerns actual title is "MLEF without capacity admission does not satisfy MLPP requirements", but we said that from the beginning. The version from way back when that was referred to... included explicit statement that it would not work without call admission control. We strengthened that statement. Yet this doc keeps arguing that point. In addition, this document contains a large number of technical inaccuracies. For example, g709 increasing throughput in face of loss. It is theoretically possible for a codec to do that, but this one doesn't. It talks about having 3 specific rates... Jon: don't want to take exception, but this is a more detailed discussion than we have time for. But we need to have the discussion. Mike objects to the document proceeding, and is not sure how it to WG status; his recollection is that there was no agreement. Jon believe there was consensus, and the first time that Mr. Baker spoke to us about it, there was strong consensus for this work. James Polk: to last point, about ILBC not being variable...Alan Durek wrote part of that. He is the author of that protocol. He is who helped write section. Mike said it's not in rfcs, though. Scott Bradner agreed that this particular document that was reviewed at ieprep was a very important document in it's day. However, he's not sure if needs to be RFC, unless it is recast as "concerns about non-admission controlled attempts at priority". It is an instructive document, but not sure it deals with the alternatives on table today. Would agree that it should fade out, but strongly support moving the others forward. Jon asked for Fred to comment. Fred stated that when the document was first published, he didn't expect it to be an RFC. He could go either way. James said that one of reasons why we regenerated this six months ago or so is that we had a couple other customers, other than us government, that wanted to promote diffserv-based QoS using that mechanism. So we wanted to have the concerns documented. He agreed with Scott that the scope ought to be broader. Fred said that he heard that if this document is to become an RFC at all, the working group must tell him what to see. Jon said that he believed the working group requested that rather than document the problems with a specific proposal, speak to general design principles that are objectionable. Scott agreed. Jon noted that we are out of time; clearly there should be more discussion on issues. Jon invited Mike to bring technical objections to list. Jon then declared the meeting to be closed. |