I've been talking to the WCom MAE folk, and the explained to me that the the VC's between beers are built as ABR, with PCR being twice SCR. Also, the port you lease from them has a non-oversubscription policy, i.e., the sum of all SCR's combined cannot be more than port speed.
From what I can tell, PBNap and Ameritech both build the VC's as UBR, with no over-allocation protection.
In my travels of contacting other providers for peer information, I have run across about 5 (albeit out of about 60 who responded) that said they couldn't turn up new VC's across MAE-East ATM, because they have reached thier subscription allocation, even though thier port is not nearly full. A few had even expressed they wish that it was the ameritech-like UBR model. One person who I spoke to at WCom had said that maybe someday they would allow UBR PVCs, but there was no timeline. What are other people's thoughts on this?
When I left wcom, there was a project starting to implement an option to provision UBR PVCs. It required non-trivial changes to Peermaker, so would take some time. I'll let the current MAE crew answer as to current state, availability, etc. Steve On Mon, Apr 17, 2000 at 10:37:17PM -0400, Alex Rubenstein wrote:
I've been talking to the WCom MAE folk, and the explained to me that the the VC's between beers are built as ABR, with PCR being twice SCR. Also, the port you lease from them has a non-oversubscription policy, i.e., the sum of all SCR's combined cannot be more than port speed.
From what I can tell, PBNap and Ameritech both build the VC's as UBR, with no over-allocation protection.
In my travels of contacting other providers for peer information, I have run across about 5 (albeit out of about 60 who responded) that said they couldn't turn up new VC's across MAE-East ATM, because they have reached thier subscription allocation, even though thier port is not nearly full. A few had even expressed they wish that it was the ameritech-like UBR model.
One person who I spoke to at WCom had said that maybe someday they would allow UBR PVCs, but there was no timeline.
What are other people's thoughts on this?
Thanks for your update Steve and to Alex for getting the ball rolling. ONYX would also like to see this change implemented. The model the AADS team uses is far superior to any other scheme to 'monitor' interactions between peers at the PVC level. Hands-off full mesh build is the easiest to activate rapidly without botched PVCs trickling in one-by-one or stuck in a random queue of a departed employee... The PeerMaker method is too human intensive for little to no gain from an operational sense. A negative if you can't use the capacity for fear of artificial caps being exceeded with other peers, which is the case noted below. Also, I've never understood why PBNAP PVC build requests between two customers - approved by both customers - have to be sent to PacBell Marketing for approval... Alex, let me know if I can help your efforts in any way. Thanks again, -Ren At 10:15 PM 4/17/00 -0700, Steve Feldman wrote:
When I left wcom, there was a project starting to implement an option to provision UBR PVCs. It required non-trivial changes to Peermaker, so would take some time.
I'll let the current MAE crew answer as to current state, availability, etc. Steve
On Mon, Apr 17, 2000 at 10:37:17PM -0400, Alex Rubenstein wrote:
I've been talking to the WCom MAE folk, and the explained to me that the the VC's between beers are built as ABR, with PCR being twice SCR. Also, the port you lease from them has a non-oversubscription policy, i.e., the sum of all SCR's combined cannot be more than port speed.
From what I can tell, PBNap and Ameritech both build the VC's as UBR, with no over-allocation protection.
In my travels of contacting other providers for peer information, I have run across about 5 (albeit out of about 60 who responded) that said they couldn't turn up new VC's across MAE-East ATM, because they have reached thier subscription allocation, even though thier port is not nearly full. A few had even expressed they wish that it was the ameritech-like UBR model.
One person who I spoke to at WCom had said that maybe someday they would allow UBR PVCs, but there was no timeline.
What are other people's thoughts on this?
-Ren Lauren F. Nowlin, ren@onyx.net Director, Peering - peering@onyx.net ONYX Networks - http://www.onyx.net/peering/ Office: 650-558-3262, Fax: 650-558-3160, Cell: 650-281-6963
Yes. To me, it seems that WCom is policing the amount of traffic one can shove into a ATM port, so the giga-fiasco doesn't occur again, which I guess is somewhat of a legitmate cause. However, the difference between the giga and the atm solution is (obviously) there is no such thing as 'head-of-line' blocking on the ATM. Moving to the UBR will allow you to more smartly fill your pipe, and not have arbitrary restrictions on the flows you send in; essentially, the bottle neck with the PCR = 2 * SCR is the PVC, not the port. Considering the nature of internet traffic, this seems silly. However, the ability to build multiple PVC's in parallel from/to the same ports is important to us, and BeerMaker allows us to do this; we'd like to not lose this functionality. On Tue, 18 Apr 2000, Lauren F. Nowlin wrote:
Thanks for your update Steve and to Alex for getting the ball rolling.
ONYX would also like to see this change implemented.
The model the AADS team uses is far superior to any other scheme to 'monitor' interactions between peers at the PVC level. Hands-off full mesh build is the easiest to activate rapidly without botched PVCs trickling in one-by-one or stuck in a random queue of a departed employee... The PeerMaker method is too human intensive for little to no gain from an operational sense. A negative if you can't use the capacity for fear of artificial caps being exceeded with other peers, which is the case noted below.
Also, I've never understood why PBNAP PVC build requests between two customers - approved by both customers - have to be sent to PacBell Marketing for approval...
Alex, let me know if I can help your efforts in any way.
Thanks again, -Ren
At 10:15 PM 4/17/00 -0700, Steve Feldman wrote:
When I left wcom, there was a project starting to implement an option to provision UBR PVCs. It required non-trivial changes to Peermaker, so would take some time.
I'll let the current MAE crew answer as to current state, availability, etc. Steve
On Mon, Apr 17, 2000 at 10:37:17PM -0400, Alex Rubenstein wrote:
I've been talking to the WCom MAE folk, and the explained to me that the the VC's between beers are built as ABR, with PCR being twice SCR. Also, the port you lease from them has a non-oversubscription policy, i.e., the sum of all SCR's combined cannot be more than port speed.
From what I can tell, PBNap and Ameritech both build the VC's as UBR, with no over-allocation protection.
In my travels of contacting other providers for peer information, I have run across about 5 (albeit out of about 60 who responded) that said they couldn't turn up new VC's across MAE-East ATM, because they have reached thier subscription allocation, even though thier port is not nearly full. A few had even expressed they wish that it was the ameritech-like UBR model.
One person who I spoke to at WCom had said that maybe someday they would allow UBR PVCs, but there was no timeline.
What are other people's thoughts on this?
-Ren
Lauren F. Nowlin, ren@onyx.net Director, Peering - peering@onyx.net ONYX Networks - http://www.onyx.net/peering/ Office: 650-558-3262, Fax: 650-558-3160, Cell: 650-281-6963
Read on, Oh wise one. "Lauren F. Nowlin" wrote:
Thanks for your update Steve and to Alex for getting the ball rolling.
ONYX would also like to see this change implemented.
The model the AADS team uses is far superior to any other scheme to 'monitor' interactions between peers at the PVC level. Hands-off full mesh build is the easiest to activate rapidly without botched PVCs trickling in one-by-one or stuck in a random queue of a departed employee..
In a large corporation, individualistic details can get lost in the broad scope of things. Rate Cap'ing is wonderful thing, IMHO, as long as you have -adequate- resources to respond to the individual granularity of the dynamics of the -real- flows. Ahhh... Therein lies the caveat, eh ? :\ The best laid plans of mice and men......
The PeerMaker method is too human intensive for little to no gain from an operational sense. A negative if you can't use the capacity for fear of artificial caps being exceeded with other peers, which is the case noted below.
Great minds..... :)
Also, I've never understood why PBNAP PVC build requests between two customers - approved by both customers - have to be sent to PacBell Marketing for approval...
Didn't they, in the old days, need to clear "tarriffing rules" out there ? Dereg was young....and some states had differing (read complex) regs. I know we had a - mess - with it.... Just my .02 Richard
Alex, your description of how the MAE ATM NAPs work is not quite in line with either my understanding or the ATMF traffic management specs. As you state, the connections to the NAPS is ABR, but you then say "with PCR being twice SCR". If the connection is ABR (and it is), there is not PCR or SCR. There is only MCR (minimum cell rate). This really means that you are guaranteed that the bandwidth reserved by the MCR will be available to you. Any traffic beyond this is treated on a best-effort basis, exactly as if it was UBR. The only limit on what you may inject (above MCR) is the line rate and there is no guarantee that any of this traffic will make it through the fabric. The best way to think of MCR is that it is much like CIR on a frame relay circuit and that an MCR of zero, like a CIR of zero, can be a practical and functional connection. At least a functional as a UBR PVC. Since the MCR is committed bandwidth, it really can't properly support over-booking. The sum of all of the MCRs for all of the PVCs connected to the line should not exceed the capacity of the line, 96000 CPS for DS-3 (PLCP), 353207 CPS for OC-3, or 1412830 CPS for OC-12. But, beyond these limits, any further traffic injected on any PVC will be forwarded on a best-effort basis exactly as it would if the switch was running UBR. A big problem is that many of the folks at the MAEs don't seem to realize this and set the MCRs to excessively large values. How high they should be set depends on how critical it is that a given connection run without drops under peak loads. For most of our peerings (not those with the major NSPs where we have multi-megabits flowing most of the time) we set the MCR on our PVCs to a rather small value. I typically use 2600 CPS or about 1 Mbps and these circuits typically run very clean. Don't wish for the Ameritech UBR model (though I am very happy with the AADS NAP). Educate people that they should not over-provision their PVCs. If the port is running idle, they are are simply wasting valuable (and expensive) capacity. And, if your router does not support the specification of ABR PVCs with an MCR, keep this in mind when specifying PCR and SCR, since these values are not really meaningful in an ABR world. I typically set PCR to line rate and SCR to MCR with a 100 cell MBS, but YMMV and I have not done enough testing to have confidence that they are near optimal, only that they work pretty well. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
On Tue, 18 Apr 2000, Kevin Oberman wrote:
Alex,
your description of how the MAE ATM NAPs work is not quite in line with either my understanding or the ATMF traffic management specs.
I'm not surprised, as I may not know what I am talking about :)
As you state, the connections to the NAPS is ABR, but you then say "with PCR being twice SCR". If the connection is ABR (and it is), there is not PCR or SCR. There is only MCR (minimum cell rate). This really means that you are guaranteed that the bandwidth reserved by the MCR will be available to you. Any traffic beyond this is treated on a best-effort basis, exactly as if it was UBR. The only limit on what you may inject (above MCR) is the line rate and there is no guarantee that any of this traffic will make it through the fabric.
I thought it was strange also, however my information comes from Wcom: <snip>
3) is it still VBR, or UBR/ABR now?
It's actually implemented as ABR, with the peak cell rate enforced and set to twice the reserved rate. </snip>
Ah! This is a bit different from what was previously said, but not that different. Mostly replace SCR with MCR. You can specify an absolute PCR for an ABR PVC (total traffic, both tagged and untagged (clp0+1)). This is typically done to prevent a faster input circuit from overwhelming a slower output circuit, e.g a PVC from an OC-12 source to a DS-3 destination, but I can't imagine why simply someone would specify PCR as twice MCR as opposed to capping it at the speed of the destination circuit or some other hardware enforced limit. Steve, any chance you could shed some light on this?
<snip>
3) is it still VBR, or UBR/ABR now?
It's actually implemented as ABR, with the peak cell rate enforced and set to twice the reserved rate.
</snip>
Alex, where did this come from? I've never seen this and would love to have a reference. There is no documentation on http://www.mae.net/atm/ as far as I can see and I didn't see this in the Peermaker manual (although I could have missed it). R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
participants (5)
-
Alex Rubenstein -
Kevin Oberman -
Lauren F. Nowlin -
Richard Irving -
Steve Feldman