Re: [P2PSIP] Broken Stop and Wait Algorithm?
"Bless, Roland (TM)" <roland.bless@kit.edu> Mon, 21 October 2013 08:24 UTC
Return-Path: <roland.bless@kit.edu>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D5D11E8337 for <p2psip@ietfa.amsl.com>; Mon, 21 Oct 2013 01:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.337
X-Spam-Level:
X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 q6sMPupT3b5k for <p2psip@ietfa.amsl.com>; Mon, 21 Oct 2013 01:24:26 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id F149E11E817E for <p2psip@ietf.org>; Mon, 21 Oct 2013 01:24:24 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1VYAmg-00067s-QG; Mon, 21 Oct 2013 10:24:21 +0200
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1VYAmh-0007HU-Gv; Mon, 21 Oct 2013 10:24:19 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 4E30DA80705; Mon, 21 Oct 2013 10:24:19 +0200 (CEST)
Message-ID: <5264E4B3.5020006@kit.edu>
Date: Mon, 21 Oct 2013 10:24:19 +0200
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Michael Chen <michaelc@idssoftware.com>, P2PSIP WG <p2psip@ietf.org>
References: <20131018154320.59ca11a9ba9389561a029f06442e67fa.2a6464af81.mailapi@email03.secureserver.net>
In-Reply-To: <20131018154320.59ca11a9ba9389561a029f06442e67fa.2a6464af81.mailapi@email03.secureserver.net>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1382343861.
Subject: Re: [P2PSIP] Broken Stop and Wait Algorithm?
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 08:24:37 -0000
Hi Michael, Am 19.10.2013 00:43, schrieb Michael Chen: > Your fragment re-assembler must tolerate duplicate fragments, because it > is the nature of the UDP transport. By comparison, ACK is never repeated. Thanks for clarification. I guessed that it's up to the upper layers to deal with it, but IMHO this actually an unnecessary potential additional source of duplicated fragments besides IP packet duplication and if you don't care about duplicates you can even leave out sequence numbers in the stop and wait protocol... Detecting duplicated fragments may not always help: If you have a single fragment only, you'll immediately pass it up to the message transport for instance. So in this case you need to check for duplicate transaction IDs or rely on the implementation (sec. 6.2.1.): Receiving nodes MUST generate semantically equivalent responses to retransmissions of the same request (this can be determined by transaction ID) if the request is received within the maximum request lifetime (15 seconds). > The sequence number must always incremented so that the receiver can > build the FramedMessage.received bitmask for the last 32 fragments. Yes, I read that part, so that you can estimate loss rates or RTTs. > --------- Original Message --------- > Subject: [P2PSIP] Broken Stop and Wait Algorithm? > From: "Roland Bless" <roland.bless@kit.edu> > Date: 10/18/13 12:46 pm > To: "P2PSIP WG" <p2psip@ietf.org> > > Hi all, > > while implementing more of the RELOAD protocol we came across > the following issue: > > In sec. 6.6.3.1. Stop and Wait Sender Algorithm > http://tools.ietf.org/html/draft-ietf-p2psip-base-26#section-6.6.3.1 > > the spec says: > For each retransmission, the sequence number MUST be incremented. > > Retransmissions continue until a response is received, or until a > total of 5 requests have been sent or there has been a hard ICMP > error [RFC1122] or a TLS alert. The sender knows a response was > received when it receives an ACK with a sequence number that > indicates it is a response to one of the transmissions of this > messages. > > > This would cause potential duplicates at the receiving side: > > A B > ---------> FramedMsg #1 -------> ---> deliver FramedMsg #1 > > |*drop* <-- Ack #1 ><---------- > > (A: timeout > + retransmit) > > ---------> FramedMsg #2 -------> ---> deliver FramedMsg #2 > (same as above, i.e. > *duplicate*). > <----------- Ack #2 ><----------- > > (A: ack received, > transmit next frame) > > ---------> FramedMsg #3 -------> ---> deliver FramedMsg #3 > > Given the current scheme, the receiver cannot > distinguish between the retransmitted frame (#2) and > a new one (#3). What was the reason to use _new_ sequence numbers > for retransmissions? Unless you increment the > sequence number by more than 5 for each _new_ > frame, the receiving side could not filter out > duplicates. > > Did I miss something?
- [P2PSIP] Broken Stop and Wait Algorithm? Roland Bless
- Re: [P2PSIP] Broken Stop and Wait Algorithm? Michael Chen
- Re: [P2PSIP] Broken Stop and Wait Algorithm? Bless, Roland (TM)