Hi Harald,
the problem with a number of the protocols is that they are later used
in a different context.
Take SCTP, for example. Initially, it was meant to be used for
server-to-server communication. Now, some folks obviously want to use it
in a different way.
Whether this is a good idea or not is a separate question but then you
obviously run into problems. The real problem, however, starts when you
do not consider the best current practice in a certain environment.
Folks working in the RAI area have noticed a couple of years back that
it is a really good idea todo everything to deal with NATs even if the
results are not beautiful nor lightweight. This has a lot todo with
their deployment experience. When you go to other areas in the IETF this
deployment experience is smaller or missing at all. Consider Mobile IP,
for example, where many optimize the last hack out of the protocol in
the believe that their extensions will run only in an IPv6 environment
without any middleboxes. This has todo with the lack of deployment of
many of the mobility protocols.
When you want to design a protocol with extensibility in mind then you
need to consider these aspects. Needless to say that protocols tend to
get more complex when you support a lot of flexibility.
I agree with your comment about SCTP running on top of UDP to a large
extend.
Ciao
Hannes
Harald Tveit Alvestrand wrote:
While I disagree with Jonathan's assertion that we should insert an
entirely useless (for all but NAT) UDP header in front of all new protocols
we design, I also disagree with Joel's (implicit) assumption that we can't
implement congestion control on top of UDP.
SCTP mapped on top of UDP would have exactly the same congestion control
properties as SCTP mapped on top of IP.
Once I've read the draft, I may have other opinions.
Harald
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf