|
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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Dan York Sent: Thursday, February 14, 2008 10:53 AM To: Jonathan Rosenberg Cc: Harald Tveit Alvestrand; Joel M. Halpern; ietf@xxxxxxxx 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:
--
Dan York, CISSP, Director of Emerging Communication
Technology
Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com
|
_______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf