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
