On Oct 19, 2004, at 1:14 PM, JP Velders wrote:
jacking the connection is in a completely different class as someone
bombarding you with a bunch of forged BGP packets to close down a
session. Without that MD5 checksum you are quite vulnerable to that. I
haven't seen a vendor come up with a solution
> Hmm, so let me figure this one out... Are you arguing against
> BCP38 implementation/filtering, or what?
no one is arguing against it. they're just trying to tell
the religious zealots (who seem not to run large networks)
why it is not deploying as rapidly as they might like.
randy
Hmm, so let me figure this one out... Are you arguing against
BCP38 implementation/filtering, or what?
- ferg
-- JP Velders <[EMAIL PROTECTED]> wrote:
In most cases it will go like that, the minority of when it doesn't
go like that, you start filtering / whatever, just like we do now.
Regard
>dropped over it's 25 day uptime:
>
> RPF Failures: Packets: 34889152, Bytes: 12838806927
> RPF Failures: Packets: 4200, Bytes: 449923
> RPF Failures: Packets: 3066337401, Bytes: 122772518288
> RPF Failures: Packets: 30954487, Bytes: 3272647457
> RPF Failures: Packets: 470
;ve
> > been part of that 'I' in their name since the very early beginning.
>
> i'm pretty depressed at the lack of self regulation among the techiefolk.
> responses to BCP38 of the form "but my customer has a good reason to spoof"
> or "but my equipment c
> Date: Tue, 19 Oct 2004 13:36:18 +
> From: Paul Vixie <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: BCP38 making it work, solving problems
> [ ... ]
> > As it was "in the old days": first clean up your own act and then
> > start point
> Date: Tue, 19 Oct 2004 13:20:08 -0400
> From: David G. Andersen <[EMAIL PROTECTED]>
> Subject: Re: BCP38 making it work, solving problems
> [ ... ]
> Unless you're worried about an adversary who taps into your
> fiber, how is MD5 checksums any better than anti sp
On Tue, Oct 19, 2004 at 07:14:32PM +0200, JP Velders scribed:
>
> > Date: Tue, 19 Oct 2004 09:21:46 -0700
> > From: Randy Bush <[EMAIL PROTECTED]>
> > Subject: Re: BCP38 making it work, solving problems
>
> > > For example, how many ISPs use TCP MD5 to l
> Date: Tue, 19 Oct 2004 09:21:46 -0700
> From: Randy Bush <[EMAIL PROTECTED]>
> Subject: Re: BCP38 making it work, solving problems
> > For example, how many ISPs use TCP MD5 to limit the possibility of a
> > BGP/TCP connection getting hijacked or disrupted by a ddos
> For example, how many ISPs use TCP MD5 to limit the possibility of a
> BGP/TCP connection getting hijacked or disrupted by a ddos attack?
i hope none use it for the latter, as it will not help. more and
more use it for the former. why? becuase they perceived the need
to solve an immediate p
y depressed at the lack of self regulation among the techiefolk.
responses to BCP38 of the form "but my customer has a good reason to spoof"
or "but my equipment can't do wire speed SAV" or "but BCP38 will not solve
all DDoS problems single-handedly" are small minded, provincial, and wrong.
... it's just "but if man was meant to fly he'd have wings" all over again.
At 01:11 PM 10/19/04 +0200, JP Velders wrote:
As it was "in the old days": first clean up your own act and then start
pointing at others that they're doing "it" wrong.
hear hear... But Paul knows and in fact does that. He is pointing out the
difficulty of getting people to do basic things that ar
> Date: 12 Oct 2004 16:22:17 +
> From: Paul Vixie <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: BCP38 making it work, solving problems
> [ ... ]
> how are we going to get there? the first thing is, some nets who want the
> internet to work this way
On 14-okt-04, at 0:17, Fred Baker wrote:
Trusting the source when it says that its packets aren't evil might
be sub-optimal. Evaluation of evilness is best left up to the
receiver.
Likely true. Next question is whether the receiver can really
determine that in real time. For some things, yes, b
level of confidence in its normality
> seems to be worth pursuing. It seems to be the natural
> progression of projects like the selection found at
> cymru.com.
>
> --Michael Dillon
ah ... so you have no problems with me marking your packets
anyway I choose, rig
> At 12:01 PM 10/13/04 +0200, Iljitsch van Beijnum wrote:
> >Trusting the source when it says that its packets aren't evil might be
> >sub-optimal. Evaluation of evilness is best left up to the receiver.
>
> Likely true. Next question is whether the receiver can really determine
> that in real
At 12:01 PM 10/13/04 +0200, Iljitsch van Beijnum wrote:
Trusting the source when it says that its packets aren't evil might be
sub-optimal. Evaluation of evilness is best left up to the receiver.
Likely true. Next question is whether the receiver can really determine
that in real time. For some t
On 13 Oct 2004, Paul Vixie wrote:
> > >How many people have seen "forged" spoofed IP addresses being used for DOS
> > >attacks lately?
>
> syn-flood protection, and random TCP ISS, are now common enough that
> spoofed-source isn't effective for TCP flows. if you want to bring down
> somebody's
> >How many people have seen "forged" spoofed IP addresses being used
> >for DOS attacks lately?
syn-flood protection, and random TCP ISS, are now common enough that
spoofed-source isn't effective for TCP flows. if you want to bring down
somebody's web server then blackhats really do have to use
> Some medium-big (and up) operators implement 'RFC-1918 source' filters on
> their gateways to the 'external internet', ...
maybe so. but i want to renew an old complaint, with updated numbers:
# ipfw show
...
00400 576234043927757977 deny ip from 10.0.0.0/8 to any in
00500
on Wed, Oct 13, 2004 at 07:09:10AM +0530, Suresh Ramasubramanian wrote:
>
> [EMAIL PROTECTED] [12/10/04 13:16 -0400]:
> >
> > > If I, and my little 7-man company, can afford to have me solve the
> > > problem on our end, why the heck can't you do the same?
> >
> > You can do it because you are
>> any idea why someone(s) is ddosing dark space? seems a bit silly.
> No one is DDOSing dark space. The dark space telescope picks up the
> "richochets" caused by DDOS.
sorry. i guess i should give up getting more sleep and go make
coffee.
randy
Randy Bush wrote:
For the week starting Sept 12, our dark space telescope "saw" 1675
spoofed DDOS attacks.
any idea why someone(s) is ddosing dark space? seems a bit silly.
Something like this I rather fancy ...
http://lists.planet-lab.org/pipermail/announce/2004-April/12.html
[Planetlab-anno
At 04:59 AM 13-10-04 -0700, Randy Bush wrote:
> For the week starting Sept 12, our dark space telescope "saw"
> 1675 spoofed DDOS attacks.
any idea why someone(s) is ddosing dark space? seems a bit silly.
No one is DDOSing dark space. The dark space telescope picks up the
"richochets" caused by
> For the week starting Sept 12, our dark space telescope "saw"
> 1675 spoofed DDOS attacks.
any idea why someone(s) is ddosing dark space? seems a bit silly.
randy
On 12-okt-04, at 7:30, Fred Baker wrote:
From an ISP perspective, I would think that it would be of value to
offer *not* ingress filtering (whether by ACL or by uRPF) as a service
that a customer pays for.
So what is our collective position on ISPs filtering their peers?
Both the position that th
At 09:50 AM 12-10-04 -0700, Bora Akyol wrote:
How many people have seen "forged" spoofed IP addresses being used
for DOS attacks lately?
For the week starting Sept 12, our dark space telescope "saw" 1675 spoofed
DDOS attacks. No idea how many non-spoofed attacks took place during the
same time p
> From [EMAIL PROTECTED] Tue Oct 12 20:41:45 2004
> Date: Wed, 13 Oct 2004 07:09:10 +0530
> From: Suresh Ramasubramanian <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Steven Champeon <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: BCP38 making it work,
[EMAIL PROTECTED] [12/10/04 13:16 -0400]:
>
> > If I, and my little 7-man company, can afford to have me solve the
> > problem on our end, why the heck can't you do the same?
>
> You can do it because you are a 7-man company. So can I. However, companies
> the size of Sprint cannot do it.
>
M
> If I, and my little 7-man company, can afford to have me solve the
> problem on our end, why the heck can't you do the same?
You can do it because you are a 7-man company. So can I. However, companies
the size of Sprint cannot do it.
Alex
On Tue, 12 Oct 2004, Bora Akyol wrote:
> Excerpt from the text quoted above:
>
>2.3. For a DDoS attack to succeed more than once, the launch points must
>remain anonymous. Therefore, forged IP source addresses are used. From
>the victim's point of view, a DDoS attack seems to come
ning today, and
cause non-trivial problems for some providers.
From my _personal_ experience (not my company, not a scientific
sampling), it appears non-spoofed sources are a bigger problem. But
ignoring spoofed sources would be a mistake, IMHO.
--
TTFN,
patrick
on Tue, Oct 12, 2004 at 12:49:54PM -0400, [EMAIL PROTECTED] wrote:
> This is just the cold blooded economic reality. The same reality which
> dictates that only smaller companies can enfore strict anti-spam policies,
> and prevent their customers from behaving badly.
You want cold-blooded economi
> uPRF is only one of several ways to implement BCP38. you could do it with
> contracts and reverse-SLA's and thus no technology (on your side) at all:
> demand that a customer pay 10X his bill, or $1.00 per packet, whichever is
> lower, if they emit packets with source addresses no explicitly na
On 10/12/04 9:06 AM, "Paul Vixie" <[EMAIL PROTECTED]> wrote:
>
>> There is, of course, the issue of multihomed networks, or networks that
>> have satellite connectivity etc emitting spoofed source packets.
>
> y'know, SAC004 (http://www.icann.org/committees/security/sac004.txt) is
> only four p
> ...
> Example:
>
> the 'chris.net' network is a customer of MCI, his customer "bakker.net".
> 'bakker.net' decides 'chris.net' has priced transit cheaply this
> year/month/day and choses not to accept traffic from 'chris.net' but send
> all outbound traffic through 'chris.net'. 'chris.net' neve
Paul Vixie wrote:
There is, of course, the issue of multihomed networks, or networks that
have satellite connectivity etc emitting spoofed source packets.
y'know, SAC004 (http://www.icann.org/committees/security/sac004.txt) is
only four pages long, and one of those is references. you should read
> There is, of course, the issue of multihomed networks, or networks that
> have satellite connectivity etc emitting spoofed source packets.
y'know, SAC004 (http://www.icann.org/committees/security/sac004.txt) is
only four pages long, and one of those is references. you should read it
before yo
On Tue, 12 Oct 2004, Niels Bakker wrote:
>
> * [EMAIL PROTECTED] (Christopher L. Morrow) [Tue 12 Oct 2004, 05:18 CEST]:
> > a common occurance we've seen is a customer of a customer NOT
> > announcing , nor planning on announcing, their routes to their
> > upstream#1 which they use ONLY for outbo
* [EMAIL PROTECTED] (Christopher L. Morrow) [Tue 12 Oct 2004, 05:18 CEST]:
> a common occurance we've seen is a customer of a customer NOT
> announcing , nor planning on announcing, their routes to their
> upstream#1 which they use ONLY for outbound traffic (cheap transit for
> instance, and perha
At 08:39 AM 10/12/04 +0530, Suresh Ramasubramanian wrote:
Yes I know that multihoming customers must make sure packets going out to
the internet over a link match the route advertised out that link .. but
stupid multihoming implementations do tend to ensure that lots of people
will yell loudly,
On Tue, 12 Oct 2004, Suresh Ramasubramanian wrote:
> Daniel Senie wrote:
> > One of your arguments presented was that corporate customers weren't
> > asking for unicast RPF, and I responded that corporate customers are not
> > in need of automated mechanisms to implement BCP38, since in most cas
Daniel Senie wrote:
One of your arguments presented was that corporate customers weren't
asking for unicast RPF, and I responded that corporate customers are not
in need of automated mechanisms to implement BCP38, since in most cases
their networks are EDGE networks, and it's quite simple to fil
At 07:51 PM 10/11/2004, Richard A Steenbergen wrote:
On Mon, Oct 11, 2004 at 06:03:08PM -0400, Daniel Senie wrote:
>
> I've removed the rest of your message, talking about which vendors do or
> don't have what capabilities. While I agree it'd be nice if more vendors
> offered automated tools for im
On Mon, Oct 11, 2004 at 06:03:08PM -0400, Daniel Senie wrote:
>
> I've removed the rest of your message, talking about which vendors do or
> don't have what capabilities. While I agree it'd be nice if more vendors
> offered automated tools for implementing ingress filtering, such tools are
> u
At 05:41 PM 10/11/2004, Richard A Steenbergen wrote:
>On Mon, Oct 11, 2004 at 02:58:59AM +, Fergie (Paul Ferguson) wrote:
>
> It's better than a sharp stick in the eye, I'll tell ya,
> lad.
>
> Listen to me: It's called a "best current practice" for a
> reason -- people should do it. Not sit an
Fergie (Paul Ferguson) wrote:
True, but yet another cop out.
If you're not part of the solution, .
- ferg
-- Dan Hollis <[EMAIL PROTECTED]> wrote:
On Mon, 11 Oct 2004, Fergie (Paul Ferguson) wrote:
I wrote it, I stand beside it. I'm sick of hearing why people
haven't implemented it yet -- i
>On Mon, Oct 11, 2004 at 02:58:59AM +, Fergie (Paul Ferguson) wrote:
>
> It's better than a sharp stick in the eye, I'll tell ya,
> lad.
>
> Listen to me: It's called a "best current practice" for a
> reason -- people should do it. Not sit and around and endlessly
> discuss it (we've already
[EMAIL PROTECTED] wrote:
"A new worm that spreads via Microsoft's instant messaging client
began badgering users Monday, several security firms said."
http://www.techweb.com/wire/security/49900742
ah... so it's a normal microsoft problem
never the less... a "slight" notice about the ETR
"A new worm that spreads via Microsoft's instant messaging client
began badgering users Monday, several security firms said."
http://www.techweb.com/wire/security/49900742
Regards
-- amar
This message was sent using IMP, the
Yeah problems were going on all day, good to know that I am not alone..
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timo
Mohre
Sent: Monday, October 11, 2004 3:36 PM
To: [EMAIL PROTECTED]
Subject: Re: Microsoft problems?
Joe Johnson wrote:
> I
Joe Johnson wrote:
I got some sort of announcement popup on Gaim from MSN that said they
would be going down for 5 minutes. That was this morning at about 11-ish
(Central time). Came back after 2 minutes and has been fine since.
Well...
all I can say is that it's been down all day and is still
On 11/10/2004 12:26 PM Chaim Fried wrote:
Anybody know of any prolonged outages at Microsoft (MSN messenger)today?
http://messenger.msn.com/Status.aspx
--
All Features. The .NET Messenger Service is temporarily unavailable.
Pleas
PROTECTED] On Behalf Of
Miguel Mata-Cardona
Sent: Monday, October 11, 2004 1:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Microsoft problems?
same here at .sv
here we felt it as inconsistent service but then in got kaputt.
On 11 Oct 2004 at 14:26, Chaim Fried wrote:
>
> Anybody know of any pro
On Mon, Oct 11, 2004 at 02:26:33PM -0400, Chaim Fried wrote:
> Anybody know of any prolonged outages at Microsoft (MSN messenger)today?
Experiencing issues all day long here in europe.
--
Cliff Albert <[EMAIL PROTECTED]>
On Mon Oct 11, 2004, Jay Hennigan wrote:
> Papal Catholicism?
not a good forum to make this statement.
Thanks,
German
--
"Discouragement is an enemy of your perseverance. If you don't fight against
discouragement you will become pessimistic first, and lukewarm afterwards.
Be an optimist"
same here at .sv
here we felt it as inconsistent service but then in got kaputt.
On 11 Oct 2004 at 14:26, Chaim Fried wrote:
>
> Anybody know of any prolonged outages at Microsoft (MSN
> messenger)today?
>
>
>
--
Miguel Mata-Cardona
Intercom El Salvador
[EMAIL PROTECTED]
voz: ++(503) 2
Ar Mon, 11 Oct 2004 14:26:33 -0400, scríobh Chaim Fried:
>
> Anybody know of any prolonged outages at Microsoft (MSN
> messenger)today?
Yes we've been having them for the past two days... messenger.msn.com has been
unreachable for approximately 93.27% of the two days. We've had to resort to usin
I've been using MSN messenger all morning and it has been working fine
for me. I havnt heard of anyone having problems with it either.
On Mon, 2004-10-11 at 11:26, Chaim Fried wrote:
> Anybody know of any prolonged outages at Microsoft (MSN messenger)today?
>
>
Thornto
Chaim Fried wrote:
Anybody know of any prolonged outages at Microsoft (MSN messenger)today?
Sure. It was also down for "scheduled maintenance" for quite a while
yesterday.
Their website also only barfs out messages like
Server Error in '/' Application.
---
Papal Catholicism?
Ursal defecation in forested terrain?
--
Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED]
WestNet: Connecting you to the planet. 805 884-6323 WB6RDV
NetLojix Communications, Inc. - http://www.netlojix.com/
I'm experiencing connection difficulties as well
-rd-
Chaim Fried wrote:
Anybody know of any prolonged outages at Microsoft (MSN messenger)today?
Anybody know of any prolonged outages at Microsoft (MSN messenger)today?
RB> Date: Sun, 10 Oct 2004 20:14:01 -0700
RB> From: Randy Bush
RB> when it solves critical problems, it'll grow more quickly.
Maybe.
* Use 25/TCP for SMTP and 587/TCP for submission
* Block outbound SMTP by default, but allow for the clueful
* Run SMTP authentication
* Let each
when it solves critical problems, it'll grow
more quickly.
randy
SD> Date: Sun, 10 Oct 2004 21:35:33 -0400 (EDT)
SD> From: Sean Donelan
SD> People think BCP38 means the packets could only originate
SD> from you.
Were BCP38 universal, this would be true. If one receives a
packet, it's either from the supposed source or a network that
allows spoofing. If no n
True, but yet another cop out.
If you're not part of the solution, .
- ferg
-- Dan Hollis <[EMAIL PROTECTED]> wrote:
On Mon, 11 Oct 2004, Fergie (Paul Ferguson) wrote:
> I wrote it, I stand beside it. I'm sick of hearing why people
> haven't implemented it yet -- it's almost five years la
On Mon, 11 Oct 2004, Fergie (Paul Ferguson) wrote:
> I wrote it, I stand beside it. I'm sick of hearing why people
> haven't implemented it yet -- it's almost five years later
> and there's simply no excuse. It's sickening.
it's cheaper to ignore bcp38 than to implement it.
operators are reactiv
It's better than a sharp stick in the eye, I'll tell ya,
lad.
Listen to me: It's called a "best current practice" for a
reason -- people should do it. Not sit and around and endlessly
discuss it (we've already done that a thousand times).
I wrote it, I stand beside it. I'm sick of hearing why p
> I have received complaints from people about NOT being able to spoof
> packets.
Technical Support: "This is CompanyX, how can I help you?"
31337kiddi0t: "wHy c0m3 3ye c4nt sp0of?!$!*@"
With all of the different standards which tend to add confusion, too much
time seems to be going to waste
On Sun, 10 Oct 2004, James Baldwin wrote:
> I agree that BCP 38 should be implemented. I agree that BCP 38 will
> have a greater affect on network abuse than port 25 filtering. They
> both have their place and address to partially overlapping groups of
> abuse imho.
Be conservative in what you se
Hi,
depending on the IP address space from where I'm trying to reach
the two MX for @sprint.net, I'm getting either:
- no TCP connection at all (Connection refused)
- a TCP session, but not even a SMTP greeting banner
- a SMTP session, but as response to RCPT TO a 550 Access denied
For the thir
In article <[EMAIL PROTECTED]> you write:
>
>Has anyone else noticed any strange problems lately when querying
>UltraDNS for name server records?
>
>I have a few scripts that seem to have broken in the past week. A
>simple PERL script that looks up NS records from
On Mon, Aug 23, 2004 at 07:53:13PM -0400, Robert Blayzor wrote:
>
> Has anyone else noticed any strange problems lately when querying
> UltraDNS for name server records?
Not for name server records, but we do have a glue record in .org that
pops up when querying one ultradns.net TLD n
Has anyone else noticed any strange problems lately when querying
UltraDNS for name server records?
I have a few scripts that seem to have broken in the past week. A
simple PERL script that looks up NS records from the root servers, which
worked fine last week, suddenly starts reporting that
> From [EMAIL PROTECTED] Mon Aug 2 17:30:06 2004
> Date: Mon, 02 Aug 2004 18:25:00 -0400
> From: Eric Kimminau <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: problems with covad.net 192.168 address space
>
>
> Hola!
>
> Anyone having problems with cov
On Mon, 2 Aug 2004, Brian Russo wrote:
> Date: Mon, 02 Aug 2004 17:56:04 -0400
> From: Brian Russo <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: problems accessing 128.171.*
>
>
> Is anyone else having problems accessing 128.171.* (hawaii.edu)
>
>
Hola!
Anyone having problems with covad.net and 192.168 public broadcasts?
--
-1-2-3-4-5-6-7
Eric Kimminau Email: [EMAIL PROTECTED]
Senior Sales Engineer Office:248.766.9921
Rainfinity Fax
Cheers to everyone who mailed me, apparently was a pccwbtn and/or
alter.net issue. Now resolved.
thanks,
- bri
At Mon, Aug 02, 2004 at 05:56:04PM -0400, Brian Russo wrote:
>
> Is anyone else having problems accessing 128.171.* (hawaii.edu)
>
> - bri
>
> --
> Recursi
Is anyone else having problems accessing 128.171.* (hawaii.edu)
- bri
--
Recursivity. Call back if it happens again.
LOL..not a problem..:)
Michel Py wrote:
I just realized that I incorrectly quoted William Warren instead of
Brian Battle in my previous post. Sorry guys, cut/paste casualty.
Sean Donelan wrote:
Could this be a Joe job by someone who doesn't like the
owners of Cool Web Search? The owners of the Co
I just realized that I incorrectly quoted William Warren instead of
Brian Battle in my previous post. Sorry guys, cut/paste casualty.
> Sean Donelan wrote:
> Could this be a Joe job by someone who doesn't like the
> owners of Cool Web Search? The owners of the Cool Web
> Search company deny the
> > I guess the big question is, is there anyone (other than those profiting
> > directly from CWS) that would complain if a provider were to do such a
> > thing...
>
> looks like a psi-net "pink contract" inherited by cogent. but since the
> psi->cogent rollup was an asset sale rather than a cor
Is anybody experiencing issues with Sprint in Ls Vegas?
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Hi all,
We're situated firmly on AT&T, and clients of ours who are behind
Level(3) are having connectivity issues reaching us. Are there any known
problems?
AT&T has reported some to me, I am just curious if it is just the T/L3
link or if it is a bigger L3 problem.
Thanks!
//jbal
Ditto-
Frequent delays in sending to yahoo.com
-C
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Loftis
Sent: Thursday, June 17, 2004 1:53 PM
To: [EMAIL PROTECTED]
Subject: Re: Yahoo mail public notice of problems ?
--On Thursday, June
--On Thursday, June 17, 2004 15:00 -0400 Mike Tancsa <[EMAIL PROTECTED]>
wrote:
Is there a notice I can point non Yahoo Mail customers to explaining why
there are delivery delays? We are seeing a lot of stalled deliveries
again, and it would be nice to point to an explanation by yahoo as to
wha
y unavailable. Please
try again later [#4.16.3].
I checked from another network totally independent of mine and they too are
seeing similar problems.
---Mike
Mike Tancsa, tel +1 519 65
An excellent article in this month's LIGHTWAVE Magazine on Cable's entry into
traditionally-LEC and ISP deployments. In fact, Cablevision's Lightpath division
is a registered LEC in its own right:
http://lw.pennnet.com/Articles/Article_Display.cfm?
Section=ARTCL&ARTICLE_ID=204382&VERSION_NUM=1&
That's how time-warner is doing it here in Maine. However, they've
assigned voip to its own channel while digital channels occupy another and
hdtv signals are compressed and on another, etc. Its a 1Ghz system.
Everything on the system is IP including the control boxes. They also
have certai
L PROTECTED]
[EMAIL PROTECTED]','','','')">[EMAIL PROTECTED]
>Sent: Monday, May 31, 2004 12:58 PM
>To: [EMAIL PROTECTED]; ''Christopher J. Wolff''; [EMAIL PROTECTED]
>Subject: Re: [url correction] Cable networks RE: best eff
e: [url correction] Cable networks RE: best effort has economic
problems, maybe OT
Correcting a previous url error on my part.
Narad's site is at:
http://www.naradnetworks.com
Sorry 'bout that, folks.
Frank
On Mon, 31 May 2004 11:30 , <[EMAIL PROTECTED]> se
On Mon, 31 May 2004, Simon Leinen wrote:
> I don't think there's 10 GE WAN PHY for the Cisco 7600 yet. It has
> very cost-effective 10 GE *LAN* PHY (10.0 Gb/s, not SONET-compatible)
> interfaces though, which I find even more interesting (see below).
Cisco won't release a WAN PHY for a long tim
Mikael Abrahamsson writes:
> Tier 1 operators do not do "best effort" really, at least not in
> their cores (and they have the SLAs to back it up). They buy hugely
> expensive top notch gear (Cisco 12000 (and now CRS:s) and Junipers)
> to get the big packet buffers, the fast reroutes and the full
Correcting a previous url error on my part.
Narad's site is at:
http://www.naradnetworks.com
Sorry 'bout that, folks.
Frank
On Mon, 31 May 2004 11:30 , <[EMAIL PROTECTED]> sent:
>
>Agree, this is a great discussion, akin to a recent Cook Report accounting of
best
>ef
Agree, this is a great discussion, akin to a recent Cook Report accounting of best
effort considerations. Several startups (now going into year two) have addressed
the cable-HF/C constraints you've mentioned. You may be interested in perusing
these two:
http://www.narad.com
Another, Rainmaker
Neil J. McRae wrote:
I've seen compelling evidence over the past two years that clearly shows
some carriers who have sold well below cost who then also went into chapter
11.
Fascinating discovery, that. What on earth will happen to us if _that_
word leaks out?!??!
--
Requiescas in pace o email
Ex
> This problem has little to do with BE vs. QoS. It's a
> temporary market imbalance caused by providers willing to
> sell service for less than cost; in the absence of external
> factors, eventually enough providers will go under for prices
> to rise back above cost.
I've seen compelling e
Thus spake "Christopher J. Wolff" <[EMAIL PROTECTED]>
> This is a great discussion. I'm interested in understanding these types
of
> limitations in the context of HFC cable networks. In my opinion, HDTV
> channel bandwidth (30mhz?) ,
Broadcast ATSC (aka HDTV) uses the same bandwidth as broadcas
On Sun, 30 May 2004, Stephen Sprunk wrote:
> This problem has little to do with BE vs. QoS. It's a temporary market
> imbalance caused by providers willing to sell service for less than cost; in
> the absence of external factors, eventually enough providers will go under
> for prices to rise bac
401 - 500 of 960 matches
Mail list logo
