& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 3 / 10   >   >>
rjs
rjs
12/5/2012 | 3:35:30 PM
re: FCC's Martin Is Ready to Pounce
As FG has mentioned earlier why not enforce CI-2? It seems to be a very simple and obvious solution.

It is common sense to want no conflicts of interest between the content provider and the bit carrier. The bit carriers and the services should be separate entities. This will naturally result in net neutrality and it will be self policing or else the competition will police it.

This structural separation has been the norm in most public infrastructures (a good example is the
interstate highway system and the electric power system).

This structural separation is vital for the growth of the network since now one entity is not required to supply all the resources required in various stratas of the business. It also levels the playing field so that the large corporations do not have an unfair advantage to the consumer due to sheer size.


-RJS



ThurstonHowell3rd
ThurstonHowell3rd
12/5/2012 | 3:35:29 PM
re: FCC's Martin Is Ready to Pounce
GREAT POST!!
stephencooke
stephencooke
12/5/2012 | 3:35:27 PM
re: FCC's Martin Is Ready to Pounce
OK, so I am slow... I just figured it out:

P2P is designed to fill whatever bandwidth is available in whatever pipe it has access to. This implies that throwing bandwidth at the issue CANNOT solve the network issues it causes. This is like trying to put out a fire with gasoline. The ONLY solution to IP-based networks with P2P is QoS based on relative traffic priorities where P2P traffic is the lowest priority.

Steve.
fgoldstein
fgoldstein
12/5/2012 | 3:35:26 PM
re: FCC's Martin Is Ready to Pounce
Stephen,

You're very close.

> P2P is designed to fill whatever bandwidth is available in whatever pipe it has access to. This implies that throwing bandwidth at the issue CANNOT solve the network issues it causes. This is like trying to put out a fire with gasoline.

Correct. Contrary to popular belief, you CANNOT solve congestion by throwing bandwidth at it. This was even mathematically demonstrated by Raj Jain. BitTorrent was designed to make it easy to demonstrate in practice. ;-)

>The ONLY solution to IP-based networks with P2P is QoS based on relative traffic priorities where P2P traffic is the lowest priority.

Well, no. That's one obvious solution, one that works, and one that Comcast essentially tried. But it ran afoul of the orthodox neuts, even as smirking ATT worked on their walled garden IMS replacement for the Internet.

Other possible answers:

1) Charge for usage. Charge extra for upstream, since it's costlier, at least on cable. That puts the onus where it belongs, on the users who volunteer their ISPs' services. You get some in the monthly package but there's an explicit overage charge. Many non-US ISPs do this.

2) Cap usage. Again, if the user goes above what they pay for, their rate is slashed. This is now being done on some UK ISPs.

3) Define appropriate behavior below the application layer. For instance limit the number of simultaneous TCP or UDP sessions, drastically capping the speed if one goes above that. Or use more detailed policies that work with, say, web pages that fetch a bunch of ads (small TCP sessions) but not Torrents that run many 1MB transfers in parallel and sequentially.

4) Some combination of the above.

There is never a need to do Deep Packet Inspection (that is, above the TCP/UDP layer). Application bits should be sacred, but the nature of the TCP flows can be monitored.

FWIW while some fanatics insist that TCP is "end to end" and should be sacred, TCP and IP were originally one layer, one protocol. They should still be viewed that way, as one "facility", in which one role usually only needs to be run at the ends and the other role is needed in the middle. This model allows TCP/UDP transport-layer flow management to be seen as a network function, without breaking application neutrality.
sgan201
sgan201
12/5/2012 | 3:35:25 PM
re: FCC's Martin Is Ready to Pounce
All,

Conceptually, this is very simple to implement. And, it has been done on ATM network. Essentially, you do per user buffering and has the same fixed buffer size for all users. When network is not congested, nobody is being buffered, everything works normally. When network is congested, everyone get buffered the same amount. The heavy user has more packets and get more thrown away since he has more to send. Hence, he experienced more delay than others. And, if he slows down, he will reduce his delay. So, there is incentive for him to manage his traffic to throttle down during congestion.

This does not require looking into the packet layers. And, it is FAIR to everyone during congestion. Everyone get approximately the same amount to send during congestion.

Dreamer
stephencooke
stephencooke
12/5/2012 | 3:35:25 PM
re: FCC's Martin Is Ready to Pounce
Hi Fred,

I don't think DPI is the way to go in the long run. I would prefer QoS-aware applications. This would require tunneling from layer 7 to layer 1/2 in the stack but would theoretically make the network DPI-free. There would be policies implemented at the home gateway that would be based on the user's SLA and credit rating (Telcos would be happy if the user went over their allotment as long as they could pay for it).

I have some questions about the alternatives that you listed:

1) Charge for usage: This would definitely help but there is still no application differentiation in the network. Paid-for Bit Torrent is still as important as paid-for E911. Congestion will happen and bits will be dumped. I guess it would be interesting to see how, and where in the network, "usage" is defined. In a congested situation and a packet doesn't get through is it still charged for?

2) Cap usage: this is simply a "policing"-type approach that provides no additional revenue for Telcos/Cablecos. Is there a value-add here? Telcos may want customers to exceed their usage as long as they can pay for the overage. Again, there is no application differentiation.

3) Limiting simultaneous sessions: how are the limits set and are there reasonable ways in which these limits can be exceeded? Application differentiation?

4) Some combination of the above: sounds pretty complex and would likely differ from Telco to Telco. Makes it hard for network equipment and software suppliers to provide a product that fits more than one Telco.

Thanks,

Steve.
rjs
rjs
12/5/2012 | 3:35:24 PM
re: FCC's Martin Is Ready to Pounce
Are there any road blocks to implementing DREAMER101's suggestion for TCP/IP switches?

This seems like a straight forward approach which is
self-policing.


-RJS
rjs
rjs
12/5/2012 | 3:35:24 PM
re: FCC's Martin Is Ready to Pounce
Are there any road blocks to implementing DREAMER101's suggestion for TCP/IP switches?

This seems like a straight forward approach which is
self-policing.


-RJS
fgoldstein
fgoldstein
12/5/2012 | 3:35:24 PM
re: FCC's Martin Is Ready to Pounce
I agree with what you're saying. Maybe my position needs some "clarification".

> This would definitely help but there is still no application differentiation in the network. Paid-for Bit Torrent is still as important as paid-for E911. Congestion will happen and bits will be dumped.

Okay, the idea is that if you charge for usage, people won't waste as much; that which costs a tiny bit is still infinite times more costly than that which costs zero. But I do agree with prioritization. IP is not good at it but does have one priority bit. I have no objection to signaling for a priority stream in TCP. And that could and probably should be chargeable, either towards the price or against a cap. That is, priority bits count more than non-priority bits.

The key is to NOT do this via DPI, not infer priority from content the way IMS does.

There is no way in IP to know what bits got through. And it should not be a billing item. The network should contract to try to deliver a certain high percentage of high-priority bits, reject requests for more than it can handle (if possible), and carry whatever of the worst-effort ("best effort" in IETF fundamentalist lingo) it has room left for.

The Internet business model (usage is free and has no distance component) is predicated on best-effort delivery. Add QoS and it's looking more like telecom. Which is not a bad thing, just a different thing, a premium-priced thing. But much preferred for E911 and for that matter telephony in general.

Re: the cap, the value add is that users will not want to be capped, and if they find it happening, they'll buy a higher cap. It only works if there are multiple price tiers.

Session limitation requires TCP monitoring and I don't really know how practical it is, but compared to DPI it has to be cheap. I'm sure DPI hardware could be repurposed.

What we need is a flexible Policy and Traffic Manager that sits just below the application (isn't DPI) but does monitor flows and apply policies per the operator's instructions.
stephencooke
stephencooke
12/5/2012 | 3:35:23 PM
re: FCC's Martin Is Ready to Pounce
Hi Dreamer,

A few questions:
1) It appears that you penalize everyone for congestion. P2P will generally cause congestion, therefore you will penalize all other applications as well. This is fair...?

2) It seems like you would be requiring Telcos to do something without a visible ROI while apparently offering worse service than customers are already getting...?

3) Where is the buffering being done (i.e.: upstream or downstream or both directions)? Again, how is this fair?

4) Couldn't heavy users remain heavy users and overflow the network for greater periods of time?

5) how is buffer management done at each node?

I guess I can't see this working very well. Maybe I just don't understand it well enough. I have a feeling that this is a VERY complicated issue no matter how you slice it.

Steve.
<<   <   Page 3 / 10   >   >>


Featured Video
Upcoming Live Events
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events