Minutes of Orlando IEPG meeting 6 Dec 1998

1. RIPE NCC update

Mirjam Kuhne gave an update on the RIPE NCC.

A few statistics: RIPE region hostcount: ~7M, 1100 Local Internet Registries, 77% small 27% medium and 6% large. Size placement is initially voluntary, but is reviewed based on assigned address space. Requests to [email protected]: ~2.400 per quarter. What takes the most time is education and assistance to LIRs. The RIPE WHOIS server receives something like 5M queries per month, that's approx. 2 per second on average, and the database receives some 170K updates per month.

The RIPE DB contents is approximately 50% domains, 35% persons, inetnum ~10% and route objects ~2%. It was asked whether the low portion of route objects meant that they weren't used, however it was guessed that this is route aggregation and CIDR at work. The total database is about 1.2M objects.

Recently there was an incident where person objects were removed which shouldn't have been, and Murphy struck again because the same week software was going to be installed that would have ensured referential integrity (could not delete objects still referenced from other objects). That new software is now in place, and also can do PGP authentication of updates and performs additional syntax checks.

IPv6 -- a policy document for address assignment is in preperation. As the address allocation structure document of the IETF has already gone through 4 revisions, it was suggested that any address allocation mechanism should be an address lending mechanism, and that address blocks allocated would be re-validated after a year. It's however not certain who can set this policy, with ICANN now on the field. The DB is ready for IPv6 objects, and it is expected that all the regional Internet Registries (RIRs) will be ready to handle IPv6 address allocation sometime in Q1 1999.

The RIPE NCC is also participating in the RIR coordination, and is working on setting up the address supporting organization of ICANN.


Paul NN

Paul Wilson presented some information from the APNIC. Their WHOIS server receives approximately 800K queries/month. Even though the database does not contain any domain information, a large portion of the queries are for domains.

The total address space assigned is approximately 25M addresses. The larger users of the APNIC are JP, AU, CN, TW and HK. The blocks used are 201/8 and 202/8; 61/8 has almost no use so far. There was also mention of a range in the traditional B range, and that use of that range would probably be filtered away (?).

AS allocations -- up to ~700. There's been a recent rise due to the opening of an HK Internet Exchange point, and more use in JP. AU remains the most multi-homed country with 14% of the addresses and 22% of the ASes.

APNIC is hiring 3 more people, rising up to 9.

APNICs "server farm" will be upgraded in the near future. APNIC has 217 members, increasing with 10 per month, but also 7 leave per month.

IPv6 allocation activity is being coordinated with ARIN and RIPE. So far they have had one formal request for IPv6 address space.

It was suggested that IPv6 address allocation policy should be to lease addresses for one year, and that each allocation would have to be re-evaluated after this year, especially given that the current address format is based on the fourth proposal for address allocation. GH indicated that address allocations should not be "once-and-for-all" as it de-facto is with IPv4, especially since renumbering of IPv6 networks is supposed to be easy. GH also suggested that one could even go all the way and pay for the address leases.

The 6BONE was mentioned, and that it has been stable at 104 routable prefixes for quite a while, and according to some stats, 80% of the traffic on the 6BONE is ICMP from various "status pages" for the 6BONE. There was talk about a IPv6-based web server, and the report was that hits/month was *very* low.

David Kessens, now of Qwest, presented a few statistics from the routing registries, related to IPv6 registrations:

                    Dec 1st          Aug 20
        ipv6-site       332             302
        inet6num        201             175
        person          374             326
        role             24              21
        mntnr           113              98


Ramin Rad

Stats are available from http://www.arin.net/IPStats.html

A few selected entries:


Projects underway:

Routing registry issues:

IPv6 issues:

Rewrite of internal system


4. CAR - experiences, or "why I don't want a CAR but a TRUCK"

Ran Atkinson, @Home

Ran gave a presentation based on the slides made and shown earlier at NANOG by Cathy Wittbrodt.

CAR does packet classification and rate limiting, implemented with a simple token bucket, characterized by

Actions: transmit, drop, mark

A lab setup was used during the tests, the object being to limit the access rate of a customer to something below the physical access rate.

The "normal burst" setup caused a lot of retransmits, knee in curve at 24KB burst size, at 128kbit/s; it caused approximately 20% retransmits. A TCP sequence/time plot showed a distinct "stair- step" with short bursts and long periods for time-outs associated with packet loss. Throughput was xxx kbit/s.

Another setup used shaping with an ATM PVC, which showed (unsurprisingly) quite an improvement.

Generic traffic shaping also improved the situation, although there are still issues with performance of that code (VIP2 load, fast- switching vs. distributed packet switching etc.)

Yet another test setup made use of the "extende burst" settings, and the results looked similar to the "normal burst" test, although retransmits were reduced to approx. 7%.

With multiple parallel streams over a CAR path the TCPs showed distinct tendencies to self-synchronization, leading to low throughput.

A few formulas had been worked out to suggest "optimal" settings of the CAR parameters:

        bn = r * 1/8 * 1.5s
        be = bn + (r * 1/8 * 1.5s) = 2 x bn

@Home had also used CAR in the field, on a busy 7500 with FDDI. There were essentially no big surprises:

5. Upstream rate limiting

Ran Atkinson, @Home

Tests had been done with standards-based cable modems to limit the upstream capacity to 128kbit/s, since upstream capacity is relatively scarce in these systems. The software was "production" based, although the vendors may later retract that status...

   Test setup:

        +------+ 100M +----+
        !BSDI A+------+E-sw!
        +------+      +--+-+
                      !Cable !
                         !cable plant
                         !    +-----+
                         +----+Cable!        +------+
                         !    !Modem+--------+BSDI B!
                         !    +-----+        +------+

   Vendor #1: Token bucket with no extended burst.  Similar effects as
        observed with CAR -- 50Kbit/s throughput with continual
        retransmits and timeouts.
   Vendor #2: 25Kbit/s throughput.  Also token bucket with no extended
   Vendor #3: 17Kbit/s throughput.
   Vendor #4: Leaky bucket, throughput ~90Kbit/s.
The basic conclusion is that "TCP needs a queue". Furthermore, a basic token bucket is bad for TCP, and that an extended bucket or a leaky bucket is better. This is not a new result, but apparently something needed to be discovered by every new group applying their technology to the Internet.

6. Internet Delay Measurements

Henk Uiterwaal, RIPE NCC

More information at http://www.ripe.net/test-traffic/

The "test traffic measurement" project at the RIPE NCC measures delay, packet-loss, capacity (eventually) and routing (paths).

Active one-way delay measurement, as defined by IPPM, using GPS synchronized clocks (using GPS Oncore VP units) on test boxes deployed close to ISP border routers.

Q: What's a "lost packet"
A: A packet which did not arrive within 255s

Henk presented a few slides which demonstrated some of the data presentations they have made based on the measurement data.

There are plans for further analysis of the data, e.g.

Approximately 20 more test boxes will be deployed early 1999 -- the currently deployed boxes are free (to be returned to the RIPE NCC once the project is finished).

RIPE NCC is using a fairly strict data disclosure policy; a host can only look at "his" statistics, and cannot publish the data without all involved parties' consent.

7. ALE update

Brian Carpenter

Brian presented a new set of graphs in the same style as those earlier presented by Frank Solensky. According to the data we are up to 43% address space consumption, and the fitted curve flats out quite a bit before we reach 50%.

It was questioned what exactly the data represents, and it was thought that the data actually represents allocations (including even those to regional registries?) and not actual assignments. The numbers are therefore "soft", and there was consensus that there is a lack of "real data".

Suggestions for more and better data collection methods solicited.

8. Registrar/Registry protocol


        Amendment 11 to NSF/NSI collaborative agreement, affects
        name portion of InterNiC.
        Extends collaborative agreement for 2 more years, during
        which period registry data should be shared     

   When (plans):
        testbed         March 1st, 1999
        operation       June 1st, 1999

        Real-time registration
        Contact info at *registrar*
        International issues delegated to registrars
        SSL used for protection

   See http://www.netsol.com/nsi/presentations/markk/SP11nanog

   Q: UTF8 for labels in the DNS?
   A: When DNS and/or BIND supports it.


Scott Bradner

Heads-up for Thursday POISSON session, more or less dedicated to ICANN issues.

10. Diff-serv ("better RED than dead" ;-)

Geoff Huston solicited deployment experiences. There are not many, but Sean Doran's half-year-old web presentation is still available at


While the above may show higher port utilization, it's not clear what happens with buffer occupancy and RTTs, or with user goodput and single-session throughput.

   Q: Can RED offer "diff-serv" AF or EF service?
   A: Matter of interpretation (?)

   RED can probably be used to implement "olympic" service levels.

   Q: What does diff-serv buy the ISPs?  (Left unanswered.)

   Q: In the diff-serv framework / architecture, is the IETF really
      meddling in ISP issues, where they normally should not?  (Also
      left unanswered.)

Meeting concluded; Elise Gerich thanked all presenters.