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

[Jon Crowcroft]

In missive <487772B1.8090302 at isi.edu>, Joe Touch typed:

 >>Consider a packet whose transport lacks a destination address
 >>altogether, as you note should be possible. Receivers of those packets
 >>have no way to turn them around.
 
 >>> icmp errors can be sent, but icmp in routers would have to parse the TCP sna option

 >>So basically the need for the *network* layer to signal the source is
 >>accommodated in packets using the TCP sna option by layer violation.

ICMP is layered on top of ip as is tcp - icmp talking to tcp is not a layer
violation.

by the way, i dont put an _address_ in the transport - i put an identifier - this
is then used receivers to lookup an address to the originator. i _might_ put a
routing hint (e.g. a care of adddress) in the transport too - this is  
not the same as putting in an actual address (which i am getting rid of as it is
invalid MOST of the time...
 
 >>Moving the source address in that case didn't make it go away, so that's
 >>just shuffling the deck chairs. If you wanted more space for IP, it's
 >>just as logical to leave the current IP header alone and place the extra 
 >>forwarding info in the TCP header - if you're violating layers for ICMP, =

this is either a semantic quibble or confusing.

1. i havnt changed the IP header ast aal - i 've changed the meaning of a field -
thishas some very nice legacy interworking properties (as noted in my note)

as above, I am not violating layers. not as i understand their functions.
 
 >>why not for forwarding?
 >>> since most of these  ICMP response are meant as a response to a transpo=
 >>rt entity,
 >>> this is semantically reasoanble.
 >>
 >>Your system posits transports might not ever need source addresses.
 >>Those transports no longer benefit from ICMP information from the network=
 >
 indeed since there is no information theoretic or control theoertic reason they
should want fedback from the net if thewy didnt want it from the end. - i am just 
bringing some consistency to a design error of the internet.
 >>
 >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed:
 >>>=20
 >>>  >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 >>>  >>--------------enigFDD94A1CA6B765ED0E2F3126
 >>>  >>Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed
 >>>  >>Content-Transfer-Encoding: quoted-printable
 >>>  >>
 >>>  >>Jon,
 >>>  >>
 >>>  >>You asked why the Internet had source addresses. I provided an answe=
 >>r,=20
 >>>  >>based on my understanding of the historical context for the decision=
 >>=2E I=20
 >>>  >>apologize for being too terse for that to be clear, or for being too=
 >>=20
 >>>  >>glib to belie a thoughful consideration of the contents of your pape=
 >>r.
 >>>  >>
 >>>  >>That, however, does not mean that I did not read your paper.
 >>>  >>
 >>>  >>My response of your (IMO, historical) question has nothing to do wit=
 >>h=20
 >>>  >>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=
 >>=20
 >>>  >>post. ;-)  Please read my more detailed note below before concluding=
 >> how=20
 >>>  >>properly I've read your work.
 >>> =20
 >>>  >>
 >>>  >>--
 >>>  >>
 >>>  >>You assert that:
 >>>  >>
 >>>  >>> Remember this (RFC 791)? Let=3D92s 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 la=
 >>yer
 >>>  >>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=20
 >>>  >>one of those higher layers that doesn't want to send something back =
 >>-=20
 >>>  >>won't happen either.
 >>>  >>
 >>>  >>The fact that further discussion asserts that error notifications we=
 >>re=20
 >>>  >>always a bad idea I find naive as well. And MTU discovery will NEVER=
 >>=20
 >>>  >>happen if the receiver has no notion of who the sender is.
 >>>  >>
 >>>  >>---
 >>>  >>
 >>>  >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed:
 >>>  >>>=20
 >>>  >>>  >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 >>>  >>>  >>--------------enig163A833E39F238C5F60A48CF
 >>>  >>>  >>Content-Type: text/plain; charset=3D3DISO-8859-1; format=3D3Dfl=
 >>owed
 >>>  >>>  >>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=3D
 >>>  >>Ps). =3D3D
 >>>  >>>  >>
 >>>  >>>  >>  Not all errors signal the transport layer; some signal the ne=
 >>twork=3D
 >>>  >>=3D3D20
 >>>  >>>  >>layer (e.g., too-big, redirect, etc.)
 >>>  >>>  >>
 >>>  >>>  >>PS - burying them in the TCP header eats option space from TCP,=
 >> whic=3D
 >>>  >>h=3D3D20
 >>>  >>>  >>isn't exactly in abundance either ;-)
 >>>  >>>  >>
 >>>  >>>  >>Joe
 >>>  >>>  >>
 >>>  >>>  >>
 >>>  >>>  >>--------------enig163A833E39F238C5F60A48CF
 >>>  >>>  >>Content-Type: application/pgp-signature; name=3D3D"signature.as=
 >>c"
 >>>  >>>  >>Content-Description: OpenPGP digital signature
 >>>  >>>  >>Content-Disposition: attachment; filename=3D3D"signature.asc"
 >>>  >>>  >>
 >>>  >>>  >>-----BEGIN PGP SIGNATURE-----
 >>>  >>>  >>Version: GnuPG v1.4.7 (MingW32)
 >>>  >>>  >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 >>>  >>>  >>
 >>>  >>>  >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9O=
 >>k
 >>>  >>>  >>W8nN+CrIaW3+dENfI/qDyaw=3D3D
 >>>  >>>  >>=3D3Do5Lq
 >>>  >>>  >>-----END PGP SIGNATURE-----
 >>>  >>>  >>
 >>>  >>>  >>--------------enig163A833E39F238C5F60A48CF--
 >>>  >>>=20
 >>>  >>>  cheers
 >>
 >>
 >>--------------enig841B4237908E688C7D411F39
 >>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
 >>
 >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8Y
 >>mhEpJZ+jr+qMgMXMe3xEFtQ=
 >>=xV8K
 >>-----END PGP SIGNATURE-----
 >>
 >>--------------enig841B4237908E688C7D411F39--

 cheers

   jon