[e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/
touch at ISI.EDU
Fri Jul 11 07:33:14 PDT 2008
You asked why the Internet had source addresses. I provided an answer,
based on my understanding of the historical context for the decision. I
apologize for being too terse for that to be clear, or for being too
glib to belie a thoughful consideration of the contents of your paper.
That, however, does not mean that I did not read your paper.
My response of your (IMO, historical) question has nothing to do with
your proposal for removing them, as is discussed below.
Jon Crowcroft wrote:
> a perfect example of people responding to email that they haven't
> actually read properly
I urge posters to read the mail they *write* as well as those others
post. ;-) Please read my more detailed note below before concluding how
properly I've read your work.
You assert that:
> Remember this (RFC 791)? Let’s think about the line marked
> by Xs. So why is there a source address there? The naive answer
> is that some receivers might want to reply.
That is a historically consistent answer.
> It’s a Datagram,
> Stupid. Not all higher layers want to send something back! The
> end-to-end argument says that we do not put a function in a lower
> layer, unless it is required by the majority of upper layer users
E2E argument allows designers to "put things in a layer that THAT layer
Later, your doc says that:
> a better place to send advisory
> information in the future Internet is onwards to the receiver, not
> backwards to the sender. Obviously the unreachable cases need
> to be considered more carefully, although if an end system is not
> reachable, a SNA-RK might be still reachable.
Host and net unreachables can't be fixed at all, as you note later.
Other messages require the receiver know the source, which - if this is
one of those higher layers that doesn't want to send something back -
won't happen either.
The fact that further discussion asserts that error notifications were
always a bad idea I find naive as well. And MTU discovery will NEVER
happen if the receiver has no notion of who the sender is.
> In missive <48768425.4000801 at isi.edu>, Joe Touch typed:
> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>Content-Transfer-Encoding: quoted-printable
> >>Jon Crowcroft wrote:
> >>> speaking of sacred cows,
> >>> why are their source addresses in IP Packets?
> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf
> >>The same reason letters have return addresses; for errors (e.g., ICMPs). =
> >> Not all errors signal the transport layer; some signal the network=20
> >>layer (e.g., too-big, redirect, etc.)
> >>PS - burying them in the TCP header eats option space from TCP, which=20
> >>isn't exactly in abundance either ;-)
> >>Content-Type: application/pgp-signature; name="signature.asc"
> >>Content-Description: OpenPGP digital signature
> >>Content-Disposition: attachment; filename="signature.asc"
> >>-----BEGIN PGP SIGNATURE-----
> >>Version: GnuPG v1.4.7 (MingW32)
> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >>-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/02b22e29/signature.bin
More information about the end2end-interest