Mailing List Archive

Mornin' Guy,

> [] to what extent does a given exchange point (NAP/MAE/etc) constrain
> the performance that a user sees (in what a user thinks of as end-
> to-end). For example, an FTP could flow at 800 kb/s for a given
> pair of users, except that MAE-north is congested, so the FTP can
> only flow at 400 kb/s.

And what type of congestion is it, medium? switch? router? transport? I
need to know what to fix.

> [] to what extent does a given exchange point constrain the performance
> that a provider sees (in what a provider thinks of as end-to-end).
> For example, a given pair of backbones could sustain 20 Mb/s over a
> private interconnect with acceptable packet loss, but can only sustain
> 10 Mb/s over the Altoona NAP.
> From different perspectives, each of these notions of end-to-end has
> meaning. Would you want to consider one or the other or both in the
> panel?

It's the users who pay the bills, but it's only at the provider level that I
(a self-appointed NANOG archetype) can act. Being vastly undereducated, I
am forced to consider both at the moment. If I get smarter (fat chance),
focus may be more appropriate. Feel free to have a bash (and that's what it
takes sometimes) to educate me.

randy
- - - - - - - - - - - - - - - - -

Curtis Villamizar <curtis@ans.net> writes:

> This is an interesting problem and actually close to solvable at the
> IP level. I'm sure you are familiar with PPP LQM. Take out the PPP
> part and keep the LQM packet format and local storage. Keep one LQM
> struct per ARP entry on a bcast or nbma interface (such as an ATM
> NAP). Count packets used by each ARP entry and update SNMP and the
> LQM entry as you would in PPP LQM. Occasionally (once a second is
> fine) send an LQM packet summarizing what has been sent.

This is a very good idea. You might want to hand it over
to your vendor before I hand it over to mine. :-)

Sean.
- - - - - - - - - - - - - - - - -

> > This is an interesting problem and actually close to solvable at the
> > IP level. I'm sure you are familiar with PPP LQM. Take out the PPP
> > part and keep the LQM packet format and local storage. Keep one LQM
> > struct per ARP entry on a bcast or nbma interface (such as an ATM
> > NAP). Count packets used by each ARP entry and update SNMP and the
> > LQM entry as you would in PPP LQM. Occasionally (once a second is
> > fine) send an LQM packet summarizing what has been sent.
>
> This is a very good idea. You might want to hand it over
> to your vendor before I hand it over to mine. :-)

Hey, now. Curtis has been saying this for at least a few years.
Clearly people haven't been paying attention!

(but don't let that stop you from knocking any particular vendor about it).

--jhawk
- - - - - - - - - - - - - - - - -

Looking at it strictly from a technical level, there is little difference
between a private interconnect and the connection between an ISP and their
upstream provider if they have one. (we might consider debating this
assumption especially in terms of scale :-))

One might as well ask if ISPs are willing to publicly display their packet
drop rates where they buy connectivity from their upstream providers at the
same time one is asking MCI, Sprint, UUNet and ANS for their
interconnection drop statistics.

Might it be easier for a customer of an ISP to get this kind of data from
their ISP? Or not?

Cheers, peter

>>>

----------
I wonder if this is something involved parties (MCI, Sprint, UUNet and
ANS)
are willing to talk about, given that I've noticed some degradation on
performance across some of these private interconnects already.. (and it's
only been couple of months since they came online!)

I understand that these are private arrangements between involved parties,
but
given their importance, it would be a great service to the community if
the
involved parties could share some information.

-dorian



- - - - - - - - - - - - - - - - -

>
>
>
> Looking at it strictly from a technical level, there is little difference
> between a private interconnect and the connection between an ISP and their
> upstream provider if they have one. (we might consider debating this
> assumption especially in terms of scale :-))
>

Actually, the traditional point2point link between any
two ISPs is a private interconnect. It does not have to
be a provider/subscriber relationship.

--bill
- - - - - - - - - - - - - - - - -

> Actually, the traditional point2point link between any
> two ISPs is a private interconnect. It does not have to
> be a provider/subscriber relationship.

True, but let's look at the goal and not at the implementation.

If customers actively requested that their providers make available
interconnect statistics, and made such statistics a contractual
requirement, perhaps this would happen more often.

Of course, merely saying that is not quite so simple, since there are
folks who have made (or claimed to have made) such requests in the
past.

Nevertheless, the current economic model does not expressly prohibit this
kind of thing.

--jhawk
- - - - - - - - - - - - - - - - -

In message <xoibufnxm6l.fsf@chops.icp.net>, Sean Doran writes:
> Curtis Villamizar <curtis@ans.net> writes:
>
> > This is an interesting problem and actually close to solvable at the
> > IP level. I'm sure you are familiar with PPP LQM. Take out the PPP
> > part and keep the LQM packet format and local storage. Keep one LQM
> > struct per ARP entry on a bcast or nbma interface (such as an ATM
> > NAP). Count packets used by each ARP entry and update SNMP and the
> > LQM entry as you would in PPP LQM. Occasionally (once a second is
> > fine) send an LQM packet summarizing what has been sent.
>
> This is a very good idea. You might want to hand it over
> to your vendor before I hand it over to mine. :-)
>
> Sean.


Sean,

I already brought it up with Cisco. Also with Steve Knowles when he
was an AD, but I never wrote an I-D. I was more inclined toward
trying to get an implementation. This was about 1994 if I remeber
correctly. Also brought it up with IBM before they stpped development
on the NSS but not for ATM, other bcast. Happens to be good stuff for
ATM, SMDS, FR. Carriers switched service perople might hate it. :-)

Curtis

ps- maybe one of us will have better luck now.
- - - - - - - - - - - - - - - - -

> > Looking at it strictly from a technical level, there is little difference
> > between a private interconnect and the connection between an ISP and their
> > upstream provider if they have one. (we might consider debating this
> > assumption especially in terms of scale :-))
>
> Actually, the traditional point2point link between any
> two ISPs is a private interconnect. It does not have to
> be a provider/subscriber relationship.
>
> --bill

Except for what one does to/with the routes learned via the BGP session
involved in such an interconnect... With a "private interconnect" between
"peers" one does not redistribute routes heard from one peer to another;
with a "upstream" - "downstream" relationship, one does redistribute routes
hears from one peer to another, thus giving the "downstream" transit to
those other peers.

I'm clarifying for others; I know you understand the difference :)

Avi

- - - - - - - - - - - - - - - - -

At this point, it looks there will be several NANGO presentations on Internet
statistics (from the RA and other groups). The RA talks will include routing
stability, end-to-end stability measurements using npd, and NetNow backbone
and NAP packet loss/delay statistics.

- Craig


at Sat, 31 Aug 1996 01:56:18 EDT, you wrote:
>
> In message <m0uwhqD-0007zqC@rip.psg.com>, Randy Bush writes:
> > Curtis,
> >
> > > I think your best bet is to run NPD.
> >
> > Huh? That looks at routing [in]stability, not goodput. Is this an
> > intentional red herring?
> >
> > randy
>
> No it wasn't an intentional red herring.
>
> I thought NPD did more than that, since Vern made other measurements.
>
> I also feel the NetNow stuff is valuable.
>
> Curtis

--
Craig Labovitz labovit@merit.edu
Merit Network, Inc. (313) 764-0252 (office)
4251 Plymouth Road, Suite C. (313) 747-3745 (fax)
Ann Arbor, MI 48105-2785



- - - - - - - - - - - - - - - - -

In message <199609041650.MAA29022@merit.edu>, Craig Labovitz writes:
>
> At this point, it looks there will be several NANGO presentations on Internet
>
> statistics (from the RA and other groups). The RA talks will include routing
> stability, end-to-end stability measurements using npd, and NetNow backbone
> and NAP packet loss/delay statistics.
>
> - Craig


Craig,

Could you begin putting the NetNow stats back up or provide them in
some form. Ftp? Also it might help to report on ANS AS1673 rather
than AS690 since AS690 is very close to being decommissioned. All the
peerings between AS1673 and the RS are up.

Thanks,

Curtis
- - - - - - - - - - - - - - - - -

i think this is somewhat related busy naps and overloaded
interconnects and i'm wondering if anyone else has noticed this kind
of thing. i've noticed in debugging on my border router at mae west
(the only place i actually looked at this) there is a lot of
broadcast traffic that shouldn't even be propogated at a nap, such as:

Sep 5 09:07:02.424: UDP: rcvd src=205.137.63.52(513),
dst=255.255.255.255(513),
length=68^M
Sep 5 09:07:02.424: UDP: rcvd src=205.137.63.52(513),
dst=255.255.255.255(513),
length=68^M

this is a unix box i'm guessing trying to get information via whod
on the fddi ring at mae west. i've logged a large number of these
broadcasts this evening, all within milliseconds of each other.
seems to me we (collectively) don't want/need to see this type of
traffic floating around when we're trying to push real customer
traffic through the interconnects.

or how about broadcasting bootp/tftp requests across the ring?
i've logged an equally large number of these tonight:

Sep 5 09:06:12.735: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67
), length=
308^M
Sep 5 09:06:12.735: BOOTP: opcode 1 from host 0.0.0.0 on Fddi10/0,
64508 secs,

and even better:

Sep 5 09:20:16.714: UDP: rcvd src=163.179.51.7(65044),dst=255.255.255
.255(69), length=29

is someone trying to pull a config (any config) via tftp from
whomever happens to have one? this kind of traffic just seems very
wasteful and unneeded at the naps.

i can't see that this is even useful to the folks doing it. more
traffic clogging up the pipes.

-brett


- - - - - - - - - - - - - - - - -