As with most protocol design issues, this is a problem that becomes much
easier to deal with if there is a frank and realistic understanding of
the real world constraints.
While UDP or TCP are acceptable for virtually all protocol needs there
are many protocols for which they are not optimal.
In particular there are many cases where you would like to establish a
'lossy TCP connection'. That is you want the flow &ct. advantages that
you get from establishing a control channel session while accepting the
fact that in a real time connection you may well want to start dropping
packets that are arriving too late.
I think this can be done end-to-end in a manner that is entirely
backwards compatible. All we have to do (people are going to hate this)
is to eliminate the traditional assumption in TCP that a retransmitted
packet is going to be the same as the original, alternatively we can
eliminate the assumption that unacknowledged packets are going to be
retransmitted. That might well be the better approach.
A high level abstraction for a lossy connection will inevitably involve
additional overhead and additional programmer complexity. There has to
be a mechanism to allow the application layer.
The approach that comes to mind is to identify communication 'frames'
that are to be either transmitted in their entirety or lost. The high
level applications at the sending and receiving side need to know which
frames are transmitted, which are being lost and some indicator to show
if the delivery rate could be stepped up.
Lossy TCP should not be a problem for the Internet core since there is
never a guarantee that packets travel on the same path. There might be a
stateful inspection firewall that checks TCP sequence numbers but the
more usual concern is to control session initiation and teardown.
________________________________
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Dan York
Sent: Thursday, February 14, 2008 10:53 AM
To: Jonathan Rosenberg
Cc: Harald Tveit Alvestrand; Joel M. Halpern; ietf(_at_)ietf(_dot_)org
Subject: Do you want the protocol DEPLOYED or not? Re:
I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]
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(_at_)cisco(_dot_)com
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(_at_)voxeo(_dot_)com
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 mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf