ACN.pptx

Text book
Computer Networks: A Systems
Approach, 5e
Larry L. Peterson and Bruce S. Davie

Advanced Internetworking and End-to-End Protocols
Multiprotocol Label Switching (MPLS): Destination-Based Forwarding, Explicit
Routing, Virtual Private Networks, and Tunnels, Routing among Mobile Devices:
Challenges for Mobile Networking, Routing to Mobile Hosts (Mobile IP), End-to-End
Protocols: Simple Demultiplexer (UDP), Reliable Byte Stream (TCP) - End-to-End
Issues, Segment Format, Connection Establishment and Termination, Sliding
Window Revisited, Triggering Transmission, Adaptive Retransmission, Record
Boundaries, TCP Extensions, Performance, Alternative Design Choices. Congestion
Control and Resource Allocation: Issues in Resource Allocation - Network Model,
Taxonomy, Evaluation Criteria. Queuing Disciplines - FIFO, Fair Queuing

 Multiprotocol Label Switching (MPLS)
 Routing among Mobile Devices
 End-to-End Protocols
 Congestion Control and Resource Allocation

 Multi-Protocol Label Switching (MPLS) is an IP packet routing technique that
routes IP packets through paths via labels instead of looking at complex routing
tables of routers.
 This feature helps in increasing the delivery rate of IP packets’ uses layer 3 service
i.e, Internet Protocol, and uses a router as forwarding device. The traffic of
different customers is separated from each other because MPLS works somewhat
like VPN.
 It does not work like regular VPN that encrypts the data but it ensures packet from
one customer cannot be received by another customer. An MPLS header is added
to packet that lies between layers 2 and 3. Hence, it is also considers to be Layer
2.5 protocol.

 Hence, it is also considering to be Layer 2.5 protocol.
 MPLS Header –
 The MPLS Header is 32 bit long and is divided into four parts –
 Label – This field is 20 bit long and can take value b/w 0 & 220 – 1.
 Exp – They are 3 bits long and used for Quality of Service (QoS).
 Bottom of stack (S) – It is of size 1 bit. MPLS labels are stacked one over the other. If there is only
one label remained in MPLS header, then its value is 1 otherwise 0.
 Time to Live (TTL) – It is 8 bit long and its value is decreased by one at each hop to prevent packet
to get stuck in network.

IMPORTANT TERMS USED IN MPLS:
Terms Description
Provider Edge(PE) Router
Router at edge of MPLS network that add or remove
label from IP packet.
Customer Edge(CE) Router
Router at edge of customer network that send or
receive IP packet from PE.
Label Switch Router(LSR)
Routers used in MPLS network that can understand
labels.
Ingress LSR
LSR routers that receive IP packet from CE Routers
and add MPLS header.
Intermediate LSR
LSR routers that swap label in MPLS header and
assigned for forwarding labeled IP packet.
Egress LSR
LSR routers that send IP packet to CE routers and
removes MPLS header.
Push, Pop and Swap
Action of addition, removal and swapping of labels by
LSR respectively.

HOW DOES MULTIPROTOCOL LABEL SWITCHING (MPLS) ROUTING WORK
 Multiprotocol Label Switching (MPLS) is a traffic routing mechanism it has significant advantages
over the traditional IP-based routing mechanism, MPLS is used in telecommunication networking
where it shapes the data packet transmission among the nodes.
 In traditional IP based routing, IP datagram packet is analysed by the router and according to the
source and destination address contains by the packet it has been processing and forwarded by the
routers (by using routing table for packet forwarding), this datagram follow the path set up by the
routing protocol such as (OSPF, BGP, EGP) and accomplish the defined route to reaching till the
destination node.
 An IP address is the identity of the network and a subnet mask, when a packet is forwarded by the
routers, the routing table is used to determine the forwarding mechanism and the packet is sent over
the interface registered with a route containing the shortest optimize path till the destination. If
there is no route found for the packet in the routing table, the default route is used to transmit the
packet to the destination.
 In MPLS each router requires to determine the next router or the next node/hope of the
packet(where the datagram need to be transmitted) by inspecting the packet destination address
before conferring its own routing table, this process is slow and degraded in terms of time
consumption and performance for live scenario such as audio and video transmission in real-time
applications.

ROUTING AMONG MOBILE DEVICES
 Mobile communication started in early 1980, and from that time the le technology has been developed to
fulfill the voice and data requirements of the subscriber.
 But the data requirements are increasing day to day because of subscriber demands, fast mobile internet for
online multimedia applications, video calls, and video conferencing, and also need fast data rate for
business applications etc.
 Therefore, different wireless stander and technologies came into the market to enhance the data capacity of
the networks and to provide new services and applications.
 All these systems are designed independently; targeting different service types and data rates. None of these
standers meet the public demands and hence are incapable to provide new services and applications that are
ubiquitous and customized to individual needs. Similarly, because of independent Radio Access
Technologies (RATs) the radio spectrum is underutilized.
 Hence the operator is not getting the optimal net profit. In order to meet the rising expectations, all wired
and wireless networks need to be integrated to share resources and services.
 This convergence introduces the concept of Converged Heterogeneous Networks (CHN). Therefore, we
need: • Context aware and active mobile networks (MN). • Intelligent, reconfigurable, cognitive and
cooperative mobile terminal (MT). By using context aware, active and cognitive MN and MT a very
flexible networking environment can be established which can address the CHN issues.

ROUTING AMONG MOBILE DEVICES
The main objective of future mobile networks is:
• To integrate all mobile networks by providing roaming and seamless handover facility
between different cellular networks and public-private unlicensed networks, hence raising
different challenges.
• We can divide the challenges of future mobile networks into the following categories:
• Efficient utilization of network resources in CHN environment.
• Technological independent network access, end to end connection and seamless handover.
• Maintaining the certain level of QoS (Quality of Service) for user applications.
• Cooperative network management.
• An intelligent billing policy.

ROUTING TO MOBILE HOSTS (MOBILE IP):
 Mobile IP is the primary mechanism in today’s Internet architecture to tackle the problem of routing packets to
mobile hosts. It introduces a few new capabilities but does not require any change from non-mobile hosts or most
routers—thus tackling the incremental deployment issue raised above.
 Therefore, the mobile host is assumed to have a permanent IP address, called its home address, which has a
network prefix equal to that of its home network. This is the address that will be used by other hosts when they
initially send packets to the mobile host; because it does not change, it can be used by long-lived applications as
the host roams.
 We can think of this as the long-lived identifier of the host. When the host moves to a new foreign network away
from its home network, it typically acquires a new address on that network using some means such as DHCP.5
 This address is going to change every time the host roams to a new network, so we can think of this as being
more like the locator for the host, but it is important to note that the host does not lose its permanent home
address when it acquires a new address on the foreign network. This home address is critical to its ability to
sustain communications as it moves, as we’ll see below.

 This router is located on the home network of the mobile host. In some cases, a second router with
enhanced functionality, the foreign agent, is also required. This router is located on a network to
which the mobile node attaches itself when it is away from its home network.
 We will consider first the operation of Mobile IP when a foreign agent is used. An example network
with both home and foreign agents is shown in Figure 4.27. Both home and foreign agents
periodically announce their presence on the networks to which they are attached using agent
advertisement messages.
• A mobile host may also solicit an advertisement when it attaches to a new network. The advertisement
by the home agent enables a mobile host to learn the address of its home agent before it leaves its home
network.
• When the mobile host attaches to a foreign network, it hears an advertisement from a foreign agent and
registers with the agent, providing the address of its home agent.
• The foreign agent then contacts the home agent, providing a care-of address. This is usually the IP
address of the foreign agent. At this point, we can see that any host that tries to send a packet to the
mobile host will send it with a destination address equal to the home address of that node.
• Normal IP forwarding will cause that packet to arrive on the home network of the mobile node on
which the home agent is sitting.

 This router is located on the home network of the mobile host. In some cases, a second router
with enhanced functionality, the foreign agent, is also required. This router is located on a
network to which the mobile node attaches itself when it is away from its home network. We will
consider first the operation of Mobile IP when a foreign agent is used. An example network with
both home and foreign agents is shown in Figure 4.27. Both home and foreign agents periodically
announce their presence on the networks to which they are attached using agent advertisement
messages.
• A mobile host may also solicit an advertisement when it attaches to a new network. The
advertisement by the home agent enables a mobile host to learn the address of its home agent
before it leaves its home network. When the mobile host attaches to a foreign network, it hears an
advertisement from a foreign agent and registers with the agent, providing the address of its home
agent.
• The foreign agent then contacts the home agent, providing a care-of address. This is usually the IP
address of the foreign agent. At this point, we can see that any host that tries to send a packet to the
mobile host will send it with a destination address equal to the home address of that node. Normal
IP forwarding will cause that packet to arrive on the home network of the mobile node on which
the home agent is sitting.

END-TO-END PROTOCOLS:
Simple Demultiplexer (UDP):
 The simplest possible transport protocol is one that extends the host-to-host delivery service
of the underlying network into a process-to-process communication service.
 There are likely to be many processes running on any given host, so the protocol needs to
add a level of demultiplexing, thereby allowing multiple application processes on each host
to share the network.
 Aside from this requirement, the transport protocol adds no other functionality to the best-
effort service provided by the underlying network. The Internet’s User Datagram Protocol is
an example of such a transport protocol.
 The only interesting issue in such a protocol is the form of the address used to identify the
target process. Although it is possible for processes to directly identify each other with an
OS-assigned process id (pid), such an approach is only practical in a closed distributed
system in which a single OS runs on all hosts and assigns each process a unique id.
 A more common approach, and the one used by UDP, is for processes to indirectly identify
each other using an abstract locater, usually called a port. The basic idea is for a sourcing
process to send a message to a port and for the destination process to receive the message
from a port,

Simple Demultiplexer (UDP):
 The header for an end-to-end protocol that implements this demultiplexing function typically
contains an identifier (port) for both the sender (source) and the receiver (destination) of the
message.
 Notice that the UDP port field is only 16 bits long. This means that there are up to 64K possible
ports, clearly not enough to identify all the processes on all the hosts on the Internet.
 Fortunately, ports are not interpreted across the entire Internet, but only on a single host. That is, a
process is really identified by a port on some particular host: a (port, host) pair. This pair constitutes
the demultiplexing key for the UDP protocol.
 The next issue is how a process learns the port for the process to which it wants to send a message.
Typically, a client process initiates a message exchange with a server process. Once a client has
contacted a server, the server knows the client’s port (from the SrcPrt field contained in the message
header) and can reply to it.
 The real problem, therefore, is how the client learns the server’s port in the first place. A common
approach is for the server to accept messages at a well-known port. That is, each server receives its
messages at some fixed port that is widely published, much like the emergency telephone service
available in the United States at the well-known phone number 911.

Figure:Format of UDP Header
 On the Internet, for example, the Domain Name Server (DNS) receives messages at well-known port 53
on each host, the mail service listens for messages at port 25, and the Unix talk program accepts messages
at well-known port 517, and so on.
 This mapping is published periodically in an RFC and is available on most Unix systems in file
/etc/services. Sometimes a well-known port is just the starting point for communication.
 The client and server use the well-known port to agree on some other port that they will use for
subsequent communication, leaving the well-known port free for other clients.

 An alternative strategy is to generalize this idea so that there is only a single well-known
port—the one at which the port mapper service accepts messages.
 A client would send a message to the port mapper’s well-known port asking for the port
it should use to talk to the “whatever” service, and the port mapper returns the
appropriate port.
 This strategy makes it easy to change the port associated with different services over
time and for each host to use a different port for the same service.

 When a message arrives, the protocol (e.g., UDP) appends the message to the end of the queue. Should the queue be full, the
message is discarded. There is no flow-control mechanism in UDP to tell the sender to slow down. When an application process
wants to receive a message, one is removed from the front of the queue. If the queue is empty, the process blocks until a message
becomes available.
 Figure: UDP message queing
 Finally, although UDP does not implement flow control or reliable/ordered delivery, it does provide one more function aside from
demultiplexing messages to some application process—it also ensures the correctness of the message by the use of a checksum.
(The UDP checksum is optional in IPv4 but is mandatory in IPv6.)
 The basic UDP checksum algorithm is the same one used for IP—that is, it adds up a set of 16-bit words using ones’ complement
arithmetic and takes the ones’ complement of the result. But the input data that is used for the checksum is a little
counterintuitive.

 In contrast to a simple demultiplexing protocol like UDP, a more sophisticated
transport protocol is one that offers a reliable, connection-oriented, byte-stream
service.
 Such a service has proven useful to a wide assortment of applications because it
frees the application from having to worry about missing or reordered data.
 The Internet’s Transmission Control Protocol is probably the most widely used
protocol of this type; it is also the most carefully tuned.
 In terms of the properties of transport protocols given in the problem statement
and TCP guarantees the reliable, in-order delivery of a stream of bytes.
 It is a full-duplex protocol, meaning that each TCP connection supports a pair of
byte streams, one flowing in each direction.
 It also includes a flow-control mechanism for each of these byte streams that
allows the receiver to limit how much data the sender can transmit at a given time.
Reliable Byte Stream (TCP) :

 Finally, like UDP, TCP supports a demultiplexing mechanism that allows multiple
application programs on any given host to simultaneously carry on a conversation
with their peers.
 TCP also implements a highly tuned (and still evolving) congestion-control
mechanism.
 The idea of this mechanism is to throttle how fast TCP sends data, not for the sake
of keeping the sender from over-running the receiver, but so as to keep the sender
from overloading the network.
 A description of TCP’s congestion-control mechanism is postponed. where we
discuss it in the larger context of how network resources are allocated.
Reliable Byte Stream (TCP) :

 At the heart of TCP is the sliding window algorithm, TCP runs over the Internet rather than
a point-to-point link, there are many important differences. This subsection identifies these
differences and explains how they complicate TCP.
 First, whereas the sliding window algorithm pis resented.it runs over a single physical link
that always connects the same two computers, TCP supports logical connections between
processes that are running on any two computers on the Internet.
 This means that TCP needs an explicit connection establishment phase during which the two
sides of the connection agree to exchange data with each other. This difference is analogous
to having to dial up the other party, rather than having a dedicated phone line.
End-to-End Issues:

 TCP also has an explicit connection teardown phase. One of the things that happen during
connection establishment is that the two parties establish some shared state to enable the
sliding window algorithm to begin.
 Connection teardown is needed so each host knows it is OK to free this state. Second,
whereas a single physical link that always connects the same two computers has a fixed
round-trip time (RTT).
 TCP connections are likely to have widely different round-trip times.
 For example, a TCP connection between a host in San Francisco and a host in Boston, which
are separated by several thousand kilometers, might have an RTT of 100 ms, while a TCP
connection between two hosts in the same room, only a few meters apart, might have an
RTT of only 1 ms.
 The same TCP protocol must be able to support both of these connections.
End-to-End Issues:

 To make matters worse, the TCP connection between hosts in San Francisco and Boston
might have an RTT of 100 ms at 3 a.m., but an RTT of 500 ms at 3 p.m.
 Variations in the RTT are even possible during a single TCP connection that lasts only a few
minutes.
 The real issue is how far out-of-order packets can get or, said another way, how late a packet
can arrive at the destination. In the worst case, a packet can be delayed on the Internet until
the IP time to live (TTL) field expires, at which time the packet is discarded (and hence
there is no danger of it arriving late).
 Knowing that IP throws packets away after their TTL expires, TCP assumes that each packet
has a maximum lifetime. The exact lifetime, known as the maximum segment lifetime
(MSL), is an engineering choice.
 An address is a byte string that identifies a node; that is, the network can use a node’s
address to distinguish it from the other nodes connected to the network.
End-to-End Issues:

 When a source node wants the network to deliver a message to a certain destination node, it
specifies the address of the destination node.
 If the sending and receiving nodes are not directly connected, then the switches and routers
of the network use this address to decide how to forward the message toward the
destination.
 The process of determining systematically how to forward messages toward the destination
node based on its address is called routing.
 Designing the system otherwise would be silly. On the other hand, almost any kind of
computer can be connected to the Internet, making the number of resources dedicated to any
one TCP connection highly variable, especially considering that any one host can potentially
support hundreds of TCP connections at the same time.
 This means that TCP must include a mechanism that each side uses to “learn” what
resources (e.g., how much buffer space) the other side is able to apply to the connection.
This is the flow control issue

 TCP is a byte-oriented protocol, which means that the sender writes bytes into a TCP
connection and the receiver reads bytes out of the TCP connection.
 Although “byte stream” describes the service TCP offers to application processes, TCP does
not, itself, transmit individual bytes over the Internet.
 Instead, TCP on the source host buffers enough bytes from the sending process to fill a
reasonably sized packet and then sends this packet to its peer on the destination host.
 TCP on the destination host then empties the contents of the packet into a receive buffer, and
the receiving process reads from this buffer at its leisure.
 The packets exchanged between TCP peers in Figure are called segments, since each one
carries a segment of the byte stream. Each TCP segment contains the header schematically
depicted in Figure.
Segment Format:

 The relevance of most of these fields will become apparent throughout this section. For now,
we simply introduce them.
 The SrcPort and DstPort fields identify the source and destination ports, respectively, just as
in UDP.
 These two fields, plus the source and destination IP addresses, combine to uniquely identify
each TCP connection.
 That is, TCP’s demux key is given by the 4-tuple: SrcPort, SrcIPAddr, DstPort, DstIPAddr.
 Note that because TCP connections come and go, it is possible for a connection between a
particular pair of ports to be established, used to send and receive data, and closed, and then
at a later time for the same pair of ports to be involved in a second connection.
 The Acknowledgment, Sequence number, and Advertised Window fields are all involved in
TCP’s sliding window algorithm. Because TCP is a byte-oriented protocol, each byte of data
has a sequence number.
Segment Format:

CONNECTION ESTABLISHMENT AND TERMINATION:
 To make the transport services reliable, TCP hosts must establish a connection-oriented session with one another.
Connection establishment is performed by using the three-way handshake mechanism. A three-way handshake
synchronizes both ends of a network by enabling both sides to agree upon original sequence numbers.This mechanism
also provides that both sides are ready to transmit data and learn that the other side is available to communicate. This is
essential so that packets are not shared or retransmitted during session establishment or after session termination. Each
host randomly selects a sequence number used to track bytes within the stream it is sending and receiving.
 The three-way handshake proceeds in the manner shown in the figure below:

 The requesting end (Host A) sends an SYN segment determining the server's port number
that the client needs to connect to and its initial sequence number (x).
 The server (Host B) acknowledges its own SYN segment, including the server’s initial
sequence number (y). The server also responds to the client SYN by accepting the sender's
SYN plus one (X + 1).
 An SYN consumes one sequence number. The client should acknowledge this SYN from
the server by accepting the server's SEQ plus one (SEQ = x + 1, ACK = y + 1). This is
how a TCP connection is settled.
 Connection Termination Protocol (Connection Release):

 While it creates three segments to establish a connection, it takes four segments to
terminate a connection.
 During a TCP connection is full-duplex (that is, data flows in each direction independently
of the other direction), each direction should be shut down alone.The termination
procedure for each host is carried out.
 The rule is that either end can share a FIN when it has finished sending data. When a TCP
receives a FIN, it should notify the application that the other end has terminated that data
flow direction. The sending of a FIN is usually the result of the application issuing a close.
 The receipt of a FIN only means that there will be no more data flowing in that direction.
A TCP can send data after receiving a FIN. The end that first issues the closfor e (example,
send the first FIN) executes the active close. The other end (that receives this FIN)
manages the passive close.

SLIDING WINDOW PROTOCOL REVISED
 TCP’s variant of the sliding window algorithm, which serves several purposes:
(1) it guarantees the reliable delivery of data,
(2) it ensures that data is delivered in order, and
(3) flow control between the sender and the receiver.
 Where TCP differs from the earlier algorithm is that it folds the flow-control function in as well. In
particular, rather than having a fixed-size sliding window, the receiver advertises a window size to the
sender. This is done using the Advertised Window field in the TCP header.
 The sender is then limited to having no more than a value of Advertised Window bytes of unacknowledged
data at any given time. The receiver selects a suitable value for the Advertised Window based on the
amount of memory allocated to the connection for the purpose of buffering data.
 The idea is to keep the sender from over-running the receiver’s buffer. We discuss this at greater length
below. Reliable and Ordered Delivery To see how the sending and receiving sides of TCP interact with
each other to implement reliable and ordered delivery, consider the situation.

SLIDING WINDOW PROTOCOL REVISED
 This buffer is used to store data that has been sent but not yet acknowledged, as well as data that has been
written by the sending application but not transmitted. On the receiving side, TCP maintains a receive
buffer.
 This buffer holds data that arrives out of order, as well as data that is in the correct order (i.e., there are no
missing bytes earlier in the stream) but that the application process has not yet had the chance to read.
 To make the following discussion simpler to follow, we initially ignore the fact that both the buffers and
the sequence numbers are of some finite size and hence will eventually wrap around. Also, we do not
distinguish between a pointer into a buffer where a particular byte of data is stored and the sequence
number for that byte.
 TCP guarantees the reliable delivery of data, it retransmits each segment if an ACK is not received in a
certain period of time. TCP sets this timeout as a function of the RTT it expects between the two ends of the
connection.
 Unfortunately, given the range of possible RTTs between any pair of hosts on the Internet, as well as the
variation in RTT between the same two hosts over time, choosing an appropriate timeout value is not that
easy.

ADAPTIVE RETRANSMISSION:
 To address this problem, TCP uses an adaptive retransmission mechanism. We now
describe this mechanism and how it has evolved over time as the Internet community has
gained more experience using TCP.
 Original Algorithm We begin with a simple algorithm for computing a timeout value
between a pair of hosts.
 This is the algorithm that was originally described in the TCP specification and the
following description presents it in those terms but it could be used by any end-to-end
protocol.
 The idea is to keep a running average of the RTT and then compute the timeout as a
function of this RTT. Specifically, every time TCP sends a data segment, it records the
time.

 When an ACK for that segment arrives, TCP reads the time again and then takes the
difference between these two times as a SampleRTT.
 TCP then computes an EstimatedRTT as a weighted average between the previous estimate
and this new sample.
That is, EstimatedRTT = α × EstimatedRTT + (1 − α) × SampleRTT
 The parameter α is selected to smooth the EstimatedRTT.

 A small α tracks changes in the RTT but is perhaps too heavily influenced by temporary
fluctuations.
 On the other hand, a large α is more stable but perhaps not quick enough to adapt to real
changes.
 The original TCP specification recommended a setting of α between 0.8 and 0.9.
 TCP then uses EstimatedRTT to compute the timeout in a rather conservative way:
TimeOut = 2 × EstimatedRTT.

 After several years of use on the Internet, a rather obvious flaw was discovered in this
simple algorithm. The problem was that an ACK does not really acknowledge a
transmission; it actually acknowledges the receipt of data.
 In other words, whenever a segment is retransmitted and then an ACK arrives at the sender,
it is impossible to determine if this ACK should be associated with the first or the second
transmission of the segment for the purpose of measuring the sample RTT.
 It is necessary to know which transmission to associate it with to compute an accurate
SampleRTT.
 In the above figure, if you assume that the ACK is for the original transmission, but it was
really for the second, then the SampleRTT is too large.
(a) If you assume that the ACK is for the second transmission but it was for the first, then the
SampleRTT is too small.
(b) Whenever TCP retransmits a segment, it stops taking samples of the RTT; it only
measures SampleRTT for segments that have been sent only once. This solution is known as
the Karn/Partridge algorithm, after its inventors.

 Their proposed fix also includes a second small change to TCP’s timeout mechanism. Each
time TCP retransmits, it sets the next timeout to be twice the last timeout, rather than basing
it on the last EstimatedRTT.
 That is, Karn and Partridge proposed that TCP use exponential backoff, similar to what the
Ethernet does.
 The motivation for using exponential backoff is simple: Congestion is the most likely cause
of lost segments, meaning that the TCP source should not react too aggressively to a
timeout.
 In fact, the more times the connection times out, the more cautious the source should
become.

RECORD BOUNDARIES:
 Since TCP is a byte-stream protocol, the number of bytes written by the sender is not
necessarily the same as the number of bytes read by the receiver.
 TCP does not interject record boundaries between the 8th and 9th bytes, nor between the
10th and 11th bytes.
 This contrasts with a message-oriented protocol, such as UDP, in which the message that
is sent is exactly the same length as the message that is received.
 Even though TCP is a byte-stream protocol, it has two different features that can be used
by the sender to insert record boundaries into this byte stream, thereby informing the
receiver how to break the stream of bytes into records.

RECORD BOUNDARIES:
 Both of these features were originally included in TCP for completely different reasons; they have
only come to be used for this purpose over time.
 The first mechanism is the urgent data feature, as implemented by the URG flag and the UrgPtr
field in the TCP header.
 Originally, the urgent data mechanism was designed to allow the sending application to send out-
of-band data to its peer.
 By “out of band” we mean data that is separate from the normal flow of data (e.g., a command to
interrupt an operation already under way).
 This out-of-band data was identified in the segment using the UrgPtr field and was to be delivered
to the receiving process as soon as it arrived, even if that meant delivering it before data with an
earlier sequence number.
 Over time, however, this feature has not been used, so instead of signifying “urgent” data, it has
come to be used to signify “special” data, such as a record marker.
 Reliable byte stream (TCP) 423 informs the application that urgent data has arrived. That is,
urgent data is not important. It is the fact that the sending process can effectively send a signal to
the receiver that is important.

PERFORMANCE:
 The two quantitative metrics by which network performance is evaluated by latency and
throughput.
 These metrics are influenced not only by the underlying hardware (e.g., propagation delay
and link bandwidth) but also by software overheads.
 Now that we have a complete software-based protocol graph available to us that includes
alternative transport protocols, we can discuss how to meaningfully measure its performance.
 The importance of such measurements is that they represent the performance seen by
application programs. We begin, as any report of experimental results should, by describing
our experimental method.
 This includes the apparatus used in the experiments; in this case, each workstation has a pair
of dual CPU 2.4-GHz Xeon processors running Linux.

PERFORMANCE:
 In order to enable speeds above 1 Gbps, a pair of Ethernet adaptors (labeled NIC, for network
interface card) are used on each machine.
 The Ethernet spans a single machine room, so propagation is not an issue, making this a
measure of processor/software overheads.
 A test program running on top of the socket interface simply tries to transfer data as quickly
as possible from one machine to the other.
 The throughput test is performed for a variety of message sizes using a standard
benchmarking tool called TTCP.
 There were some real problems (e.g., network adaptors, workstation architectures, and
operating systems all had to be designed with network-to-application throughput.
 Also, some perceived problems turned out to be not so serious. High on the list of such
problems was the concern that existing transport protocols, TCP in particular, might not be up
to the challenge of gigabit operation.

ALTERNATIVE DESIGN CHOICES:
 TCP has proven to be a robust protocol that satisfies the needs of a wide range of
applications, the design space for transport protocols is quite large.
 TCP is by no means the only valid point in that design space. We conclude our discussion of
TCP by considering alternative design choices.
 we observe that other protocols exist that have made other choices, and more such protocols
may appear in the future.
 There are at least two interesting classes of transport protocols: stream-oriented protocols like
TCP and request/reply protocols like RPC.
 TCP is a full-duplex protocol, so it would be easy to open a TCP connection between the
client and server, send the request message in one direction, and send the reply message in
the other direction.

CONGESTION CONTROL AND RESOURCE ALLOCATION:
 Congestion control and resource allocation involve both hosts and network elements such as
routers.
 In network elements, various queuing disciplines can be used to control the order in which
packets get transmitted and which packets get dropped.
 The queuing discipline can also segregate traffic to keep one user’s packets from unduly
affecting another user’s packets.
 At the end hosts, the congestion control mechanism paces how fast sources are allowed to
send packets.
 This is done to keep congestion from occurring in the first place and, should it occur, to help
eliminate the congestion.

ISSUES IN RESOURCE ALLOCATION:
 Resource allocation and congestion control are complex issues that have been the subject of
many studies ever since the first network was designed.
 They are still active areas of research. One factor that makes these issues complex is that they
are not isolated to one single level of a protocol hierarchy.
 Resource allocation is partially implemented in the routers, switches, and links inside the
network and partially in the transport protocol running on the end hosts.
 End systems may use signaling protocols to convey their resource requirements to network
nodes, which respond with information about resource availability.
 By resource allocation, we mean the process by which network elements try to meet the
competing demands that applications have for network resources primarily link bandwidth
and buffer space in routers or switches
 This might be achieved simply by persuading a few hosts to stop sending, thus improving the
situation for everyone else. However, it is more common for congestion-control mechanisms
to have some aspect of fairness

NETWORK MODEL:
 In Packet-Switched Network, We have considered resource allocation in a packet-switched
network (or internet) consisting of multiple links and switches (or routers).
 Since most of the mechanisms described were designed for use on the Internet, and therefore
were originally defined in terms of routers rather than switches, we use the term router
throughout our discussion.
 The problem is essentially the same, whether on a network or the internetwork. In such an
environment, a given source may have more than enough capacity on the immediate outgoing
link to send a packet, but somewhere in the middle of a network, its packets encounter a link
that is being used by many different traffic sources.
 Two high-speed links are feeding a low-speed link. This contrasts with shared-access
networks like Ethernet and wireless networks, where the source can directly observe the
traffic on the network and decide accordingly whether or not to send a packet. These access-
control algorithms are, in some sense, analogous to congestion-control algorithms in a
switched network.

CONNECTIONLESS FLOWS:
 For much of our discussion, we assume that the network is essentially connectionless, with
any connection-oriented service implemented in the transport protocol that is running on the
end hosts.
 This is precisely the model of the Internet, where IP provides a connectionless datagram
delivery service and TCP implements an end-to-end connection abstraction.

 Note that this assumption does not hold in virtual circuit networks such as ATM and X.25. In
such networks, a connection setup message traverses the network when a circuit is
established.
 This setup message reserves a set of buffers for the connection at each router, thereby
providing a form of congestion control a connection is established only if enough buffers can
be allocated to it at each router.
 The major shortcoming of this approach is that it leads to an underutilization of resources—
buffers reserved for a particular circuit are not available for use by other traffic even if they
were not currently being used by that circuit.

 The focus of this chapter is on resource allocation approaches that apply in an internetwork,
and thus we focus mainly on connectionless networks.
 We need to qualify the term connectionless because our classification of networks as being
either connectionless or connection-oriented is a bit too restrictive.
 The datagrams are certainly switched independently, but it is usually the case that a stream of
datagrams between a particular pair of hosts flows through a particular set of routers.
 This idea of a flow—a sequence of packets sent between a source/destination pair and
following the same route through the network—is an important abstraction in the context of
resource allocation.

SERVICE MODEL:
 In the early part of this, we will focus on mechanisms that assume the best-effort service
model of the Internet.
 With best-effort service, all packets are given essentially equal treatment, with end hosts
given no opportunity to ask the network that some packets or flows be given certain
guarantees or preferential service.
 Defining a service model that supports some kind of preferred service or guarantee for
example, guaranteeing the bandwidth needed for a video stream.
 Such a service model is said to provide multiple qualities of service (QoS).
 As we will see, there is actually a spectrum of possibilities, ranging from a purely best-effort
service model to one in which individual flows receive quantitative guarantees of QoS.
 One of the greatest challenges is to define a service model that meets the needs of a wide
range of applications and even allows for the applications that will be invented in the future.

TAXONOMY:
 There are countless ways in which resource allocation mechanisms differ, so creating a
thorough taxonomy is a difficult proposition.
 Router-Centric versus Host-Centric Resource allocation mechanisms can be classified into
two broad groups:
 The problem from inside the network (i.e., at the routers or switches) and those that address it
from the edges of the network (i.e., in the hosts, perhaps inside the transport protocol).
 Since it is the case that both the routers inside the network and the hosts at the edges of the
network participate in resource allocation, the real issue is where the majority of the burden
falls.
 In a router-centric design, each router takes responsibility for deciding when packets are
forwarded and selecting which packets are to be dropped, as well as informing the hosts that
are generating the network traffic how many packets they are allowed to send.
 In a host-centric design, the end hosts observe the network conditions (e.g., how many
packets they are successfully getting through the network) and adjust their behavior
accordingly. Reservation-Based versus Feedback-Based.

TAXONOMY:
 A second way that resource allocation mechanisms are sometimes classified is according to
whether they use reservations or feedback.
 In a reservation-based system, some entity (e.g., the end host) asks the network for a certain
amount of capacity to be allocated for a flow. Each router then allocates enough resources
(buffers and/or percentage of the link’s bandwidth) to satisfy this request.
 If the request cannot be satisfied at some router because doing so would overcommit its
resources, then the router rejects the reservation.
 This is analogous to getting a busy signal when trying to make a phone call. In a feedback-
based approach, the end hosts begin sending data without first reserving any capacity and
then adjust their sending rate according to the feedback they receive.
 This feedback can be either explicit (i.e., a congested router sends a “please slow down”
message to the host) or implicit (i.e., the end host adjusts its sending rate according to the
externally observable behavior of the network, such as packet losses).

EVALUATION CRITERIA:
 The final issue is one of knowing whether a resource allocation mechanism is good or not.
 Recall that in the problem statement at the start, we posed the question of how a network
effectively and fairly allocates its resources.
 This suggests at least two broad measures by which a resource allocation scheme can be
evaluated. We consider each in turn.
a) Effective Resource Allocation
b) Queuing Disciplines
c) FIFO
d) Fair Queuing :

ACN.pptx

Recommended

Recommended

More Related Content

Similar to ACN.pptx

Similar to ACN.pptx (20)

Recently uploaded

Recently uploaded (20)

ACN.pptx