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

[Joe Touch]

Jon Crowcroft wrote:
> 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.

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.

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, 
why not for forwarding?

...
> since most of these  ICMP response are meant as a response to a transport 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.

Joe

> 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

-------------- 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/7fe349f3/signature-0001.bin