Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

ELEMENTS OF TRANSPORT PROTOCOLS

No description
by

Shashank Kumar

on 23 April 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of ELEMENTS OF TRANSPORT PROTOCOLS

ELEMENTS OF TRANSPORT PROTOCOLS
Contents
Network Layer vs Transport Layer
Data Link Layer vs Transport Layer
Elements of Transport Layer.
Addressing
Connection Establishment
Connection Release
Connection Establishment
To establish a connection, you send off a connection request to the other end
The other end then accepts the connection, and returns an acknowledgment.
Problem
: Suppose you don’t get an answer, so you do another request.
Your first request didn’t make it .(no harm done)
The ACK didn’t make it back.(you’re establishing a second connection, but this can probably be detected)
Your first request didn’t make it
YET
.(now you’re really making a second connection and no one knows you didn’t do this on purpose.
How to handle...
One way is to use throwaway transport addresses. In this approach, each time a transport address is needed, a new one is generated. Delayed duplicate packets then never find their way to a transport process and can do no damage.

Use connection identifier (a sequence number) and keep a list of obsolete connections after they are released. Whenever a CR comes in, it can be checked with the list to see if it belongs to a previously released connection.
Require to keep the history for infinite amount of time.
When a router crashes, all history will be lost.
How to handle...
Restrict the lifetime of TPDUs
if the maximum lifetime is known in advance, we can be sure that a previous packet is discarded and that it won’t interfere with successive ones Three possible solutions:
(a) Restricted subnet design
(b) Putting a hop counter in each packet
(c) Timestamping each packet (requires global clock synchronization)
To make sure that not only data packets but even their acknowledgements are dead, a multiple of true maximum lifetime is used instead.

Basic idea: With packet lifetimes bounded, assign sequence numbers to TPDUs, and let the sequence number space be so large that no two outstanding TPDUs can have the same number. Duplicates of this packet may still occur but it is no longer the case that a delayed duplicate of an old packet may beat a new packet with the same sequence number and be accepted by the
destination in its stead.
Problem
: When a host crashes, it has to start numbering TPDUs again. So, where does it start?
You can’t just wait the maximum packet lifetime T and start counting from the start again: in wide-area systems, T may be too large to do that.
The point is that you must avoid that an
initial
sequence number corresponds to a TPDU still floating around. ⇒
So, just find the right initial number
Tomlinson’s method
Tomlinson’s method
Each host is equipped with a TOD clock which is assumed to be running even when the router crashes. Clocks at different hosts need not be synchronized.
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).
The sequence numbers are incremented and put into subsequent TPDUs (for the same connection) independent of the clock.

Tomlinson’s method
Then, the host crashes and comes up immediately again.
At t=60, 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.

Fig . Linear relation between time and initial sequence numbers (thick line)
Now ,consider the following scenario:
At t = t1, a connection is established with connection-5 (previously opened) and ISN = t1, 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. (Here T=60sec)
We should NOT have assigned the sequence number 80 to X. 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.

SOLUTION:
Recovery after a crash
When sequence numbers are assigned at a lower pace than the clock ticks, we may enter the region “from the top.”
Likewise, assigning them too fast makes you enter the region “from the bottom”
Recovery after a crash
Problem
: Great, we have a way of avoiding duplicates, but how do we get a connection in the first place?
One way or the other we have to get the sender and receiver to agree on initial sequence numbers.
We need to avoid that an old (unnumbered) connection request pops up.
Solution
: Three-way handshake.
Host 1 chooses a sequence number, x, and sends a CONNECTION REQUEST TPDU containing it to host 2.
Host 2 replies with an ACK TPDU acknowledging x and announcing its own initial sequence number, y.
Finally, host 1 acknowledges host 2’s choice of an initial sequence number in the first data TPDU that it sends


Three-way handshake
Three-way handshake
Normal operation
Old CONNECTION REQUEST appearing out of nowhere
Duplicate CONNECTION REQUEST and duplicate ACK
Network Layer vs Transport Layer
Similarities
Both provide services CO/CL to the higher layer.
Both perform congestion control
Differences
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.
Transport layer ensures that the protocols operated at this layer provide reliable end-to-end flow and error control whereas the network layer controls routing of data from source to destination plus the building and dismantling data packets.

Data Link Layer vs Transport Layer
Similarities
Error Control
Flow Control
Sequencing
Differences
In DLL, two routers communicate directly through a physical link. In TL, the two transport entities communicate through the entire subnet.
Explicit addressing of the destination.
Storage capacity of subnet.

When an application (e.g., a user) process wishes to set up a connection to a remote application process, it must specify which one to connect to.
The method normally used is to define transport addresses to which processes can listen for connection requests.
TSAP (Transport Service Access Point) means a specific endpoint in the transport layer like ports .
The analogous endpoints in the network layer are called NSAPs (Network Service Access Points). IP addresses are examples of NSAPs.

Addressing
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 .
AP asks for the Time-of the Day
Server responds with the TOD
Connection is released.
Transport Layer Addresses : TSAP
How do we get to know where the other party is?
Well known servers use well known ports . for ex. ports & servers defined in /etc/services file on UNIX .
How about the servers which are rarely used? Letting a server listen whole day to a fixed TSAP is wasteful.
Solution: Initial Connection Protocol , have a single process, located at a well-known address, handle a large number of services (process server). In UNIX world it is called inetd .
Sometimes you just can’t have a process handle all services, e.g. because the service requires special hardware
Solution: have to use a name server.

Issues & Solutions
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 process server which acts as proxy. Then this proxy spawns the requested server inheriting all the properties of the connection.
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. Then we can use name server.


Process Server
Initial Connection Protocol
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.
Name server responds back.
Connection with the name server 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 name server together with its TSAP.


Name Server
references
thank

you

by:
rohan jain

(ue148080)
shahshank kr. singh
(ue148087)
shikhar verma

(ue148088)
Connection Release
Asymmetric
: It is the way the telephone system works when one party hangs up, the connection is broken. It is sudden and unexpected, may result in loss of data.

Symmetric
: It treats the connection as two separate unidirectional connections and requires each one to be released separately.
Asymmetric Release
After the connection is established, host 1 sends a TPDU that arrives properly at host 2. Then host 1 sends another TPDU. Unfortunately, host 2 issues a DISCONNECT before the second TPDU arrives. The result is that the connection is released and data are lost.

symmetric Release
In this method, each direction is released independently of the other one. Here, a host can continue to receive data even after it has sent a DISCONNECT TPDU.
Symmetric release is useful when each process has a fixed amount of data to send and clearly knows when it has sent it.
It works on a protocol in which, host 1 says: I am done. Are you done too? If host 2 responds: I am done too. Goodbye, the connection can be safely released.

Two-army problem
If either blue army attacks by itself, it will be defeated, but if the two blue armies attack simultaneously, they will be victorious.
Their only communication medium is to send messengers into the valley, where they might be captured and the message may lost

Two-army problem
It can be proven that no protocol to synchronize the attack exists neither of the two commanders can be certain that the other one has received the message, as either the last message or the acknowledgement may be lost.
As we know last message is essential, so if it is lost, the attack does not take place. Since the sender of the final message can never be sure of its arrival, he will not risk attacking. Worse yet, the other blue army knows this, so it will not attack either.
In practice, one is usually prepared to take more risks when releasing connections than when attacking white armies, so the situation is not entirely hopeless. This leads to four scenarios of releasing connection using a three-way handshake. While this protocol is not infallible, it is usually adequate.

Four scenarios of Releasing Connection
In the normal case one of the users sends a DR (Disconnection Request) TPDU to initiate the connection release. When it arrives, the recipient sends back a DR TPDU, too, and starts a timer, just in case its DR is lost. When this DR arrives, the original sender sends back an ACK TPDU and releases the connection. Finally, when the ACK TPDU arrives, the receiver also releases the connection.
If the final ACK TPDU is lost, the situation is saved by the timer. When the timer expires, the connection is released anyway.
Four scenarios of Releasing Connection
Now consider the case of the second DR being lost. The user initiating the disconnection will not receive the expected response, will time out, and will start all over again. We can see how this works, assuming that the second time no TPDUs are lost and all TPDUs are delivered correctly and on time.
Our last scenario is the same as third scenario except that now we assume all the repeated attempts to retransmit the DR also fail due to lost TPDUs. After N retries, the sender just gives up and releases the connection. Meanwhile, the receiver times out and also exits.

PROBLEM:
This protocol can fail if the initial DR and N retransmissions are all lost. The sender will give up and release the connection, while the other side knows nothing at all about the attempts to disconnect and is still fully active. This situation results in a half-open connection.

SOLUTION:
One way to kill off half-open connections is to have a rule saying that if no TPDUs have arrived for a certain number of seconds, the connection is then automatically disconnected. That way, if one side ever disconnects, the other side will detect the lack of activity and also disconnect. If this rule is introduced, it is necessary for each transport entity to have a timer that is stopped and then restarted whenever a TPDU is sent. If this timer expires, a dummy TPDU is transmitted, just to keep the other side from disconnecting. On the other hand, if the automatic disconnect rule is used and too many dummy TPDUs in a row are lost on an otherwise idle connection, first one side, then the other side will automatically disconnect.
CONNECTION RELEASE

Computer Networks (5th Edition) by Andrew S. Tanenbaum

Computer Networks-Transport Layer by Paolo Costa(Vrije University Amsterdam)
Full transcript