On Wed, Aug 15, 2007, Fred Baker wrote:
> >And finally why only do this during extreme congestion? Why not
> >always
> >do it?
>
> I think I would always do it, and expect it to take effect only under
> extreme congestion.
Well, emprically (on multi-megabit customer-facing links) it takes
>
> On Aug 15, 2007, at 5:34 PM, Mark Andrews wrote:
>
> >> Yes, and this convention still generates nuisance root traffic
> >> whenever the application fails to comprehend "." is a special
> >> target. This is true even when _defined_ as a special target for
> >> the specific resource r
[...Lots of good stuff deleted to get to this point...]
On Wed, 15 Aug 2007, Fred Baker wrote:
So I would suggest that a third thing that can be done, after the other two
avenues have been exhausted, is to decide to not start new sessions unless
there is some reasonable chance that they will
On Aug 15, 2007, at 8:39 PM, Sean Donelan wrote:
Or would it be better to let the datagram protocols fight it out
with the session oriented protocols, just like normal Internet
operations
Session protocol start packets (TCP SYN/SYN-ACK, SCTP INIT, etc)
1% queue
Everything else (UDP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- Douglas Otis <[EMAIL PROTECTED]> wrote:
>Do not depend upon applications not to resolve addresses for root
names, even when a convention is explicit. Depending upon root
answers to support a protocol feature unrelated to DNS is normally
c
On Aug 15, 2007, at 5:34 PM, Mark Andrews wrote:
Yes, and this convention still generates nuisance root traffic
whenever the application fails to comprehend "." is a special
target. This is true even when _defined_ as a special target for
the specific resource record, as with SRV. In th
>
> On Aug 14, 2007, at 10:22 PM, Mark Andrews wrote:
>
> >
> >> On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:
> >>>
> >>> Since all valid email domains are required to have a working
> >>> postmaster you can safely drop any email from such domains.
> >>
> >> Use of root "." as a na
On Aug 15, 2007, at 2:55 PM, Barry Shein wrote:
Then my next question is, what reasons are there where it'd be
wise/useful/non-criminal to do it on a large scale?
It's a relatively passive activity when used for ad pages, no one
forces anyone to look at them. I'm not sure what the problem
On Aug 15, 2007, at 2:55 PM, Barry Shein wrote:
It seems to me that this should be an issue between the domain
registrars and their customers, but maybe some over-arching policy
is making it difficult to do the right thing?
Charging a "re-stocking fee" sounded perfectly reasonable. I don't
On August 15, 2007 at 14:38 [EMAIL PROTECTED] (Al Iverson) wrote:
>
> On 8/15/07, Barry Shein <[EMAIL PROTECTED]> wrote:
> > > I am not sure tasting is criminal or fraud.
> >
> > Neither am I, we agree. I meant if there's subsequent criminality or
> > fraud that should be dealt with separ
On Aug 15, 2007, at 12:38 PM, Al Iverson wrote:
Dumb question, not necessarily looking to call you or anyone out,
but I'm curious: What valid, legitimate, or likely to be used non-
criminal reasons are there for domain tasting?
This article describes the motivation leading to domain tastin
On Wed, Aug 15, 2007 at 02:38:48PM -0500, Al Iverson wrote:
> I'm curious: What valid, legitimate, or likely to be used non-criminal
> reasons are there for domain tasting?
Making money on the basis of the published policies of a registry? If
this were some sort of "Web 2.0" application, everyb
On 8/15/07, Barry Shein <[EMAIL PROTECTED]> wrote:
> > I am not sure tasting is criminal or fraud.
>
> Neither am I, we agree. I meant if there's subsequent criminality or
> fraud that should be dealt with separately.
Dumb question, not necessarily looking to call you or anyone out, but
I'm curi
Is this a declaration of principles? There is no reason why 'Tier 1' means that
the carrier will not have an incentive to shape or even block traffic.
Particularly, if they have a lot of eyeballs.
Roderick S. Beck
Director of EMEA Sales
Hibernia Atlantic
1, Passage du Chantier, 75012 Paris
http
On Aug 14, 2007, at 11:00 PM, Chris L. Morrow wrote:
On Wed, 15 Aug 2007, Paul Ferguson wrote:
More than ~85% of all spam is being generated by spambots.
yes, that relates to my question how though? I asked: "Do spammers
monitor the domain system in order to spam from the domains in flux
On August 13, 2007 at 16:01 [EMAIL PROTECTED] (Carl Karsten) wrote:
>
> Barry Shein wrote:
> >
> > That is, if you extend domains on credit w/o any useful accountability
> > of the buyer and this results in a pattern of criminality then the
> > liability for that fraud should be shared by
My opinion:
A tier 1 provider does not care what traffic it carries. That is all a
function of the application not the network.
A tier 2 provider may do traffic shaping, etc.
A tier 3 provider may decide to block traffic paterns.
--
More or less... The network wa
Congestion and applications...
My opinion:
A tier 1 provider does not care what traffic it carries. That is all a
function of the application not the network.
A tier 2 provider may do traffic shaping, etc.
A tier 3 provider may decide to block traffic paterns.
--
let me answer at least twice.
As you say, remember the end-2-end principle. The end-2-end
principle, in my precis, says "in deciding where functionality should
be placed, do so in the simplest, cheapest, and most reliable manner
when considered in the context of the entire network. That is
On Wed, 15 Aug 2007 11:59:54 EDT, Sean Donelan said:
> Since major events in the real-world also result in a lot of "new"
> traffic, how do you signal new sessions before they reach the affected
> region of the network? Can you use BGP to signal the far-reaches of
> the Internet that I'm having p
On Aug 14, 2007, at 10:22 PM, Mark Andrews wrote:
On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:
Since all valid email domains are required to have a working
postmaster you can safely drop any email from such domains.
Use of root "." as a name for a target may create undesired
Hey Sean,
On Wed, Aug 15, 2007 at 11:35:43AM -0400, Sean Donelan wrote:
> On Wed, 15 Aug 2007, Stephen Wilcox wrote:
> >(Check slide 4) - the simple fact was that with something like 7 of 9
> >cables down the redundancy is useless .. even if operators maintained
> >N+1 redundancy which is unlik
On Wed, 15 Aug 2007, Fred Baker wrote:
On Aug 15, 2007, at 8:35 AM, Sean Donelan wrote:
Or should IP backbones have methods to predictably control which IP
applications receive the remaining IP bandwidth? Similar to the telephone
network special information tone -- All Circuits are Busy. May
On Aug 15, 2007, at 8:35 AM, Sean Donelan wrote:
Or should IP backbones have methods to predictably control which IP
applications receive the remaining IP bandwidth? Similar to the
telephone network special information tone -- All Circuits are
Busy. Maybe we've found a new use for ICMP
On Wed, 15 Aug 2007, Stephen Wilcox wrote:
(Check slide 4) - the simple fact was that with something like 7 of 9
cables down the redundancy is useless .. even if operators maintained
N+1 redundancy which is unlikely for many operators that would imply
50% of capacity was actually used with 50%
On Wed, 15 Aug 2007 10:15:01 BST, [EMAIL PROTECTED] said:
> telecom hotel/data centre. In the exchange point, you could
> theoretically have special "INSURANCE" peering agreements where you
> don't exchange traffic until there is an emergency, and then you can
> quickly turn it on, perhaps using a
> I think the real question given the facts around this is
> whether South East Asia will look to protect against a future
> failure by providing new routes that circumvent single points
> of failure such as the Luzon straights at Taiwan. But that
> costs a lot of money .. so the futures not h
On Wed, Aug 15, 2007 at 12:06:36PM +0800, Chengchen Hu wrote:
> I find that the link recovery is sometimes very slow when failure occures
> between different ASes. The outage may last hours. In such cases, it seems
> that the automatic recovery of BGP-like protocol fails and the repair is took
On Aug 15, 2007, at 2:01 AM, Leigh Porter wrote:
LOL!
I guess if they are from different source addresses, varying UDP
ports etc and the total bandwidth in infeasible for a typical video
stream..
I was quite serious.
I run a video streaming site, AmericaFree.TV.
Most of our packets
On 15 Aug 2007, at 08:07, Chengchen Hu wrote:
Just suppose no business fators (like multiple ASes belongs to a
same ISP), is it always possible for BGP to automatically find an
alternative path when failure occurs if exist one? If not, what may
be the causes?
I think everyone here has
On Tue, 14 Aug 2007, Al Iverson wrote:
> On 8/14/07, Douglas Otis <[EMAIL PROTECTED]> wrote:
>
> > This comment was added as a follow-on note. Sorry for not being clear.
> >
> > Accepting messages from a domain lacking MX records might be risky
> > due to the high rate of domain turnovers. Withi
> Thank you for comments. I know there are economic/contractual
> relationships between two networks, and BGP cannot find a
> path that the business rules forbid. But when in these
> cases, how to recover it? The network operators just wait for
> physically reparing the link or they may manu
Chengchen Hu wrote:
> Thank you for your detailed explainaton.
>
> Just suppose no business fators (like multiple ASes belongs to a same ISP),
> is it always possible for BGP to automatically find an alternative path when
> failure occurs if exist one? If not, what may be the causes?
If you
On Aug 15, 2007, at 12:11 AM, Chengchen Hu wrote:
But when in these cases, how to recover it? The network operators
just wait for physically reparing the link or they may manully
configure an alternative path by paying another network for transit
service or finding a peering network?
Or
On Aug 15, 2007, at 12:07 AM, Chengchen Hu wrote:
is it always possible for BGP to automatically find an alternative
path when failure occurs if exist one? If not, what may be the causes?
Barring implementation bugs or network misconfigurations, I've never
experienced an operational probl
> Does anyone known some tool for network documentation with:
>
> - inventory (cards, serial numbers, manufactor...)
> - documentation (configurations, software version control, etc)
> - topology building (L2, L3.. connections, layer control, ...)
We've been using a modelling tool called WANDL w
> > > http://www.icann.org/announcements/announcement-2-10aug07.htm
> Is this something where a consensus 'vote' from a larger
> group would help?
> or one of the letter writing campaigns congress loves so much?
My impression is that it will be more useful for many individuals to
make their own
--- [EMAIL PROTECTED] wrote:---
On Aug 14, 2007, at 9:06 PM, Chengchen Hu wrote:
> 1. Why BGP-like protocol failed to recover the path sometimes? Is
> it mainly because the policy setting by the ISP and network operators?
There are an infinitude of possible answers to thes
Thank you for comments. I know there are economic/contractual relationships
between two networks, and BGP cannot find a path that the business rules
forbid. But when in these cases, how to recover it? The network operators just
wait for physically reparing the link or they may manully configur
Thank you for your detailed explainaton.
Just suppose no business fators (like multiple ASes belongs to a same ISP), is
it always possible for BGP to automatically find an alternative path when
failure occurs if exist one? If not, what may be the causes?
C. Hu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- "Chris L. Morrow" <[EMAIL PROTECTED]> wrote:
>> More than ~85% of all spam is being generated by spambots.
>
>yes, that relates to my question how though? I asked: "Do spammers monitor
>the domain system in order to spam from the domains in flux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:
>Why do you think BGP was supposed to find the remaining path?
And to be less verbose -- let's remember that IP-layer
notification (specifically BGP) as a certain "ships-in-the-night"
characterist
42 matches
Mail list logo
