IETF Logo Mail Archive

Re: [tsvwg] draft-tuexen-tsvwg-sctp-sack-immediately-07.txt

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sat, 10 November 2012 08:33 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AAD21F84B2 for <tsvwg@ietfa.amsl.com>; Sat, 10 Nov 2012 00:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk6+m1zXmvf6 for <tsvwg@ietfa.amsl.com>; Sat, 10 Nov 2012 00:33:56 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id C864F21F84B1 for <tsvwg@ietf.org>; Sat, 10 Nov 2012 00:33:55 -0800 (PST)
Received: from [10.53.147.184] (unknown [80.187.201.11]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E43C91C0C0693; Sat, 10 Nov 2012 09:33:52 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com>
Date: Sat, 10 Nov 2012 09:33:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D785C4A-BEBF-400E-B420-5594512FE9BB@lurchi.franken.de>
References: <04A38419-1229-4635-A74D-3603BA76CF19@lurchi.franken.de> <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
X-Mailer: Apple Mail (2.1283)
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "randall@lakerest.net" <randall@lakerest.net>
Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-sack-immediately-07.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Nov 2012 08:33:56 -0000

On Nov 10, 2012, at 2:14 AM, Scheffenegger, Richard wrote:

>  
> Again one stupid question:
>  
> The security considerations only mention RFC4960, but a malicious receiver/sender is not mentioned there… Could there be any adverse effect when the I-bit is constantly set? For latency-sensitive applications that appears like something an application programmer wants to do on a permanent basis, to never have to wait for any delayed SACK chunk…
The receiver can already now use the socket API
http://tools.ietf.org/html/rfc6458#section-8.1.19
to set the SACK frequency to 1.

The only point is that it can be controlled by the sender... So I don't think there
is an issue here.

Best regards
Michael
>  
> But forgive me if this is a too TCP-ish view…
>  
> Regards,
>  
> Richard Scheffenegger
>

v2.23.0 | Report a Bug | By Email