--On 14. februar 2008 08:38 -0800 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> 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
[email protected]
http://www.ietf.org/mailman/listinfo/ietf
