IETF Logo Mail Archive

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

Randy Stewart <randall@lakerest.net> Mon, 12 November 2012 15:09 UTC

Return-Path: <randall@lakerest.net>
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 3E55721F859C for <tsvwg@ietfa.amsl.com>; Mon, 12 Nov 2012 07:09: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 ukQk3WRAdzSm for <tsvwg@ietfa.amsl.com>; Mon, 12 Nov 2012 07:09:55 -0800 (PST)
Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 920FB21F85AD for <tsvwg@ietf.org>; Mon, 12 Nov 2012 07:09:55 -0800 (PST)
Received: from [192.168.0.2] (67-5-108-133.spok.qwest.net [67.5.108.133]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id qACF9sFv057887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2012 10:09:56 -0500 (EST) (envelope-from randall@lakerest.net)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Randy Stewart <randall@lakerest.net>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D7676DD@SACEXCMBX04-PRD.hq.netapp.com>
Date: Mon, 12 Nov 2012 10:09:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <062638C4-CACF-4C07-AB87-31F1AA82FAA6@lakerest.net>
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: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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: Mon, 12 Nov 2012 15:09:56 -0000

Actually, if you want to be real TCPish the original TCP RFC (793) allows
you to sack every packet… not that folks do that but I do think its legal..

R
On Nov 9, 2012, at 8:14 PM, 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…
>  
> But forgive me if this is a too TCP-ish view…
>  
> Regards,
>  
> Richard Scheffenegger
> 

-----
Randall Stewart
randall@lakerest.net

v2.23.0 | Report a Bug | By Email