[e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/

[Joe Touch]

Jon,

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.

Joe

--

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 
actually needs".

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)
>  >>--------------enig163A833E39F238C5F60A48CF
>  >>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 ;-)
>  >>
>  >>Joe
>  >>
>  >>
>  >>--------------enig163A833E39F238C5F60A48CF
>  >>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
>  >>
>  >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9Ok
>  >>W8nN+CrIaW3+dENfI/qDyaw=
>  >>=o5Lq
>  >>-----END PGP SIGNATURE-----
>  >>
>  >>--------------enig163A833E39F238C5F60A48CF--
> 
>  cheers
> 
>    jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/02b22e29/signature.bin