The Internetworking Problem.....

Hello friends,
In this artical i will discuss internetworking problem.As we all know internet become a main part of everyone's life.Without it we suffer much in today.As a mca student it become my soul.What problem face by us during networking.I am here to discuss that major problem.

Problem:- How to interconnect different networks together?
Look into IP, TCP, end-to-end issues.

The Internetworking Problem. Many different networks.

Link heterogeneity issue. Single-link LANs do not scale well over hundreds of miles distances. LAN switching for unknown destination implies broadcasting, a poor scheme in large nets.

Link technology: LANs, point-to-point, Packet radio, wireless, satellites. An extremely heterogeneous community.

Challenge: Design a scalable network infrastructure that connects different types of smaller networks enabling packet flows between hosts across different nets.

Issues to reckon:

■ Addressing: Each net may have its own addressing approach. Ethernet uses 6-byte ID, Telephone uses 10-digit numbers.

Gateways:
Primarily a protocol converter. It interfaces distinct networks with different characteristics.

Two types: Translation GW, and Unified Network Layer.

Translation-based Gateways: translates packet headers and protocol from one network to another seamlessly.
Problems:

a. Feature deficiency: Not all features are “preserved” as one moves from one net to another. Not all features are supported by the translation.
b. Poor scalability: Translation = where is the number of networks connected. Untenable at large networks

Internet Design principles:

Identify key parameters (a small number) which must be preserved through translation. All hosts and networks must implement them. Check the seminal paper: “End-to-end arguments” http://www.reed.com/Papers/EndtoEnd.html


Universality principles:

U1. IP-over-everything. A standard network protocol IP would be used as Internet Protocol. Must have a standard well-defined addressing convention. Then scaling is not an issue.

U2. Best-effort service model. All packets are treated alike, if any gets lost address this at the end, not inside the network to recover it. (Increases scalbility and throughput)
U3. End-to-end arguments. Keeps the interior of the network as simple as possible. Move all controls for reliability, congestion control etc. at the end-hosts. TCP functionality removed from Gateways.

Robustness principle:

R1. Soft-state inside the network. Refresh soft-states such as Router tables as often as possible. Thus, even if it gets lost once in a while, it’s no big deal.

R2. Fate sharing. Even if a GW crashes, the end-to-end communication must continue. The GW state is a soft-state, and it shouldn’t share its fate with end-hosts.

R3. Conservative-transmission/Liberal reception. Be conservative in what you send, be liberal in what you receive. What does a TCP sender do when it sees an ACK for a message it didn’t expect?



Weaknesses:-

Internet architecture has its own weaknesses.

■ Architecture relies heavily on the trustworthiness of end-systems. How does one build a trusted networks when hosts (or a subset of them) couldn’t be trusted?
■ Greedy sources aren’t handled well. TCP does a good job in sharing its bandwidth, but more and more traffic isn’t TCP
■ Security issues have been neglected
■ Administration and management tools are not all that matured
■ Incremental deployment. Not a fundamental problem, but ought to be recognized by every protocol designer.




■ Bandwidth and Latency: Link bandwidth would vary from net to net from bits/sec to Gb/sec. Latencies can be from μs to several secs.

■ Packet size: In general varies between networks
■ Loss rates & QoS: All networks vary considerably in these. These depend on traffic volume, congestion, service demands, …
■ Packet routing: Routing of packets may be handled differently by different nets.

The original TCP/IP (Cerf & Kahn).

■ Key idea. Gateways. Reject translation in favor of gateways.

■ IP over everything.
■ Standard packet header format
■ Gateways perform fragmentation, reassembly at end-hosts
■ TCP: Process-level communication via TCP, a reliable, in-order, byte-stream protocol. Original TCP did reassembly; now it’s done at the receiver. TCP and IP were tightly interwined originally, now they are separate.
■ How to launch/sustain/deliver multiple TCP between two processes? Original design didn’t consider this.
1. Use same IP packet for multiple TCP segments?
2. Use different IP packets for different segments?
■ 2 is simpler than 1. It’s easier to demux and out-of-order packets are difficult to handle in 1. Demux key is the port number of the receiving process.
■ Sliding window, cumulative ACK-based ARQ protocol.
■ Window-based flow control
■ Heavily dependent on connection setup and release scheme.
■Way off the mark on accounting issues
■One line summary