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

Alfred Hönes <ah@tr-sys.de> Fri, 16 November 2007 18:59 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6P6-0005Hd-E0; Fri, 16 Nov 2007 13:59:00 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1It6P5-0005HP-8J for tcpm-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:58:59 -0500
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6P4-0005H6-UB for tcpm@ietf.org; Fri, 16 Nov 2007 13:58:58 -0500
Received: from dsl.tr-sys.de ([] helo=WOTAN.TR-Sys.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It6P3-0000rW-04 for tcpm@ietf.org; Fri, 16 Nov 2007 13:58:58 -0500
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: $/16.3) id AA211569492; Fri, 16 Nov 2007 19:58:12 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA15560; Fri, 16 Nov 2007 19:58:10 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@tr-sys.de>
Message-Id: <200711161858.TAA15560@TR-Sys.de>
Subject: [tcpm] RE: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test
To: jheffner@psc.edu, toby.moncaster@bt.com
Date: Fri, 16 Nov 2007 19:58:10 +0100 (MEZ)
References: <473B28E0.6040602@psc.edu>
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

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!


tcpm mailing list