Subject: TCP/IP Terms

From: "Bill Cunningham" <[email-masked]>
Date: Sat, 28 Sep 2002 19:57:32 -0400

The terms can be TCP/IP layer dependant. For example,  rfc 1122 says a
datagram is a "connectionless protocol" if I'm correct. Fine. UDP is at
transport layer, IP and ICMP is at Internet layer. IP is called datagram.
This can get confusing. Of course there is potential in defining layer
dependant terms of getting confusing as well. Terms like packet and datagram
can become more inclusive, in an official way to be layer dependant
according to TCP/IP.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 30 Sep 2002 08:09:09 -0700

Bill,

This slide is confusing, for sure. The reason I posted the link was the
comparison between the OSI and the TCP/IP models.

Michel.

> From: Bill Cunningham [mailto:[email-masked]]
> http://dast.nlanr.net/Training/DCWJuly99/kai_tcpip/sld008.htm
> I looked at this page of one of the links you sent me. Notice
> at the Internet and Transport levels it simply says, Application
> data (datagram ?), TCP header, could this be a datagram, or
> maybe a packet. Then at the Internet level, application data,
> TCP header and IP header. Now according to rfc 1122, we know that -
> o application data, tcp header
> o application data, tcp header, and ip header.
> Are both datagrams. Wow IMHO what a mix up. Unless you know the
> name of the protocol and where you know (or think) it is in
> TCP/IP, you're lost.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 30 Sep 2002 10:34:13 -0700

> I'd actually much prefer for OSI to win the "war of the definitions".
> Rigid definitions tend to constrain thinking to fit into the patterns
> defined.   We're much better off just having a rough idea what things
> mean when it gets to this level.

While the concept of layering is fine (more or less), the specific
layers adopted in the OSI model have only a moderate relation with
actual practice, and are a poor fit for the Internet architecture.
Specifically:

1) OSI's modeling of the lower layers was driven by the need to
accommodate X.25 split between physical transmission, HDLC/LAP-B, and
virtual circuits. This does not describe well the situation in the
Internet, in which IP is often layered on top of what OSI considers a
network layer, e.g. X.25 or ATM; the same problem arose when attempting
to layer CLNP on top of these networks; this led to Byzantine
discussions of sub-layers 3a, 3b and 3c. 

2) OSI's modeling of the upper layers was driven by the need to
accommodate the Teletex application, which used a pass-through transport
(class zero) and required a "session" layer to handle check-pointing and
restart. In the real world, check-pointing and other synchronization
tasks are performed a layer above marshalling and un-marshalling, i.e.
above the presentation layer. Again, OSI's response to the reality check
has been a Byzantine decomposition of the application layer into
"application service elements" that would what we usually understand as
"session control". 

The main problem with OSI is that they drew the layers in 1980, i.e.
before the client server architectures based on RPC stabilized, before
we gained experience with internetworking. The TCP-IP architecture
choice of having an internet layer on top of a subnet layer, and single
layer for the application were, at the time, much more practical. They
withstood time much better.

-- Christian Huitema

---

From: "Brian Bisaillon" <[email-masked]>
Date: Mon, 30 Sep 2002 11:10:57 -0400

In the four-layer model, "Application" encompasses "Layer 7", "Layer 6", and "Layer 5" from the seven-layer OSI model.

I always considered TCP headers or IP headers as data formats that make up the overall protocol. They have to be processed. Therefore, they are essentially "application data".

Anyway, it gets confusing when you start trying to differentiate between what is an algorithm, what is a data format, what is a file format, and what is a protocol. The terms should be a lot clearer. For instance, some people think algorithms and protocols are the same. Other people think data formats and protocols are the same. Additionally, some people have trouble differentiating between what is a data format and a file format. Does data format mean the data is generated on-the-fly whereas a file format is a static file? In the logical sense, something like XML still has to be processed so to me it's just another data format but if you think of it in its "statically and physically stored" sense it's a file format. Mind boggling... :-)

Brian B.

>>> "Bill Cunningham" <[email-masked]> 09/30/02 12:34AM >>>

    I looked at this page of one of the links you sent me. Notice at the
Internet and Transport levels it simply says, Application data (datagram ?),
TCP header, could this be a datagram, or maybe a packet. Then at the
Internet level, application data, TCP header and IP header. Now according to
rfc 1122, we know that -
 o application data, tcp header
 o application data, tcp header, and ip header.

Are both datagrams. Wow IMHO what a mix up. Unless you know the name of the
protocol and where you know (or think) it is in TCP/IP, you're lost.

-
This message was passed through [email-masked], which
is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

---

From: "Chris Evans" <[email-masked]>
Date: Mon, 30 Sep 2002 17:03:48 -0700

Thanks man.. that clear up confusion on PPP ! 

>mentioned before PPP is an example written since rfc 1122-23. It is 
>now its
>own suite, with a family of link and network control protocols.
>
>