Re: Emulating ADSL bandwidth shaping

[Aria Stewart]

On May 3, 2010, at 9:19 PM, Patrick Giagnocavo wrote:
>> - do ISPs typically use token bucket filters with large bursts to shape 
>> traffic?
>> - what kind of burst sizes and latencies/limits are typically used for
>> the filter?
>> 
> 
> You will definitely have to account for latency.
> 
> For emulating cable traffic, latencies (in the USA) will be about
> 60-80ms to typical sites.  Burst mode in my experience occurs only for
> about the first 15 seconds, then is throttled back (though not always;
> seems to depend on time of day).
> 

And queues of 1 second at line rate are not uncommon, so if you load the link, 
things lag. 

> For DSL, I seem to recall latency being about 90-110ms (note, I haven't
> used DSL in many years).  Burst mode was generally not noticeable or
> available, that is, you got the same speed regardless of downloading a
> 1MB jpeg or a 640MB .iso  file.

Now more typically 40ms. And yeah, no bursts over normal line rate. Most turn 
down line rate for other plans, not shape.

Re: Emulating ADSL bandwidth shaping

[Patrick Giagnocavo]

Srikanth Sundaresan wrote:
> I'm trying to model ADSL access link bandwidth shaping. With a link of
> 18Mbps, I'm using a token bucket filter (tc + netem) to model 10Mbps,
> 8Mbps and 2Mbps access plans. I have a couple of questions:
> 
> - do ISPs typically use token bucket filters with large bursts to shape 
> traffic?
> - what kind of burst sizes and latencies/limits are typically used for
> the filter?
> 

You will definitely have to account for latency.

For emulating cable traffic, latencies (in the USA) will be about
60-80ms to typical sites.  Burst mode in my experience occurs only for
about the first 15 seconds, then is throttled back (though not always;
seems to depend on time of day).

For DSL, I seem to recall latency being about 90-110ms (note, I haven't
used DSL in many years).  Burst mode was generally not noticeable or
available, that is, you got the same speed regardless of downloading a
1MB jpeg or a 640MB .iso  file.

IMHO, IME, ISTR, YMMV...

--Patrick

Emulating ADSL bandwidth shaping

[Srikanth Sundaresan]

I'm trying to model ADSL access link bandwidth shaping. With a link of
18Mbps, I'm using a token bucket filter (tc + netem) to model 10Mbps,
8Mbps and 2Mbps access plans. I have a couple of questions:

- do ISPs typically use token bucket filters with large bursts to shape traffic?
- what kind of burst sizes and latencies/limits are typically used for
the filter?

Thanks in advance,
Srikanth

Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[Bill Bogstad]

On Mon, May 3, 2010 at 2:27 PM, Gregory Edigarov
 wrote:
> On Mon, 3 May 2010 14:12:45 -0400
> Holly shit... Where do you live? In Ukraine we have almost no
> difference (well it is different from one company to another) between
> commercial and residental setups. At least it is so with smaller
> providers like one I have at home and one I work for (they are two
> different companies).
> So it seems very very strange to me you need to justify anything with
> your network operator.

North America.   Specifically the Boston metro area of the USA.   It's
fairly common here to put all kinds of type of service restrictions on
residential Internet connectivity.   From what I've read on NANOG over
the years, I thought this was common practice worldwide, but it sounds
like that might not be the case in the Ukraine.

Thanks,
Bill Bogstad

Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[Steven Bellovin]

> 
> 
> - many ISPs, especially cable modem, have annoying policies that say
> you can't run a server at home.  But many don't.

Right.  Often, this is due to a combination of technology limitations -- with 
DSL, upstream and downstream bandwidths are tradeoffs; with cable modems, 
limited upstream bandwidth is inherent in the technology -- coupled with an 
obsolete model that assumes that consumers mostly download.

Besides, if you can charge more for business service, why not...?


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[William Pitcock]

On Mon, 2010-05-03 at 14:12 -0400, Bill Bogstad wrote:
> Like many people, I can't justify the expense of "commercial" IP
> connectivity for my residence.  As a result, I deal with dynamic IP
> addresses; dns issues; and limitations on the services that I can host
> at my residence.  It just struck me that in the same way that
> IPv6 connectivity can be done via tunneling over IPv4 (Hurricane
> Electric, etc.), that static IPv4 addressability could be offered in a
> similar fashion.
> 
> Some my question is:
> 
> Does anyone offer (probably bandwidth restricted) IPv4 over IPv4
> tunneling (with static IPs) commercially?
> 
> I realize that making use of such a service MIGHT violate Terms of
> Service agreements, but that is going to vary from provider to
> provider and doesn't make offering such a service inherently wrong.
> Other possible reasons such services might be desired include wanting
> access to Internet services which are regionally restricted.  (Again
> TOS violation possibilities MAY or MAY NOT apply.)
> 
> In the (very?) long term, IPv4 over IPv6 tunneling could end up being
> one way that organizations can get IPv4 connectivity when the default
> changes from only-IPv4 to only-IPv6.  (Yeah, I know that day may never
> come...)
> 
> Thanks,
> Bill Bogstad
> 

You could do this with a VPS.  Make sure they run Xen or KVM or VMware
though, so you have control over the routing table.

William

Re: Surcharge for providing Internet routes?

[Bill Stewart]

Back when I was on that side of the house, if you bought transit from
7018 and were managing your own routers, you got your choice of BGP or
static, and BGP could have full routes, our-customer routes, default
routes, and maybe some other variants.  No charge for any of those
options, but if you wanted full routes you'd need a hefty enough
router, and if you thought you wanted full routes on your T1 line we'd
offer you some hints about that not being a good idea.   Other than
that, full routes burned a bit of extra bandwidth, so if you had
usage-based pricing that might have some minor effects.

(If we were managing your routers, you usually weren't in the
dual-homing business, or at least we'd be charging you more for a
fatter router and managing the extra complexity of whatever you needed
done locally, but all of that was just router management pricing, not
network pricing.)


-- 

 Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[Bill Stewart]

> On Mon, 3 May 2010 14:12:45 -0400
> Bill Bogstad  wrote:
>> Like many people, I can't justify the expense of "commercial" IP
>> connectivity for my residence.  As a result, I deal with dynamic IP ..

On Mon, May 3, 2010 at 11:27 AM, Gregory Edigarov
 wrote:
> Holly shit... Where do you live? In Ukraine we have almost no
> difference (well it is different from one company to another) between
> commercial and residental setups. At least it is so with smaller
> providers like one I have at home and one I work for (they are two
> different companies).
> So it seems very very strange to me you need to justify anything with
> your network operator.

In most of the US, the standard residential ISP service gives you
- some amount of bandwidth, usually asynchronous
- dynamic IP address (with static available for a higher price)
- some service quality and repair speed guarantees
- many ISPs, especially cable modem, have annoying policies that say
you can't run a server at home.  But many don't.
- some ISPs are starting to get the idea tha

Most of the ISPs that provide that kind of service offer business
service using the residential technology
- higher price
- better service quality and repair speed guarantees
- static IP addresses, and you can run a server



-- 

 Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[Chris Grundemann]

On Mon, May 3, 2010 at 12:12, Bill Bogstad  wrote:
> Like many people, I can't justify the expense of "commercial" IP
> connectivity for my residence.  As a result, I deal with dynamic IP
> addresses; dns issues; and limitations on the services that I can host
> at my residence.


Not sure where you live / what service is available to you but many
"business" DSL, cable and fixed-wireless offerings are quite
reasonably priced these days.  I pay about $100/mo for 16m x 2m and a
/28 from my local cable operator - which is likely less than
residential service plus a vpn/tunnel service. It sure isn't a fiber
metro-E connection but it does let me run my various servers out of
the house. Perhaps something to look into.

$0.02
~Chris

>
> Thanks,
> Bill Bogstad
>
>


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org

Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[Gregory Edigarov]

On Mon, 3 May 2010 14:12:45 -0400
Bill Bogstad  wrote:

> Like many people, I can't justify the expense of "commercial" IP
> connectivity for my residence.  As a result, I deal with dynamic IP
> addresses; dns issues; and limitations on the services that I can host
> at my residence.  It just struck me that in the same way that
> IPv6 connectivity can be done via tunneling over IPv4 (Hurricane
> Electric, etc.), that static IPv4 addressability could be offered in a
> similar fashion.
> 
> Some my question is:
> 
> Does anyone offer (probably bandwidth restricted) IPv4 over IPv4
> tunneling (with static IPs) commercially?
> 
> I realize that making use of such a service MIGHT violate Terms of
> Service agreements, but that is going to vary from provider to
> provider and doesn't make offering such a service inherently wrong.
> Other possible reasons such services might be desired include wanting
> access to Internet services which are regionally restricted.  (Again
> TOS violation possibilities MAY or MAY NOT apply.)
> 
> In the (very?) long term, IPv4 over IPv6 tunneling could end up being
> one way that organizations can get IPv4 connectivity when the default
> changes from only-IPv4 to only-IPv6.  (Yeah, I know that day may never
> come...)

Holly shit... Where do you live? In Ukraine we have almost no
difference (well it is different from one company to another) between
commercial and residental setups. At least it is so with smaller
providers like one I have at home and one I work for (they are two
different companies).
So it seems very very strange to me you need to justify anything with
your network operator. 

-- 
With best regards,
Gregory Edigarov

Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[Brandon Galbraith]

http://www.google.com/search?q=vpn+service

Encryption would be a side benefit for your purpose.

On Mon, May 3, 2010 at 1:12 PM, Bill Bogstad  wrote:

> Like many people, I can't justify the expense of "commercial" IP
> connectivity for my residence.  As a result, I deal with dynamic IP
> addresses; dns issues; and limitations on the services that I can host
> at my residence.  It just struck me that in the same way that
> IPv6 connectivity can be done via tunneling over IPv4 (Hurricane
> Electric, etc.), that static IPv4 addressability could be offered in a
> similar fashion.
>
> Some my question is:
>
> Does anyone offer (probably bandwidth restricted) IPv4 over IPv4
> tunneling (with static IPs) commercially?
>
> I realize that making use of such a service MIGHT violate Terms of
> Service agreements, but that is going to vary from provider to
> provider and doesn't make offering such a service inherently wrong.
> Other possible reasons such services might be desired include wanting
> access to Internet services which are regionally restricted.  (Again
> TOS violation possibilities MAY or MAY NOT apply.)
>
> In the (very?) long term, IPv4 over IPv6 tunneling could end up being
> one way that organizations can get IPv4 connectivity when the default
> changes from only-IPv4 to only-IPv6.  (Yeah, I know that day may never
> come...)
>
> Thanks,
> Bill Bogstad
>
>


-- 
Brandon Galbraith
Voice: 630.492.0464

any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants?

[Bill Bogstad]

Like many people, I can't justify the expense of "commercial" IP
connectivity for my residence.  As a result, I deal with dynamic IP
addresses; dns issues; and limitations on the services that I can host
at my residence.  It just struck me that in the same way that
IPv6 connectivity can be done via tunneling over IPv4 (Hurricane
Electric, etc.), that static IPv4 addressability could be offered in a
similar fashion.

Some my question is:

Does anyone offer (probably bandwidth restricted) IPv4 over IPv4
tunneling (with static IPs) commercially?

I realize that making use of such a service MIGHT violate Terms of
Service agreements, but that is going to vary from provider to
provider and doesn't make offering such a service inherently wrong.
Other possible reasons such services might be desired include wanting
access to Internet services which are regionally restricted.  (Again
TOS violation possibilities MAY or MAY NOT apply.)

In the (very?) long term, IPv4 over IPv6 tunneling could end up being
one way that organizations can get IPv4 connectivity when the default
changes from only-IPv4 to only-IPv6.  (Yeah, I know that day may never
come...)

Thanks,
Bill Bogstad

Re: Surcharge for providing Internet routes?

[Patrick W. Gilmore]

On May 3, 2010, at 10:43 AM, Will Hargrave wrote:
> On 3 May 2010, at 05:27, Matthew Petach wrote:
>> In Asia, there is a popular, but incorrectly named product offering
>> that many ISPs sell called "domestic transit" which they sell
>> for price $X; for "full routes" you often pay $2X-$3X.  I grind my
>> teeth every time I hear it, since "transit" doesn't mean "to select
>> parts of the internet" in most people's eyes.  It's really a paid
>> peering offering, but no matter how much I try to correct people,
>> the habit of calling it "domestic transit" still persists.  :(
> 
> 
> This is relatively common in europe too - normally under the name 'partial 
> transit'.

At least they are naming it correctly.


> paid peering: [provider AS] + [providers customers] 
> partial transit: [provider AS] + [providers customers] + [providers peers]
> 
> Pricing is typically 5-20% of the cost of full routes, and will provide in 
> the region of 40-120k routes.

And pricing it correctly!

Let's see, transit is at $1/Mbps, so I can get 120K prefixes for $0.05/Mbps? 


-- 
TTFN,
patrick

Re: Surcharge for providing Internet routes?

[Will Hargrave]

On 3 May 2010, at 05:27, Matthew Petach wrote:
> In Asia, there is a popular, but incorrectly named product offering
> that many ISPs sell called "domestic transit" which they sell
> for price $X; for "full routes" you often pay $2X-$3X.  I grind my
> teeth every time I hear it, since "transit" doesn't mean "to select
> parts of the internet" in most people's eyes.  It's really a paid
> peering offering, but no matter how much I try to correct people,
> the habit of calling it "domestic transit" still persists.  :(


This is relatively common in europe too - normally under the name 'partial 
transit'.

paid peering: [provider AS] + [providers customers] 
partial transit: [provider AS] + [providers customers] + [providers peers]

Pricing is typically 5-20% of the cost of full routes, and will provide in the 
region of 40-120k routes.

IPv6 Ripeness

[Vesna Manojlovic]

[warning - statistics!]

Dear colleagues,

we have published an article on the RIPE Labs about the IPv6 Ripeness - 
a method of rating the v6 deployment of LIRs (Local Internet Registries) 
in RIPE NCC service region:


http://labs.ripe.net/content/ipv6-ripeness

In total: 8% of all (6.7K) LIRs have "4 stars", 27% have at least v6 space.
Top results are for Slovenia: 25% "4 stars", and 67% v6 space!

For now, we summarized the results per country. But, we have big plans 
for the future ...


Please take a look, and tell us how useful you find it, and how can we 
make it better.


Regards,
Vesna Manojlovic
RIPE NCC Trainer

Root Zone DNSSEC Deployment Technical Status Update

[Joe Abley]

Root Zone DNSSEC Deployment
Technical Status Update 2010-05-03

This is the fifth of a series of technical status updates intended
to inform a technical audience on progress in signing the root zone
of the DNS.


**  The final transition to the DURZ will take place on
**  J-Root, on 2010-05-05 between 1700--1900 UTC.
**
**  After that maintenance all root servers will be serving the
**  DURZ, and will generate larger responses to DNS
**  queries that request DNSSEC information.
**
**  If you experience technical problems or need to contact
**  technical project staff, please send e-mail to roots...@icann.org
**  or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred
**  if possible.
**
**  See below for more details.


RESOURCES

Details of the project, including documentation published to date,
can be found at .

We'd like to hear from you. If you have feedback for us, please
send it to roots...@icann.org.


DEPLOYMENT STATUS

The incremental deployment of DNSSEC in the Root Zone is being
carried out first by serving a Deliberately Unvalidatable Root Zone
(DURZ), and subsequently by a conventionally signed root zone.
Discussion of the approach can be found in the document "DNSSEC
Deployment for the Root Zone", as well as in the technical presentations
delivered at RIPE, NANOG, IETF and ICANN meetings.

Twelve of the thirteen root servers have already made the transition
to the DURZ.  No harmful effects have been identified.

The final root server to make the transition, J-Root, will start
serving the DURZ in a maintenance window scheduled for 1700--1900
UTC on 2010-05-05.

Initial observations relating to this transition will be presented
and discussed at the DNS Working Group meeting at the RIPE meeting
in Prague on 2010-05-06.


PLANNED DEPLOYMENT SCHEDULE

Already completed:

  2010-01-27: L starts to serve DURZ

  2010-02-10: A starts to serve DURZ

  2010-03-03: M, I start to serve DURZ

  2010-03-24: D, K, E start to serve DURZ

  2010-04-14: B, H, C, G, F start to serve DURZ

To come:

  2010-05-05: J starts to serve DURZ

  2010-07-01: Distribution of validatable, production, signed root
zone; publication of root zone trust anchor

  (Please note that this schedule is tentative and subject to change
  based on testing results or other unforeseen factors.)

A more detailed DURZ transition timetable with maintenance windows
can be found in the document "DNSSEC Deployment for the Root Zone",
the most recent draft of which can be found on the project web page
at .

Re: MikroTik strikes again ?

[Alexander Harrowell]

On Monday 03 May 2010 11:25:45 Bret Clark wrote:
> Uhmokay...but why does anyone prepend their ASN that much? Are you 
> saying the Mikrotik did that on purpose?
> 

There was a well-known routing incident last year in which a difference 
between the Mikrotik and Cisco CLIs caused the propagation of extremely long 
AS-PATH attributes, which caused certain Cisco routers to crash.

Basically, someone remembered their Cisco IOS syntax and typed "bgp-prepend 
47868" into a Mikrotik; the correct syntax would have been "bgp-prepend x 
47868" where x is an integer between 0 and 16 representing the desired number 
of prepends. The Mikrotik correctly tried to prepend 47868 47868 times, but 
had only one byte to store this value and therefore produced 255 prepends.

Some Cisco machines, it turned out, had a bug that caused path lengths close 
to 255 to crash them. Fun and games ensued.

The Renesys blog has much, much more: 
http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml
-- 
The only thing worse than e-mail disclaimers...is people who send e-mail to 
lists complaining about them


signature.asc
Description: This is a digitally signed message part.

Re: MikroTik strikes again ?

[Bret Clark]

Tim Warnock wrote:

Adrian M wrote:


MikroTik strikes again ?

%BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
  

From: Bret Clark [mailto:bcl...@spectraaccess.com]
Sent: Monday, 3 May 2010 8:26 PM
To: nanog@nanog.org
Subject: Re: MikroTik strikes again ?

Uhmokay...but why does anyone prepend their ASN that much? Are you
saying the Mikrotik did that on purpose?




MikroTik asks for an amount of prepends rather than what ASN to prepend
with.

There was a bug in an old version that would modulus the ASN with 256 and
prepend that many times.

In this case 39625 modulo 256 = 201 prepends.
 



  

Yeah...guess I see why that would be a problem.

Re: MikroTik strikes again ?

[Christian]

It's not really a bug, only a matter of habbit I guess :)
I read this some time ago in nanog list:
http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml

regards,
Christian

Bret Clark wrote:
Uhmokay...but why does anyone prepend their ASN that much? Are you 
saying the Mikrotik did that on purpose?


Adrian M wrote:

MikroTik strikes again ?

%BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 received from : More than configured
MAXAS-LIMIT

aut-num: AS39625
as-name: ARANEO-AS
descr:  Omni-Araneo's AS number
org: ORG-OSTW3-RIPE
import:  from AS12968 action pref=100; accept ANY
export:  to AS12968 announce AS39625
import:  from AS39412 action pref=100; accept ANY
export:  to AS39412 announce AS39625
admin-c: TW1273-RIPE
tech-c:  TW1273-RIPE
mnt-by:  AS12968-MNT
mnt-routes:  AS12968-MNT
source:  RIPE # Filtered

  

RE: MikroTik strikes again ?

[Tim Warnock]

> Adrian M wrote:
> > MikroTik strikes again ?
> >
> > %BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625
> > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
>
> From: Bret Clark [mailto:bcl...@spectraaccess.com]
> Sent: Monday, 3 May 2010 8:26 PM
> To: nanog@nanog.org
> Subject: Re: MikroTik strikes again ?
> 
> Uhmokay...but why does anyone prepend their ASN that much? Are you
> saying the Mikrotik did that on purpose?
>

MikroTik asks for an amount of prepends rather than what ASN to prepend
with.

There was a bug in an old version that would modulus the ASN with 256 and
prepend that many times.

In this case 39625 modulo 256 = 201 prepends.
 

Re: MikroTik strikes again ?

[Bret Clark]

Uhmokay...but why does anyone prepend their ASN that much? Are you 
saying the Mikrotik did that on purpose?


Adrian M wrote:

MikroTik strikes again ?

%BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 received from : More than configured
MAXAS-LIMIT

aut-num: AS39625
as-name: ARANEO-AS
descr:  Omni-Araneo's AS number
org: ORG-OSTW3-RIPE
import:  from AS12968 action pref=100; accept ANY
export:  to AS12968 announce AS39625
import:  from AS39412 action pref=100; accept ANY
export:  to AS39412 announce AS39625
admin-c: TW1273-RIPE
tech-c:  TW1273-RIPE
mnt-by:  AS12968-MNT
mnt-routes:  AS12968-MNT
source:  RIPE # Filtered

  

MikroTik strikes again ?

[Adrian M]

MikroTik strikes again ?

%BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625
39625 39625 39625 39625 received from : More than configured
MAXAS-LIMIT

aut-num: AS39625
as-name: ARANEO-AS
descr:  Omni-Araneo's AS number
org: ORG-OSTW3-RIPE
import:  from AS12968 action pref=100; accept ANY
export:  to AS12968 announce AS39625
import:  from AS39412 action pref=100; accept ANY
export:  to AS39412 announce AS39625
admin-c: TW1273-RIPE
tech-c:  TW1273-RIPE
mnt-by:  AS12968-MNT
mnt-routes:  AS12968-MNT
source:  RIPE # Filtered

Re: Surcharge for providing Internet routes?

[Randy Bush]

> Just to clarify, there are both domestic transit and country specific 
> paid peering products out there in Asia/Pacific region.

and europe.  and ...

randy