& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 4 / 10   >   >>
sgan201
sgan201
12/5/2012 | 3:35:23 PM
re: FCC's Martin Is Ready to Pounce
All,

It is not that complicated. Since you know a subscriber has fixed IP address for each session, you could have a fixed buffer size for each session. You could do this in the BRAS and / or CMTS.

It is the same concept as per connection in ATM but it is a session in IP based on IP address.

Dreamer
fgoldstein
fgoldstein
12/5/2012 | 3:35:23 PM
re: FCC's Martin Is Ready to Pounce
Dreamer is describing one possible implementation of one of ATM's QoS options. But ATM is not IP, full stop.

ATM was designed from the get-go to offer multiple QoS options, including CBR (lossless/jitterless circuit emulation), VBR (slight loss and jitter, two common variants, for semi-bursty traffic), UBR (sort of like IP, no rate) and ABR (low loss if you respond to network feedback and take just what's offered).

Yeah, I was there, pushing for a credit-based ABR scheme (QFC), based on something we actually bulit at DEC, though a rate-based scheme was standardized (if rarely implemented).

"Fairness" in TCP/IP is tricky. Since most applications (say, FTP) open one TCP data transfer flow, they will "fairly" share with one another, modulo the fact that closer connections (less latency) end up getting more. An application that parallelizes the flow and creates multiple TCP sessions will get multiples of the capacity. Is that fair? You be the judge.

ATM, of course, was built by the telecom industry, under its business model (pay for what you use). That lost to the free-lunch illusion of the Internet model. Now the diners are demanding permission to let their horses and tigers dine at the one-price-per-meal buffet.
paolo.franzoi
paolo.franzoi
12/5/2012 | 3:35:23 PM
re: FCC's Martin Is Ready to Pounce

dreamer,

I think your presumption is that all the subscribers in a P2P group are within the same carrier. This is not true and policing the traffic as it arrives from other carriers is a bit more complicated.

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

Given the TCP/IP stack, it would be done at the TCP layer, which corresponds most closely to the "connection". However, the number and nature of such connections from a given subscriber (roughly, IP address) should be monitored, not just the behavior of connections in isolation.

There is no layer above TCP where it could be done without DPI and application-layer relaying. And that's the real problem that neutrality folks should be worrying about, since that would stop new applications from being carried.

Larry, of course, is pushing connection-based (flow) routing. He's correct on technical terms. Connectionless is hopelessly inefficient. Connection-oriented networking got a bad name with X.25, which went overboard. Vast efforts are made nowadays to infer connections in the network where the routing layer (IP) architecture theoretically isn't supposed to know about them. But from firewalls to NATs to flow managers and beyond, nobody who actually works in the space (in contrast to the academics who preach about it, based on theoretical knowledge of how the ARPAnet supposedly worked in 1983 when the TCP/IP transition took place) takes the model seriously.

While the TCP/IP stack is broken and obsolete, a good way to think about things is to view the two protocols as one actual layer (and thus no boundary, no reason to not look at the TCP header). Yes, the relaying role (IP) is used in the intermediate systems and the control role (TCP) is sometimes only done at the edges, but they collectively create a Facility. Such a Facility can carry applications or, recursively (think VPNs or IPsec), carry another Facility as payload.
stephencooke
stephencooke
12/5/2012 | 3:35:22 PM
re: FCC's Martin Is Ready to Pounce
Fred,

"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."

This makes the most sense to me. Where would it make the most sense to implement it (i.e.: part of the TCP layer or higher, and how would the flows be managed)?

Incidentally, speaking of flow management, Larry Roberts (one of the Founders of the Internet) spoke at a seminar I attended on exactly this topic. According to him, network routers can only work at 30% capacity as currently implemented. Flow management is necessary to bring the numbers up to 90% or higher. He has a company that is doing flow-based routers.

Steve.
stephencooke
stephencooke
12/5/2012 | 3:35:21 PM
re: FCC's Martin Is Ready to Pounce
Fred,

"Given the TCP/IP stack, it would be done at the TCP layer, which corresponds most closely to the "connection". However, the number and nature of such connections from a given subscriber (roughly, IP address) should be monitored, not just the behavior of connections in isolation. "

So, basically the TCP-layer would need to be re-written to take into account the Telco's policies and set QoS on a session-by-session basis? Wouldn't this make the network DPI-free, provided that the network could carry the QoS-based traffic through the core and between carriers?

Steve.
paolo.franzoi
paolo.franzoi
12/5/2012 | 3:35:20 PM
re: FCC's Martin Is Ready to Pounce

Dreamer,

Where are you policing this traffic? At every router in the network? You want to stop it at the network edge to ensure that your network does not get congested. Since the sources of the traffic come from multiple ISPs which will be across multiple peering points, how will you know how much traffic is destined to one endpoint at any given time?

seven
sgan201
sgan201
12/5/2012 | 3:35:20 PM
re: FCC's Martin Is Ready to Pounce
All,

The problem with this scheme is

A) It works.

B) It is TOO SIMPLE.

Hence, nobody will design a box to do this. They cannot charge a lot for this. It can be copied easily. There is NO MONEY to make from this.

Dreamer
sgan201
sgan201
12/5/2012 | 3:35:20 PM
re: FCC's Martin Is Ready to Pounce
Stephencooke,

1) When there is congestion, you want to make sure that EVERYONE get the FAIR share of the bandwidth. In this case, the same size buffer make sure of that. Now, the abuser get MORE bandwidth during congestion. That is NOT fair.

2) The problem with Telco now is they cannot provide FAIR sharing of bandwidth. With this scheme, when network is NOT congested, everyone can burst to what they want. When network is congested, everyone get FAIR share. What is wrong with that??

3) It could be upstream or downstream or both. It is FAIR because the current scheme punished the normal and nice user while let the abuser get away with MORE BANDWIDTH during congestion. This scheme make sure everyone get FAIR share during congestion.

4) Due to small and fix buffer size, the abuser will get MORE PACKETS thrown away due to buffer over-run. Their good throughput (goodput) go way down. They have to play nice to get their traffic to and from Internet. They have to play nice (back down during congestion) in order to get better performance.

5) Only at key bottle neck. In most network, it will be the BRAS / CMTS.

It is SIMPLER. You do not have look into what traffic that a user is carrying. You just manage the flow at the subscriber level.

It is very simple. During network congestion, everyone get buffered. If you make sure that every subscriber has its own buffer and same size. The abuser will have more thrown away while normal user will have nothing thrown away.

Dreamer
sgan201
sgan201
12/5/2012 | 3:35:20 PM
re: FCC's Martin Is Ready to Pounce
Seven,

Why does it matters where the P2P traffic come from?? In most ISP, the bottleneck is the access network. For example, in DSL network, the connection to CO or the connection to DSLAM is the bottleneck. The traffic management is done at where the bottleneck is and where is needed.

Dreamer
<<   <   Page 4 / 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