Network Layer Computer Science Engineering (CSE) Notes | EduRev

Computer Networks

Computer Science Engineering (CSE) : Network Layer Computer Science Engineering (CSE) Notes | EduRev

The document Network Layer Computer Science Engineering (CSE) Notes | EduRev is a part of the Computer Science Engineering (CSE) Course Computer Networks.
All you need of Computer Science Engineering (CSE) at this link: Computer Science Engineering (CSE)


  • provide logical communication between app processes running on different hosts
  • transport protocols run in end systems
    • send side: breaks app messages into segments, passes to network layer
    • rcv side: reassembles segments into messages, passes to app layer
  • more than one transport protocol available to apps
    • Internet: TCP and UDP
  • network layer: logical communication between hosts
  • transport layer: logical communication between processes relies on, enhances, network layer services  reliable, in-order delivery (TCP) congestion control (distributed control)
    • flow control
    • connection setup
  • unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP services not available:
    • delay guarantees

    • bandwidth guarantees


“no frills,” “bare bones” Internet transport protocol  best effort” service, UDP segments may be:

  • lost
  • delivered out of order to app  



  • no handshaking between UDP sender, receiver
  • each UDP segment handled independently of others
  • no connection establishment (which can add delay)
  • simple: no connection state at sender, receiver
  • small segment header
  • no congestion control: UDP can blast away as fast as desired  

often used for streaming multimedia apps

  • loss tolerant
  • rate sensitive

other UDP uses

  • DNS
  • SNMP

reliable transfer over UDP: add reliability at application layer

  •  application-specific error recovery!


Network Layer Computer Science Engineering (CSE) Notes | EduRev



  • one sender, one receiver  reliable, in-order byte steam: 
  • no “message boundaries” 


  • TCP congestion and flow control set window size send & receive buffers


Network Layer Computer Science Engineering (CSE) Notes | EduRev

full duplex data:

  • bi-directional data flow in same connection
  • MSS: maximum segment size


  • handshaking (exchange of control msgs) init’s sender, receiver state before data exchange

flow controlled: sender will not overwhelm receiver

3.1.TCP segment structure


Network Layer Computer Science Engineering (CSE) Notes | EduRev

3.2. TCP seq. #’s and ACKs


Seq. #’s: byte stream “number” of first byte in segment’s data

ACKs: seq # of next byte expected from other side cumulative ACK

how receiver handles out-of-order segments. TCP spec doesn’t say, - up to implementor longer than RTT. but RTT varies

too short: premature timeout unnecessary retransmissions

too long: slow reaction to segment loss

SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions

SampleRTT will vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT TCP Round Trip Time and Timeout EstimatedRTT = (1-a )*EstimatedRTT +a *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast typical value: a =0.125



  • informally: “too many sources sending too much data too fast for network to handle” different from flow control!
  • manifestations:
    • lost packets (buffer overflow at routers)
    • long delays (queueing in router buffers)
  • a top-10 problem!

Causes/costs of congestion: scenario 1

  • two senders, two receivers
  • one router, infinite buffers
  • no retransmission

Causes/costs of congestion: scenario 2

  • one router, finite buffers
  • sender retransmission of lost packet
  • always: (goodput)
  • “perfect” retransmission only when loss: retransmission of delayed (not lost) packet makes larger (than perfect case) for same
  • “costs” of congestion: more work (retrans) for given “goodput” unneeded retransmissions: link carries multiple copies of pkt

Causes/costs of congestion: scenario 3

  • four senders multihop paths timeout/retransmit
  • Another “cost” of congestion: when packet dropped, any “upstream transmission capacity used for that packet was wasted!. Approaches towards congestion control End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems
    • single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)
    • explicit rate sender
Offer running on EduRev: Apply code STAYHOME200 to get INR 200 off on our premium plan EduRev Infinity!

Related Searches

study material


Sample Paper


Network Layer Computer Science Engineering (CSE) Notes | EduRev


Extra Questions


Network Layer Computer Science Engineering (CSE) Notes | EduRev


Semester Notes


past year papers


Network Layer Computer Science Engineering (CSE) Notes | EduRev












Objective type Questions


practice quizzes


Viva Questions


video lectures


Important questions




shortcuts and tricks


mock tests for examination


Previous Year Questions with Solutions