10 Mbit/s problem in your network

fredrik danerklint fredan-nanog at fredan.se
Sun Feb 10 19:15:11 UTC 2013


> You seem to be mistaken that any bandwidth issue will be remedied by
> TLMC. A significant number (well over the 50% mark I'd wager) will not
> be remedied. This thread was started over such a subject.

And to save 1 - 5 Mbit/s of this bandwidth is wrong, how?


> The Apple TV cited as an example was an example.

If the TV Show/films/movies/etc.. is static content, then we
should be able to cache it, at the hotel's cache server.


> Travellers, be they
> corporate or leisure, have significant networking needs that the TLMC
> cannot address. Just think of "The Cloud" (yes, I'll go and flog
> myself for bringing it into a discussion on NANOG), where people are
> storing their (semi-) private documents or files - in the end it's
> similar to connecting back to the office to access the fileserver.

(We have 1 - 5 Mbit/s of more bandwidth for these services).

What you are talking about here is dynamic content, which should not
be cached at all and everyone knows this.


>> How about those who have limited bandwidth to the Internet? Like
>> ferries, trains, buses or satellite links...
>
> And pray tell me, why should they all have TLMC's ?

I'm not saying that they should have a cache server. I'm saying
that they could.

> Now if you're a content provider, then yes I can
> imagine why you'd like everybody else to pay for better ways to
> deliver your content without having to pay for it yourself.

It does matter how you are going to try to solve this, it is always
the customer who is going to pay in the end.

> Within this discussion we're talking about the actual last mile.

I call it "The Last Mile Cache", TLMC

> A proxy or cache won't be of any use if the users can't get to it with
> sufficient bandwidth to make it work anyway.

So, as long as a user does not have enough bandwidth, they should not
have a cache server on their side, correct?

-- 
//fredan

http://tlmc.fredan.se




More information about the NANOG mailing list