Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Four steps to manage the Internet bandwidth

neutrino38 (1037806) writes | more than 6 years ago

The Internet 2

I am not a proponent of maximal network neutrality that states that "every IP packet should be treated equally". This egalitarian approach works well when a network is quasi empty but fails when in come close to saturation. However, the need for uniform rules is obvious and I am sympathetic to arguments that would avoid that some content providers get more priority on the network than others just because they have . The calls for more investment in the Internet infrastructure are not g

I am not a proponent of maximal network neutrality that states that "every IP packet should be treated equally". This egalitarian approach works well when a network is quasi empty but fails when in come close to saturation. However, the need for uniform rules is obvious and I am sympathetic to arguments that would avoid that some content providers get more priority on the network than others just because they have . The calls for more investment in the Internet infrastructure are not going to be answered unless there are additional revenue streams. To me, managing the Internet bandwidth is about addressing the following issues:

  • how to avoid that 5% of Internet users uses 50 % of the bandwidth
  • how to prioritize legitimate content over peer to peer file exchange
  • how to decrease SPAM
  • how to address real time media transfer?

I recenty read some material about TCP algorithm evolution and noted an interesting proposal in the comments (see my next post). All this lead me to the following four steps to regulate internet bandwidth:

Step 1 - define three type of service uniformly across all DSL and Fiber connections on the user side

This is the most sensible proposal I have ever read and the Web. Let us imagine a typical European DSL with 8 Mbit/s download and 800 kbit/s upload. The idea is to provide worldwide support for type of service as defined RFC 1349.

Under this system, applications that would choose TOS 'maximize throuput' would have access to the full capacity of the DSL link (upload and download) but with lower priority. By default all FTP, SMTP wouls be assigned this TOS.

Application that would choose 'minimum delay (latency)' would have access to a fraction of the DSL badwidth e.g. 2 Mbit/s download, and 600 Kbit/s upload) but with higher priority. It is expected that common Web surfing would use this.

Application that would choose 'maximum reliability' would have access to a low symetric bandwidth such as 500 kbit/s but with garanteed troughput.

The same principle could be extended to Fiber and SDSL links. That would enable the ISPs to do bandwith provisionning.

The GIX nodes and peering interconnection would be critical in managing these TOS accross the Internet. It would the GIX responsibility to charge TOS traffic differently or in case of peering agresments, to weight IP traffic differently depending on the TOS. It is also possible to imagine bandwith limitation related to high priority TOS.

It is expected that on the user side, every application would ave the ability to choose its TOS although there would be defualt settings that would fit the average user's needs. This would dramatically alleviate the P2P bandwidth issue as such applications would probabily select the low priority / high bandwidth type of service to take advantage of the whole capacity offered. Normal traffic would then be processed with higher priority making the network to appear as more responsive. If a P2P application would chosse the high priority type of service, the bandwidth used would be limited.

Step 2 - separate e-mail traffic from the rest

The other source of bandwidth waste is spam. A lot of smart systems (SPF, cryptology, ...) have been designed to reject SPAM mainly when the messages reach the destination the mail. They do not prevent the SPAM to be transferred over the Network. I know that this proposal will hurt every person with a libetarian approach but what we need is to go back to an administred e-mail system.

Today every body can setup a mail server and hookup on the Internet and send e-mail by a few DNS lookup on MX records.

What we need is:

  • to enforce a mail server chain: private e-mail server --- ISP e-mail server ---- global exchange e-mail server.
  • to remove the access to SMTP protocol to Mail User Agent. SMTP would be solely used between PO and MTAs.
  • extend IMAP protocol to support e-mail sending by Mail User Agent and roaming (the ability to connect on a PO and have the connection relayed to the attachement post-office).
  • to have a simple (and free) administrative procedure to connect a private mail server to the ISP.

In that case, the ISP and the global exchange MTA would have simply the ability to pinpoint spam sources and to block them just by shutting down the transfer link between the incriminated e-mail server and the next MTA when they reach a certain quota.

Step 3 - manage media delivey differently

All the above does not address the need for some service providers that are offering VOD services. What we need is to have the ability to open IP virtual circuits from client to server and negociate the bandwith all the way long to be sure that the delivered media would be available with the requested quality.

For ToIP and media delivery, we need to go back to the congestion model proposed by the telephone network that reject new circuit overload without degrading the quality of established circuits.

Thess circuits would be high priority bandwith that would have a costs for the carrier. Content provider need to somehow share some of their revenue stream to ensure this kind of high quality transport and it is expected that the ISP would charge per minute and per kbit/s and share the revenue with the content provider.

Step 4 - multi-tiered Internet

All the above tend to outline the need to separate four types of traffic:

  • T1 - low priority reliable traffic for P2P and file transfert
  • T2 - store and forward traffic
  • T3 - high priority traffic for transactional application / signalling (banking, telephony control, supervisions, Web services)
  • T4 - media transport (RTP, streaming, YouTube) from content providers

Maybe the GIX for all this kind of traffic should be clearly separated with different accounting rules.

  • T1 would be accounted per volume,
  • T2 would accounted per message,
  • T3 would be accounted by the garanteed capacity offered,
  • T4 accounted by sessions (based on time and bandwidth requested).

This separation could be extended to some part of the core network of ISP.

Having said all that, I guess that I will be killed by Network neutrality proponents as this pave the way to differenciated charging of Internet services.

cancel ×

2 comments

Sorry! There are no comments related to the filter you selected.

An interesting take on things (1)

Evets (629327) | more than 6 years ago | (#23137458)

I think that the usefulness of e-mail has passed us up, and it really is us older network end users that keeps it active.

Rather than segmenting e-mail traffic, I think a better solution would be to push forward a more well thought out one. Whether it's social network messaging, or a more global solution that takes into account the problem that is Spam today, I think e-mail deserves a quick and painful death.

When you see that 93+% of e-mail transmitted is not going to be read, and is neither solicited, nor desired, I think it's time to come up with a new paradigm.

This in and of itself would cause a major decrease in network traffic.

I also think that the remaining bandwidth issues could really be addressed at the protocol level with little internet impact on end users in general. Your ideas are a good starting point, but if you start with the idea that you can get rid of network traffic that is not desired, the big picture changes dramatically.

Re:An interesting take on things (1)

neutrino38 (1037806) | more than 6 years ago | (#23149544)

About the e-mail usefulness, I tend to disagree. This is still the standard for interpersonal communication in a corporate environement. However, it is true that some kind of evolution is needed to make e-mail, SMS / MMS, forums and IM some kind of converged service with several options. I dream to have a modified Thunderbird client that would support SMS sending, IM client, interface naturally with web mail and allow me to browse through fora and comment on /.

I won't comment on the social networking as I am not knowledgeable at all on this.

The principle that changes should occur at the protocol level with a minimal impact on the user side is a good one. I read a book on UMTS network architecture and that was a good illustration of this principle. However such protocol change often induce unexpected usage change because of the new possibilities offered and eventuelly have an impact (positive or negative) on the user land.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>