[tcpm] RE: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test

At Fri, 16 Nov 2007 10:51:27 -0000 , <toby.moncaster at bt.com>  wrote:

> * Those receivers that are seeking to conceal congestion losses must
> have decided they don't need the missing data. This suggests either
> they are streaming media off the sender or they are collaborating
> with the sender.  ...

That is exactly the scenario supported by the Space Communication
Transport Protocol (SCPS-TP) "BETS" extension to TCP, now shortly
discussed in Section 6.5.4 of draft-moncaster-tcpm-rcv-cheat-02:
The reciever does not need outdated data, and it announces this
(and supporting protocol behavior) by negotiating BETS via TCP
option #20; and thus, the sender is aware or the possibility of
receiving ACKs for data not arrived at the receiver, and can
suppress the test.

I suggest that particular applications interested in this "Real-Time
Streaming over TCP" should consider implementing enough parts of
SCPS-TP to support BETS to coordinate sender and receiver behavior
in a manner tailored to these specific requirements.
Partial implementation of SCPS-TP is facilitated by the fact that
most TCP extensions of SCPS-TP have to be negotiated per connection;
if you do not have implemented a feature, just don't negotiate it!

  Alfred.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm