The design principles of the Internet protocols assume that the network infrastr ucture is inherently unreliable at any

single network element or transmission me dium and that it is dynamic in terms of availability of links and nodes. No cent ral monitoring or performance measurement facility exists that tracks or maintai ns the state of the network. For the benefit of reducing network complexity, the intelligence in the network is purposely mostly located in the end nodes of eac h data transmission, cf. end-to-end principle. Routers in the transmission path simply forward packets to the next known local gateway matching the routing pref ix for the destination address. As a consequence of this design, the Internet Protocol only provides best effort delivery and its service can also be characterized as unreliable. In network ar chitectural language it is a connection-less protocol, in contrast to so-called connection-oriented modes of transmission. The lack of reliability allows any of the following fault events to occur: data corruption lost data packets duplicate arrival out-of-order packet delivery; meaning, if packet 'A' is sent before packet 'B', packet 'B' may arrive before packet 'A'. Since routing is dynamic and there is n o memory in the network about the path of prior packets, it is possible that the first packet sent takes a longer path to its destination. The only assistance that the Internet Protocol provides in Version 4 (IPv4) is t o ensure that the IP packet header is error-free through computation of a checks um at the routing nodes. This has the side-effect of discarding packets with bad headers on the spot. In this case no notification is required to be sent to eit her end node, although a facility exists in the Internet Control Message Protoco l (ICMP) to do so. IPv6, on the other hand, has abandoned the use of IP header checksums for the be nefit of rapid forwarding through routing elements in the network. The resolution or correction of any of these reliability issues is the responsib ility of an upper layer protocol. For example, to ensure in-order delivery the u pper layer may have to cache data until it can be passed to the application. In addition to issues of reliability, this dynamic nature and the diversity of t he Internet and its components provide no guarantee that any particular path is actually capable of, or suitable for, performing the data transmission requested , even if the path is available and reliable. One of the technical constraints i s the size of data packets allowed on a given link. An application must assure t hat it uses proper transmission characteristics. Some of this responsibility lie s also in the upper layer protocols between application and IP. Facilities exist to examine the maximum transmission unit (MTU) size of the local link, as well as for the entire projected path to the destination when using IPv6. The IPv4 in ternetworking layer has the capability to automatically fragment the original da tagram into smaller units for transmission. In this case, IP does provide re-ord ering of fragments delivered out-of-order.[1]

User Datagram Protocol is a connectionless datagram protocol. Like IP, it is a b est effort, "unreliable" protocol. Reliability is addressed through error detect ion using a weak checksum algorithm. UDP is typically used for applications such as streaming media (audio, video, Voice over IP etc) where on-time arrival is m ore important than reliability, or for simple query/response applications like D NS lookups, where the overhead of setting up a reliable connection is disproport ionately large. Real-time Transport Protocol (RTP) is a datagram protocol that i s designed for real-time data such as streaming audio and video. TCP and UDP are used to carry an assortment of higher-level applications. The ap propriate transport protocol is chosen based on the higher-layer protocol applic ation. For example, the File Transfer Protocol expects a reliable connection, bu t the Network File System (NFS) assumes that the subordinate Remote Procedure Ca ll protocol, not transport, will guarantee reliable transfer. Other applications

, such as VoIP, can tolerate some loss of packets, but not the reordering or del ay that could be caused by retransmission. The applications at any given network address are distinguished by their TCP or UDP port. By convention certain well known ports are associated with specific ap plications. (See List of TCP and UDP port numbers.) [edit]Application Layer The Application Layer refers to the higher-level protocols used by most applicat ions for network communication. Examples of application layer protocols include the File Transfer Protocol (FTP) and the Simple Mail Transfer Protocol (SMTP)[10 ]. Data coded according to application layer protocols are then encapsulated int o one or (occasionally) more transport layer protocols (such as the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)), which in turn use lowe r layer protocols to effect actual data transfer. Since the IP stack defines no layers between the application and transport layer s, the application layer must include any protocols that act like the OSI's pres entation and session layer protocols. This is usually done through libraries. Application Layer protocols generally treat the transport layer (and lower) prot ocols as "black boxes" which provide a stable network connection across which to communicate, although the applications are usually aware of key qualities of th e transport layer connection such as the end point IP addresses and port numbers . As noted above, layers are not necessarily clearly defined in the Internet pro tocol suite. Application layer protocols are most often associated with client ser ver applications, and the commoner servers have specific ports assigned to them by the IANA: HTTP has port 80; Telnet has port 23; etc. Clients, on the other ha nd, tend to use ephemeral ports, i.e. port numbers assigned at random from a ran ge set aside for the purpose. Transport and lower level layers are largely unconcerned with the specifics of a pplication layer protocols. Routers and switches do not typically "look inside" the encapsulated traffic to see what kind of application protocol it represents, rather they just provide a conduit for it. However, some firewall and bandwidth throttling applications do try to determine what's inside, as with the Resource Reservation Protocol (RSVP). It's also sometimes necessary for Network Address Translation (NAT) facilities to take account of the needs of particular applicat ion layer protocols. (NAT allows hosts on private networks to communicate with t he outside world via a single visible IP address using port forwarding, and is a n almost ubiquitous feature of modern domestic broadband routers).