Yes, I know that people have tried to deploy new schemes beyond TCP and UDP.
DCCP has one major difference, it is not designed for deployment and so as far
as I am concerned it might as well not exist. Like multicast this is a
transport optimization. A transport optimization has precisely zero interest to
me unless it is going to interoperate with 100% of the systems I might want to
connect to.
Harald's proposal is elegant and has minimum impact on the infrastructure. That
is the type of proposal that I like and would want to see supported.
Proposing new protocol numbers may have some interest in large walled garden
infrastructures, particularly if you want to make the transition from walled
garden to Internet somewhat costly for lock in purposes. But its a dead end
unless you have a really powerful killer application that can build out the
infrastructure for you.
________________________________
From: Lars Eggert [mailto:lars(_dot_)eggert(_at_)nokia(_dot_)com]
Sent: Fri 15/02/2008 10:53 AM
To: Hallam-Baker, Phillip
Cc: Dan York; Jonathan Rosenberg; Harald Tveit Alvestrand; Joel M. Halpern;
ietf(_at_)ietf(_dot_)org
Subject: Re: Do you want the protocol DEPLOYED or not? Re:
I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]
Hi,
On 2008-2-14, at 18:38, ext Hallam-Baker, Phillip wrote:
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.
you're not the first one to have that idea. Which is why there is DCCP.
And you're going to say that that doesn't work because it uses a
different protocol number, but if you are going to reuse protocol 6
for "lossy" TCP, you are going to need a flag somewhere that lets a
receiver differentiate between standard and "lossy" TCP. What you're
proposing is DCCP with that flag somewhere other than the protocol
number, or any other field that NATs have assumptions about.
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,
There is no such assumption in TCP. A hole in the sequence number
space can be filled through any combination of retransmissions.
alternatively we can
eliminate the assumption that unacknowledged packets are going to be
retransmitted. That might well be the better approach.
And that's what DCCP does.
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.
There is a piece of this sentence missing, but anyhow, DCCP has
realized this and is working on a "user guide" that would tell app
implementers about how to use the protocol.
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.
You might want to read RFC4340.
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.
Few things are a problem for the core, but there's a ton of
middleboxes at the edge that have assumptions about what TCP should
look and act like. Things aren't as simple as using protocol number 6
with something that sort of looks like a TCP header.
Lars
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf