All, At SIGCOMM 2004, it became clear that the current beacon prefixes suffer from 2 problems: a) They have more peers giving transit than any other AS on the Internet. b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should be one anchor per beacon. So, people suggested that for the next period (1/10/2004-30/9/2005), we make the following changes: 1. A new /19 is requested from the RIPE NCC. This /19 is split into /24's. 2. Each RRC annouces 2 /24's. Assuming A.B.Z is the base address A.B.(Z+2*Y).0/24 A.B.(Z+2*Y+1).0/24 For Y=0 to 13 for the (up to 16) RRC's. The first prefix is announced permanently. The second one is a flapping prefix: up at 0 GMT, down at 2 GMT, up at 4 GMT etc. The pattern may be changed at a later stage. 3. Inside each /24, a pingable address will be established. 4. We ask only 2 or 3 peers at each IX to provide transit for these prefixes. (In other words, we do not ask everybody). 5. Other experiments that we do are: - An overflow prefix (prefix announced at 1 RRC, flapping at the next). - Hitesh's experiment. 6. The current 195.80.224.0/20 is returned to the RIPE NCC Comments? Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ In a room with a window in the corner, I found truth. (Ian Curtis)
Henk Uijterwaal (RIPE NCC) wrote:
All,
At SIGCOMM 2004, it became clear that the current beacon prefixes suffer from 2 problems:
a) They have more peers giving transit than any other AS on the Internet.
b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should be one anchor per beacon.
So, people suggested that for the next period (1/10/2004-30/9/2005), we make the following changes:
1. A new /19 is requested from the RIPE NCC. This /19 is split into /24's.
2. Each RRC annouces 2 /24's. Assuming A.B.Z is the base address
A.B.(Z+2*Y).0/24 A.B.(Z+2*Y+1).0/24
For Y=0 to 13 for the (up to 16) RRC's.
The first prefix is announced permanently. The second one is a flapping prefix: up at 0 GMT, down at 2 GMT, up at 4 GMT etc. The pattern may be changed at a later stage.
3. Inside each /24, a pingable address will be established.
4. We ask only 2 or 3 peers at each IX to provide transit for these prefixes. (In other words, we do not ask everybody).
5. Other experiments that we do are:
- An overflow prefix (prefix announced at 1 RRC, flapping at the next). - Hitesh's experiment.
6. The current 195.80.224.0/20 is returned to the RIPE NCC
Comments?
This looks good to me. -- Shane Kerr RIPE NCC
Hi Henk,
a) They have more peers giving transit than any other AS on the Internet.
This was discussed internally right from day one of RIS beacon project. Good that the research community have confirmed concerns raised back then.
b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should
be one anchor
per beacon.
Yup, our beacons were deemed practically useless in the paper by Mao, Bush et al, so it's good that we're finally fixing above. What about timestamping and sequence numbers in the BGP messages? Was this also something that needed to be addressed? Cheers, Matthew
-----Original Message----- From: ris-int-admin@ripe.net [mailto:ris-int-admin@ripe.net] On Behalf Of Shane Kerr Sent: 28 September 2004 12:25 To: Henk Uijterwaal (RIPE NCC) Cc: zmao@eecs.umich.edu; ris-int@ripe.net Subject: Re: [ris-int] RIS Beacons
Henk Uijterwaal (RIPE NCC) wrote:
All,
At SIGCOMM 2004, it became clear that the current beacon prefixes suffer from 2 problems:
a) They have more peers giving transit than any other AS on the Internet.
b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should be one anchor per beacon.
So, people suggested that for the next period (1/10/2004-30/9/2005), we make the following changes:
1. A new /19 is requested from the RIPE NCC. This /19 is split into /24's.
2. Each RRC annouces 2 /24's. Assuming A.B.Z is the base address
A.B.(Z+2*Y).0/24 A.B.(Z+2*Y+1).0/24
For Y=0 to 13 for the (up to 16) RRC's.
The first prefix is announced permanently. The second one is a flapping prefix: up at 0 GMT, down at 2 GMT, up at 4 GMT etc. The pattern may be changed at a later stage.
3. Inside each /24, a pingable address will be established.
4. We ask only 2 or 3 peers at each IX to provide transit for these prefixes. (In other words, we do not ask everybody).
5. Other experiments that we do are:
- An overflow prefix (prefix announced at 1 RRC, flapping at the next). - Hitesh's experiment.
6. The current 195.80.224.0/20 is returned to the RIPE NCC
Comments?
This looks good to me.
-- Shane Kerr RIPE NCC
Hi Henk and Matthew, Thanks very much for including me on these emails. I have also CC'd Ramesh Govindan and Paul Francis who are also interested in using the Beacons.
a) They have more peers giving transit than any other AS on the Internet.
This was discussed internally right from day one of RIS beacon project. Good that the research community have confirmed concerns raised back then.
Would it be possible to set up the experiment such that the beacon alternates across the different upstream providers, i.e., at one point announced by two providers, then withdraw from one, re-announce to another one, etc? And iterate using another two different providers. For one of the multi-homed PSG beacons (hosted by Randy Bush), we are performing this experiment (shown http://www.psg.com/~zmao/beacon5.jpg) to understand the effect of fail over behavior. Perhaps something similar to this can be set up in the RIS beacon project. This would be very interesting to study.
b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should
be one anchor
per beacon.
Yup, our beacons were deemed practically useless in the paper by Mao, Bush et al, so it's good that we're finally fixing above.
What about timestamping and sequence numbers in the BGP messages? Was this also something that needed to be addressed?
Perhaps a similar scheme to the PSG beacons can be adopted. Right now, for PSG beacons we are overloading the Aggregator AS field to denote the sequence number (each new announcement has a seq number incremented from the old one), and aggregator IP field to denote the time at which the message is sent out. To prevent people from misinterpreting these two fields, we make sure that the Aggregator AS is in the private AS range (64512-65535), and the Aggregator IP is also in the private address range (e.g., 10/8). Thanks! --Morley
Cheers, Matthew
-----Original Message----- From: ris-int-admin@ripe.net [mailto:ris-int-admin@ripe.net] On Behalf Of Shane Kerr Sent: 28 September 2004 12:25 To: Henk Uijterwaal (RIPE NCC) Cc: zmao@eecs.umich.edu; ris-int@ripe.net Subject: Re: [ris-int] RIS Beacons
Henk Uijterwaal (RIPE NCC) wrote:
All,
At SIGCOMM 2004, it became clear that the current beacon prefixes suffer from 2 problems:
a) They have more peers giving transit than any other AS on the Internet.
b) When a prefix is invisible, it is not clear if this is caused by an experimental problem or by the prefix being filtered. The anchor prefix does not solve this problem, there should be one anchor per beacon.
So, people suggested that for the next period (1/10/2004-30/9/2005), we make the following changes:
1. A new /19 is requested from the RIPE NCC. This /19 is split into /24's.
2. Each RRC annouces 2 /24's. Assuming A.B.Z is the base address
A.B.(Z+2*Y).0/24 A.B.(Z+2*Y+1).0/24
For Y=0 to 13 for the (up to 16) RRC's.
The first prefix is announced permanently. The second one is a flapping prefix: up at 0 GMT, down at 2 GMT, up at 4 GMT etc. The pattern may be changed at a later stage.
3. Inside each /24, a pingable address will be established.
4. We ask only 2 or 3 peers at each IX to provide transit for these prefixes. (In other words, we do not ask everybody).
5. Other experiments that we do are:
- An overflow prefix (prefix announced at 1 RRC, flapping at the next). - Hitesh's experiment.
6. The current 195.80.224.0/20 is returned to the RIPE NCC
Comments?
This looks good to me.
-- Shane Kerr RIPE NCC
participants (4)
-
Henk Uijterwaal (RIPE NCC) -
Matthew Williams -
Shane Kerr -
Z. Morley Mao