They're already deployment failures. Straightforward UDP tunnelling (encapsulate IP packet in UDP payload, that's all) is not happening for these protocols. A custom encapsulation method tailored just to carrying these protocols (in effect, a pointless addition to each protocol) is not justified. Do you need to create a custom way of UDP tunnelling these protocols just to promote the basic idea of UDP tunnelling? I don't think so. UDP tunnelling of these protocols can already be done. There's still no demand. Writing a document saying there's a slightly more complicated way to do UDP tunnelling instead of just doing UDP tunnelling won't change that. Lloyd Wood http://sat-net.com/L.Wood ________________________________________ From: Michael Welzl [michawe@xxxxxxxxxx] Sent: 27 April 2010 12:08 To: Wood L Dr (Electronic Eng) Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx Subject: Re: UDP encaps for SCTP and SCCP Hi, On Apr 27, 2010, at 12:06 PM, <L.Wood@xxxxxxxxxxxx> <L.Wood@xxxxxxxxxxxx> wrote: > "A bit stupid"? Sorry - I didn't mean to be personal, my point was that this looks like a self-contradicting (somehow circular) argument. > UDP encapsulation of these protocols can already be done. Tunnelling > is not new. IP packet, UDP header, IP outer header, you're done. > > What is not needed or justified is a 'special' encap which requires > documentation, implementation, and then deployment - because lack of > deployment of these protocols is already the problem here, and that > won't help. > > Now, if there were already masses and masses of UDP tunnels of these > protocols, with users complaining about MTU issues and the need for > efficiencies, then there just _might_ be a case for it. But if > there's no UDP tunnelling of these protocols happening, why create a > bespoke solution? ok, I see your point, now - and it makes me wonder why, indeed, we don't have these masses and masses of UDP tunnels, at least for SCTP. But then, not having an agreement on one particular way of doing that might just be a reason. Let's say that specifying UDP encapsulation increases the chances of, e.g., SCTP usage by just a little bit. What's the big disadvantage that stands against doing it? It doesn't seem like a horribly complex piece of work to me, and what's the big risk of having it? My view is, at this point we should be doing all we can to get these protocols deployed. Or would you rather go ahead and put them straight into the gallery of deployment failures, together with IP multicast, QoS, etc etc... ? > To look at your analogy, you're not fixing tool X. You're saying > that tool X would suddenly be magically more useful if tool > attachment Y could be added to it; for example, we can't use an odd > Torx-variant screwdriver in the dark, so let's add an LED light! But > torches are already available, and using a screwdriver in the > presence of a separate light source is straightforward and the > common case. Having the optional LED light won't sell any more odd > Torx-variant screwdrivers. I'm not sure I follow you anymore. How is tunneling over UDP (which should foster deployment of the protocols) the same as adding a pointless feature to SCTP or DCCP? > And there was consensus that the OSI protocols would be useful and a > lot of workgroups were formed. So? well, these are not OSI standards, and so there must have been quite broad IETF consensus that these protocols make sense, at some point in time. This being the same standardization body, my concern is about following a zig-zag course. I understand that concensus can change, as the world around us does, and so going with the facts of today makes sense - but first saying "hey, that seems like a good idea, let's develop this protocol" and then saying "hm, noone uses it, let's not bother trying to make this more practical" seems odd and halfhearted. Cheers, Michael
