Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Brian Butterworth
On 15/04/2008, Gareth Davis <[EMAIL PROTECTED]> wrote:
>
>  Brian,
> It has been pointed out several times now that the problem is between the
> home user and the ISP, not the ISP and the BBC/Akamai. Although it might
> appear from a traceroute that there is nothing between your home router and
> your ISP - there is, but the IP traffic is encapsulated and passed within
> BTs ATM cloud so you cannot see it. It is the cost of moving the
> encapsulated IP within this cloud between the home user and the ISP where
> the problem is.
>

One does not depend upon traceroute for anything in these situations...  you
never learn anything to your advantage.

Once again it is a great shame that we ended up with this deformed IP
network, if the model had been constructed in a truly competitive market, as
with the US, this problem would not have arisen.


No amount of caching or proxying at the ISP end will help, because it
> is outside the ATM cloud. If any caching were to be effective it would have
> to work inside the cloud at exchange or regional level, and I'm not aware of
> any technology that can read the ATM packets, decap the IP packets from
> them, interpret the IP packets - then inject more packets with correctly
> encapsulated and valid IP into the ATM cloud as a response. All this would
> have to be at wire speed so as not to add latency to all connections passing
> through the device. Without doing this, there is no where else to put the
> proxy for it to be effective.
>
> Anyone who thinks they can do this, go and build it. You stand to make a
> vast amount of money installing them in every exchange.
>

Putting the equipment in each exchange was, as I recall, was actually the
conclusion of the report I wrote, all that time ago.  And there is so much
room in them as they were all built in the old Strouger days...




-- 
> *Gareth Davis* | Production Systems Specialist
> World Service Future Media, Digital Delivery Team - Part of BBC Global
> News Division
> 8 http://www.bbcworldservice.com/ + 702NE Bush House, Strand, London, WC2B
> 4PH
>
>  --
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Brian Butterworth
> *Sent:* 15 April 2008 17:14
> *To:* backstage@lists.bbc.co.uk
> *Subject:* Re: [backstage] iPlayer and the ISPs - a solution
>
> You are saying that the capacity on each individual ADSL line here is the
> problem?  I really don't see that.  The STATED problem is PAYING for the
> PIPES to backbone from BT.  If this isn't the problem, then someone is
> lying.
>
>
>


-- 
Please email me back if you need any more help.

Brian Butterworth
http://www.ukfree.tv


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Peter Bowyer
On 15/04/2008, Brian Butterworth <[EMAIL PROTECTED]> wrote:
>
>
> On 15/04/2008, Peter Bowyer <[EMAIL PROTECTED]> wrote:
> > On 15/04/2008, Jason Cartwright <[EMAIL PROTECTED]> wrote:
> > > Isn't this what Akamai are doing for the iPlayer content already?
> >
> >
> > Yes
> >
> >
> > > Doesn't
> > > get the content close enough to the consumer to solve the issues ISPs
> > > apparently have.
> >
> >
> > No - as has been pointed out several times here, it's the last-mile
> > (individual ADSL line)
>
>
> You are saying that the capacity on each individual ADSL line here is the
> problem?  I really don't see that.  The STATED problem is PAYING for the
> PIPES to backbone from BT.  If this isn't the problem, then someone is
> lying.

Not capacity of those lines, but the commercial model involved.


> > and second-last-mile (backhaul from DLE to the
> > ISP's network via BT's ATM network) that's the problem. BTW's
> > usage-based-charging model on IPStream makes it jolly expensive for
> > the ISP when the bandwidth utilisation goes up. Their business model
> > is based on an average utilisation which they see as under threat.
>
>
> Ah, back to the BT-behaves-like-a-monopoly-issue.

Not really, no. The introduction of usage-based charging on IPStream
enabled BTW's resellers to compete on price with the LLU operators and
their resellers. The reseller is able to decide their own price points
and usage caps in order to differentiate their offering, attract the
bit of the market they're interested in, and hopefully still make a
profit based on the mix of punters and their usage patterns. The older
capacity-based charge simply left them making a fixed and
downward-trending margin reselling a simple product.
.
If suddenly all their punters' usage patterns change for the worse,
this screws their business model - hence the outcry about iPlayer.

IPStream backhaul is a bit simpler - resellers buy it in bandwidth
chunks called 'central pipes' - small ones (STM-1) or large ones
(Gig-E). There's no metering as such, but obviously the aggregate
bandwidth demands from a reseller's userbase, the more pipes they need
to maintain a given level of contention.

Peter

-- 
Peter Bowyer
Email: [EMAIL PROTECTED]
Follow me on Twitter: twitter.com/peeebeee
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


RE: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Gareth Davis
Brian,
It has been pointed out several times now that the problem is between
the home user and the ISP, not the ISP and the BBC/Akamai. Although it
might appear from a traceroute that there is nothing between your home
router and your ISP - there is, but the IP traffic is encapsulated and
passed within BTs ATM cloud so you cannot see it. It is the cost of
moving the encapsulated IP within this cloud between the home user and
the ISP where the problem is.
 
No amount of caching or proxying at the ISP end will help, because it is
outside the ATM cloud. If any caching were to be effective it would have
to work inside the cloud at exchange or regional level, and I'm not
aware of any technology that can read the ATM packets, decap the IP
packets from them, interpret the IP packets - then inject more packets
with correctly encapsulated and valid IP into the ATM cloud as a
response. All this would have to be at wire speed so as not to add
latency to all connections passing through the device. Without doing
this, there is no where else to put the proxy for it to be effective.
 
Anyone who thinks they can do this, go and build it. You stand to make a
vast amount of money installing them in every exchange.
-- 
Gareth Davis | Production Systems Specialist
World Service Future Media, Digital Delivery Team - Part of BBC Global
News Division
* http://www.bbcworldservice.com/ <http://www.bbcworldservice.com/>  *
702NE Bush House, Strand, London, WC2B 4PH






From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Butterworth
Sent: 15 April 2008 17:14
To: backstage@lists.bbc.co.uk
Subject: Re: [backstage] iPlayer and the ISPs - a solution


You are saying that the capacity on each individual ADSL line
here is the problem?  I really don't see that.  The STATED problem is
PAYING for the PIPES to backbone from BT.  If this isn't the problem,
then someone is lying.
 



Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Brian Butterworth
On 15/04/2008, Peter Bowyer <[EMAIL PROTECTED]> wrote:
>
> On 15/04/2008, Jason Cartwright <[EMAIL PROTECTED]> wrote:
> > Isn't this what Akamai are doing for the iPlayer content already?
>
>
> Yes
>
>
> > Doesn't
> > get the content close enough to the consumer to solve the issues ISPs
> > apparently have.
>
>
> No - as has been pointed out several times here, it's the last-mile
> (individual ADSL line)


You are saying that the capacity on each individual ADSL line here is the
problem?  I really don't see that.  The STATED problem is PAYING for the
PIPES to backbone from BT.  If this isn't the problem, then someone is
lying.


and second-last-mile (backhaul from DLE to the
> ISP's network via BT's ATM network) that's the problem. BTW's
> usage-based-charging model on IPStream makes it jolly expensive for
> the ISP when the bandwidth utilisation goes up. Their business model
> is based on an average utilisation which they see as under threat.


Ah, back to the BT-behaves-like-a-monopoly-issue.


LLU operators have more flexibility because typically their backhaul
> network is not accounted for on a usage-based model.
>
> Again as has been mentioned before, these are financial issues not
> technical ones.





Peter
>
>
> --
> Peter Bowyer
> Email: [EMAIL PROTECTED]
> Follow me on Twitter: twitter.com/peeebeee
> -
>
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial
> list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>



-- 
Please email me back if you need any more help.

Brian Butterworth
http://www.ukfree.tv


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Brian Butterworth
 Dutch providers and tv-zenders start this autumn with a new cooperation for
the distribution of video by means of Internet. That is necessary because of
the fast increase of online video.

In the cooperation bond around the Internet button point
Ams-IXwork
some providers and the public broadcasting and RTL for common
appointments and an open protocol with which video distribution must become
by means of Internet cheaper and more reliable. The first technical tests
starts this autumn. In the system most popular content on the servers of
provider themselves it is put automatically.

The previous years were there already mutual appointments between providers
exchange band width at Ams-IX, the ' peering '. The new system goes
according to the people concerned a step further. It ensures that
automatically on servers of the providers to come stand whereupon they most
examined video files the those pictures within its own network are able
spread.

That saves date movement to the providers and the servers of tv-zenders also
less is by it charged.

A similar system twists already internal at the public broadcasting. Ams-IX
the video working party is open for all Ams-IX members. A subgroup with
among others the public broadcasting, RTL, XS4all and Solcon develop the
protocol and the appointments.

We look at if we can an open system in which contentbedrijven offer directly
to providers make and that can distribute then within their own network this
way efficient possible further. And that this way automated possible,
technical director of XS4All says Simon Hania. Oftewel: automatic caching of
most interesting content at the ISP.

We want agree an open protocol with which can be exchanged content and as
closely as possible to the end-user can be brought. Then is finished
automatically content. The most popular videos are added up by provider. If
maximumaantal are reached, then the file is moved to its own network of the
provider", lay Egon moult, consultant new media of the public broadcasting,
from.

*' worldwide unique ' *

The system is formulated as internetdraft. Within a couple months must be it
ready. The complete procedure, the totaalpakket, is worldwide still nowhere
present. thus Simon Hania.

The situation in the Netherlands is favourable for the cooperation between
providers and senders because of Ams-IX, success of on demand-video at the
public broadcasting and RTL, and the high number of broadband connections.
In the Netherlands we everything have concentrated spots on a couple.
Moreover we have here already much online videocontent and the question
after that is large", Jan Paul Dekker, say chef of technique at RTL.

Because it concerns a test it is not yet looked at there to possible
business models and setoffs, although the protocol for that, however, space
gives, or to legal complications. According to Hania there ' expressly ' it
is not spoken concerning ' commercial models '. It is beautiful that that
does not need also. We have rapidly come free behind what the common
interests to be: content must come well and cheap at the end-users.

*capacity problems*

The company Jetstream provides expertise to several providers and technique
for the test, says director Stef of of the soul. "at a couple providers
already spullen stand which can be used immediately, and at Surfnet also a
test will be set up", thus of of the soul, which set up the first live
videostream in the Netherlands in 1994, of metalconcert in a gronings youth
centre.

Sometimes providers reach now already their capacity by the large number of
internetkijkers. That happened for example in July then the NOS by means of
the company Garnier live-beelden of the tour the France by means of Internet
transmitted. Several providers walked towards then against their
limits.
Of the causes was that those stream were sent from one point, where
providers did not cooperate mutually.

All providers are not according to of of the soul always even glad with the
old peering model: Because the proportions between the movement which does
not flow back and forth equal be. The proportion is sometimes gone.

According to the people concerned turn out better than expected the problems
cause by the growing popularity of online video now still, but it are the
question if that is concerning a couple year still this way. Now it is
problem still no. But if the large catalogue with old programmes is ask
easily by means of the remote control on the TV, then the question increases
still much, and is possible it a larger problem becomes. thus Jan Paul
Dekker van RTL.

*Peer-to-peer not ideal
*
Recently British providers reacted incensed to the new on
demand-videosoftware of the BBC, the
iPlayer

Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Werner Ramaekers
What Brian explained is how the dutch public broadcast organization is
collaborating with 8 ISP's to ensure the best service for catch-up tv
over the internet (uitzendiggemist.nl)
There is an article in dutch that explains this collaboration :
http://www.emerce.nl/nieuws.jsp?id=2103122


-- 
--
ir. Werner Ramaekers

Read my Blog at http://www.werner.be
--

Werner Ramaekers
Internet Technologies for Media

VRT Medialab -IBBT

On Tue, Apr 15, 2008 at 2:39 PM, Jeremy James <[EMAIL PROTECTED]> wrote:
> Brian Butterworth wrote:
>  > * ISPs provide rack space for BBC servers inside their network
>
>  * Who pays for servers?
>  * Who maintains servers? ISP? Siemens?
>  * Who pays for power usage?
>
>  > * ISPs provide list of IP addresses to directed to said servers
>
>  * How is this done? Manually? How many ISPs? Or as fun as those
>  automatic emails to/from Nominet?
>  * ISPs sometimes move users from one end of the country to the other on
>  the same IPs, but via different (effective) POPs. How much information
>  needs to be transmitted to allow closer proxies?
>  * Is the mapping of IPs to logical network layout confidential?
>
>  > * BBC copies each new file (and deletes) to these servers
>
>  * How much disk space required?
>  * Standard protocols to copy files? (rsync? HTTP?) New ones?
>  * How can you be sure ISPs delete the content when they are meant to?
>
>  > * iPlayer software detect and redirects to BBC servers inside ISP network
>
>  * Big list of IPs to scan on a regular basis. Performance issues?
>  * What if ISP proxy is dead?
>  * What if it dies during playback?
>  * What if it doesn't have the content yet/already deleted it?
>
>  > * Interim solution until fatter pipes purchased, say 2-3 years.
>
>  * Agreed. Fibre FTW, as they say.
>  * But who pays?
>
>  -jeremy
>  -
>  Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial list archive: 
> http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Peter Bowyer
On 15/04/2008, Jason Cartwright <[EMAIL PROTECTED]> wrote:
> Isn't this what Akamai are doing for the iPlayer content already?

Yes

> Doesn't
> get the content close enough to the consumer to solve the issues ISPs
> apparently have.

No - as has been pointed out several times here, it's the last-mile
(individual ADSL line) and second-last-mile (backhaul from DLE to the
ISP's network via BT's ATM network) that's the problem. BTW's
usage-based-charging model on IPStream makes it jolly expensive for
the ISP when the bandwidth utilisation goes up. Their business model
is based on an average utilisation which they see as under threat.

LLU operators have more flexibility because typically their backhaul
network is not accounted for on a usage-based model.

Again as has been mentioned before, these are financial issues not
technical ones.

Peter

-- 
Peter Bowyer
Email: [EMAIL PROTECTED]
Follow me on Twitter: twitter.com/peeebeee
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Jason Cartwright
Isn't this what Akamai are doing for the iPlayer content already? Doesn't
get the content close enough to the consumer to solve the issues ISPs
apparently have.

J

On Mon, Apr 14, 2008 at 5:46 AM, Brian Butterworth <[EMAIL PROTECTED]>
wrote:

> I have to say that I am very impressed with Ashly Highfield at the
> moment.  His defense of the public interest and also of BBC money is worthy
> of high praise.
>
> He is 100% correct when he says that the Internet Service Providers should
> provide an Internet service.  The whole way the Internet has developed (and
> I've been using ever since it could be reached in the UK) has required ISPs
> to buy bigger and bigger pipes, to support more and more users.  The
> economics (which I have gone into before) provides that the more you buy,
> the cheaper each bit becomes.
>
> The ISPs (just to recap) are complaining because they need more capacity
> because the BBC iPlayer is popular, and people are suddenly watching whole
> half-hour and hour-long programmes, streamed from the BBC's servers.
>
> I am of the mind that if you are a Internet host (like the BBC in this
> case) then you pay for your end of the connection to the cloud and the
> end-user pays for theirs via their ISP.
>
> So, Mr Highfield is correct to reject the idea that the BBC should pay for
> ISPs Internet pipes.
>
> However, I wrote a paper about this when I worked at BT Broadcast Services
> (about ten years ago, in fact) about dealing with this situation, and as I
> recall (I don't have it here with me on Crete) there are a few ways to deal
> with it:
>
> 1. ISPs by BIGGER PIPES and upgrade their network.  This is 100% the
> correct answer in the long run.  Moore's Law tends to work at a bit-delivery
> level, so the great evil here is probably the BT wholesale provision which
> seems to be behaving somewhat monopolisticly, which is a tendency that I
> know BT has.
>
> 2. Use transparent or non-transparent PROXY SERVERS.  This might work, but
> my experience of them is that transparent proxies reduce overall performance
> because they need to get in the way of each and every HTTP transaction.
> Non-transparent proxies are fine on corporate and educational networks
> because you deny access to people who do not use them, or you can do
> complicated configuration scripts.
>
> 3. Store and forward: Locate MIRROR SERVERS inside the ISP network.  This
> seems a much better idea.  Rather than the ISP being given BBC cash, which
> is an intolerable idea, the ISP provide the BBC with rack space 'inside'
> their networks for mirror servers.  These could work in one of two ways:
>
> - use DNS to redirect the requests for content (the massive files that are
> the video 'streams') to these servers.
>
> - change the main BBC iPlayer to redirect requests for the content to the
> Mirror Server located in the ISPs network.
>
> DNS is a tricy beast and almost impossible to manage in these situations,
> due to the way it is cached.  If people switch networks regularly, which
> they do, DNS trickery can turn into a nightmare.
>
> The second solution is clearly a better one.  The iPlayer already checks
> the end-users IP address to ensure that they are in the UK.
>
> It would be very simple to check to see if the users is in the range for a
> particular ISP and issue a HTTP redirect (or similar) to the ISPs server to
> get the content.
>
> The BBC would simply have to provide servers for each ISP which are fed
> with each of the iPlayer content files when they are produced, and manage
> the IP address lists for each server on a central BBC machine.
>
> This would mean transferring each file to the BBC machine inside the ISP
> network just once, and this would take seconds as it would be out there in
> the 'fat pipe' bit of the cloud.
>
> Finally, the client Flash Player software would need to know that if the
> content could not be obtained for some reason from the BBC machine inside
> the ISPs network, by calling back to the main BBC iPlayer server with an
> extra parameter.
>
> The BBC could argue that the ISP should provide these mirror servers, but
> as the hardware and storage costs of much machines is 'tiny' (and fixed) it
> would be better for these to remain under BBC control, from a management and
> responsibility point of view.
>
> Now, cut the crap and make it happen...
>
> Brian Butterworth
> http://www.ukfree.tv
>
>
>


-- 
Jason Cartwright
Web Specialist, EMEA Marketing
[EMAIL PROTECTED]
+44(0)2070313161


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Jeremy James
Brian Butterworth wrote:
> * ISPs provide rack space for BBC servers inside their network

* Who pays for servers?
* Who maintains servers? ISP? Siemens?
* Who pays for power usage?

> * ISPs provide list of IP addresses to directed to said servers

* How is this done? Manually? How many ISPs? Or as fun as those
automatic emails to/from Nominet?
* ISPs sometimes move users from one end of the country to the other on
the same IPs, but via different (effective) POPs. How much information
needs to be transmitted to allow closer proxies?
* Is the mapping of IPs to logical network layout confidential?

> * BBC copies each new file (and deletes) to these servers

* How much disk space required?
* Standard protocols to copy files? (rsync? HTTP?) New ones?
* How can you be sure ISPs delete the content when they are meant to?

> * iPlayer software detect and redirects to BBC servers inside ISP network

* Big list of IPs to scan on a regular basis. Performance issues?
* What if ISP proxy is dead?
* What if it dies during playback?
* What if it doesn't have the content yet/already deleted it?

> * Interim solution until fatter pipes purchased, say 2-3 years.

* Agreed. Fibre FTW, as they say.
* But who pays?

-jeremy
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Fearghas McKay


On 15 Apr 2008, at 12:50, Brian Butterworth wrote:

I'm really suprised that no-one actually read what I wrote.



We do - it is just that your solution does not solve the cost issues  
of the second last & last mile.


The cost of data transport is not from the BBC to the ISP NOC/Data  
Centre as that is probably on local fibre inside a data centre in  
Docklands where they are both peering. The cost is the haul to the  
ISP customer from there - your proposal does not address that.


Furthermore the fatter pipes in the future do not solve the charging  
issue for UK transit. This is an economic issue not a technical  
capacity issue.


f
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Brian Butterworth
I'm really suprised that no-one actually read what I wrote.

Let me make it really simple, as it seems no-one can read something until
the end anymore (I presume no-one gets to do the test paper where the last
"question" says "on this occasion to pass you must not complete any of the
above questions").

Bullet points, people:

* proxy servers - bad
* store and forward - good
* Doing redirect using DNS - bad
* File synchronization - great, fast in backbone network
* Differential file sync - 100% unnecessary

So:

* ISPs provide rack space for BBC servers inside their network
* ISPs provide list of IP addresses to directed to said servers
* BBC copies each new file (and deletes) to these servers
* iPlayer software detect and redirects to BBC servers inside ISP network
* Interim solution until fatter pipes purchased, say 2-3 years.



On 15/04/2008, Darren Stephens <[EMAIL PROTECTED]> wrote:
>
>  Just a few thoughts (some of which may be emanating from my posterior,
> but no matter):
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Brian Butterworth
> *Sent:* Monday, April 14, 2008 5:38 PM
> *To:* backstage@lists.bbc.co.uk
> *Subject:* Re: [backstage] iPlayer and the ISPs - a solution
>
>
>
>
> > but my experience of them is that transparent proxies reduce overall
> > performance because they need to get in the way of each and every HTTP
> > transaction.
>
>  Yes, I suppose in theory, but use of appropriate routing and firewalling
> means not in practice. Though adding this before the application layers will
> introduce a separate latency of its own. It would be difficult to filter
> such traffic on port admittedly, but not on other things, like source and
> dest addresses (see below).
>
>
> I wouldn't have thought that the small increase in latency would be
> noticeable for a several hundred megabyte file.
>
>  I would have thought otherwise, since the latency is, almost by
> definition, indeterminate and could, in fact, be appreciable, especially if
> under high load
>
>
> > 3. Store and forward: Locate MIRROR SERVERS inside the ISP network.
> > This seems a much better idea.
>
>  But the BBC's network does a LOT of this mirroring and load balancing
> stuff already, certainly if you look at some parts of their operation (like
> News) and especially with HTTP.
>
> It wouldn't work otherwise. And when it doesn't quite work like that,
> performance does suffer.
>
>
> It sounds a lot like some kind of Cache. And another question is *who*
> is going to pay for the servers that speak RTMP? This sounds like some
> kind of revenue driving scheme for the BBC's commercial friends.
>
>
> > the ISP provide the BBC with rack
> > space 'inside' their networks for mirror servers.
>
>
>
> A generic cache would be much more scalable, if the servers only mirror
> BBC data then this does nothing to solve problems with other sites.
>
> How does one mirror this data? Will it be available via rsync? Will it
> be mirrorable by *anyone* or does the BBC intend to pick and chose
> commercial ISPs to provide better access to. Again very shaky ground.
>
>  And even though technologies like rsync are largely differential, the
> traffic generated from such syncing is not trivial, especially if the
> content is in binary formats and not textual. Because constructed deltas
> that are used for syncing may not be that small. And, more prosaically, once
> the data is inside the ISP's networks, who is responsible for it?
>
>
> > - change the main BBC iPlayer to redirect requests for the content to
> > the Mirror Server located in the ISPs network.
>
> Really unscalable, how is the BBC going to know which ISPs have mirrors
> and which do not? This would require each ISP to notify the BBC. Just
> seems wrong. Having every Content Provider have to speak to every ISP
> seems to go against the core of the Internet.
>
>
>
> If the BBC is decides to provide such a service, what is wrong with it
> whitelisting those who sign up to use it?
>
> Not necessarily something I agree with but not unfeasible from a technical
> point of view. Potentially very fiddly however and, as rightly pointed out,
> not hugely scalable for the long term.
>
>
> If a pipe on the Internet is not running at 100% it is being underused!
>
>
>
> On the other hand, a pipe running at 100% could clearly be considered
> borderline congested.
>
>
>
> Andy
>
> [1]
> <
> http://www.opsi.gov.uk/acts/acts1998/ukpga_19980041_en_2#pt1-ch2-pb2-l1g18
> >
>
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please
> visit ht

RE: [backstage] iPlayer and the ISPs - a solution

2008-04-15 Thread Darren Stephens
Just a few thoughts (some of which may be emanating from my posterior,
but no matter):

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Butterworth
Sent: Monday, April 14, 2008 5:38 PM
To: backstage@lists.bbc.co.uk
Subject: Re: [backstage] iPlayer and the ISPs - a solution

 


> but my experience of them is that transparent proxies reduce overall
> performance because they need to get in the way of each and every HTTP
> transaction.



Yes, I suppose in theory, but use of appropriate routing and firewalling
means not in practice. Though adding this before the application layers
will introduce a separate latency of its own. It would be difficult to
filter such traffic on port admittedly, but not on other things, like
source and dest addresses (see below).


I wouldn't have thought that the small increase in latency would be
noticeable for a several hundred megabyte file.



I would have thought otherwise, since the latency is, almost by
definition, indeterminate and could, in fact, be appreciable, especially
if under high load


> 3. Store and forward: Locate MIRROR SERVERS inside the ISP network.
> This seems a much better idea.



But the BBC's network does a LOT of this mirroring and load balancing
stuff already, certainly if you look at some parts of their operation
(like News) and especially with HTTP. 

It wouldn't work otherwise. And when it doesn't quite work like that,
performance does suffer.


It sounds a lot like some kind of Cache. And another question is *who*
is going to pay for the servers that speak RTMP? This sounds like some
kind of revenue driving scheme for the BBC's commercial friends.


> the ISP provide the BBC with rack
> space 'inside' their networks for mirror servers.



 

A generic cache would be much more scalable, if the servers only mirror
BBC data then this does nothing to solve problems with other sites.

How does one mirror this data? Will it be available via rsync? Will it
be mirrorable by *anyone* or does the BBC intend to pick and chose
commercial ISPs to provide better access to. Again very shaky ground.



And even though technologies like rsync are largely differential, the
traffic generated from such syncing is not trivial, especially if the
content is in binary formats and not textual. Because constructed deltas
that are used for syncing may not be that small. And, more prosaically,
once the data is inside the ISP's networks, who is responsible for it?


> - change the main BBC iPlayer to redirect requests for the content to
> the Mirror Server located in the ISPs network.

Really unscalable, how is the BBC going to know which ISPs have mirrors
and which do not? This would require each ISP to notify the BBC. Just
seems wrong. Having every Content Provider have to speak to every ISP
seems to go against the core of the Internet.

 

If the BBC is decides to provide such a service, what is wrong with it
whitelisting those who sign up to use it?

Not necessarily something I agree with but not unfeasible from a
technical point of view. Potentially very fiddly however and, as rightly
pointed out, not hugely scalable for the long term.


If a pipe on the Internet is not running at 100% it is being underused!

 

On the other hand, a pipe running at 100% could clearly be considered
borderline congested.



Andy

[1]
<http://www.opsi.gov.uk/acts/acts1998/ukpga_19980041_en_2#pt1-ch2-pb2-l1
g18>

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe,
please visit
http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
Unofficial list archive:
http://www.mail-archive.com/backstage@lists.bbc.co.uk/




-- 
Please email me back if you need any more help.

Brian Butterworth
http://www.ukfree.tv 

*
To view the terms under which this email is distributed, please go to 
http://www.hull.ac.uk/legal/email_disclaimer.html
*

Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Brian Butterworth
On 14/04/2008, Paul Doyle <[EMAIL PROTECTED]> wrote:
>
> BBC chief quits to launch online service
> http://www.ft.com/cms/s/0/202eab38-09ae-11dd-81bf-779fd2ac.html
>
> Ashley Highfield, the BBC's director of future media and technology,
> is leaving the corporation to launch a joint online video platform for
> the BBC, ITV   and Channel 4 which the broadcasters hope will be "a
> Freeview for the internet".
>
> "His appointment as chief executive of the on-demand service,
> code-named Kangaroo..."



So called, of course, because it's in the pocket of PACT :-D


Brian Butterworth
http://www.ukfree.tv


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Brian Butterworth
Andy,

It would be lovely if you read my email to the end first!

On 14/04/2008, Andy <[EMAIL PROTECTED]> wrote:
>
> Brian Butterworth wrote:
> > 1. so the great evil here is probably the BT wholesale
>
> > provision which seems to be behaving somewhat monopolisticly, which is a
> > tendency that I know BT has.
>
>
> Abuse of dominant position is prohibited under Section 18 of the
> Competition Act 1998[1]. If BT are "behaving somewhat monopolisticly"
> shouldn't Ofcom do something about it?
>
>
> > 2. Use transparent or non-transparent PROXY SERVERS.
>
>
> As stated earlier it is unsafe to cache protocols you can't understand.
> Thus the BBC is blocking the ISPs from using this course of action.
> The BBC however should immediately cease this practice and use a
> protocol that ISPs can cache if they want. (HTTP has support for caching
> built into it, how forward thinking of them).
>
>
> > but my experience of them is that transparent proxies reduce overall
> > performance because they need to get in the way of each and every HTTP
> > transaction.
>
>
> I wouldn't have thought that the small increase in latency would be
> noticeable for a several hundred megabyte file.
>
>
> > 3. Store and forward: Locate MIRROR SERVERS inside the ISP network.
> > This seems a much better idea.
>
>
> It sounds a lot like some kind of Cache. And another question is *who*
> is going to pay for the servers that speak RTMP? This sounds like some
> kind of revenue driving scheme for the BBC's commercial friends.
>
>
> > the ISP provide the BBC with rack
> > space 'inside' their networks for mirror servers.
>
>
> A generic cache would be much more scalable, if the servers only mirror
> BBC data then this does nothing to solve problems with other sites.
>
> How does one mirror this data? Will it be available via rsync? Will it
> be mirrorable by *anyone* or does the BBC intend to pick and chose
> commercial ISPs to provide better access to. Again very shaky ground.
>
>
> > - change the main BBC iPlayer to redirect requests for the content to
> > the Mirror Server located in the ISPs network.
>
>
> Really unscalable, how is the BBC going to know which ISPs have mirrors
> and which do not? This would require each ISP to notify the BBC. Just
> seems wrong. Having every Content Provider have to speak to every ISP
> seems to go against the core of the Internet.
>
> If a pipe on the Internet is not running at 100% it is being underused!
>
> Andy
>
> [1]
> <
> http://www.opsi.gov.uk/acts/acts1998/ukpga_19980041_en_2#pt1-ch2-pb2-l1g18
> >
>
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial
> list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>



-- 
Please email me back if you need any more help.

Brian Butterworth
http://www.ukfree.tv


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Frank Wales

Mr I Forrester wrote:

   Virgin Media CEO Says Net Neutrality is “A Load of Bollocks”

The new CEO of Virgin Media is putting his cards on the table early, 
branding net neutrality “a load of bollocks” and claiming he’s already 
doing deals to deliver some people’s content faster than others. If you 
aren’t prepared to cough up the extra cash, he says he’ll put you in the 
Internet “bus lane”.


http://torrentfreak.com/virgin-media-ceo-says-net-neutrality-is-a-load-of-bollocks-080413/ 


I think the interesting statement in this article is:


With around 3.5 million customers in the UK, and already traffic shaping due to 
lack of capacity, [...]


Or, in other words: "Having signed up far more customers than their
existing technical infrastructure can handle, [...]".

I bet this guy would get on really well with that other bozo who, as head of
some US TV network, claimed that skipping commercials was stealing the 
programmes,
since both of them seem to want the world to change so that their business 
models can work.
--
Frank Wales [EMAIL PROTECTED]
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


RE: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Christopher Woods
> Virgin Media CEO Says Net Neutrality is "A Load of Bollocks"
> 
> 
> The new CEO of Virgin Media is putting his cards on the table 
> early, branding net neutrality "a load of bollocks" and 
> claiming he's already doing deals to deliver some people's 
> content faster than others. If you aren't prepared to cough 
> up the extra cash, he says he'll put you in the Internet "bus lane".


Aaand watch VM's customers rapidly jump ship and their profits sink
lower and lower. VM's new CEO hasn't a clue what he's on about (either that
or he's just putting on a bullish face for the investors). I would've left
already if I wasn't tied into a contract (going right back to LLU if things
stay the way they are)... Amazing how a company can mess things up so
completely within the space of a calendar year!

With their 24 hour STM on the way (not confirmed yet, but the 'deafening
silence' from all tech support and VM points of contact making the intention
quite clear) and various other factors (horrible overcrowding on core
network, widespread problems and issues running the gamut from billing to
poor installation) that company is realy suffering. It needs a tender loving
hand and a good injection of cash, and that's just not going to happen in
the next few years.

Still, the company's being led by the marketing department, most recently
commencing the rollout of speed upgrades of middle tier customers to more
than double their previous peak bandwidth (the 4 -> 10mbps uplift) while
doubling the top tier from 10mbps to 20mbps last July/August and
implementing aggressive 'traffic management' at the same time... That and
the Phorm issue has been the icing on the cake for some.

Oh, and they're going to announce that everyone's bills are rising by a
(seemingly) arbitrary amount from next month - but it's news to me as I
heard about it on the newsgroups and still haven't had my letter from VM
yet! Let's see if 30 days' notice is really 30 days ;)


Much has been said about their past year's decisions, and many concur that
they've not acted very sensibly. Maybe BT will buy them in five years when
they're on the verge of bankruptcy and use their existing network to roll
out fibre... And it would need is a little more fibre laid, all the
trunking's already there!

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Mr I Forrester


   This might have got missed by the list...



   Virgin Media CEO Says Net Neutrality is “A Load of Bollocks”


The new CEO of Virgin Media is putting his cards on the table early, 
branding net neutrality “a load of bollocks” and claiming he’s already 
doing deals to deliver some people’s content faster than others. If you 
aren’t prepared to cough up the extra cash, he says he’ll put you in the 
Internet “bus lane”.


http://torrentfreak.com/virgin-media-ceo-says-net-neutrality-is-a-load-of-bollocks-080413/ 


-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Peter Bowyer
On 14/04/2008, Steve Jolly <[EMAIL PROTECTED]> wrote:
> Andy wrote:
> > Brian Butterworth wrote:
> >
> > > 1. so the great evil here is probably the BT wholesale
> > > provision which seems to be behaving somewhat monopolisticly, which is a
> > > tendency that I know BT has.
> > >
> >
> > Abuse of dominant position is prohibited under Section 18 of the
> > Competition Act 1998[1]. If BT are "behaving somewhat monopolisticly"
> > shouldn't Ofcom do something about it?
> >
>
> I believe that the wholesale price of IPStream ADSL is regulated by Ofcom
> already.  Cutting it drastically would kick the legs out from under LLU.

As part of its undertakings to Ofcom which led to the split-off of
Openreach (and not the enforced sale of the access business or the
wholesale business), BT committed to fix IPStream wholesale pricing at
its then level until the LLU installed base had reached 1.5M lines.
This milestone was passed about a year ago[1], and the price of
IPStream is now unregulated.

Peter

[1] http://www.offta.org.uk/charts.htm
-- 
Peter Bowyer
Email: [EMAIL PROTECTED]
Follow me on Twitter: twitter.com/peeebeee
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Steve Jolly

Andy wrote:

Brian Butterworth wrote:

1. so the great evil here is probably the BT wholesale
provision which seems to be behaving somewhat monopolisticly, which is a
tendency that I know BT has.


Abuse of dominant position is prohibited under Section 18 of the
Competition Act 1998[1]. If BT are "behaving somewhat monopolisticly"
shouldn't Ofcom do something about it?


I believe that the wholesale price of IPStream ADSL is regulated by 
Ofcom already.  Cutting it drastically would kick the legs out from 
under LLU.


S

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Andy
Brian Butterworth wrote:
> 1. so the great evil here is probably the BT wholesale
> provision which seems to be behaving somewhat monopolisticly, which is a
> tendency that I know BT has.

Abuse of dominant position is prohibited under Section 18 of the
Competition Act 1998[1]. If BT are "behaving somewhat monopolisticly"
shouldn't Ofcom do something about it?

> 2. Use transparent or non-transparent PROXY SERVERS.

As stated earlier it is unsafe to cache protocols you can't understand.
Thus the BBC is blocking the ISPs from using this course of action.
The BBC however should immediately cease this practice and use a
protocol that ISPs can cache if they want. (HTTP has support for caching
built into it, how forward thinking of them).

> but my experience of them is that transparent proxies reduce overall
> performance because they need to get in the way of each and every HTTP
> transaction.

I wouldn't have thought that the small increase in latency would be
noticeable for a several hundred megabyte file.

> 3. Store and forward: Locate MIRROR SERVERS inside the ISP network. 
> This seems a much better idea.

It sounds a lot like some kind of Cache. And another question is *who*
is going to pay for the servers that speak RTMP? This sounds like some
kind of revenue driving scheme for the BBC's commercial friends.

> the ISP provide the BBC with rack
> space 'inside' their networks for mirror servers.

A generic cache would be much more scalable, if the servers only mirror
BBC data then this does nothing to solve problems with other sites.

How does one mirror this data? Will it be available via rsync? Will it
be mirrorable by *anyone* or does the BBC intend to pick and chose
commercial ISPs to provide better access to. Again very shaky ground.

> - change the main BBC iPlayer to redirect requests for the content to
> the Mirror Server located in the ISPs network.

Really unscalable, how is the BBC going to know which ISPs have mirrors
and which do not? This would require each ISP to notify the BBC. Just
seems wrong. Having every Content Provider have to speak to every ISP
seems to go against the core of the Internet.

If a pipe on the Internet is not running at 100% it is being underused!

Andy

[1]

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


Re: [backstage] iPlayer and the ISPs - a solution

2008-04-14 Thread Paul Doyle
BBC chief quits to launch online service
http://www.ft.com/cms/s/0/202eab38-09ae-11dd-81bf-779fd2ac.html

Ashley Highfield, the BBC's director of future media and technology,
is leaving the corporation to launch a joint online video platform for
the BBC, ITV   and Channel 4 which the broadcasters hope will be "a
Freeview for the internet".

"His appointment as chief executive of the on-demand service,
code-named Kangaroo..."




2008/4/14 Brian Butterworth <[EMAIL PROTECTED]>:
> I have to say that I am very impressed with Ashly Highfield at the moment.
> His defense of the public interest and also of BBC money is worthy of high
> praise.
>
> He is 100% correct when he says that the Internet Service Providers should
> provide an Internet service.  The whole way the Internet has developed (and
> I've been using ever since it could be reached in the UK) has required ISPs
> to buy bigger and bigger pipes, to support more and more users.  The
> economics (which I have gone into before) provides that the more you buy,
> the cheaper each bit becomes.
>
> The ISPs (just to recap) are complaining because they need more capacity
> because the BBC iPlayer is popular, and people are suddenly watching whole
> half-hour and hour-long programmes, streamed from the BBC's servers.
>
> I am of the mind that if you are a Internet host (like the BBC in this case)
> then you pay for your end of the connection to the cloud and the end-user
> pays for theirs via their ISP.
>
> So, Mr Highfield is correct to reject the idea that the BBC should pay for
> ISPs Internet pipes.
>
> However, I wrote a paper about this when I worked at BT Broadcast Services
> (about ten years ago, in fact) about dealing with this situation, and as I
> recall (I don't have it here with me on Crete) there are a few ways to deal
> with it:
>
> 1. ISPs by BIGGER PIPES and upgrade their network.  This is 100% the correct
> answer in the long run.  Moore's Law tends to work at a bit-delivery level,
> so the great evil here is probably the BT wholesale provision which seems to
> be behaving somewhat monopolisticly, which is a tendency that I know BT has.
>
> 2. Use transparent or non-transparent PROXY SERVERS.  This might work, but
> my experience of them is that transparent proxies reduce overall performance
> because they need to get in the way of each and every HTTP transaction.
> Non-transparent proxies are fine on corporate and educational networks
> because you deny access to people who do not use them, or you can do
> complicated configuration scripts.
>
> 3. Store and forward: Locate MIRROR SERVERS inside the ISP network.  This
> seems a much better idea.  Rather than the ISP being given BBC cash, which
> is an intolerable idea, the ISP provide the BBC with rack space 'inside'
> their networks for mirror servers.  These could work in one of two ways:
>
> - use DNS to redirect the requests for content (the massive files that are
> the video 'streams') to these servers.
>
> - change the main BBC iPlayer to redirect requests for the content to the
> Mirror Server located in the ISPs network.
>
> DNS is a tricy beast and almost impossible to manage in these situations,
> due to the way it is cached.  If people switch networks regularly, which
> they do, DNS trickery can turn into a nightmare.
>
> The second solution is clearly a better one.  The iPlayer already checks the
> end-users IP address to ensure that they are in the UK.
>
> It would be very simple to check to see if the users is in the range for a
> particular ISP and issue a HTTP redirect (or similar) to the ISPs server to
> get the content.
>
> The BBC would simply have to provide servers for each ISP which are fed with
> each of the iPlayer content files when they are produced, and manage the IP
> address lists for each server on a central BBC machine.
>
> This would mean transferring each file to the BBC machine inside the ISP
> network just once, and this would take seconds as it would be out there in
> the 'fat pipe' bit of the cloud.
>
> Finally, the client Flash Player software would need to know that if the
> content could not be obtained for some reason from the BBC machine inside
> the ISPs network, by calling back to the main BBC iPlayer server with an
> extra parameter.
>
> The BBC could argue that the ISP should provide these mirror servers, but as
> the hardware and storage costs of much machines is 'tiny' (and fixed) it
> would be better for these to remain under BBC control, from a management and
> responsibility point of view.
>
> Now, cut the crap and make it happen...
>
> Brian Butterworth
> http://www.ukfree.tv
>
>
>
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/


[backstage] iPlayer and the ISPs - a solution

2008-04-13 Thread Brian Butterworth
I have to say that I am very impressed with Ashly Highfield at the moment.
His defense of the public interest and also of BBC money is worthy of high
praise.

He is 100% correct when he says that the Internet Service Providers should
provide an Internet service.  The whole way the Internet has developed (and
I've been using ever since it could be reached in the UK) has required ISPs
to buy bigger and bigger pipes, to support more and more users.  The
economics (which I have gone into before) provides that the more you buy,
the cheaper each bit becomes.

The ISPs (just to recap) are complaining because they need more capacity
because the BBC iPlayer is popular, and people are suddenly watching whole
half-hour and hour-long programmes, streamed from the BBC's servers.

I am of the mind that if you are a Internet host (like the BBC in this case)
then you pay for your end of the connection to the cloud and the end-user
pays for theirs via their ISP.

So, Mr Highfield is correct to reject the idea that the BBC should pay for
ISPs Internet pipes.

However, I wrote a paper about this when I worked at BT Broadcast Services
(about ten years ago, in fact) about dealing with this situation, and as I
recall (I don't have it here with me on Crete) there are a few ways to deal
with it:

1. ISPs by BIGGER PIPES and upgrade their network.  This is 100% the correct
answer in the long run.  Moore's Law tends to work at a bit-delivery level,
so the great evil here is probably the BT wholesale provision which seems to
be behaving somewhat monopolisticly, which is a tendency that I know BT has.

2. Use transparent or non-transparent PROXY SERVERS.  This might work, but
my experience of them is that transparent proxies reduce overall performance
because they need to get in the way of each and every HTTP transaction.
Non-transparent proxies are fine on corporate and educational networks
because you deny access to people who do not use them, or you can do
complicated configuration scripts.

3. Store and forward: Locate MIRROR SERVERS inside the ISP network.  This
seems a much better idea.  Rather than the ISP being given BBC cash, which
is an intolerable idea, the ISP provide the BBC with rack space 'inside'
their networks for mirror servers.  These could work in one of two ways:

- use DNS to redirect the requests for content (the massive files that are
the video 'streams') to these servers.

- change the main BBC iPlayer to redirect requests for the content to the
Mirror Server located in the ISPs network.

DNS is a tricy beast and almost impossible to manage in these situations,
due to the way it is cached.  If people switch networks regularly, which
they do, DNS trickery can turn into a nightmare.

The second solution is clearly a better one.  The iPlayer already checks the
end-users IP address to ensure that they are in the UK.

It would be very simple to check to see if the users is in the range for a
particular ISP and issue a HTTP redirect (or similar) to the ISPs server to
get the content.

The BBC would simply have to provide servers for each ISP which are fed with
each of the iPlayer content files when they are produced, and manage the IP
address lists for each server on a central BBC machine.

This would mean transferring each file to the BBC machine inside the ISP
network just once, and this would take seconds as it would be out there in
the 'fat pipe' bit of the cloud.

Finally, the client Flash Player software would need to know that if the
content could not be obtained for some reason from the BBC machine inside
the ISPs network, by calling back to the main BBC iPlayer server with an
extra parameter.

The BBC could argue that the ISP should provide these mirror servers, but as
the hardware and storage costs of much machines is 'tiny' (and fixed) it
would be better for these to remain under BBC control, from a management and
responsibility point of view.

Now, cut the crap and make it happen...

Brian Butterworth
http://www.ukfree.tv