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 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
Stats are available from http://www.arin.net/IPStats.html
A few selected entries:
inet6num -- RIPE object for internal data representation
Use it for external representation too? Not yet decided.
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
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:
# of rate queues -- similarly
VIP2-50 better than VIP2-40
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 !
!router!
+--+---+
!
!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
burst.
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.
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.
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.
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.
Why:
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
Details:
Lightweight
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.
Heads-up for Thursday POISSON session, more or less dedicated to ICANN issues.
http://adm.ebone.net/~smd/red-1.html
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.)