Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
"Buford, John F (John)" <buford@avaya.com> Tue, 04 September 2012 16:05 UTC
Return-Path: <buford@avaya.com>
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 <sam@ietfa.amsl.com>; 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 <sam@ietfa.amsl.com>; 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 <sam@irtf.org>; 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)" <buford@avaya.com>
To: "sam@irtf.org" <sam@irtf.org>
Date: Tue, 04 Sep 2012 12:05:57 -0400
Thread-Topic: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
Thread-Index: Ac2KtufkQKfROgL4Q1ybLKQwZcdbxQ==
Message-ID: <ACCC07BD69AAD84B9383C920F3EBD20343554B0576@DC-US1MBEX5.global.avaya.com>
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" <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" <sam.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/sam>, <mailto:sam-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/sam>
List-Post: <mailto:sam@irtf.org>
List-Help: <mailto:sam-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/sam>, <mailto:sam-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Sep 2012 16:06:13 -0000
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. 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] Review of draft-samrg-sam-baseline-protocol… Marc Petit-Huguenin
- Re: [SAM] Review of draft-samrg-sam-baseline-prot… Dr Mario Kolberg
- Re: [SAM] Review of draft-samrg-sam-baseline-prot… Marc Petit-Huguenin
- Re: [SAM] Review of draft-samrg-sam-baseline-prot… John Buford
- Re: [SAM] Review of draft-samrg-sam-baseline-prot… Marc Petit-Huguenin
- Re: [SAM] Review of draft-samrg-sam-baseline-prot… John Buford
- Re: [SAM] Review of draft-samrg-sam-baseline-prot… Buford, John F (John)
- Re: [SAM] Review of draft-samrg-sam-baseline-prot… Marc Petit-Huguenin