Do you want the protocol DEPLOYED or not? Re: I-D Action:draft-rosenberg-internet-waist-hourglass-00.txt]

[Dan York <dyork@xxxxxxxxx>]

What I took from Jonathan's draft was the sense (correct in my view) that if we want new protocols to be successfully *deployed* in actual production networks and communicate across the firewall (which may or may not be doing NAT) to the public Internet, they should ideally sit on top of either TCP or UDP.

In both small and large corporate environments, my experience has certainly been that if you want communication to occur through the firewall, at some point you have to talk to "the firewall people".  It may be one person or a team and they may have differing levels of paranoia about how tight of a ruleset they have, but they are there.  And any new protocol needs to go through their box.

If you go to them and say that you need to open up TCP or UDP port XXX to/from a certain box, they may ask you questions, but at least they understand you. You are speaking their language.

If you go to them and say that you need to open up connections for a new transport protocol on top of IP, they will probably look at you like you have 3 heads.  And then they'll probably ask you a lot MORE questions.  And in fact they *may not be able to do it* with whatever firewall software they have.  I have seen some firewall software that when you are creating rules from the GUI, you only have 3 choices for a protocol on top of IP: TCP, UDP or ICMP.  Period. End of story.  If you want another transport protocol you *might* be able to do it with some command-line hackery, but that might also potentially be beyond the expertise level of the firewall people.

We can argue about how poorly designed that firewall software is, but that is the reality.  The deployed production environment on the public Internet today understands that transport protocols are TCP and UDP (with ICMP around to serve its limited purpose).  

That is my take on Jonathan's point.

Want to have a successful protocol?  Want it to take off and (potentially) be adopted by millions?   Use TCP or UDP as the base.

My 2 cents,

Dan

On Feb 14, 2008, at 9:19 AM, Jonathan Rosenberg wrote:

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,

Well, I'd hardly characterize, "allowing it to work across the public 

Internet" as a property that is useless. Statements like, "useless for 

all but NAT" trivialize what the Internet has evolved into. There is NAT 

everywhere. Lets accept it and design for what the Internet is, and not 

for the Internet as we wish it would be.

You may not like it, but its reality.

-Jonathan R.

-- 

Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.

Cisco Fellow                                   Edison, NJ 08837

Cisco, Voice Technology Group

jdrosen@xxxxxxxxx

http://www.jdrosen.net                         PHONE: (408) 902-3084

http://www.cisco.com

-- 

Dan York, CISSP, Director of Emerging Communication Technology

Office of the CTO    Voxeo Corporation     dyork@xxxxxxxxx

Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com

Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.

Find out how at http://evolution.voxeo.com

_______________________________________________

Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf