Re: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01

Michael Tuexen <tuexen@fh-muenster.de> Wed, 10 July 2013 07:42 UTC

Return-Path: <tuexen@fh-muenster.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 172F721F9DE3 for <tsvwg@ietfa.amsl.com>; Wed, 10 Jul 2013 00:42:27 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlXRvyCqHA00 for <tsvwg@ietfa.amsl.com>; Wed, 10 Jul 2013 00:42:26 -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 86B1221F9D2A for <tsvwg@ietf.org>; Wed, 10 Jul 2013 00:42:23 -0700 (PDT)
Received: from [192.168.1.101] (p5481B3B6.dip0.t-ipconnect.de [84.129.179.182]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CB0F11C0C0695; Wed, 10 Jul 2013 09:42:18 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Michael Tuexen <tuexen@fh-muenster.de>
In-Reply-To: <CAAFAkD-Kgb34TBC2bDWKVUfF4NNgyWSMzPk1MAU5rUwjkf=4uw@mail.gmail.com>
Date: Wed, 10 Jul 2013 09:42:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de>
References: <CAAFAkD-Kgb34TBC2bDWKVUfF4NNgyWSMzPk1MAU5rUwjkf=4uw@mail.gmail.com>
To: Jamal Hadi Salim <hadi@mojatatu.com>
X-Mailer: Apple Mail (2.1508)
Cc: tsvwg@ietf.org, robin.seggelmann@t-systems.com
Subject: Re: [tsvwg] comments draft-tuexen-tsvwg-sctp-prpolicies-01
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: Wed, 10 Jul 2013 07:42:27 -0000

On Jul 10, 2013, at 3:22 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

> 
> Hi,
> 
> Looks good. 
> I have an unrelated question since a mention occurs in the sprstat_abandoned_sent stats): 
> does it make sense to abandon a message that is partially sent? At the receiver, I am
> assuming if such a  partial message was to make it, partial delivery will be made to
> the socket user?
Ji Jamal,

you have to distinguish between the sender and receiver side.

Assume the sender sends a user message which is approximately of size 3*MTU.
So SCTP will fragment it into 3 DATA chunk and send them. If the user
has specified that the number of retransmissions is limited to 0 and
the last fragment gets lost in the network, the sender will increment
sprstat_abandoned_sent.

What will happen at the receiver side if you assume that the first two
fragments have been received. If partial delivery was started, you will
get a SCTP_PARTIAL_DELIVERY_EVENT event indicating SCTP_PARTIAL_DELIVERY_ABORTED.
Without partial delivery being started, the receiver could also drop the
first part of the message.

Best regards
Michael
> 
> 
> cheers,
> jamal
> 
>