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
