[e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/
Joe Touch
touch at ISI.EDU
Fri Jul 11 09:10:16 PDT 2008
Jon,
Jon Crowcroft wrote:
...
> I simplify the design of ip to get these properties
> properly, at the cost of complex icmp but
> icmp is slow path/control plane so that tradeoff is to MY benefit.
>
> putting information for forwarding (as opposed to for end system)
> into the TCP header would require ip forwarding to look there -
> on the fast path which is clearly a Bad Idea not just in relegious
> sense, but also in an engienering sense.
I agree that shifting things around to make forwarding faster would be
beneficial. However, I disagree that putting things in the transport
header is a reasonable solution - whether ICMP is slow path or not,
you're requiring routers to parse transport header, which is also a bad
engineering idea.
> ICMP communicates largely information for transport
> (i.e. its a middle box function) so as i have said several times, it is
> completely within scope to consider making this communication more
> fit for purpose (indeed, more in keeping with the end to end argument)
ICMP is useful for network (e.g., routing) as well as transport. Even
when considering just their transport use, however, they are generated
as network signals to the source transport.
Again, I appreciate the desire for more space for realms, etc., but
there is no case here for using space in the transport header for the
source ID or any other network layer information.
> end of argument
I agree; we have each come to our conclusions.
Joe
> In missive <48778010.102 at isi.edu>, Joe Touch typed:
>
> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> >>--------------enigF1C37DEE2E67C3C7E2C863DF
> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>Content-Transfer-Encoding: quoted-printable
> >>
> >>
> >>
> >>Jon Crowcroft wrote:
> >>> you say i should put the realm info as a tcp option and then say there=
> >> isnt
> >>> much space for tcp options.
> >>
> >>You do put something as a TCP option - the source ID. I'm saying that it =
> >>
> >>is just as useful (or problematic) to put the realm there, and that TCP=20
> >>lacks space in general for either.
> >>
> >>> i say sna does it in a way that is more flexible, doesnt need a lot of =
> >>routers to
> >>> change just yet,=20
> >>
> >>All routers on a path need to change to find the SNA ID to send return=20
> >>ICMP errors.
> >>
> >> > and provides a lot of what people have done in mobile ipv6 (with
> >>> route optimisation) without the pain of turning on full internet wide v=
> >>6 routing.
> >>> admittedly there's a little tweaking of some icmp code - this is not pe=
> >>rformance
> >>> critical and one could easily (as per shim6) do the transport/icmp inte=
> >>rworking
> >>> cleanly across all transports
> >>
> >>If this is done as a shim on IP, then it's just an IP option=20
> >>(implemented a different way), in which case you haven't removed the=20
> >>source address so much as shifted it.
> >>
> >>If this is done as a common transport option, you're pinning transport=20
> >>protocols into a structure in order to support a network layer=20
> >>capability, which violates layering.
> >>
> >>> hosts already peak into ICMP errors to see for what Transport they migh=
> >>t be useful;=20
> >>
> >>That's not peeking; that's receiving an ICMP message and parsing it as=20
> >>indicated.
> >>
> >>> i dont see why ICMP looking in transport to figure out=20
> >>> whether its useful to send something at all and to whome is any differe=
> >>nt=20
> >>> in terms of religions like "layer violation" and its a whole lot more e=
> >>fficient
> >>
> >>It's not a religious issue; I'm noting that source IDs/addresses aren't
> >>only transport-layer info, and that's why ICMP needs access to them.
> >>
> >>Overall:
> >>
> >>- your proposal doesn't get rid of the source addr, it just moves it
> >> e.g., because packets without source addrs can be silently
> >> dropped without signaling the source, as you note,
> >> and apps sending packets without sources should expect this
> >>
> >>- moving the source address doesn't accomplish anything
> >> you want extra space for realms; that's fine, but taking
> >> that space from IP and putting the info in TCP isn't
> >> a win; it complicates ICMP design at routers. it's
> >> just as useful to put realms in the TCP header,
> >> or to put it in an IP option; there may be utility
> >> in that, but this has nothing to do with getting rid
> >> of a source address
> >>
> >>Joe
> >>
> >>
> >>> In missive <487777D1.6090001 at isi.edu>, Joe Touch typed:
> >>>=20
> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> >>> >>--------------enigD0DFC0254F721440EFF890E4
> >>> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
> >>> >>Content-Transfer-Encoding: quoted-printable
> >>> >>
> >>> >>Jon (et al.),
> >>> >>
> >>> >>Jon Crowcroft wrote:
> >>> >>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed:
> >>> >>>=3D20
> >>> >>> >>Consider a packet whose transport lacks a destination address
> >>> >>> >>altogether, as you note should be possible. Receivers of those =
> >>packe=3D
> >>> >>ts
> >>> >>> >>have no way to turn them around.
> >>> >>> =3D20
> >>> >>> >>> icmp errors can be sent, but icmp in routers would have to pa=
> >>rse t=3D
> >>> >>he TCP sna option
> >>> >>>=3D20
> >>> >>> >>So basically the need for the *network* layer to signal the sou=
> >>rce i=3D
> >>> >>s
> >>> >>> >>accommodated in packets using the TCP sna option by layer viola=
> >>tion.=3D
> >>> >>
> >>> >>>=3D20
> >>> >>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is no=
> >>t a l=3D
> >>> >>ayer
> >>> >>> violation.
> >>> >>
> >>> >>If you call ICMP a transport layer (fair enough), you haven't explai=
> >>ned=3D20
> >>> >>why one transport should peek into the headers of another. ICMP can =
> >>talk =3D
> >>> >>
> >>> >>to TCP, but having ICMP parse TCP headers would be layer violation I=
> >>MO.
> >>> >>
> >>> >>> by the way, i dont put an _address_ in the transport - i put an id=
> >>entif=3D
> >>> >>ier - this
> >>> >>> is then used receivers to lookup an address to the originator. i _=
> >>might=3D
> >>> >>_ put a
> >>> >>> routing hint (e.g. a care of adddress) in the transport too - this=
> >> is =3D
> >>> >>
> >>> >>> not the same as putting in an actual address (which i am getting r=
> >>id of=3D
> >>> >> as it is
> >>> >>> invalid MOST of the time...
> >>> >>
> >>> >>Understood. That difference isn't key to my responses, so I've just=3D=
> >>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=3D
> >>> >>at's
> >>> >>> >>just shuffling the deck chairs. If you wanted more space for IP=
> >>, it'=3D
> >>> >>s
> >>> >>> >>just as logical to leave the current IP header alone and place =
> >>the e=3D
> >>> >>xtra=3D20
> >>> >>> >>forwarding info in the TCP header - if you're violating layers =
> >>for I=3D
> >>> >>CMP, =3D3D
> >>> >>>=3D20
> >>> >>> this is either a semantic quibble or confusing.
> >>> >>>=3D20
> >>> >>> 1. i havnt changed the IP header ast aal - i 've changed the meani=
> >>ng of=3D
> >>> >> a field -
> >>> >>> thishas some very nice legacy interworking properties (as noted in=
> >> my n=3D
> >>> >>ote)
> >>> >>
> >>> >>Changing the meaning of a field changes the header. I.e., you can't =
> >>pass =3D
> >>> >>
> >>> >>that packet through a legacy router usefully - it could generate ICM=
> >>Ps=3D20
> >>> >>to the wrong place, and won't interpret the source address field as =
> >>an=3D20
> >>> >>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=3D20
> >>> >>same as IP's source address; I could just as easily put the source I=
> >>D in =3D
> >>> >>
> >>> >>the TCP header too if you prefer).
> >>> >>
> >>> >>Further, your paper and emails have not addressed the fact that TCP=3D=
> >>20
> >>> >>headers don't exactly have lots of space - especially the SYN packet=
> >>,=3D20
> >>> >>which is where the source identifier for a connection would need to =
> >>be=3D20
> >>> >>established.
> >>> >>
> >>> >>=3D2E..
> >>> >>> >>why not for forwarding?
> >>> >>> >>> since most of these ICMP response are meant as a response to=
> >> a tr=3D
> >>> >>anspo=3D3D
> >>> >>> >>rt entity,
> >>> >>> >>> this is semantically reasoanble.
> >>> >>> >>
> >>> >>> >>Your system posits transports might not ever need source addres=
> >>ses.
> >>> >>> >>Those transports no longer benefit from ICMP information from t=
> >>he ne=3D
> >>> >>twork=3D3D
> >>> >>>
> >>> >>> indeed since there is no information theoretic or control theoerti=
> >>c rea=3D
> >>> >>son they
> >>> >>> should want fedback from the net if thewy didnt want it from the e=
> >>nd. -=3D
> >>> >> i am just=3D20
> >>> >>> bringing some consistency to a design error of the internet.
> >>> >>
> >>> >>I agree that unidirectional packets don't necessarily need network=3D=
> >>20
> >>> >>feedback. That implies:
> >>> >>
> >>> >>1. that your entire supposition that the IP packet doesn't need a so=
> >>urce =3D
> >>> >>
> >>> >>address because the transport layer is unacknowledged may be true, b=
> >>ut=3D20
> >>> >>actually implies that all transport layers should be bidirectional=3D=
> >>20
> >>> >>(rather than implying that you don't need a source address).
> >>> >>
> >>> >>2. bidirectional packets need network address info in the network=3D=
> >>20
> >>> >>header, because the network needs to respond to that information. if=
> >> I=3D20
> >>> >>leave this to the transport layer, then every time I deploy a new=3D=
> >>20
> >>> >>transport protocol (SCTP, DCCP, etc.), I need to recode all my route=
> >>rs=3D20
> >>> >>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=3D20
> >>> >>end host. The need for source addresses in the header in the Interne=
> >>t is =3D
> >>> >>
> >>> >>to enable network-based error indicators. It's not clear at all why =
> >>that =3D
> >>> >>
> >>> >>is something we can/should want to get rid of entirely.
> >>> >>
> >>> >>Joe
> >>> >>
> >>> >>
> >>> >>
> >>> >>> >>
> >>> >>> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed:
> >>> >>> >>>=3D3D20
> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)=
> >>
> >>> >>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126
> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3Dwindows-1252; form=
> >>at=3D3D3D=3D
> >>> >>flowed
> >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable
> >>> >>> >>> >>
> >>> >>> >>> >>Jon,
> >>> >>> >>> >>
> >>> >>> >>> >>You asked why the Internet had source addresses. I provide=
> >>d an =3D
> >>> >>answe=3D3D
> >>> >>> >>r,=3D3D20
> >>> >>> >>> >>based on my understanding of the historical context for th=
> >>e dec=3D
> >>> >>ision=3D3D
> >>> >>> >>=3D3D2E I=3D3D20
> >>> >>> >>> >>apologize for being too terse for that to be clear, or for=
> >> bein=3D
> >>> >>g too=3D3D
> >>> >>> >>=3D3D20
> >>> >>> >>> >>glib to belie a thoughful consideration of the contents of=
> >> your=3D
> >>> >> pape=3D3D
> >>> >>> >>r.
> >>> >>> >>> >>
> >>> >>> >>> >>That, however, does not mean that I did not read your pape=
> >>r.
> >>> >>> >>> >>
> >>> >>> >>> >>My response of your (IMO, historical) question has nothing=
> >> to d=3D
> >>> >>o wit=3D3D
> >>> >>> >>h=3D3D20
> >>> >>> >>> >>your proposal for removing them, as is discussed below.
> >>> >>> >>> >>
> >>> >>> >>> >>Jon Crowcroft wrote:
> >>> >>> >>> >> > a perfect example of people responding to email that th=
> >>ey ha=3D
> >>> >>ven't=3D3D
> >>> >>> >>
> >>> >>> >>> >> > actually read properly
> >>> >>> >>> >>
> >>> >>> >>> >>I urge posters to read the mail they *write* as well as th=
> >>ose o=3D
> >>> >>thers=3D3D
> >>> >>> >>=3D3D20
> >>> >>> >>> >>post. ;-) Please read my more detailed note below before =
> >>concl=3D
> >>> >>uding=3D3D
> >>> >>> >> how=3D3D20
> >>> >>> >>> >>properly I've read your work.
> >>> >>> >>> =3D3D20
> >>> >>> >>> >>
> >>> >>> >>> >>--
> >>> >>> >>> >>
> >>> >>> >>> >>You assert that:
> >>> >>> >>> >>
> >>> >>> >>> >>> Remember this (RFC 791)? Let=3D3D3D92s think about the l=
> >>ine mar=3D
> >>> >>ked
> >>> >>> >>> >>> by Xs. So why is there a source address there? The naive=
> >> answ=3D
> >>> >>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 bac=
> >>k! Th=3D
> >>> >>e
> >>> >>> >>> >>> end-to-end argument says that we do not put a function i=
> >>n a l=3D
> >>> >>ower
> >>> >>> >>> >>> layer, unless it is required by the majority of upper la=
> >>yer u=3D
> >>> >>sers
> >>> >>> >>> >>
> >>> >>> >>> >>E2E argument allows designers to "put things in a layer th=
> >>at TH=3D
> >>> >>AT la=3D3D
> >>> >>> >>yer
> >>> >>> >>> >>actually needs".
> >>> >>> >>> >>
> >>> >>> >>> >>Later, your doc says that:
> >>> >>> >>> >>
> >>> >>> >>> >>> a better place to send advisory
> >>> >>> >>> >>> information in the future Internet is onwards to the rec=
> >>eiver=3D
> >>> >>, not=3D3D
> >>> >>> >>
> >>> >>> >>> >>> backwards to the sender. Obviously the unreachable cases=
> >> need=3D
> >>> >>
> >>> >>> >>> >>> to be considered more carefully, although if an end syst=
> >>em is=3D
> >>> >> not
> >>> >>> >>> >>> reachable, a SNA-RK might be still reachable.
> >>> >>> >>> >>
> >>> >>> >>> >>Host and net unreachables can't be fixed at all, as you no=
> >>te la=3D
> >>> >>ter. =3D3D
> >>> >>> >>
> >>> >>> >>> >>Other messages require the receiver know the source, which=
> >> - if=3D
> >>> >> this=3D3D
> >>> >>> >> is=3D3D20
> >>> >>> >>> >>one of those higher layers that doesn't want to send somet=
> >>hing =3D
> >>> >>back =3D3D
> >>> >>> >>-=3D3D20
> >>> >>> >>> >>won't happen either.
> >>> >>> >>> >>
> >>> >>> >>> >>The fact that further discussion asserts that error notifi=
> >>catio=3D
> >>> >>ns we=3D3D
> >>> >>> >>re=3D3D20
> >>> >>> >>> >>always a bad idea I find naive as well. And MTU discovery =
> >>will =3D
> >>> >>NEVER=3D3D
> >>> >>> >>=3D3D20
> >>> >>> >>> >>happen if the receiver has no notion of who the sender is.=
> >>
> >>> >>> >>> >>
> >>> >>> >>> >>---
> >>> >>> >>> >>
> >>> >>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed:
> >>> >>> >>> >>>=3D3D20
> >>> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and =
> >>3156)=3D
> >>> >>
> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF
> >>> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3D3DISO-8859-1;=
> >> format=3D
> >>> >>=3D3D3D3Dfl=3D3D
> >>> >>> >>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 er=
> >>rors =3D
> >>> >>(e.g.=3D3D
> >>> >>> >>, ICM=3D3D3D
> >>> >>> >>> >>Ps). =3D3D3D3D
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >> Not all errors signal the transport layer; some sig=
> >>nal t=3D
> >>> >>he ne=3D3D
> >>> >>> >>twork=3D3D3D
> >>> >>> >>> >>=3D3D3D3D20
> >>> >>> >>> >>> >>layer (e.g., too-big, redirect, etc.)
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >>PS - burying them in the TCP header eats option space=
> >> from=3D
> >>> >> TCP,=3D3D
> >>> >>> >> whic=3D3D3D
> >>> >>> >>> >>h=3D3D3D3D20
> >>> >>> >>> >>> >>isn't exactly in abundance either ;-)
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >>Joe
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF
> >>> >>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D3=
> >>D"signa=3D
> >>> >>ture.as=3D3D
> >>> >>> >>c"
> >>> >>> >>> >>> >>Content-Description: OpenPGP digital signature
> >>> >>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D3D"si=
> >>gnature=3D
> >>> >>=3D2Easc"
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >>-----BEGIN PGP SIGNATURE-----
> >>> >>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32)
> >>> >>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.m=
> >>ozdev=3D
> >>> >>=3D2Eorg
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTE=
> >>sWdYQ=3D
> >>> >>CdF9O=3D3D
> >>> >>> >>k
> >>> >>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D3D
> >>> >>> >>> >>> >>=3D3D3D3Do5Lq
> >>> >>> >>> >>> >>-----END PGP SIGNATURE-----
> >>> >>> >>> >>> >>
> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF--
> >>> >>> >>> >>>=3D3D20
> >>> >>> >>> >>> cheers
> >>> >>> >>
> >>> >>> >>
> >>> >>> >>--------------enig841B4237908E688C7D411F39
> >>> >>> >>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
> >>> >>> >>
> >>> >>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8=
> >>Y
> >>> >>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D3D
> >>> >>> >>=3D3DxV8K
> >>> >>> >>-----END PGP SIGNATURE-----
> >>> >>> >>
> >>> >>> >>--------------enig841B4237908E688C7D411F39--
> >>> >>>=3D20
> >>> >>> cheers
> >>> >>>=3D20
> >>> >>> jon
> >>> >>
> >>> >>
> >>> >>--------------enigD0DFC0254F721440EFF890E4
> >>> >>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
> >>> >>
> >>> >>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE
> >>> >>J6vm6gE7ZeA+AeVBsDHv/t8=3D
> >>> >>=3DSAYu
> >>> >>-----END PGP SIGNATURE-----
> >>> >>
> >>> >>--------------enigD0DFC0254F721440EFF890E4--
> >>>=20
> >>> cheers
> >>>=20
> >>> jon
> >>
> >>
> >>--------------enigF1C37DEE2E67C3C7E2C863DF
> >>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
> >>
> >>iD8DBQFId4AQE5f5cImnZrsRAiVYAJ9gkJxsv7y+UqJlnkhe2xEQGB06OgCeMWQ0
> >>/q2ZOYRu0DHrMLUzzZC1Q9s=
> >>=YQ+E
> >>-----END PGP SIGNATURE-----
> >>
> >>--------------enigF1C37DEE2E67C3C7E2C863DF--
>
> 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/b5b08a2f/signature.bin
More information about the end2end-interest
mailing list