IETF Logo Mail Archive

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

Jamal Hadi Salim <hadi@mojatatu.com> Fri, 12 July 2013 18:15 UTC

Return-Path: <hadi@mojatatu.com>
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 233A821E80AB for <tsvwg@ietfa.amsl.com>; Fri, 12 Jul 2013 11:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.939
X-Spam-Level:
X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Q5mg4pZVkNZL for <tsvwg@ietfa.amsl.com>; Fri, 12 Jul 2013 11:15:18 -0700 (PDT)
Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85521E80A9 for <tsvwg@ietf.org>; Fri, 12 Jul 2013 11:15:18 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id pb11so8439986veb.23 for <tsvwg@ietf.org>; Fri, 12 Jul 2013 11:15:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=X6IL6lfyI2WQPhdppujvUsCaTuNdQ9yn7EVRq/U1RcQ=; b=nPBPfsvmrMwZ+nR9oDEqGbgiIaqErxs+FCxlTwXRl0vF6lQ3cehbRyxgmX4yZWWCR8 L5QdZ7tKt0JPUBh9E5S+wyHOhCE2iVIr+zko8X7YCjen1L1cwQwoUDN9RXT0fPatPEI/ XkGTLTOybDRAsguDzEZxYoA5fA+DSN/jyYJFxZACWay5hFp1toRRQetaYALMWjPkZKeT JFaRAOJ+5zQfZMp9+cgjhkqIejo4NVEDw9qR4bruuGCuTlbj+w/cuOMkPzvcijZM5Fy7 ulIl+X3lClvz3oc4vnFVhC75tflBWhv+5o9eSxdl8z+335ki5suGtaE1pah7mOnwCJVN dlkw==
X-Received: by 10.220.42.147 with SMTP id s19mr25089998vce.46.1373652917841; Fri, 12 Jul 2013 11:15:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.247.197 with HTTP; Fri, 12 Jul 2013 11:14:57 -0700 (PDT)
In-Reply-To: <C88CF9DB-E53F-4FA7-B0FF-B037660EA197@fh-muenster.de>
References: <CAAFAkD-Kgb34TBC2bDWKVUfF4NNgyWSMzPk1MAU5rUwjkf=4uw@mail.gmail.com> <27BA1FEC-AE84-412F-8D8A-4857FF283149@fh-muenster.de> <CAAFAkD_+22YfgTa+DusmH-CAW3q-afH=f-tbHQLCXaKf-wbyOA@mail.gmail.com> <C88CF9DB-E53F-4FA7-B0FF-B037660EA197@fh-muenster.de>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Fri, 12 Jul 2013 14:14:57 -0400
Message-ID: <CAAFAkD9oE74d9+f=-TM6VfupG10eV7+8RHbuWSRi=ReQv-zSuA@mail.gmail.com>
To: Michael Tuexen <tuexen@fh-muenster.de>
Content-Type: multipart/alternative; boundary="047d7b3a8d0c367fea04e1547ea1"
X-Gm-Message-State: ALoCoQmFzI62PafaCYuPKKZA4C9hMjXOqQOBxX8qpO+wklsrnbSvvSepBIwzY+E81R8/FKVTs+O+
X-Mailman-Approved-At: Mon, 22 Jul 2013 05:18:57 -0700
Cc: tsvwg <tsvwg@ietf.org>, "robin.seggelmann" <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: Fri, 12 Jul 2013 18:15:25 -0000

Hi Michael,
I think this addresses my earlier comments (and thanks for the responses on
the other questions earlier).

cheers,
jamal


On Fri, Jul 12, 2013 at 11:21 AM, Michael Tuexen <tuexen@fh-muenster.de>wrote:

> On Jul 10, 2013, at 11:48 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
>
> >
> > Hi Michael,
> >
> > On Wed, Jul 10, 2013 at 3:42 AM, Michael Tuexen <tuexen@fh-muenster.de>
> wrote:
> >
> > 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.
> >
> > Ok,  so the last fragment essentially doesnt get acknowledged before we
> > abandon ship. And the other stat indicates we abandoned while we still
> had some
> > sitting locally. Is the intersection of the two (some are sent but not
> acked and
> > some are still sitting locally) implying both stats will be incremented?
> >
> > Other than the perceived ambiguity -  why do i care to know about the
> > two types of abandoned messages in a user app? I  will have to sum
> > those two, so why not just give me one stat?
> >
> > BTW: the doc will benefit from such a small description as you gave me
> > above.
> The new revision contains some clarification:
> http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-02
>
> Best regards
> Michael
> >
> > 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.
> >
> >
> > You answered the essence of my question.
> > Silly follow up: I am assuming that event will come with an EOR?
> > To use your example (at receiver):
> > EPOLLIN, recvmsg chunk1, chunk2, EAGAIN
> > EPOLLIN, recvmsg SCTP_PARTIAL_DELIVERY_EVENT, EOR
> >
> > cheers,
> > jamal
>
>

v2.23.0 | Report a Bug | By Email