-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- William Warren [EMAIL PROTECTED] wrote:
Here in comcast land hdtv is actually averaging around 12 megabits a
second. Still adds up to staggering numbers..:)
Another disturbing fact inside this entire mess is that, by compressing
HD content,
Time to push multicast as transport for bittorrent? If the downloads get
better performance that way, I think the clients would be around quicker
that multicast would be enabled for consumer DSL or cable.
Pete
Paul Ferguson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --
Hi Guyz
We have a cisco PDSN that acts as a NAS for our Wireless BroadBand Clients.
The PDSN tackles the IP alllocation Part. This is because we have
defined the
ips to be allocated using the IP LOCAL POOL command.
Is there a way to reduce the lease period of the allocated IPs.
The IOS code is
Time to push multicast as transport for bittorrent?
Bittorrent clients are already multicast, only they do it in a crude way
that does not match network topology as well as it could. Moving to use
IP multicast raises a whole host of technical issues such as lack of
multicast peering. Solving
I think you're too high there! MPEG2 SD is around 4-6Mbps,
MPEG4 SD is
around 2-4Mbps, MPEG4 HD is anywhere from 8 to 20Mbps, depending on
how much wow factor the broadcaster is trying to give.
Nope, ATSC is 19 (more accurately 19.28) megabits per second.
So why would anyone plug
It's certainly not reasonable to assume the same video goes to all
consumers, but on the other hand, there *is* plenty of video that goes to a
*lot* of consumers. I don't really need my own personal unicast copy of the
bits that make up an episode of BSG or whatever. I would hope that the
future
So why would anyone plug an ATSC feed directly into the Internet?
Because we can. One day ISPs might do multicast and it might become
cheap enough to deliver to the home. If we don't then they probably
will never bother fixing those two problems
I've been multicasting the BBCs channels in the
On Apr 21, 2008, at 9:35 PM, Frank Bulk - iNAME wrote:
I've found it interesting that those who do Internet TV (re)define
HD in a
way that no one would consider HD anymore except the provider. =)
The FCC did not appear to set a bit rate specification for HD
Television.
The ATSC
On Tue, 22 Apr 2008 11:55:58 +0100
[EMAIL PROTECTED] wrote:
Time to push multicast as transport for bittorrent?
Bittorrent clients are already multicast, only they do it in a crude way
that does not match network topology as well as it could. Moving to use
IP multicast raises a whole
[EMAIL PROTECTED] wrote:
But there is another way. That is for software developers to build a
modified client that depends on a topology guru for information on the
network topology. This topology guru would be some software that is run
While the current bittorrent implementation is
Is there a problem that needs to be solved that is not solved by
Akamai's of the world already?
Yes, the ones that aren't Akamai want to play too
branodn
___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog
Well it had sounded like I was in the minority and should keep my mouth
shut. But here goes. On several occasions the peer that would advertise
our routes would drop and with that the peer with the full bgp tables
would drop as well. This happened for months on end. They tried blaming
our
All this talk of exafloods seems to ignore the basic economics of
IP networks. No ISP is going to allow subscribers to pull in 8gigs
per day of video stream. And no broadcaster is going to pay for the
bandwidth needed to pump out all those ATSC streams. And nobody is
going to stick IP
[EMAIL PROTECTED] wrote:
...
You need a way to insert non-technical
information about the network into the decision-making process.
The only way for this to work is to allow the network operator
to have a role in every P2P transaction. And to do that you need
a middlebox that sits in the
(I know, replying to your own email is sad ...)
You could probably do this with a variant of DNS. Use an Anycast
address common to everyone to solve the discovery problem. Client
sends a DNS request for a TXT record for, as an example,
148.165.32.217.p2ptopology.org. The topology box
NCAP - Network Capability (or Cost) Announcement Protocol.
On Tue, Apr 22, 2008 at 2:24 PM, Matthew Moyle-Croft [EMAIL PROTECTED]
wrote:
(I know, replying to your own email is sad ...)
You could probably do this with a variant of DNS. Use an Anycast
address common to everyone to solve the
Well it had sounded like I was in the minority and should keep my mouth
shut. But here goes. On several occasions the peer that would advertise
our routes would drop and with that the peer with the full bgp tables
would drop as well. This happened for months on end. They tried blaming
our
On Tue, Apr 22, 2008 at 2:02 PM, Joe Greco [EMAIL PROTECTED] wrote:
As far as I am concerned the killer application for IP multicast is
*NOT* video, it's market data feeds from NYSE, NASDAQ, CBOT, etc.
You can go compare the relative successes of Yahoo! Finance and YouTube.
While it
On Tue, Apr 22, 2008 at 02:02:21PM +0100,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 46 lines which said:
This is where all the algorithmic tinkering of the P2P software
cannot solve the problem. You need a way to insert non-technical
information about the network into the
Well it also was the total arrogance on the part of Cogent engineering
and management taking zero responsibility and pushing it back everytime
valid issue or not. You had to be there. But everyone has a different
opinion, my opinion is set regardless of what cogent tries to sell me now.
I've tried from 4-5 different mail providers to send something to
[EMAIL PROTECTED]
Can't figure out what's wrong, as I've never seen AuthRequired anywhere
before.
Every single one of them has gotten the reply of:
*Delivery has failed to these recipients or distribution lists:*
[EMAIL
This raises an interesting issue - should optimization of p2p traffic (P4P) be
based on static network information, or dynamic network information. It's
certainly easier for ISP's to provide a simple network map that real-time
network condition data, but the real-time data might be much more
On Apr 22, 2008, at 9:15 AM, Marc Manthey wrote:
Am 22.04.2008 um 16:05 schrieb Bruce Curtis:
p2p isn't the only way to deliver content overnight, content could
also be delivered via multicast overnight.
http://www.intercast.com/Eng/Index.asp
http://kazam.com/Eng/About/About.jsp
hmm
On Tue, 22 Apr 2008 10:44:07 -0400
Jake Matthews [EMAIL PROTECTED] wrote:
I've tried from 4-5 different mail providers to send something to
[EMAIL PROTECTED]
Can't figure out what's wrong, as I've never seen AuthRequired anywhere
before.
If it is security related, I highly recommend you
Try the voice route .. their helpdesk is (859) 257-1300
Cheers,
Michael Holstein
Cleveland State University
I've tried from 4-5 different mail providers to send something to
[EMAIL PROTECTED]
Can't figure out what's wrong, as I've never seen AuthRequired anywhere
before.
Every single
IP multicast does not help you when you have 1000 subscribers
all pulling in 1000 unique streams.
Yes, that's potentially a problem. That doesn't mean that
multicast can not be leveraged to handle prerecorded
material, but it does suggest that you could really use a
TiVo-like
On Tue, Apr 22, 2008, Marc Manthey wrote:
hmm sorry i did not get it IMHO multicast ist uselese for VOD ,
correct ?
As a delivery mechanism to end-users? Sure.
As a way of feeding content to edge boxes which then serve VOD?
Maybe not so useless. But then, its been years since I toyed with
On 22 Apr 2008, at 12:47, Joe Greco wrote:
You mean a computer? Like the one that runs file-sharing
clients?
Like the one that nobody really wants to watch large quantities of
television on?
Perhaps more like the mac mini that's plugged into the big plasma
screen in the living room? Or
The OSCAR is the first H.264 encoder appliance designed by HaiVision
specifically for QuickTime environments. It natively supports
the RTSP streaming media protocol. The OSCAR can stream directly to
QuickTime supporting up to full D1 resolution (full standard
definition resolution or 720 x 480
I know I have experienced the engineering department there as well, the
best one was when they wanted paper documentation for every route I
asked to have in our filters... (and they were incapable of using
RADB). It was especially odd since we have 80 of our own peers and
three other transit
I'm pleased to announce the next OARC DNS Operations meeting will take
place immediately after the NANOG43 meeting, in Brooklyn, NY, USA.
The venue will be CUNY's Brooklyn College, about 5 miles from the NANOG
Hotel. The open DNS Operations workshop will take place on the afternoon
of Wed 4th
John van Oppen (list account) wrote:
I know I have experienced the engineering department there as well, the
best one was when they wanted paper documentation for every route I
asked to have in our filters... (and they were incapable of using
RADB). It was especially odd since we have 80
On 22 Apr 2008, at 12:47, Joe Greco wrote:
You mean a computer? Like the one that runs file-sharing
clients?
Like the one that nobody really wants to watch large quantities of
television on?
Perhaps more like the mac mini that's plugged into the big plasma
screen in the living
Is there a prefix list available listing the IP space of cryptographic
export restricted countries? My google skills are failing me. I'm
required to apply a ban on North Korea, Iran, Syria, Sudan and Cuba.
___
NANOG mailing list
NANOG@nanog.org
...is the first H.264 encoder .. designed by
specifically for ... environments. It natively supports
the RTSP streaming media protocol. can stream directly to
.
hi marc
so your oskar can rtsp multicast stream over ipv6 and quicktime
not , or was this just an
35 matches
Mail list logo
