[e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Fri Jul 11 08:23:37 PDT 2008
you say i should put the realm info as a tcp option and then say there isnt
much space for tcp options.
i say sna does it in a way that is more flexible, doesnt need a lot of routers to
change just yet, and provides a lot of what people have done in mobile ipv6 (with
route optimisation) without the pain of turning on full internet wide v6 routing.
admittedly there's a little tweaking of some icmp code - this is not performance
critical and one could easily (as per shim6) do the transport/icmp interworking
cleanly across all transports
hosts already peak into ICMP errors to see for what Transport they might be useful;
i dont see why ICMP looking in transport to figure out
whether its useful to send something at all and to whome is any different
in terms of religions like "layer violation" and its a whole lot more efficient
In missive <487777D1.6090001 at isi.edu>, Joe Touch typed:
>>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>>--------------enigD0DFC0254F721440EFF890E4
>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>Content-Transfer-Encoding: quoted-printable
>>
>>Jon (et al.),
>>
>>Jon Crowcroft wrote:
>>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed:
>>>=20
>>> >>Consider a packet whose transport lacks a destination address
>>> >>altogether, as you note should be possible. Receivers of those packe=
>>ts
>>> >>have no way to turn them around.
>>> =20
>>> >>> icmp errors can be sent, but icmp in routers would have to parse t=
>>he TCP sna option
>>>=20
>>> >>So basically the need for the *network* layer to signal the source i=
>>s
>>> >>accommodated in packets using the TCP sna option by layer violation.=
>>
>>>=20
>>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is not a l=
>>ayer
>>> violation.
>>
>>If you call ICMP a transport layer (fair enough), you haven't explained=20
>>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 identif=
>>ier - 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=20
>>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 th=
>>at'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 e=
>>xtra=20
>>> >>forwarding info in the TCP header - if you're violating layers for I=
>>CMP, =3D
>>>=20
>>> this is either a semantic quibble or confusing.
>>>=20
>>> 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 n=
>>ote)
>>
>>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=20
>>to the wrong place, and won't interpret the source address field as an=20
>>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=20
>>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=20
>>headers don't exactly have lots of space - especially the SYN packet,=20
>>which is where the source identifier for a connection would need to be=20
>>established.
>>
>>=2E..
>>> >>why not for forwarding?
>>> >>> since most of these ICMP response are meant as a response to a tr=
>>anspo=3D
>>> >>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 ne=
>>twork=3D
>>>
>>> indeed since there is no information theoretic or control theoertic rea=
>>son they
>>> should want fedback from the net if thewy didnt want it from the end. -=
>> i am just=20
>>> bringing some consistency to a design error of the internet.
>>
>>I agree that unidirectional packets don't necessarily need network=20
>>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=20
>>actually implies that all transport layers should be bidirectional=20
>>(rather than implying that you don't need a source address).
>>
>>2. bidirectional packets need network address info in the network=20
>>header, because the network needs to respond to that information. if I=20
>>leave this to the transport layer, then every time I deploy a new=20
>>transport protocol (SCTP, DCCP, etc.), I need to recode all my routers=20
>>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=20
>>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:
>>> >>>=3D20
>>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126
>>> >>> >>Content-Type: text/plain; charset=3D3Dwindows-1252; format=3D3D=
>>flowed
>>> >>> >>Content-Transfer-Encoding: quoted-printable
>>> >>> >>
>>> >>> >>Jon,
>>> >>> >>
>>> >>> >>You asked why the Internet had source addresses. I provided an =
>>answe=3D
>>> >>r,=3D20
>>> >>> >>based on my understanding of the historical context for the dec=
>>ision=3D
>>> >>=3D2E I=3D20
>>> >>> >>apologize for being too terse for that to be clear, or for bein=
>>g too=3D
>>> >>=3D20
>>> >>> >>glib to belie a thoughful consideration of the contents of your=
>> pape=3D
>>> >>r.
>>> >>> >>
>>> >>> >>That, however, does not mean that I did not read your paper.
>>> >>> >>
>>> >>> >>My response of your (IMO, historical) question has nothing to d=
>>o wit=3D
>>> >>h=3D20
>>> >>> >>your proposal for removing them, as is discussed below.
>>> >>> >>
>>> >>> >>Jon Crowcroft wrote:
>>> >>> >> > a perfect example of people responding to email that they ha=
>>ven't=3D
>>> >>
>>> >>> >> > actually read properly
>>> >>> >>
>>> >>> >>I urge posters to read the mail they *write* as well as those o=
>>thers=3D
>>> >>=3D20
>>> >>> >>post. ;-) Please read my more detailed note below before concl=
>>uding=3D
>>> >> how=3D20
>>> >>> >>properly I've read your work.
>>> >>> =3D20
>>> >>> >>
>>> >>> >>--
>>> >>> >>
>>> >>> >>You assert that:
>>> >>> >>
>>> >>> >>> Remember this (RFC 791)? Let=3D3D92s think about the line mar=
>>ked
>>> >>> >>> by Xs. So why is there a source address there? The naive answ=
>>er
>>> >>> >>> 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! Th=
>>e
>>> >>> >>> end-to-end argument says that we do not put a function in a l=
>>ower
>>> >>> >>> layer, unless it is required by the majority of upper layer u=
>>sers
>>> >>> >>
>>> >>> >>E2E argument allows designers to "put things in a layer that TH=
>>AT la=3D
>>> >>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=3D
>>> >>
>>> >>> >>> 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 la=
>>ter. =3D
>>> >>
>>> >>> >>Other messages require the receiver know the source, which - if=
>> this=3D
>>> >> is=3D20
>>> >>> >>one of those higher layers that doesn't want to send something =
>>back =3D
>>> >>-=3D20
>>> >>> >>won't happen either.
>>> >>> >>
>>> >>> >>The fact that further discussion asserts that error notificatio=
>>ns we=3D
>>> >>re=3D20
>>> >>> >>always a bad idea I find naive as well. And MTU discovery will =
>>NEVER=3D
>>> >>=3D20
>>> >>> >>happen if the receiver has no notion of who the sender is.
>>> >>> >>
>>> >>> >>---
>>> >>> >>
>>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed:
>>> >>> >>>=3D20
>>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)=
>>
>>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF
>>> >>> >>> >>Content-Type: text/plain; charset=3D3D3DISO-8859-1; format=
>>=3D3D3Dfl=3D
>>> >>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.=3D
>>> >>, ICM=3D3D
>>> >>> >>Ps). =3D3D3D
>>> >>> >>> >>
>>> >>> >>> >> Not all errors signal the transport layer; some signal t=
>>he ne=3D
>>> >>twork=3D3D
>>> >>> >>=3D3D3D20
>>> >>> >>> >>layer (e.g., too-big, redirect, etc.)
>>> >>> >>> >>
>>> >>> >>> >>PS - burying them in the TCP header eats option space from=
>> TCP,=3D
>>> >> whic=3D3D
>>> >>> >>h=3D3D3D20
>>> >>> >>> >>isn't exactly in abundance either ;-)
>>> >>> >>> >>
>>> >>> >>> >>Joe
>>> >>> >>> >>
>>> >>> >>> >>
>>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF
>>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D"signa=
>>ture.as=3D
>>> >>c"
>>> >>> >>> >>Content-Description: OpenPGP digital signature
>>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D"signature=
>>=2Easc"
>>> >>> >>> >>
>>> >>> >>> >>-----BEGIN PGP SIGNATURE-----
>>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32)
>>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev=
>>=2Eorg
>>> >>> >>> >>
>>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQ=
>>CdF9O=3D
>>> >>k
>>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D
>>> >>> >>> >>=3D3D3Do5Lq
>>> >>> >>> >>-----END PGP SIGNATURE-----
>>> >>> >>> >>
>>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF--
>>> >>> >>>=3D20
>>> >>> >>> cheers
>>> >>
>>> >>
>>> >>--------------enig841B4237908E688C7D411F39
>>> >>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
>>> >>
>>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8Y
>>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D
>>> >>=3DxV8K
>>> >>-----END PGP SIGNATURE-----
>>> >>
>>> >>--------------enig841B4237908E688C7D411F39--
>>>=20
>>> cheers
>>>=20
>>> jon
>>
>>
>>--------------enigD0DFC0254F721440EFF890E4
>>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
>>
>>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE
>>J6vm6gE7ZeA+AeVBsDHv/t8=
>>=SAYu
>>-----END PGP SIGNATURE-----
>>
>>--------------enigD0DFC0254F721440EFF890E4--
cheers
jon
More information about the end2end-interest
mailing list