Peering point speed publicly available?

Fri Jul 2 02:01:48 UTC 2004

Latency does have a impact on TCP transfers, now granted the difference between a oc-3 and oc-192 is negligible, but if you stack a lot of T1 connections back to back its going to be a factor in your max throughput across the path.

(Stats below might not exactly be accurate...snipped from another site)

DS3: (1500 bytes * 8 bits/byte) / 44040192 bits/sec = .27 ms (approx)
DS1: (1500 bytes * 8 bits/byte) / 1572864 bits/sec = 8 ms (approx)
DS0: (1500 bytes * 8 bits/byte) / 65536 bits/sec = 183 ms (approx)

If you don't think it does then run some ftp transfers end to end with 1ms of delay, and with 100ms, 200ms, 500ms, 1000 ms

I never said that .002 microseconds is going to have a noticeable difference, but those 10ms - 20ms hops starts to add up. As well as propagation delay as you stated. 

-C

-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Thursday, July 01, 2004 7:30 PM
To: Cody Lerum
Cc: Tony Li; erik at myevilempire.net; nanog at merit.edu; network.support at oati.net
Subject: Re: Peering point speed publicly available?

On Thu, Jul 01, 2004 at 07:05:51PM -0600, Cody Lerum wrote:
> 
> Work with the network operators on each side of the link to determine
> the speed/load. For the most part if they really want your business, 
> they will be able to provide something.

Actually, many larger peering relationships come with contracts which 
explicitly forbid them from telling you any details about link capacity or 
utilization, or in some cases even acknowledging that peering exists. They 
might tell you anyways though. :)

For the most part, it is hope for descriptive DNS or bust. For the most 
part, DNS is not descriptive (especially on peering links). :)

> The main reason link speed maybe important to me would serialization
> delay on the circuit. OC-768 should be much lower latency than a
> T1...unless your are at the end of the queue :-)

Once you get past 10Mbps, serialization delay is measured in fractions of 
a millisecond. This has absolutely no impact on TCP performance, compared 
to speed of light delays (like from oh say a 50ft patch cable).

> Latency is probably be your primary concern for large TCP transfers
> anyway.

I think that you are very confused about how TCP works.

> >  4 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113)  20.436 ms  18.309 ms  
> > 17.605 ms   <------------DS3
> >   5  so1-0-0-2488M.ar4.SEA1.gblx.net (67.17.71.210)  17.607 ms  16.982 
> > ms  16.971 ms  <-----OC-48
> >  6  p3-3.IR1.Seattle-WA.us.xo.net (206.111.7.5)  17.864 ms  19.491 ms  
> > 17.181 ms

Name:    p3-3.IR1.Seattle-WA.us.xo.net
Address:  206.111.7.5

Name:    206.111.7.6.ptr.us.xo.net
Address:  206.111.7.6

Sometimes you can find descriptive DNS on the other side of the PTR, and
sometimes you find missing data. In this case, there is no speed
description at all. The p3-3 interface indicates that this is a PoS
interface, probably Cisco, and the IR designation on XO indicates a
peering router. Educated hunch based on what the traffic levels between
3549 and 2828 in Seattle probably are... OC3?

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)