[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound
Dean,
Deployments don't need to support the Very Important Stuff you mention
below to see problems with UDP fragmentation across NATs. Just support
an event package with some honkin' XML sizes like presence, you'll see
it pretty quickly then.
I think the big problem in the UDP vs. TCP debate is that end customers
do not perceive the choice in transport protocol as being something that
provides them with significant value. Because of that, they don't push
their vendors to support it (as evidenced by the large amount of UDP
equipment running around out there) and the system engineering
requirements for TCP are viewed to be significantly different from UDP.
The reason I am pointing this out is because we're trying to fix the
problem by forcing people's hand's in the standard, which I believe is
ultimately going to fail. People will put in whatever they need to
continue to avoid the cost of developing proper TCP support until the
market demands TCP be supported (meaning that they can no longer avoid
the cost because they won't be able to deploy any equipment without it).
IMHO-- we should be flexible in this regard. Make sure that the UDP
behavior is at least minimally specified in the standard (warts and all)
and then work outside of standards with customers so that they fully
appreciate (and properly value) what they're getting with TCP that
they're not getting with UDP. At that point I think the whole debate
will resolve itself because the number of implementations wanting to use
UDP will drop.
Also, people should keep in mind that there are a panoply of access
network types out there. Some of them behave better with UDP than they
do with TCP because of the way the access network itself operates. If
you are thinking only in a CAT-5/6 world, there are other issues out
there that people may be up against that pushes them to use UDP. If I
have an access network that favors UDP in performance, and I know there
are no NATs between the client and the outbound proxy that have
fragmentation issues, it doesn't make sense to use TCP.
Regards,
Brian
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Sunday, December 24, 2006 5:54 PM
> To: Cullen Jennings
> Cc: SIP; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] Question about Poll: Proposal relating to
> keepalive, TCP, and UDP usage in draft-ietf-sip-outbound
>
> Cullen Jennings wrote:
>
> > Hmm - I wish we had better specifics here - I will point out there
> > are millions of endpoints on well known residential endpoints that
> > are working through NATs and connected to PSTN gw and softwswiches
> > that are working over UDP.
> ...
> > Could you point me at a non enterprise deployment that is not in
> > point 2? I suspect there are some but the bulk seem to be form 2.
>
> The problem is that none of those deployments are (yet) using
> the boatload of features like identity, e2m, complex
> route-header cookies, and other Very Important Stuff that we
> think might be likely to happen.
> But when that stuff starts to happen, UDP fragmentation will
> start to occur. We don't yet know how much will break as a
> result. But my guess is "a lot".
>
> How about we rip out UDP, fix the Outbound stuff, fix the
> route-construction stuff, fix the early-media stuff. and call
> it SIP 3.0?
>
> --
> Dean
>
>
> --
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip