IP layer

[nonlinear]

Hi I present a piece of text from the book "TCP/IP Illustrated, Volume 1" by Richard Stevens that I do not understand (page 33): "...IP provides an unreliable,connectionless datagram delivery service. By unreliable we mean there are no guarantees that an IP datagram successfully gets to its destination. IP provides a best effort service. When something goes wrong...IP has a simple error handling algorithm: throw away the datagram and try to send an ICMP message back to the source. Any required reliability mut be provided by the upper layers (e.g. TCP)"
Hey, if IP layer is not reliable then what is mean "IP provides a best effort service." From what I see THERE IS an error handling!!!!
Thanks

 

[LawnBoy]

IP datagrams are also known as UDP. By "best effort" they mean that the sending party does what it can, but does not resend a bad packet. A UDP packet is not tracked; it is simply transmitted. If the receiving party does not get the packet, the sender has no way of knowing and just sends the next packet in the sequence.

Don't confuse IP datagrams (UDP) with TCP. TCP has an error tracking system built-in; if the receiver doesn't get a packet it asks the sender to transmit that same packet again. UDP does not do this.


--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.

 

[nonlinear]

... If the receiving party does not get the packet, the sender has no way of knowing..."
I thing that the book say different thing "When something goes wrong, such as a router temporarily running out of buffers,IP has a simple error handling algorithm: throw away the datagram and try to send an ICMP message back to the source".
Therefore there is a way of knowing that the packet did not get!

 

[jimbopalmer]

Only if the ICMP error packet makes back to the sender. If the UDP data packet don't make it, it is sadly likely the ICMP control packets don't either.

I tried to remain child-like, all I acheived was childish.

 

[LawnBoy]

You are correct that the book says something different. To the best of my knowledge, it is incorrect. I do not find any mention of that in RFC 768, (

http://www.ietf.org/rfc/rfc768.txt)

nor do I find any mention of it in a quick 20 minute search on the internet.

According to the RFC, there is no field in the datagram to state a sequence number. So you cannot, for example, say that this is datagram 6 out of a total of 10; each datagram is an entity unto itself and does not refer to any other related datagram (the data contained within the datagram could, but this error checking would be handled by the application, not the protocol).

Let's look at a couple of scenarios.

1: The receiving party gets a malformed or "bad" datagram. It could then send an ICMP request back to the sender (even though the RFC does not say to) but it would be of no use whatsoever. The sender would have no way of knowing that the ICMP packet is related to any datagrams that have been sent, nor which particular datagram it is in response to. Indeed, the receiver could have sent the ICMP from a totally unrelated application and port, for a totally unrelated reason.

2: The receiving party misses a datagram. Since there is no time frame in which to expect the datagram, and there is no sequence number in the datagram, the receiver does not know that it missed anything. It sits and waits for the next datagram to come along, whenever that might be.

I hate to argue with a published author, but I see no reference to the mechanism he describes. If anyone can show me differently, I welcome the opportunity to become better educated on the subject.

--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.

 

[nonlinear]

Ok LawnBoy,thanks for your response but I have some notices:
1. this book suppose to be of the best in the TCP/IP area. It is the must for those who want to learn about TCP/IP or at least was at one time. I believe that I misunderstand something.
2. You speak about UDP protocol not IP. IP communicate not only with UDP on an upper layer but also with TCP. We talk about IP protocol and its unreliability. If this unreliability continued in the upper layer then we talk about UDP else we talk about TCP.
I known, anyway, that IP protocol is unreliable but I was surprised by this sentence in the book and for this reason I looked for a TCP/IP forum.

 

[burtsbees]

You want a better TCP/IP book? Get Routing TCP/IP Volume I and II, by Cisco Press. I'd trust a CCIE over your book any day...

Burt

 

[LawnBoy]

Hmmm. I've been laboring under the false impression that "IP datagram" and "UDP" were synonymous. I see I was wrong, please diregard my previous posts as I was talking about UDP, not IP.

I did find this, perhaps it can help to answer your question.

http://www.tcpipguide.com/free/t_IPOverviewandKeyOperationalCharacteristics.htm

--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.

 

[burtsbees]

Lawn---I believe you are correct in assuming that IP datagram is UDP, though the misnomer being that IP is layer 3, and UDP is layer 4. The word datagram does suggest UDP (User Datagram Protocol).

Burt

 

[LawnBoy]

Not according to what I learned yesterday. An IP datagram is not UDP, it is the underlying frame used by UDP, TCP, ICMP, etc.

UDP doesn't really add anything to the IP frame so the terms appear synonymous, but technically they are not. As you say, IP is layer 3 and UDP is layer 4.

I'm finding

http://www.tcpipguide.com

to be an excellent reference.


--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.

 

[CiscoGuy33]

Lawnboy,

You are correct with your correction

IP sits at Layer 3 and is an unreliable,connectionless datagram delivery service, it relies on the Transport layer (layer 4) for a reliable connection using TCP or if a reliable connection is NOT needed then UDP is used at Layer 4.

That is why TCP/IP works - the TCP protocal keeps track of what did not get there and puts it back in order by sequence numbers.

Wow, I have not done my TCP/IP lecture in about 2 years - I need to dust off my Power Points!


E.A. Broda
CCNA, CCDA, CCAI, Network +