[e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/
Joe Touch
touch at ISI.EDU
Fri Jul 11 08:10:09 PDT 2008
Jon (et al.),
Jon Crowcroft wrote:
> 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.
If you call ICMP a transport layer (fair enough), you haven't explained
why one transport should peek into the headers of another. ICMP can talk
to TCP, but having ICMP parse TCP headers would be layer violation IMO.
> 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...
Understood. That difference isn't key to my responses, so I've just
referred to it as an address, but didn't mean to confuse that issue.
> >>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)
Changing the meaning of a field changes the header. I.e., you can't pass
that packet through a legacy router usefully - it could generate ICMPs
to the wrong place, and won't interpret the source address field as an
extension of the destination address.
My view is that:
change IP src address to mean destination realm
add source identifier to TCP header (e.g., as an option)
is just as usefully accomplished as:
leave IP as-is
add destination realm to the TCP header (as an option)
(the only remaining difference is that your source identifier isn't the
same as IP's source address; I could just as easily put the source ID in
the TCP header too if you prefer).
Further, your paper and emails have not addressed the fact that TCP
headers don't exactly have lots of space - especially the SYN packet,
which is where the source identifier for a connection would need to be
established.
...
> >>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.
I agree that unidirectional packets don't necessarily need network
feedback. That implies:
1. that your entire supposition that the IP packet doesn't need a source
address because the transport layer is unacknowledged may be true, but
actually implies that all transport layers should be bidirectional
(rather than implying that you don't need a source address).
2. bidirectional packets need network address info in the network
header, because the network needs to respond to that information. if I
leave this to the transport layer, then every time I deploy a new
transport protocol (SCTP, DCCP, etc.), I need to recode all my routers
to know where to peek to get information for ICMP to respond to.
Again, as noted, many ICMP messages originate from the network, not the
end host. The need for source addresses in the header in the Internet is
to enable network-based error indicators. It's not clear at all why that
is something we can/should want to get rid of entirely.
Joe
> >>
> >>> 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
-------------- 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/255cfe61/signature.bin
More information about the end2end-interest
mailing list