Do fragments have the same length field as the original datagram?

This turned out to be a much harder question to answer than initially
assumed.  I believe the answer is that fragments have their length
values adjusted to reflect the length of the fragment itself. I base
this on the following obervations:
a) each fragment is a self-contained datagram
b) the reassembly code on page 259 seems to suggest that the
   length is associated with the fragment
c) if you look at the ip_output function from
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c?rev=1.178&content-type=text/x-cvsweb-markup
   you see the following sequences of code:
	len = (ifp->if_mtu - hlen) &~ 7;
	if (len < 8) {
		error = EMSGSIZE;
		goto bad;
	}
[...]
		*mhip = *ip;
[...]
		if (off + len >= (u_short)ip->ip_len)
			len = (u_short)ip->ip_len - off;
		else
			mhip->ip_off |= IP_MF;
		mhip->ip_len = htons((u_short)(len + mhlen));

What this shows is that the new length is being calculated as the MTU
size of the interface in question less the size of the IP header.
Later on, the original IP header is being copied into the new fragment.
Finally, we check if this fragment is the final fragment. If so, it's
actual length is calculated, and if not, the 'M' flag (indicating more
fragments) is set.

So, if each fragment has a length that applies to that fragment and
specifies its offset from the original datagram, then you may wonder
what's the need for the 'M' bit that indicates whether or not this
datagram is the end of the fragment. The answer is that by definition,
fragmentation is supposed to be transparent to any layers above IP.
If the 'M' flag didn't exist, you wouldn't know when it was
appropriate to send the datagram up to the higher levels.



What was the size hint business on the AAL 3/4 slide?

It seems that the size hint is just a hint, not an approximation to
account for the padding. On page 205 of the book, it's explained that
the actual length may not be known at the time the header is being
sent, so that's why you have the hint. The actual length is at the
end, by which time the send has to know it. The padding is there to
ensure proper alignment of the trailer.



With all this coverage of ATM, are you saying that ATM is better than
(and more widely used than) datagrams?

ATM is important in the sense that it was a widely-deployed high-speed
system with provisions for quality of service and was used both for
voice and data. The phone companies still have this in their
backbones, for legacy and political reasons if nothing else. So, a
complete networkin course has to have some coverage of it. It's also
the case that it's connection-oriented and had to solve some problems
that are likely to arise in any connection-oriented service without an
easy broadcast channel. Omitting it would likely lead to forgetting
it, and then having people reinvent the wheel.



We've got really small amounts of feedback

This one's mine, and it's just an observation. What I noticed from
teaching 318 was that when the amount of feedback dropped, it was
highly correlated to people not keeping up with the readings and
lectures. So, I'd encourage you have more feedback, not for the sake
of the feedback, but also because it means that we're all on the same
track. If someone's got a better idea, I'm open to suggestions.