Aaron opened the meeting at 2:15PM on 3/28/00 Went over the agenda, with no comments. Defered discussion of assymetric draft, since authors are not at this meeting WG status: ---------- -Submitted "Long Thin Networks" to IESG in October 99 -Should submit PEP draft as informational to IESG by Nov 00 -ASYM document needs more discussion on the list -Aaron: ASYM will go away if there is consensus that these mechanisms are not needed -Should submit LINK draft to IESG by Nov 00 -SLOW and ERROR are expected to become BCPs during spring 2000, now in last call John Border gave the status on the PEP draft: --------------------------------------------- -The -01 draft missed the DC meeting deadline but was submitted after DC meeting. For the -00 we got valuable comments, but for -01 we didn't get any commnets; maybe as a result of being late? -Looking for input in the following sections protocol booster mechanisims ACK filtering and regeneration Partial ACK mechanisims Others?? -Some additional example environments where PEPs are in use may be added, but only if they illustriate new types or mechanisms not already covered -Need help on completing the section on WAP -Mainly looking for input on implications of using PEPS End-to-end failure diagnostics Multi-homing environments QoS transparency Security implications Others? Need further terminology refinment Comments: ??: Can get more information on the WAP section from the IAB worksop BOF and plenary WAP discussion John?: Some problems between asym and pep draft as what happens to ASYM is not known John Border: Leave specific information in asym draft, if it doesn't go away Aaron Falk: ASYM will go away if the mechanisims are not real and needed PEP document should only contain mechanisims that are used or are going to be used, and not just academic mechanisims John Border: We have to draw the line somewhere ??: Are web caches considered peps? John Border: There is a fine line to whether they are peps or not Markku Kojo: They are considered PEPs in this doc only when they are related to specific link characteristic(s), i.e. they use some specific mechanisms to mitigate problems due to link behavior Phil Karn gave the status on the link draft: -------------------------------------------- -Goal of document is to give advice to designers of subnetworks that intend to carry IP -Emphasis on end-to-end model, awareness of inter-layer interactions, and eliminating redundancy (between what IP already provides and what link designers are providing) -01 draft submitted for nov99 IETF Changes include: address delays, MTUs, error recovery, connection-oriented subnetworks, framing, Bandwidth on Demand -02 was submitted for this IETF Reflects current versions of mailing list comments Added congestion and flow control QoS, multicast, etc. -Changes to the current draft (since -01) refinement of all sections esp those on impacts on net asym -end to end philosophy -all sections related to fundamental link design added sections -QoS management and flow control have some redundent parts compression -mobility -broadcast/multicast Sections needing work -QoS & Congestion Control -Delay and delay variance characteritics -routing & mobility (how much routing should IP provide and how much should the subnetwork provide?) -multicast support -QoS management next steps -revisit draft -seek advice and agree on end to end (QoS ?) Jamashid: How much delay can a subnetwork add? If many people all take the same advice then the delay can addup Phil Karn: No one is adding gratituas delay; give us hooks to tell whether the pkt is delay sensitive ??: Connection oriented subnetworks section is biased might want to look at MPLS (MPLS introduces some connection-orientinesh to nets) Phil Karn: The section advises one to avoid connection oriented subnetworks, some of these topics should be added to congestion management section Aaron Falk: This is a really important document, and now is the time to add new sections or add/correct current sections, since the document is maturing Phil Karn: The more people that add to the document, the more credibility it will have Jamashid: Is there some way to add a short summary of key points Phil Karn: Thinks this is a good idea, since some sections are long ??: What about FDDI switches that fragment IP packets Phil Karn: Maybe add this as an example Gabe Montenagro gave the status of the SLOW and ERROR drafts ------------------------------------------------------------ -Most of the changes are cosmetic -Changed from explicit corruption notification to explicit transmission error notification in error draft -New section were added in both drafts to separate: -recommended mechanisms -topics for further work -Both drafts are currently in last call till april 7 -Issues with SLOW draft (as seen by the authors) -Need to redo receive and router buffer size example in section 2.3 and address the issues related to the router buffer size more clearly -Should we reccomend RED? (we think yes) -Should we recomment ECN? -Need to beef up MTU section, maybe steal some of link text -Issues with ERROR draft (as seen by the authors) -Need editing on section 1.2 (relationship with LINK draft) -Section 2.2 on AIMD is not accurate -Section 2.2, why cwnd remains small: -#2 is inaccurate -#3 must be removed, cannot be generalised, applies LTNs only -Need to update section 4.0 -on SACK-EXT as it is no onger experimental -Delayed DUPACKs section needs clarification -Some changes are desirable in both drafts Do we need a second last call? Aaron: if the changes are substantial Comments: Phil Karn: The wording may not carry over from link document, since audiences are different (on whether duplicating text, using pointers to other pilc docs) Aaron and John: Said that we should make it clear that the topics for further work in appendicies are not part of the recommendations Gabe Montenagro: Maybe a paragraphs stating that the appencicies are not the emphasis of the document Geoff Huston: Should say active queue management is important and use RED as an example of this