Looking glass or web-tracerouter within Chinanet/AS4134 needed

[Gunther Stammwitz]

Hello colleagues,

I'm trying to optimize the latency & packet loss between CHINANET (AS4134) and 
our network.
The outgoing traffic to china is fine now but I have no idea how they are 
routing towards us. 
This is why I'm looking for some sort of looking glass, route server or 
webtracerouter within AS4134.

Any where to find one?

Thanks,
Gunther

Re: houston.rr.com MX fubar?

[Tony Finch]

On Mon, 14 Jan 2008, Suresh Ramasubramanian wrote:
> On Jan 13, 2008 9:55 PM, Tony Finch <[EMAIL PROTECTED]> wrote:
> > On Sun, 13 Jan 2008, Suresh Ramasubramanian wrote:
> > >
> > > One operationally better way to go seems to be Mark Delany's mx0dot
> > > proposal, which started out as an internet draft, but seems to have
> > > lost momentum .. the concept is sound though.
> >
> > Exim implements this convention.
>
> Er, the concept is DNS related .. totally MTA independent.  Simply
> declaring that there is no MX record in a way that stops fallback to
> an A record.

It's slightly more subtle than that. MTAs have to interpret MX records, so
there is plenty of variation in semantics. If an MTA does not implement
the "." convention then it will look up the root's  and A records,
which is stupid but should cause the message to bounce as desired. However
if it does implement the convention (just like the "usage rules" for a SRV
record target of "." in RFC 2782) then it can skip the address lookups and
save the root some work. (It can also produce a better error message.)
This really ought to be explained in draft-delany-nullmx.

Note that an MTA can't rely on its recursive DNS server to populate the
additional section of a DNS reply, because of the truncation rules in RFC
2181. So if the additional section is empty (as it would be for an MX
target of ".") it must explicitly look up the address records to find out
if they are really missing or were just truncated. So it's worth
implementing the "." convention explicitly. (See also
http://www1.ietf.org/mail-archive/web/ietf/current/msg49843.html
for the IPv6 implications of truncated MX records.)

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
LUNDY FASTNET IRISH SEA: MAINLY SOUTHWESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE
GALE 9 IN LUNDY AND FASTNET. ROUGH OR VERY ROUGH. SQUALLY SHOWERS THEN RAIN.
MODERATE OR GOOD, OCCASIONALLY POOR LATER.

Asymmetrical routing opinions/debate

[Drew Weaver]

Pardon me if I am using the wrong term, I am using the term 
Asymmetrical routing to describe a scenario in which a request packet enters a 
network via one path and the response packet exits the network via a different 
path.

For example an ICMP ping request enters a network via ISP A and the reply 
leaves via ISP B (due to multi-homing on both networks, and or some kind of 
manual or automatic 'tweaking' of route preferences on one end or the other).

I haven't noticed too many instances of this causing huge performance problems, 
but I have noticed some, has anyone noticed any instances in the real world 
where this has actually caused performance gains over symmetrical routing? Also 
in a multi-homed environment is there any way to automatically limit or control 
the amount of Asymmetrical routing which takes place? (should you?) I have read 
a few papers [what few I could find] and they are conflicted about whether or 
not it is a real problem for performance of applications although I cannot see 
how it wouldn't be. Has there been any real community consensus on this issue 
published that I may have overlooked?

Thank you,
-Drew

RE: Asymmetrical routing opinions/debate

[Darden, Patrick S.]

I'm not sure I understand.  If a routing protocol such as BGP is being used, 
this is considered normal behavior, and the routing determination is made 
usually wrt either best route or best bandwidth.  In the first case, a return 
packet would usually follow on the same interface.  In the second case it would 
be determined by however you have set things up (round robin, 2/3rds on one int 
and 1/3rd on the other, whatever.)

If you are multi-homed with two backbone providers with static routes, then it 
is also normal behavior for some packets to enter thru either of your two 
interfaces, and then to exit on the preferred interface (if no preference is 
made clear via routing, then the default outbound interface is the one with the 
lower IP address--e.g. 201.x.y.z would be preferred over 202.x.y.z).

Does that help?

--Patrick Darden
--ARMC


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Drew Weaver
Sent: Monday, January 14, 2008 10:31 AM
To: nanog@merit.edu
Subject: Asymmetrical routing opinions/debate



Pardon me if I am using the wrong term, I am using the term 
Asymmetrical routing to describe a scenario in which a request packet enters a 
network via one path and the response packet exits the network via a different 
path.

For example an ICMP ping request enters a network via ISP A and the reply 
leaves via ISP B (due to multi-homing on both networks, and or some kind of 
manual or automatic 'tweaking' of route preferences on one end or the other).

I haven't noticed too many instances of this causing huge performance problems, 
but I have noticed some, has anyone noticed any instances in the real world 
where this has actually caused performance gains over symmetrical routing? Also 
in a multi-homed environment is there any way to automatically limit or control 
the amount of Asymmetrical routing which takes place? (should you?) I have read 
a few papers [what few I could find] and they are conflicted about whether or 
not it is a real problem for performance of applications although I cannot see 
how it wouldn't be. Has there been any real community consensus on this issue 
published that I may have overlooked?

Thank you,
-Drew

RE: Asymmetrical routing opinions/debate

[Scott Morris]

Routing in general is based of the premise of "my decision, my control" and
therefore you have some (albeit limited) controls about how YOU can
influence someone else's routing decision.

So any time you have more than one connection to the collective ('Net) then
you simply run the risk of you make one decision to send a packet out a
particular link, but a bunch of other people make decisions about routing as
well and it may very well come back another path.

Presumably you have your IP addressing as a constant.  If you are NATting,
you may have some interesting problems with this, but that would be a design
problem on your end.  Same with stateful firewalls.

>From an appplication viewpoint though, it really shouldn't make any
difference.  Packet goes out.  Packet comes back.  Life is good.

In short though, you have some choices with this, but they are all design
choices on your end.  If you want to be multihomed, this is the way life is.

HTH,

Scott 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew
Weaver
Sent: Monday, January 14, 2008 10:31 AM
To: nanog@merit.edu
Subject: Asymmetrical routing opinions/debate


Pardon me if I am using the wrong term, I am using the term
Asymmetrical routing to describe a scenario in which a request packet enters
a network via one path and the response packet exits the network via a
different path.

For example an ICMP ping request enters a network via ISP A and the reply
leaves via ISP B (due to multi-homing on both networks, and or some kind of
manual or automatic 'tweaking' of route preferences on one end or the
other).

I haven't noticed too many instances of this causing huge performance
problems, but I have noticed some, has anyone noticed any instances in the
real world where this has actually caused performance gains over symmetrical
routing? Also in a multi-homed environment is there any way to automatically
limit or control the amount of Asymmetrical routing which takes place?
(should you?) I have read a few papers [what few I could find] and they are
conflicted about whether or not it is a real problem for performance of
applications although I cannot see how it wouldn't be. Has there been any
real community consensus on this issue published that I may have overlooked?

Thank you,
-Drew

Re: Asymmetrical routing opinions/debate

[William Herrin]

On Jan 14, 2008 10:30 AM, Drew Weaver <[EMAIL PROTECTED]> wrote:
> I haven't noticed too many instances of this causing huge performance 
> problems,
> but I have noticed some, has anyone noticed any instances in the real world 
> where this
> has actually caused performance gains over symmetrical routing?

Drew,

There are at least two common scenarios where intentional asymmetric
routing (aka traffic engineering) benefits the sender:

Scenario 1: InterNAP-like product where the outbound packet takes a
path optimized for conditions other than shortest AS path. Conditions
might include minimize packet loss or maximize throughput as
determined by ongoing communication with testpoints in that direction.

Scenario 2: Cost minimization for bulk transfer. If you operate a
large mailing list or a usenet server, you might arrange for traffic
from the server to prefer peers first and then your lowest-cost
transit provider.

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

RE: ISPs slowing P2P traffic...

[Frank Bulk]

Geo:

That's an over-simplification.  Some access technologies have different
modulations for downstream and upstream.
i.e. if a:b and a=b, and c:d and c>d, a+bmailto:[EMAIL PROTECTED] On Behalf Of Geo.
Sent: Sunday, January 13, 2008 1:47 PM
To: nanog list
Subject: Re: ISPs slowing P2P traffic...

> The vast majority of our last-mile connections are fixed wireless.   The
> design of the system is essentially half-duplex with an adjustable ratio
> between download/upload traffic.

This in a nutshell is the problem, the ratio between upload and download
should be 1:1 and if it were then there would be no problems. Folks need to
stop pretending they aren't part of the internet. Setting a ratio where
upload:download is not 1:1 makes you a leech. It's a cheat designed to allow
technology companies to claim their devices provide more bandwidth than they
actually do. Bandwidth is 2 way, you should give as much as you get.

Making the last mile a 18x unbalanced pipe (ie 6mb down and 384K up) is what
has created this problem, not file sharing, not running backups, not any of
the things that require up speed. For the entire internet up speed must
equal down speed or it can't work. You can't leech and expect everyone else
to pay for your unbalanced approach.

Geo.

RE: ISPs slowing P2P traffic...

[Mikael Abrahamsson]

On Mon, 14 Jan 2008, Frank Bulk wrote:

In other words, you're denying the reality that people download a 3 to 4 
times more than they upload and penalizing every in trying to attain a 
1:1 ratio.


That might be your reality.

My reality is that people with 8/1 ADSL download twice as much as they 
upload, people with 10/10 upload twice as much as they download.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: ISPs slowing P2P traffic...

[Frank Bulk]

Interesting, because we have a whole college attached of 10/100/1000 users,
and they still have a 3:1 ratio of downloading to uploading.  Of course,
that might be because the school is rate-limiting P2P traffic.  That further
confirms that P2P, generally illegal in content, is the source of what I
would call disproportionate ratios.

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mikael Abrahamsson
Sent: Monday, January 14, 2008 11:22 AM
To: nanog list
Subject: RE: ISPs slowing P2P traffic...


On Mon, 14 Jan 2008, Frank Bulk wrote:

> In other words, you're denying the reality that people download a 3 to 4
> times more than they upload and penalizing every in trying to attain a
> 1:1 ratio.

That might be your reality.

My reality is that people with 8/1 ADSL download twice as much as they
upload, people with 10/10 upload twice as much as they download.

--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: ISPs slowing P2P traffic...

[Lasher, Donn]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
David E. Smith
Sent: Sunday, January 13, 2008 12:03 PM
To: nanog@merit.edu
Subject: Re: ISPs slowing P2P traffic...


>The wireless ISP business is a bit of a special case in this regard, where
P2P traffic is especially nasty.
>It's not the bandwidth, it's the number of packets being sent out 
>I still have a job, so we must have a few customers who are alright with
this limitation on their broadband service.

Speaking as a former wifi network operator, I feel for guys who are doing it
now, it's not an easy fence to sit on, between keeping your network
operational, and keeping your customers happy. In our case, we realized two
things very early on.

1. Radio PPS limitations appeared far sooner than BPS limits. A certain
vendor who made 3Mbit SSFH radios, which could carry about 1.7Mbit with big
packets, choked at about 200kbit with small packets. Radio methods of
traffic shaping were completely ineffective, so we needed a better way to
keep service levels up.

2. P2P was already a big challenge (back in the early Kazaa days) so we
found hardware solutions (Allot) with Layer7 awareness to deal with the
issue. Surprise surprise, even back in 2001, we found 60% of our traffic
from any given 'tower' was P2P traffic.

We implemented time-of-day based limits on P2P traffic, both in PPS and in
BPS. Less during the day (we were a business ISP) and more during the night,
and everybody was happy. 

Never once in 5+ years of operating that way, did we get a customer
complaining about their speeds for P2P. In fact, more often than not, we'd
see a customer flatline their connection, call their IT guy, explain what
the traffic was, and his reaction was "Those SOB's.. I told them not to use
that stuff.. What port is it on?? (30 seconds later) is it gone? Good!! Any
time you see that, call me directly!"

In the end, regardless of customer complaints, operators need to be able to
provide the service they are committed to selling, in spite of customers
attempts to disrupt that service, intentional or accidental.







smime.p7s
Description: S/MIME cryptographic signature

FW: ISPs slowing P2P traffic...

[Bailey Stephen]

>From my experience, the Internet IP Transit Bandwidth costs ISP's a lot
more than the margins made on Broadband lines.

So users who rarely use their connection are more profitable to the ISP.

We used the Cisco Service Control Engine (SCE) to throttle P2P
bandwidth.

Stephen Bailey
IS Network Services - FUJITSU 


Fujitsu Services Limited, Registered in England no 96056, Registered
Office 22 Baker Street, London, W1U 3BW

This e-mail is only for the use of its intended recipient.  Its contents
are subject to a duty of confidence and may be privileged.  Fujitsu
Services does not guarantee that this e-mail has not been intercepted
and amended or that it is virus-free.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mikael Abrahamsson
Sent: 14 January 2008 17:22
To: nanog list
Subject: RE: ISPs slowing P2P traffic...


On Mon, 14 Jan 2008, Frank Bulk wrote:

> In other words, you're denying the reality that people download a 3 to
4 
> times more than they upload and penalizing every in trying to attain a

> 1:1 ratio.

That might be your reality.

My reality is that people with 8/1 ADSL download twice as much as they 
upload, people with 10/10 upload twice as much as they download.

-- 
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: ISPs slowing P2P traffic...

[Robert Bonomi]

> Subject: RE: ISPs slowing P2P traffic...
> Date: Sun, 13 Jan 2008 23:19:58 -
> From: <[EMAIL PROTECTED]>
>
[[..  munch  ..]]
>
> From a technical point of view, if your Bittorrent protocol seeder
> does not have a copy of the file on its harddrive, but pulls it
> in from the customer's computer, you would only be caching the
> file in RAM and there is some legal precedent going back into
> the pre-Internet era that exempts such copies from legislation.

"Not Exactly"..  there is a court case (MAI Systems Corp. vs Peak Computer Inc
991 F.2d 511) holding that copying from storage media into computer ram *IS* 
actionable copyright infringement.  A specific exemption was written into
the copyright statutes for computer _programs_ (but *NOT* 'data') that the
owner of the computer hardware has a legal right to use. 

If you own the hardware, a third party can, WITHOUT infringing on copyright
cause the copying of "your" *programs* from storage (disk, tape, whatever) 
into RAM without infringing on the copyright owner's rights.

OTOH, it the colletion of bits on the storage media is just 'data', not
an executable program, the 9th Circuit interpretation of Title 17 stands,
and such loading into RAM _is_ actionable copyright infringement.  

It is _possible_ -- but, to the best of my knowledge *UNTESTED* in 
court -- that 47 USC 230 (c) (1) immunity might apply to a caching 'upload
server', since the content therein _is_ provided by "another information
content provider' (the customer who uploaded it).


I wouldn't want to bet on which prevails.  
Management pays the lawyers for that, 
*NOT* the operations people.  

Re: ISPs slowing P2P traffic...

[JC Dill]

Mikael Abrahamsson wrote:


On Mon, 14 Jan 2008, Frank Bulk wrote:

In other words, you're denying the reality that people download a 3 to 
4 times more than they upload and penalizing every in trying to attain 
a 1:1 ratio.


That might be your reality.

My reality is that people with 8/1 ADSL download twice as much as they 
upload, people with 10/10 upload twice as much as they download.



I'm a photographer.  When I shoot a large event and have hundreds or 
thousands of photos to upload to the fulfillment servers, to the event 
websites, etc. it can take 12 hours or more over my slow ADSL uplink. 
When my contract is up, I'll be changing to a different service with 
symmetrical service, faster upload speeds.


The faster-upload service costs more - ISPs charge more for 2 reasons: 
1)  Because they can (because the market will bear it) and 2) Because 
the average customer who buys this service uses more bandwidth.


Do you really find it surprising that people who upload a lot of data 
are the ones who would pay extra for the service plan that includes a 
faster upload speed?  Why "penalize" the customers who pay extra?


I predicted this billing and usage problem back in the early days of 
DSL.  Just as no webhost can afford to give customers "unlimited usage" 
on their web servers, no ISP can afford to give customers "unlimited 
usage" on their access plans.  You hope that you don't get too many of 
the users who use your "unlimited" service - but you are afraid to 
change your service plans to a realistic plan that actually meets 
customer needs.  You are terrified of dropping that term "unlimited" 
have having your competitors use this against you in advertising.  So 
you try to "limit" the "unlimited" service without having to drop the 
term "unlimited" from your service plans.


Some features of an ideal internet access service plan for home users 
include:


1)  Reasonable bandwidth usage allotment per month
2)  Proactive monitoring and notification from the ISP if the daily 
usage indicates they will exceed the plan's monthly bandwidth limit
3)  A grace period, so the customer can change user behavior or change 
plans before being hit with an unexpected bill for "excess use".

4)  Spam filtering that Just Works.
5)  Botnet detection and proactive notifications when botnet activity is 
detected from end-user computers.  Help them keep their computer running 
without viruses and botnets and they will love you forever!


If you add the value-ads (#4 and 5), customers will gladly accept 
reasonable bandwidth caps as *part* of the total *service* package you 
provide.


If all you want is to provide a pipe, no service, whine about those who 
use "too much" of the "unlimited" service you sell, well then you create 
an adversarial relationship with your customers (starting with your lie 
about "unlimited") and it's not surprising that you have problems.


jc

RE: ISPs slowing P2P traffic...

[Mikael Abrahamsson]

On Mon, 14 Jan 2008, Frank Bulk wrote:


Interesting, because we have a whole college attached of 10/100/1000 users,
and they still have a 3:1 ratio of downloading to uploading.  Of course,
that might be because the school is rate-limiting P2P traffic.  That further
confirms that P2P, generally illegal in content, is the source of what I
would call disproportionate ratios.


You're not delivering "Full Internet IP connectivity", you're delivering 
some degraded pseudo-Internet connectivity.


If you take away one of the major reasons for people to upload (ie P2P) 
then of course they'll use less upstream bw. And what you call 
disproportionate ratio is just an idea of "users should be consumers" and 
"we want to make money at both ends by selling download capacity to users 
and upload capacity to webhosting" instead of the Internet idea that 
you're fully part of the internet as soon as you're connected to it.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: ISPs slowing P2P traffic...

[Frank Bulk]

We're delivering full IP connectivity, it's the school that's deciding to
rate-limit based on application type.

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mikael Abrahamsson
Sent: Monday, January 14, 2008 1:28 PM
To: nanog list
Subject: RE: ISPs slowing P2P traffic...


On Mon, 14 Jan 2008, Frank Bulk wrote:

> Interesting, because we have a whole college attached of 10/100/1000
users,
> and they still have a 3:1 ratio of downloading to uploading.  Of course,
> that might be because the school is rate-limiting P2P traffic.  That
further
> confirms that P2P, generally illegal in content, is the source of what I
> would call disproportionate ratios.

You're not delivering "Full Internet IP connectivity", you're delivering
some degraded pseudo-Internet connectivity.

If you take away one of the major reasons for people to upload (ie P2P)
then of course they'll use less upstream bw. And what you call
disproportionate ratio is just an idea of "users should be consumers" and
"we want to make money at both ends by selling download capacity to users
and upload capacity to webhosting" instead of the Internet idea that
you're fully part of the internet as soon as you're connected to it.

--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: ISPs slowing P2P traffic...

[Joe Greco]

> Geo:
> 
> That's an over-simplification.  Some access technologies have different
> modulations for downstream and upstream.
> i.e. if a:b and a=b, and c:d and c>d, a+b 
> In other words, you're denying the reality that people download a 3 to 4
> times more than they upload and penalizing every in trying to attain a 1:1
> ratio.

So, is that actually true as a constant, or might there be some
cause->effect mixed in there?

For example, I know I'm not transferring any more than I absolutely must
if I'm connected via GPRS radio.  Drawing any sort of conclusions about
my normal Internet usage from my GPRS stats would be ... skewed ... at
best.  Trying to use that "reality" as proof would yield you an exceedingly
misleading picture.

During those early years of the retail Internet scene, it was fairly easy
for users to migrate to usage patterns where they were mostly downloading
content; uploading content on a 14.4K modem would have been unreasonable.
There was a natural tendency towards eyeball networks and content networks.

However, these days, more people have "always on" Internet access, and may
be interested in downloading larger things, such as services that might
eventually allow users to download a DVD and burn it.

http://www.engadget.com/2007/09/21/dvd-group-approves-restrictive-download-to-burn-scheme/

This means that they're leaving their PC on, and maybe they even have other
gizmos or gadgets besides a PC that are Internet-aware.

To remain doggedly fixated on the concept that an end-user is going to
download more than they upload ...  well, sure, it's nice, and makes
certain things easier, but it doesn't necessarily meet up with some of
the realities.  Verizon recently began offering a 20M symmetrical FiOS
product.  There must be some people who feel differently.

So, do the "modulations" of your "access technologies" dictate what your
users are going to want to do with their Internet in the future, or is it
possible that you'll have to change things to accomodate different
realities?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

RE: ISPs slowing P2P traffic...

[Frank Bulk]

You're right, I shouldn't let the access technologies define the services I
offer, but I have to deal with the equipment I have today.  Although that
equipment doesn't easily support a 1:1 product offering, I can tell you that
all the decisions we're making in regards to upgrades and replacements are
moving toward that goal.  In the meantime, it is what it is and we need to
deal with it.

Frank

-Original Message-
From: Joe Greco [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 14, 2008 3:17 PM
To: [EMAIL PROTECTED]
Cc: nanog@merit.edu
Subject: Re: ISPs slowing P2P traffic...

> Geo:
>
> That's an over-simplification.  Some access technologies have different
> modulations for downstream and upstream.
> i.e. if a:b and a=b, and c:d and c>d, a+b
> In other words, you're denying the reality that people download a 3 to 4
> times more than they upload and penalizing every in trying to attain a 1:1
> ratio.

So, is that actually true as a constant, or might there be some
cause->effect mixed in there?

For example, I know I'm not transferring any more than I absolutely must
if I'm connected via GPRS radio.  Drawing any sort of conclusions about
my normal Internet usage from my GPRS stats would be ... skewed ... at
best.  Trying to use that "reality" as proof would yield you an exceedingly
misleading picture.

During those early years of the retail Internet scene, it was fairly easy
for users to migrate to usage patterns where they were mostly downloading
content; uploading content on a 14.4K modem would have been unreasonable.
There was a natural tendency towards eyeball networks and content networks.

However, these days, more people have "always on" Internet access, and may
be interested in downloading larger things, such as services that might
eventually allow users to download a DVD and burn it.

http://www.engadget.com/2007/09/21/dvd-group-approves-restrictive-download-t
o-burn-scheme/

This means that they're leaving their PC on, and maybe they even have other
gizmos or gadgets besides a PC that are Internet-aware.

To remain doggedly fixated on the concept that an end-user is going to
download more than they upload ...  well, sure, it's nice, and makes
certain things easier, but it doesn't necessarily meet up with some of
the realities.  Verizon recently began offering a 20M symmetrical FiOS
product.  There must be some people who feel differently.

So, do the "modulations" of your "access technologies" dictate what your
users are going to want to do with their Internet in the future, or is it
possible that you'll have to change things to accomodate different
realities?

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then
I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN)
With 24 million small businesses in the US alone, that's way too many
apples.

Re: FW: ISPs slowing P2P traffic...

[Joe Greco]

> From my experience, the Internet IP Transit Bandwidth costs ISP's a lot
> more than the margins made on Broadband lines.
> 
> So users who rarely use their connection are more profitable to the ISP.

The fat man isn't a welcome sight to the owner of the AYCE buffet.

What exactly does this imply, though, from a networking point of view?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: FW: ISPs slowing P2P traffic...

[William Herrin]

On Jan 14, 2008 5:25 PM, Joe Greco <[EMAIL PROTECTED]> wrote:
> > So users who rarely use their connection are more profitable to the ISP.
>
> The fat man isn't a welcome sight to the owner of the AYCE buffet.

Joe,

The fat man is quite welcome at the buffet, especially if he brings
friends and tips well. That's the buffet's target market: folks who
aren't satisfied with a smaller portion.

The unwelcome guy is the smelly slob who spills half his food,
complains, spends most of 4 hours occupying the table yelling into a
cell phone (with food still in his mouth and in a foreign language to
boot), burps, farts, leaves no tip and generally makes the restaurant
an unpleasant place for anyone else to be.


> What exactly does this imply, though, from a networking point of view?

That the unpleasant nuisance who degrades everyone else's service and
bothers the staff gets encouraged to leave.

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Re: FW: ISPs slowing P2P traffic...

[Matt Palmer]

On Mon, Jan 14, 2008 at 06:43:12PM -0500, William Herrin wrote:
> On Jan 14, 2008 5:25 PM, Joe Greco <[EMAIL PROTECTED]> wrote:
> > > So users who rarely use their connection are more profitable to the ISP.
> >
> > The fat man isn't a welcome sight to the owner of the AYCE buffet.
> 
> The fat man is quite welcome at the buffet, especially if he brings
> friends and tips well. That's the buffet's target market: folks who
> aren't satisfied with a smaller portion.
> 
> The unwelcome guy is the smelly slob who spills half his food,
> complains, spends most of 4 hours occupying the table yelling into a
> cell phone (with food still in his mouth and in a foreign language to
> boot), burps, farts, leaves no tip and generally makes the restaurant
> an unpleasant place for anyone else to be.

However, if the sign on the door said "burping and farting welcome" and
"please don't tip your server", things are a bit different.  Similar
comparisons to use of the word "unlimited" apply.

> > What exactly does this imply, though, from a networking point of view?
> 
> That the unpleasant nuisance who degrades everyone else's service and
> bothers the staff gets encouraged to leave.

Until it is generally considered common courtesy (and recognised as such
in a future edition of "Miss Manners' Guide To The Intertubes") to not
download heavily for fear of upsetting your virtual neighbours, it's
reasonable that not specifically informing people that their "unpleasant"
behaviour is unwelcome should imply that such behaviour is acceptable.

- Matt

Re: Asymmetrical routing opinions/debate

[Bill Stewart]

There's the somewhat trivial efficiency that if you're willing to
accept asymmetric routing, you spend a lot less time tweaking your
networks than if you insist on symmetry, and the more significant
issue that the network will usually be more resilient and reliable
(though slightly less predictable) if you're not tweaking it.

Essentially, if you don't control all the parts of the network that
your packet uses, you're not able to directly set optimization
parameters, so what you're doing to get symmetry is throwing lots of
hints at the network and hoping some will stick, and the parts of the
network that happen to cooperate with you may not be the best ones
that are otherwise available.

Re: Asymmetrical routing opinions/debate

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- "Bill Stewart" <[EMAIL PROTECTED]> wrote:

>
>Essentially, if you don't control all the parts of the network that
>your packet uses, you're not able to directly set optimization
>parameters, so what you're doing to get symmetry is throwing lots of
>hints at the network and hoping some will stick, and the parts of the
>network that happen to cooperate with you may not be the best ones
>that are otherwise available.
>

I wish I could remember who to attribute this quote (maybe Geoff
Huston?), but paraphrasing:

"Asymmetric end-to-end traffic paths in The Internet is a fact of
life. Get over it."

:-)

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFHjBWeq1pz9mNUZTMRAkW4AKCiIBfZtNamFrfrUY3ymOIhQcLr+ACeIVXP
7x/pIYWX1tqdicfaeFSOQzM=
=LQxO
-END PGP SIGNATURE-




--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: houston.rr.com MX fubar?

[Suresh Ramasubramanian]

On Jan 14, 2008 5:08 PM, Tony Finch <[EMAIL PROTECTED]> wrote:

> the "." convention then it will look up the root's  and A records,
> which is stupid but should cause the message to bounce as desired. However
> if it does implement the convention (just like the "usage rules" for a SRV
> record target of "." in RFC 2782) then it can skip the address lookups and
> save the root some work. (It can also produce a better error message.)
> This really ought to be explained in draft-delany-nullmx.

The draft died.  And I think this stuff about looking up A /  for
the root was certainly raised in the IETF sometime back.  Not that
there isnt enough junk traffic (and DDoS etc) coming the roots' way
that this kind of single lookup would get lost in the general noise ..

Might want to revive it and take it forward?  I rather liked that
draft (and Mark Delany cites me in the acknowledgements as I suggested
a few wording changes for the definition of a null MX - dot terminated
null string, STD13 etc, during his drafting of the document)

--srs

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Asymmetrical routing opinions/debate

[Adrian Chadd]

On Tue, Jan 15, 2008, Paul Ferguson wrote:

> I wish I could remember who to attribute this quote (maybe Geoff
> Huston?), but paraphrasing:
> 
> "Asymmetric end-to-end traffic paths in The Internet is a fact of
> life. Get over it."

I wish people wouldn't base their bloody netflow accounting systems
on perfectly symmetric traffic flows. Argh.

Its 2008 I still see the country academic backbone implement
symmetric netflow based accounting, and I get pissed off every time
a department gets charged thousands of dollars from a very much
local or internet-2 connected ISP, because of asymmetric flows.
FFS.



Adrian

Re: houston.rr.com MX fubar?

[Mark Andrews]

In article <[EMAIL PROTECTED]> you write:
>
>On Jan 14, 2008 5:08 PM, Tony Finch <[EMAIL PROTECTED]> wrote:
>
>> the "." convention then it will look up the root's  and A records,
>> which is stupid but should cause the message to bounce as desired. However
>> if it does implement the convention (just like the "usage rules" for a SRV
>> record target of "." in RFC 2782) then it can skip the address lookups and
>> save the root some work. (It can also produce a better error message.)
>> This really ought to be explained in draft-delany-nullmx.
>
>The draft died.  And I think this stuff about looking up A /  for
>the root was certainly raised in the IETF sometime back.  Not that
>there isnt enough junk traffic (and DDoS etc) coming the roots' way
>that this kind of single lookup would get lost in the general noise ..
>
>Might want to revive it and take it forward?  I rather liked that
>draft (and Mark Delany cites me in the acknowledgements as I suggested
>a few wording changes for the definition of a null MX - dot terminated
>null string, STD13 etc, during his drafting of the document)
>
>--srs
>
>-- 
>Suresh Ramasubramanian ([EMAIL PROTECTED])

There are lots of places in the DNS where "." makes sense
as a null indicator.  RP uses it today, as does SRV.  MX
should use it and fallback to A should be removed.  It
actually takes more cache space to record that a MX record
does not exist than it takes to record that a A or 
record exists (SOA rdata is atleast 22 octets).

draft-ietf-dnsop-default-local-zones used it for SOA RNAME
but was changed under WG pressure.

A and  should use 0.0.0.0 and :: to indicate that a host
exists but is not currently connected.

Mark

Re: houston.rr.com MX fubar?

[Randy Bush]

Fallback to A should be removed sure sounds like a plan.


great idea.  it will only break mail to 42% of the internet.

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

randy

Re: houston.rr.com MX fubar?

[Suresh Ramasubramanian]

On Jan 15, 2008 8:53 AM, Mark Andrews <[EMAIL PROTECTED]> wrote:

> There are lots of places in the DNS where "." makes sense
> as a null indicator.  RP uses it today, as does SRV.  MX
> should use it and fallback to A should be removed.  It

Fallback to A should be removed sure sounds like a plan.

srs

Re: houston.rr.com MX fubar?

[Mark Andrews]

> > Fallback to A should be removed sure sounds like a plan.
> 
> great idea.  it will only break mail to 42% of the internet.

Since there is no fallback to , in a few years it will
break very little as most of the internet will have IPv6
MTA's (and hence MX's) for their mail domains.

MX fallback to A should have had a sunset time added to it
when it was originally proposed.  It is, after all, only a
transition strategy.  We can still add a sunset clause.

MTA's would lookup their own MX records for the mail domains
they are configured as final delivery agents for and if not
found log that there are missing MX records.

Mark

> http://en.wikipedia.org/wiki/Principle_of_least_astonishment
> 
> randy

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Anyone with clue at GBLX / AS3549 -- long duration fiber cut

[John van Oppen]

Anyone have any detail on the apparent GBLX fiber cut between Seattle
and northern California?   The outage has been ongoing since
mid-morning.

 

 

Thanks,

 

John van Oppen
Spectrum Networks LLC
206.973.8302 (Direct)
206.973.8300 (main office)

 

Re: Anyone with clue at GBLX / AS3549 -- long duration fiber cut

[Kameron Gasso]

John van Oppen wrote:
> Anyone have any detail on the apparent GBLX fiber cut between Seattle
> and northern California?   The outage has been ongoing since mid-morning.

We're sitting on about 12 hours of downtime for an affected circuit
here; I've been told that techs were on-scene doing splices starting at
14:00 PST, and as of about 10 minutes ago was quoted an ETR of 01:30
PST, but not entirely sure how accurate that all is...

Thanks,
-- 
Kameron Gasso | Senior Systems Administrator | visp.net
Direct: 541-955-6903 | Fax: 541-471-0821