Here are my notes from the recent NANOG meeting. Please note that any mistakes are mine. Corrections, providing missing information, or futher exposition of any of the information here will be gratefully accepted and added to this document which will be available via anonymous ftp later this month. ---------------------------------------------------------------------------- NANOG Notes by Stan Barber <sob@academ.com> [Please note that any errors are mine, and I'd appreciate corrections being forwarded to me.] Elise Gerich opened the meeting with Merit's current understanding of the state of the transition. THENET, CERFNET and MICHNET have expressed specific dates for transition. John Scudder then discussed some modelling he and Sue Hares have done on the projected load at the NAPs. The basic conclusions are that the FDDI technology (at Sprint) will be saturated sometime next year and that load-balancing strategies among NSPs across the NAPS is imperative for the long term viability of the new architecture. John also expressed concern over the lack of expressed policy for the collection of statistical data by the NAP operators. All of the NAP operator are present and stated that they will collect data, but that there are serious and open questions concerning the privacy of that data and how to publish it appropriately. John said that collecting the data was most important. Without the data, there is no source information from which publication become possible. He said that MERIT/NSFNET had already tackled these issues. Maybe the NAP operators can use this previous work as a model to develop their own policies for publication. After the break, Paul Vixie discussed the current status of the DNS and BIND. Specifically, he discusses DNS security. There are two reasons why DNS are not secure. There are two papers on this topic and they are both in the current BIND kit. So the information is freely available. Consider the case of telnetting across the Internet and getting what appears to be your machine's login banner. Doing a double check (host->address, then address->host) will help eliminate this problem. hosts.equiv and .rhosts are also sources of problems. Polluting the cache is a real problem. Doing UDP flooding is another problem. CERT says that doing rlogin is bad, but that does not solve the cache pollution problem. How to defend? 1. Validate the packets returned in a response to the query. Routers should drop UDP packets on which the source address don't match what it should be. (e.g. a udp packet comes in on a WAN link that should have come in via an ethernet interface). 2. There are a number of static validations of packet format that can be done. Adding some kind of cryptographic information to the DNS would help. Unfortunately, this moves very slowly because there are a number of strong conflicting opinions. What is being done? The current BETA of BIND has almost everything fixed that can be fixed without a new protocol. Versions prior 4.9 are no longer supported. Paul is funded half-time by the Internet Software Consortium. Rick Adams funds it via UUNET's non-profit side. Rick did not want to put it under GNU. DNS version 2 is being discussed. This is due to the limit in the size of the udp packet. Paul M. and Paul V. are working to say something about this at the next IETF. HP, Sun, DEC and SGI are working with Paul to adopt the 4.9.3 BIND once it is productional. After this comes out, Paul will start working on other problems. One problem is the size of BIND in core. This change will include using the Berkeley db routing to feed this from a disk-based database. There will also be some effort for helping doing load-balancing better. What about service issues? Providing name service is a start. DEC and SGI will be shipping BIND 4.9.3 will be shipping it with the next release. Paul has talked to Novell, but noone else....Novell has not been a helpful from the non-Unix side. RA Project : Merit and ISI with a subcontract with IBM ISI does the Route Server Development and the RA Futures Merit does the Routing Registry Databases and Network Management The Global Routing Registry consists of the RADB, various private routing registries, RIPE and APNIC. The RADB will be used to generate route server configurations and potentially router configurations. 1993 -- RIPE 81 1994 -- PRIDE tools April 1994 -- Merit Routing Registry September 1994 -- RIPE-181 October 1994 -- RIPE-181 Software implementation November 1994 -- NSP Policy Registrations/Route Server Configurations Why use the RADB? Troubleshooting, Connectivity, Stability The Route Server by ISI with IBM They facilitate routeing information exchange. They don't forward packets. There are two at each NAP with one AS number. They provide routing selection and distribution on behalf of clients (NSPs). [Replication of gated single table use = view] Multiple views to support clients with dissimilar route selection and/or distribution policies. BGP4 and BGP4 MIB are supported. RS's AS inserted in AS path, MED is passed unmodified (this appears controversal). The Route Servers are up and running on a testbed and have been tested with up to 8 peers and 5 views. Target ship date to 3 NAPS is October 21. The fourth will soon follow. The Network Management aspect of the RA project uses a Hierarchically Distributed Network Management Model. At the NAP, only local NM Traffic, externalizes NAP Problems, SNMPv1 and SNMPv2 are supported. OOB Access provides seamless PPP backup & console port access. Remote debugging enviromnent is identical to local debugging environment. The Centralizes Network Management System at Merit polls distributed rovers for problems, consolidates the problems into ROC alert screen. It is operational on August 1st which is operated by the University of Michigan Network Systems at the same location as the previous NSFNET NOC. 24/7 human operator coverage. Everything should be operational by the end of November. Routing Futures -- Route Server decoupling packet forwarding from routing inforation exchange, scalability and modularity. For example, explicit routing will be supported (with the development of ERP). IPv6 will be provided. Doing analysis of RRDB and define a general policy language (backward compatible with RIPE 181). Routing policy consistany and aggregration will be developed. Securing the route servers -- All of the usual standard mechanisms are being applied. Single-use passwords.... mac-layer bridges .... etc....How do we keep the routes from getting screwed intentionally? Denial of service attacks are possible. A design document on the route server will be available via the RRDB.MERIT.EDU WWW server. There is a serious concern to sychronization of the route servers and the routing registries. No solution has been implemented currently. Merit believes that will do updates at least once a day. Conversion from PRDB to RRDB The PRDB is AS 690 specific, NCARs, twice weekly and AUP constrained. The RADB has none of these features. Migration will occur before April of 1995. The PRDB will be temporarily part of the Global Routing Registry during transition. Real soon now -- Still send NCAR and it will be entered into PRDB and RRDB. Constancy checking will be more automated. Output for AS 690 will be compared from both to check consistancy. While this is happening, users will do what they always have. [Check ftp.ra.net for more information.] There is alot of concern among the NANOG participants about the correctness of all the information in the PRDB. Specifically, there appears to be some inaccuracy (homeas) of the information. ESnet has a special concern about this. [dsj@merit.edu to fix the missing homeas problem] Transition Plan: 1. Continue submitting NACRs 2. Start learning RIPE 181 3. Set/Confirm your AS's Maintainer object for future security 4. Switch to using Route Templates (in December) When it all works --RADB will be source for AS690 configuration, NCARs will go away, use local registries RADB to generate AS690 on second week of December. NACRs to die at the end of that week. Proxy Aggregation -- CIDR by Yakov Rekhter Assumptions -- Need to match the volume of routing information with the available resources, while providing connectivity server -- on a per provider basis. Need to match the amount of resource with the utility of routing information -- on a per provider basis. But what abaout "MORE THRUST?" It's not a good answer. Drives the costs up, doesn't help with complexity of operations, eliminates small providers Proxy aggregation -- A mechanism to allow aggregation of routing information originated by sites that are BGP-4 incapable. Proxy aggregation -- problems -- full consensus must exist for it to work. Local aggregation -- to reconnect the entity that benefits from the aggregation and the party that creates the aggregation. Bilateral agreements would control the disposition of doing local aggregation. Potential Candidates for Local Aggregation -- Longer prefix in presence of a shorter prefix, Adjacent CIDR Blocks, Aggregation over known holes. Routing in the presens of Local Aggregation -- AS and router that did the aggregation is identified via BGP (AGGREGATOR attribute) Should register in RRDB Summary -- adding more memory to routers is not an answer Regionals should aggregate their own CIDR blocks An NSP may do local aggregation and register it in the RRDB. Optimal routing and large scale routing are mutually exclusive. CIDR is the only known technique to provide scalable routing in the Internet. Large Internet and the ability of every site to control its own routing are mutually exclusive. Sprint Network Reengineering T-3 Network with sites in DC, Atlanta, Ft.Worth and Stockton currently. Will be expanding to Seattle, Chicago and Sprint NAP in the next several months. ICM uses this network for transit from one coast to the other. They expect to create a seperate ICM transit network early next year. Next NANOG will be at NCAR in February. PacBell NAP Status--Frank Liu The Switch is a Newbridge 36-150. NSFNET/ANS connected via Hayward today. MCINET via Hayward today. PB Labs via Concord today. Sprintlink connected via SanJose (not yet). NETCOM connected via Santa Clara in the next Month. APEX Global Information Services (based in Chicago) will connect via Santa Clara, but not yet. The Packet Clearing House (consortium) for small providers connected via Frame Relay to PB NAP. They will connect via one router to the NAP. It is being led by Electric City's Chris Allen. CIX connections are also in the cloud, but not in the same community yet. Testing done by Bellcore and PB. [TTCP was used for testing. The data was put up and removed quickly, so I did lose some in taking notes.] One source (TAXI/Sonet) -> One sink Two Sources (TAXI/Sonet) -> One Sink Five Sources (ethernet connected) ->One Sink (ethernet connected) Equipment issues -- DSU HSSI Clock mistmatch with the data rate. Sink devices does not have enough processing power to deal with large numbers of 512 byte packets. One Source-> One Sink MSS Window Througput (out of 40Mb/sec) 4470 51000 33.6 4470 25000 22.33 Two Source -> One Sink 4470 18000 33.17 (.05% cell loss, .04% packet restrans) 1500 51000 15.41 (.69% cell loss, 2.76% packet restrans) Conclusions Maximum througput is 33.6 Mbps for the 1:1 connection. Maximum througput will be higher when the DSU HSSI clock and data-rate mistmatch is corrected. Cell loss rate is low (.02% -- .69%). Througput degraded with the TCP window size is greater than 13000 bytes. Large switch buffers and router traffic shaping are needed. [The results appear to show TCP backing-off strategy engaging.] Future Service Plan of the SF-NAP-- Chin Yuan Currently, the NAP does best effort with RFC 1490 encapsulation. March 1995 -- Variable Bit Rate, Sub-Rate Tariff (4,10,16,25,34 and 40Mbps on 51, 100 and 140Mbps on OC3c). At CPE: Static Traffic Shaping and RFC 1483 and 1577 support [Traffic Shaping to be supported by Cisco later this year in API card for both OC3c and T3.] June 1995 -- Support for DS1 ATM (DXI and UNI at 128, 384 kbps and 1.4Mbps) 1996 or later -- Available Bit Rate and SVCs. At CPE: Dynamic Traffic Shaping Notes on Variable Bit Rate: Sustainable Cell Rate(SCR) and Maximum Burst Size (MBS)--- * Traffic Policing * Aggregated SCR is no greater than the line rate * MBS = 32, 100, 200 cells (Negotiable if > 200 cells) Peak Cell Rate (possible) * PCR <=line rate Traffic shaping will be required for the more advanced services. Available Bit Rate will require feedback to the router. ANS on performance --- Curtis Vallamizar There are two problems: aggregation of lower-speed TCP flows, support for high speed elastic supercomputer application. RFC 1191 is very important as is RFC-1323 for these problems to be addressed. The work that was done -- previous work showed that top speed for TCP was 30Mbs. The new work -- TCP Single Flow, TCP Multiple Flow Environment -- two different DS3 paths (NY->MICH: 20msec; NY->TEXAS->MICH: 68msec), four different versions of the RS6000 router software and Indy/SCs Conditions -- Two backround conditions (no backround traffic, reverse TCP flow intended to achive 70-80% utilization) Differing numbers of TCP flows. Results are available on-line via http. Temporarily it is located at: http://tweedledee.ans.net:8001:/ It will be on line rrdb.merit.edu more permanently. ATM -- What Tim Salo wants from ATM.... [I ran out of alertness, so I apologize to Tim for having extremely sketchy notes on this talk.] MAGIC -- Gigabit TestBed Currently Local Area ATM switches over SONET. Mostly FORE switches. Lan encapsuation (ATM Forum) versus RFC 1537 Stan Barber sob@academ.com
In message <aad32b6d0002100474db@[192.136.150.3]>, Stan Barber writes:
Here are my notes from the recent NANOG meeting. Please note that any mistakes are mine. Corrections, providing missing information, or futher exposition of any of the information here will be gratefully accepted and added to this document which will be available via anonymous ftp later this month.
Stan, Thanks for taking notes. It is a difficult job. There are some major ommisions. Here are just a few that I think are important in that they deal with what might be a critical issue. I left the Cc on, in case someone remembers differently. Curtis Ameritec presented testing results of tests using TCP on their NAP. (Please get details from Ameritec). Ameritec claims that their switch performed well. It was pointed out that with no delay in the tests, the delay bandwidth product of the TCP flows was near zero and it was asserted (by me actually) that results from such testing is not useful since real TCP flows going through a NAP have considerable delays.
PacBell NAP Status--Frank Liu
[ ... ]
Testing done by Bellcore and PB. [TTCP was used for testing. The data was put up and removed quickly, so I did lose some in taking notes.] [ ... ]
Conclusions
Maximum througput is 33.6 Mbps for the 1:1 connection.
Maximum througput will be higher when the DSU HSSI clock and data-rate mistmatch is corrected.
Cell loss rate is low (.02% -- .69%).
Througput degraded with the TCP window size is greater than 13000 bytes.
Large switch buffers and router traffic shaping are needed.
[The results appear to show TCP backing-off strategy engaging.]
Again, no delay was added. Measured delay (ping time) was said to be 3 msec (presumably due to switching or slow host response). Again - It was pointed out that with no delay in the tests, the delay bandwidth product of the TCP flows was near zero and asserted that results from such testing is not useful.
ANS on performance --- Curtis Vallamizar There are two problems: aggregation of lower-speed TCP flows, support for high speed elastic supercomputer application.
RFC 1191 is very important as is RFC-1323 for these problems to be addressed.
The work that was done -- previous work showed that top speed for TCP was 30M bs.
The new work -- TCP Single Flow, TCP Multiple Flow
Environment -- two different DS3 paths (NY->MICH: 20msec; NY->TEXAS->MICH: 68msec), four different versions of the RS6000 router software and Indy/SCs
Conditions -- Two backround conditions (no backround traffic, reverse TCP flow intended to achive 70-80% utilization) Differing numbers of TCP flows.
Results are available on-line via http. Temporarily it is located at:
http://tweedledee.ans.net:8001:/
It will be on line rrdb.merit.edu more permanently.
The difficulty in carrying TCP traffic is proportional to the delay bandwidth product of the traffic, not just the bandwidth. Adding delay makes the potential for bursts sustained over a longer period. Real networks have delay. US cross continent delay is 70 msec. ANSNET results were given using improved software which improved buffer capacity, intentionally crippled software (artificially limited buffering), and software which included Random Early Detection (RED - described in a IEEE TON paper by Floyd and Jacobson). Sustained goodput rates of up to 40-41 Mb/s were acheived using ttcp and 1-8 TCP flows. Some pathelogical cases were demonstrated in which much worse performace was acheived. These case mostly involve too little buffering at the congestion point (intentionally crippled router code was used to demostrate this) or using a single TCP flow and setting the TCP window much too large (3-5 times the delay bandwidth product). The latter pathelogic case can be avoided if the routers implement RED. The conclusions were: 1) routers need buffer capacity as large as the delay bandwidth product and 2) routers should impement RED. Only a 20 msec delay was added to the prototype NAP testing. Results with the prototype NAP and 20 msec delay were very poor compared to the performance of unchannelized DS3. Prototype NAP testing results were poor compared to Ameritec and Pacbell results due to the more realistic delay bandwidth product. Worse results can be expected with a 70 msec delay and may be better indications of actual performance when forwarding real traffic. More testing is needed after fixes to ADSUs are applied. A sufficient bottleneck can not be created at the switch until ADSU problems are addressed. There was some discussion (at various times during the presentations) of what this all means for the NAPs. If I may summarize - On the positive side the Ameritec switch has more buffering than the Fore used in the Bellcore prototype NAP. On the negative side, Ameritec didn't include any delay in their testing. NAP testing results (both positive results from Amertic, mixed results from PacBel and negative results from ANS) are inconclusive so far. Curtis BTW - I can't see how anyone could have kept accurate notes since a lot was presented. Maybe it would be better to just collect the slides from the presenters. If you want an ascii version on mine try http://tweedledee.ans.net:8001/nap-testing/tcp-performance.html and save-as plain text. You'll get the slides minus the plots of results but with some additional annotation.
participants (2)
-
Curtis Villamizar -
sob＠academ.com