IEPG Meeting

14 March 1999
Minneapolis

Authors:


Cable TV Standards

Ran Atkinson, @Home

Overview

terminology:

evolution of cable networks

Note: standard channel size is 6MHz for NTSC, 8MHz for PAL

data over cable

issues:

cable router in headend:

data over cable: plant

data over cable: home

data over cable: standards

Internet trends:

@HOMES perspective:

 
 Diagram:
   global Internet
 	|
   NAPS
 	|
   @Home private ATM backbone
 	|
   22 regional data centres
 	|
   many headends connected to these
 	|
   users connected to headend (via OTNs)
Notes:

conclusions:
cable data networks:

Questions

Why low freq range for upstream?

Oversubscription strategies?

Some companies may still oversubscribe more than with modems?

Net reliability is decreasing??


RTFM (Real Time Traffic Flow Management)

Neville Brownee, University of Aukland

Outline:

attributes for TCP streams

To-From Sends and Acks:

a few new TCP attributes added in NeTraMet 4.3

Byte Lost percentage (BLP), a 'TCP Performance' indicator:

showed interesting plots

Sequence Decrease Percentage (SDP), another TCP indicator:

Turnaround times for tcp data

Graphs

TCP Transfer Performance

conclusions:

Questions, Comments:

Paul Vixie: ASNs might not be the best way to look at this. We need smaller bucket size - ie customer nets within ASNs. Eg 701 spans too many continents.

A: Agreed.

Ran Atkinson: can you extract similar netflow data from cisco router? useful alternative for Netramets to collect data?

Neville: cisco netflow has not primarily been developed as data collecting tool, it only gives summaries, can't see any detailed information netramet tool doesn't also try to be a router at the same time.


Y2K and Root Servers

Mark Kosters, NSI

Y2K program: What is InterNIC doing wrt to Y2K

Summary of programme:

Schedule:

Testing:

root NSes:

contingency planning:

what about the other root servers:

Phil: NSI has a lot of resources and has put a lot of effort into this. Has NSI been sharing the information with the other root name servers? Mark: exchange with other roots so far on an informal basis. General feel is that sharing their results will be ok, and will be happy to divulge what they have done.

Bill: a lot of root name server use GPS timing, and GPS rollover issue is coming up on 28 August 1999. Many people relying on GPS are issing "compliance statements" on this. Has NSI addressed it?

Mark: no

Brian: has this been discussed in the root name server advisory committee?

Mark: yes, and we will continue to do so.

Phil: last stats slide from A root NS sustain 2 Mbps of load. Are you provisioned to cope with more (6 or 7 times as mush) just in case the other servers break?

Mark: Would like to ensure that they are better provisioned even now, and trying to fight that battle internally inside NSI.

Paul Vixie: Y2K issues only a few additions:

Bill: probably almost all root NS would be able to answer all queries they receive on 1 Jan 2000, the question is if they receive the queries. the problem is not in the root NS system, it is in the telephone system. Spoke with US FCC. May be problems in this area, so FCC should prioritise circuit restoral, to ensure that root server system can get reconnected into infrastructure.

Paul ensures that the NS operators have loads of experience to operate root NS system, even with half the servers down. Internet doesn't stop to work, it just gets a little slower.


ARIN status report

Michael O'Neill

Overview:

stats for Jan,Feb 1999

 /24s issued to ISPs:          3496  3128
 /24s issued to end-users        80    48
 ASN's issued:                   74   110
 approved:                      110   118
 ASNs pending:                   58   159
 IP requests rejected:            4     2
 IP addresses transfers:         13     8
 
 new ISP requests:               87    96
 new IP requests:                45    27
 first time allocs to ISPs:      22    39
 of those multihomed-policies:    9    17
 rejected ISP requests:         n/a     3
 ISPs receiving allocation:      46    57
 
 number of allocations to ISP members in 1998:
 small (/24 - /19):             227
 medium (/18 - /16):            183
 large (/15 - /14):              32
 XLarge (/14):                    7

news, new initiatives, new policies:

ARIN routing registry

IPv6

ARIN staff introductions:

ARIN membership meeting:

URLs:

Questions:

Paula: is it a requirement to register the ASN in the routing registry now?

Michael: no, it is only encouraged

Phil: what is the scope on the grandfathered WG?

Kim: issues including

Randy Bush: How is the co-ordination with the other IRRs, e.g. the RADB. Thought that ARIN would take over the RR from Merit's RADB. Kim: this is not the idea at the moment, more co-ordination needed with Merit. discussion postponed til later when Abha is in the room. Initially the main idea was to link IP and RR to be able to verify announcements.


RIPE NCC Status report

Mirjam Kuehne

see http://www.ripe.net/meetings/pres/iepg-9903/


APNIC Status report

Paul Wilson

see http://www.apnic.net/presentations/IEPGmar99


BIND version 9

David Randy Conrad

Initial comment from Paul Vixie: recent developments re root server.

It is no longer possible to ftp the .com zone file from NSI. This has been the case for some time, but private arrangement existed to allow some people to access the files. This arrangement has recently ended.

ISC received advice from NSI asking that zone transfers be turned off, then sent email to other roots and others asking their advice - no decision made yet as to whether they should turn it off.


BIND version 9

BIND version 8.2 is in the final stages of beta, due for release tomorrow.

One remaining issue: some changes in the architecture required, which resulted in 30% increase of the memory consumption. Therefore Bind 8.2 couldn't be run on some root name servers. This has been resolved.

Other issues to be resolved relating to part implementation of DNSsec in BIND 8.2, and export restrictions.

Code (executable?) is publicly available on www.isc.org, but there is some question if ISC is allowed to self-classify this code. Government might ask them to stop in future (even though crypto is used for authorisation/signing, not for encryption).

Question: John Gilmore in conjunction with others (Network Associates) wrote DNS sec implementation around 6-9 months back. release was officially approved. it was then referenced in a book and the government realised that DNS sec can't be shipped anymore.

A: DRC - details, including stripping of Des and other code to ensure that only authentication is done, and not any encryption. TIS DSA (Digital Sig Algorithm) can be exported.

Major issue is that code is publicly available, that means everyone can go ahead and implement strong cryptography.

BIND 9:

In august 98, unix vendors agreed with ISC to fund new version. Feature requirements:

Operational issues:

Note DNS protocol has become vastly more complex.

ISC not sure that IPv6, DNS sec, A6 records, and other stuff can scale globally on the "live" Internet. Code will work, but successful deployment yet to be proven.

A6 records give a major potential problem: single query - multiple secondary queries - multiple answers (big potential for denial of service attacks)

Implementation and porting:

Due to limitations of BIND 8 (single threaded, hard to maintain etc), ISC decided to redesign and reimplement BIND 9.

(bind 9 was called "deep space bind")

First code drop has been made to funding organisations, but little feedback so far.

Ported to Solaris 251, hpux, aix, irix, digital, linux, freebsd, netbsd, openbsd, bsdi. Also to AS400 and others.

NT support not deliverable at this stage (noone funded it!), but ISC is taking care to ensure it can be done if funding arrives.

Brian: can you explain the issues around IPv6

A: have you done an analysis. might be a chicken and egg problem, since IPv6 is not deployed yet. But what are you concerned about?

Paul Vixie: where one query can result in more work required in answer than in generating the query, there is a problem. especially if increase in work is exponential with recursive queries. Denial of service attack could be v easy. if there were no multi-homing and renumbering requirements, it would be a lot easier.


DNS root-server queries (A few scary notes)

Maurizio, LINX

RIPE NCC operate the K root server, host it at LINX (London Internet Exchange)

Has heard it said that 18% Of total packets on the net are DNS traffic??? (but not sure of this)

 Diagram:
 
   transit ISPs
     | | | |
   transit router -
  • collector Router | k root server
  • traffic statistics:

    Query type distribution:

       A  77%
       NS 15%
       MX 5%
       Etc
     
       .2% IPv6 queries?
    

    Scary statistics:

    26% valid root domain queries
    6% valid queries, but server can't answer in authoritative way (.com, .net etc.)
    .5% valid queries for TLD domain,br> 66% queries for non existent TLDs
    (probably to do with Windows)

    Hit parade of weird domain queries:

    desktop, loopback, notes, mail, http, hotmail, yahoo, www, proxy, server, Internet, news, Internet, exchange...

    (request -pls put this on the IEPG list)

    Paul Vixie: this is consistent which what he sees at F. Agree that it seems to be NT workgroup and similar names, and because clients have no "negative name caches" errors not remembered and the queries get repeated - up to 10 times/sec.

    Question: what if we sent an answer in response to these bad names eg 127.0.0.1?

    no objections - people seem to like the idea.

    Paul V will take it up with the IANA people.

    Lars-Johan Liman: supports this. Harvard Eidnes did statistics and found out that much is originated from one place, there is a region or a ISP that has deployed certain SW to TCP queries. new version of this SW doesn't have this implemented, but old version is still around.


    Observations on Internet Routing

    Abha Ahuja, Merit.

    Measurement Infrastructure

    Route tracker:

    Review:

    Problems:

    has been fixed over time
    in 1996 huge number of withdrawals, now reduced with update of router SW

    Internet failures analysis

    default free route

    how long does it take to get failures fixed:

    reasons of failure:

    want to find out the reasons for each outage.

    looking for people who provide them with their default-free routing tables.

    See details on the Web:
    http://www.merit.edu/ipma
    - follow links to papers and graphs.


    Visualisation of Internet routing tables

    Kim Claffy, CAIDA

    Summary:

    Demo and discussion of Skitter software for visualising BGP routing table.

    URLc/o CAIDA


    Other discussion:

    Question re Merit vs ARIN routing registry

    Abha:

    Transition was discussed, but not under active discussion any more. Discussion should resume. RADB will continue, for as long as people keep putting data there.


    Next meeting:

    there is still a general desire to have one, so will be announced in advance of next ietf, on mailing list.