--On 14. februar 2008 08:38 -0800 "Hallam-Baker, Phillip"
<pbaker(_at_)verisign(_dot_)com> wrote:
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.
Many years ago I implemented an even simpler approach to "lossy TCP":
When sending a packet (most higher level protocols have packets), check how
full the sending buffer (which retains a copy of all unacknowledged data)
is; if it's "rather full", and the packet is "not important", throw it away.
Worked like a charm. And no redefinitions of TCP semantics required at all.
Harald
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf