Luca Martini, Level 3

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 5 / 10 > >>

Tony Li 12/5/2012 | 12:01:38 AM

re: Luca Martini, Level 3
Skeptic,

Another frustration on the vendor side is the percentage of customers who have made a corporate decision to sell QoS services, but have not bothered to define a service model. The result is inevitably friction between the customer's engineering and marketing, with both sides happy to point fingers at the equipment vendor.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

raj_sarkar 12/5/2012 | 12:01:38 AM

re: Luca Martini, Level 3 The whole concept of connection-oriented networks was developed on the shoulder of end-to-end QOS delivery. Whereas connectionless networks were supposed to be best-effort.

What is the use of a connection-oriented path of packet delivery from endpoint A to endpoint B if there is no requirement for traffic engineering, bandwidth guarantees and meeting the requirements for latency, jitter, throughput etc?

Hence, stems the very important debate of QOS and its importance in connection oriented networks...

If i accept the fact that my core network will not be congested and will only occupy 70% of the link bandwidth [ LER takes care of traffic policing/shaping so that bursty behavior of the traffic is avoided], why do i need MPLS LSPs to deliver the packets? The optimists will say, I can aggregate ATM,FR,IP et al over the network ...
so what??

my point is there is no way we can deny the fact that QOS has a role to play for the proper deployment of MPLS ( and they are important). As well as, it is important in the discussion of CO and CLNS networks.

Though the pundits will argue that TE is not so important in the core - it will play a role in the long run where the SPs would love to give preferential treatment to some of the LSPs compared to others [ my business gold/silver/bronze customer - MPLS VPNs over the core ]. Especially, it would be interesting to see how MPLS will fare in the case of nodal or link failures in the network [ tho a lot of work is going on for graceful restarts and fast-reroutes] ....

Truthfully, maybe I am being naive - as Mark pointed out before - I don't see any difference between ATM and MPLS other than:

- The packet sizes differ
- multiple level of hierarchy
(vpi/vci == two levels of hierarchy)

[OK , OK!!! I agree to the fact that this entire LAN Emulation,MPOA and Classical IP over ATM is horse-shit -- but the ATM technology could have been better utilized for IP if appropriate standardization was undertaken..]

OR are we reinventing the wheel here?

- Raj

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 12:01:38 AM

re: Luca Martini, Level 3
Indy,

I think that you're pointing out some loose wording that I don't think is intentional. I think that most folks do realize that jitter and latency still matter on an OC-192. I think what they're really trying to say is that it is not difficult to meet those criteria at that speed because the transmission time of the packet already in flight is so short. No point in turning down the MTU here, because the size of the packet is not an issue.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 12:01:37 AM

re: Luca Martini, Level 3
So let me see if I can further enliven this discussion with a rationale for why QoS for MPLS and for IP is really unnecessary except for jitter-sensitive services.

Today, the SPs are in a position where they need to have market share and they must simultaneously make their operations more efficient so that they can achieve profitability. To have the economies of scale, these SPs need to have traffic volume and today that implies that they have to provide a best effort service. However, coupled with that, they must also provide a competitive best effort service. This implies that the best effort network must NOT congest in any significant way. Certainly customers who see significant packet loss for extended durations will simply find another SP.

If the network is sufficiently provisioned such that best effort is not congested, then what does QoS ever buy you? All of your packets will get through, it's only a matter of whether or not you want your packets to go to the head of the queue.

If you have a jitter sensitive application, then obviously this is of some value to you. However, for all other traffic classes, you end up paying for something for which you get no real value in return.

While PT Barnum might be content to take this money indefinitely, most consumers will eventually figure out that they are paying for no return and move elsewhere, so the SP is not likely to continue this behavior for too long.

Thus, there are effectively only three real classes of service that a SP needs to maintain:

- network control traffic (routing, link layer, management)
- jitter-sensitive traffic (VoIP)
- best effort

Based on this, I'd say that six levels of service is overkill. ;-)

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

CarrierClass 12/5/2012 | 12:01:37 AM

re: Luca Martini, Level 3 Tony,

The Ethernet customer demarcation point issue is not as trivial as you make out:

[TL: No arguments. If the SP wants to provide the switch, that fine by me. However, it is again not something special. As you note, it's a commodity off the shelf product. Functionally it's the same thing whether the SP pays for it and charges the customer or whether the customer pays directly for it and lets the SP ping it.]

To use a comparison, a SP (lets say call them SP1) that does not have reach in a particular area can lease an ATM/Frame Relay circuit from another provider (lets call them SP2). Now, SP1 may use this circuit as an access circuit to an RFC2547 VPN for a customer (say Customer1). In this case, SP1 is responsible for managing the L3 VPN, and SP2 is responsible for managing the ATM/frame Relay circuit. SP1 may or may not manage Customer1GÇÖs router, SP2 manages the L2 circuit up to the NTE/NTU. The point here is that SP2 does not need to have any contact with Customer1 (other than to get access to the building), SP2s customer is actually SP1.

Now, if the ATM/Frame Relay circuit is replaced with an Ethernet circuit, and there is no NTE/NTU like device then things become very complicated. SP2 must now be able to GÇÿpingGÇÖ the customers router, whereas before SP2 didnGÇÖt need to have any knowledge about the customers network at all. If SP1 is also responsible for managing Customer1GÇÖs router then that means Customer1, SP1, and SP2 all need to manage the same box.

The way round this is for SP2 to use some type of circuit termination device, (which could be an L2 switch) which SP2 is responsible for. SP2 would manage the circuit up to the circuit termination device, which would be the customer demarcation point. Customer1 can then plug their router (which may or may not be managed by SP1) into the termination device. There is a clear demarcation here between what SP1 Is responsible for and what SP2 is responsible for.

This multiple provider problem may also exist internally within large incumbent telco providers. It is likely that the group of people responsible for the maintenance of an L2 circuit is totally separate to the group of people responsible for managing the L3 VPN service. The GÇÿits not my problem, it must be yoursGÇÖ issues are hard enough to solve today even with proper customer demarcation.

For new providers the demarcation problem may not be a big issue. But a large incumbent cannot simply replace a ATM/Frame Relay circuit with an Ethernet GÇÿWireGÇÖ, and plug it directly into the CPE without having to tackle new management issues that didnGÇÖt exist before.

CC

Reply | Post Message | MESSAGES LIST | START A BOARD

Holy Grail 12/5/2012 | 12:01:36 AM

re: Luca Martini, Level 3 Tony,

OK for as long as the network remains uncongested, however you may have short periods of local congestion due to link/node outages, when this happens you may want to ensure that delay sensitive not perhaps quite so jitter sensitive stuff (streaming) gets priority over BE etc and if O/P queue is too long then discarded, also that perhaps some loss sensitive stuff (Business critical TCP) gets priority access to buffers and queues above BE but below voice and low loss data.

We are almost there, the core ideally needs 5 priorities, Control, Voice, Low delay, Low Loss, Best effort.

IP+MPLS+Diffserv is I think the packet networking Holy Grail, hence the name.

Good luck spreading the gospel, have fun.

Reply | Post Message | MESSAGES LIST | START A BOARD

indianajones 12/5/2012 | 12:01:36 AM

re: Luca Martini, Level 3 Tony,

I will have to disagree with you here.

Several of my friends log on using NetZero and other free Internet services. If the business model of an SP is based on providing these free-loaders with competitive best effort service, it is bound to fail. Proof positive why all pure IP providers have either gone bankrupt or floundering. If best-effort provides me a good service, there is no incentive for me to move higher up the service value chain. As an example, if BE is good enough, why should I pay for AFx assured service?

Such a business model is flawed by construction. Look at all these DSL providers coming up with 3 service levels based on the level of bandwidth as a way to charge more for people who use more.
If customers move SPs because their current SP's best effort service sucks, it won't be long before the SP who offers the better best effort at the same price point (assuming everything is the same) goes out of business.

Reply | Post Message | MESSAGES LIST | START A BOARD

vrparente 12/5/2012 | 12:01:35 AM

re: Luca Martini, Level 3 Tony, et. al.

I couldn't agree more. QoS is really un-necessary. All I can add is to say that the same thing in other ways.

QoS amounts to paying extra (for gear, services, etc.) for what the network should always do -- reliabily deliver all packets.

However, multiple classes of service for "desktop" applications and even server to server communications is so overly complex as to negate the potential benefits through the lost productivity and expensive of designing, implementing, and operating QoS.

I think the greatest benefit from QoS has actually been accidental. As a result of all of the work put into QoS hardware and software, in the late 90's the industry found itself with this processing and classification hardware on routing and switching platforms. It wasn't being used (for QoS). Instead we found a use for that hardware in other layer4-7 applications. As a result the hardware and system archiectures designed to support QoS paved the way for advanced layer4-7 applications which have been very widely adopted and have really contributed to the operation of reliabile and secure services in web, streaming, file distribution, etc.

You've heard it from a very experienced builder of routers (Tony) and now you've heard it from an experienced network operator.

-Victor Parente-Blake

Reply | Post Message | MESSAGES LIST | START A BOARD

Mark Seery 12/5/2012 | 12:01:35 AM

re: Luca Martini, Level 3 Hi Raj,

>> The whole concept of connection-oriented networks was developed on the shoulder of end-to-end QOS delivery. Whereas connectionless networks were supposed to be best-effort. <<

Well actually I would disagree with this. The true datagram recursors to the Internet (note here that while some consider the Internet a datagram service I do not - but that is another thread) were designed for guaranteed delivery; a slightly different concept perhaps, but important none the less.

>> What is the use of a connection-oriented path of packet delivery from endpoint A to endpoint B if there is no requirement for traffic engineering, bandwidth guarantees and meeting the requirements for latency, jitter, throughput etc? <<

Well there is a completely different angle of attack on these terms that we haven't discussed yet which answers this question in part.

Firstly, we have not discussed in this thread so far the basic tradeoff between CNLS and CO, and that is the idea of place information within very frame (CNLS) vs associating state with a connection. This is a paradigm/philosophy issue which has implications beyond just the issues you raise.

There are also the issues of billing etc.

>> If i accept the fact that my core network will not be congested and will only occupy 70% of the link bandwidth [ LER takes care of traffic policing/shaping so that bursty behavior of the traffic is avoided], why do i need MPLS LSPs to deliver the packets? <<

A lot of MPLS-TE is actually traffic steering rather than traffic engineering, i.e. creating a logical topolgy to avoid having a symmetrical mesh. This saves real money when it comes to facility costs.

>> Though the pundits will argue that TE is not so important in the core...... <<<

To be honest, the real thing that has gone astray over the last couple of years is the intense competition between CNLS and CO development. What I mean by this is that I actually think genetic diversity is good. So having the IP ecosystem focus on CO networking has sapped the industry of intense development on CNLS networking. That is a loss at some level.

>> Truthfully, maybe I am being naive - as Mark pointed out before - I don't see any difference between ATM and MPLS other than:

- The packet sizes differ
- multiple level of hierarchy
(vpi/vci == two levels of hierarchy) <<

Those are the main differences you seem to see. The other aspect, which I am too tired to really explain properly is this whole idea of a common control plane for two different layers of the network, i.e. solving the router adjaceny issue.

>> [OK , OK!!! I agree to the fact that this entire LAN Emulation,MPOA and Classical IP over ATM is horse-shit -- but the ATM technology could have been better utilized for IP if appropriate standardization was undertaken..] <<

No question. But ATM tried to compete with IP, so it set up friction - it should have tried to compete with SONET ;-)

>> OR are we reinventing the wheel here? <<

No question we are. Did you notice that crankback was just submitted for GMPLS ;-)

Mark

Reply | Post Message | MESSAGES LIST | START A BOARD

Mark Seery 12/5/2012 | 12:01:34 AM

re: Luca Martini, Level 3 Tony wrote:

>> Skeptic,

Another frustration on the vendor side is the percentage of customers who have made a corporate decision to sell QoS services, but have not bothered to define a service model. The result is inevitably friction between the customer's engineering and marketing, with both sides happy to point fingers at the equipment vendor.

Tony <<

ack. one of the hall marks of the boom was the complete disconnect between the engineering, marketing, and sales departments at SPs (of large ISPs especially). No business can run this way forever.

Mark

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 5 / 10 > >>