Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-immediately-02: 19th March 2013

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Tue, 02 April 2013 08:58 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 98F2E21F9887 for <tsvwg@ietfa.amsl.com>; Tue, 2 Apr 2013 01:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smYbb0QSTCUP for <tsvwg@ietfa.amsl.com>; Tue, 2 Apr 2013 01:58:08 -0700 (PDT)
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 681AD21F9866 for <tsvwg@ietf.org>; Tue, 2 Apr 2013 01:58:07 -0700 (PDT)
Received: from [192.168.1.102] (p5481807F.dip0.t-ipconnect.de [84.129.128.127]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CB2F11C0C069D; Tue, 2 Apr 2013 10:58:05 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <267C7CD9-6E64-4133-B4B5-029DE6EA8847@ifi.uio.no>
Date: Tue, 02 Apr 2013 10:58:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E527DD3C-F037-442A-98FF-9CE61758E669@lurchi.franken.de>
References: <4F605902.40009@erg.abdn.ac.uk> <5148B330.3000304@erg.abdn.ac.uk> <CAO249ycs-1at532RQWHzJVpH49p-PyXX4Sh=e=DGTs7WqMKOzQ@mail.gmail.com> <A7378318-1AA0-4B8C-B2A6-DF45B7F5A63B@lurchi.franken.de> <267C7CD9-6E64-4133-B4B5-029DE6EA8847@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.1283)
Cc: tsvwg <tsvwg@ietf.org>
Subject: Re: [tsvwg] WGLC Announcement for draft-ietf-tsvwg-sctp-sack-immediately-02: 19th March 2013
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: Tue, 02 Apr 2013 08:58:08 -0000

On Apr 2, 2013, at 10:15 AM, Michael Welzl wrote:

> Hi,
> 
> I have read this draft and support it.
> 
> Regarding the issue below:
> 
> 
> On 2. apr. 2013, at 09:27, Michael Tuexen wrote:
> 
>> On Apr 2, 2013, at 8:29 AM, Yoshifumi Nishida wrote:
>> 
>>> Hi,
>>> 
>>> I support this draft.
>>> Some minor questions I have are related to the following rule in the draft.
>>> "the sending of a DATA chunk fills the congestion or receiver window."
>>> 
>>> 1: I am personally curious about how much benefit we can get by this.
>>>   If there's an analysis on this, I will want to see it in the reference.
>> Hi Yoshifumi,
>> 
>> some simulation results are available at:
>> Improving the Acknowledgment Handling of SCTP
>> Rüngeler, I.; Tüxen, M.; Rathgeb, E. P.
>> Proceedings of the 4th International Conference on Digital Society (ICDS 2010), February 2010.
>>> 
>>> 2: Because this rule will be checked on every packet transmission, I
>>> would like to know if the draft suggests to set I-bit everytime we
>>> have a chance or there might be a case where we shouldn't.
>> The sender could do it to switch off delayed SACK. However, this
>> might not be useful. Therefore, as stated, the sender should set it,
>> when he is waiting for an SACK.
> 
> Could there be a way to phrase this in that style, to also make it more general than "a DATA chunk fills the congestion or receiver window" ?
Besides the very generic statement
(Whenever the sender of a DATA chunk can benefit from the
corresponding SACK chunk being sent back without delay...)
the ID lists some concrete situations (not a complete list).
I'm open to add another one, if you can provide some text...
> 
> I'm thinking about the case that draft-ietf-tcpm-rtorestart-00 addresses, of an application-limited sender that only has one SACK to expect and, in case it doesn't arrive, only a timeout to rely upon. Unless I'm missing some SCTP-specific detail here, it should also be beneficial to SACK early in this case (see fig. 1 in our draft).
I'm not sure how the I-bit helps. I think you are focussing on retransmissions in case of packet drops.
Assume that the RTO is larger than the RTT + SACK.delay (if not, it is a mis-configuation, in
which setting the I-bit allows the sender to work around the problem), then one of two things happen:
* the packet is dropped and there is no SACK acking it. The sender will retransmit after RTO.
* the packet arrives and the corresponding SACK will arrive after an RTT or RTT + SACK.delay.
  In both cases, no retransmission will happen.

Am I missing something?
> 
> This case would be covered by "when it is waiting for a SACK" but not by "fills the congestion or receiver window" (because both of these windows may be much larger than what the sender really transmits).
I'm open for adding another scenario, where it helps. However, I did not understand you case
above...

Best regards
Michael
> 
> Cheers,
> Michael
> 
> 
>> 
>> Best regards
>> Michael
>>> 
>>> Thanks,
>>> --
>>> Yoshifumi
>>> 
>>> 
>>> On Tue, Mar 19, 2013 at 11:49 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>>>> 
>>>> This email announces the start of a working group last call for
>>>> draft-ietf-tsvwg-sctp-sack-immediately-02.txt, "SACK-IMMEDIATELY Extension
>>>> for the Stream Control Transmission Protocol". This document is now thought
>>>> to be ready to proceed to be published as a PS. Please send any comments to
>>>> the TSVWG list.
>>>> 
>>>> The draft is available at:
>>>> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately/
>>>> 
>>>> The last call will run for TWO weeks, ending Friday 5th April 2013.
>>>> 
>>>> Emails saying "I support" or "I don't support" publication are also most
>>>> helpful in judging the WG consensus. Please let us know if this draft is
>>>> useful and seems to provide the correct advice.
>>>> 
>>>> James, David and Gorry
>>>> (TSVWG Chairs)
>>>> tsvwg-chairs@ietf.org
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>