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

[Jon Crowcroft]

as discussed in the note which i referenced :

icmp advisories are sent to the receiver who knows how to turn them around - this
is no more silly than (say) ecn.

icmp errors can be sent, but icmp in routers would have to parse the TCP sna option
((it has to include the header in the icmp error any how so a bit of parsing in
what is always on the slow path anyhow, is not a big burden)
since most of these  ICMP response are meant as a response to a transport entity, 
this is semantically reasoanble.

your move.



In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed:

 >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 >>--------------enigFDD94A1CA6B765ED0E2F3126
 >>Content-Type: text/plain; charset=windows-1252; format=flowed
 >>Content-Transfer-Encoding: quoted-printable
 >>
 >>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.
 
 >>
 >>--
 >>
 >>You assert that:
 >>
 >>> Remember this (RFC 791)? Let=92s 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=3DISO-8859-1; format=3Dflowed
 >>>  >>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., ICM=
 >>Ps). =3D
 >>>  >>
 >>>  >>  Not all errors signal the transport layer; some signal the network=
 >>=3D20
 >>>  >>layer (e.g., too-big, redirect, etc.)
 >>>  >>
 >>>  >>PS - burying them in the TCP header eats option space from TCP, whic=
 >>h=3D20
 >>>  >>isn't exactly in abundance either ;-)
 >>>  >>
 >>>  >>Joe
 >>>  >>
 >>>  >>
 >>>  >>--------------enig163A833E39F238C5F60A48CF
 >>>  >>Content-Type: application/pgp-signature; name=3D"signature.asc"
 >>>  >>Content-Description: OpenPGP digital signature
 >>>  >>Content-Disposition: attachment; filename=3D"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=3D
 >>>  >>=3Do5Lq
 >>>  >>-----END PGP SIGNATURE-----
 >>>  >>
 >>>  >>--------------enig163A833E39F238C5F60A48CF--
 >>> 
 >>>  cheers