• No results found

Signaling Granularity and End-to-End QoS

3.1.1 Trade-off

When the customer wishes end-to-end service guarantees for traffic that crosses several networks then DiffServ becomes a multi-provider service. This is for example the case when the customer wishes guarantees about e.g. latency and throughput that hold for his/her premium traffic independent of the traffic source or destination. Obviously, all network providers on the traffic path must reserve sufficient resources for such a service guarantee. As said before, the broker ar- chitecture proposes a chain of service level agreements that reflect the aggregated resource requirements on a per-peer basis. The service level agreements are set up in advance and can be updated by means of ESB communication (see section 2.3.3). Figure3.1 shows an example of a working DiffServ scenario. Here, two

host networks (H1 and H2) have each established an SLA with an ISP A for 500 Kbit per second guarantee for DiffServ traffic. They inject that amount of DiffServ traffic plus a large amount of best-effort traffic through fast access links. ISP A for- wards all traffic to ISP B. The brokers of the two ISPs have already established a sufficient SLA (1Mbps) between them, thus the DiffServ traffic can continue on its path to the destinations. The link between ISP A and B is only of limited size, thus it can be congested. However, this congestion only affects the best-effort traffic.

500 Kbps 500 Kbps ISP A ... SLA SLA SLA BB Bandwidth Broker (BB) Host network H1 Host network H2

ISP B

Congestion !

Dropped best effort traffic.

Best effort traffic

1Mbps

Figure 3.1: The ideal DiffServ scenario.

Unfortunately, the DiffServ architecture does not describe how the SLAs are established in the first place. The only thing said is that the brokers communicate with each other. The problem addressed in this chapter is how frequent such com- munication takes place and how the service guarantees and the scalability are af- fected. In one extreme case each customer application signals its QoS requirements to the bandwidth brokers of the access ISP. The brokers forward these requirements from one to another in order to assure end-to-end QoS. The advantage of this ap- proach is that the application which knows them best) signals the requirements. Furthermore, the application may block the traffic and wait for an acknowledgment by the brokers. The brokers can thus perform a fine-grained admission control. The brokers have total knowledge about all traffic flows that they have to accommodate. However, this centralization of information is also a huge problem since a broker of a backbone network would have to keep track of millions of traffic flows. The Inte- grated Services architecture pursued this fine-grained QoS approach. Yet, it could not be deployed successfully in the global Internet because of this huge complexity it introduces to the Internet backbone management. It simply did not scale. The DiffServ architecture has been designed with scalability in mind. The DiffServ broker signaling must therefore be more coarse grained than the presented extreme approach. However, if the brokers do not have the fine-grained view of the network traffic demand then admission control is less efficient and end-to-end service de- livery may be affected. This chapter is going to discuss alternative coarse-grained

signaling schemes. It studies the trade-off between end-to-end service guarantees and scalability given a signaling granularity level.

3.1.2 Signaling and SLA Update Options

All of the options that follow are more coarse grained than the like IntServ ap- proach. The traffic is not treated on a per-micro-flow1 basis as in IntServ. All proposed signaling options deal with traffic aggregates. The fate of the IntServ architecture showed that this is necessary. So it is not the customer application that signals a micro-flow. Instead, customers negotiate SLAs with the brokers of their ISPs. These customer-provider SLAs may have various granularity levels, but they too should not deal with single flows but with traffic aggregates. They may for ex- ample deal with traffic between two IP addresses or even two autonomous systems numbers. The broker can react to customer SLA requests by updating its SLAs with peer providers and/or by signaling the event to them. Note, that the customer SLA request is thus used as an implicit signal. The SLA updates between providers can also be used as an implicit signal, but the following results show that this is not to be recommended (see section 3.4.1). Here are the three basic options for the reaction of brokers that are studied in the rest of this chapter: adaptive reservation, limited signaling and end-to-end signaling. The first two options were presented in [GB99] and the third option was discussed in [DGBS00].

Adaptive Reservation. The broker does not react to SLA changes. Instead, it

constantly measures its SLA conformance. Once it sees that in fact it sends more DiffServ traffic to the upstream provider than agreed in the SLA then it updates the SLA. This option does not use any signaling at all.

Limited signaling. The broker forwards signals only in certain cases. The bro-

ker thus needs a heuristic to decide which requests have a heavier impact and thus need to be forwarded to other brokers. For example, large Diff- Serv requirements can be signaled and an admission control can take place. However, during normal operation no signals need to be exchanged.

End-to-end signaling. For each signaled event the broker checks if it must adapt

its SLAs. It always forwards the signal. Each signaled aggregated flow is subject to admission control.

In the following sections (3.3,3.4, and3.5) refine these three options, describe the advantages and problems of them in terms of scalability, uncertainty of ser- vice guarantees and SLA update rates. Data provided by a specialized simulator underline the findings.

1

A micro-flow is a end-to-end communication identified by a source and destination address pair, a protocol number and (if these exist) a pair of port numbers. A TCP socket communication is a typical example of a micro-flow.