From buford@avaya.com Tue Sep 4 09:05:26 2012 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B85911E809A for ; Tue, 4 Sep 2012 09:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J03JEHTzhgsp for ; Tue, 4 Sep 2012 09:05:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8424011E808A for ; Tue, 4 Sep 2012 09:05:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAA8mRlCHCzI1/2dsb2JhbABFgkq1JIM9gQeCIAEBAQECARIbTAUNAQgNC2AmAQQODRqHZQadWp0AkV9gA5taihmCfw X-IronPort-AV: E=Sophos;i="4.80,368,1344225600"; d="scan'208,217";a="25283778" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Sep 2012 12:00:12 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Sep 2012 11:44:25 -0400 Received: from DC-US1MBEX5.global.avaya.com ([169.254.2.145]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 4 Sep 2012 12:05:21 -0400 From: "Buford, John F (John)" To: "sam@irtf.org" Date: Tue, 4 Sep 2012 12:05:57 -0400 Thread-Topic: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00 Thread-Index: Ac2KtufkQKfROgL4Q1ybLKQwZcdbxQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_ACCC07BD69AAD84B9383C920F3EBD20343554B0576DCUS1MBEX5glo_" MIME-Version: 1.0 Cc: "marc@petit-huguenin.org" Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:06:13 -0000 --_000_ACCC07BD69AAD84B9383C920F3EBD20343554B0576DCUS1MBEX5glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marc, Below was one item you raised previously. However I think this is no longer relevant to our draft, since all of our m= essages are being mapped to exp_{a,b}_req, exp_{a,b}_rsp, which enables response code +1 to request cod= e for all messages. That is, in previous draft we introduced our own experimental message codes= beyond those listed in 14.8 of RELOAD; but we aren't using that approach now that RELOAD has introduced= 2 sets of experimental messages. As far as I can tell, we don't depend upon any special request-response mat= ching for RELOAD implementation. Regards, John -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/24/2011 10:31 PM, John Buford wrote: > Agree with the dictionary definition suggestion. > > For the JoinRequest =3D> JoinAccept,JoinReject 3-some, > we could do JoinRequest =3D> JoinResponse with sub-types for the response > Accept,Reject > > I wasn't aware that all message routing required an encoded "+1" response= . OK, let me backtrack a little bit here. After checking the spec, I do not = think that you have to use a ForwardingOptions for this as the nodes will be happ= y to route any of your messages. The real problem would be in the interpretatio= n by an implementation of this text in 5.2.1: "Because messages may be lost in transit through the overlay, RELOAD incorporates an end-to-end reliability mechanism. When an originating node transmits a request it MUST set a timer to the current overlay-reliability-timer. If a response has not been received when the timer fires, the request is retransmitted with the same transaction identifier. The request MAY be retransmitted up to 4 times (for a total of 5 messages). After the timer for the fifth transmission fires, the message SHALL be considered to have failed. Note that this retransmission procedure is not followed by intermediate nodes. They follow the hop-by-hop reliability procedure described in Section 5.6.3." The question here is how does this mechanism matches a response with a requ= est. My initial interpretation was that a response has 1) the same transaction_i= d and 2) either message_code equals to the request message_code + 1 or to the error value (0xffff). So I guess that it depends on the interpretation of = a particular implementation. In all cases, I would suggest to ask the author= s of draft-ietf-p2psip-base for a clarifications on the rules to use to match a response with a request. If they say that my interpretation is correct, th= en you will have to use the modification that you proposed above. If they say= that only the transaction_id is needed to match them, then your original proposa= l would work. > > Thanks for suggestions. > > John --_000_ACCC07BD69AAD84B9383C920F3EBD20343554B0576DCUS1MBEX5glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marc,=

 

Below wa= s one item you raised previously.

&= nbsp;

However I think this is no longer relev= ant to our draft, since all of our messages are being mapped to  =

exp_{a,b}_req, exp_{a,b}_rsp, which enables = response code +1 to request code for all messages.

That is, in previous draft we introduced our own experimental = message codes beyond those listed in 14.8

of RELOAD; but we aren’t using that approach now that RELOAD has in= troduced 2 sets of experimental messages.

 

As far as I can tell, we don= 217;t depend upon any special request-response matching for RELOAD implemen= tation.

 

Regards,

John

 

-----BEGIN PGP= SIGNED MESSAGE-----

Hash: SHA1

 

On 11/= 24/2011 10:31 PM, John Buford wrote:

>= ; Agree with the dictionary definition suggestion.

>

> For the JoinRequ= est =3D> JoinAccept,JoinReject 3-some,

> we could do JoinRequest =3D> JoinResponse with sub-types for the = response

> Accept,Reject

>

> I wasn= 't aware that all message routing required an encoded "+1" respon= se.

 

OK, let me backtrack a little bit here.  After checking the spec= , I do not think

that you have to use a = ForwardingOptions for this as the nodes will be happy to

route any of your messages.  The real problem would b= e in the interpretation by

an implementa= tion of this text in 5.2.1:

 <= /o:p>

"Because messages may be lost in transit= through the overlay, RELOAD

incorporat= es an end-to-end reliability mechanism.  When an

originating node transmits a request it MUST set a timer to = the

current overlay-reliability-timer.&= nbsp; If a response has not been

receiv= ed when the timer fires, the request is retransmitted with the

same transaction identifier.  The request MAY = be retransmitted up to

4 times (for a t= otal of 5 messages).  After the timer for the fifth

transmission fires, the message SHALL be considered to ha= ve failed.

Note that this retransmissio= n procedure is not followed by

intermed= iate nodes.  They follow the hop-by-hop reliability procedure

described in Section 5.6.3."

 

The questio= n here is how does this mechanism matches a response with a request.

My initial interpretation was that a response= has 1) the same transaction_id

and 2) e= ither message_code equals to the request message_code + 1 or to the

error value (0xffff).  So I guess that it = depends on the interpretation of a

parti= cular implementation.  In all cases, I would suggest to ask the author= s of

draft-ietf-p2psip-base for a clarif= ications on the rules to use to match a

= response with a request.  If they say that my interpretation is correc= t, then

you will have to use the modific= ation that you proposed above.  If they say that

only the transaction_id is needed to match them, then your or= iginal proposal

would work.

 

> =

> Thanks for suggestions.

<= p class=3DMsoNormal>>

> John=

= --_000_ACCC07BD69AAD84B9383C920F3EBD20343554B0576DCUS1MBEX5glo_-- From petithug@acm.org Wed Sep 5 07:50:25 2012 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1D21F8621 for ; Wed, 5 Sep 2012 07:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001, SARE_RMML_Stock1=0.21, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdjZmtMxaoAk for ; Wed, 5 Sep 2012 07:50:24 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6921F84E1 for ; Wed, 5 Sep 2012 07:50:24 -0700 (PDT) Received: from [IPv6:2001:5c0:1515:1100:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1515:1100:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D03C520E87; Wed, 5 Sep 2012 14:50:22 +0000 (UTC) Message-ID: <504766AC.6070207@acm.org> Date: Wed, 05 Sep 2012 07:50:20 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: "Buford, John F (John)" References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "sam@irtf.org" Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:50:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi John, On 09/04/2012 09:05 AM, Buford, John F (John) wrote: > Marc, > > > > Below was one item you raised previously. > > > > However I think this is no longer relevant to our draft, since all of our > messages are being mapped to > > exp_{a,b}_req, exp_{a,b}_rsp, which enables response code +1 to request > code for all messages. > > That is, in previous draft we introduced our own experimental message codes > beyond those listed in 14.8 > > of RELOAD; but we aren’t using that approach now that RELOAD has > introduced 2 sets of experimental messages. > > > > As far as I can tell, we don’t depend upon any special request-response > matching for RELOAD implementation. Yes, but this is still not implementable. First of all there is no explanation on how the sub-types listed in section 15 are used. -base does not define the format of exp_a_req, exp_a_ans, exp_b_req or exp_b_ans, so this spec has to provide the definitions of these requests/answers for this usage, in which the sub-type will be defined. Then there is "Create Tree" (section 7.2.1), where some of the text seems to say that this is a new Request/Response (and the example seems to support that) but the rest talks about a Store. So is it a new request/response or is it a Store? Additionally, and assuming it is a Store, then the rules listing at the end of the section do not match any existing access control policy, so a new one would have to be defined. And talking about example, it seems to not have been updated for the messages, i.e. none of the JoinXXX requests are matched with JoinXXX answers. Note that this is still not a complete review, just immediate problems that I see preventing a review (as I do reviews by implementing I-Ds, or in this case, evaluating what I would do to implement them). > > > > Regards, > > John > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 11/24/2011 10:31 PM, John Buford wrote: > >> Agree with the dictionary definition suggestion. > >> > >> For the JoinRequest => JoinAccept,JoinReject 3-some, > >> we could do JoinRequest => JoinResponse with sub-types for the response > >> Accept,Reject > >> > >> I wasn't aware that all message routing required an encoded "+1" >> response. > > > > OK, let me backtrack a little bit here. After checking the spec, I do not > think > > that you have to use a ForwardingOptions for this as the nodes will be > happy to > > route any of your messages. The real problem would be in the > interpretation by > > an implementation of this text in 5.2.1: > > > > "Because messages may be lost in transit through the overlay, RELOAD > > incorporates an end-to-end reliability mechanism. When an > > originating node transmits a request it MUST set a timer to the > > current overlay-reliability-timer. If a response has not been > > received when the timer fires, the request is retransmitted with the > > same transaction identifier. The request MAY be retransmitted up to > > 4 times (for a total of 5 messages). After the timer for the fifth > > transmission fires, the message SHALL be considered to have failed. > > Note that this retransmission procedure is not followed by > > intermediate nodes. They follow the hop-by-hop reliability procedure > > described in Section 5.6.3." > > > > The question here is how does this mechanism matches a response with a > request. > > My initial interpretation was that a response has 1) the same > transaction_id > > and 2) either message_code equals to the request message_code + 1 or to > the > > error value (0xffff). So I guess that it depends on the interpretation of > a > > particular implementation. In all cases, I would suggest to ask the > authors of > > draft-ietf-p2psip-base for a clarifications on the rules to use to match a > > response with a request. If they say that my interpretation is correct, > then > > you will have to use the modification that you proposed above. If they > say that > > only the transaction_id is needed to match them, then your original > proposal > > would work. > > > >> > >> Thanks for suggestions. > >> > >> John > > > > _______________________________________________ SAM mailing list > SAM@irtf.org http://www.irtf.org/mailman/listinfo/sam - - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQR2Z0AAoJECnERZXWan7EBKwQAIPRqRRb5NvSGYFJ88PDBOkf jEVbaoTGnYAvCyjogNEvqP14zZnac0yTj6PFLYtbunFxQgmUlDd0TaFWcouEOw6I T1O4pqcezyXIvr11CkQxb+78q9V8W3ZcJD51GQIW1WAwaQGrXzP4Zqf+9ilvPv1r LfxViHhqTy9xY2Ba+1q8Wnwh5xciOG9RV50tCvJp9qIyaUEMTvqzL0ioGAf5t2XD 4JzrGRQfw6w8BNX1hh5+6lGY1WvFNqLQpqxuihUr3HkyMy6lzSy0LGRsWwJaXARh +Zt4piQA1ABX3VTCTQa4RiAnZ4YlCdSSWXuCVnvQT/OGGhy62HIsCWXT+Crl3i0Y zhybYPj8e2oaEvzPDPTmHoVUG2uuCDUftExfHnzHOPNZiQltbjE2t9iIokmS6aHq dbj+N1dVcv0T9xcgaVdXkoJKWp4Xs0kmV0IqcTsYJc8VbHLgCrSRgx1YcabXtwe0 +3hY+BxbbHLf05rV6h7OoymHtaAq8FbtL+lsQzlocun/4RUoS4FG5CITQUEFGIS2 11gSMe3JSAuhG2h5Bz7pYZ+9cHKyEw54b9TUZTsu0yiobjMpVYC9D4usIOKbIwUB vDNCisn+DCezVmkwHhkPVkFmI1MjzvbRgDyokih+GZm69j9NLUGthBDI1hbf1nVJ wzN4kOYAVNFyCLzdPwbR =bIeA - -----END PGP SIGNATURE----- - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQR2aqAAoJECnERZXWan7ErYIP/AqS7mgihFyyUDHmiA/9LAmr pA1f6zVF4tQFvBvo6WGUJT5uruIV46ZLadOzRZjVrLrC9u7y+fnb+QbaghbvfLFx UDF3HK8P1Z8NJcH2yLsxw4nH4asm0uvrSxWpB09AOMkIlmoTNG+uyk8JPu6grtHZ hSzPp5qpoywrvHhbvHBag8jrQqvAKXKdjU1Vt8Cb7y8rbwfWna/IpkH9xPMf3GTA 9SFC/g0PAh80cajjWxBBBhpTKIutMeTYPS27KauuTLoQFYc1cUr0XJtBfo/g/8pm qFIDFjTCMQJKI8HhVhZh8f8yzs40CHr7yrHNCP9QUCoIBvaA2Ipo7vlYoUyEh4GH joxSfL1zSUUXIrJ9DHxgaQWXc85vbtRNfT7Lqp7VbVx2N5KEjxQgfoON5Czm3dBc EQXXTkuVWXBfdSrJpjlBoxQzAfQMv+Th1VIn52HmZrvj90DbZgeyCp6pJSJeKLK1 y/6+DEacHDi6h8p/WCRIUblD8g6cYBlc6JJhuDjrfR41Op20Ut+ZndkdSPzOK6Sp pqdWtrFa008OLEBk3sBh+fDv/aGC4geGiS5zSrVjIivY+fkMlwpO0/l4GDbzfJ30 mrRx3aEkgOeOIQNwsxk0l4lzXmfPA276AAirePFZadRgS3ZeMMz5LjWsGAlvgBJ4 OzhtfiLu0f0laYisCXv4 =rkIT -----END PGP SIGNATURE----- From lars@netapp.com Wed Sep 12 10:04:07 2012 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E6B21F86C5 for ; Wed, 12 Sep 2012 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.934 X-Spam-Level: X-Spam-Status: No, score=-11.934 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, SARE_NETPROD=0.111] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdnSTDiOEadW for ; Wed, 12 Sep 2012 10:04:06 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C285821F869E for ; Wed, 12 Sep 2012 10:04:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,410,1344236400"; d="p7s'?scan'208";a="688826293" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Sep 2012 10:04:06 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q8CH46pP005113 for ; Wed, 12 Sep 2012 10:04:06 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.212]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0309.002; Wed, 12 Sep 2012 10:04:05 -0700 From: "Eggert, Lars" To: "sam@irtf.org" Thread-Topic: Call for Nominations: Applied Networking Research Prize 2013 Thread-Index: AQHNkQid8S5j0ypJIEq0cxr663tnDA== Date: Wed, 12 Sep 2012 17:04:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_780F1960-0510-4EE2-B058-9B7E8B7E43CB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [SAM] Call for Nominations: Applied Networking Research Prize 2013 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "anrp@irtf.org" List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:04:07 -0000 --Apple-Mail=_780F1960-0510-4EE2-B058-9B7E8B7E43CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2013 http://irtf.org/anrp ******************************************************************** *** Submit nominations for the 2013 award period of the *** *** Applied Networking Research Prize until November 30, 2012! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: =95 cash prize of $500 (USD) =95 invited talk at the IRTF Open Meeting =95 travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) =95 recognition at the IETF plenary =95 invitation to related social activities =95 potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one=92s own paper) and third-party nominations (nominating someone else=92s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year=92s IETF meetings in person and in its entirety. Nominations must include: =95 the name and email address of the nominee =95 a bibliographic reference to the published (or accepted) nominated paper =95 a PDF copy of the nominated paper =95 a statement that describes how the nominated paper fulfills the goals of the award =95 a statement about which of the year=92s IETF meetings the nominee would be available to attend in person and in its entirety =95 a brief biography or CV of the nominee =95 optionally, any other supporting information (link to nominee=92s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2013/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. IMPORTANT DATES Applications close: November 30, 2012 (hard) Notifications: December 20, 2012 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2013-flyer.pdf --Apple-Mail=_780F1960-0510-4EE2-B058-9B7E8B7E43CB Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkxMjE3MDQxMVowIwYJKoZIhvcNAQkEMRYEFBjT aX077WTgDs97msFn1R17+s6zMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBACQwT7IF jdmetrQZkD54ZZho7jcUM4UVNlhy/1J3tC61BUY16yMq31yf3HMyAX9jcY75m1P1l3inwOBrYW0x m8ErioA1TcOmxkE0BwzrqqG3E1VZL0j4qkuGxNAGvU3kzW3lMsWMk/vKZ5qQS96c49p7UqDlJDMt UlFPFDm8Ohwj3Lt6gIDwf6gvhACBuT7ggDKt0PD/bX7vu5ffoVckmXSgTivl1pGj+Po8p9KcDUHU vDb7sXZSHQ/X8LCz5XCueFDNbBhLzHWWv0DyDbImt609q59QcqIHkpXNI05/wPTsApd/2HAe2tjI 9gythuRUMkAFsBawJgR7AgUjErnoU54AAAAAAAA= --Apple-Mail=_780F1960-0510-4EE2-B058-9B7E8B7E43CB-- From wwwrun@ietfa.amsl.com Wed Sep 26 10:03:05 2012 Return-Path: X-Original-To: sam Delivered-To: sam@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 0F97F21F85A1; Wed, 26 Sep 2012 10:03:05 -0700 (PDT) From: "Glen via RT" In-Reply-To: References: <34E66D8E-3849-4260-BDB7-1A5D7813F3E2@vpnc.org> <1A0FA67E-5A04-4A87-81F2-1EA0DD29B1E3@vpnc.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #50961 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: glen@amsl.com To: "OtherRecipients of www.ietf.org/rt Ticket #50961":; MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 26 Sep 2012 10:03:04 -0700 X-Mailman-Approved-At: Wed, 26 Sep 2012 13:38:11 -0700 Subject: [SAM] [www.ietf.org/rt #50961] The IETF rsync server is down again X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Reply-To: ietf-action@ietf.org List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:03:05 -0000 On Wed Sep 26 09:39:37 2012, paul.hoffman@vpnc.org wrote: > > The IETF rsync server was not, in fact, down. All available > connections were being used, and that > > situation has been rectified. > > Thanks. Out of curiosity, why did you set "max connections" in > rsyncd.conf? > > --Paul Hoffman Hi Paul - Glen here. This has been escalated to me. I always try to set sane limits on all processes, to prevent one runaway from consuming the entire server. It seems like a responsible way to proceed; and, in this case, my guess is that the offending external site could have used up a much larger number of processes, potentially impacting the rest of the server, had those limits not been set. I hope this information is helpful, let me know if you need more. Glen Glen Barney IT Director AMS (IETF Secretariat) From wwwrun@ietfa.amsl.com Wed Sep 26 12:22:59 2012 Return-Path: X-Original-To: sam Delivered-To: sam@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 677DE21F85DA; Wed, 26 Sep 2012 12:22:58 -0700 (PDT) From: "Glen via RT" In-Reply-To: References: <34E66D8E-3849-4260-BDB7-1A5D7813F3E2@vpnc.org> <1A0FA67E-5A04-4A87-81F2-1EA0DD29B1E3@vpnc.org> Message-ID: Precedence: bulk X-RT-Loop-Prevention: www.ietf.org/rt RT-Ticket: www.ietf.org/rt #50961 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: glen@amsl.com To: "OtherRecipients of www.ietf.org/rt Ticket #50961":; MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 Date: Wed, 26 Sep 2012 12:22:58 -0700 X-Mailman-Approved-At: Wed, 26 Sep 2012 13:38:11 -0700 Subject: [SAM] [www.ietf.org/rt #50961] The IETF rsync server is down again X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Reply-To: ietf-action@ietf.org List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:22:59 -0000 On Wed Sep 26 10:30:06 2012, paul.hoffman@vpnc.org wrote: > Yeah, that makes sense for a box that has multiple services on it. > However, it means that you (in the future) need to monitor when the > limit is being hit for, say, more than an hour. And then do > something about it, which is harder. Yes, I totally agree. I'm building a comprehensive monitoring system for stuff like this for AMS, and the IETF, so your point is well-taken and we will definitely be adding something like this in shortly. > Glad I only do ops as a hobby... Ahh, I dream of such luxury! Best regards, Glen