Skip to main content
SpringerLink
Log in

IP-Based Networks and Future Trends

  • Chapter
  • First Online:
Queuing Theory and Telecommunications

  • 2562 Accesses

Abstract

A growing number of people are using the Internet, the network of the networks; this is also evident from the different bandwidth-intensive applications supported by Internet and by the considerable number of Internet books, video, etc. that have become available during these years. The widespread diffusion of social networks (Facebook, YouTube, etc.), peer-to-peer traffic, and cloud applications have further contributed to the impressive growth in the Internet use. IP traffic has globally grown eight times in the period 2008–2012 (5 years) and is expected to increase threefold in the next 3 years. The annual global IP traffic will surpass the Zettabyte (i.e., 1021 bytes) threshold by the end of 2016 [1]. This chapter focuses on the protocols and the network technologies to support Internet traffic.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Log in via an institution
Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 84.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 109.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    ARP is an Internet protocol, which dynamically determines the physical hardware (MAC) address corresponding to an IP address in case of direct routing.

  2. 2.

    Peering locations are places where the networks of different ASs interconnect. Public peering locations were known as NAPs, but today are most often called IXPs. See also Sect. 3.9.2.

  3. 3.

    In Unix and other computer operating systems, a daemon is a particular class of computer programs running in background, rather than under the direct control of a user. These processes run independently of users, who are logged-in. Usually, daemons have names ending with a “d”.

  4. 4.

    In real systems, there is always a granularity in the arrival process (at the level of packets) so that the arrival traffic is a discrete-time process with a finite set of values.

  5. 5.

    In this refined token bucket model, we assume that at time t = 0 the regulator allows the transmission of a whole packet of size M at an infinite speed if M < b. Combining the token bucket contractual constraint b + rt with the physical limitations M + pt, the resulting arrival curve is α(t) = min(pt + M, rt + b).

  6. 6.

    The service curve is now σ(t) = max[0, R(t − T 0) + T 0].

  7. 7.

    The MSS values to be used for a TCP connection (by both sides) can be defined during the TCP three-way handshake procedure by the two end systems. Each end system notifies an MSS value (typically a host bases its MSS value on its outgoing interface MTU size) using the MSS option in the initial SYN message sent; the other end system makes use of the notified MSS value when it sends TCP segments. If one end does not receive an MSS option from the other end, a default MSS value of 536 bytes (i.e., MTU of 576 bytes) is assumed. However, RFC 1122 states that the use of the MSS option is mandatory in the connection set up phase.

  8. 8.

    The Nagle algorithm is used to avoid sending small segments in the network. The generation of small packets can be due to either some applications or a slow receiver asking to continuously reduce the window (silly window syndrome) up to the point that the data transmitted is smaller than the packet header, making data transmissions extremely inefficient. On slow links, many small packets can potentially lead to congestion. The Nagle algorithm works by combining a number of small packets, and sending them all together.

  9. 9.

    In general, DUPACKs can be generated due to many reasons, such as a segment loss, segments received out-of-sequence, retransmission of packets already received at the destination.

  10. 10.

    When the receiver implements delayed ACKs, the number of ACKs sent by the receiver roughly halves so that the sender opens cwnd more slowly (approximately of 1 segment every two RTTs).

  11. 11.

    More correctly, if B = 0, the maximum rate would be 3 × IBR/4 and not IBR.

References

  1. Cisco visual networking index: forecast and methodology, 2011–2016. Available online on the CISCO Web page with URL: http://www.cisco.com/en/US/

  2. Postel J (1972) Telnet protocol. IETF RFC 318, 3 Apr 1972

    Google Scholar 

  3. Bhushan A (1972) The file transfer protocol. IETF RFC 354, 8 Jul 1972

    Google Scholar 

  4. Braden R (1973) Comments on file transfer protocol. IETF RFC 430, 7 Feb 1973

    Google Scholar 

  5. IETF Web site with URL: www.ietf.org/rfc/

  6. Postel J (1981) Internet protocol. IETF RFC 791, Sept 1981

    Google Scholar 

  7. Postel J (1981) Transmission control protocol. IETF RFC 793, Sept 1981

    Google Scholar 

  8. Feit S (1996) TCP/IP architecture, protocols and implementation with IPv6 and IP security (revised and expanded), 2nd edn. McGraw-Hill, New York

    Google Scholar 

  9. Comer DE (2003) Network system design using network processor. Prentice Hall, Upper Saddle River, NJ

    Google Scholar 

  10. Comer DE (2000) Internetworking with TCP/IP. Principles protocols and architecture, 4th edn. Prentice-Hall, Upper Saddle River, NJ

    Google Scholar 

  11. Perlman R (1999) Interconnections: bridges, routers, switches, and internetworking protocols. Addison-Wesley, Reading, MA

    Google Scholar 

  12. Braden R (1989) Requirements for internet hosts—communication layers. IETF RFC 1122, Oct 1989

    Google Scholar 

  13. Kirkpatrick S, Stahl M, Recker M (1990) Internet numbers. IETF RFC 1166, Jul 1990

    Google Scholar 

  14. Reynolds J, Postel J (1994) Assigned numbers. IEFT RFC 1700, Oct 1994

    Google Scholar 

  15. Deering S, Hinden R (1998) Internet protocol, version 6 (IPv6) specification. RFC 2460, Dec 1998

    Google Scholar 

  16. Cherkassky BV, Goldberg AV, Radzik T (1996) Shortest paths algorithms: theory and experimental evaluation. Math Program A 73(2):129–174

    Article  MATH  MathSciNet  Google Scholar 

  17. Mills DL (1984) Exterior gateway protocol formal specification. IETF RFC 904, Apr 1984

    Google Scholar 

  18. Rekhter Y, Watson TJ, Li T (1995) A border gateway protocol 4 (BGP-4). IETF RFC 1771, Mar 1995

    Google Scholar 

  19. Braden R, Clark D, Shenker S (1994) Integrated services in the internet architecture: an overview. IETF RFC 1633, 1994

    Google Scholar 

  20. Braden R, Zhang L, Berson S, Herzog S, Jamin S (1997) Resource reservation protocol (RSVP) version 1 functional specification. IETF RFC 2205, 1997

    Google Scholar 

  21. Cruz RL (1991) A calculus for network delay. Part I: Network elements in isolation. IEEE Trans Inf Theory 37(1):114–131

    Article  MATH  MathSciNet  Google Scholar 

  22. Parekh AKJ (1992) A generalized processor sharing approach to flow control in integrated service networks. MIT Laboratory for Information and Decision Systems, Report LIDS-TH-2089, Feb 1992

    Google Scholar 

  23. Le Boudec J-Y, Thiran P (2004) Network calculus: a theory of deterministic queuing systems for the internet, vol 2050, LNCS. Springer, New York

    Google Scholar 

  24. Shenker S, Partridge C, Guérin R (1997) Specification of guaranteed quality of service. IETF RFC 2212, Sept 1997

    Google Scholar 

  25. Blake S, Black D, Carlson M, Davies E, Wang Z, Weiss W (1998) An architecture for differentiated service. IETF RFC 2475, Dec 1998

    Google Scholar 

  26. Andreadis A, Giambene G (2002) Protocols for high-efficiency wireless networks. Kluwer, New York

    Google Scholar 

  27. Floyd S, Jacobson V (1993) Random early detection (RED) gateways for congestion avoidance. IEEE/ACM Trans Networking 1(4):397–413

    Article  Google Scholar 

  28. Bernet Y, Ford P, Yavatkar R, Baker F, Zhang L, Speer M, Braden R, Davie B, Wroclawski J, Felstaine E (2000) A framework for integrated services operation over Diffserv networks. IETF RFC 2998, Nov 2000

    Google Scholar 

  29. Huston G (2000) Next steps for the IP QoS architecture. IETF RFC 2990, Nov 2000

    Google Scholar 

  30. Heinanen J (1993) Multiprotocol encapsulation over ATM adaptation layer 5. IETF RFC 1483, Jul 1993

    Google Scholar 

  31. Laubach M (1994) Classical IP and ARP over ATM. IETF RFC 1577, Jan 1994

    Google Scholar 

  32. Laubach M, Halpern J (1998) Classical IP and ARP over ATM. IETF RFC 2225, Apr 1998

    Google Scholar 

  33. Rosen E, Viswanathan A, Callon R (2001) Multiprotocol label switching architecture. IETF RFC 3031, Jan 2001

    Google Scholar 

  34. Rosen E, Tappan D, Fedorkow G, Rekhter Y, Farinacci D, Li T, Conta A (2001) MPLS label stack encoding. IETF RFC 3032, Jan 2001

    Google Scholar 

  35. Andersson L, Doolan P, Feldman N, Fredette A, Thomas B (2001) LDP specification 2. IETF RFC 3036, Jan 2001

    Google Scholar 

  36. Xiao X, Hannan A, Bailey B, Ni L (2000) Traffic engineering with MPLS in the internet. IEEE Network magazine, Mar 2000

    Google Scholar 

  37. Nichols K, Blake S, Baker F, Black D (1998) Definition of the differentiated services field (DS Field) in the IPv4 and IPv6 headers. IETF RFC 2474, Dec 1998

    Google Scholar 

  38. Awduche D, Berger L, Gan D, Li T, Srinivasan V, Swallow G (2001) RSVP-TE: extensions to RSVP for LSP tunnels. IETF RFC 3209, 2001

    Google Scholar 

  39. Jamoussi B et al (2002) Constraint-based LSP setup using LDP. IETF RFC 3212, 2002

    Google Scholar 

  40. Davie B, Rekhter Y (2000) MPLS: technology and applications. Morgan Kauffmann, San Francisco, CA

    Google Scholar 

  41. Mogul J (1990) Path MTU discovery. IETF RFC 1191, Nov 1990

    Google Scholar 

  42. Allman M, Paxons V, Stevens W (1999) TCP congestion control. IETF RFC 2581, Apr 1999

    Google Scholar 

  43. Karn P, Partridge C (1987) Improving round-trip time estimates in reliable transport protocols. In: Proc. of ACM SIGCOMM 1987

    Google Scholar 

  44. Chang RKC, Chan HY (2000) A throughput deadlock-free TCP for high-speed internet. Eighth IEEE International Conference on Networks (ICON‘00), 2000

    Google Scholar 

  45. Jain M, Prasad RS, Dovrolis C (2003) The TCP bandwidth-delay product revisited: network buffering, cross traffic, and socket buffer auto-sizing. Technical Report 2003 (GIT-CERCS-03-02). Available online with URL: http://www.cercs.gatech.edu/tech-reports/

  46. Jacobson V (1988) Congestion avoidance and control. Comput Commun Rev 18(4):314–329

    Article  Google Scholar 

  47. Mathis M, Mahdavi J, Floyd S, Romanow A (1996) TCP selective acknowledgment options. IETF RFC 2018, Oct 1996

    Google Scholar 

  48. Floyd S, Mahdavi J, Mathis M, Podolsky M (2000) An extension to the selective acknowledgement (SACK) option for TCP. IETF RFC 2883, Jul 2000

    Google Scholar 

  49. Floyd S, Henderson T, Gurtov A (2004) The NewReno modification to TCP’s fast recovery algorithm. IETF RFC 3782, 2004

    Google Scholar 

  50. Parvez N, Mahanti A, Williamson C (2006) TCP NewReno: slow-but-steady or impatient? In: Proc. of IEEE international conference on communications 2006 (ICC‘06), pp 716–722

    Google Scholar 

  51. Floyd S (1996) SACK TCP: the sender’s congestion control algorithms for the implementation “sack1” in LBNL’s “ns” simulator (viewgraphs). Technical report, Mar 1996. Presentation to the TCP Large Windows Working Group of the IETF, 7 Mar 1996

    Google Scholar 

  52. Fall K, Floyd S (1996) Simulation-based comparisons of Tahoe, Reno, and SACK TCP. ACM Comput Commun Rev 26(3):5–21

    Article  Google Scholar 

  53. Floyd S (2003) HighSpeed TCP for large congestion windows. IETF RFC 3649, Dec 2003

    Google Scholar 

  54. Kelly T (2003) Scalable TCP: improving performance in highspeed wide area networks. ACM Comput Commun Rev 33(2):83–91

    Article  Google Scholar 

  55. Gopal S, Paul S (2007) TCP dynamics in 802.11 wireless local area networks. In: Proc. of the IEEE international conference on communications 2007 (ICC‘07), 24–28 Jun 2007

    Google Scholar 

  56. Hoe J (1996) Improving the start-up behavior of a congestion control scheme for TCP. In: Proc. of ACM SIGCOMM, Aug 1996

    Google Scholar 

  57. Padhye J, Firoiu V, Towsley D, Kurose J (2000) Modeling TCP Reno performance: a simple model and its empirical validation. IEEE/ACM Trans Networking 8(2):133–145

    Article  Google Scholar 

  58. Mathis M, Semke J, Mahdavi J, Ott T (1997) The macroscopic behavior of the TCP congestion avoidance algorithm. ACM Comput Commun Rev 27(3):67–82

    Article  Google Scholar 

  59. NS-2 Network Simulator URL: http://www.isi.edu/nsnam/ns/

  60. Postel J (1980) User datagram protocol. IEFT RFC 768, 28 Aug 1980

    Google Scholar 

  61. IANA Web site with URL: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

  62. Sadiku MNO, Nguyen TH (2002) Next generation networks. IEEE Potentials 21(2):6–8

    Article  Google Scholar 

  63. Cochennec J-Y (2002) Activities on next-generation networks under global information infrastructure in ITU-T. IEEE Commun Mag 40(7):98–101

    Article  Google Scholar 

  64. ITU-T (2004) General overview of NGN. Recommendation Y.2001

    Google Scholar 

  65. Kartalopoulos SV (2004) DWDM: shaping the future communications network. IEEE Potentials, pp 16–19

    Google Scholar 

  66. Goode B (2002) Voice over internet protocol (VoIP). IEEE Proc 90(9):1495–1517

    Article  Google Scholar 

  67. ITU-T (2000) Packet-based multimedia communications systems. Recommendation H.323v4

    Google Scholar 

  68. Rosenberg J et al (2002) SIP: session initiation protocol. IETF RFC 3261, Jun 2002

    Google Scholar 

  69. FP5 GEANT project Web site with URL: http://www.geant.net/

  70. GEANT2 project Web site with URL: http://www.geant2.net/

  71. Chini P, Giambene G, Hadzic S (2008) Broadband satellite multimedia networks, chapter XV. In: Cranley N, Murphy L (eds) Handbook of research on wireless multimedia: quality of service and solutions. IGI, Hershey, PA, pp 377–397

    Chapter  Google Scholar 

  72. ETSI (2004) Satellite earth stations and systems (SES). Broadband Satellite Multimedia. Services and Architectures; BSM Traffic Classes. ETSI Technical Specification, TS 102 295 V1.1.1, Feb 2004.

    Google Scholar 

  73. ESA Satlab (2010) SatLabs system recommendations—quality of service specifications, Jun 2010

    Google Scholar 

  74. Survey on Satellite Systems available online with URL: http://space.skyrocket.de/doc_sat/sat-contracts.htm

  75. Baccelli F, Crowcroft J. Future internet technology—introduction. Available online with URL: http://ercim-news.ercim.eu/en77/special/future-internet-technologies-introduction

Download references

Author information

Authors and Affiliations

  1. Department of Information Engineering and Mathematical Sciences, University of Siena, Siena, Italy

    Giovanni Giambene

Authors
  1. Giovanni Giambene
    View author publications

    You can also search for this author in PubMed Google Scholar

1 Supplementary Materials

Exercises on Part I of the Book

Exercises on Part I of the Book

This section contains some exercises on the first part of the book. The main interest is on traffic regulators, Dijkstra routing, deterministic queuing, and cwnd behavior of TCP.

Ex. I.1 We have a Frame Relay network, which applies a policer to control the access of traffic sources. Let us consider a traffic source, which has a periodic ON-OFF bit-rate as a function of time as shown in Fig. 3.57, with parameters b (= burst bit-rate), T (= time length of the source cycle), and l (= xT, burst duration). The policer uses the following assumptions for the measurement interval, T c, the committed burst size, B c, and the excess burst size, B e:

Fig. 3.57
figure 57

Periodic traffic source (source cycle T) and measurement interval T c (in this graph T c ≡ T, y = 1)

Full size image

  • B c/T c = R c, a constant value

  • B e/T c = R e, a constant value

  • bl/T = bx = R s, mean source bit-rate

  • A rectangular pulse (burst) represents a single packet in Fig. 3.57

  • The measurement interval T c is applied to the periodic source according to the “phase” shown in Fig. 3.57, so that the source cycle T contains an integer number of measurement intervals T c (T c = yT, with y = 1, 1/2, 1/3, etc.)

  • Constraints: bx = R s ≤ R c (so that there is enough capacity to service the traffic source) and T c ≥ xT ⇒ y ≥ x (the measurement interval is larger than the burst duration).

It is requested to determine the conditions to have marking or dropping of all generated packets.

Ex. I.2 Let us consider an ATM switch with a switching table, which manages virtual paths and virtual channels, as shown in Fig. 3.58. It is requested to determine the VPI and VCI fields to be used for an input cell if we like that this cell leaves the switch from output line A; in this case, we are also asked to provide the VPI and VCI fields of the corresponding output cell.

Fig. 3.58
figure 58

ATM switch and its switching table

Full size image

Ex. I.3 Let us consider the network depicted in Fig. 3.59: it is requested to determine the sink tree for node A by applying the Dijkstra shortest path routing algorithm.

Fig. 3.59
figure 59

Network with bidirectional links, labeled by (a, c), where “a” denotes the link number and “c” represents the link cost

Full size image

Ex. I.4 Let us consider an FTP data transfer (TCP “elephant” flow), referring to the network model depicted in Fig. 3.60. We adopt a scenario with IP packets (MTU) of 1,500 bytes, Information Bit-Rate (IBR) of the bottleneck link equal to 600 kbit/s and physical Round-Trip Time (RTT) equal to 0.5 s (GEO satellite scenario). It is requested to determine the Bandwidth-Delay Product (BDP) and plot the behaviors of both the congestion window (cwnd) and the slow start threshold (ssthresh) up to 25 RTTs for both TCP Tahoe and TCP NewReno, under the following conditions:

Fig. 3.60
figure 60

System model for the reliable transfer of data; case of an “elephant” TCP flow (FTP)

Full size image

  • Bottleneck link buffer capacity B = 20 pkts.

  • Sockets’ buffer size much larger than B + BDP.

  • Initial ssthresh value equal to 32 pkts.

Then, it is also requested to show the cwnd behaviors up to 25 RTTs for TCP Tahoe and TCP NewReno with initial ssthresh equal to 64 pkts: what are the differences with respect to the previous case?

Finally, assuming to be able to change the size of the buffer of the bottleneck link, let us determine its optimal size from the TCP throughput standpoint.

Ex. I.5 Let us refer to an FTP transfer (TCP “elephant” flow) on a network characterized by a Bandwidth-Delay Product (BDP) equal to 30 pkts. We are asked to plot cwnd and ssthresh behaviors up to 40 RTTs in the TCP NewReno case under the following conditions:

  • Bottleneck link buffer with capacity B = 10 pkts.

  • Sockets’ buffer size much larger than B + BDP.

  • Initial ssthresh value equal to 16 pkts.

Ex. I.6 Let us consider a TCP-based traffic flow with the cwnd behavior shown in Fig. 3.61 (the unit of time in abscissa is RTT). Assuming that this cwnd behavior is for the TCP Reno version, it is requested to answer the following questions:

Fig. 3.61
figure 61

Cwnd behavior for TCP Reno

Full size image

  • Identify where slow start and congestion avoidance phases are used in the graph.

  • After time 34 RTTs, is the segment loss revealed by three DUPACKs or by an RTO expiration?

  • What is the initial ssthresh value? And what is the ssthresh value after time 34 RTTs?

  • If we know that the bottleneck link buffer has a capacity of 30 pkts, what is the value of the Bandwidth-Delay-Product (BDP)?

  • When is the 63-th TCP segment sent? (RTT interval)

Ex. I.7 Let us consider a network adopting IntServ-Guaranteed Service as quality of service technique. We have a traffic source with fluid-flow model accessing the network. The traffic source is regulated according to the following T-Spec parameters: (r, p, b) = (1 kbit/s, 4 kbit/s, 500 bits) [1 token = 1 bit]. Following the arrival curve approach, it is requested to determine the minimum service rate R to guarantee a delay lower than or equal to Δmax = 150 ms (let us neglect propagation delays).

Ex. I.8 Referring to the IPv4 address 128.15.10.5, it is requested to determine:

  • The class of the IPv4 address and the corresponding network address.

  • The most efficient subnet mask for a subnet with 58 hosts.

  • An example of IPv4 address of the above subnet.

Ex. I.9 It requested to determine the classes of the following IPv4 addresses:

  1. (a)

    126.12.1.5

  2. (b)

    198.15.1.7

How many host addresses are available in the networks corresponding to cases (a) and (b)?

Ex. I.10 Let us consider the ON-OFF periodic traffic source (fluid-flow model) that is feeding a leaky bucket traffic regulator as shown in Fig. 3.62. Let r denote the rate of the source in the ON state. Let R denote the output rate of the regulator. We assume r ≥ R. It is requested to determine: (1) the stability condition; (2) the input traffic burstiness; (3) the maximum buffer occupancy; (4) the maximum delay imposed on the traffic by the leaky bucket regulator; (5) the behavior of the regulator buffer occupancy; (6) the output traffic behavior.

Fig. 3.62
figure 62

Periodic ON-OFF traffic source at the input of a leaky bucket regulator

Full size image

Rights and permissions

Reprints and permissions

Copyright information

© 2014 Springer Science+Business Media New York

About this chapter

Cite this chapter

Giambene, G. (2014). IP-Based Networks and Future Trends. In: Queuing Theory and Telecommunications. Springer, Boston, MA. https://doi.org/10.1007/978-1-4614-4084-0_3

Download citation

  • DOI: https://doi.org/10.1007/978-1-4614-4084-0_3

  • Published:

  • Publisher Name: Springer, Boston, MA

  • Print ISBN: 978-1-4614-4083-3

  • Online ISBN: 978-1-4614-4084-0

  • eBook Packages: EngineeringEngineering (R0)

Publish with us

Policies and ethics

Search

Navigation