From br@brianrosen.net Fri Oct 11 05:58:12 2013 Return-Path: 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 5F60921E8100 for ; Fri, 11 Oct 2013 05:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.323 X-Spam-Level: X-Spam-Status: No, score=-103.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, 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 BMBDt8irmURn for ; Fri, 11 Oct 2013 05:58:07 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5B821F9AF0 for ; Fri, 11 Oct 2013 05:57:43 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id r5so2865916qcx.23 for ; Fri, 11 Oct 2013 05:57:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=VDY0bgv2PSMW6aDs1Llm3dI7ojsuGjGofSlGASQb5bc=; b=MrypIJT4IMITGlS4i1VPkUPqW/rcL9sYEToswHKgRJ9Zyezt1fRAYA2Tnfmqe/HnM1 3uwXg9XgMK2IQwv2QqmLte5jO2UX7kQrYxElVKK+QcLrksGasP2USy2wkcqIxmgkBD18 T6ih0LmdP62swdViVSNrS0Ne9Fjiy6+S5H5o8scn5rYncWiYGWpW0+HgNxvHw4oTACX8 b/1ryLwcwt190S0zZMzssvO9G6KQAo0UfKzf9IP045WPB9Ei/zcl9iS7RvSR8meVU0j1 Fe6lyPwYMlRWktj4AVa9t6pNtQQPmZnO3vyI8H+AGwybezBZGh1B1LGMkHFxw5Awm0Nu 5oVA== X-Gm-Message-State: ALoCoQmT3kqQJDD5YkYmM79xs6opWnIerFduLvEc2iarwBbBXjkA2I3SjB/G04jb9Of99UirYOzp X-Received: by 10.224.6.10 with SMTP id 10mr16547543qax.31.1381496262649; Fri, 11 Oct 2013 05:57:42 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id h2sm97006596qev.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Oct 2013 05:57:42 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628" Date: Fri, 11 Oct 2013 08:57:40 -0400 References: <52579E47.6020706@ericsson.com> To: p2psip@ietf.org, siprec@ietf.org Message-Id: <6CCB5952-2369-4E74-A4B8-B3E102CFEC1A@brianrosen.net> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [P2PSIP] Fwd: [RAI] NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:58:12 -0000 --Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: Gonzalo Camarillo > Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - = APP, OAM, RAI, TSV > Date: October 11, 2013 2:44:23 AM EDT > To: >=20 > Folks, >=20 > we need more volunteers (see email below). If you are thinking of > running but still have some doubts about it, feel free to talk with me > (or with any of the former RAI ADs) and we will be happy to clarify > everything for you. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > -------- Original Message -------- > Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, = RAI, TSV > Date: Tue, 8 Oct 2013 11:45:14 -0700 > From: NomCom Chair > Reply-To: > To: IETF Announcement List > CC: >=20 > UPDATE: nominations are too sparse in several of the IESG areas: APP, = OAM, > RAI, and TSV. If you know one or more of those areas, exercise your = social > network and submit nominations. We'll be very grateful! >=20 > Is there someone you work with at IETF who has leadership potential = and a > growing track record? Please read this Nomcom call for nominations and > consider > nominating her or him. Or several folks! Deadline for nominations is > October 18. > Nominate soon to give your nominee(s) plenty time to fill in the > questionnaire. >=20 > If you're nominated, even if you support the present incumbent, being > reviewed > by Nomcom is great IETF experience. The questionnaire offers a chance = to > think about IETF and about your area. Whether or not your candidacy > progresses > this time, you'll have gained some valuable insights, and you'll have > contributed > greatly. This process only works because many IETFers take part; = please > join in. >=20 > Lots more, including which positions are open, how to make a = nomination > (including nomination of yourself), and how to send us your feedback = on > the desired expertise, follows. >=20 > IETFers, let's hear from you! Make nominations, accept nominations! >=20 > If you have any questions about the process, feel free to get in touch > with me. >=20 > Best regards, >=20 > Allison for the Nomcom >=20 > Allison Mankin > Nomcom Chair 2013-14 >=20 > ----- The Info You Need for Nominating ----- >=20 > The 2013-14 Nominating Committee (Nomcom) is seeking nominations > from now until October 18, 2013. The open positions being considered > by this year's Nomcom can be found later in this section, and also on > this year's Nomcom website: >=20 > https://datatracker.ietf.org/nomcom/2013/ >=20 > Information about the desired expertise for positions is here: > https://datatracker.ietf.org/nomcom/2013/expertise >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2013 home page, or by visiting the following URL: >=20 > https://datatracker.ietf.org/nomcom/2013/nominate/ >=20 > Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > Nominations may also be made by email to nomcom13 at ietf.org. > If you nominate by email, please include the word "Nominate" in the = Subject > and indicate in the email who is being nominated, their email address = (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you use email, please use a separate = email for > each person you nominate, and for each position (if you are nominating = one > person for multiple positions). >=20 > Self-nomination is welcome! No need to be shy. >=20 > Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and = will > not be disclosed. >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the > Nomcom on or before October 18, 2013. Please submit your nominations > as early as possible for the sake of your nominees, as we've set the > questionnaire submission deadline for October 25, 2013. >=20 > The list of people and posts whose terms end with the March 2014 IETF > meeting, > and thus the positions for which we are accepting nominations: >=20 > IAOC > Chris Griffiths >=20 > IAB > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig >=20 > IESG > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF. Also, please give serious consideration to accepting = nominations > you receive. >=20 > The summaries of the desired expertise for the positions, developed by = the > respective bodies, are found at: >=20 > https://datatracker.ietf.org/nomcom/2013/expertise/ >=20 > In addition to nominations, the Nomcom seeks community input on > the positions themselves. We need and welcome the community's > views and input on the jobs within each organization. If you > have ideas on the positions' responsibilities (more, less, > different), please let us know. You can send us email about this to > nomcom13 at ietf.org, and we will use this feedback actively. >=20 > Thank you for your help in nominating a great pool of strong and = interesting > nominees! >=20 >=20 >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai --Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Gonzalo Camarillo = <Gonzalo.Camarillo@ericsson.= com>
Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for = Nominations - APP, OAM, RAI, TSV
Date: October 11, 2013 = 2:44:23 AM EDT

Folks,

we need more volunteers (see email below). If you are = thinking of
running but still have some doubts about it, feel free to = talk with me
(or with any of the former RAI ADs) and we will be happy = to clarify
everything for = you.

Cheers,

Gonzalo


-------- Original Message = --------
Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - = APP, OAM, RAI, TSV
Date: Tue, 8 Oct 2013 11:45:14 -0700
From: = NomCom Chair <nomcom-chair@ietf.org>
Rep= ly-To: <nomcom-chair-2013@ietf.org&= gt;
To: IETF Announcement List <ietf-announce@ietf.org>
C= C: <ietf@ietf.org>

UPDATE: = nominations are too sparse in several of the IESG areas:  APP, = OAM,
RAI, and TSV.  If you know one or more of those areas, = exercise your social
network and submit nominations.  We'll be = very grateful!

Is there someone you work with at IETF who has = leadership potential and a
growing track record? Please read this = Nomcom call for nominations and
consider
nominating her or him. Or = several folks! Deadline for nominations is
October 18.
Nominate = soon to give your nominee(s) plenty time to fill in = the
questionnaire.

If you're nominated, even if you support = the present incumbent, being
reviewed
by Nomcom is great IETF = experience.  The questionnaire offers a chance to
think about = IETF and about your area.  Whether or not your = candidacy
progresses
this time, you'll have gained some valuable = insights, and you'll have
contributed
greatly. This process only = works because many IETFers take part; please
join in.

Lots = more, including which positions are open, how to make a = nomination
(including nomination of yourself), and how to send us = your feedback on
the desired expertise, follows.

IETFers, = let's hear from you!  Make nominations, accept = nominations!

If you have any questions about the process, feel = free to get in touch
with me.

Best regards,

Allison for = the Nomcom

Allison Mankin
Nomcom Chair 2013-14

----- = The Info You Need for Nominating -----

The 2013-14 Nominating = Committee (Nomcom) is seeking nominations
from now until October 18, = 2013. The open positions being considered
by this year's Nomcom can = be found later in this section, and also on
this year's Nomcom = website:

https://datatracker.iet= f.org/nomcom/2013/

Information about the desired expertise = for positions is here:
=          https://datatracker.= ietf.org/nomcom/2013/expertise

Nominations may be made by = selecting the Nominate link at the top of
the Nomcom 2013 home page, = or by visiting the following = URL:

https://datatracker.ietf.org/nomcom/2013/nominate/

Note= that nominations made using the web tool require an = ietf.org
datatracker account. You can create a datatracker ietf.org = account
if you don't have one already by visiting the following = URL:

https://datatracker.ietf.org/accounts/create/

Nominatio= ns may also be made by email to nomcom13 at ietf.org.
If you nominate = by email, please include the word "Nominate" in the Subject
and = indicate in the email who is being nominated, their email address = (to
confirm acceptance of the nomination), and the position for which = you
are making the nomination. If you use email, please use a = separate email for
each person you nominate, and for each position = (if you are nominating one
person for multiple = positions).

Self-nomination is welcome!  No need to be = shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure = of Willing
Nominees" described in RFC 5680.  As stated in RFC = 5680: "The list of
nominees willing to be considered for positions = under review in the
current Nomcom cycle is not confidential". = Willing nominees for each
position will be listed in a publicly = accessible way - anyone with a
datatracker account may access the = lists.  In all other ways, the
confidentiality requirements of = RFC 3777/BCP10 remain in effect.  All
feedback and all Nomcom = deliberations will remain confidential and will
not be = disclosed.

In order to ensure time to collect sufficient = community feedback about
each of the willing nominees, nominations = must be received by the
Nomcom on or before October 18, 2013. =  Please submit your nominations
as early as possible for the = sake of your nominees, as we've set the
questionnaire submission = deadline for October 25, 2013.

The list of people and posts whose = terms end with the March 2014 IETF
meeting,
and thus the positions = for which we are accepting nominations:

IAOC
Chris = Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross = Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba = (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations = and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant = (Routing)
Sean Turner (Security)
Martin Stiemerling = (Transport)

Please be resourceful in identifying possible = candidates for these
positions, as developing our talent is a very = crucial requirement for
the IETF.  Also, please give serious = consideration to accepting nominations
you receive.

The = summaries of the desired expertise for the positions, developed by = the
respective bodies, are found = at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In = addition to nominations, the Nomcom seeks community input on
the = positions themselves.  We need and welcome the community's
views = and input on the jobs within each organization. If you
have ideas on = the positions' responsibilities (more, less,
different), please let = us know.  You can send us email about this to
nomcom13 at = ietf.org, and we will use this feedback actively.

Thank you for = your help in nominating a great pool of strong and = interesting
nominees!



__________________________________= _____________
RAI mailing = list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

= --Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628-- From roland.bless@kit.edu Fri Oct 18 12:46:27 2013 Return-Path: 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 30C2111E82A8 for ; Fri, 18 Oct 2013 12:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 9rOrdQOmrU9k for ; Fri, 18 Oct 2013 12:46:21 -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 CC43D21F9C38 for ; Fri, 18 Oct 2013 12:46:19 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1VXFzz-0005l1-Nr for ; Fri, 18 Oct 2013 21:46:18 +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 for id 1VXFzz-00081D-Pb; Fri, 18 Oct 2013 21:46:15 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 90B74A80119 for ; Fri, 18 Oct 2013 21:46:15 +0200 (CEST) Message-ID: <52619007.1060202@kit.edu> Date: Fri, 18 Oct 2013 21:46:15 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: P2PSIP WG X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 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 1382125578. Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:46:28 -0000 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? Regards, Roland From michaelc@idssoftware.com Fri Oct 18 15:43:38 2013 Return-Path: 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 EF35921F9A8C for ; Fri, 18 Oct 2013 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 0J3jeEWXoskL for ; Fri, 18 Oct 2013 15:43:25 -0700 (PDT) Received: from p3plwbeout03-03.prod.phx3.secureserver.net (p3plsmtp03-03-2.prod.phx3.secureserver.net [72.167.218.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8BC21F9B12 for ; Fri, 18 Oct 2013 15:43:22 -0700 (PDT) Received: from localhost ([72.167.218.244]) by p3plwbeout03-03.prod.phx3.secureserver.net with bizsmtp id emjM1m0015GyNsw01mjMBJ; Fri, 18 Oct 2013 15:43:21 -0700 X-SID: emjM1m0015GyNsw01 Received: (qmail 25937 invoked by uid 99); 18 Oct 2013 22:43:21 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_09d01da8832482feef822c9b09c67cf6" To: "Roland Bless" , "P2PSIP WG" From: "Michael Chen" In-Reply-To: <52619007.1060202@kit.edu> Date: Fri, 18 Oct 2013 15:43:20 -0700 Message-Id: <20131018154320.59ca11a9ba9389561a029f06442e67fa.2a6464af81.mailapi@email03.secureserver.net> X-Originating-IP: 75.85.78.244 User-Agent: MailAPI 24838 X-Sender: michaelc@idssoftware.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 22:43:39 -0000 --=_09d01da8832482feef822c9b09c67cf6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Roland, =20 Your fragment re-assembler must tolerate duplicate fragments, because it is the nature of the UDP transport. By comparison, ACK is never repeated. =20 The sequence number must always incremented so that the receiver can build the FramedMessage.received bitmask for the last 32 fragments. =20 Thanks =20 --Michael --------- Original Message --------- Subject: [P2PSIP] Broken Stop and Wait= Algorithm? From: "Roland Bless" Date: 10/18/13 12:46 pm To: "P2PSIP WG" Hi all, =20 while implementing more of the RELOAD protocol we came across the following issue: =20 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 =20 the spec says: For each retransmission, the sequence number MUST be incremented. =20 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. =20 =20 This would cause potential duplicates at the receiving side: =20 A B ---------> FramedMsg #1 -------> ---> deliver FramedMsg #1 =20 |*drop* <-- Ack #1 ><---------- =20 (A: timeout + retransmit) =20 ---------> FramedMsg #2 -------> ---> deliver FramedMsg #2 (same as above, i.e. *duplicate*). <----------- Ack #2 ><----------- =20 (A: ack received, transmit next frame) =20 ---------> FramedMsg #3 -------> ---> deliver FramedMsg #3 =20 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. =20 Did I miss something? =20 Regards, Roland _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --=_09d01da8832482feef822c9b09c67cf6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Roland,
 
Your fragment re-assembler must tolerate duplicate fragments, because = it
is the nature of the UDP transport. By comparison, ACK is never repeat= ed.
 
The sequence number must always incremented so that the receiver can
build the FramedMessage.received bitmask for the last 32 fragments.
 
Thanks
 
--Michael
--------- Original Message -----= ----
Subject: [P2PSIP] Broken Stop and Wait Algorithm?
From: "Roland B= less" <roland.bless@kit.edu>
Date: 10/18/13 12:46 pm
To: "P= 2PSIP WG" <p2psip@ietf.org>

Hi all,

while imp= lementing more of the RELOAD protocol we came across
the following is= sue:

In sec. 6.6.3.1. Stop and Wait Sender Algorithm
htt= p://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 r= eceived, or until a
total of 5 requests have been sent or there has b= een a hard ICMP
error [RFC1122] or a TLS alert. The sender knows a re= sponse was
received when it receives an ACK with a sequence number th= at
indicates it is a response to one of the transmissions of this
messages.


This would cause potential duplicates at t= he receiving side:

A B
---------> FramedMsg #1 ------= -> ---> deliver FramedMsg #1

|*drop* <-- Ack #1 >&= lt;----------

(A: timeout
+ retransmit)

---= ------> FramedMsg #2 -------> ---> deliver FramedMsg #2
(sam= e as above, i.e.
*duplicate*).
<----------- Ack #2 ><-= ----------

(A: ack received,
transmit next frame)
=
---------> FramedMsg #3 -------> ---> deliver FramedMsg #3<= br />
Given the current scheme, the receiver cannot
distinguis= h between the retransmitted frame (#2) and
a new one (#3). What was t= he reason to use _new_ sequence numbers
for retransmissions? Unless y= ou increment the
sequence number by more than 5 for each _new_
= frame, the receiving side could not filter out
duplicates.

Did I miss something?

Regards,
Roland
_________= ______________________________________
P2PSIP mailing list
P2PS= IP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--=_09d01da8832482feef822c9b09c67cf6-- From michaelc@idssoftware.com Sat Oct 19 06:19:41 2013 Return-Path: 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 5DFF111E81A9 for ; Sat, 19 Oct 2013 06:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 cTuJ+YGb3yyP for ; Sat, 19 Oct 2013 06:19:35 -0700 (PDT) Received: from p3plwbeout03-06.prod.phx3.secureserver.net (p3plsmtp03-06-2.prod.phx3.secureserver.net [72.167.218.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8C121F9FB0 for ; Sat, 19 Oct 2013 06:19:34 -0700 (PDT) Received: from localhost ([72.167.218.244]) by p3plwbeout03-06.prod.phx3.secureserver.net with bizsmtp id f1KZ1m0015GyNsw011KZyd; Sat, 19 Oct 2013 06:19:33 -0700 X-SID: f1KZ1m0015GyNsw01 Received: (qmail 6085 invoked by uid 99); 19 Oct 2013 13:19:33 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_21c725e1eb61fddc19a59fbb08c67f54" To: reload-it@implementers.org From: "Michael Chen" Date: Sat, 19 Oct 2013 06:19:33 -0700 Message-Id: <20131019061933.59ca11a9ba9389561a029f06442e67fa.92ef585bd6.mailapi@email03.secureserver.net> X-Originating-IP: 75.85.78.244 User-Agent: MailAPI 24838 X-Sender: michaelc@idssoftware.com Cc: p2psip@ietf.org Subject: [P2PSIP] Multiple node-id in an enrollment certificate X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 13:19:41 -0000 --=_21c725e1eb61fddc19a59fbb08c67f54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Marc, =20 I was wondering about its use case. If you use a multi-node-id certificate = on the wire, the receiver wouldn't know which one is being used. You can't = make a new cert with one node-id either, because it is signed by the root c= ert. =20 Thanks =20 --Michael --=_21c725e1eb61fddc19a59fbb08c67f54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hey Marc,
 
I was wondering about its use case. If you use a multi-node-id certifi= cate on the wire, the receiver wouldn't know which one is being used. You c= an't make a new cert with one node-id either, because it is signed by the r= oot cert.
 
Thanks
 
--Michael
--=_21c725e1eb61fddc19a59fbb08c67f54-- From internet-drafts@ietf.org Sun Oct 20 20:16:43 2013 Return-Path: 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 AA95A11E8480; Sun, 20 Oct 2013 20:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DWe6pZdrg2xn; Sun, 20 Oct 2013 20:16:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3A411E8455; Sun, 20 Oct 2013 20:16:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021031639.22701.7610.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 20:16:39 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-rpr-11.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 03:16:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Protocol = Working Group of the IETF. Title : An Extension to REsource LOcation And Discovery (RELOAD)= Protocol to Support Relay Peer Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-rpr-11.txt Pages : 14 Date : 2013-10-20 Abstract: This document proposes an optional extension to REsource LOcation And Discovery (RELOAD) protocol to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential use cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-rpr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-rpr-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-rpr-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Oct 20 20:18:17 2013 Return-Path: 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 9BF4C11E8487; Sun, 20 Oct 2013 20:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 LMi8qf3m+EUO; Sun, 20 Oct 2013 20:18:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3226611E8122; Sun, 20 Oct 2013 20:18:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021031817.22792.98092.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 20:18:17 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-drr-11.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 03:18:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Protocol = Working Group of the IETF. Title : An Extension to REsource LOcation And Discovery (RELOAD)= Protocol to Support Direct Response Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-drr-11.txt Pages : 17 Date : 2013-10-20 Abstract: This document proposes an optional extension to REsource LOcation And Discovery (RELOAD) protocol to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-drr-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-drr-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From roland.bless@kit.edu Mon Oct 21 01:24:36 2013 Return-Path: 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 ; 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 ; 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 ; 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)" 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 , P2PSIP WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" > Date: 10/18/13 12:46 pm > To: "P2PSIP WG" > > 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? From ietf-ipr@ietf.org Thu Oct 24 08:12:08 2013 Return-Path: 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 733FD11E833D; Thu, 24 Oct 2013 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 gXO8hOvyvePm; Thu, 24 Oct 2013 08:12:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD66311E8311; Thu, 24 Oct 2013 08:11:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: fluffy@cisco.com, bbl@lowekamp.net, ekr@rtfm.com, salman@cs.columbia.edu, hgs@cs.columbia.edu X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131024151159.2898.39492.idtracker@ietfa.amsl.com> Date: Thu, 24 Oct 2013 08:11:59 -0700 Cc: p2psip@ietf.org, ipr-announce@ietf.org Subject: [P2PSIP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-p2psip-base-26 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 15:12:08 -0000 Dear Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning = Schulzrinne: An IPR disclosure that pertains to your Internet-Draft entitled "REsource LOcation And Discovery (RELOAD) Base Protocol" (draft-ietf-p2psip-base) was submitted to the IETF Secretariat on 2013-10-24 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2223/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-p2= psip- base-26.""); The IETF Secretariat From radhika.r.roy.civ@mail.mil Wed Oct 30 10:20:01 2013 Return-Path: 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 D274C21F9D9A for ; Wed, 30 Oct 2013 10:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 ZyymcAQy33oR for ; Wed, 30 Oct 2013 10:19:55 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id E17F621F9CED for ; Wed, 30 Oct 2013 10:18:14 -0700 (PDT) Received: from UCOLHP3M.easf.csd.disa.mil (131.64.100.152) by edge-cols.mail.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Oct 2013 17:18:06 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.177]) by UCOLHP3M.easf.csd.disa.mil ([131.64.100.152]) with mapi id 14.03.0158.002; Wed, 30 Oct 2013 17:18:05 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: "p2psip@ietf.org" Thread-Topic: P2PSIP Products Info (UNCLASSIFIED) Thread-Index: Ac7Vk/mfALM2Gn0CRuCg4qfi9JDz6w== Date: Wed, 30 Oct 2013 17:18:05 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF55AA74BE@ucolhp9b.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0043_01CED572.76A9F180" MIME-Version: 1.0 Subject: [P2PSIP] P2PSIP Products Info (UNCLASSIFIED) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 17:20:02 -0000 ------=_NextPart_000_0043_01CED572.76A9F180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0044_01CED572.76A9F180" ------=_NextPart_001_0044_01CED572.76A9F180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Dear P2PSIP Members: I am seeking some information about P2PSIP products/prototypes developed by researchers and/or vendors. Any information related to the P2PSIP products will be extremely helpful. I will appreciate any information related to this sent to me via email. This is my personal enquiry for obtaining the info about the latest status related to the P2PSIP products. If needed, anyone can call me as well. Thanks in advance. Best regards, Radhika R. Roy A&S U.S. Army RDECOM CERDEC S&TCD 6010 Frankford St, C2/CNT East, Room 402-44 Aberdeen Proving Ground, MD 21005-5001 Tel (office): 443-395-7400 DSN:648-7400 Email: radhika.r.roy.civ@mail.mil PS: If any procurement is done, it follows the normal official procedures. Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_001_0044_01CED572.76A9F180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED
Caveats: NONE

Dear P2PSIP = Members:

 

I am seeking some information about P2PSIP = products/prototypes developed by researchers and/or = vendors.

 

Any information related to the P2PSIP products will be = extremely helpful.

 

I will = appreciate any information related to this sent to me via = email.

 

This is my personal enquiry for obtaining the info = about the latest status related to the P2PSIP products.

 

If needed, = anyone can call me as well.

 

Thanks in = advance.

 

Best regards,

 

Radhika R. = Roy

A&S=

U.S. Army RDECOM CERDEC = S&TCD

6010 Frankford St, = C2/CNT East, Room 402-44

Aberdeen Proving Ground, = MD  21005-5001

Tel (office): = 443-395-7400

DSN:648-7400

Email: radhika.r.roy.civ@mail.mil=

 

PS: If any procurement is done, it follows the normal = official procedures.

 


Classification: = UNCLASSIFIED
Caveats: NONE

------=_NextPart_001_0044_01CED572.76A9F180-- ------=_NextPart_000_0043_01CED572.76A9F180 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzEwMzAxNzE4MDNaMCMGCSqGSIb3DQEJBDEWBBTJy7XBrTij0+EBGARyOsEN y6vcKTBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAJKyiVv8j34dzEWhcxRCBqpWHZXHPOLpBmK8bdVqOtro23aC6JrvUUxkHYcDZsTpxUt4 z1m7Hr+qYPINoRo6o7J6POGDZDjZr4PyV9JODWelNG7FlaCqY2RdXr08t4kBwO9ozyueoVvuS4uW QAlGs3BtyxFSssSDVg39saMdwxg8dbdawDbXktZB+hVQ6a5/U3wRUN07tzKuujD7dkxV30w7TugO t+anvgYjcixcm0ak4BKXj/Q8NdockXlsvJf+6oTEgzbz1nvtlWgtCqANMFUvWrsTIU2FGFEkq+5z JiwDUOEfIVFgee2+0u+OIfT0Gh0/YajmczuGXfxq0GZD1aYAAAAAAAA= ------=_NextPart_000_0043_01CED572.76A9F180--