I notice that the field in question. total packet length or total
datagram length.

is described in RFC 791 as
Total Datagram Length AND measured in octets.

I saw found a zip file for the kurose book, which has some example
packets involving fragmentation. I loaded them into Ethereal.

The field in question, was clearly
Total Packet Length (not datagram length).

Also, in those packets in the Kurose example, and in any other packets
to and from the internet, it's measured in bytes.

I guess it's alwaysm easured in byes and the RFC is overruled by what
has become practice.

But, is it always Packet Length and not Datagram length? If people
write TCP/IP implementations that mix that up, couldn't there be
serious problems ?
Surely this change from RFC 791 must be documented !

(I guess if it is , it is in richard stevens or perhaps comer too. I
should get those books)

But is that orrect.
That it's packet not datagram?. (this is only significant when
fragmentation occurs)

And of course, bytes not octets

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

q_q_anonymous@yahoo.co.uk wrote:
> I notice that the field in question. total packet length or total
> datagram length.
>
> is described in RFC 791 as
> Total Datagram Length AND measured in octets.
>
> I saw found a zip file for the kurose book, which has some example
> packets involving fragmentation. I loaded them into Ethereal.
>
> The field in question, was clearly
> Total Packet Length (not datagram length).
>
> Also, in those packets in the Kurose example, and in any other packets
> to and from the internet, it's measured in bytes.

To the untrained eye, bytes and octets are the same.

Octets are explicit groups of 8 bits
Bytes are groups of bits, but not always groups of 8 bits.

Over the years (especially in the last 15-20 years), "byte" has become
synonymous with "octet" in the common tongue.

> I guess it's alwaysm easured in byes and the RFC is overruled by what
> has become practice.

No. It is always measured in octets, and the RFC is enforced. That, to
you, octets and bytes are the same size is immaterial to the RFC or the
implementation.

[snip]



- --

Lew Pitcher, IT Specialist, Corporate Technology Solutions,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEThspagVFX4UWr64RArRRAJ9d+HFHGZZmOYNukUabyJ tgA5g86QCePYL1
jQFUrGjy10TVQyZal86gik8=
=xjb0
-----END PGP SIGNATURE-----

q_q_anonymous@yahoo.co.uk wrote:
> I notice that the field in question. total packet length or total
> datagram length.
>
> is described in RFC 791 as
> Total Datagram Length AND measured in octets.
>
> I saw found a zip file for the kurose book, which has some example
> packets involving fragmentation. I loaded them into Ethereal.
>
> The field in question, was clearly
> Total Packet Length (not datagram length).
>

RFC 791 seems to be using datagram interchangeably with your (and my)
notion of 'packet'. Also from 791:

To fragment a long internet datagram, an internet protocol
module (for example, in a gateway), creates two new internet
datagrams

I believe this is where the confusion comes from. Substitute 'packet'
for 'datagram' in the text we've both cited and the meaning would be
clear.

In the case of, say, a large UDP datagram in a to-be-fragmented IP
packet, the router performing fragmentation certainly isn't creating
two new UDP datagrams. There's still one UDP datagram, and it spans
the two new IP packets.

You're right that this is confusing terminology, and in conflict with
popular usage. Cisco Press, for example equates 'datagram' with
'L4PDU'.

> Also, in those packets in the Kurose example, and in any other packets
> to and from the internet, it's measured in bytes.
> I guess it's alwaysm easured in byes and the RFC is overruled by what
> has become practice.

'Octet' is an octet of _bits_. An octet of bits is a byte. No problem
there.

/chris marget

googlegroups@marget.com wrote:
> q_q_anonymous@yahoo.co.uk wrote:
> > I notice that the field in question. total packet length or total
> > datagram length.
> >
> > is described in RFC 791 as
> > Total Datagram Length AND measured in octets.
> >
> > I saw found a zip file for the kurose book, which has some example
> > packets involving fragmentation. I loaded them into Ethereal.
> >
> > The field in question, was clearly
> > Total Packet Length (not datagram length).
> >
>
> RFC 791 seems to be using datagram interchangeably with your (and my)
> notion of 'packet'. Also from 791:
>
> To fragment a long internet datagram, an internet protocol
> module (for example, in a gateway), creates two new internet
> datagrams
>
> I believe this is where the confusion comes from. Substitute 'packet'
> for 'datagram' in the text we've both cited and the meaning would be
> clear.


great, thanks, .

It's a shame that some texts pick the one definition over the other and
bang away at it as if the other definition doesn't exist.

Unfortunately, the book "internet core protocols" by eric hall, makes
it seem like a datagram is strictly the original packet that is
reassembled at the destination, and so he says fragmentation identifier
is really a datagram identifier.

>
> In the case of, say, a large UDP datagram in a to-be-fragmented IP
> packet, the router performing fragmentation certainly isn't creating
> two new UDP datagrams. There's still one UDP datagram, and it spans
> the two new IP packets.
>
> You're right that this is confusing terminology, and in conflict with
> popular usage. Cisco Press, for example equates 'datagram' with
> 'L4PDU'.

interesting, I can't find that. do you know what book/page.
In CCNA Intro (with 2005 updates) by Odom, ISBN 1-58720-094-5
P.30
he calls L4PDU a segment (most accurate).

That book corresponds with "The TCP/IP Guide" which says that datagram
when unqualified is IP Datagram- layer 3. But if qualified it can refer
to L4 Datagram. e.g. TCP datagram, UDP datagram.
http://www.tcpipguide.com/free/t_Mes...andCells-2.htm




> > Also, in those packets in the Kurose example, and in any other packets
> > to and from the internet, it's measured in bytes.
> > I guess it's alwaysm easured in byes and the RFC is overruled by what
> > has become practice.
>
> 'Octet' is an octet of _bits_. An octet of bits is a byte. No problem
> there.
>
> /chris marget

yep, a silly mistake on my part.

Fragmentation offset is 13-bit and uses group of 8 *bytes*. so
8192*8=65536
(65536 being max total packet length , and max (original) datagram size
)
(I guess the original datagram shouldn't be bigger than a packet 'cos
internal/local fragmentation is unnecessary)
Shame there's no name for a group of 8 bytes/octets

q_q_anonymous@yahoo.co.uk wrote:
> googlegroups@marget.com wrote:

> > You're right that this is confusing terminology, and in conflict with
> > popular usage. Cisco Press, for example equates 'datagram' with
> > 'L4PDU'.
>
> interesting, I can't find that. do you know what book/page.
> In CCNA Intro (with 2005 updates) by Odom, ISBN 1-58720-094-5
> P.30
> he calls L4PDU a segment (most accurate).

My mistake. I didn't have any book in front of me at the moment, but
'L4PDU==segment' is probably what I was thinking of.

> > > Also, in those packets in the Kurose example, and in any other packets
> > > to and from the internet, it's measured in bytes.
> > > I guess it's alwaysm easured in byes and the RFC is overruled by what
> > > has become practice.
> >
> > 'Octet' is an octet of _bits_. An octet of bits is a byte. No problem
> > there.

> yep, a silly mistake on my part.
>
> Fragmentation offset is 13-bit and uses group of 8 *bytes*. so
> 8192*8=65536
> (65536 being max total packet length , and max (original) datagram size
> )

I'd guessed you interpreted unqualified 'octet' as 8 bytes. Very
understandable when you've got 8 byte bounded fragmentation on the
brain.

> (I guess the original datagram shouldn't be bigger than a packet 'cos
> internal/local fragmentation is unnecessary)

Not necessarily true. When layer 4 is doing the segmentation on its
own accord (TCP) then you're right. OTOH, I don't think there's
anything to stop an application from sending a >MTU UDP datagram down
to IP, forcing IP to fragment the (cough :-) packet before it leaves
the sending system.

/chris marget

Lew Pitcher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> q_q_anonymous@yahoo.co.uk wrote:
> > I notice that the field in question. total packet length or total
> > datagram length.
> >
> > is described in RFC 791 as
> > Total Datagram Length AND measured in octets.
> >
> > I saw found a zip file for the kurose book, which has some example
> > packets involving fragmentation. I loaded them into Ethereal.
> >
> > The field in question, was clearly
> > Total Packet Length (not datagram length).
> >
> > Also, in those packets in the Kurose example, and in any other packets
> > to and from the internet, it's measured in bytes.
>
> To the untrained eye, bytes and octets are the same.
>
> Octets are explicit groups of 8 bits
> Bytes are groups of bits, but not always groups of 8 bits.
>
> Over the years (especially in the last 15-20 years), "byte" has become
> synonymous with "octet" in the common tongue.

interesting, I wasn't aware of that.

> > I guess it's alwaysm easured in byes and the RFC is overruled by what
> > has become practice.
>
> No. It is always measured in octets, and the RFC is enforced. That, to
> you, octets and bytes are the same size is immaterial to the RFC or the
> implementation.
>
> [snip]
>

yep, my mistake.

thanks