Transport Layer

1
Transport Layer
2
Context of various layers upto Network layer

• NL present in LAN and subnet
• MAC sublayer not present in Subnets, only in
  LANs
• DLL present in LAN and subnet

3
Context of various layers

• Transport Layer Peer (a transport entity, a
  process in TL, in a host H1) to Peer (a transport
  entity, a process in TL, in a host H2).
• Network Layer End (IP address of H1) to End (IP
  address of H2).
• DLL Local, (DLL address of) router to (DLL
  address of) router in subnet or host to router on
  a LAN.

4
Context of various layers contd

• DLL node to node and not source to destination
• MAC address also node to node and not source to
  destination
• NL Though addressing is source to destination
  but responsibilities are node to node

5
DLL revisited

• Services offered by the DLL may be CO or CL
• Implementation of CO in DLL is done with the help
  of frame sequence numbers
• DLL handles errors due to transmission only I.e.
  due to the physical errors..bits damaged etc

6
Services offered by the DLL may or may not be
reliable

• When the medium is reliable or the system is real
  time where fast response is more important than
  correct data for eg. Voice DLL should be kept
  light and reliability if required must be added
  in higher layers
• When the medium is unreliable and it is more
  important that data is never lost than the
  response time, it may be worth adding reliable
  services(ACKs) in the DLL

7
NL revisted

• CL service Internet community They say that
  subnet is inherently unreliable and hence
  reliability, error control, flow control must be
  done by the destination host anyway, and hence
  there is no need of doing that in the NL (and
  hence at every router).
• CO service Telephone Companies

8
Implementation of CO in NL

• Is done with Virtual Circuit Numbers between H1
  and H2.
• Now suppose there are two processes (transport
  entity) on H1 wanting to establish connection
  with one or two processes on H2. NL may establish
  separate connections or use a common connection
  between H1 and H2 for the two applications.

9
Contd..

• Now consider the following scenario
• Suppose a network entity is informed halfway
  halfway through a long transmission that its
  network connection has been abruptly terminated
  (router crash or link down etc).
• TL entity can set up a new connection to the
  remote TL entity and ask upto what point it
  received and start from thereon.
• This cannot be done at the NL since the NL cannot
  distinguish between the two TL connections
  because it was using the same virtual circuit for
  both.

10
The Transport Layer

• Truly Peer to peer layer.
• Services provided in TL are similar to those
  provided in the NL and DLL together.

11
Why do we need the Transport Layer

• To take care of the issues which were not taken
  care of, by the lower layers.
• Or, one could say, a final check.

12
Why Transport Layer?

• Since the protocols are developed independent of
  the protocols in the lower layers, It handles all
  the things
• CO
• Reliability by adding Acks, even if Acks were
  added at the DLL we still need them here as at
  DLL only frames damaged due to transmission
  errors are resent. However, packets may be
  dropped for other reasons such as congestion etc.
  If this is not taken care of at the NL, which is
  most often the case, then it must be done at the
  transport layer.
• Error-control
• Flow-control
• Congestion-control

13
Elements of Transport Protocols

• Addressing
• Connection Establishment
• Connection Release
• Flow Control and Buffering
• Multiplexing
• Crash Recovery

14
Differences between NL and TL

• Real Networks can loose packets and NL may not
  make an attempt to recover or retransmit the lost
  packets. Whereas TL services are meant to be
  reliable.
• One of the main objective of TL provide a
  reliable service on top of unreliable network.
• Users Users of NL services are TL entities and
  not an end user whereas the users of TL services
  are the programmers writing applications, hence
  TL entity must be convenient and easy to use.

15
Similarities between NL and TL

• Both provide services CO/CL to the higher layer.
• Both perform congestion control

16
Similarities between DLL and TL

• TL services resemble more with that of the DLL
• Error Control
• Flow Control
• Sequencing etc

17
Differences between DLL and TL

• Due to the dissimilarities between the
  environment they operate inIn DLL, two routers
  communicate directly through a physical link. In
  TL, the two transport entities communicate
  through the entire subnet. Thus the life is
  greatly simplified in case of DLL as compared to
  that in TL.

18
Differences contd..

• In DLL, each outgoing line uniquely identifies
  the destination router, no explicit addressing is
  required whereas in TL explicit addressing of the
  destination is required.
• Initial connection establishment is more
  complicated in TL.
• In DLL, a packet is either delivered or lost. But
  at TL, a packet may go around in the subnet, be
  stored in some router for some time and emerge
  later.

19
Differences contd..

• Buffering and Flow Control In DLL, buffer space
  is allocated with each line. The number of lines
  a router is connected is small and constant.
  Having dedicating buffers with each VC at the TL
  is not feasible as the number of VCs is too large.

20
TL addresses TSAP (Transport Service Access
Point)

• A server 1(say Time of Day) on host 2 attaches
  itself to TSAP 1522 to continuously listen for an
  incoming request. This attachment is done by a
  system call by the OS.
• An application process on Host 1 attaches itself
  to an available TSAP say 1208 and issues a
  CONNECT request specifying source TSAP as 1208
  and destination TSAP as 1522.
• When Server 1 receives this request, connection
  is established eventually (well discuss later).
• AP asks for the Time-of the Day
• Server responds with the TOD
• Connection is released.

21
Addressing

• .

TSAPs, NSAPs and transport connections
22
TSAP

• There may be other servers on Host 2 attached to
  a different TSAP waiting for an incoming request.

23
Issues in Addressing

• How does the client know the TSAP (Transport
  Service access point) I.e. the port used by the
  server
• Well known servers use well known ports defined
  in /etc/services file on UNIX for eg.
• Initial Connection Protocol Process Server
  (attached to a well known TSAP)
• Name Server (attached to a well known TSAP)
  Provides TSAP of the required service/server.

24
Some well known assigned ports
Port
Protocol
Use
21
FTP
File transfer
23
Remote login
Telnet
E-mail
25
SMTP
69
Trivial File Transfer Protocol
TFTP
Finger
Lookup info about a user
79
80
World Wide Web
HTTP
POP-3
110
Remote e-mail access
USENET news
119
NNTP
Back
25
Issues contd..

• Stable and Standardized TSAPs are used for some
  frequently used servers.
• How about the servers which are rarely used?
• Letting a server listen whole day to a fixed TSAP
  is wasteful.
• Solution proxy server listening to multiple
  TSAPs at the same time.

26
Proxy Server

• A client sends a request specifying the TSAP of
  the required service. But finds no one waiting at
  that TSAP, the request is handed over to the
  proxy server. The proxy server spawns the
  requested server inheriting all the properties of
  the connection.
• Problem TSAP of the service required is still
  required to be known and works fine only for
  those services which can be created as and when
  required like TOD server.
• Solution Name Server

27
Initial Connection Protocol

• How a user process in host 1 establishes a
  connection with a time-of-day server in host 2.

28
Name Server

• Client connects itself to a name server on host
  2. Name Server works on a well known TSAP.
• It requests the name server to provide the TSAP
  of the required service.
• NS responds back.
• Connection with the NS is released and a new
  connection with the required server is set up.
• Needless to say, when a new service comes up it
  must register itself with the NS together with
  its TSAP.

29
Connection Establishment

• Establish connection
• Transfer Data
• Release Connection

30
Issues in Connection Establishment

• Packets may be lost or may be duplicated or may
  roam around and emerge later
• Consider the following scenario
• Connection Request
• Transfer data (say banking, say some amount to
  some account)
• Connection Release
• Suppose all the packets duplicate, roam around
  and emerge again after the connection is
  released the connection will be re-established,
  data transferred again and again released.

31
How to handle

• Use connection identifier (a sequence number) and
  keep a list of obsolete connections after they
  are released.Not good to keep the history for
  infinite amount of time, also what happens when a
  router crashes.. All history will be lost.
• Kill off ageing packets Keep a packet life
  time.
• Hop count or,
• Time Stamp requires global synchronization of
  clock
• Unfortunately, none of them is fool proof.

32
Packet Lifetime

• To make sure that not only data packets but even
  their acknowledgements are lost, a multiple of
  true lifetime is used instead.

33
Tomlinsons method

• Each host is equipped with a TOD clock which is
  assumed to be running even when the router
  crashes. No problem in this assumption, a
  battery-operated clock which gets charged up when
  powered.
• Clocks at different hosts need not be
  synchronized.

34
Tomlinsons Method contd..

• The clock is actually a binary counter which is
  incremented at uniform intervals.
• The number of bits in the binary counter must be
  greater or equal than the number of bits in the
  sequence number.
• When a connection is established, the low-order k
  bits of the clock are used as the initial
  sequence number and put into the TPDU (connection
  request).
• Once the initial sequence number is fixed any
  sliding window protocol can be used to control
  the flow of data.
• The sequence numbers are incremented and put into
  subsequent TPDUs (for the same connection)
  independent of the clock.

35
TM contd..

• Now we want to ensure that two TPDUs numbered
  identically are not outstanding at the same time.
  
• If the sequence space is large enough that by the
  time seq no.s wrap around, old TPDUs with the
  same seq. no. are long gone, problem occurs only
  due to crashes.

36
Recovery after a crash

• Consider the following scenario
• At t t0, a connection is established with
  connection identifier 5 and ISN t0, more TPDUs
  are generated for this connection and,
• At t 30 a sequence number say 80 is generated
  and put into a TPDU for the same connection, call
  this TPDU X.
• Then, the host crashes and comes up immediately
  again.
• At t60, it starts establishing connections 0-4.
• At t 70, it establishes a new connection 5, with
  ISN 70 and within next 15 sec, it sends TPDUs
  numbered 70-80.
• Thus a new TPDU with CI 5 and SN 80 has been
  created, call it Y.
• If X arrives at the receiver before Y, X may be
  accepted as original and Y may be rejected as
  duplicate..problem

37
Solution

• We should not have assigned the sequence number
  80 to X. We should have waited for an appropriate
  amount of time before assigning 80 to X.
• i.e. If we are about to assign a sequence number
  say 80 to a TPDU say x, when there are chances
  that in a near future (before the life time of x
  say T) 80 may be assigned as ISN, then we should
  wait. This wait period is called the forbidden
  region for a sequence number.

38
An example

• For example, let at t 30, host wants to send a
  TPDU x with CI 5 and SN 90.
• Suppose T 60 then the TPDU with desired SN can
  be generated but if
• It was to be generated at t 31, it cannot be,
  it will have to wait until t 91.
• i.e. a sequences s should not be generated in the
  time period s-T to s.

39
Another Example

• Let at t 30, host wants to send a TPDU x with
  CI 5 and SN 31.
• It waits until t 32.

40
Connection Establishment (2)

• (a) TPDUs may not enter the forbidden region.
• (b) The resynchronization problem.

41

• Note that if at t20, host wants to send a TPDU
  with SN 80. It can send.

42
What about the control packets?

• Once the two parties agree on the ISN, this
  method works fine?
• What if the control packets like CONNECTION
  REQUEST get delayed.

43
Possible Scenario

• a delayed duplicate packet of a CR by host1
  proposing an ISN comes up.
• CA by host2 accepting the request.
• Connection will be setup incorrectly.

44
Three way handshake for Connection Establishment
Three protocol scenarios for establishing a
connection using a three-way handshake. CR
denotes CONNECTION REQUEST. (a) Normal
operation, (b) Old CONNECTION REQUEST appearing
out of nowhere. (c) Duplicate CONNECTION
REQUEST and duplicate ACK.
45
Connection Release

• Asymmetric Telephone System, may result in loss
  of data.
• Symmetric treats the connection as two
  unidirectional connections and each must be
  closed separately.

46
Connection Release

• Abrupt disconnection with loss of data.

47
Connection Release (2)

• The two-army problem.

48
Connection Release (3)

• Four protocol scenarios for releasing a
  connection. (a) Normal case of a three-way
  handshake. (b) final ACK lost.

6-14, a, b
49
Connection Release (4)

• (c) Response lost. (d) Response lost and
  subsequent DRs lost.

6-14, c,d
50
Flow control and buffering

• Difference between DLL and TL
• In TL, too many connections, dedicated buffers
  for each connection is not a very good idea.
• Buffers at sender vs at receiver
• If the network service is unreliable, sender must
  keep the unacked TPDUs in the buffer.
• If the network service is reliable(acked
  packets), several tradeoffs are possible.

51
An Important (side) Note

• In a reliable network, if the receiver guarantees
  enough buffer space to accept every incoming
  TPDU, sender need not buffer the unacked TPDUs
  (remember reliable network).
• Else, sender must. It cannot rely on the acked
  service of the network for that only means that
  packet arrived safely (and accepted) at the NL of
  the receiver but whether TL has enough space to
  buffer the TPDU or not is not guaranteed.

52
Tradeoffs in a reliable network
(a) Chained fixed-size buffers. (b) Chained
variable-sized buffers. (c) One large circular
buffer per connection.
53
Tradeoffs in a reliable network

• Fixed size buffers what should be the size?
• Variable size buffers better memory utilization
  but complicated buffer management
• One large circular buffer per connection good if
  all connections are heavily loaded but poor
  otherwise.
• In practice, a combination might be used
  depending upon the application.

54
Tradeoffs between buffering at sender and at
receiver

• Low bandwidth bursty application like interactive
  terminal,
• having dedicated buffers is not a good idea,
  buffers must be acquired dynamically.
• Hence, buffer space at the receiver is not
  guaranteed, therefore sender must keep.
• High bandwidth traffic like file transfer
• Receiver must dedicate buffers to allow smooth
  and fast flow of data.
• Hence, sender need not keep.

55
Negotiating buffer space in CR

• As connections are opened and closed, and the
  traffic pattern changes, sender and receiver must
  be able to adjust their buffer allocation
  dynamically.
• TP should allow the sender to request for buffer
  space at the receiver in CR,
• And the receiver to inform the sender as to how
  much buffer space it has for the sender, say in
  CA.

56
(No Transcript)
57
COO service in TL Transport Service Primitives

• The primitives for a simple transport service.

58

• Server is continuously LISTENing.
• Client sends a CONNECT request.
• Server is unblocked and accepts the request.
• Exchange data using SEND and RECEIVE.
• DISCONNECT could be symmetric or asymmetric.

59
DISCONNECT

• Symmetric Each side is closed separately. When
  one side issues a DISCONNECT, it means it has no
  more data to send but it can accept more data.
  The other side can continue to send data and
  issues a separate DISCONNECT when it is done.
• Asymmetric Any side can issue a DISCONNECT and
  the connection is released when it arrives at the
  other end.

60
TPDU Transport Protocol Data Unit

• The nesting of TPDUs, packets, and frames.

61
Transport Service Primitives (3)
A state diagram for a simple connection
management scheme. Transitions labeled in
italics are caused by packet arrivals. The solid
lines show the client's state sequence. The
dashed lines show the server's state sequence.
62
Berkeley Sockets

• The socket primitives for TCP.

63
Socket Programming ExampleInternet File Server
6-6-1

• Client code using sockets.

64
Socket Programming ExampleInternet File Server
(2)

• Client code using sockets.

65
Issues in Connection Release

• Asymmetric Release One party disconnects as in
  telephone system and the connection is released
  . May lead to data loss
• Symmetric Release If fixed amount of data then
  fine else problem

66
Connection Release

• Abrupt disconnection with loss of data.

67
Connection Release

• Four protocol scenarios for releasing a
  connection. (a) Normal case of a three-way
  handshake. (b) final ACK lost.

6-14, a, b
68
Connection Release

• (c) Response lost. (d) Response lost and
  subsequent DRs lost.

6-14, c,d
69
Connection Release

• What if the initial DR and all subsequent tries
  are lost sender releases the connection but
  receiver stays connected results in half-open
  connection
• Use timer If no TPDUs arrive for a certain
  amount of time then disconnect

70
Flow Control and Buffering

• In DLL, Sliding window (buffering) is kept at
  both the senders end as well as at the
  receivers end for each connection.
• However, in a router the number of lines is few
  whereas at TL, the number of connections is
  large.
• Thus keeping buffers with each connection may not
  be very memory efficient.

71
Flow Control and Buffering If subnet provides
datagram service

• Since subnet provides unreliable datagram, TL
  must acknowledge, hence sender has to keep the
  unacked TPDUs, I.e. has to buffer them.
• So buffering at the receiver need not be very
  efficient.. Say a common pool may be maintained
  for all the connections.
• When a TPDU arrives, if there is a room in the
  pool, it is accepted else discarded and
  retransmitted by the sender

72
Flow Control and Buffering subnet is reliable

• Other optimizations are possible receiver can
  agree to do the buffering.
• Assuming the receiver always have sufficient
  space, sender need not buffer and TPDUs are never
  discarded and hence retransmitted due to
  insufficient buffer space.

73
How to make sure that the receiver always has
enough space?

• Case a most TPDUs are of same size
• Case b variable-sized TPDUs chained together
  space efficient, buffer management is more
  complicated
• Case c single large chunk per connection
  works well if all connections are heavily loaded,
  but poor otherwise.

74
Flow Control and Buffering
(a) Chained fixed-size buffers. (b) Chained
variable-sized buffers. (c) One large circular
buffer per connection.
75
Source buffering Vs Destination buffering

• Low-bandwidth bursty traffic eg. Bursty traffic
  .. Buffer at senders end
• High-bandwidth smooth traffic eq. file transfer
  buffer at receivers end to allow the data to
  flow at maximum speed

76
Dynamic allocation of buffers

• As the traffic pattern changes, buffer allocation
  strategies must change.
• The TL Protocol thus should allow the sender to
  request buffer space at the receivers end.

77
Flow Control and Buffering

• .

78
Multiplexing

• Upward Multiplexing to reduce cost by
  multiplexing several TL connections on a single
  NL VC. Cost of NL VC is high as resources are
  reserved.
• Downward Multiplexing Improve throughput by
  multiplexing single TL connection on multiple NL
  throughput.
• There is a tradeoff between cost and throughput

79
Crash Recovery