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

Let's say I have a 32000 bytes buffer for each subscriber at the right spot. BT can create as many TCP connections that it wants but the summation of the TCP windows across ALL connections will be around 32000 bytes due to the buffer. For UDP, the user can stream as much as they want. But, as soon as traffic shaping during congestion kick in, it be dropped by buffer over at the 32000 bytes buffer.

Dreamer
fgoldstein
fgoldstein
12/5/2012 | 3:35:12 PM
re: FCC's Martin Is Ready to Pounce
OP, yes, I know there are all sorts of theoretical ways to aggregate things. Whether they are effective when one user or application process is actively trying to circumvent them is a different question.

ATM was designed to be faster than packet switching (IP) and I think it still could be, if anyone tried. With ATM it is of course possible to put an explicit price on everything; an SVC-based STN with per-SVC metering would be technically practical today. The downside is that consumers wouldn't buy it. That's the paradox. Consumers want the network to perform well, but don't want to think about the chance of a bill at the end of the month, and most seemed quite happy with Comcast's service (which is still signing up users in droves). They don't want to think about the consequences of applications that break the business and pricing model.

That's what we do.

BTW I'm not positing ATM as the solution, merely pointing out that it was designed 20 years ago to behave a certain set of ways. ATM was designed by a committee, and shows it. Networking technology is in a serious rut, stuck trying to coax more and more out of 30-year-old "good enough" IP.

And BTW I'm not a lawyer, though I play an engineer on TV. I do usually work with lawyers though; somebody on the team has to be the one to write the testimony as expert witness. ;-)
OldPOTS
OldPOTS
12/5/2012 | 3:35:12 PM
re: FCC's Martin Is Ready to Pounce
I can get the routers if you can get enough money.

Actually there are methods under MPLS to aggregate traffic types into different streams/labels to do traffic type throttling and this can be loosley sub-divided by source types. But it may be cheaper/faster to do DPI if you do this too much.

OP

PS Fred I didn't know legals knew so much about ATM and eye pee. I vote for more bananas.

Actually the processing per subscriber was a reason that ATM had BW limitations. But today fabrics with OC168s, especially POS, are possible and operate approaching those available in Ethernet/IP. The reason is that for high volumes of traffic the hardware is essentially the same to handle the speeds and to distribute the work.

- Note this Gig ideologs living at the edge that religiously believe in BW at all costs (and I once was told BW was free, even on this board).

That is why there are multi-protocol core switch and router platforms. The packets are processed and buffered in the line cards, including routing/switching tables, with central routing/switching management/administration done in the redundant management cards. Different protocols through SW.
People fail to understand the scale difference (and shifted line card costs) between an edge/typical enterprise router/switch and those required upstream at high volume and aggregation points and the core. Just do a trace on a few popular WEB sites to see the number of these networks and nodes you travel through. The difference between protocols in the high volume points is now more about how (little or much) flow queues are managed, TM schemes. Has BT finally learned this?

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

fg,

SSSSHHHHH....we can sell an entire new generation of core and metro routers with per subscriber queuing.

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

Who cares about routers?? In almost all those FIOS/ DSL/Cable / 3G/ 4G networks, there is a box that manage the user sessions. For example, in DSL, that is the BRAS. And, in most cases, they do have per user queues.

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

You don't seem to understand that there is more than one network here. The P2P requester is on the local network and there are many other P2P content providers on several other networks that connect, core-to-core, to the local network's core. The traffic from those other networks causes congestion in the local core, causing all local network access customers to have the buffers activated... as the local core is congested due to the traffic from the OTHER NETWORKS. The edge router or BRAS that feeds the P2P requester is the only place in the network where the traffic, coming from the OTHER NETWORKS gets dropped because of a user buffer overflow.

However, the traffic from those other networks has caused congestion in the local network's core because it has not gone through an edge router that is connected to a congested core. The OTHER NETWORKS are not congested, just the local core. As I hope you can now see, the buffers have simply punished all the local network's users because of traffic coming to a single user on that local network.

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

So, you get retransmission. But, the TCP window and congestion avoidance algorithm kicked in. So, the TCP window size is reduced and the TCP transmission slow down until no further drop. Then, it reaches steady state. How long does this takes?? A few seconds.

Dreamer
rjs
rjs
12/5/2012 | 3:35:09 PM
re: FCC's Martin Is Ready to Pounce
Seven, if the edge router is enabled to limit line throughput (duplex) at the CPE when the network is congested, the end user will automatically throttle down his P2P connection. If there is no congestion all this is moot and the CPE continues to use the line at the max capacity.

It is kind a like the old CPUs which did not have
enough computing power. If the user opened too many applications it slowed down to the point that the user killed a few processes to get the performance required.


When the aggregate line throughput at CPE (client) is monitored, packets are viewed equally ... this avoids DPI completely and results in self-policing.
In such a scenario, the user will get a feedback of slowing connection and will themselves kill the P2P processes. There is no need to go to the
Application/TCP/IP or any routing layer.

Yes, and Dreamer's way of buffer for individual CPE (client) is is one way of
monitoring the line.

Most ISPs do this BW limiting for upload routinely.

-RJS



" ....
So, let's go through a P2P example. You request a file and the P2P software hooks you up with 30 other customers. None of their networks are congested so they all stream data at your ISP. Whoops, now your ISP is congested and stays that way until you stop using your P2P service. Your local router keeps tail dropping your connection (okay it will use WRED as well). Guess what! That adds MORE congestion as the packets retransmit across the core and metro networks.

seven

"



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

dreamer,

You keep missing the point. Yes, there is a box. It controls the traffic to and from the user. It is in the end office in FiOS.

From that end office, you then traverse the core and metro networks to get to "the Internet" or better stated peering points with other networks.

Traffic destined for that customer will traverse the core and metro networks BEFORE you get to the end office router (which in the case of FiOS is an 1440 ERX moving to an E320). Thus, you have all that congestion in the core and metro networks that are impacting other customers BEFORE it hits that last end router. In fact, the last mile connection may NOT be congested if enough people are doing this in a network.

So, let's go through a P2P example. You request a file and the P2P software hooks you up with 30 other customers. None of their networks are congested so they all stream data at your ISP. Whoops, now your ISP is congested and stays that way until you stop using your P2P service. Your local router keeps tail dropping your connection (okay it will use WRED as well). Guess what! That adds MORE congestion as the packets retransmit across the core and metro networks.

seven
rjs
rjs
12/5/2012 | 3:35:07 PM
re: FCC's Martin Is Ready to Pounce
Stephencooke, I am just trying to understand the
problem. I still fail to see why the
simple line rate throughput control at the edge will not solve the problem.

So lets us consider your example:
Once the users throughput gets capped by the edge,
-- for example say at 1Mbps download, and 200kbps
upload, many of these P2P servers will be streaming to a client that will not be accepting the streams, they should automatically drop.
If the application intentionally does not terminate the session, this is the same as receiving junk mail, and junk mail is a problem only if it does not cost the sender anything.

However, bear in mind that in P2P one persons upload is the other guys download so my guess is that the P2P servers/users would have a vested interest to drop dead connections so that they do not overload their edge connection.
The system should achieve steady state after sometime. We may end up in having glitches and lost packets depending on the time constant of the network.

I am not against line metering as that still does not violate net neutrality and is fair to all in that sense.

-RJS

" ....
You don't seem to understand that there is more than one network here. The P2P requester is on the local network and there are many other P2P content providers on several other networks that connect, core-to-core, to the local network's core. The traffic from those other networks causes congestion in the local core, causing all local network access customers to have the buffers activated... as the local core is congested due to the traffic from the OTHER NETWORKS. The edge router or BRAS that feeds the P2P requester is the only place in the network where the traffic, coming from the OTHER NETWORKS gets dropped because of a user buffer overflow. "


<<   <   Page 7 / 10   >   >>


Featured Video
Upcoming Live Events
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