From fluffy@cisco.com Mon Mar 2 13:22:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60B53A68CD for ; Mon, 2 Mar 2009 13:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.657 X-Spam-Level: X-Spam-Status: No, score=-106.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWqQRLsCquTx for ; Mon, 2 Mar 2009 13:22:27 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1F1B43A6849 for ; Mon, 2 Mar 2009 13:22:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,291,1233532800"; d="scan'208";a="149465822" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 02 Mar 2009 21:22:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n22LMr8h013255 for ; Mon, 2 Mar 2009 13:22:53 -0800 Received: from dhcp-171-68-21-120.cisco.com (dhcp-171-68-21-120.cisco.com [171.68.21.120]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n22LMraB006411 for ; Mon, 2 Mar 2009 21:22:53 GMT Message-Id: <72FB0F54-0357-4D72-8E74-EFC94E874379@cisco.com> From: Cullen Jennings To: P2PSIP WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 13:22:58 -0800 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=404; t=1236028973; x=1236892973; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Comment=20on=20p2psip-diagnostics |Sender:=20; bh=SNpDPT2UHrO88DdXS3SFRnmId1ewwH+xtMbkcwcz2Rw=; b=uYgVkExPttkgHFpglxdauysSAjVi/+O1HIpY1jARimlBMMtyDKNxb0g+Vd s1Nvpxilo5y5dr7fhEqKUqJ+fvo2S8aEgd/o9jKJz5rkYtjug17bM15vEHPP Ab+TeVWY86; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2009 21:22:27 -0000 One comment on the Echo design.... I'm worried about a method where sending a single request can cause a whole bunch of responses. This has congestion and DOS issues. It is also not clear how all the retransmissions timers would work with it. We should think about if it is possible to move away from the one request, multiple responses design. Cullen From fluffy@cisco.com Mon Mar 2 13:45:58 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE7B3A6902 for ; Mon, 2 Mar 2009 13:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.655 X-Spam-Level: X-Spam-Status: No, score=-106.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6cElnywasjR for ; Mon, 2 Mar 2009 13:45:58 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 21E8C3A67F3 for ; Mon, 2 Mar 2009 13:45:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,291,1233532800"; d="scan'208";a="136764231" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2009 21:46:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n22LkOFi025504; Mon, 2 Mar 2009 13:46:24 -0800 Received: from dhcp-171-68-21-120.cisco.com (dhcp-171-68-21-120.cisco.com [171.68.21.120]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n22LkO2L028662; Mon, 2 Mar 2009 21:46:24 GMT Message-Id: <3647843D-53CE-4E07-AC84-3E0120FC136E@cisco.com> From: Cullen Jennings To: Gonzalo Camarillo In-Reply-To: <499FB831.80809@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 13:46:28 -0800 References: <499FB831.80809@ericsson.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=890; t=1236030384; x=1236894384; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Draft=20on=20P2P=20architect ures |Sender:=20; bh=7PgEDtenynm5PDEBX6iZdDQwY+ik6JIcAI1InpJIUn0=; b=i7mEr9X5sSzJoUgE+z8L0IpVsw9cftr7M4S4NqO7mERHjb1Q6bGhsp1Glb Zm794+zAVTy3S9oUxjkvYaWUCBRms/qHLfVbXuoxQ6D7L1YJTp1fQuJ1HEWO Mmzp9ItbZv; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "iab@iab.org IAB" , P2PSIP Mailing List Subject: Re: [P2PSIP] Draft on P2P architectures X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2009 21:45:59 -0000 This is great - thank you writing it. One topic that might help improve the draft is discussing incentives for peers. Most the successful P2P systems I can think of have put a bunch of thought into the incentives for peers to to things for other peers. When trying to decide if p2p is a good architecture for a given application, it's critical to think about "what are the incentives" Cullen On Feb 21, 2009, at 24:15 , Gonzalo Camarillo wrote: > Folks, > > the IAB has just submitted the following draft: > > http://www.ietf.org/internet-drafts/draft-iab-p2p-archs-00.txt > > Comments from people involved in this WG are especially appreciated. > > Thanks, > > Gonzalo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@idssoftware.com Mon Mar 2 21:25:38 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388203A6808 for ; Mon, 2 Mar 2009 21:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, SARE_OBFU_PART_ORT=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWc8ITkyAKmw for ; Mon, 2 Mar 2009 21:25:36 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 54A0B3A6ACD for ; Mon, 2 Mar 2009 21:25:35 -0800 (PST) Received: from [64.203.45.253] (helo=[10.9.0.1]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LeN8j-0003rX-QX; Tue, 03 Mar 2009 00:26:02 -0500 Message-ID: <49ACBFEB.7080106@idssoftware.com> Date: Mon, 02 Mar 2009 21:28:11 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Bruce Lowekamp References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9405ff7a2d6c47265fad7b1913254246ee6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.203.45.253 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 03 Mar 2009 05:25:38 -0000 Bruce, I have 2 suggestions for section "5.5.2.1. Framed Message Format" in the current Reload draft relevant to UDP fragmentation and retransmission. This section defined framed message as: enum {data (128), ack (129), (255)} FramedMessageType; struct { FramedMessageType type; select (type) { case data: uint24 sequence; opaque message<0..2^24-1>; case ack: uint24 ack_sequence; uint32 received; }; Suggestion 1: The 24-bit length for the message payload is unnecessary and should be removed. The message is DTLS record, which has its own size and integrity check scheme. Also, the UDP packet carries its own packet size which is returned with the recvfrom() function on the UDP socket. Suggestion 2: Add a third message type "truncated (130)", which can be sent back by the receiver to indicate that the UDP packet was truncated, most likely due to a smaller MTU in either side. The receiver can easily detect this error state by verifying the DTLS record length against the UDP packet size. case truncated: uint24 ack_sequence; uint32 packet_size; The ack_sequence in a truncated reply is identical to a ack reply, except that the sender MUST retransmit this same sequence with a smaller packet size, which is hinted by the second value packet_size; The sender can also initiate a MTU discovery. If MTU discovery (before the first payload is sent) is mandated by later revision of this draft, then suggestion 2 can be ignored. Thanks --Michael Bruce Lowekamp wrote: > There has been a bunch of discussion about the reassembly of > fragmented packets. Because fragmentation and hop-by-hop reliability > are related, we've been considering them both together. Here is a > proposal for how to address these and other related issues. Although > some of this is in normative text, much of it is descriptive and > normative text will need to be written for the draft. > > Bruce > > Topics that need to be addressed include: > > * Via List changes > * hop-by-hop fragmenting, end-to-end-reassembly of fragmented messages > * MTU discovery > * TFRC and semi-reliable retransmission for unreliable links > * framing for stream-based links (TLS/TCP) > * queueing overlay messages > * link failure detection > * end-to-end retransmission > * removal of route-logging > * negotiating new overlay link protocols > > > * Via List changes > > The current via-list structure will be changed. The shortest via > list entry (other than for the origination and destination) is a > 15-bit opaque identifier with meaning only to the forwarding peer. > This 15-bit information is encoded in only 16 bits to minimize the > size of the via list. We have chosen to go with this very tight > encoding because the entire forwarding header must be present in each > fragment, and the protocol must work well over links with very small > MTUs. > > The remainder of the encoding will remain as it is now, although a > variable-length opaque identifier will also be allowed for situations > where the implementer or deployer knows that more than 15 bits of > information is required. An implementation SHOULD use the shortest > possible entry for its application. > > If the first bit is 0, then the Destination is 16 bits long, and the > destination_data is an opaque 15-bit identifier. > > (these structure definitions are conceptual only and intended for > discussion. the final representation may be different.) > > struct { > uint8 isLong:1; // =0 > uint16 dest_info:15; > } > > struct { > uint8 isLong:1; // =1 > uint8 length:7 > DestinationType type; > DestinationData destination_data; > } > > add a DestinationType for opaque id; > > > One possible encoding of the dest_info opaque identifier is to encode > an index into a connection table. To avoid misrouting responses in > the event a response is delayed and the connection table entry has > changed, the identifier should be split between an index and a > generation counter for that index. At startup, the generation > counters should be initialized to random values. An implementation > could use 12 bits for the connection table index and 3 bits for the > generation counter. (Note that this does not suggest a 4096 entry > connection table for every node, only the ability to encode for a > larger connection table.) When a connection table slot is used for a > new connection, the generation counter is incremented (with wrapping). > Connection table slots are used on a rotating basis to maximize the > time interval between using the same slot for different connections. > When routing a message to an entry in the destination list encoding a > connection table entry, the node confirms that the generation counter > matches the current generation counter of that index before forwarding > the message. If it does not match, the message is silently dropped. > > Regardless of how the dest_info field or opaque DestinationType is > used, the encoding MUST include a generation counter designed to > prevent misrouting of responses due to the connection table entry > having changed since the request message was originally forwarded. > > > * hop-by-hop fragmenting, end-to-end-reassembly of fragmented messages > > > Any node along the path can fragment the message but only the final > destination reassembles the fragments. When a node takes a packet and > fragments it, each fragment has a full copy of the Forwarding Header > but the data after the Forwarding Header is broken up in appropriate > sized chunks. The size of the payload chunks needs to take into > account space to allow the via and lists to grow. Each fragment MUST > contain a full copy of the via and destination list and MUST contain > at least 256 bytes of the message body. If the via and destination > list are so large that this is not possible, RELOAD fragmentation is > not performed and IP-layer fragmentation is allowed to occur. When a > message must be fragmented, it SHOULD be split into equal-sized > fragments that are no larger than the PMTU of the next overlay link > minus 32 bytes. This is to allow the via list to grow before further > fragmentation is required. > > Note that this fragmentation is not optimal for the end-to-end > path---a message may be refragmented multiple times as it traverses > the overlay. This option has been chosen as it is far easier to > implement than e2e PMTU discovery across an ever-changing overlay, and > effectively addresses the reliability issues of relying on IP-layer > fragmentation. However, PING will be extended to allow e2e PMTU to be > implemented if desired. > > The final node that was receiving the data would need to reassemble > it. Any fragment older than 15 seconds SHOULD be discarded. However, > it does need to store all the fragments it receives and once it has > all the fragments for a messages. The amount of buffer space it needs > for this is proportional to whatever bit rate it is wiling to precess > messages at. Will have to specify something allowing excess fragments > to be dropped in case of attack. > > > * MTU discovery > > MTU discovery is required both at the overlay link level and > end-to-end across the overlay (being the minimum of the overlay link > MTUs along the path). We will refer to these as overlay link MTU and > end-to-end MTU. > > PING is used for overlay link MTU discovery. After establishing a new > connection, a node uses PING sent to this neighbor with the DF bit set > and a NULL (need to define) forwarding option header that extends the > message to the desired length. A series of these probes is used to > identify the overlay link MTU for this connection. See RFC4821 for > more details on this algorithm. > > If a node choses not to perform overlay link MTU discovery, or before > it has determined a larger overlay link MTU via a PING, it SHOULD use > a default overlay link MTU of the overlay link of 576 bytes for IPv4 > and 1280 bytes for IPv6 (RFC5405). > > For end-to-end MTU discovery, the PING response will have an > attribute added indicating the largest fragment of the PING request > that was received. Calculating this value is OPTIONAL and if not > implemented, 0 should be reported in this field. Note that use of > this field measures a lower-bound, and not an upper bound on the > end-to-end MTU. It also does not ensure that each hop along the path > did not use IP-layer fragmentation. End-to-end MTU discovery is not > required nor specified by this document. > > * TFRC and semi-reliable retransmission for unreliable links > > Goal of algorithm specified in document is: > > - provide a stop and wait algorithm that is as simple to implement as > possible > - provide a somewhat more complicated AIMD algorithm that is also more > conservative than TFRC and allows pipelining > - allow TFRC to be implemented > - do this with a single simple receiver, so all changes to allow more > complicated congestion control are done on the sender side. > > Much of this is the same as what is in the current draft, but there > are some clarifications here. > > Each packet sent has a sequence number. A sequence number is never > reused (until wraparound), if a retransmission occurs it receives a > new sequence number. It is up to the sender to keep track of that. > > When the receiver sends an ACK, it ACKs a particular sequence number > and sets bits in the mask for recently received packets that it has a > record of. A bit not being set in the mask is not a NACK. Nodes > SHOULD remember the previous 32 sequence numbers. A receiver MUST NOT > use any form of delayed ACKs. > > A receiver does not implement any form of a buffer or memory of which > packets it has or has not received outside of the most recent 32. It > is purely the job for the sender to implement semi-reliability. > > The hop-by-hop link retransmission is intended to provide > semi-reliable service. (good-effort service.) It does not, and > cannot, provide total reliability. Among other problems, an overlay > network may experience congestion or stability problems, so attempts > to achieve perfect hop-by-hop reliability will not achieve the desired > effect of perfect message reliability. > > Now details of the sender algorithms: > > stop-and-wait: > > Stop and wait allows only one fragment to be in transit per DTLS > connection. It has abysmal performance for WAN connections, but is > typically acceptable for LAN performance (for low-bandwidth overlays). > > A peer SHOULD retransmit a fragment if it has not received an ACK for > that fragment starting with an interval of RTO ("Retransmission > TimeOut"), doubling after each retransmission. In each retransmission, > the sequence number is incremented. The RTO is an estimate of the > round-trip time (RTT), and is computed as described in RFC 2988 > [RFC2988], with two exceptions. First, the initial value for RTO > SHOULD be calculated from the STUN connectivity checks used to > establish the connection. If that is not possible, the initial value > for RTO SHOULD be configurable (rather than the 3 s recommended in RFC > 2988) and SHOULD be greater than 500 ms. In fixed-line access links, > a value of 500 ms is RECOMMENDED. Second, the value of RTO SHOULD NOT > be rounded up to the nearest second. Rather, a 1 ms accuracy SHOULD be > maintained. As with TCP, the usage of Karn's algorithm is RECOMMENDED > [TODO REF KARN87] which means that RTT estimates SHOULD NOT be > computed from transactions that result in the retransmission of a > request. The value for RTO is calculated separately for each DTLS > session. > > Retransmissions continue until a response is received, or until a > total of Rc requests have been sent or there has been a hard ICMP > error [RFC1122]. The RECOMMENDED value of Rc is 5 and it MUST be at > least 3. The receiver knows a responses was received by receiving and > ACK with a sequence number that indicates it is a response to one of > the transmissions of this fragment. For example, assuming an RTO of > 500 ms and Rc of 5, requests would be sent at times 0 ms, 500 ms, 1500 > ms, 3500 ms, and 7500 ms. If all retransmissions for a fragment fail, > the DTLS connection SHOULD be closed. > > Once an ACK has been received for a fragment, the next fragment can be > sent but the peer SHOULD ensure that there is at least 10 ms between > sending any two fragments. > > > AIMD: > > A sender can implement TCP or TCP-like algorithms provided that they > meet the aggressiveness requirement. The algorithm here is only the > AIMD portion of TCP. All other features are restricted to simplify > the implementation, i.e. no slow start (initial window is 1), no fast > retransmission, and no fast recovery. An implementation may use one > timer per fragment or a single timer for only the oldest outstanding > fragment. > > AIMD extends stop and wait by allowing multiple fragments to be > pending at the same time. The sender allows w unacknowledged > fragments to be outstanding at any given time. w is initially set to > one. Every RTO interval that no retransmissions occur, w is increased > by one. When a loss occurs, w is halved. After halving w, if there > are more than w fragments for which an ACK is pending, no further > retransmissions of the most recently initiated fragments are performed > until they fit in the window w, at which point they begin the > retransmission algorithm again. w is held fixed for one RTO. After that > point, if additional retransmissions occur, it will be halved again, > otherwise it may be incremented after an additional RTO without loss. > > If w drops to one and the one pending fragment is not ACKed by the > other side after 5 requests are sent, the link is considered to have > failed. Otherwise, unACKed fragments are simply dropped. > > TFRC: > > TFRC (RFC5348) can be implemented in the Sender-Based Variant format > with the same receiver algorithm. This implementation requires the > sender to maintain precise timestamps in ms of the transmission time > of each sequence number as well as the segment sizes. That, combined > with the ACKs (and that the ACKs are not delayed) allows the sender to > calculate the performance required by TFRC, including information > calculated by the receiver in the conventional form of TFRC. > > TFRC is used for congestion control. For reliability, an individual > fragment is retransmitted up to twice at RTO intervals, pending the > availability of room in the congestion window. If it is not > ACKed after another RTO following its last retransmission, it is dropped. > > > * framing for stream-based links (TLS/TCP) > > A framing header is specified for TCP links. The framing headers are > used to calculate RTT and detect when the TCP link has failed. > > > * queueing overlay messages > > For all link types, a peer MUST implement an appropriate queueing > discipline for determining which messages are forwarded. For all link > types, the peer MUST queue at least 5 messages. For overlay link > algorithms that implement a congestion window, the peer SHOULD queue > the greater of 5 messages or the current size of the congestion > window. For overlay link algorithms that rely on an underlying > buffer, such as TCP, the peer SHOULD queue 5 messages beyond what fits > in the socket buffer. Tuning for performance of the overlay link > SHOULD be accomplished by adjusting the size of the socket buffer > appropriately (ref). In no case should a message be queued longer than > 500ms. > > A node MAY implement a separate queue for internally originated > messages, but when operating in a congestion-limited mode, the node > MUST NOT allow its internally originated traffic to dominate the link. > > * link failure detection > > Links are detected to have failed under these conditions: > > - periodic STUN keepalive fails (need to specify when these are used) > - no new TCP or UDP framing acknowledgements are received for 10RTT > > (Note that ICE and ICE-TCP both require the use of keepalives. A node > MAY elect to substitute receiving framing acknowledgements for > separate active STUN keepalives.) > > * end-to-end retransmission > > End-to-end retransmission will be accomplished using exponential > backoff. An implementation SHOULD track round-trip times of messages > sent on the overlay and use set end-to-end RTO to 1.5 times the > average RTT. An implementation MAY track RTTs and set RTOs on a > per-destination basis. If an implementation does not track end-to-end > RTT, then RTO SHOULD default to 3000ms. > > * removal of route-logging > > route log will be removed from the forwarding header > > * negotiating new overlay link protocols > > a protocol ID will be added to the ICE negotiation to specify what > link protocol is being run between nodes, analogous to how media is > negotiated in SDP. To avoid offer/answer headaches, we will not > import the concept of an offer-less attach, and there will be a > mandatory protocol that must be included in each offer so there cannot > be a failure to share a protocol. (optionally include "better" base > option in overlay config?) > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From ekr@networkresonance.com Mon Mar 2 22:08:10 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B21C3A6B0C for ; Mon, 2 Mar 2009 22:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi6Lhy32f3NX for ; Mon, 2 Mar 2009 22:08:09 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9CE5428C129 for ; Mon, 2 Mar 2009 22:08:05 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2BB6650822; Mon, 2 Mar 2009 22:31:23 -0800 (PST) Date: Mon, 02 Mar 2009 22:31:23 -0800 From: Eric Rescorla To: Michael Chen In-Reply-To: <49ACBFEB.7080106@idssoftware.com> References: <49ACBFEB.7080106@idssoftware.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090303063123.2BB6650822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 03 Mar 2009 06:08:10 -0000 At Mon, 02 Mar 2009 21:28:11 -0800, Michael Chen wrote: > > Bruce, > > I have 2 suggestions for section "5.5.2.1. Framed Message Format" in the > current Reload draft relevant to UDP fragmentation and retransmission. > This section defined framed message as: > > enum {data (128), ack (129), (255)} FramedMessageType; > struct { > FramedMessageType type; > select (type) { > case data: > uint24 sequence; > opaque message<0..2^24-1>; > case ack: > uint24 ack_sequence; > uint32 received; > }; > > Suggestion 1: > The 24-bit length for the message payload is unnecessary and should be > removed. The message is DTLS record, which has its own size and > integrity check scheme. Also, the UDP packet carries its own packet size > which is returned with the recvfrom() function on the UDP socket. This framing is also going to be used with TLS, so you do need the length there. I'd rather have a consistent framing than save 3 bytes. > Suggestion 2: > Add a third message type "truncated (130)", which can be sent back by > the receiver to indicate that the UDP packet was truncated, most likely > due to a smaller MTU in either side. The receiver can easily detect > this error state by verifying the DTLS record length against the UDP > packet size. > > case truncated: > uint24 ack_sequence; > uint32 packet_size; > > The ack_sequence in a truncated reply is identical to a ack reply, > except that the sender MUST retransmit this same sequence with a smaller > packet size, which is hinted by the second value packet_size; The > sender can also initiate a MTU discovery. > > If MTU discovery (before the first payload is sent) is mandated by later > revision of this draft, then suggestion 2 can be ignored. What sort of IP network element do you think would truncate UDP datagrams? AFAIK, either they should be (1) sent intact (2) fragmented or (3) dropped. -Ekr From melodysong@huawei.com Mon Mar 2 22:26:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892A828C0FB for ; Mon, 2 Mar 2009 22:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GgoDi3BrjJW for ; Mon, 2 Mar 2009 22:26:28 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 60EA028C0F1 for ; Mon, 2 Mar 2009 22:26:28 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFX003MD38J3M@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 03 Mar 2009 14:26:43 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFX00ABJ38JF9@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 03 Mar 2009 14:26:43 +0800 (CST) Received: from s64081 ([10.164.12.16]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFX00I3U38IIQ@szxml06-in.huawei.com> for p2psip@ietf.org; Tue, 03 Mar 2009 14:26:43 +0800 (CST) Date: Tue, 03 Mar 2009 14:26:43 +0800 From: Song Haibin In-reply-to: <72FB0F54-0357-4D72-8E74-EFC94E874379@cisco.com> To: 'Cullen Jennings' , 'P2PSIP WG' Message-id: <01b601c99bc9$0536a990$100ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmbfRFJe9VBru1ETgKdUclzp8195AAScxjw Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 03 Mar 2009 06:26:29 -0000 Dear Cullen, You have the same concern with Bruce and Henning. The authors do not think this method is broadly suitable for the diagnostics in the open Internet environment either. However, it may be used in some administrative p2p overlays. The usage of Echo method is limited to certain application scenarios. As we said in the draft: "An Echo request message is used to retrieve the diagnostic information of the specified path in administrative p2p overlays where all the peers in the overlay are trusted or based on specific authorization. For example, it can be used in a p2p overlay where all peers deployed by the operator to provide services to the customers (clients), where the diagnostics happens between peers in the p2p overlay. For the untrusted p2p overlays, e.g. some end user equipments can be the peers in the overlay network, then the Echo method must be used with care for the consideration of potential DoS attack. Compared with Path_Track method, Echo method brings less messages to the p2p overlay network." Best Regards, Haibin Skype: alexsonghw >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >Cullen Jennings >Sent: Tuesday, March 03, 2009 5:23 AM >To: P2PSIP WG >Subject: [P2PSIP] Comment on p2psip-diagnostics > > >One comment on the Echo design.... I'm worried about a method where >sending a single request can cause a whole bunch of responses. This >has congestion and DOS issues. It is also not clear how all the >retransmissions timers would work with it. > >We should think about if it is possible to move away from the one >request, multiple responses design. > >Cullen > > > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip From wang.jun17@zte.com.cn Tue Mar 3 00:09:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70433A68A7 for ; Tue, 3 Mar 2009 00:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.965 X-Spam-Level: X-Spam-Status: No, score=-92.965 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF+Blnyl5c8h for ; Tue, 3 Mar 2009 00:09:06 -0800 (PST) Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 468E63A6857 for ; Tue, 3 Mar 2009 00:09:02 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 35764.2075036648; Tue, 3 Mar 2009 16:30:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2385s0A006021 for ; Tue, 3 Mar 2009 16:05:57 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) To: "p2psip@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Tue, 3 Mar 2009 16:05:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-03 16:05:48, Serialize complete at 2009-03-03 16:05:48 Content-Type: multipart/alternative; boundary="=_alternative 002C77214825756E_=" X-MAIL: mse1.zte.com.cn n2385s0A006021 Subject: Re: [P2PSIP] New Version Notification for draft-wang-p2psip-event-notification-extension-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 03 Mar 2009 08:09:06 -0000 This is a multipart message in MIME format. --=_alternative 002C77214825756E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksZm9sa3MNCiAgICBJIGhhdmUgd3JvdGUgYSBkcmFmdCByZWdhcmRpbmcgcDJwc2lwIGV2ZW50 IG5vdGlmaWNhdGlvbiBleHRlbnNpb24uIEkgDQp0aGluayBpdCBjYW4gbWVldCB0aGUgcmVxdWly ZW1lbnRzIG9mIHJlYWwgdGltZSBkYXRhIGFjY2VzcyBzY2VuYXJpby4NCiANCiAgICBIb3BlIGZv ciB5b3VyIGNvbW1lbnRzLg0KDQoNCklFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCA8aWRzdWJtaXNz aW9uQGlldGYub3JnPiANCjIwMDktMDMtMDIgMTk6NDANCg0KytW8/sjLDQp3YW5nLmp1bjE3QHp0 ZS5jb20uY24NCrOty80NCmNoZW4uemhpZmVuZ0B6dGUuY29tLmNuDQrW98ziDQpOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtd2FuZy1wMnBzaXAtZXZlbnQtbm90aWZpY2F0aW9u LWV4dGVuc2lvbi0wMA0KDQoNCg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgDQpkcmFm dC13YW5nLXAycHNpcC1ldmVudC1ub3RpZmljYXRpb24tZXh0ZW5zaW9uLTAwLnR4dCBoYXMgYmVl biBzdWNjZXNzZnVseSANCnN1Ym1pdHRlZCBieSBKdW4gV2FuZyBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgICAgICAgICAgZHJhZnQtd2FuZy1w MnBzaXAtZXZlbnQtbm90aWZpY2F0aW9uLWV4dGVuc2lvbg0KUmV2aXNpb246ICAgICAgICAgICAg ICAgICAwMA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAyUFNJUCBFdmVudCBO b3RpZmljYXRpb24gRXh0ZW5zaW9uDQpDcmVhdGlvbl9kYXRlOiAgICAgICAgICAgIDIwMDktMDMt MDINCldHIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRlcGVuZGVudCBTdWJtaXNz aW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDIwDQoNCkFic3RyYWN0Og0KVGhlIHAycCB0ZWNobm9sb2d5 IGlzIGRhdGEgY2VudHJpYywgd2hlcmUgdGhlIGRhdGEgb2JqZWN0cyBhcmUgDQpkaXN0cmlidXRl ZCBpbiB0aGUgcDJwIG92ZXJsYXkgYWNjb3JkaW5nIHRvIHRoZSByb3V0aW5nIGFsZ29yaXRobS4g DQpBcHBsaWNhdGlvbnMgYWNjZXNzIHRoZSBkYXRhIG9iamVjdHMgdmlhIHBlZXIvY2xpZW50IHBy b3RvY29sIG9yIA0KZ2F0ZXdheXMsIGFuZCBzb21lIG9mIHRoZW0gcmVxdWlyZSBkYXRhIHJlcGxp Y2FzIHRvIGJlIHN5bmNocm9uaXplZCANCmluIHJlYWwgdGltZSwgc3VjaCBhcyBhIGRhdGEgb2Jq ZWN0IHN0b3JlZCBpbiBvdmVybGF5IGFuZCBpdHMgY2FjaGUgDQpjb3B5IGluIGNsaWVudCBtZW1v cnkuIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5IGludHJvZHVjaW5nIGFuIGV2ZW50IA0Kbm90aWZp Y2F0aW9uIGV4dGVuc2lvbiB0byBwMnAgcHJvdG9jb2wuIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IHRoZSANCnN1YnNjcmliZS9ub3RpZnkgbWVjaGFuaXNtIGZvciBwMnBzaXAgYW5kIGRlZmluZSBz ZXZlcmFsIG5ldyBtZXRob2RzIA0KdG8gaW1wbGVtZW50IHN1Y2ggZXh0ZW5zaW9uLg0KICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29s ZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21t dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js aWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 002C77214825756E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLGZvbGtzPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IEkgaGF2ZSB3cm90 ZSBhIGRyYWZ0IHJlZ2FyZGluZw0KcDJwc2lwIGV2ZW50IG5vdGlmaWNhdGlvbiBleHRlbnNpb24u IEkgdGhpbmsgaXQgY2FuIG1lZXQgdGhlIHJlcXVpcmVtZW50cw0Kb2YgcmVhbCB0aW1lIGRhdGEg YWNjZXNzIHNjZW5hcmlvLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgSG9wZSBmb3IgeW91ciBjb21tZW50cy48L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SUVURiBJLUQgU3VibWlzc2lvbiBUb29s DQombHQ7aWRzdWJtaXNzaW9uQGlldGYub3JnJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDMtMDIgMTk6NDA8L2ZvbnQ+DQo8dGQgd2lkdGg9 NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+d2FuZy5qdW4xN0B6dGUuY29t LmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jaGVuLnpoaWZlbmdAenRlLmNvbS5jbjwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXdhbmctcDJwc2lwLWV2ZW50LW5vdGlmaWNhdGlvbi1leHRl bnNpb24tMDA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTI+PHR0Pjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLXAycHNpcC1l dmVudC1ub3RpZmljYXRpb24tZXh0ZW5zaW9uLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bHkg c3VibWl0dGVkIGJ5IEp1biBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48 YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ZHJhZnQtd2FuZy1wMnBzaXAtZXZlbnQtbm90aWZp Y2F0aW9uLWV4dGVuc2lvbjxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDswMDxicj4NClRpdGxlOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KUDJQU0lQIEV2ZW50IE5vdGlmaWNhdGlvbiBFeHRlbnNpb248YnI+DQpDcmVhdGlvbl9kYXRl OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsyMDA5LTAzLTAyPGJyPg0KV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpJbmRlcGVuZGVudCBTdWJtaXNz aW9uPGJyPg0KTnVtYmVyX29mX3BhZ2VzOiAyMDxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NClRo ZSBwMnAgdGVjaG5vbG9neSBpcyBkYXRhIGNlbnRyaWMsIHdoZXJlIHRoZSBkYXRhIG9iamVjdHMg YXJlIDxicj4NCmRpc3RyaWJ1dGVkIGluIHRoZSBwMnAgb3ZlcmxheSBhY2NvcmRpbmcgdG8gdGhl IHJvdXRpbmcgYWxnb3JpdGhtLiA8YnI+DQpBcHBsaWNhdGlvbnMgYWNjZXNzIHRoZSBkYXRhIG9i amVjdHMgdmlhIHBlZXIvY2xpZW50IHByb3RvY29sIG9yIDxicj4NCmdhdGV3YXlzLCBhbmQgc29t ZSBvZiB0aGVtIHJlcXVpcmUgZGF0YSByZXBsaWNhcyB0byBiZSBzeW5jaHJvbml6ZWQgPGJyPg0K aW4gcmVhbCB0aW1lLCBzdWNoIGFzIGEgZGF0YSBvYmplY3Qgc3RvcmVkIGluIG92ZXJsYXkgYW5k IGl0cyBjYWNoZSA8YnI+DQpjb3B5IGluIGNsaWVudCBtZW1vcnkuIFRoaXMgY2FuIGJlIGFjaGll dmVkIGJ5IGludHJvZHVjaW5nIGFuIGV2ZW50IDxicj4NCm5vdGlmaWNhdGlvbiBleHRlbnNpb24g dG8gcDJwIHByb3RvY29sLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgPGJyPg0Kc3Vic2Ny aWJlL25vdGlmeSBtZWNoYW5pc20gZm9yIHAycHNpcCBhbmQgZGVmaW5lIHNldmVyYWwgbmV3IG1l dGhvZHMgPGJyPg0KdG8gaW1wbGVtZW50IHN1Y2ggZXh0ZW5zaW9uLjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0K PGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuPGJyPg0KPGJyPg0KPGJyPg0KPC90dD48 L2ZvbnQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 002C77214825756E_=-- From michaelc@IDSSOFTWARE.COM Tue Mar 3 03:30:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37BB628C22A for ; Tue, 3 Mar 2009 03:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78MU49iqou1b for ; Tue, 3 Mar 2009 03:30:31 -0800 (PST) Received: from smtpoutwbe01.prod.mesa1.secureserver.net (smtpoutwbe01.prod.mesa1.secureserver.net [208.109.78.112]) by core3.amsl.com (Postfix) with SMTP id 5EB0128C243 for ; Tue, 3 Mar 2009 03:30:31 -0800 (PST) Received: (qmail 7153 invoked from network); 3 Mar 2009 11:30:57 -0000 Received: from unknown (HELO gem-wbe26.prod.mesa1.secureserver.net) (64.202.189.160) by smtpoutwbe01.prod.mesa1.secureserver.net with SMTP; 3 Mar 2009 11:30:57 -0000 Received: (qmail 23178 invoked by uid 99); 3 Mar 2009 11:30:57 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 64.203.45.253 User-Agent: Web-Based Email 4.14.21 Message-Id: <20090303043057.61e8c06078a3b23a733c71e914c0b9df.14bdaafea8.wbe@email.secureserver.net> From: michaelc@IDSSOFTWARE.COM To: "Eric Rescorla" Date: Tue, 03 Mar 2009 04:30:57 -0700 Mime-Version: 1.0 Cc: Michael Chen , "p2psip@ietf.org" Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 03 Mar 2009 11:30:32 -0000 Eric,

-------- Original Message --------
Subject: Re: [P2PSIP] proposal for reload congestion control,
fragmentation, and retransmission
From: Eric Rescorla <ekr@networkresonance.com>
...
>
> Suggestion 1:
> The 24-bit length for the message payload is unnecessary and should be=
> removed. The message is DTLS record, which has its own size and
> integrity check scheme. Also, the UDP packet carries its own packet si= ze
> which is returned with the recvfrom() function on the UDP socket.

This framing is also going to be used with TLS, so you do need
the length there. I'd rather have a consistent framing than
save 3 bytes.

My thought section 5.2.2 is for unreliable l= ink (UDP/DTLS) only. I assume the TLS record layer is sufficient for TCP. E= ven if framing is used for TCP, wouldn't it be using rfc4571 as suggested b= y draft-ietf-mmusic-ice-tcp-07? Please clarify.

Please ignore sugges= tion 2. I misread the Linux man page for udp(7).

Thanks
--Michael
 From lilichun@gmail.com Tue Mar 3 04:39:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EEC3A6C46 for ; Tue, 3 Mar 2009 04:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ischzsBOkNXT for ; Tue, 3 Mar 2009 04:39:13 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id 8086428C2B8 for ; Tue, 3 Mar 2009 04:38:27 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so295711nfh.39 for ; Tue, 03 Mar 2009 04:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yZWRw1n1CCCnt8o1raTqLNfqAJCeu6uh+8zS5Jmz2TE=; b=jFTVlmoyfPNhHLENMYVTDNn4zNhUgUJoLzMtzwgc5j97U5BRJd3EshbH7/P0UOuKi9 bdzGJVj4Zl55rtkhyT74Jrm5+s32/vKMYCVtxvXKuT+hC9ZzFNkiOAEy2x0j9KWxijjN GjqdhaBXScJ1hkCO6TgLXsZGWsenmH2VBsktU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bRAuhfav/tGFuAHrypyV+VHb2zjrC87U0I/y0kfAtTA0ML/22venr8BVkwzDSXCMU5 VMjil/sDd5yxHMRz6VSUdJuIyboq5Psy7lj3hDT3lUWGSyQaQr9jni4EmKe5RSnJidtT odkf4vxGqhhR39kEG3FF+aW3BX6kcrK5GVPl8= MIME-Version: 1.0 Received: by 10.210.92.8 with SMTP id p8mr5671642ebb.6.1236083933519; Tue, 03 Mar 2009 04:38:53 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Mar 2009 20:38:53 +0800 Message-ID: <7d6b50690903030438p4b672d8ci63072a3d7ec19d81@mail.gmail.com> From: lichun li To: wang.jun17@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] New Version Notification for draft-wang-p2psip-event-notification-extension-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 03 Mar 2009 12:39:14 -0000 I think subscribe/notify mechnism is very neccesary and can also be used to inform other events other than data modification. Have consider notifier migration? At a glance, I don't find notifier migration in the draft. If the orignal notifier leaves or fails, another peer should become new notifier immediately. Otherwise, the subscriber may not get the latest data for a while. On Tue, Mar 3, 2009 at 4:05 PM, wrote: > > Hi,folks > I have wrote a draft regarding p2psip event notification extension. I > think it can meet the requirements of real time data access scenario. > > Hope for your comments. > > IETF I-D Submission Tool > > 2009-03-02 19:40 > > =CA=D5=BC=FE=C8=CB > wang.jun17@zte.com.cn > =B3=AD=CB=CD > chen.zhifeng@zte.com.cn > =D6=F7=CC=E2 > New Version Notification for > draft-wang-p2psip-event-notification-extension-00 > > > > > > A new version of I-D, draft-wang-p2psip-event-notification-extension-00.t= xt > has been successfuly submitted by Jun Wang and posted to the IETF > repository. > > Filename: draft-wang-p2psip-event-notification-extension > Revision: 00 > Title: P2PSIP Event Notification Extens= ion > Creation_date: 2009-03-02 > WG ID: Independent Submission > Number_of_pages: 20 > > Abstract: > The p2p technology is data centric, where the data objects are > distributed in the p2p overlay according to the routing algorithm. > Applications access the data objects via peer/client protocol or > gateways, and some of them require data replicas to be synchronized > in real time, such as a data object stored in overlay and its cache > copy in client memory. This can be achieved by introducing an event > notification extension to p2p protocol. This document describes the > subscribe/notify mechanism for p2psip and define several new methods > to implement such extension. > > > > > The IETF Secretariat. > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT From ekr@networkresonance.com Tue Mar 3 09:38:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CD63A6C17 for ; Tue, 3 Mar 2009 09:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn9egVIcQEz4 for ; Tue, 3 Mar 2009 09:38:29 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D987D3A6A0C for ; Tue, 3 Mar 2009 09:38:29 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2E05650822; Tue, 3 Mar 2009 10:01:48 -0800 (PST) Date: Tue, 03 Mar 2009 10:01:48 -0800 From: Eric Rescorla To: michaelc@IDSSOFTWARE.COM In-Reply-To: <20090303043057.61e8c06078a3b23a733c71e914c0b9df.14bdaafea8.wbe@email.secureserver.net> References: <20090303043057.61e8c06078a3b23a733c71e914c0b9df.14bdaafea8.wbe@email.secureserver.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090303180148.2E05650822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 03 Mar 2009 17:38:30 -0000 [Note: please figure out how to send plaintext email. HTML is not convenient for me] At Tue, 03 Mar 2009 04:30:57 -0700, > > This framing is also going to be used with TLS, so you do need
> > the length there. I'd rather have a consistent framing than
> > save 3 bytes.
> > My thought section 5.2.2 is for unreliable link (UDP/DTLS) only. Editorial error. It was our intent that everything be framed. > I > assume the TLS record layer is sufficient for TCP. TLS does not preserve write boundaries. > Even if framing > is used for TCP, wouldn't it be using rfc4571 as suggested by > draft-ietf-mmusic-ice-tcp-07? Please clarify. No, that's at the wrong layer--below TLS rather than above. -Ekr From saumitra@qualcomm.com Tue Mar 3 17:10:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEA03A68FB for ; Tue, 3 Mar 2009 17:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1nYw7+m4Xtb for ; Tue, 3 Mar 2009 17:10:29 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3FA623A6A3F for ; Tue, 3 Mar 2009 17:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1236129057; x=1267665057; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-cr-puzzleid: x-cr-hashedpuzzle:acceptlanguage:content-type: content-transfer-encoding:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Tue,=203 =20Mar=202009=2017:10:51=20-0800|Subject:=20New=20Load=20 balancing=20in=20RELOAD=20draft|Thread-Topic:=20New=20Loa d=20balancing=20in=20RELOAD=20draft|Thread-Index:=20AcmcZ g8NSmjgPll/QY+UnNBNtMExsQ=3D=3D|Message-ID:=20<2D06DE445C 2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.co m>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-cr-puzzleid:=20 {63231119-F516-4BA7-A678-95B132E2BEAF}|x-cr-hashedpuzzle: =20AQSU=20AqnB=20AxEi=20ClO8=20E0ie=20FJ6S=20FMSa=20FzVb =20F25Y=20GKD2=20GxKG=0D=0A=20HeVt=20Hf2D=20JrK8=20KKzn =0D=0A=20Kf04=3B1=3BcAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByA GcA=3BSosha1_v1=3B7=3B{63231119-F516-4BA7-A678-95B132E2BE AF}=3BcwBhAHUAbQBpAHQAcgBhAEAAcQB1AGEAbABjAG8AbQBtAC4AYwB vAG0A=3BWed,=0D=0A=2004=20Mar=202009=2001:10:51=0D=0A=20G MT=3BTgBlAHcAIABMAG8AYQBkACAAYgBhAGwAYQBuAGMAaQBuAGcAIABp AG4AIABSAEUATABPAEEARAAgAGQAcgBhAGYAdAA=3D |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5542"=3B=20a=3D"15938273"; bh=KhakKfQZPtzyZ7mDdxagK/schtAMkobcTkfMZXtgSoI=; b=YtIiXXmjGtrA1sLlepRtjg6IH3NgpefA9D8Tp3kM7HpH/xu9DevQXN6Z J05HWTzs1zaSEO1Lo50lCMPJe/6sGrSGEuUZz6c8r9rp0FVCQUrisnbrd HtQ79c+YM2LWwauOcauEC94WVPij4kA1+tRmGuWRB3KImsobA3mj7KIGX Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5542"; a="15938273" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2009 17:10:56 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n241AuO6012643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Mar 2009 17:10:56 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n241AsqJ012619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 3 Mar 2009 17:10:55 -0800 (PST) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Tue, 3 Mar 2009 17:10:55 -0800 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Tue, 3 Mar 2009 17:10:51 -0800 Thread-Topic: New Load balancing in RELOAD draft Thread-Index: AcmcZg8NSmjgPll/QY+UnNBNtMExsQ== Message-ID: <2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {63231119-F516-4BA7-A678-95B132E2BEAF} x-cr-hashedpuzzle: AQSU AqnB AxEi ClO8 E0ie FJ6S FMSa FzVb F25Y GKD2 GxKG HeVt Hf2D JrK8 KKzn Kf04; 1; cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {63231119-F516-4BA7-A678-95B132E2BEAF}; cwBhAHUAbQBpAHQAcgBhAEAAcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0A; Wed, 04 Mar 2009 01:10:51 GMT; TgBlAHcAIABMAG8AYQBkACAAYgBhAGwAYQBuAGMAaQBuAGcAIABpAG4AIABSAEUATABPAEEARAAgAGQAcgBhAGYAdAA= acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] New Load balancing in RELOAD draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 01:10:35 -0000 Hi all, I just submitted a draft that proposes a load balancing solution for the de= fault DHT in RELOAD. Comments are appreciated. http://www.ietf.org/internet-drafts/draft-saumitra-p2psip-loadbalance-00.tx= t =20 Best, Saumitra www.saumitra.info=20 From wang.jun17@zte.com.cn Tue Mar 3 18:21:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01923A689D for ; Tue, 3 Mar 2009 18:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.357 X-Spam-Level: X-Spam-Status: No, score=-89.357 tagged_above=-999 required=5 tests=[AWL=-3.568, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM4FdHd+Ropq for ; Tue, 3 Mar 2009 18:21:01 -0800 (PST) Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 16C663A6846 for ; Tue, 3 Mar 2009 18:20:58 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 35764.4179221585; Wed, 4 Mar 2009 10:43:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n242HoQF023567; Wed, 4 Mar 2009 10:17:52 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <7d6b50690903030438p4b672d8ci63072a3d7ec19d81@mail.gmail.com> To: lichun li MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Wed, 4 Mar 2009 10:17:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-04 10:17:48, Serialize complete at 2009-03-04 10:17:48 Content-Type: multipart/alternative; boundary="=_alternative 000C9BC14825756F_=" X-MAIL: mse1.zte.com.cn n242HoQF023567 Cc: "p2psip@ietf.org" Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24gZm9yIGRyYWZ0LXdhbmctcDJwc2lwLWV2ZW50LW5vdGlmaWNhdGlvbi1l?= =?gb2312?b?eHRlbnNpb24tMDA=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 02:21:02 -0000 This is a multipart message in MIME format. --=_alternative 000C9BC14825756F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSAzLjMuNA0KMy4zLjQuIFN0b3JhZ2UgYW5kIHJl cGxpY2F0aW9uIA0KDQogICBUaGUgTm90aWZpZXIgTVVTVCBzdG9yZSB0aGUgc3Vic2NyaXB0aW9u IHN0YXRlIGFzIHBhcnQgb2YgcmVzb3VyY2UgDQogICBkYXRhIG9iamVjdCBhbmQgZW5mb3JjZSB0 aGUgc2FtZSByZXBsaWNhdGlvbiBzdHJhdGVneS4gSW4gY2FzZSBhIG5vZGUgDQogICBmYWlscywg dGhlIG90aGVyIG5vZGUgd2hlcmUgdGhlIHJlcGxpY2Egc3RvcmVkIGNhbiBwcm9jZXNzIGFueSAN CiAgIHJlcXVlc3QgdG93YXJkcyB0aGUgcmVwbGljYXRlZCByZXNvdXJjZS4gDQoNClRoYW5rcw0K IA0KDQoNCg0KDQoNCmxpY2h1biBsaSA8bGlsaWNodW5AZ21haWwuY29tPiANCjIwMDktMDMtMDMg MjA6MzgNCg0KytW8/sjLDQp3YW5nLmp1bjE3QHp0ZS5jb20uY24NCrOty80NCiJwMnBzaXBAaWV0 Zi5vcmciIDxwMnBzaXBAaWV0Zi5vcmc+DQrW98ziDQpSZTogW1AyUFNJUF0gTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LXdhbmctcDJwc2lwLWV2ZW50LW5vdGlmaWNhdGlvbi1l eHRlbnNpb24tMDANCg0KDQoNCg0KDQoNCkkgdGhpbmsgc3Vic2NyaWJlL25vdGlmeSBtZWNobmlz bSBpcyB2ZXJ5IG5lY2Nlc2FyeSBhbmQgY2FuIGFsc28gYmUgdXNlZA0KdG8gaW5mb3JtIG90aGVy IGV2ZW50cyBvdGhlciB0aGFuIGRhdGEgbW9kaWZpY2F0aW9uLg0KDQpIYXZlIGNvbnNpZGVyIG5v dGlmaWVyIG1pZ3JhdGlvbj8gQXQgYSBnbGFuY2UsIEkgZG9uJ3QgZmluZCBub3RpZmllcg0KbWln cmF0aW9uIGluIHRoZSBkcmFmdC4NCklmIHRoZSBvcmlnbmFsIG5vdGlmaWVyIGxlYXZlcyBvciBm YWlscywgYW5vdGhlciBwZWVyIHNob3VsZCBiZWNvbWUNCm5ldyBub3RpZmllciBpbW1lZGlhdGVs eS4NCk90aGVyd2lzZSwgdGhlIHN1YnNjcmliZXIgbWF5IG5vdCBnZXQgdGhlIGxhdGVzdCBkYXRh IGZvciBhIHdoaWxlLg0KDQpPbiBUdWUsIE1hciAzLCAyMDA5IGF0IDQ6MDUgUE0sICA8d2FuZy5q dW4xN0B6dGUuY29tLmNuPiB3cm90ZToNCj4NCj4gSGksZm9sa3MNCj4gICAgIEkgaGF2ZSB3cm90 ZSBhIGRyYWZ0IHJlZ2FyZGluZyBwMnBzaXAgZXZlbnQgbm90aWZpY2F0aW9uIGV4dGVuc2lvbi4g DQpJDQo+IHRoaW5rIGl0IGNhbiBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgcmVhbCB0aW1lIGRh dGEgYWNjZXNzIHNjZW5hcmlvLg0KPg0KPiAgICAgSG9wZSBmb3IgeW91ciBjb21tZW50cy4NCj4N Cj4gSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIDxpZHN1Ym1pc3Npb25AaWV0Zi5vcmc+DQo+DQo+ IDIwMDktMDMtMDIgMTk6NDANCj4NCj4gytW8/sjLDQo+IHdhbmcuanVuMTdAenRlLmNvbS5jbg0K PiCzrcvNDQo+IGNoZW4uemhpZmVuZ0B6dGUuY29tLmNuDQo+INb3zOINCj4gTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvcg0KPiAgZHJhZnQtd2FuZy1wMnBzaXAtZXZlbnQtbm90aWZpY2F0aW9u LWV4dGVuc2lvbi0wMA0KPg0KPg0KPg0KPg0KPg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgDQpk cmFmdC13YW5nLXAycHNpcC1ldmVudC1ub3RpZmljYXRpb24tZXh0ZW5zaW9uLTAwLnR4dA0KPiBo YXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgSnVuIFdhbmcgYW5kIHBvc3RlZCB0byB0 aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPg0KPiBGaWxlbmFtZTogZHJhZnQtd2FuZy1wMnBzaXAt ZXZlbnQtbm90aWZpY2F0aW9uLWV4dGVuc2lvbg0KPiBSZXZpc2lvbjogICAgICAgICAgICAgICAg ICAwMA0KPiBUaXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAyUFNJUCBF dmVudCBOb3RpZmljYXRpb24gDQpFeHRlbnNpb24NCj4gQ3JlYXRpb25fZGF0ZTogICAgICAgICAg ICAgICAgICAyMDA5LTAzLTAyDQo+IFdHIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KPiBOdW1iZXJfb2ZfcGFnZXM6IDIwDQo+DQo+ IEFic3RyYWN0Og0KPiBUaGUgcDJwIHRlY2hub2xvZ3kgaXMgZGF0YSBjZW50cmljLCB3aGVyZSB0 aGUgZGF0YSBvYmplY3RzIGFyZQ0KPiBkaXN0cmlidXRlZCBpbiB0aGUgcDJwIG92ZXJsYXkgYWNj b3JkaW5nIHRvIHRoZSByb3V0aW5nIGFsZ29yaXRobS4NCj4gQXBwbGljYXRpb25zIGFjY2VzcyB0 aGUgZGF0YSBvYmplY3RzIHZpYSBwZWVyL2NsaWVudCBwcm90b2NvbCBvcg0KPiBnYXRld2F5cywg YW5kIHNvbWUgb2YgdGhlbSByZXF1aXJlIGRhdGEgcmVwbGljYXMgdG8gYmUgc3luY2hyb25pemVk DQo+IGluIHJlYWwgdGltZSwgc3VjaCBhcyBhIGRhdGEgb2JqZWN0IHN0b3JlZCBpbiBvdmVybGF5 IGFuZCBpdHMgY2FjaGUNCj4gY29weSBpbiBjbGllbnQgbWVtb3J5LiBUaGlzIGNhbiBiZSBhY2hp ZXZlZCBieSBpbnRyb2R1Y2luZyBhbiBldmVudA0KPiBub3RpZmljYXRpb24gZXh0ZW5zaW9uIHRv IHAycCBwcm90b2NvbC4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlDQo+IHN1YnNjcmliZS9u b3RpZnkgbWVjaGFuaXNtIGZvciBwMnBzaXAgYW5kIGRlZmluZSBzZXZlcmFsIG5ldyBtZXRob2Rz DQo+IHRvIGltcGxlbWVudCBzdWNoIGV4dGVuc2lvbi4NCj4NCj4NCj4NCj4NCj4gVGhlIElFVEYg U2VjcmV0YXJpYXQuDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIA0KaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0 aW9uIA0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSANCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9z ZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KPiBUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCANCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCm9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSAN Cm9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUDJQU0lQ IG1haWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4NCj4NCg0KDQoNCi0tIA0KU2luY2VyZWx5IHlvdXJz LA0KDQpMaWNodW4gTGkNCk1vYmlsZSBMaWZlIE5ldyBNZWRpYSBMYWIsIEJVUFQNCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 000C9BC14825756F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIGNvbW1l bnRzLCBzZWUgMy4zLjQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDIwNDEgZmFj ZT0iQ291cmllciBOZXciPjxiPjMuMy40LiBTdG9yYWdlIGFuZA0KcmVwbGljYXRpb24gPC9iPjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAm bmJzcDtUaGUgTm90aWZpZXIgTVVTVCBzdG9yZQ0KdGhlIHN1YnNjcmlwdGlvbiBzdGF0ZSBhcyBw YXJ0IG9mIHJlc291cmNlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPiZuYnNwOyAmbmJzcDtkYXRhIG9iamVjdCBhbmQgZW5mb3JjZQ0KdGhlIHNhbWUgcmVwbGlj YXRpb24gc3RyYXRlZ3kuIEluIGNhc2UgYSBub2RlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtmYWlscywgdGhlIG90aGVyIG5vZGUNCndo ZXJlIHRoZSByZXBsaWNhIHN0b3JlZCBjYW4gcHJvY2VzcyBhbnkgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3JlcXVlc3QgdG93YXJkcyB0 aGUgcmVwbGljYXRlZA0KcmVzb3VyY2UuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPmxpY2h1biBsaSAmbHQ7bGlsaWNodW5A Z21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDA5LTAzLTAzIDIwOjM4PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPndhbmcuanVuMTdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+JnF1b3Q7cDJwc2lwQGlldGYub3JnJnF1b3Q7ICZsdDtwMnBzaXBAaWV0Zi5vcmcmZ3Q7 PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW1AyUFNJUF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u DQpmb3IgZHJhZnQtd2FuZy1wMnBzaXAtZXZlbnQtbm90aWZpY2F0aW9uLWV4dGVuc2lvbi0wMDwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ SSB0aGluayBzdWJzY3JpYmUvbm90aWZ5IG1lY2huaXNtIGlzIHZlcnkgbmVjY2VzYXJ5DQphbmQg Y2FuIGFsc28gYmUgdXNlZDxicj4NCnRvIGluZm9ybSBvdGhlciBldmVudHMgb3RoZXIgdGhhbiBk YXRhIG1vZGlmaWNhdGlvbi48YnI+DQo8YnI+DQpIYXZlIGNvbnNpZGVyIG5vdGlmaWVyIG1pZ3Jh dGlvbj8gQXQgYSBnbGFuY2UsIEkgZG9uJ3QgZmluZCBub3RpZmllcjxicj4NCm1pZ3JhdGlvbiBp biB0aGUgZHJhZnQuPGJyPg0KSWYgdGhlIG9yaWduYWwgbm90aWZpZXIgbGVhdmVzIG9yIGZhaWxz LCBhbm90aGVyIHBlZXIgc2hvdWxkIGJlY29tZTxicj4NCm5ldyBub3RpZmllciBpbW1lZGlhdGVs eS48YnI+DQpPdGhlcndpc2UsIHRoZSBzdWJzY3JpYmVyIG1heSBub3QgZ2V0IHRoZSBsYXRlc3Qg ZGF0YSBmb3IgYSB3aGlsZS48YnI+DQo8YnI+DQpPbiBUdWUsIE1hciAzLCAyMDA5IGF0IDQ6MDUg UE0sICZuYnNwOyZsdDt3YW5nLmp1bjE3QHp0ZS5jb20uY24mZ3Q7IHdyb3RlOjxicj4NCiZndDs8 YnI+DQomZ3Q7IEhpLGZvbGtzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEkgaGF2ZSB3cm90ZSBh IGRyYWZ0IHJlZ2FyZGluZyBwMnBzaXAgZXZlbnQgbm90aWZpY2F0aW9uDQpleHRlbnNpb24uIEk8 YnI+DQomZ3Q7IHRoaW5rIGl0IGNhbiBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgcmVhbCB0aW1l IGRhdGEgYWNjZXNzIHNjZW5hcmlvLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg SG9wZSBmb3IgeW91ciBjb21tZW50cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJRVRGIEktRCBTdWJt aXNzaW9uIFRvb2wgJmx0O2lkc3VibWlzc2lvbkBpZXRmLm9yZyZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAyMDA5LTAzLTAyIDE5OjQwPGJyPg0KJmd0Ozxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0 OyB3YW5nLmp1bjE3QHp0ZS5jb20uY248YnI+DQomZ3Q7ILOty808YnI+DQomZ3Q7IGNoZW4uemhp ZmVuZ0B6dGUuY29tLmNuPGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0OyBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yPGJyPg0KJmd0OyAmbmJzcDtkcmFmdC13YW5nLXAycHNpcC1ldmVudC1ub3Rp ZmljYXRpb24tZXh0ZW5zaW9uLTAwPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5n LXAycHNpcC1ldmVudC1ub3RpZmljYXRpb24tZXh0ZW5zaW9uLTAwLnR4dDxicj4NCiZndDsgaGFz IGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEp1biBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEY8YnI+DQomZ3Q7IHJlcG9zaXRvcnkuPGJyPg0KJmd0Ozxicj4NCiZndDsgRmlsZW5hbWU6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwO2RyYWZ0LXdhbmctcDJwc2lwLWV2ZW50LW5vdGlmaWNhdGlvbi1leHRlbnNpb248YnI+ DQomZ3Q7IFJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDswMDxicj4NCiZndDsgVGl0bGU6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFAyUFNJUCBF dmVudCBOb3RpZmljYXRpb24NCkV4dGVuc2lvbjxicj4NCiZndDsgQ3JlYXRpb25fZGF0ZTogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7MjAwOS0wMy0wMjxicj4NCiZndDsgV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGVwZW5kZW50IFN1Ym1pc3Np b248YnI+DQomZ3Q7IE51bWJlcl9vZl9wYWdlczogMjA8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBYnN0 cmFjdDo8YnI+DQomZ3Q7IFRoZSBwMnAgdGVjaG5vbG9neSBpcyBkYXRhIGNlbnRyaWMsIHdoZXJl IHRoZSBkYXRhIG9iamVjdHMgYXJlPGJyPg0KJmd0OyBkaXN0cmlidXRlZCBpbiB0aGUgcDJwIG92 ZXJsYXkgYWNjb3JkaW5nIHRvIHRoZSByb3V0aW5nIGFsZ29yaXRobS48YnI+DQomZ3Q7IEFwcGxp Y2F0aW9ucyBhY2Nlc3MgdGhlIGRhdGEgb2JqZWN0cyB2aWEgcGVlci9jbGllbnQgcHJvdG9jb2wg b3I8YnI+DQomZ3Q7IGdhdGV3YXlzLCBhbmQgc29tZSBvZiB0aGVtIHJlcXVpcmUgZGF0YSByZXBs aWNhcyB0byBiZSBzeW5jaHJvbml6ZWQ8YnI+DQomZ3Q7IGluIHJlYWwgdGltZSwgc3VjaCBhcyBh IGRhdGEgb2JqZWN0IHN0b3JlZCBpbiBvdmVybGF5IGFuZCBpdHMgY2FjaGU8YnI+DQomZ3Q7IGNv cHkgaW4gY2xpZW50IG1lbW9yeS4gVGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgaW50cm9kdWNpbmcg YW4gZXZlbnQ8YnI+DQomZ3Q7IG5vdGlmaWNhdGlvbiBleHRlbnNpb24gdG8gcDJwIHByb3RvY29s LiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGU8YnI+DQomZ3Q7IHN1YnNjcmliZS9ub3RpZnkg bWVjaGFuaXNtIGZvciBwMnBzaXAgYW5kIGRlZmluZSBzZXZlcmFsIG5ldyBtZXRob2RzPGJyPg0K Jmd0OyB0byBpbXBsZW1lbnQgc3VjaCBleHRlbnNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQuPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9u IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQptYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVy cy48YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kDQppbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUNCmFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yDQpvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KJmd0OyBUaGlzIG1l c3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1T cGFtDQpzeXN0ZW0uPGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IFAyUFNJUEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wMnBzaXA8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4N Cjxicj4NCi0tIDxicj4NClNpbmNlcmVseSB5b3Vycyw8YnI+DQo8YnI+DQpMaWNodW4gTGk8YnI+ DQpNb2JpbGUgTGlmZSBOZXcgTWVkaWEgTGFiLCBCVVBUPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+ DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90 aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJz cDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNw O1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVk Jm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJz cDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7 Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJz cDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZu YnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50 aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUm bmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2Vu dGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQu Jm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7 ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhl Jm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkm bmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2Um bmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNw O3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5u ZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7 WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000C9BC14825756F_=-- From wang.jun17@zte.com.cn Tue Mar 3 20:42:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D7F3A6AC5 for ; Tue, 3 Mar 2009 20:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.419 X-Spam-Level: X-Spam-Status: No, score=-89.419 tagged_above=-999 required=5 tests=[AWL=-2.079, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olfanmoCzPgm for ; Tue, 3 Mar 2009 20:42:18 -0800 (PST) Received: from mail.zte.com.cn (mail.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id F28B33A6A69 for ; Tue, 3 Mar 2009 20:42:15 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 35764.4179221585; Wed, 4 Mar 2009 13:03:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n244fQWR048455; Wed, 4 Mar 2009 12:41:26 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <7d6b50690903031849n66e286f7kaf2e7266fe5c26ac@mail.gmail.com> To: lichun li MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Wed, 4 Mar 2009 12:41:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-04 12:41:19, Serialize complete at 2009-03-04 12:41:19 Content-Type: multipart/alternative; boundary="=_alternative 0019C0D34825756F_=" X-MAIL: mse1.zte.com.cn n244fQWR048455 Cc: "p2psip@ietf.org" Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgTmV3IFZlcnNpb24g?= =?gb2312?b?Tm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLXAycHNpcC1ldmVudC1ub3Rp?= =?gb2312?b?ZmljYXRpb24tZXh0ZW5zaW9uLTAw?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 04:42:19 -0000 This is a multipart message in MIME format. --=_alternative 0019C0D34825756F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 bGljaHVuIGxpIDxsaWxpY2h1bkBnbWFpbC5jb20+INC009ogMjAwOS0wMy0wNCAxMDo0OTo0MToN Cg0KPiBTbyB0aGUgb3RoZXIgbm9kZSB3aWxsIGF1dG9tYXRpY2FsbHkgYmVjb21lIG5vdGlmaWVy IGJlZm9yZSB0aGUNCj4gc3Vic2NyaWJlciByZWZyZXNoZXMgc3Vic2NyaXB0aW9uPw0KWWVzDQoN Cj4gQW5vdGhlciBxdWVzdGlvbi4gV2hhdCB3aWxsIGEgbm90aWZpZXIgZG8gaWYgaXQgZGV0ZWN0 cyB0aGF0IGENCj4gc3Vic2NyaWJlciBmYWlscz8NCkN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJh ZnQgZG9lc24ndCB0YWtlIGFjY291bnQgb2YgdGhpcyBzaXR1YXRpb24uIFNpbmNlIA0KdGhlIG5v dGlmaWVyIG1heSBub3QgYWRqYWNlbnQgdG8gdGhlIHN1YnNjcmliZXIsIGl0J3MgZGlmZmljdWx0 IHRvIHBlcmZvcm0gDQpzdWNoIGEgZmFpbHVyZSBkZXRlY3Rpb24uIFRvIGVhc2UgdGhlIHNpdHVh dGlvbiwgbm90aWZpZXIgc2hvdWxkIGNvbmZpZ3VyZSANCmEgYXBwcm9wcmlhdGUgZXhwaXJpdGlv biB0aW1lciBhbmQgcHJvaGliaXQgcGVybWFuZW50IHN1YnNjcmlwdGlvbi4NCg0KPiANCj4gMjAw OS8zLzQgPHdhbmcuanVuMTdAenRlLmNvbS5jbj4NCj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhlIGNv bW1lbnRzLCBzZWUgMy4zLjQNCj4gPiAzLjMuNC4gU3RvcmFnZSBhbmQgcmVwbGljYXRpb24NCj4g Pg0KPiA+ICAgIFRoZSBOb3RpZmllciBNVVNUIHN0b3JlIHRoZSBzdWJzY3JpcHRpb24gc3RhdGUg YXMgcGFydCBvZiByZXNvdXJjZQ0KPiA+ICAgIGRhdGEgb2JqZWN0IGFuZCBlbmZvcmNlIHRoZSBz YW1lIHJlcGxpY2F0aW9uIHN0cmF0ZWd5LiBJbiBjYXNlIGEgDQpub2RlDQo+ID4gICAgZmFpbHMs IHRoZSBvdGhlciBub2RlIHdoZXJlIHRoZSByZXBsaWNhIHN0b3JlZCBjYW4gcHJvY2VzcyBhbnkN Cj4gPiAgICByZXF1ZXN0IHRvd2FyZHMgdGhlIHJlcGxpY2F0ZWQgcmVzb3VyY2UuDQo+ID4NCj4g PiBUaGFua3MNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gbGljaHVuIGxpIDxsaWxpY2h1 bkBnbWFpbC5jb20+DQo+ID4NCj4gPiAyMDA5LTAzLTAzIDIwOjM4DQo+ID4NCj4gPiDK1bz+yMsN Cj4gPiB3YW5nLmp1bjE3QHp0ZS5jb20uY24NCj4gPiCzrcvNDQo+ID4gInAycHNpcEBpZXRmLm9y ZyIgPHAycHNpcEBpZXRmLm9yZz4NCj4gPiDW98ziDQo+ID4gUmU6IFtQMlBTSVBdIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1wMnBzaXAtZXZlbnQtDQo+IG5vdGlmaWNh dGlvbi1leHRlbnNpb24tMDANCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEkgdGhpbmsgc3Vic2Ny aWJlL25vdGlmeSBtZWNobmlzbSBpcyB2ZXJ5IG5lY2Nlc2FyeSBhbmQgY2FuIGFsc28gYmUgDQp1 c2VkDQo+ID4gdG8gaW5mb3JtIG90aGVyIGV2ZW50cyBvdGhlciB0aGFuIGRhdGEgbW9kaWZpY2F0 aW9uLg0KPiA+DQo+ID4gSGF2ZSBjb25zaWRlciBub3RpZmllciBtaWdyYXRpb24/IEF0IGEgZ2xh bmNlLCBJIGRvbid0IGZpbmQgbm90aWZpZXINCj4gPiBtaWdyYXRpb24gaW4gdGhlIGRyYWZ0Lg0K PiA+IElmIHRoZSBvcmlnbmFsIG5vdGlmaWVyIGxlYXZlcyBvciBmYWlscywgYW5vdGhlciBwZWVy IHNob3VsZCBiZWNvbWUNCj4gPiBuZXcgbm90aWZpZXIgaW1tZWRpYXRlbHkuDQo+ID4gT3RoZXJ3 aXNlLCB0aGUgc3Vic2NyaWJlciBtYXkgbm90IGdldCB0aGUgbGF0ZXN0IGRhdGEgZm9yIGEgd2hp bGUuDQo+ID4NCj4gPiBPbiBUdWUsIE1hciAzLCAyMDA5IGF0IDQ6MDUgUE0sICA8d2FuZy5qdW4x N0B6dGUuY29tLmNuPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBIaSxmb2xrcw0KPiA+ID4gICAgIEkg aGF2ZSB3cm90ZSBhIGRyYWZ0IHJlZ2FyZGluZyBwMnBzaXAgZXZlbnQgbm90aWZpY2F0aW9uIA0K ZXh0ZW5zaW9uLiBJDQo+ID4gPiB0aGluayBpdCBjYW4gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9m IHJlYWwgdGltZSBkYXRhIGFjY2VzcyANCnNjZW5hcmlvLg0KPiA+ID4NCj4gPiA+ICAgICBIb3Bl IGZvciB5b3VyIGNvbW1lbnRzLg0KPiA+ID4NCj4gPiA+IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9v bCA8aWRzdWJtaXNzaW9uQGlldGYub3JnPg0KPiA+ID4NCj4gPiA+IDIwMDktMDMtMDIgMTk6NDAN Cj4gPiA+DQo+ID4gPiDK1bz+yMsNCj4gPiA+IHdhbmcuanVuMTdAenRlLmNvbS5jbg0KPiA+ID4g s63LzQ0KPiA+ID4gY2hlbi56aGlmZW5nQHp0ZS5jb20uY24NCj4gPiA+INb3zOINCj4gPiA+IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiA+ICBkcmFmdC13YW5nLXAycHNpcC1ldmVu dC1ub3RpZmljYXRpb24tZXh0ZW5zaW9uLTAwDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0K PiA+ID4NCj4gPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLXAycHNpcC1ldmVu dC1ub3RpZmljYXRpb24tDQo+IGV4dGVuc2lvbi0wMC50eHQNCj4gPiA+IGhhcyBiZWVuIHN1Y2Nl c3NmdWx5IHN1Ym1pdHRlZCBieSBKdW4gV2FuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+ID4g PiByZXBvc2l0b3J5Lg0KPiA+ID4NCj4gPiA+IEZpbGVuYW1lOiBkcmFmdC13YW5nLXAycHNpcC1l dmVudC1ub3RpZmljYXRpb24tZXh0ZW5zaW9uDQo+ID4gPiBSZXZpc2lvbjogICAgICAgICAgICAg ICAgICAwMA0KPiA+ID4gVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQ MlBTSVAgRXZlbnQgDQo+IE5vdGlmaWNhdGlvbiBFeHRlbnNpb24NCj4gPiA+IENyZWF0aW9uX2Rh dGU6ICAgICAgICAgICAgICAgICAgMjAwOS0wMy0wMg0KPiA+ID4gV0cgSUQ6ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQo+ID4gPiBOdW1i ZXJfb2ZfcGFnZXM6IDIwDQo+ID4gPg0KPiA+ID4gQWJzdHJhY3Q6DQo+ID4gPiBUaGUgcDJwIHRl Y2hub2xvZ3kgaXMgZGF0YSBjZW50cmljLCB3aGVyZSB0aGUgZGF0YSBvYmplY3RzIGFyZQ0KPiA+ ID4gZGlzdHJpYnV0ZWQgaW4gdGhlIHAycCBvdmVybGF5IGFjY29yZGluZyB0byB0aGUgcm91dGlu ZyBhbGdvcml0aG0uDQo+ID4gPiBBcHBsaWNhdGlvbnMgYWNjZXNzIHRoZSBkYXRhIG9iamVjdHMg dmlhIHBlZXIvY2xpZW50IHByb3RvY29sIG9yDQo+ID4gPiBnYXRld2F5cywgYW5kIHNvbWUgb2Yg dGhlbSByZXF1aXJlIGRhdGEgcmVwbGljYXMgdG8gYmUgc3luY2hyb25pemVkDQo+ID4gPiBpbiBy ZWFsIHRpbWUsIHN1Y2ggYXMgYSBkYXRhIG9iamVjdCBzdG9yZWQgaW4gb3ZlcmxheSBhbmQgaXRz IGNhY2hlDQo+ID4gPiBjb3B5IGluIGNsaWVudCBtZW1vcnkuIFRoaXMgY2FuIGJlIGFjaGlldmVk IGJ5IGludHJvZHVjaW5nIGFuIGV2ZW50DQo+ID4gPiBub3RpZmljYXRpb24gZXh0ZW5zaW9uIHRv IHAycCBwcm90b2NvbC4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlDQo+ID4gPiBzdWJzY3Jp YmUvbm90aWZ5IG1lY2hhbmlzbSBmb3IgcDJwc2lwIGFuZCBkZWZpbmUgc2V2ZXJhbCBuZXcgbWV0 aG9kcw0KPiA+ID4gdG8gaW1wbGVtZW50IHN1Y2ggZXh0ZW5zaW9uLg0KPiA+ID4NCj4gPiA+DQo+ ID4gPg0KPiA+ID4NCj4gPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KPiA+ID4NCj4gPiA+DQo+ ID4gPg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gDQo+IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkg b2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsDQo+IGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgDQo+ IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyANCj4gb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gPiA+IFRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgDQo+IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gDQo+IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgDQo+IG5vdGlmeSB0aGUgb3JpZ2luYXRv ciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIA0KPiBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+ID4gPiBUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS0NCj4gU3Bh bSBzeXN0ZW0uDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gPiA+IFAyUFNJUEBp ZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBz aXANCj4gPiA+DQo+ID4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gU2luY2VyZWx5IHlv dXJzLA0KPiA+DQo+ID4gTGljaHVuIExpDQo+ID4gTW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwg QlVQVA0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPiBtYWlsIGlzIHNvbGVseSBwcm9w ZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgDQo+IGNvbW11bmlj YXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgDQo+IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyANCj4gb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4g PiBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCANCj4gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkNCj4gYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgDQo+IG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIA0KPiBtZXNz YWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+ID4gVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSAN CnN5c3RlbS4NCj4gDQo+IA0KPiANCj4gLS0NCj4gU2luY2VyZWx5IHlvdXJzLA0KPiANCj4gTGlj aHVuIExpDQo+IE1vYmlsZSBMaWZlIE5ldyBNZWRpYSBMYWIsIEJVUFQNCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0019C0D34825756F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5saWNodW4gbGkgJmx0O2xpbGljaHVuQGdtYWlsLmNvbSZn dDsg0LTT2iAyMDA5LTAzLTA0DQoxMDo0OTo0MTo8YnI+DQo8YnI+DQomZ3Q7IFNvIHRoZSBvdGhl ciBub2RlIHdpbGwgYXV0b21hdGljYWxseSBiZWNvbWUgbm90aWZpZXIgYmVmb3JlIHRoZTxicj4N CiZndDsgc3Vic2NyaWJlciByZWZyZXNoZXMgc3Vic2NyaXB0aW9uPzwvdHQ+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mj48dHQ+WWVzPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48 YnI+DQomZ3Q7IEFub3RoZXIgcXVlc3Rpb24uIFdoYXQgd2lsbCBhIG5vdGlmaWVyIGRvIGlmIGl0 IGRldGVjdHMgdGhhdCBhPGJyPg0KJmd0OyBzdWJzY3JpYmVyIGZhaWxzPzwvdHQ+PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mj48dHQ+Q3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBkb2Vzbid0 IHRha2UgYWNjb3VudA0Kb2YgdGhpcyBzaXR1YXRpb24uIFNpbmNlIHRoZSBub3RpZmllciBtYXkg bm90IGFkamFjZW50IHRvIHRoZSBzdWJzY3JpYmVyLA0KaXQncyBkaWZmaWN1bHQgdG8gcGVyZm9y bSBzdWNoIGEgZmFpbHVyZSBkZXRlY3Rpb24uIFRvIGVhc2UgdGhlIHNpdHVhdGlvbiwNCm5vdGlm aWVyIHNob3VsZCBjb25maWd1cmUgYSBhcHByb3ByaWF0ZSBleHBpcml0aW9uIHRpbWVyIGFuZCBw cm9oaWJpdCBwZXJtYW5lbnQNCnN1YnNjcmlwdGlvbi48L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0Pjxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDA5LzMvNCAmbHQ7d2FuZy5qdW4xN0B6 dGUuY29tLmNuJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3MgZm9yIHRo ZSBjb21tZW50cywgc2VlIDMuMy40PGJyPg0KJmd0OyAmZ3Q7IDMuMy40LiBTdG9yYWdlIGFuZCBy ZXBsaWNhdGlvbjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VGhl IE5vdGlmaWVyIE1VU1Qgc3RvcmUgdGhlIHN1YnNjcmlwdGlvbiBzdGF0ZSBhcw0KcGFydCBvZiBy ZXNvdXJjZTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ZGF0YSBvYmplY3QgYW5kIGVuZm9y Y2UgdGhlIHNhbWUgcmVwbGljYXRpb24gc3RyYXRlZ3kuDQpJbiBjYXNlIGEgbm9kZTxicj4NCiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ZmFpbHMsIHRoZSBvdGhlciBub2RlIHdoZXJlIHRoZSByZXBs aWNhIHN0b3JlZCBjYW4NCnByb2Nlc3MgYW55PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDty ZXF1ZXN0IHRvd2FyZHMgdGhlIHJlcGxpY2F0ZWQgcmVzb3VyY2UuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IFRoYW5rczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBsaWNo dW4gbGkgJmx0O2xpbGljaHVuQGdtYWlsLmNvbSZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgMjAwOS0wMy0wMyAyMDozODxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyDK1bz+ yMs8YnI+DQomZ3Q7ICZndDsgd2FuZy5qdW4xN0B6dGUuY29tLmNuPGJyPg0KJmd0OyAmZ3Q7ILOt y808YnI+DQomZ3Q7ICZndDsgJnF1b3Q7cDJwc2lwQGlldGYub3JnJnF1b3Q7ICZsdDtwMnBzaXBA aWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7INb3zOI8YnI+DQomZ3Q7ICZndDsgUmU6IFtQMlBT SVBdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1wMnBzaXAtZXZlbnQt PGJyPg0KJmd0OyBub3RpZmljYXRpb24tZXh0ZW5zaW9uLTAwPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkg dGhpbmsgc3Vic2NyaWJlL25vdGlmeSBtZWNobmlzbSBpcyB2ZXJ5IG5lY2Nlc2FyeSBhbmQgY2Fu IGFsc28NCmJlIHVzZWQ8YnI+DQomZ3Q7ICZndDsgdG8gaW5mb3JtIG90aGVyIGV2ZW50cyBvdGhl ciB0aGFuIGRhdGEgbW9kaWZpY2F0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBI YXZlIGNvbnNpZGVyIG5vdGlmaWVyIG1pZ3JhdGlvbj8gQXQgYSBnbGFuY2UsIEkgZG9uJ3QgZmlu ZCBub3RpZmllcjxicj4NCiZndDsgJmd0OyBtaWdyYXRpb24gaW4gdGhlIGRyYWZ0Ljxicj4NCiZn dDsgJmd0OyBJZiB0aGUgb3JpZ25hbCBub3RpZmllciBsZWF2ZXMgb3IgZmFpbHMsIGFub3RoZXIg cGVlciBzaG91bGQNCmJlY29tZTxicj4NCiZndDsgJmd0OyBuZXcgbm90aWZpZXIgaW1tZWRpYXRl bHkuPGJyPg0KJmd0OyAmZ3Q7IE90aGVyd2lzZSwgdGhlIHN1YnNjcmliZXIgbWF5IG5vdCBnZXQg dGhlIGxhdGVzdCBkYXRhIGZvciBhIHdoaWxlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBPbiBUdWUsIE1hciAzLCAyMDA5IGF0IDQ6MDUgUE0sICZuYnNwOyZsdDt3YW5nLmp1bjE3QHp0 ZS5jb20uY24mZ3Q7DQp3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7IEhpLGZvbGtzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBJIGhhdmUgd3Jv dGUgYSBkcmFmdCByZWdhcmRpbmcgcDJwc2lwIGV2ZW50DQpub3RpZmljYXRpb24gZXh0ZW5zaW9u LiBJPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhpbmsgaXQgY2FuIG1lZXQgdGhlIHJlcXVpcmVtZW50 cyBvZiByZWFsIHRpbWUgZGF0YSBhY2Nlc3MNCnNjZW5hcmlvLjxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBIb3BlIGZvciB5b3VyIGNvbW1lbnRz Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSUVURiBJLUQgU3VibWlz c2lvbiBUb29sICZsdDtpZHN1Ym1pc3Npb25AaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAyMDA5LTAzLTAyIDE5OjQwPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZndDsgJmd0OyB3YW5nLmp1 bjE3QHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyCzrcvNPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgY2hlbi56aGlmZW5nQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyDW98ziPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZuYnNwO2RyYWZ0LXdhbmctcDJwc2lwLWV2ZW50LW5vdGlmaWNhdGlvbi1leHRlbnNp b24tMDA8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdhbmctcDJwc2lwLWV2ZW50 LW5vdGlmaWNhdGlvbi08YnI+DQomZ3Q7IGV4dGVuc2lvbi0wMC50eHQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgSnVuIFdhbmcgYW5kIHBvc3Rl ZCB0bw0KdGhlIElFVEY8YnI+DQomZ3Q7ICZndDsgJmd0OyByZXBvc2l0b3J5Ljxicj4NCiZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO2RyYWZ0LXdhbmct cDJwc2lwLWV2ZW50LW5vdGlmaWNhdGlvbi1leHRlbnNpb248YnI+DQomZ3Q7ICZndDsgJmd0OyBS ZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7MDA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaXRsZTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUDJQU0lQ DQpFdmVudCA8YnI+DQomZ3Q7IE5vdGlmaWNhdGlvbiBFeHRlbnNpb248YnI+DQomZ3Q7ICZndDsg Jmd0OyBDcmVhdGlvbl9kYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsyMDA5LTAzLTAyPGJyPg0KJmd0OyAmZ3Q7ICZndDsg V0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEluZGVwZW5kZW50DQpTdWJtaXNzaW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsg TnVtYmVyX29mX3BhZ2VzOiAyMDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIHAycCB0ZWNobm9sb2d5IGlzIGRh dGEgY2VudHJpYywgd2hlcmUgdGhlIGRhdGEgb2JqZWN0cw0KYXJlPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgZGlzdHJpYnV0ZWQgaW4gdGhlIHAycCBvdmVybGF5IGFjY29yZGluZyB0byB0aGUgcm91dGlu Zw0KYWxnb3JpdGhtLjxicj4NCiZndDsgJmd0OyAmZ3Q7IEFwcGxpY2F0aW9ucyBhY2Nlc3MgdGhl IGRhdGEgb2JqZWN0cyB2aWEgcGVlci9jbGllbnQgcHJvdG9jb2wNCm9yPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgZ2F0ZXdheXMsIGFuZCBzb21lIG9mIHRoZW0gcmVxdWlyZSBkYXRhIHJlcGxpY2FzIHRv IGJlIHN5bmNocm9uaXplZDxicj4NCiZndDsgJmd0OyAmZ3Q7IGluIHJlYWwgdGltZSwgc3VjaCBh cyBhIGRhdGEgb2JqZWN0IHN0b3JlZCBpbiBvdmVybGF5IGFuZA0KaXRzIGNhY2hlPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgY29weSBpbiBjbGllbnQgbWVtb3J5LiBUaGlzIGNhbiBiZSBhY2hpZXZlZCBi eSBpbnRyb2R1Y2luZw0KYW4gZXZlbnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBub3RpZmljYXRpb24g ZXh0ZW5zaW9uIHRvIHAycCBwcm90b2NvbC4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMNCnRoZTxi cj4NCiZndDsgJmd0OyAmZ3Q7IHN1YnNjcmliZS9ub3RpZnkgbWVjaGFuaXNtIGZvciBwMnBzaXAg YW5kIGRlZmluZSBzZXZlcmFsDQpuZXcgbWV0aG9kczxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvIGlt cGxlbWVudCBzdWNoIGV4dGVuc2lvbi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZA0KaW4gPGJyPg0KJmd0OyB0aGlzIG1haWwgaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbDxicj4NCiZndDsg Y29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZA0KPGJyPg0KJmd0OyB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMNCjxicj4NCiZndDsgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy48YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsDQo8YnI+DQomZ3Q7 IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20NCjxicj4NCiZndDsgdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZQ0KPGJyPg0KJmd0OyBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcw0K PGJyPg0KJmd0OyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFDQpBbnRpLTxicj4NCiZndDsgU3BhbSBzeXN0ZW0uPGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IFAyUFNJUCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBQMlBTSVBAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsg Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcDxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS08YnI+DQomZ3Q7ICZndDsgU2lu Y2VyZWx5IHlvdXJzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBMaWNodW4gTGk8YnI+ DQomZ3Q7ICZndDsgTW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQlVQVDxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyBaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlz PGJyPg0KJmd0OyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgPGJyPg0KJmd0OyBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkDQo8YnI+DQomZ3Q7IHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cw0KPGJyPg0KJmd0OyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLjxicj4NCiZn dDsgJmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsDQphbmQgPGJyPg0KJmd0OyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleTxicj4NCiZndDsgYXJlIGFk ZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ug PGJyPg0KJmd0OyBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcw0KPGJyPg0KJmd0OyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBTaW5j ZXJlbHkgeW91cnMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExpY2h1biBMaTxicj4NCiZndDsgTW9i aWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQlVQVDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxwcmU+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtU aGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNw O2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRz Jm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5i c3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7 cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5i c3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0K VGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21p dHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2Fu ZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0 byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5i c3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7 aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdp bmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3Mm bmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5i c3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpU aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9y Jm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0Fu dGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0019C0D34825756F_=-- From wang.jun17@zte.com.cn Tue Mar 3 22:59:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705103A6B60; Tue, 3 Mar 2009 22:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.278 X-Spam-Level: X-Spam-Status: No, score=-90.278 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2safl+mX2Eni; Tue, 3 Mar 2009 22:59:36 -0800 (PST) Received: from mail.zte.com.cn (mail2.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 7015E3A6804; Tue, 3 Mar 2009 22:59:32 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 35764.3793085276; Wed, 4 Mar 2009 15:21:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n246x5Gg045737; Wed, 4 Mar 2009 14:59:07 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com> To: "Das, Saumitra" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Wed, 4 Mar 2009 14:58:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-04 14:58:58, Serialize complete at 2009-03-04 14:58:58 Content-Type: multipart/alternative; boundary="=_alternative 00265A984825756F_=" X-MAIL: mse1.zte.com.cn n246x5Gg045737 Cc: "p2psip@ietf.org" , p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogIE5ldyBMb2FkIGJhbGFuY2luZyBpbiBSRUxP?= =?gb2312?b?QUQgZHJhZnQ=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 06:59:37 -0000 This is a multipart message in MIME format. --=_alternative 00265A984825756F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgeW91ciBhcnRpY2xlLCBhbmQgYWdyZWUgdGhhdCBsb2FkIGJhbGFuY2luZyBp cyBhIGtleSBpc3N1ZSANCmVzcGVjaWFsbHkgd2hlbiB3ZSBkZXBsb3kgdGhlIGJhY2tlbmQgc2Vy dmVyIHN5c3RlbXMgYnVpbHQgYnkgcDJwIA0KdGVjaG5vbG9neS4NClNvbWUgcXVlc3Rpb25zIGZv bGxvd2luZzoNCjEpRG9lcyB0aGUgZmluZ2VyIHRhYmxlIG9ubHkgaW5jbHVkZSB0aGUgcHJpbWFy eSB2aXJ0dWFsIG5vZGUgSUQ/DQoyKUhvdyB0byBjaGFuZ2UgdGhlIGVzdGltYXRlZCBOIHBhcmFt ZXRlciAgYW5kIGtlZXAgdGhlIHNlcnZpY2VzIA0Kbm9uLXN0b3BwaW5nPyBTdXBwb3NpbmcgdGhh dCBpdCBoYXMgYmVlbiBmYXIgYXdheSBmcm9tIHRoZSBhY3R1YWwgbmV0d29yayANCnNjYWxlLg0K MylDb3VsZCB0aGUgaW1iYWxhbmNlIGZhY3RvciBiZSByZWR1Y2VkIGZ1cnRoZXI/DQoNCg0KUnVz c2VsbCBXYW5nDQoNCg0KDQpwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMDktMDMtMDQg MDk6MTA6NTE6DQoNCj4gSGkgYWxsLA0KPiANCj4gSSBqdXN0IHN1Ym1pdHRlZCBhIGRyYWZ0IHRo YXQgcHJvcG9zZXMgYSBsb2FkIGJhbGFuY2luZyBzb2x1dGlvbiBmb3INCj4gdGhlIGRlZmF1bHQg REhUIGluIFJFTE9BRC4gQ29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KPiANCj4gDQpodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zYXVtaXRyYS1wMnBzaXAtbG9hZGJh bGFuY2UtMDAudHh0IA0KDQo+IA0KPiBCZXN0LA0KPiBTYXVtaXRyYQ0KPiANCj4gDQo+IA0KPiAN Cj4gd3d3LnNhdW1pdHJhLmluZm8gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0u DQo= --=_alternative 00265A984825756F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSByZWFkIHlvdXIgYXJ0 aWNsZSwgYW5kIGFncmVlDQp0aGF0IGxvYWQgYmFsYW5jaW5nIGlzIGEga2V5IGlzc3VlIGVzcGVj aWFsbHkgd2hlbiB3ZSBkZXBsb3kgdGhlIGJhY2tlbmQNCnNlcnZlciBzeXN0ZW1zIGJ1aWx0IGJ5 IHAycCB0ZWNobm9sb2d5LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+U29tZSBxdWVzdGlvbnMgZm9sbG93aW5nOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+MSlEb2VzIHRoZSBmaW5nZXIgdGFibGUgb25seSBpbmNsdWRlDQp0aGUg cHJpbWFyeSB2aXJ0dWFsIG5vZGUgSUQ/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4yKUhvdyB0byBjaGFuZ2UgdGhlIGVzdGltYXRlZCBOIHBhcmFtZXRlcg0KJm5i c3A7YW5kIGtlZXAgdGhlIHNlcnZpY2VzIG5vbi1zdG9wcGluZz8gU3VwcG9zaW5nIHRoYXQgaXQg aGFzIGJlZW4gZmFyDQphd2F5IGZyb20gdGhlIGFjdHVhbCBuZXR3b3JrIHNjYWxlLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MylDb3VsZCB0aGUgaW1iYWxhbmNl IGZhY3RvciBiZSByZWR1Y2VkDQpmdXJ0aGVyPzwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UnVzc2VsbCBXYW5nPGJyPg0KPGJyPg0KPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmcg0LTT 2iAyMDA5LTAzLTA0IDA5OjEwOjUxOjxicj4NCjxicj4NCiZndDsgSGkgYWxsLDxicj4NCiZndDsg PGJyPg0KJmd0OyBJIGp1c3Qgc3VibWl0dGVkIGEgZHJhZnQgdGhhdCBwcm9wb3NlcyBhIGxvYWQg YmFsYW5jaW5nIHNvbHV0aW9uIGZvcjxicj4NCiZndDsgdGhlIGRlZmF1bHQgREhUIGluIFJFTE9B RC4gQ29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zYXVtaXRyYS1wMnBzaXAtbG9hZGJh bGFuY2UtMDAudHh0DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCw8YnI+DQomZ3Q7IFNhdW1p dHJhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IHd3dy5zYXVtaXRyYS5pbmZvIDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7IFAyUFNJUEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wMnBzaXA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48cHJlPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNw O0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5m b3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7 aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVy J3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVk Jm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWlu Jm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZu YnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7 dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtl bWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRl bmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9t Jm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJy b3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVz c2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVz ZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJz cDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00265A984825756F_=-- From lilichun@gmail.com Tue Mar 3 23:19:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948A93A6AFE for ; Tue, 3 Mar 2009 23:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.779 X-Spam-Level: *** X-Spam-Status: No, score=3.779 tagged_above=-999 required=5 tests=[AWL=-3.329, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljjYE2BZQNvI for ; Tue, 3 Mar 2009 23:19:56 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id 2677628C2C2 for ; Tue, 3 Mar 2009 23:19:55 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so378868nfh.39 for ; Tue, 03 Mar 2009 23:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CYKpDv050aVxznOrqOaN+5UzW57kiBu7UM8pI+LeCfs=; b=KHOWVzfhoQE5QTFb84X/8CyE2SGg+BFEriZPOauM6yiTzvAOQGsSu6gsLOp4I1RvkP GMM5ak52GZBGbcM9w29DJJoBq0ICQFaNRuC/D0tnYSV/6KAocDXHioTbFJPQBl9ksShA ll+DpzUAf27YLW3CpweY4uvaMXL1kO9QzWjUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UWJH2ka9UmUUmd7R+d4l4NGCwsLDVbvaM0OBG7oR/4+4y3O+i0j7t5h5JmzX8K6GB8 OompJtgU3nPG+Yez6aSy+2SGLC+FteEIthr9imU53mj8luNSOU24Qqv2p7+PkMgpmmt/ AYgI3URgGg8/nQkam2Owvj9YJzowEY7JtfMNI= MIME-Version: 1.0 Received: by 10.210.20.17 with SMTP id 17mr4983264ebt.45.1236151223046; Tue, 03 Mar 2009 23:20:23 -0800 (PST) In-Reply-To: References: <7d6b50690903031849n66e286f7kaf2e7266fe5c26ac@mail.gmail.com> Date: Wed, 4 Mar 2009 15:20:21 +0800 Message-ID: <7d6b50690903032320j512aada1q938290df5a4bb210@mail.gmail.com> From: lichun li To: wang.jun17@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgTmV3IFZlcnNpb24g?= =?gb2312?b?Tm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLXAycHNpcC1ldmVu?= =?gb2312?b?dC1ub3RpZmljYXRpb24tZXh0ZW5zaW9uLTAw?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 07:19:57 -0000 2009/3/4 : > > lichun li =D0=B4=D3=DA 2009-03-04 10:49:41: > >> So the other node will automatically become notifier before the >> subscriber refreshes subscription? > Yes > >> Another question. What will a notifier do if it detects that a >> subscriber fails? > Current version of the draft doesn't take account of this situation. Sinc= e > the notifier may not adjacent to the subscriber, it's difficult to perfor= m > such a failure detection. To ease the situation, notifier should configur= e a > appropriate expirition timer and prohibit permanent subscription. I think notifier can detect subscriber's failing if the subscriber doesn't respond to notify messages. >> >> 2009/3/4 >> > >> > Thanks for the comments, see 3.3.4 >> > 3.3.4. Storage and replication >> > >> > The Notifier MUST store the subscription state as part of resource >> > data object and enforce the same replication strategy. In case a no= de >> > fails, the other node where the replica stored can process any >> > request towards the replicated resource. >> > >> > Thanks >> > >> > >> > >> > >> > >> > lichun li >> > >> > 2009-03-03 20:38 >> > >> > =CA=D5=BC=FE=C8=CB >> > wang.jun17@zte.com.cn >> > =B3=AD=CB=CD >> > "p2psip@ietf.org" >> > =D6=F7=CC=E2 >> > Re: [P2PSIP] New Version Notification for draft-wang-p2psip-event- >> notification-extension-00 >> > >> > >> > >> > >> > I think subscribe/notify mechnism is very neccesary and can also be us= ed >> > to inform other events other than data modification. >> > >> > Have consider notifier migration? At a glance, I don't find notifier >> > migration in the draft. >> > If the orignal notifier leaves or fails, another peer should become >> > new notifier immediately. >> > Otherwise, the subscriber may not get the latest data for a while. >> > >> > On Tue, Mar 3, 2009 at 4:05 PM, wrote: >> > > >> > > Hi,folks >> > > I have wrote a draft regarding p2psip event notification >> > > extension. I >> > > think it can meet the requirements of real time data access scenario= . >> > > >> > > Hope for your comments. >> > > >> > > IETF I-D Submission Tool >> > > >> > > 2009-03-02 19:40 >> > > >> > > =CA=D5=BC=FE=C8=CB >> > > wang.jun17@zte.com.cn >> > > =B3=AD=CB=CD >> > > chen.zhifeng@zte.com.cn >> > > =D6=F7=CC=E2 >> > > New Version Notification for >> > > draft-wang-p2psip-event-notification-extension-00 >> > > >> > > >> > > >> > > >> > > >> > > A new version of I-D, draft-wang-p2psip-event-notification- >> extension-00.txt >> > > has been successfuly submitted by Jun Wang and posted to the IETF >> > > repository. >> > > >> > > Filename: >> > > draft-wang-p2psip-event-notification-extension >> > > Revision: 00 >> > > Title: P2PSIP Event >> Notification Extension >> > > Creation_date: 2009-03-02 >> > > WG ID: Independent Submission >> > > Number_of_pages: 20 >> > > >> > > Abstract: >> > > The p2p technology is data centric, where the data objects are >> > > distributed in the p2p overlay according to the routing algorithm. >> > > Applications access the data objects via peer/client protocol or >> > > gateways, and some of them require data replicas to be synchronized >> > > in real time, such as a data object stored in overlay and its cache >> > > copy in client memory. This can be achieved by introducing an event >> > > notification extension to p2p protocol. This document describes the >> > > subscribe/notify mechanism for p2psip and define several new methods >> > > to implement such extension. >> > > >> > > >> > > >> > > >> > > The IETF Secretariat. >> > > >> > > >> > > >> > > -------------------------------------------------------- >> > > ZTE Information Security Notice: The information contained in >> this mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents >> of this communication to others. >> > > This email and any files transmitted with it are confidential >> and intended solely for the use of the individual or entity to whom >> they are addressed. If you have received this email in error please >> notify the originator of the message. Any views expressed in this >> message are those of the individual sender. >> > > This message has been scanned for viruses and Spam by ZTE Anti- >> Spam system. >> > > >> > > _______________________________________________ >> > > P2PSIP mailing list >> > > P2PSIP@ietf.org >> > > https://www.ietf.org/mailman/listinfo/p2psip >> > > >> > > >> > >> > >> > >> > -- >> > Sincerely yours, >> > >> > Lichun Li >> > Mobile Life New Media Lab, BUPT >> > >> > >> > -------------------------------------------------------- >> > ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated >> to maintain secrecy and are not permitted to disclose the contents >> of this communication to others. >> > This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please >> notify the originator of the message. Any views expressed in this >> message are those of the individual sender. >> > This message has been scanned for viruses and Spam by ZTE Anti-Spam >> > system. >> >> >> >> -- >> Sincerely yours, >> >> Lichun Li >> Mobile Life New Media Lab, BUPT > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT From zongning@huawei.com Wed Mar 4 03:55:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33E33A6B4F for ; Wed, 4 Mar 2009 03:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.266 X-Spam-Level: X-Spam-Status: No, score=-93.266 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MANGLED_EMAIL=2.3, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaCynPwpPW02 for ; Wed, 4 Mar 2009 03:55:31 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2E27A3A6892 for ; Wed, 4 Mar 2009 03:55:31 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFZ00IWFD58GE@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 04 Mar 2009 19:55:56 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFZ00G2ED58NH@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 04 Mar 2009 19:55:56 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.81]) by szxmc04-in.huawei.com (mshttpd); Wed, 04 Mar 2009 19:55:56 +0800 Date: Wed, 04 Mar 2009 19:55:56 +0800 From: zongning 63316 In-reply-to: <015f01c99720$97da17d0$c78e4770$@re.kr> To: Softgear Ko Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <016201c9948d$a29a98b0$8410fe81@etri.info> <015f01c99720$97da17d0$c78e4770$@re.kr> Cc: p2psip@ietf.org Subject: [P2PSIP] =?gb2312?b?u9i4tCA6UkU6ICBOZXcgSVBUViBVc2FnZSBkcmFmdC1z?= =?gb2312?b?b2Z0Z2Vhci1wMnBzaXAtaXB0di0wMA==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 11:55:33 -0000 Thank you=2C Ko=2E I understand your point now and I think it does make sense if noly channe= l information (not chunk information) is managed by RELOAD overlay=2E The= RELOAD overlay will actually act as a distributed directory server for P= 2P streaming=2C a=2Ek=2Ea=2E Trackers in most current P2P streaming syste= ms=2E (I would like to use P2P streaming rather than IPTV) As you may know=2C PPSP BoF focus on distributed media resource location = and transmission=2E The border between PPSP and RELOAD overlay could be f= ound in PPSP requirement draft as below=3A http=3A//www=2Eietf=2Eorg/internet-drafts/draft-zong-ppsp-reqs-00=2Etxt One of my concern is that the Channel Manager would be not necessary for = some use cases such as data-driven streaming model where peers interact w= ith each other and setup session by themselves=2E Channel Manager is usef= ul in overlay multicast to control the overall data transmission topology= =2E So I would suggest that more use cases are still needed to expand this do= cument=2E I will provide more information later on this document=2E Anywa= y=2C I think your draft is a good start for the non-trivial study of the = impact of P2P streaming on both RELOAD and PPSP=2E Hope to see you guys in SF=2E Best Regards Ning Zong *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained herein in any way (in= cluding=2C but not limited to=2C total or partial disclosure=2C reproduct= ion=2C or dissemination) by persons other than the intended recipient(s) = is prohibited=2E If you receive this e-mail in error=2C please notify the= sender by phone or em ail immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Softgear Ko =3Csoftgear=40etri=2Ere=2Ekr=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =B6=FE=D4=C2 25=C8=D5=2C 2009 =CF=C2= =CE=E74=3A12 =D6=F7=CC=E2=3A RE=3A =5BP2PSIP=5D New IPTV Usage draft-softgear-p2psip-i= ptv-00 =CA=D5=BC=FE=C8=CB=3A =27zongning 63316=27 =3Czongning=40huawei=2Ecom=3E =B3=AD=CB=CD=3A p2psip=40ietf=2Eorg =3E Hello=2C Ning Zong=2E =3E = =3E Thank you for your comments=2E =3E = =3E In churn=2C a Viewer or a Relay would ask the Channel Manager to re- =3E estabilishmedia path=2E But=2C because the Viewer (or relay) has = =3E already connected to the =3E Channel Manager=2C the Viewer does not use RELOAD overlay=2E The = =3E Viewer ask the =3E Channel Manager using =22Media Delivery Network Control protocol=22=2E= = =3E Once a =3E Viewer or a Relay find a Channel Manager from RELOAD overlay=2C he = =3E does not =3E access RELOAD overlay any more for this channel=2E Therefore=2C Askin= g the =3E Channel Manager to reestablish media path does not load RELOAD = =3E overlay=2E The =3E VoD case is also similar=2E In a centralized server=2C one VoD server= gets =3E stress from all viewer for all channel=2E However=2C in this distribu= tion =3E system=2C only one virtual server gets stress from viewers for one = =3E channel=2E =3E According to =22Media Delivery Network Control Protocol=22=2C a chann= el = =3E manager in =3E this draft can works as a entry point to join a (non-RELOAD) overlay =3E multicast tree for this channel=2E Therefore=2C The role of Channel = =3E managerdepends on =22=22Media Delivery Network Control Protocol=22=2E= =3E = =3E In this draft=2C I focus on the scalability problem when there are = =3E too many =3E channels=2E Now on in the future=2C there will be lots of IPTV channe= l =3E (including UCC) in the world=2E RELOAD will contain them=2C find them= =2C and =3E connect them=2E =3E I also know the scalability problem when there are too many = =3E viewers for one =3E channel=2E I think that PPSP can be a good solution for it=2E =3E = =3E = =3E Best Regards=2C =3E Seokkap Ko=2E =3E = =3E = =3E = =3E -----Original Message----- =3E From=3A zongning 63316 =5Bmailto=3Azongning=40huawei=2Ecom=5D = =3E Sent=3A Monday=2C February 23=2C 2009 5=3A44 PM =3E To=3A Ko=2C Seokkap =3E Cc=3A p2psip=40ietf=2Eorg =3E Subject=3A =BB=D8=B8=B4=3A=5BP2PSIP=5D New IPTV Usage draft-softgear-= p2psip-iptv-00 =3E = =3E = =3E Hi=2C Ko=2C =3E I believe that introduing distributed IPTV technique is a quite = =3E interestingand challenging work=2E But I would like to suggest that = =3E the use case and =3E characteristic of each distributed service is the first thing to = =3E think about =3E before adopting them to RELOAD overlay=2E IMO=2C unlike VoIP=2C = =3E distributed (or =3E P2P=3F) IPTV is often called a =22community=22 who involves many = =3E intermediatenodes (or relay in your draft) to share media=2E These = =3E nodes may be subject =3E to highly dynamical behavior (e=2Eg=2E churn)=2E That means each = =3E receiver would =3E contact with Channel Manager on the RELOAD overlay frequently to = =3E ask for =3E media path adaptation=2C which in turn places unexpectable load on = =3E RELOADoverlay=2E Another case is VoD=2C where each receiver would ask= = =3E for transmission =3E of any piece of media on any time=2E =3E So my suggestion is to consider how to use RELOAD overlay = =3E properly=2E Which =3E parts of distributed service can be managed by RELOAD overlay=3F If =3E scalability is not a critical issue=2C why not use centralized = =3E server=3F E=2Eg=2E =3E limited number of channels can be managed by some centralized = =3E servers - just =3E like trackers in PPLive system=2E Would it be better to utilize peers= =3E themselves to exchange content information such as which IPTV = =3E media pieces =3E is stored = =3E in which peers between each other=3F =3E Just for your information=2C you can also refer to PPSP mailing list = =3E where a =3E lot of P2P streaming use cases have been discussed and standardizatio= n =3E requirements will be addressed=2E =3E = =3E Further comments are welcome! =3E = =3E Best Regards =3E Ning Zong =3E = =3E *********************************************************************= ******* =3E ************** =3E This email and its attachments contain confidential information from =3E HUAWEI=2C which is intended only for the person or entity whose = =3E address is =3E listed above=2E Any use of the information contained herein in any wa= y =3E (including=2C but not limited to=2C total or partial disclosure=2C = =3E reproduction=2Cor dissemination) by persons other than the intended = =3E recipient(s) is =3E prohibited=2E If you receive this e-mail in error=2C please notify th= e = =3E sender by =3E phone or em =3E ail immediately and delete it! =3E = =3E *********************************************************************= ******* =3E ************* =3E = =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =B7=A2=BC=FE=C8=CB=3A =22Ko=2C Seokkap=22 =3Csoftgear=40etri=2Ere=2Ek= r=3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=D5=2C =B6=FE=D4=C2 22=C8=D5=2C 2009 =C9= =CF=CE=E79=3A34 =3E =D6=F7=CC=E2=3A =5BP2PSIP=5D New IPTV Usage draft-softgear-p2psip-ipt= v-00 =3E =CA=D5=BC=FE=C8=CB=3A p2psip=40ietf=2Eorg =3E = =3E =3E Hello folks=2C I have just submitted a draft which proposes a = =3E =3E distributed IPTV Usage for RELOAD=2E RELOAD does not only support= = =3E =3E SIP based VoIP service but also other services=2E This IPTV Usage= = =3E of = =3E =3E RELOAD allows RELOAD to store IPTV related information within = =3E the = =3E =3E overlay=2E A URL for this Internet-Draft = =3E =3E is=3Ahttp=3A//www=2Eietf=2Eorg/internet-drafts/draft-softgear-p2p= sip- =3E iptv- =3E =3E 00=2Etxt any comment is appreciated=2E Best Regards=2CSeokkap Ko=2E= = =3E =3E = =3E =3E -----Original Message----- = =3E =3E From=3A =22IETF I-D Submission Tool=22 =3Cidsubmission=40ietf=2Eo= rg=3E = =3E =3E From Date=3A 2009-02-21 =3F=3F 9=3A57=3A04 = =3E =3E To=3A =22softgear=40dcn=2Essu=2Eac=2Ekr=22 =3Csoftgear=40dcn=2Ess= u=2Eac=2Ekr=3E = =3E =3E Cc=3A =22younghak=40ssu=2Eac=2Ekr=22 =3Cyounghak=40ssu=2Eac=2Ekr=3E= =2C = =3E =3E =22bytelee=40etri=2Ere=2Ekr=22 =3Cbytelee=40etri=2Ere=2Ekr=3E = =3E =3E Subject=3A New Version Notification for draft-softgear-p2psip-ipt= v- =3E =3E 00 = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E A new version of I-D=2C draft-softgear-p2psip-iptv-00=2Etxt has b= een = =3E =3E successfuly submitted by Seok-Kap Ko and posted to the IETF = =3E =3E repository=2E = =3E =3E = =3E =3E Filename=3A draft-softgear-p2psip-iptv = =3E =3E Revision=3A 00 = =3E =3E Title=3A An IPTV Usage for RELOAD = =3E =3E Creation=5Fdate=3A 2009-02-21 = =3E =3E WG ID=3A Independent Submission = =3E =3E Number=5Fof=5Fpages=3A 15 = =3E =3E = =3E =3E Abstract=3A = =3E =3E This document defines a distributed IPTV Usage for Resource = =3E =3E Location = =3E =3E And Discovery (RELOAD)=2E The IPTV Usage provides lookup service = =3E for = =3E =3E IPTV channel information and IPTV metadata stored in the = =3E overlay=2E = =3E =3E The = =3E =3E Attach method is used to establish a direct connection between a = =3E =3E distributed channel manager and a viewer=2E IPTV control messages= = =3E =3E are = =3E =3E exchanged through this connection=2E = =3E =3E = =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E The IETF Secretariat=2E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E = =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E P2PSIP mailing list =3E =3E P2PSIP=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/p2psip =3E =3E = =3E = =3E From michaelc@IDSSOFTWARE.COM Wed Mar 4 05:39:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B96A3A68D4 for ; Wed, 4 Mar 2009 05:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLKgmW0bAp+C for ; Wed, 4 Mar 2009 05:39:24 -0800 (PST) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by core3.amsl.com (Postfix) with SMTP id A75E63A68CC for ; Wed, 4 Mar 2009 05:39:24 -0800 (PST) Received: (qmail 23123 invoked from network); 4 Mar 2009 13:39:52 -0000 Received: from unknown (HELO gem-wbe41.prod.mesa1.secureserver.net) (64.202.189.120) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 4 Mar 2009 13:39:52 -0000 Received: (qmail 25584 invoked by uid 99); 4 Mar 2009 13:39:52 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 64.203.45.253 User-Agent: Web-Based Email 4.14.21 Message-Id: <20090304063952.61e8c06078a3b23a733c71e914c0b9df.a6ae927188.wbe@email.secureserver.net> From: To: "Eric Rescorla" Date: Wed, 04 Mar 2009 06:39:52 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 13:39:25 -0000 Eric, > -------- Original Message -------- > Subject: Re: [P2PSIP] proposal for reload congestion control, > fragmentation, and retransmission > From: Eric Rescorla =20 >=20 > [Note: please figure out how to send plaintext email. HTML is > not convenient for me] >=20 > At Tue, 03 Mar 2009 04:30:57 -0700, > > > This framing is also going to be used with TLS, so you do need
> > > the length there. I'd rather have a consistent framing than
> > > save 3 bytes.
> >=20 >=20 > > My thought section 5.2.2 is for unreliable link (UDP/DTLS) only. >=20 > Editorial error. It was our intent that everything be framed. It would be helpful if a section of the draft present a complete logical view of all frames and protocol layers. > > I assume the TLS record layer is sufficient for TCP. >=20 > TLS does not preserve write boundaries. >=20 >=20 > > Even if framing > > is used for TCP, wouldn't it be using rfc4571 as suggested by > > draft-ietf-mmusic-ice-tcp-07? Please clarify. >=20 > No, that's at the wrong layer--below TLS rather than above. >=20 > -Ekr Okay, the FramedMessage is encrypted by TLS/DTLS. Then why mention demultiplexing with STUN. I don't believe STUN is send inside the TLS/DTLS layload. According to ICE, STUN should be at the outer most layer inside the TCP/UDP frame, so there are only two protocols being multiplexed inside the TCP/UDP frame: STUN and TLS/DTLS. Please confirm. Thanks --Michael From ekr@networkresonance.com Wed Mar 4 07:01:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38773A6C8F for ; Wed, 4 Mar 2009 07:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW5o0wbsLO4o for ; Wed, 4 Mar 2009 07:01:51 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3AD5B3A67C0 for ; Wed, 4 Mar 2009 07:01:51 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2CAC950822; Wed, 4 Mar 2009 07:25:06 -0800 (PST) Date: Wed, 04 Mar 2009 07:25:06 -0800 From: Eric Rescorla To: In-Reply-To: <20090304063952.61e8c06078a3b23a733c71e914c0b9df.a6ae927188.wbe@email.secureserver.net> References: <20090304063952.61e8c06078a3b23a733c71e914c0b9df.a6ae927188.wbe@email.secureserver.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090304152506.2CAC950822@romeo.rtfm.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 15:01:52 -0000 At Wed, 04 Mar 2009 06:39:52 -0700, wrote: > Okay, the FramedMessage is encrypted by TLS/DTLS. Naturally. > Then why mention > demultiplexing with STUN. I don't believe STUN is send inside the > TLS/DTLS layload. According to ICE, STUN should be at the outer most > layer inside the TCP/UDP frame, so there are only two protocols being > multiplexed inside the TCP/UDP frame: STUN and TLS/DTLS. Please confirm. Right. Thinko by one of the authors. -Ekr From davidbryan@gmail.com Wed Mar 4 13:15:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F4028C3EE for ; Wed, 4 Mar 2009 13:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBl5RiJCEAMo for ; Wed, 4 Mar 2009 13:15:02 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 8500D3A6874 for ; Wed, 4 Mar 2009 13:15:02 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3995735wfd.31 for ; Wed, 04 Mar 2009 13:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i+31xCYB7qSOOAmITeiYStS3Lt5+00k6ucr1ddxcbws=; b=I+6MTQbhe9nPd/BTkBd06syeyVmI1seMbem0OA0Rl0nuRMteYfE9Ack8WMxUSLyLT6 R0iaxIqqKONW+81Wd79eLZAwkKNE0Vx5MqjkaEPywAMi4g+/1omdEF2dB60cs4SnBYWq IEVpckx+d0X6Ps+Act+6Is7rufckMRdDAOJIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=qfHZW9G5pUjCjBvvHnc2AtFl+eIsJNjgVJWtG9jcRrx986XYvkkVw07ZT7eG8YMEnS cPHKoXdg+r1NuAl5vIxNggc8snzoJeaL0gfL3WlYOpNfTVrQcLagDp8zKYhbSn2s0xOo YQbxIcyxAgvq1tphFKnJa9pLNhPh2xncVrvEE= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.142.57.19 with SMTP id f19mr125714wfa.80.1236201331231; Wed, 04 Mar 2009 13:15:31 -0800 (PST) Date: Wed, 4 Mar 2009 16:15:31 -0500 X-Google-Sender-Auth: 0fa9cb3cdd4ae99a Message-ID: <8b2769930903041315x164bc4bjdb3f8d67da8cafda@mail.gmail.com> From: "David A. Bryan" To: "p2psip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Agenda Requests X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2009 21:15:03 -0000 With the draft agendas due in one week, I wanted to start the process of putting together an agenda. If you would like to request a slot to speak, please send Brian and I a request. As usual, just because you request a slot doesn't mean you will get it -- we'll give slots to drafts that have had extensive discussion and that have problems that can be resolved in the meeting, and WG drafts have priority, as usual. Thanks, David (as chair) From vidyan@qualcomm.com Thu Mar 5 13:19:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7663A6AA7 for ; Thu, 5 Mar 2009 13:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y3944VMvI+5 for ; Thu, 5 Mar 2009 13:19:14 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CF4EC3A6821 for ; Thu, 5 Mar 2009 13:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1236287984; x=1267823984; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Eric=20Rescorla=20|CC:=20"p2 psip@ietf.org"=20|Date:=20Thu,=205=20Mar =202009=2013:19:35=20-0800|Subject:=20RE:=20[P2PSIP]=20Dy namically=20introducing=20new=20types|Thread-Topic:=20[P2 PSIP]=20Dynamically=20introducing=20new=20types |Thread-Index:=20Acl0+CuI8ZAabowlQAq3b+UtVfJfogo2Pa+Q |Message-ID:=20|References:=20<2008121916442 1.9858050822@romeo.rtfm.com>=0D=0A=09=0D=0A =09<20090109183932.A272850822@romeo.rtfm.com>=0D=0A=09=0D=0A=20<20090112205556.3B911EA71B@kilo.local> |In-Reply-To:=20<20090112205556.3B911EA71B@kilo.local> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5544"=3B=20a=3D"16004896"; bh=oG4KVf4B0sgkGOkuUGNr0C//F7WVNHPF3bckBkPBe3A=; b=WUD3Kkc3CyBrO3qk3FGv9nIG5NU6zh7IsIR4NjNZEdyVPlgQvkTRMlIq X77thFaL7QkL+XyboHEMmEkBZzLmHYLwh8M6I1sn3EIFZM8KjV9x408Y3 1O7AOVQHGZY4sVZCyPTS4zIizNbLQYfegj7/Botw90swpGtSCVejg7gyQ 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5544"; a="16004896" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2009 13:19:44 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n25LJirH026416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Mar 2009 13:19:44 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n25LJARt023835 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Mar 2009 13:19:44 -0800 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 5 Mar 2009 13:19:36 -0800 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 5 Mar 2009 13:19:37 -0800 From: "Narayanan, Vidya" To: Eric Rescorla Date: Thu, 5 Mar 2009 13:19:35 -0800 Thread-Topic: [P2PSIP] Dynamically introducing new types Thread-Index: Acl0+CuI8ZAabowlQAq3b+UtVfJfogo2Pa+Q Message-ID: References: <20081219164421.9858050822@romeo.rtfm.com> <20090109183932.A272850822@romeo.rtfm.com> <20090112205556.3B911EA71B@kilo.local> In-Reply-To: <20090112205556.3B911EA71B@kilo.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Dynamically introducing new types X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 05 Mar 2009 21:19:16 -0000 Apologies for picking up this thread after a really long period of silence.= . a long vacation got in the way :)=20 =20 > > > > What I meant was that the type of authorization rule applied will be > > indicated in the message, rather than needing to look up a > > configuration document. >=20 > I'm sorry, I still don't see how this is going to work: the > sender and the receiver of the message are potentially adversarial: > for instance, the sender may want to delete data belonging to > someone else. This means that the recipient needs to be able > to determine the correct access control rule in a way that > the sender can't interfere with. Otherwise the sender can > just choose an access control rule which is most permissive for > his purposes. >=20 Sorry, I'm not sure I understand this. Are you saying that Bob could potent= ially choose an authorization rule that allows his ResourceID to map to Ali= ce's ResourceID that followed the legitimate authorization rule? That shou= ldn't happen with a good hash function. And, in general, one node should n= ever be able to delete data corresponding to any other node, unless explici= tly authorized to do so. A part of the problem here may be that RELOAD doe= s not yet address delegation of data access control. I think that by defaul= t, data should be stored against the creator id, and data from one creator = must never overwrite data from another creator. We probably should also ad= d support for ACLs of some kind to be associated with the data, thereby all= owing the creator to specify other nodes/users that can actually modify the= ir data. =20 Apart from the above, I also want to go back to the set of authorization ru= les you had proposed:=20 " - User must have a certificate with H(user_name) =3D=3D Resource-ID in order to write or delete. - User must have a certificate with H(user_name) =3D=3D Resource-ID in order to write or delete and Node-Id matches the dictionary key [used for SIP Registration] - User must have a certificate with H(NodeID) =3D=3D Resource-ID in order to write or delete. - User must have a certificate with H(NodeID || integer) =3D=3D Resource= -ID for integer < X in order to write or delete. [used for TURN service] - Any user may write. User must have a certificate with H(user_name) =3D=3D Resource-ID in order to overwrite or delete [allegedly useful for voice mail.]"=20 I think we also need to allow for a rule where there is no constraint in th= e resource name construction. Even though we don't yet have a kind that ne= eds it (I'll argue in a separate thread that the TURN-SERVICE kind really s= hould), this is very useful to have for allowing keyword-like searches even= tually. And, we can easily see that being necessary to support a generic s= uite of applications on the DHT. In order to support this, I think we shou= ld allow for the case where any user may write or retrieve without constrai= nts to the resource id - but, only the creator (or when delegation is possi= ble, other nodes explicitly authorized by the creator) can overwrite or del= ete the data. =20 Cheers, Vidya From saumitra@qualcomm.com Fri Mar 6 12:57:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198C43A676A for ; Fri, 6 Mar 2009 12:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.664 X-Spam-Level: X-Spam-Status: No, score=-104.664 tagged_above=-999 required=5 tests=[AWL=1.335, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM946Zz3t5UU for ; Fri, 6 Mar 2009 12:57:33 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9EEB13A6870 for ; Fri, 6 Mar 2009 12:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1236373084; x=1267909084; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"wang.jun17@zte.com.cn"=20|CC: =20"p2psip@ietf.org"=20|Date:=20Fri,=206 =20Mar=202009=2012:57:59=20-0800|Subject:=20RE:=20[P2PSIP ]=20New=20Load=20balancing=20in=20RELOAD=20draft |Thread-Topic:=20[P2PSIP]=20New=20Load=20balancing=20in =20RELOAD=20draft|Thread-Index:=20AcmcltggXiMjnBL0Q0SsObR u/5ygaQCBlSQw|Message-ID:=20<2D06DE445C2ADE44890118C3F449 B9634009A1B9@NASANEXMB12.na.qualcomm.com>|References:=20< 2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.q ualcomm.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5545"=3B=20 a=3D"16056845"; bh=ACbUH07oTdj119hCU7DPj//EPlfeZ8dbZTe1EzVGRS0=; b=zCbkdk3DHfzasleYWs+bCdVdgBc3E0xwLaXw4EqMBqDxsl+Lz+5doXYf OzFZQbrON+bnQ76+/jLvHhwt94ah8MhdO89JDmhjpeCTI56/HkNpI+pu8 uagC8s50LFligCtdv7GTsTaMdu5pfFuTBsTUFm0Pd1x3sW+ZO8RpyuLZ+ g=; X-IronPort-AV: E=McAfee;i="5300,2777,5545"; a="16056845" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2009 12:58:04 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26Kw4u1025663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2009 12:58:04 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26Kw1ag020432 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Mar 2009 12:58:04 -0800 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Fri, 6 Mar 2009 12:58:00 -0800 From: "Das, Saumitra" To: "wang.jun17@zte.com.cn" Date: Fri, 6 Mar 2009 12:57:59 -0800 Thread-Topic: [P2PSIP] New Load balancing in RELOAD draft Thread-Index: AcmcltggXiMjnBL0Q0SsObRu/5ygaQCBlSQw Message-ID: <2D06DE445C2ADE44890118C3F449B9634009A1B9@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] New Load balancing in RELOAD draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 06 Mar 2009 20:57:41 -0000 SGkgUnVzc2VsbCwNCg0KICBUaGFua3MgZm9yIGdvaW5nIHRocm91Z2ggdGhlIGRyYWZ0Lg0KDQog IDEpRG9lcyB0aGUgZmluZ2VyIHRhYmxlIG9ubHkgaW5jbHVkZSB0aGUgcHJpbWFyeSB2aXJ0dWFs IG5vZGUgSUQ/IA0KDQogIFRoZSBmaW5nZXIgdGFibGUgb25seSBpbmNsdWRlcyB0aGUgcHJpbWFy eSB2aXJ0dWFsIElEcy4gUm91dGluZyBhbHdheXMgaGFwcGVucyBpbiB0d28gc3RlcHMuIEluIHRo ZSBmaXJzdCBzdGVwLCB5b3UgY2FuIGp1c3QgaW1hZ2luZSB0aGF0IHlvdSBkb27igJl0IGhhdmUg dGhlIHNlY29uZGFyeSB2aXJ0dWFsIG5vZGUgSURzIGFuZCBqdXN0IGhhdmUgdGhlIHByaW1hcnkg b25lcy4gVGhlbiwgYXMgaW4gdGhlIGNhc2Ugb2YgQ2hvcmQsIHlvdSB3b3VsZCB1c2UgdGhlIHBy aW1hcnkgSURzIHRvIHJvdXRlIHRoZSByZXF1ZXN0IHRvIHRoZSBwcmltYXJ5IElEIGNsb3Nlc3Qg dG8gdGhlIG9iamVjdC4gQXQgdGhpcyBwb2ludCwgdGhlIG5vZGUgdGhhdCByZWNlaXZlcyB0aGUg cmVxdWVzdCBjaGVja3MgaWYgaXQgb3ducyB0aGF0IHBhcnQgb2YgdGhlIElEIHNwYWNlLiBJZiB5 ZXMsIGl0IHNpbXBseSByZXR1cm5zIHRoZSBvYmplY3QvcmVzcG9uc2UuIElmIG5vLCB0aGVuIGl0 IHVzZXMgdGhlIG5laWdoYm9yIHRhYmxlcyB0byByb3V0ZSB0aGUgcmVxdWVzdHMuIFRoaXMgd291 bGQgdGFrZSBhIG1heGltdW0gb2YgTyhsb2cgTikgYWRkaXRpb25hbCBob3BzLg0KDQoyKUhvdyB0 byBjaGFuZ2UgdGhlIGVzdGltYXRlZCBOIHBhcmFtZXRlciAgYW5kIGtlZXAgdGhlIHNlcnZpY2Vz IG5vbi1zdG9wcGluZz8gU3VwcG9zaW5nIHRoYXQgaXQgaGFzIGJlZW4gZmFyIGF3YXkgZnJvbSB0 aGUgYWN0dWFsIG5ldHdvcmsgc2NhbGUuIA0KDQogIEkgZG9u4oCZdCB0aGluayB0aGVyZSB3aWxs IGJlIGEgc2l0dWF0aW9uIHdoZXJlIGl0IGlzIGZhciBhd2F5IGZyb20gdGhlIGFjdHVhbCBuZXR3 b3JrIHNjYWxlIHNpbmNlIHRoZSBmaW5nZXJzIGtlZXAgdXBkYXRpbmcgYXMgYW5kIHdoZW4gdGhl IG5ldHdvcmsgZ3Jvd3MuIEluIHNvbWUgd2F5cywgdGhlIHVwZGF0ZSBhbGdvcml0aG0gd2lsbCBl bnN1cmUgdGhhdCB0aGlzIHNpdHVhdGlvbiB3b3VsZCBub3QgYXJpc2UuIEluIHRoZSB3b3JzdCBj YXNlLCBpZiB0aGUgc2l0dWF0aW9uIGhhcHBlbnMgdG8gYXJpc2UsIHRoZW4gdGhhdCB3b3VsZCBp bXBseSB0aGF0IHRoaXMgcGFydGljdWxhciBub2RlIGlzIGhpZ2hseSBpbWJhbGFuY2VkIGFuZCBp cyBoYW5kbGluZyBhIHZlcnkgbGFyZ2UgYW1vdW50IG9mIGxvYWQuIFRoZXJlZm9yZSwgaXQgd291 bGQgYmUgb2YgYmVuZWZpdCBmb3IgdGhlIG5vZGUgdG8gb2ZmbG9hZCBzb21lIG9mIGl0cyBsb2Fk LiBUaGUgY2hhbmdlIGNhbiBiZSBkb25lIGJ5IGxlYXZpbmcgam9pbmluZyB0aGUgbmV0d29yayB3 aXRoIGEgbmV3IHNldCBvZiB2aXJ0dWFsIGlkcyBhbmQgbGVhdmluZyB0aGUgbmV0d29yayB3aXRo IHRoZSBvbGQgb25lcy4gVGhpcyBjYW4gYmUgZG9uZSBzbG93bHkgd2l0aG91dCBhZmZmZWN0aW5n IHNlcnZpY2VzIChub3QgbGVhdmUgYW5kIGpvaW4gYXQgdGhlIHNhbWUgdGltZSB3aXRoIGFsbCB0 aGUgdmlydHVhbCBub2RlIGlkcykuDQoNCjMpQ291bGQgdGhlIGltYmFsYW5jZSBmYWN0b3IgYmUg cmVkdWNlZCBmdXJ0aGVyPyANCg0KWWVzLiBUaGUgc2ltcGxlc3Qgd2F5IGlzIGJ5IGluY3JlYXNp bmcgYWxwaGEgb3IgYnkgaW5jcmVhc2luZyBkZWx0YS4gSG93ZXZlciwgaWYgeW91IGluY3JlYXNl IGFscGhhIG9yIGRlbHRhIHRvbyBtdWNoIHRoZW4gcm91dGluZyB3b3VsZCBiZWNvbWUgbGVzcyBl ZmZpY2llbnQgcmVxdWlyaW5nIG1vcmUgdGhhbiBPKGxvZyBOKSBob3BzLiBBIG1vcmUgY29tcGxp Y2F0ZWQgd2F5IHRvIHJlZHVjZSB0aGUgaW1iYWxhbmNlIGZhY3RvciBpcyBieSBlbXBsb3lpbmcg YSBoaWVyYXJjaGljYWwgYXBwcm9hY2ggYW5kIGJ1aWxkaW5nIFkwIG92ZXIgYW5vdGhlciBZMC4N Cg0KVGhhbmtzDQpTYXVtaXRyYQ0KDQpGcm9tOiB3YW5nLmp1bjE3QHp0ZS5jb20uY24gW21haWx0 bzp3YW5nLmp1bjE3QHp0ZS5jb20uY25dIA0KU2VudDogVHVlc2RheSwgTWFyY2ggMDMsIDIwMDkg MTA6NTkgUE0NClRvOiBEYXMsIFNhdW1pdHJhDQpDYzogcDJwc2lwQGlldGYub3JnOyBwMnBzaXAt Ym91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDog562U5aSNOiBbUDJQU0lQXSBOZXcgTG9hZCBiYWxh bmNpbmcgaW4gUkVMT0FEIGRyYWZ0DQoNCg0KSSBoYXZlIHJlYWQgeW91ciBhcnRpY2xlLCBhbmQg YWdyZWUgdGhhdCBsb2FkIGJhbGFuY2luZyBpcyBhIGtleSBpc3N1ZSBlc3BlY2lhbGx5IHdoZW4g d2UgZGVwbG95IHRoZSBiYWNrZW5kIHNlcnZlciBzeXN0ZW1zIGJ1aWx0IGJ5IHAycCB0ZWNobm9s b2d5LiANClNvbWUgcXVlc3Rpb25zIGZvbGxvd2luZzogDQoxKURvZXMgdGhlIGZpbmdlciB0YWJs ZSBvbmx5IGluY2x1ZGUgdGhlIHByaW1hcnkgdmlydHVhbCBub2RlIElEPyANCjIpSG93IHRvIGNo YW5nZSB0aGUgZXN0aW1hdGVkIE4gcGFyYW1ldGVyIMKgYW5kIGtlZXAgdGhlIHNlcnZpY2VzIG5v bi1zdG9wcGluZz8gU3VwcG9zaW5nIHRoYXQgaXQgaGFzIGJlZW4gZmFyIGF3YXkgZnJvbSB0aGUg YWN0dWFsIG5ldHdvcmsgc2NhbGUuIA0KMylDb3VsZCB0aGUgaW1iYWxhbmNlIGZhY3RvciBiZSBy ZWR1Y2VkIGZ1cnRoZXI/IA0KDQoNClJ1c3NlbGwgV2FuZw0KDQoNCg0KcDJwc2lwLWJvdW5jZXNA aWV0Zi5vcmcg5YaZ5LqOIDIwMDktMDMtMDQgMDk6MTA6NTE6DQoNCj4gSGkgYWxsLA0KPiANCj4g SSBqdXN0IHN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQgcHJvcG9zZXMgYSBsb2FkIGJhbGFuY2luZyBz b2x1dGlvbiBmb3INCj4gdGhlIGRlZmF1bHQgREhUIGluIFJFTE9BRC4gQ29tbWVudHMgYXJlIGFw cHJlY2lhdGVkLg0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtc2F1bWl0cmEtcDJwc2lwLWxvYWRiYWxhbmNlLTAwLnR4dCANCj4gDQo+IEJlc3QsDQo+IFNh dW1pdHJhDQo+IA0KPiANCj4gDQo+IA0KPiB3d3cuc2F1bWl0cmEuaW5mbyANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUDJQU0lQIG1haWxpbmcg bGlzdA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wMnBzaXANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURcKgSW5mb3JtYXRpb27CoFNlY3VyaXR5wqBOb3RpY2U6wqBU aGXCoGluZm9ybWF0aW9uwqBjb250YWluZWTCoGluwqB0aGlzwqBtYWlswqBpc8Kgc29sZWx5wqBw cm9wZXJ0ecKgb2bCoHRoZcKgc2VuZGVyJ3PCoG9yZ2FuaXphdGlvbi7CoFRoaXPCoG1haWzCoGNv bW11bmljYXRpb27CoGlzwqBjb25maWRlbnRpYWwuwqBSZWNpcGllbnRzwqBuYW1lZMKgYWJvdmXC oGFyZcKgb2JsaWdhdGVkwqB0b8KgbWFpbnRhaW7CoHNlY3JlY3nCoGFuZMKgYXJlwqBub3TCoHBl cm1pdHRlZMKgdG/CoGRpc2Nsb3NlwqB0aGXCoGNvbnRlbnRzwqBvZsKgdGhpc8KgY29tbXVuaWNh dGlvbsKgdG/CoG90aGVycy4NClRoaXPCoGVtYWlswqBhbmTCoGFuecKgZmlsZXPCoHRyYW5zbWl0 dGVkwqB3aXRowqBpdMKgYXJlwqBjb25maWRlbnRpYWzCoGFuZMKgaW50ZW5kZWTCoHNvbGVsecKg Zm9ywqB0aGXCoHVzZcKgb2bCoHRoZcKgaW5kaXZpZHVhbMKgb3LCoGVudGl0ecKgdG/CoHdob23C oHRoZXnCoGFyZcKgYWRkcmVzc2VkLsKgSWbCoHlvdcKgaGF2ZcKgcmVjZWl2ZWTCoHRoaXPCoGVt YWlswqBpbsKgZXJyb3LCoHBsZWFzZcKgbm90aWZ5wqB0aGXCoG9yaWdpbmF0b3LCoG9mwqB0aGXC oG1lc3NhZ2UuwqBBbnnCoHZpZXdzwqBleHByZXNzZWTCoGluwqB0aGlzwqBtZXNzYWdlwqBhcmXC oHRob3NlwqBvZsKgdGhlwqBpbmRpdmlkdWFswqBzZW5kZXIuDQpUaGlzwqBtZXNzYWdlwqBoYXPC oGJlZW7CoHNjYW5uZWTCoGZvcsKgdmlydXNlc8KgYW5kwqBTcGFtwqBiecKgWlRFwqBBbnRpLVNw YW3CoHN5c3RlbS4NCg== From saumitra@qualcomm.com Fri Mar 6 12:59:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8170C3A68A6 for ; Fri, 6 Mar 2009 12:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmuJ5rwppgDN for ; Fri, 6 Mar 2009 12:59:50 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8A7C13A6869 for ; Fri, 6 Mar 2009 12:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1236373221; x=1267909221; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"Das,=20Saumitra"=20,=0D=0A=20 =20=20=20=20=20=20=20"wang.jun17@zte.com.cn"=0D=0A=09|CC:=20"p2psip@ietf.org"=20|Date:=20Fri,=206=20Mar=202009=2013:00:18=20-0800 |Subject:=20RE:=20[P2PSIP]=20New=20Load=20balancing=20in =20RELOAD=20draft|Thread-Topic:=20[P2PSIP]=20New=20Load =20balancing=20in=20RELOAD=20draft|Thread-Index:=20Acmclt ggXiMjnBL0Q0SsObRu/5ygaQCBlSQwAABMXpA=3D|Message-ID:=20<2 D06DE445C2ADE44890118C3F449B9634009A1BA@NASANEXMB12.na.qu alcomm.com>|References:=20<2D06DE445C2ADE44890118C3F449B9 6340099F6D@NASANEXMB12.na.qualcomm.com>=0D=0A=09=0D=0A=20<2D06DE445C2ADE44890118C3F449B9634009A1B9@NA SANEXMB12.na.qualcomm.com>|In-Reply-To:=20<2D06DE445C2ADE 44890118C3F449B9634009A1B9@NASANEXMB12.na.qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5545"=3B=20 a=3D"16039884"; bh=QbbdtFFhWf1NYqm/sUSs/3v6vt0trRZB3Btrb1SmGIc=; b=IMeoVAAkFIYrG3oXNnzJBXBSyHywy78DdyrNaJjFO5Pd0wpUeNCNkeVr 4+rK3/qfp7Ye4hzEr7USUbETfSPRjKFpeQR0H2sFGgXx/y79aNvNtNbXs d+vgHLE70sVTorkFI9zPKBZMQVW9pWLYrevTyYdxWCsXJgcQOz4dBMygU E=; X-IronPort-AV: E=McAfee;i="5300,2777,5545"; a="16039884" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2009 13:00:21 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26L0Lgr025965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2009 13:00:21 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26L0Kex021910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Mar 2009 13:00:20 -0800 (PST) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Fri, 6 Mar 2009 13:00:20 -0800 From: "Das, Saumitra" To: "Das, Saumitra" , "wang.jun17@zte.com.cn" Date: Fri, 6 Mar 2009 13:00:18 -0800 Thread-Topic: [P2PSIP] New Load balancing in RELOAD draft Thread-Index: AcmcltggXiMjnBL0Q0SsObRu/5ygaQCBlSQwAABMXpA= Message-ID: <2D06DE445C2ADE44890118C3F449B9634009A1BA@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com> <2D06DE445C2ADE44890118C3F449B9634009A1B9@NASANEXMB12.na.qualcomm.com> In-Reply-To: <2D06DE445C2ADE44890118C3F449B9634009A1B9@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] New Load balancing in RELOAD draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 06 Mar 2009 20:59:51 -0000 SnVzdCBhIGNsYXJpZmljYXRpb24NCg0KMylDb3VsZCB0aGUgaW1iYWxhbmNlIGZhY3RvciBiZSBy ZWR1Y2VkIGZ1cnRoZXI/IA0KDQpZZXMuIFRoZSBzaW1wbGVzdCB3YXkgaXMgYnkgaW5jcmVhc2lu ZyBhbHBoYSBvciBieSBpbmNyZWFzaW5nIGRlbHRhLiBIb3dldmVyLCBpZiB5b3UgaW5jcmVhc2Ug YWxwaGEgb3IgZGVsdGEgdG9vIG11Y2ggdGhlbiByb3V0aW5nIHdvdWxkIGJlY29tZSBsZXNzIGVm ZmljaWVudCByZXF1aXJpbmcgbW9yZSB0aGFuIE8obG9nIE4pIGhvcHMuIEEgbW9yZSBjb21wbGlj YXRlZCB3YXkgdG8gcmVkdWNlIHRoZSBpbWJhbGFuY2UgZmFjdG9yIGlzIGJ5IGVtcGxveWluZyBh IGhpZXJhcmNoaWNhbCBhcHByb2FjaCBieSBjbHVzdGVyaW5nIG5vZGVzIGludG8gZ3JvdXBzIChk b2luZyB0aGUgc2NoZW1lIGluIHRoYXQgZ3JvdXApIGFuZCB0aGVuIGRvIHRoZSBzYW1lIHNjaGVt ZSBvbiB0aGUgc3VwZXJncm91cHMgYXMgYSB3aG9sZS4gVGhpcyBjYW4gZ2V0IGNvbXBsaWNhdGVk IGFuZCB3ZSBzdGF5ZWQgYXdheSBmcm9tIGl0IHRvIGtlZXAgdGhlIHByb3Bvc2FsIHNpbXBsZS4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHAycHNpcC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXMsIFNh dW1pdHJhDQpTZW50OiBGcmlkYXksIE1hcmNoIDA2LCAyMDA5IDEyOjU4IFBNDQpUbzogd2FuZy5q dW4xN0B6dGUuY29tLmNuDQpDYzogcDJwc2lwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1AyUFNJ UF0gTmV3IExvYWQgYmFsYW5jaW5nIGluIFJFTE9BRCBkcmFmdA0KDQpIaSBSdXNzZWxsLA0KDQog IFRoYW5rcyBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgZHJhZnQuDQoNCiAgMSlEb2VzIHRoZSBmaW5n ZXIgdGFibGUgb25seSBpbmNsdWRlIHRoZSBwcmltYXJ5IHZpcnR1YWwgbm9kZSBJRD8gDQoNCiAg VGhlIGZpbmdlciB0YWJsZSBvbmx5IGluY2x1ZGVzIHRoZSBwcmltYXJ5IHZpcnR1YWwgSURzLiBS b3V0aW5nIGFsd2F5cyBoYXBwZW5zIGluIHR3byBzdGVwcy4gSW4gdGhlIGZpcnN0IHN0ZXAsIHlv dSBjYW4ganVzdCBpbWFnaW5lIHRoYXQgeW91IGRvbuKAmXQgaGF2ZSB0aGUgc2Vjb25kYXJ5IHZp cnR1YWwgbm9kZSBJRHMgYW5kIGp1c3QgaGF2ZSB0aGUgcHJpbWFyeSBvbmVzLiBUaGVuLCBhcyBp biB0aGUgY2FzZSBvZiBDaG9yZCwgeW91IHdvdWxkIHVzZSB0aGUgcHJpbWFyeSBJRHMgdG8gcm91 dGUgdGhlIHJlcXVlc3QgdG8gdGhlIHByaW1hcnkgSUQgY2xvc2VzdCB0byB0aGUgb2JqZWN0LiBB dCB0aGlzIHBvaW50LCB0aGUgbm9kZSB0aGF0IHJlY2VpdmVzIHRoZSByZXF1ZXN0IGNoZWNrcyBp ZiBpdCBvd25zIHRoYXQgcGFydCBvZiB0aGUgSUQgc3BhY2UuIElmIHllcywgaXQgc2ltcGx5IHJl dHVybnMgdGhlIG9iamVjdC9yZXNwb25zZS4gSWYgbm8sIHRoZW4gaXQgdXNlcyB0aGUgbmVpZ2hi b3IgdGFibGVzIHRvIHJvdXRlIHRoZSByZXF1ZXN0cy4gVGhpcyB3b3VsZCB0YWtlIGEgbWF4aW11 bSBvZiBPKGxvZyBOKSBhZGRpdGlvbmFsIGhvcHMuDQoNCjIpSG93IHRvIGNoYW5nZSB0aGUgZXN0 aW1hdGVkIE4gcGFyYW1ldGVyICBhbmQga2VlcCB0aGUgc2VydmljZXMgbm9uLXN0b3BwaW5nPyBT dXBwb3NpbmcgdGhhdCBpdCBoYXMgYmVlbiBmYXIgYXdheSBmcm9tIHRoZSBhY3R1YWwgbmV0d29y ayBzY2FsZS4gDQoNCiAgSSBkb27igJl0IHRoaW5rIHRoZXJlIHdpbGwgYmUgYSBzaXR1YXRpb24g d2hlcmUgaXQgaXMgZmFyIGF3YXkgZnJvbSB0aGUgYWN0dWFsIG5ldHdvcmsgc2NhbGUgc2luY2Ug dGhlIGZpbmdlcnMga2VlcCB1cGRhdGluZyBhcyBhbmQgd2hlbiB0aGUgbmV0d29yayBncm93cy4g SW4gc29tZSB3YXlzLCB0aGUgdXBkYXRlIGFsZ29yaXRobSB3aWxsIGVuc3VyZSB0aGF0IHRoaXMg c2l0dWF0aW9uIHdvdWxkIG5vdCBhcmlzZS4gSW4gdGhlIHdvcnN0IGNhc2UsIGlmIHRoZSBzaXR1 YXRpb24gaGFwcGVucyB0byBhcmlzZSwgdGhlbiB0aGF0IHdvdWxkIGltcGx5IHRoYXQgdGhpcyBw YXJ0aWN1bGFyIG5vZGUgaXMgaGlnaGx5IGltYmFsYW5jZWQgYW5kIGlzIGhhbmRsaW5nIGEgdmVy eSBsYXJnZSBhbW91bnQgb2YgbG9hZC4gVGhlcmVmb3JlLCBpdCB3b3VsZCBiZSBvZiBiZW5lZml0 IGZvciB0aGUgbm9kZSB0byBvZmZsb2FkIHNvbWUgb2YgaXRzIGxvYWQuIFRoZSBjaGFuZ2UgY2Fu IGJlIGRvbmUgYnkgbGVhdmluZyBqb2luaW5nIHRoZSBuZXR3b3JrIHdpdGggYSBuZXcgc2V0IG9m IHZpcnR1YWwgaWRzIGFuZCBsZWF2aW5nIHRoZSBuZXR3b3JrIHdpdGggdGhlIG9sZCBvbmVzLiBU aGlzIGNhbiBiZSBkb25lIHNsb3dseSB3aXRob3V0IGFmZmZlY3Rpbmcgc2VydmljZXMgKG5vdCBs ZWF2ZSBhbmQgam9pbiBhdCB0aGUgc2FtZSB0aW1lIHdpdGggYWxsIHRoZSB2aXJ0dWFsIG5vZGUg aWRzKS4NCg0KMylDb3VsZCB0aGUgaW1iYWxhbmNlIGZhY3RvciBiZSByZWR1Y2VkIGZ1cnRoZXI/ IA0KDQpZZXMuIFRoZSBzaW1wbGVzdCB3YXkgaXMgYnkgaW5jcmVhc2luZyBhbHBoYSBvciBieSBp bmNyZWFzaW5nIGRlbHRhLiBIb3dldmVyLCBpZiB5b3UgaW5jcmVhc2UgYWxwaGEgb3IgZGVsdGEg dG9vIG11Y2ggdGhlbiByb3V0aW5nIHdvdWxkIGJlY29tZSBsZXNzIGVmZmljaWVudCByZXF1aXJp bmcgbW9yZSB0aGFuIE8obG9nIE4pIGhvcHMuIEEgbW9yZSBjb21wbGljYXRlZCB3YXkgdG8gcmVk dWNlIHRoZSBpbWJhbGFuY2UgZmFjdG9yIGlzIGJ5IGVtcGxveWluZyBhIGhpZXJhcmNoaWNhbCBh cHByb2FjaCBhbmQgYnVpbGRpbmcgWTAgb3ZlciBhbm90aGVyIFkwLg0KDQpUaGFua3MNClNhdW1p dHJhDQoNCkZyb206IHdhbmcuanVuMTdAenRlLmNvbS5jbiBbbWFpbHRvOndhbmcuanVuMTdAenRl LmNvbS5jbl0gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwMywgMjAwOSAxMDo1OSBQTQ0KVG86IERh cywgU2F1bWl0cmENCkNjOiBwMnBzaXBAaWV0Zi5vcmc7IHAycHNpcC1ib3VuY2VzQGlldGYub3Jn DQpTdWJqZWN0OiDnrZTlpI06IFtQMlBTSVBdIE5ldyBMb2FkIGJhbGFuY2luZyBpbiBSRUxPQUQg ZHJhZnQNCg0KDQpJIGhhdmUgcmVhZCB5b3VyIGFydGljbGUsIGFuZCBhZ3JlZSB0aGF0IGxvYWQg YmFsYW5jaW5nIGlzIGEga2V5IGlzc3VlIGVzcGVjaWFsbHkgd2hlbiB3ZSBkZXBsb3kgdGhlIGJh Y2tlbmQgc2VydmVyIHN5c3RlbXMgYnVpbHQgYnkgcDJwIHRlY2hub2xvZ3kuIA0KU29tZSBxdWVz dGlvbnMgZm9sbG93aW5nOiANCjEpRG9lcyB0aGUgZmluZ2VyIHRhYmxlIG9ubHkgaW5jbHVkZSB0 aGUgcHJpbWFyeSB2aXJ0dWFsIG5vZGUgSUQ/IA0KMilIb3cgdG8gY2hhbmdlIHRoZSBlc3RpbWF0 ZWQgTiBwYXJhbWV0ZXIgwqBhbmQga2VlcCB0aGUgc2VydmljZXMgbm9uLXN0b3BwaW5nPyBTdXBw b3NpbmcgdGhhdCBpdCBoYXMgYmVlbiBmYXIgYXdheSBmcm9tIHRoZSBhY3R1YWwgbmV0d29yayBz Y2FsZS4gDQozKUNvdWxkIHRoZSBpbWJhbGFuY2UgZmFjdG9yIGJlIHJlZHVjZWQgZnVydGhlcj8g DQoNCg0KUnVzc2VsbCBXYW5nDQoNCg0KDQpwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4g MjAwOS0wMy0wNCAwOToxMDo1MToNCg0KPiBIaSBhbGwsDQo+IA0KPiBJIGp1c3Qgc3VibWl0dGVk IGEgZHJhZnQgdGhhdCBwcm9wb3NlcyBhIGxvYWQgYmFsYW5jaW5nIHNvbHV0aW9uIGZvcg0KPiB0 aGUgZGVmYXVsdCBESFQgaW4gUkVMT0FELiBDb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQo+IA0K PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zYXVtaXRyYS1wMnBz aXAtbG9hZGJhbGFuY2UtMDAudHh0IA0KPiANCj4gQmVzdCwNCj4gU2F1bWl0cmENCj4gDQo+IA0K PiANCj4gDQo+IHd3dy5zYXVtaXRyYS5pbmZvIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+IFAyUFNJUEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFwqBJbmZvcm1hdGlvbsKgU2VjdXJpdHnCoE5vdGljZTrCoFRoZcKgaW5mb3JtYXRpb27C oGNvbnRhaW5lZMKgaW7CoHRoaXPCoG1haWzCoGlzwqBzb2xlbHnCoHByb3BlcnR5wqBvZsKgdGhl wqBzZW5kZXInc8Kgb3JnYW5pemF0aW9uLsKgVGhpc8KgbWFpbMKgY29tbXVuaWNhdGlvbsKgaXPC oGNvbmZpZGVudGlhbC7CoFJlY2lwaWVudHPCoG5hbWVkwqBhYm92ZcKgYXJlwqBvYmxpZ2F0ZWTC oHRvwqBtYWludGFpbsKgc2VjcmVjecKgYW5kwqBhcmXCoG5vdMKgcGVybWl0dGVkwqB0b8KgZGlz Y2xvc2XCoHRoZcKgY29udGVudHPCoG9mwqB0aGlzwqBjb21tdW5pY2F0aW9uwqB0b8Kgb3RoZXJz Lg0KVGhpc8KgZW1haWzCoGFuZMKgYW55wqBmaWxlc8KgdHJhbnNtaXR0ZWTCoHdpdGjCoGl0wqBh cmXCoGNvbmZpZGVudGlhbMKgYW5kwqBpbnRlbmRlZMKgc29sZWx5wqBmb3LCoHRoZcKgdXNlwqBv ZsKgdGhlwqBpbmRpdmlkdWFswqBvcsKgZW50aXR5wqB0b8Kgd2hvbcKgdGhlecKgYXJlwqBhZGRy ZXNzZWQuwqBJZsKgeW91wqBoYXZlwqByZWNlaXZlZMKgdGhpc8KgZW1haWzCoGluwqBlcnJvcsKg cGxlYXNlwqBub3RpZnnCoHRoZcKgb3JpZ2luYXRvcsKgb2bCoHRoZcKgbWVzc2FnZS7CoEFuecKg dmlld3PCoGV4cHJlc3NlZMKgaW7CoHRoaXPCoG1lc3NhZ2XCoGFyZcKgdGhvc2XCoG9mwqB0aGXC oGluZGl2aWR1YWzCoHNlbmRlci4NClRoaXPCoG1lc3NhZ2XCoGhhc8KgYmVlbsKgc2Nhbm5lZMKg Zm9ywqB2aXJ1c2VzwqBhbmTCoFNwYW3CoGJ5wqBaVEXCoEFudGktU3BhbcKgc3lzdGVtLg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClAyUFNJUCBtYWls aW5nIGxpc3QNClAyUFNJUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wMnBzaXANCg== From vidyan@qualcomm.com Sat Mar 7 23:54:00 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135F23A6BE7 for ; Sat, 7 Mar 2009 23:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYXBw8MFvCGM for ; Sat, 7 Mar 2009 23:53:58 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E36403A69FE for ; Sat, 7 Mar 2009 23:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1236498870; x=1268034870; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-cr-puzzleid: x-cr-hashedpuzzle:acceptlanguage:content-type: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"p2psip@ietf.org"=20|Date:=20Sat,=207 =20Mar=202009=2023:54:09=20-0800|Subject:=20Threat=20Anal ysis=20I-D|Thread-Topic:=20Threat=20Analysis=20I-D |Thread-Index:=20AcmfwxA7NkUaRWYxSYuseorCHycLRQ=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-cr-puzzleid:=20{8EE14C45-0857-41 A3-B7AB-7B6B6E983A41}|x-cr-hashedpuzzle:=20ALAQ=20AVcE=20 AhtM=20A8m3=20FTrD=20F2r8=20GB4z=20GDzv=20GRcm=20GSKs=20G mKP=0D=0A=20HEvi=20HGy6=20Iziz=20I+/o=0D=0A=20JCYO=3B1=3B cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA=3BSosha1_v1=3B7 =3B{8EE14C45-0857-41A3-B7AB-7B6B6E983A41}=3BdgBpAGQAeQBhA G4AQABxAHUAYQBsAGMAbwBtAG0ALgBjAG8AbQA=3D=3BSun,=0D=0A=20 08=20Mar=202009=2007:54:09=20GMT=3BVABoAHIAZQBhAHQAIABBAG 4AYQBsAHkAcwBpAHMAIABJAC0ARAA=3D|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_BE82361A0E26874DBC2ED1BA244866B93028C82FNALASEX MB08naqu_"|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfe e=3Bi=3D"5300,2777,5546"=3B=20a=3D"16079594"; bh=8tMEYPDpGsKOK8qHAy9US1tIu+2ogaGu1tY8dUagkoA=; b=FwgPV3YK08WhQkMp7+OjHsLgHcHWC+ff1Ngeh5XHG72DBcaCv/WSG+lA 99fQ05s4cN9YgLiPDsjmliwlx3DeVK14PJLcC1So6nQMJi/b0uRS0lwU/ 41ppTAapBMjvLUKv6GXc3xxUG9slagx71mudfC/O7/ebodXUluqCth+a8 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5546"; a="16079594" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2009 23:54:14 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n287sEe6005161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 7 Mar 2009 23:54:14 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n287sDoi021102 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 7 Mar 2009 23:54:13 -0800 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.336.0; Sat, 7 Mar 2009 23:54:13 -0800 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Sat, 7 Mar 2009 23:54:12 -0800 From: "Narayanan, Vidya" To: "p2psip@ietf.org" Date: Sat, 7 Mar 2009 23:54:09 -0800 Thread-Topic: Threat Analysis I-D Thread-Index: AcmfwxA7NkUaRWYxSYuseorCHycLRQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {8EE14C45-0857-41A3-B7AB-7B6B6E983A41} x-cr-hashedpuzzle: ALAQ AVcE AhtM A8m3 FTrD F2r8 GB4z GDzv GRcm GSKs GmKP HEvi HGy6 Iziz I+/o JCYO; 1; cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8EE14C45-0857-41A3-B7AB-7B6B6E983A41}; dgBpAGQAeQBhAG4AQABxAHUAYQBsAGMAbwBtAG0ALgBjAG8AbQA=; Sun, 08 Mar 2009 07:54:09 GMT; VABoAHIAZQBhAHQAIABBAG4AYQBsAHkAcwBpAHMAIABJAC0ARAA= acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BE82361A0E26874DBC2ED1BA244866B93028C82FNALASEXMB08naqu_" MIME-Version: 1.0 Subject: [P2PSIP] Threat Analysis I-D X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 08 Mar 2009 07:54:00 -0000 --_000_BE82361A0E26874DBC2ED1BA244866B93028C82FNALASEXMB08naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a p2p threat analysis draft - http://tools.ietf.org/html/dr= aft-mao-p2psip-threat-analysis-00. Comments are welcome. Thanks, Vidya --_000_BE82361A0E26874DBC2ED1BA244866B93028C82FNALASEXMB08naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We’ve submitted a p2p threat analysis draft - htt= p://tools.ietf.org/html/draft-mao-p2psip-threat-analysis-00.  Comments are welcome.

 

Thanks,
Vidya

--_000_BE82361A0E26874DBC2ED1BA244866B93028C82FNALASEXMB08naqu_-- From wang.jun17@zte.com.cn Sun Mar 8 20:58:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17763A6866 for ; Sun, 8 Mar 2009 20:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.326 X-Spam-Level: X-Spam-Status: No, score=-92.326 tagged_above=-999 required=5 tests=[AWL=1.671, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LgEwDsvBlPU for ; Sun, 8 Mar 2009 20:57:58 -0700 (PDT) Received: from mail.zte.com.cn (mx1.zte.no [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id B70833A6819 for ; Sun, 8 Mar 2009 20:57:52 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.2308507414; Mon, 9 Mar 2009 12:20:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n293w54c022142; Mon, 9 Mar 2009 11:58:05 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <2D06DE445C2ADE44890118C3F449B9634009A1BA@NASANEXMB12.na.qualcomm.com> To: "Das, Saumitra" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Mon, 9 Mar 2009 11:57:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-09 11:58:00, Serialize complete at 2009-03-09 11:58:00 Content-Type: multipart/alternative; boundary="=_alternative 0015C76E48257574_=" X-MAIL: mse1.zte.com.cn n293w54c022142 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] New Load balancing in RELOAD draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2009 03:58:06 -0000 This is a multipart message in MIME format. --=_alternative 0015C76E48257574_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgc2F1bWl0cmENCnRoYW5rcyBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLiBJIHJlYWQgdGhlIGFy dGljbGUgYWdhaW4sIGFuZCBzdGlsbCB3YXMgDQp3b25kZXJpbmcgdGhhdDoNCg0KMSlBYm91dCBk YXRhIGluc2VydGlvbiBwcm9jZWR1cmUuIEEgbmV3IGRhdGEgc3RvcmluZyByZXF1ZXN0IHNob3Vs ZCBmaXJzdCANCmFycml2ZSBhdCB0aGUgcGh5c2ljYWwgbm9kZSB3aGljaCBwcmltYXJ5IElEIGlz IHRoZSBpbW1lZGlhdGUgc3VjY2Vzc29yIG9mIA0KdGhlIG9iamVjdCBJRCwgdGhlbiBiZSBkaXNw YXRjaGVkIHRvIHRoZSBuZWFyZWFzdCBzZWNvbmRhcnkgbm9kZSBpbiB0aGUgDQpwaHlzaWNhbCBu b2RlPyBDYW4gc2Vjb25kYXJ5IElEIG1pZ3JhdGUgZHluYW1pY2FsbHkgYW1vbmcgcGVlcnM/DQoy KUFib3V0IHBlcmZvcm1hbmNlLiBJbiBzb21lIG1hbmFnZWQgcDJwIHN5c3RlbXMsIHBlcmZvcm1h bmNlIGlzIGNyaXRpY2FsLCANCnNvIE8oMSkgREhUIGlzIHRoZSBwcmVmZXJhYmxlIGFsZ3JpdGht LiBGb3IgTygxKSBESFQsIGV4dHJhICBPKExvZ04pIGhvcHMgDQppbnRyb2R1Y2VkIGJ5IGxvYWQg YmFsYW5jaW5nIG1heSBiZSB0b28gbGFyZ2UuDQoNCg0KDQoNCg0KDQoiRGFzLCBTYXVtaXRyYSIg PHNhdW1pdHJhQHF1YWxjb21tLmNvbT4gDQoyMDA5LTAzLTA3IDA1OjAwDQoNCsrVvP7Iyw0KIkRh cywgU2F1bWl0cmEiIDxzYXVtaXRyYUBxdWFsY29tbS5jb20+LCAid2FuZy5qdW4xN0B6dGUuY29t LmNuIiANCjx3YW5nLmp1bjE3QHp0ZS5jb20uY24+DQqzrcvNDQoicDJwc2lwQGlldGYub3JnIiA8 cDJwc2lwQGlldGYub3JnPg0K1vfM4g0KUkU6IFtQMlBTSVBdIE5ldyBMb2FkIGJhbGFuY2luZyBp biBSRUxPQUQgZHJhZnQNCg0KDQoNCg0KDQoNCkp1c3QgYSBjbGFyaWZpY2F0aW9uDQoNCjMpQ291 bGQgdGhlIGltYmFsYW5jZSBmYWN0b3IgYmUgcmVkdWNlZCBmdXJ0aGVyPyANCg0KWWVzLiBUaGUg c2ltcGxlc3Qgd2F5IGlzIGJ5IGluY3JlYXNpbmcgYWxwaGEgb3IgYnkgaW5jcmVhc2luZyBkZWx0 YS4gDQpIb3dldmVyLCBpZiB5b3UgaW5jcmVhc2UgYWxwaGEgb3IgZGVsdGEgdG9vIG11Y2ggdGhl biByb3V0aW5nIHdvdWxkIGJlY29tZSANCmxlc3MgZWZmaWNpZW50IHJlcXVpcmluZyBtb3JlIHRo YW4gTyhsb2cgTikgaG9wcy4gQSBtb3JlIGNvbXBsaWNhdGVkIHdheSANCnRvIHJlZHVjZSB0aGUg aW1iYWxhbmNlIGZhY3RvciBpcyBieSBlbXBsb3lpbmcgYSBoaWVyYXJjaGljYWwgYXBwcm9hY2gg YnkgDQpjbHVzdGVyaW5nIG5vZGVzIGludG8gZ3JvdXBzIChkb2luZyB0aGUgc2NoZW1lIGluIHRo YXQgZ3JvdXApIGFuZCB0aGVuIGRvIA0KdGhlIHNhbWUgc2NoZW1lIG9uIHRoZSBzdXBlcmdyb3Vw cyBhcyBhIHdob2xlLiBUaGlzIGNhbiBnZXQgY29tcGxpY2F0ZWQgDQphbmQgd2Ugc3RheWVkIGF3 YXkgZnJvbSBpdCB0byBrZWVwIHRoZSBwcm9wb3NhbCBzaW1wbGUuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnAycHNp cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQpPZiBEYXMsIFNhdW1pdHJhDQpTZW50OiBG cmlkYXksIE1hcmNoIDA2LCAyMDA5IDEyOjU4IFBNDQpUbzogd2FuZy5qdW4xN0B6dGUuY29tLmNu DQpDYzogcDJwc2lwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1AyUFNJUF0gTmV3IExvYWQgYmFs YW5jaW5nIGluIFJFTE9BRCBkcmFmdA0KDQpIaSBSdXNzZWxsLA0KDQogIFRoYW5rcyBmb3IgZ29p bmcgdGhyb3VnaCB0aGUgZHJhZnQuDQoNCiAgMSlEb2VzIHRoZSBmaW5nZXIgdGFibGUgb25seSBp bmNsdWRlIHRoZSBwcmltYXJ5IHZpcnR1YWwgbm9kZSBJRD8gDQoNCiAgVGhlIGZpbmdlciB0YWJs ZSBvbmx5IGluY2x1ZGVzIHRoZSBwcmltYXJ5IHZpcnR1YWwgSURzLiBSb3V0aW5nIGFsd2F5cyAN CmhhcHBlbnMgaW4gdHdvIHN0ZXBzLiBJbiB0aGUgZmlyc3Qgc3RlcCwgeW91IGNhbiBqdXN0IGlt YWdpbmUgdGhhdCB5b3UgZG9uDQqhr3QgaGF2ZSB0aGUgc2Vjb25kYXJ5IHZpcnR1YWwgbm9kZSBJ RHMgYW5kIGp1c3QgaGF2ZSB0aGUgcHJpbWFyeSBvbmVzLiANClRoZW4sIGFzIGluIHRoZSBjYXNl IG9mIENob3JkLCB5b3Ugd291bGQgdXNlIHRoZSBwcmltYXJ5IElEcyB0byByb3V0ZSB0aGUgDQpy ZXF1ZXN0IHRvIHRoZSBwcmltYXJ5IElEIGNsb3Nlc3QgdG8gdGhlIG9iamVjdC4gQXQgdGhpcyBw b2ludCwgdGhlIG5vZGUgDQp0aGF0IHJlY2VpdmVzIHRoZSByZXF1ZXN0IGNoZWNrcyBpZiBpdCBv d25zIHRoYXQgcGFydCBvZiB0aGUgSUQgc3BhY2UuIElmIA0KeWVzLCBpdCBzaW1wbHkgcmV0dXJu cyB0aGUgb2JqZWN0L3Jlc3BvbnNlLiBJZiBubywgdGhlbiBpdCB1c2VzIHRoZSANCm5laWdoYm9y IHRhYmxlcyB0byByb3V0ZSB0aGUgcmVxdWVzdHMuIFRoaXMgd291bGQgdGFrZSBhIG1heGltdW0g b2YgTyhsb2cgDQpOKSBhZGRpdGlvbmFsIGhvcHMuDQoNCjIpSG93IHRvIGNoYW5nZSB0aGUgZXN0 aW1hdGVkIE4gcGFyYW1ldGVyICBhbmQga2VlcCB0aGUgc2VydmljZXMgDQpub24tc3RvcHBpbmc/ IFN1cHBvc2luZyB0aGF0IGl0IGhhcyBiZWVuIGZhciBhd2F5IGZyb20gdGhlIGFjdHVhbCBuZXR3 b3JrIA0Kc2NhbGUuIA0KDQogIEkgZG9uoa90IHRoaW5rIHRoZXJlIHdpbGwgYmUgYSBzaXR1YXRp b24gd2hlcmUgaXQgaXMgZmFyIGF3YXkgZnJvbSB0aGUgDQphY3R1YWwgbmV0d29yayBzY2FsZSBz aW5jZSB0aGUgZmluZ2VycyBrZWVwIHVwZGF0aW5nIGFzIGFuZCB3aGVuIHRoZSANCm5ldHdvcmsg Z3Jvd3MuIEluIHNvbWUgd2F5cywgdGhlIHVwZGF0ZSBhbGdvcml0aG0gd2lsbCBlbnN1cmUgdGhh dCB0aGlzIA0Kc2l0dWF0aW9uIHdvdWxkIG5vdCBhcmlzZS4gSW4gdGhlIHdvcnN0IGNhc2UsIGlm IHRoZSBzaXR1YXRpb24gaGFwcGVucyB0byANCmFyaXNlLCB0aGVuIHRoYXQgd291bGQgaW1wbHkg dGhhdCB0aGlzIHBhcnRpY3VsYXIgbm9kZSBpcyBoaWdobHkgDQppbWJhbGFuY2VkIGFuZCBpcyBo YW5kbGluZyBhIHZlcnkgbGFyZ2UgYW1vdW50IG9mIGxvYWQuIFRoZXJlZm9yZSwgaXQgDQp3b3Vs ZCBiZSBvZiBiZW5lZml0IGZvciB0aGUgbm9kZSB0byBvZmZsb2FkIHNvbWUgb2YgaXRzIGxvYWQu IFRoZSBjaGFuZ2UgDQpjYW4gYmUgZG9uZSBieSBsZWF2aW5nIGpvaW5pbmcgdGhlIG5ldHdvcmsg d2l0aCBhIG5ldyBzZXQgb2YgdmlydHVhbCBpZHMgDQphbmQgbGVhdmluZyB0aGUgbmV0d29yayB3 aXRoIHRoZSBvbGQgb25lcy4gVGhpcyBjYW4gYmUgZG9uZSBzbG93bHkgd2l0aG91dCANCmFmZmZl Y3Rpbmcgc2VydmljZXMgKG5vdCBsZWF2ZSBhbmQgam9pbiBhdCB0aGUgc2FtZSB0aW1lIHdpdGgg YWxsIHRoZSANCnZpcnR1YWwgbm9kZSBpZHMpLg0KDQozKUNvdWxkIHRoZSBpbWJhbGFuY2UgZmFj dG9yIGJlIHJlZHVjZWQgZnVydGhlcj8gDQoNClllcy4gVGhlIHNpbXBsZXN0IHdheSBpcyBieSBp bmNyZWFzaW5nIGFscGhhIG9yIGJ5IGluY3JlYXNpbmcgZGVsdGEuIA0KSG93ZXZlciwgaWYgeW91 IGluY3JlYXNlIGFscGhhIG9yIGRlbHRhIHRvbyBtdWNoIHRoZW4gcm91dGluZyB3b3VsZCBiZWNv bWUgDQpsZXNzIGVmZmljaWVudCByZXF1aXJpbmcgbW9yZSB0aGFuIE8obG9nIE4pIGhvcHMuIEEg bW9yZSBjb21wbGljYXRlZCB3YXkgDQp0byByZWR1Y2UgdGhlIGltYmFsYW5jZSBmYWN0b3IgaXMg YnkgZW1wbG95aW5nIGEgaGllcmFyY2hpY2FsIGFwcHJvYWNoIGFuZCANCmJ1aWxkaW5nIFkwIG92 ZXIgYW5vdGhlciBZMC4NCg0KVGhhbmtzDQpTYXVtaXRyYQ0KDQpGcm9tOiB3YW5nLmp1bjE3QHp0 ZS5jb20uY24gW21haWx0bzp3YW5nLmp1bjE3QHp0ZS5jb20uY25dIA0KU2VudDogVHVlc2RheSwg TWFyY2ggMDMsIDIwMDkgMTA6NTkgUE0NClRvOiBEYXMsIFNhdW1pdHJhDQpDYzogcDJwc2lwQGll dGYub3JnOyBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogW1AyUFNJUF0g TmV3IExvYWQgYmFsYW5jaW5nIGluIFJFTE9BRCBkcmFmdA0KDQoNCkkgaGF2ZSByZWFkIHlvdXIg YXJ0aWNsZSwgYW5kIGFncmVlIHRoYXQgbG9hZCBiYWxhbmNpbmcgaXMgYSBrZXkgaXNzdWUgDQpl c3BlY2lhbGx5IHdoZW4gd2UgZGVwbG95IHRoZSBiYWNrZW5kIHNlcnZlciBzeXN0ZW1zIGJ1aWx0 IGJ5IHAycCANCnRlY2hub2xvZ3kuIA0KU29tZSBxdWVzdGlvbnMgZm9sbG93aW5nOiANCjEpRG9l cyB0aGUgZmluZ2VyIHRhYmxlIG9ubHkgaW5jbHVkZSB0aGUgcHJpbWFyeSB2aXJ0dWFsIG5vZGUg SUQ/IA0KMilIb3cgdG8gY2hhbmdlIHRoZSBlc3RpbWF0ZWQgTiBwYXJhbWV0ZXIgIGFuZCBrZWVw IHRoZSBzZXJ2aWNlcyANCm5vbi1zdG9wcGluZz8gU3VwcG9zaW5nIHRoYXQgaXQgaGFzIGJlZW4g ZmFyIGF3YXkgZnJvbSB0aGUgYWN0dWFsIG5ldHdvcmsgDQpzY2FsZS4gDQozKUNvdWxkIHRoZSBp bWJhbGFuY2UgZmFjdG9yIGJlIHJlZHVjZWQgZnVydGhlcj8gDQoNCg0KUnVzc2VsbCBXYW5nDQoN Cg0KDQpwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMDktMDMtMDQgMDk6MTA6NTE6DQoN Cj4gSGkgYWxsLA0KPiANCj4gSSBqdXN0IHN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQgcHJvcG9zZXMg YSBsb2FkIGJhbGFuY2luZyBzb2x1dGlvbiBmb3INCj4gdGhlIGRlZmF1bHQgREhUIGluIFJFTE9B RC4gQ29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KPiANCj4gDQpodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zYXVtaXRyYS1wMnBzaXAtbG9hZGJhbGFuY2UtMDAudHh0 IA0KDQo+IA0KPiBCZXN0LA0KPiBTYXVtaXRyYQ0KPiANCj4gDQo+IA0KPiANCj4gd3d3LnNhdW1p dHJhLmluZm8gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQMlBTSVAgbWFpbGluZyBsaXN0DQpQ MlBTSVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJw c2lwDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNl bmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50 aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2Vj cmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRo aXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJh bnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRk cmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBu b3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQg aW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50 aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0015C76E48257574_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIHNhdW1pdHJhPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFua3MgZm9yIHlvdXIgY2xhcmlm aWNhdGlvbi4gSSByZWFkDQp0aGUgYXJ0aWNsZSBhZ2FpbiwgYW5kIHN0aWxsIHdhcyB3b25kZXJp bmcgdGhhdDo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PjEpQWJvdXQgZGF0YSBpbnNlcnRpb24gcHJvY2VkdXJlLiBBDQpuZXcgZGF0YSBzdG9yaW5nIHJl cXVlc3Qgc2hvdWxkIGZpcnN0IGFycml2ZSBhdCB0aGUgcGh5c2ljYWwgbm9kZSB3aGljaA0KcHJp bWFyeSBJRCBpcyB0aGUgaW1tZWRpYXRlIHN1Y2Nlc3NvciBvZiB0aGUgb2JqZWN0IElELCB0aGVu IGJlIGRpc3BhdGNoZWQNCnRvIHRoZSBuZWFyZWFzdCBzZWNvbmRhcnkgbm9kZSBpbiB0aGUgcGh5 c2ljYWwgbm9kZT8gQ2FuIHNlY29uZGFyeSBJRCBtaWdyYXRlDQpkeW5hbWljYWxseSBhbW9uZyBw ZWVycz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIpQWJvdXQg cGVyZm9ybWFuY2UuIEluIHNvbWUgbWFuYWdlZA0KcDJwIHN5c3RlbXMsIHBlcmZvcm1hbmNlIGlz IGNyaXRpY2FsLCBzbyBPKDEpIERIVCBpcyB0aGUgcHJlZmVyYWJsZSBhbGdyaXRobS4NCkZvciBP KDEpIERIVCwgZXh0cmEgJm5ic3A7TyhMb2dOKSBob3BzIGludHJvZHVjZWQgYnkgbG9hZCBiYWxh bmNpbmcgbWF5DQpiZSB0b28gbGFyZ2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7RGFzLCBTYXVtaXRyYSZxdW90Ow0KJmx0O3NhdW1p dHJhQHF1YWxjb21tLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDA5LTAzLTA3IDA1OjAwPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0RhcywgU2F1bWl0cmEmcXVvdDsg Jmx0O3NhdW1pdHJhQHF1YWxjb21tLmNvbSZndDssDQomcXVvdDt3YW5nLmp1bjE3QHp0ZS5jb20u Y24mcXVvdDsgJmx0O3dhbmcuanVuMTdAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPuaKhOmAgTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7cDJwc2lwQGlldGYub3JnJnF1b3Q7ICZsdDtwMnBzaXBAaWV0Zi5vcmcmZ3Q7PC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbUDJQU0lQXSBOZXcgTG9hZCBiYWxhbmNpbmcgaW4gUkVM T0FEDQpkcmFmdDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+SnVzdCBhIGNsYXJpZmljYXRpb248YnI+DQo8YnI+DQozKUNvdWxkIHRoZSBp bWJhbGFuY2UgZmFjdG9yIGJlIHJlZHVjZWQgZnVydGhlcj8gPGJyPg0KPGJyPg0KWWVzLiBUaGUg c2ltcGxlc3Qgd2F5IGlzIGJ5IGluY3JlYXNpbmcgYWxwaGEgb3IgYnkgaW5jcmVhc2luZyBkZWx0 YS4gSG93ZXZlciwNCmlmIHlvdSBpbmNyZWFzZSBhbHBoYSBvciBkZWx0YSB0b28gbXVjaCB0aGVu IHJvdXRpbmcgd291bGQgYmVjb21lIGxlc3MNCmVmZmljaWVudCByZXF1aXJpbmcgbW9yZSB0aGFu IE8obG9nIE4pIGhvcHMuIEEgbW9yZSBjb21wbGljYXRlZCB3YXkgdG8NCnJlZHVjZSB0aGUgaW1i YWxhbmNlIGZhY3RvciBpcyBieSBlbXBsb3lpbmcgYSBoaWVyYXJjaGljYWwgYXBwcm9hY2ggYnkN CmNsdXN0ZXJpbmcgbm9kZXMgaW50byBncm91cHMgKGRvaW5nIHRoZSBzY2hlbWUgaW4gdGhhdCBn cm91cCkgYW5kIHRoZW4NCmRvIHRoZSBzYW1lIHNjaGVtZSBvbiB0aGUgc3VwZXJncm91cHMgYXMg YSB3aG9sZS4gVGhpcyBjYW4gZ2V0IGNvbXBsaWNhdGVkDQphbmQgd2Ugc3RheWVkIGF3YXkgZnJv bSBpdCB0byBrZWVwIHRoZSBwcm9wb3NhbCBzaW1wbGUuPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnAycHNpcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mIERhcywgU2F1bWl0cmE8YnI+ DQpTZW50OiBGcmlkYXksIE1hcmNoIDA2LCAyMDA5IDEyOjU4IFBNPGJyPg0KVG86IHdhbmcuanVu MTdAenRlLmNvbS5jbjxicj4NCkNjOiBwMnBzaXBAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTog W1AyUFNJUF0gTmV3IExvYWQgYmFsYW5jaW5nIGluIFJFTE9BRCBkcmFmdDxicj4NCjxicj4NCkhp IFJ1c3NlbGwsPGJyPg0KPGJyPg0KICZuYnNwO1RoYW5rcyBmb3IgZ29pbmcgdGhyb3VnaCB0aGUg ZHJhZnQuPGJyPg0KPGJyPg0KICZuYnNwOzEpRG9lcyB0aGUgZmluZ2VyIHRhYmxlIG9ubHkgaW5j bHVkZSB0aGUgcHJpbWFyeSB2aXJ0dWFsIG5vZGUgSUQ/DQo8YnI+DQo8YnI+DQogJm5ic3A7VGhl IGZpbmdlciB0YWJsZSBvbmx5IGluY2x1ZGVzIHRoZSBwcmltYXJ5IHZpcnR1YWwgSURzLiBSb3V0 aW5nDQphbHdheXMgaGFwcGVucyBpbiB0d28gc3RlcHMuIEluIHRoZSBmaXJzdCBzdGVwLCB5b3Ug Y2FuIGp1c3QgaW1hZ2luZSB0aGF0DQp5b3UgZG9u4oCZdCBoYXZlIHRoZSBzZWNvbmRhcnkgdmly dHVhbCBub2RlIElEcyBhbmQganVzdCBoYXZlIHRoZSBwcmltYXJ5DQpvbmVzLiBUaGVuLCBhcyBp biB0aGUgY2FzZSBvZiBDaG9yZCwgeW91IHdvdWxkIHVzZSB0aGUgcHJpbWFyeSBJRHMgdG8gcm91 dGUNCnRoZSByZXF1ZXN0IHRvIHRoZSBwcmltYXJ5IElEIGNsb3Nlc3QgdG8gdGhlIG9iamVjdC4g QXQgdGhpcyBwb2ludCwgdGhlDQpub2RlIHRoYXQgcmVjZWl2ZXMgdGhlIHJlcXVlc3QgY2hlY2tz IGlmIGl0IG93bnMgdGhhdCBwYXJ0IG9mIHRoZSBJRCBzcGFjZS4NCklmIHllcywgaXQgc2ltcGx5 IHJldHVybnMgdGhlIG9iamVjdC9yZXNwb25zZS4gSWYgbm8sIHRoZW4gaXQgdXNlcyB0aGUNCm5l aWdoYm9yIHRhYmxlcyB0byByb3V0ZSB0aGUgcmVxdWVzdHMuIFRoaXMgd291bGQgdGFrZSBhIG1h eGltdW0gb2YgTyhsb2cNCk4pIGFkZGl0aW9uYWwgaG9wcy48YnI+DQo8YnI+DQoyKUhvdyB0byBj aGFuZ2UgdGhlIGVzdGltYXRlZCBOIHBhcmFtZXRlciAmbmJzcDthbmQga2VlcCB0aGUgc2Vydmlj ZXMgbm9uLXN0b3BwaW5nPw0KU3VwcG9zaW5nIHRoYXQgaXQgaGFzIGJlZW4gZmFyIGF3YXkgZnJv bSB0aGUgYWN0dWFsIG5ldHdvcmsgc2NhbGUuIDxicj4NCjxicj4NCiAmbmJzcDtJIGRvbuKAmXQg dGhpbmsgdGhlcmUgd2lsbCBiZSBhIHNpdHVhdGlvbiB3aGVyZSBpdCBpcyBmYXIgYXdheSBmcm9t DQp0aGUgYWN0dWFsIG5ldHdvcmsgc2NhbGUgc2luY2UgdGhlIGZpbmdlcnMga2VlcCB1cGRhdGlu ZyBhcyBhbmQgd2hlbiB0aGUNCm5ldHdvcmsgZ3Jvd3MuIEluIHNvbWUgd2F5cywgdGhlIHVwZGF0 ZSBhbGdvcml0aG0gd2lsbCBlbnN1cmUgdGhhdCB0aGlzDQpzaXR1YXRpb24gd291bGQgbm90IGFy aXNlLiBJbiB0aGUgd29yc3QgY2FzZSwgaWYgdGhlIHNpdHVhdGlvbiBoYXBwZW5zDQp0byBhcmlz ZSwgdGhlbiB0aGF0IHdvdWxkIGltcGx5IHRoYXQgdGhpcyBwYXJ0aWN1bGFyIG5vZGUgaXMgaGln aGx5IGltYmFsYW5jZWQNCmFuZCBpcyBoYW5kbGluZyBhIHZlcnkgbGFyZ2UgYW1vdW50IG9mIGxv YWQuIFRoZXJlZm9yZSwgaXQgd291bGQgYmUgb2YNCmJlbmVmaXQgZm9yIHRoZSBub2RlIHRvIG9m ZmxvYWQgc29tZSBvZiBpdHMgbG9hZC4gVGhlIGNoYW5nZSBjYW4gYmUgZG9uZQ0KYnkgbGVhdmlu ZyBqb2luaW5nIHRoZSBuZXR3b3JrIHdpdGggYSBuZXcgc2V0IG9mIHZpcnR1YWwgaWRzIGFuZCBs ZWF2aW5nDQp0aGUgbmV0d29yayB3aXRoIHRoZSBvbGQgb25lcy4gVGhpcyBjYW4gYmUgZG9uZSBz bG93bHkgd2l0aG91dCBhZmZmZWN0aW5nDQpzZXJ2aWNlcyAobm90IGxlYXZlIGFuZCBqb2luIGF0 IHRoZSBzYW1lIHRpbWUgd2l0aCBhbGwgdGhlIHZpcnR1YWwgbm9kZQ0KaWRzKS48YnI+DQo8YnI+ DQozKUNvdWxkIHRoZSBpbWJhbGFuY2UgZmFjdG9yIGJlIHJlZHVjZWQgZnVydGhlcj8gPGJyPg0K PGJyPg0KWWVzLiBUaGUgc2ltcGxlc3Qgd2F5IGlzIGJ5IGluY3JlYXNpbmcgYWxwaGEgb3IgYnkg aW5jcmVhc2luZyBkZWx0YS4gSG93ZXZlciwNCmlmIHlvdSBpbmNyZWFzZSBhbHBoYSBvciBkZWx0 YSB0b28gbXVjaCB0aGVuIHJvdXRpbmcgd291bGQgYmVjb21lIGxlc3MNCmVmZmljaWVudCByZXF1 aXJpbmcgbW9yZSB0aGFuIE8obG9nIE4pIGhvcHMuIEEgbW9yZSBjb21wbGljYXRlZCB3YXkgdG8N CnJlZHVjZSB0aGUgaW1iYWxhbmNlIGZhY3RvciBpcyBieSBlbXBsb3lpbmcgYSBoaWVyYXJjaGlj YWwgYXBwcm9hY2ggYW5kDQpidWlsZGluZyBZMCBvdmVyIGFub3RoZXIgWTAuPGJyPg0KPGJyPg0K VGhhbmtzPGJyPg0KU2F1bWl0cmE8YnI+DQo8YnI+DQpGcm9tOiB3YW5nLmp1bjE3QHp0ZS5jb20u Y24gW21haWx0bzp3YW5nLmp1bjE3QHp0ZS5jb20uY25dIDxicj4NClNlbnQ6IFR1ZXNkYXksIE1h cmNoIDAzLCAyMDA5IDEwOjU5IFBNPGJyPg0KVG86IERhcywgU2F1bWl0cmE8YnI+DQpDYzogcDJw c2lwQGlldGYub3JnOyBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZzxicj4NClN1YmplY3Q6IOetlOWk jTogW1AyUFNJUF0gTmV3IExvYWQgYmFsYW5jaW5nIGluIFJFTE9BRCBkcmFmdDxicj4NCjxicj4N Cjxicj4NCkkgaGF2ZSByZWFkIHlvdXIgYXJ0aWNsZSwgYW5kIGFncmVlIHRoYXQgbG9hZCBiYWxh bmNpbmcgaXMgYSBrZXkgaXNzdWUNCmVzcGVjaWFsbHkgd2hlbiB3ZSBkZXBsb3kgdGhlIGJhY2tl bmQgc2VydmVyIHN5c3RlbXMgYnVpbHQgYnkgcDJwIHRlY2hub2xvZ3kuDQo8YnI+DQpTb21lIHF1 ZXN0aW9ucyBmb2xsb3dpbmc6IDxicj4NCjEpRG9lcyB0aGUgZmluZ2VyIHRhYmxlIG9ubHkgaW5j bHVkZSB0aGUgcHJpbWFyeSB2aXJ0dWFsIG5vZGUgSUQ/IDxicj4NCjIpSG93IHRvIGNoYW5nZSB0 aGUgZXN0aW1hdGVkIE4gcGFyYW1ldGVyICZuYnNwO2FuZCBrZWVwIHRoZSBzZXJ2aWNlcyBub24t c3RvcHBpbmc/DQpTdXBwb3NpbmcgdGhhdCBpdCBoYXMgYmVlbiBmYXIgYXdheSBmcm9tIHRoZSBh Y3R1YWwgbmV0d29yayBzY2FsZS4gPGJyPg0KMylDb3VsZCB0aGUgaW1iYWxhbmNlIGZhY3RvciBi ZSByZWR1Y2VkIGZ1cnRoZXI/IDxicj4NCjxicj4NCjxicj4NClJ1c3NlbGwgV2FuZzxicj4NCjxi cj4NCjxicj4NCjxicj4NCnAycHNpcC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDA5LTAzLTA0 IDA5OjEwOjUxOjxicj4NCjxicj4NCiZndDsgSGkgYWxsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJ IGp1c3Qgc3VibWl0dGVkIGEgZHJhZnQgdGhhdCBwcm9wb3NlcyBhIGxvYWQgYmFsYW5jaW5nIHNv bHV0aW9uIGZvcjxicj4NCiZndDsgdGhlIGRlZmF1bHQgREhUIGluIFJFTE9BRC4gQ29tbWVudHMg YXJlIGFwcHJlY2lhdGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zYXVtaXRyYS1wMnBzaXAtbG9hZGJhbGFuY2UtMDAudHh0 DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCw8YnI+DQomZ3Q7IFNhdW1pdHJhPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHd3dy5zYXVtaXRy YS5pbmZvIDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IFAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IFAyUFNJUEBp ZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w MnBzaXA8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkm bmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0 eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7 VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRp YWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtv YmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNw O2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0 aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJz cDt0byZuYnNwO290aGVycy48YnI+DQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkm bmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5i c3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJz cDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJz cDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90 aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2Fn ZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO3NlbmRlci48YnI+DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNw O2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1Nw YW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClAyUFNJUCBt YWlsaW5nIGxpc3Q8YnI+DQpQMlBTSVBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxw cmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJz cDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZu YnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGll bnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3Rv Jm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5i c3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRz Jm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJz Lg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFu c21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNw O2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJz cDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lm Jm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5i c3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29y aWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmll d3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJl Jm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIu DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7 Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNw O0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0015C76E48257574_=-- From bbl@lowekamp.net Mon Mar 9 05:52:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B653A6984 for ; Mon, 9 Mar 2009 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWs0PeLNfX8M for ; Mon, 9 Mar 2009 05:52:21 -0700 (PDT) Received: from mail-qy0-f108.google.com (mail-qy0-f108.google.com [209.85.221.108]) by core3.amsl.com (Postfix) with ESMTP id 7AEEA3A6A89 for ; Mon, 9 Mar 2009 05:52:21 -0700 (PDT) Received: by qyk6 with SMTP id 6so954025qyk.29 for ; Mon, 09 Mar 2009 05:52:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.74.79 with SMTP id t15mr2734652qcj.2.1236603174921; Mon, 09 Mar 2009 05:52:54 -0700 (PDT) In-Reply-To: <2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com> Date: Mon, 9 Mar 2009 08:52:54 -0400 Message-ID: From: Bruce Lowekamp To: "Das, Saumitra" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] New Load balancing in RELOAD draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2009 12:52:29 -0000 Saumitra, Very interesting draft. Do you have experimental results of how this works in an implementation? In particular, given the sensitivity of the load distribution on delta, I'm wondering whether peers' different perceptions of the size of the overlay creates its own load imbalance factor. (may be able to do that quantitatively, I guess.) It also seems like the arrival of a new peer is going to cause a storm of data migrations, and this would cause the overlay to suffer congestion collapse in anything but a stable overlay. Due to those concerns, and in particular because of the complexity of the implementation, I would oppose modifying the base dht algorithm in this manner. Not that load imbalance and handling peers with different resource levels isn't an issue with the base dht, but implementation complexity is already a serious issue that I remain concerned about. However, I believe a draft like this specifying an alternative dht algorithm is beneficial, and would support a further revision. Bruce On Tue, Mar 3, 2009 at 9:10 PM, Das, Saumitra wrote: > Hi all, > > I just submitted a draft that proposes a load balancing solution for the default DHT in RELOAD. Comments are appreciated. > > http://www.ietf.org/internet-drafts/draft-saumitra-p2psip-loadbalance-00.txt > > Best, > Saumitra > > > > > www.saumitra.info > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From root@core3.amsl.com Sat Mar 7 14:15:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B575B3A67D6; Sat, 7 Mar 2009 14:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307221501.B575B3A67D6@core3.amsl.com> Date: Sat, 7 Mar 2009 14:15:01 -0800 (PST) X-Mailman-Approved-At: Mon, 09 Mar 2009 11:04:20 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-02.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-base-02.txt Pages : 139 Date : 2009-03-07 In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC 3979 respectively. They refer only to those RFCs and not any documents that update or supersede them. This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-base-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07141147.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Mar 7 14:15:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BE2523A67E9; Sat, 7 Mar 2009 14:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307221501.BE2523A67E9@core3.amsl.com> Date: Sat, 7 Mar 2009 14:15:01 -0800 (PST) X-Mailman-Approved-At: Mon, 09 Mar 2009 11:04:20 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-sip-01.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : A SIP Usage for RELOAD Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-sip-01.txt Pages : 13 Date : 2009-03-07 This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-sip-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07141213.I-D@ietf.org> --NextPart-- From hardie@qualcomm.com Mon Mar 9 12:04:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C3A3A6CB3 for ; Mon, 9 Mar 2009 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=-2.575, BAYES_00=-2.599, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCP4YYIazTIF for ; Mon, 9 Mar 2009 12:04:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BA70428C293 for ; Mon, 9 Mar 2009 12:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1236625464; x=1268161464; h=mime-version:message-id:date:to:from:subject: content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|Date:=20Mon,=209=20Mar=202009=2012:04:1 7=20-0700|To:=20|From:=20Ted=20Hardie=20 |Subject:=20possible=20agenda=20requ est|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5548"=3B=20 a=3D"16092479"; bh=/ORRI/FYLwPDP4+G2UK6WD6Oe4t7yuGwaEl+tin+3Rc=; b=pK3+dWSvzGiZonQDkHASLqTcx/ZwtvDrGaXYBaXDqF/N2pqRs85lKBrs GkaQHyFzure8rQb8uOWDMfVPf87mmoj0khVQByu05FeCnIu9Cm8xPZH/6 LZBOLT55YF5cdDz5hCgH/HDnaNI11gXGGYMduY0/Ph8UyRWLfWj0Y4oqb o=; X-IronPort-AV: E=McAfee;i="5300,2777,5548"; a="16092479" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2009 12:04:24 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n29J4NmZ018487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Mar 2009 12:04:23 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n29J4KEU027284 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 9 Mar 2009 12:04:20 -0700 (PDT) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 9 Mar 2009 12:04:19 -0700 Received: from [10.227.68.131] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 9 Mar 2009 12:04:19 -0700 MIME-Version: 1.0 Message-ID: Date: Mon, 9 Mar 2009 12:04:17 -0700 To: From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: [P2PSIP] possible agenda request X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2009 19:04:31 -0000 So, I have updated draft-hardie-p2psip-p2p-pointers to 01, eliminating the MIME type and focusing on the URIs. I would like to ask two questions: 1) Does anyone object to a request for provisional registration at this point, so we can start experimenting with these? As a sub bullet, does anyone have feedback on the IANA registries requested by this doc and have any objections/input/better ideas? 2) Is anyone interested in progressing the MIME type work? I took it out because it seemed to overlap the application/p2p-overlay+xml stuff in the reload base draft, and I didn't want too much confusion. I think the cases are distinguishable, but I wasn't sure anyone wanted the pointers to be that distinct from bootstrap information. If anyone does care, speaking up now would be handy. A short discussion during the meeting would resolve this, but if folks have opinions now and want to put them onto the mailing list, we can also likely resolve it here. If we do want to go forward on the URI side now, the next steps would be discussion on the uri-review and uri mailing lists. regards, Ted From hsinnrei@adobe.com Mon Mar 9 18:04:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89EDA3A6CCF for ; Mon, 9 Mar 2009 18:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XWQL2UODqSe for ; Mon, 9 Mar 2009 18:04:36 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 00CEE3A6CAB for ; Mon, 9 Mar 2009 18:04:34 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSbW8xVlsJ+6Ybt15C1AKRHGH7KFZZ44Z@postini.com; Mon, 09 Mar 2009 18:05:10 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n2A0xieM012332; Mon, 9 Mar 2009 17:59:44 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n2A158iq005706; Mon, 9 Mar 2009 18:05:08 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 9 Mar 2009 18:05:08 -0700 From: Henry Sinnreich To: p2psip Date: Mon, 9 Mar 2009 18:05:05 -0700 Thread-Topic: I-D Action:draft-ahrenholz-hiprg-dht-04.txt Thread-Index: Acmg89fg4lePl4beRsGlIpbcNBV0ywAKGduE Message-ID: In-Reply-To: <20090309201501.A9D043A6A4E@core3.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5DB26F1C177hsinnreiadobecom_" MIME-Version: 1.0 Cc: "jeffrey.m.ahrenholz@boeing.com" Subject: [P2PSIP] FW: I-D Action:draft-ahrenholz-hiprg-dht-04.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 10 Mar 2009 01:04:37 -0000 --_000_C5DB26F1C177hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------ Forwarded Message From: Reply-To: Date: Mon, 9 Mar 2009 13:15:01 -0700 To: Conversation: I-D Action:draft-ahrenholz-hiprg-dht-04.txt Subject: I-D Action:draft-ahrenholz-hiprg-dht-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : HIP DHT Interface Author(s) : J. Ahrenholz Filename : draft-ahrenholz-hiprg-dht-04.txt Pages : 24 Date : 2009-03-09 This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --_000_C5DB26F1C177hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D Action:draft-ahrenholz-hiprg-dht-04.txt
------ Forwarded Message
From: <Internet-Drafts@ietf.org>
Reply-To: <internet-drafts@i= etf.org>
Date: Mon, 9 Mar 2009 13:15:01 -0700
To: <i-d-announce@ietf.org&= gt;
Conversation: I-D Action:draft-ahrenholz-hiprg-dht-04.txt
Subject: I-D Action:draft-ahrenholz-hiprg-dht-04.txt

A New Internet-Draft is available from the = on-line Internet-Drafts directories.

        Title    &nb= sp;      : HIP DHT Interface
        Author(s)    = ;   : J. Ahrenholz
        Filename    =     : draft-ahrenholz-hiprg-dht-04.txt
        Pages    &nb= sp;      : 24
        Date    &nbs= p;       : 2009-03-09

This document specifies a common interface for using HIP with a
Distributed Hash Table service to provide a HIT-to-address lookup
service and an unmanaged name-to-HIT lookup service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-04.txt<= /a>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet= -drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Route Logging in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 10 Mar 2009 14:18:44 -0000 AES256-SHAAt Tue, 10 Mar 2009 13:16:21 +0200, Jaime Jimenez wrote: > > Hi, > > I have a question about the Forwarding Header of RELOAD, particularly > the Route Logging. > > > enum { (255) } RouteLogExtensionType; > > struct { > RouteLogExtensionType type; > uint16 length; > > select (type){ > /* Extension values go here */ > } extension; > } RouteLogExtension; > > enum { > reserved(0), > tcp_tls(1), > udp_dtls(2), > (255) > } OverlayLink; > > struct { > opaque version<0..28-1>; /* A string */ > OverlayLink linkProtocol; /* TCP or UDP */ > NodeId id; > uint32 uptime; > IpAddressPort address; > opaque certificate<0..216-1>; > RouteLogExtension extensions<0..216-1>; > } RouteLogEntry; > > struct { > RouteLogEntry entries<0..216-1>; > } RouteLog; > > > The structure defines a RouteLogExtension but I could not interprete > whether it defines many extensions for each RouteLogEntry or just one. Many. That syntax means that they're laid end to end up to a total length of 2^16-1. > In the case there are many we have a problem when we parse an encoded > message since we do not know the length of the RouteLogExtension > structure or the number of extensions there are. So, if there were many, > it might be convenient to have a field specifying the length of the list > of entries. Those are both there. RouteLogExtension.length is the length of each extension. RouteLogEntry.extensions has a length field. -Ekr From saumitra@qualcomm.com Tue Mar 10 11:24:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678673A6932 for ; Tue, 10 Mar 2009 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.775 X-Spam-Level: X-Spam-Status: No, score=-104.775 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K6pYh5jbsub for ; Tue, 10 Mar 2009 11:24:41 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 449B428C15F for ; Tue, 10 Mar 2009 11:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1236709513; x=1268245513; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"wang.jun17@zte.com.cn"=20|CC: =20"p2psip@ietf.org"=20|Date:=20Tue,=201 0=20Mar=202009=2011:25:12=20-0700|Subject:=20RE:=20[P2PSI P]=20New=20Load=20balancing=20in=20RELOAD=20draft |Thread-Topic:=20[P2PSIP]=20New=20Load=20balancing=20in =20RELOAD=20draft|Thread-Index:=20Acmga0YQqS5vRhuNTWeei5E zmwbitwBNzAJw|Message-ID:=20<2D06DE445C2ADE44890118C3F449 B9634009A3C2@NASANEXMB12.na.qualcomm.com>|References:=20< 2D06DE445C2ADE44890118C3F449B9634009A1BA@NASANEXMB12.na.q ualcomm.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5549"=3B=20 a=3D"16144510"; bh=RgAnItMVWVqgj+9GI8ffHm70kgtf/ARsZ8FAk8f7O7w=; b=RlbYKJjEkZbAQ6/oLFUmW1xl536qBaJZB0cicv6xLVHWYx2syygXLwKS rNFgUYcu0Fme+xdVW3EcnCuyY6nWF5r9sumxKtdrIakEs7+V/qF0sC0oE cKuKZQOPdXW4YeJS/aXGWkFPhszUuYOhQnXGwxBqS56eoza+qcMMAuQpy o=; X-IronPort-AV: E=McAfee;i="5300,2777,5549"; a="16144510" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2009 11:25:13 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2AIPD5P001480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Mar 2009 11:25:13 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2AIPCCU023199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Mar 2009 11:25:13 -0700 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 10 Mar 2009 11:25:11 -0700 From: "Das, Saumitra" To: "wang.jun17@zte.com.cn" Date: Tue, 10 Mar 2009 11:25:12 -0700 Thread-Topic: [P2PSIP] New Load balancing in RELOAD draft Thread-Index: Acmga0YQqS5vRhuNTWeei5EzmwbitwBNzAJw Message-ID: <2D06DE445C2ADE44890118C3F449B9634009A3C2@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B9634009A1BA@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] New Load balancing in RELOAD draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 10 Mar 2009 18:24:49 -0000 MS4gQWJvdXQgZGF0YSBpbnNlcnRpb24gcHJvY2VkdXJlLiBBIG5ldyBkYXRhIHN0b3JpbmcgcmVx dWVzdCBzaG91bGQgZmlyc3QgYXJyaXZlIGF0IHRoZSBwaHlzaWNhbCBub2RlIHdoaWNoIHByaW1h cnkgSUQgaXMgdGhlIGltbWVkaWF0ZSBzdWNjZXNzb3Igb2YgdGhlIG9iamVjdCBJRCwgdGhlbiBi ZSBkaXNwYXRjaGVkIHRvIHRoZSBuZWFyZWFzdCBzZWNvbmRhcnkgbm9kZSBpbiB0aGUgcGh5c2lj YWwgbm9kZT8NCg0KWWVzLiBUaGlzIGlzIGNvcnJlY3QuDQoNCjIuIENhbiBzZWNvbmRhcnkgSUQg bWlncmF0ZSBkeW5hbWljYWxseSBhbW9uZyBwZWVycz8NCg0KUHJpbWFyeSBJRHMgYXJlIGZpeGVk IGFuZCBhIG5vZGUgaGFzIG9uZSBwcmltYXJ5IElEIGFzc2lnbmVkIGZvciBpdHMgbGlmZXRpbWUg b24gdGhlIG5ldHdvcmsgc2ltaWxhciB0byBiYXNlIFJFTE9BRC4gVGhlIHNlY29uZGFyeSBJRHMg Y2hhbmdlIGR5bmFtaWNhbGx5IGFzIHJlcXVpcmVkIChmb3IgZXhhbXBsZSwgZHVyaW5nIGFkZGlu ZyBvciByZW1vdmluZyBub2RlcyBhcyBpbiBvdXIgdXBkYXRlIGFsZ29yaXRobSkuIEkgZ3Vlc3Mg dGhpcyBpcyB3aGF0IHlvdSBhcmUgYXNraW5nIG9yIG1heWJlIEkgYW0gbWlzdW5kZXJzdGFuZGlu ZyB5b3VyIHF1ZXN0aW9uLiBBbiBpZCBjYW5ub3QgYmUgaGFuZGVkIG9mZiBiZXR3ZWVuIHBlZXJz Lg0KDQozLiBJbiBzb21lIG1hbmFnZWQgcDJwIHN5c3RlbXMsIHBlcmZvcm1hbmNlIGlzIGNyaXRp Y2FsLCBzbyBPKDEpIERIVCBpcyB0aGUgcHJlZmVyYWJsZSBhbGdyaXRobS4gRm9yIE8oMSkgREhU LCBleHRyYSAgTyhMb2dOKSBob3BzIGludHJvZHVjZWQgYnkgbG9hZCBiYWxhbmNpbmcgbWF5IGJl IHRvbyBsYXJnZS4NCg0KSW4gdGhlIGJhc2ljIGZvcm0sIHlvdSB3b3VsZCByZXF1aXJlIE8obG9n IE4pIHRvIGdldCB0byB0aGUgcHJpbWFyeSB2aXJ0dWFsIG5vZGUgY2xvc2VzdCB0byB0aGUgb2Jq ZWN0IElEICh2aWEgQ2hvcmQvUGFzdHJ5IGV0Yy4pLCBhbmQgdGhlbiBhbiBhZGRpdGlvbmFsIE8o bG9nIE4pIGhvcHMgdG8gZ2V0IHRvIHRoZSBjb3JyZWN0IHBoeXNpY2FsIG5vZGUuIFRoZSBsYXR0 ZXIgc3RlcCBpcyB1c3VhbGx5IHJhbmRvbS13YWxrIGJhc2VkIHdoZXJlIHlvdSBqdXN0IHdhbGsg YmFja3dhcmRzIGZyb20gdGhlIHByaW1hcnkgdmlydHVhbCBub2RlIHVudGlsIHlvdSBnZXQgdG8g YSBwaHlzaWNhbCBub2RlIHRoYXQgb3ducyB0aGUgb2JqZWN0IElELiANCg0KTm93LCB0aGUgc3Rl cCAxIGNhbiBiZSBlYXNpbHkgaW1wbGVtZW50ZWQgb3ZlciBhIE8oMSkgREhUIGp1c3QgYnkgcmVw bGFjaW5nIHRoZSBDaG9yZC9QYXN0cnkgbGlrZSB0b3BvbG9neSB3aXRoIHRoZSBjb3JyZXNwb25k aW5nIE8oMSkgREhULiBUaGVyZSBhcmUgc2V2ZXJhbCBwcm9wb3NhbHMgaW4gcmVzZWFyY2ggcGFw ZXJzIHRvIGRvIHRoaXMuIEluIFBhc3RyeSB5b3UgY291bGQgdmFyeSB0aGUgc3lzdGVtIHBhcmFt ZXRlcnMgdG8gYWNoaWV2ZSB0aGlzLg0KDQpJZiB3ZSB3YW50IHRvIG1ha2UgdGhlIHJhbmRvbSB3 YWxrIHBhcnQgYWxzbyBPKDEpLCB0aGVuIHRoZSBlYXNpZXN0IHdheSB0byBkbyBpdCBpcyBieSBp bmNsdWRpbmcgbW9yZSBuZWlnaGJvciBzdGF0ZSAoZS5nLiBPKGxvZyBOKSBuZWlnaGJvcnMgaW4g YWRkaXRpb24gdG8gTyhsb2cgTikgZmluZ2VycykgaW4gdGhlIG5vZGUgc28gdGhhdCB0aGUgb2Jq ZWN0IGNhbiBiZSByb3V0ZWQgdG8gdGhlIGV4YWN0IElEIGluIE8oMSkgaG9wcy4NCg0KU28geWVz LCBpbiBtYW5hZ2VkIGJhY2tlZCBwMnAgc3lzdGVtcyB3aGljaCBtYXkgbm90IGJlIHRvbyBjb25j ZXJuZWQgd2l0aCBoaWdoZXIgb3ZlcmhlYWQgYXMgZ2VuZXJpYyBwMnAgc3lzdGVtcywgdGhlIHNj aGVtZSBjYW4gYmUgZXh0ZW5kZWQuDQoNClRoYW5rcw0KU2F1bWl0cmENCg0KDQpGcm9tOiB3YW5n Lmp1bjE3QHp0ZS5jb20uY24gW21haWx0bzp3YW5nLmp1bjE3QHp0ZS5jb20uY25dIA0KU2VudDog U3VuZGF5LCBNYXJjaCAwOCwgMjAwOSA4OjU4IFBNDQpUbzogRGFzLCBTYXVtaXRyYQ0KQ2M6IHAy cHNpcEBpZXRmLm9yZzsgRGFzLCBTYXVtaXRyYQ0KU3ViamVjdDogUkU6IFtQMlBTSVBdIE5ldyBM b2FkIGJhbGFuY2luZyBpbiBSRUxPQUQgZHJhZnQNCg0KDQpIaSBzYXVtaXRyYSANCnRoYW5rcyBm b3IgeW91ciBjbGFyaWZpY2F0aW9uLiBJIHJlYWQgdGhlIGFydGljbGUgYWdhaW4sIGFuZCBzdGls bCB3YXMgd29uZGVyaW5nIHRoYXQ6IA0KDQoxKUFib3V0IGRhdGEgaW5zZXJ0aW9uIHByb2NlZHVy ZS4gQSBuZXcgZGF0YSBzdG9yaW5nIHJlcXVlc3Qgc2hvdWxkIGZpcnN0IGFycml2ZSBhdCB0aGUg cGh5c2ljYWwgbm9kZSB3aGljaCBwcmltYXJ5IElEIGlzIHRoZSBpbW1lZGlhdGUgc3VjY2Vzc29y IG9mIHRoZSBvYmplY3QgSUQsIHRoZW4gYmUgZGlzcGF0Y2hlZCB0byB0aGUgbmVhcmVhc3Qgc2Vj b25kYXJ5IG5vZGUgaW4gdGhlIHBoeXNpY2FsIG5vZGU/IENhbiBzZWNvbmRhcnkgSUQgbWlncmF0 ZSBkeW5hbWljYWxseSBhbW9uZyBwZWVycz8gDQoyKUFib3V0IHBlcmZvcm1hbmNlLiBJbiBzb21l IG1hbmFnZWQgcDJwIHN5c3RlbXMsIHBlcmZvcm1hbmNlIGlzIGNyaXRpY2FsLCBzbyBPKDEpIERI VCBpcyB0aGUgcHJlZmVyYWJsZSBhbGdyaXRobS4gRm9yIE8oMSkgREhULCBleHRyYSDCoE8oTG9n TikgaG9wcyBpbnRyb2R1Y2VkIGJ5IGxvYWQgYmFsYW5jaW5nIG1heSBiZSB0b28gbGFyZ2UuIA0K DQoNCg0KDQoiRGFzLCBTYXVtaXRyYSIgPHNhdW1pdHJhQHF1YWxjb21tLmNvbT4gDQoyMDA5LTAz LTA3IDA1OjAwIA0K5pS25Lu25Lq6DQoiRGFzLCBTYXVtaXRyYSIgPHNhdW1pdHJhQHF1YWxjb21t LmNvbT4sICJ3YW5nLmp1bjE3QHp0ZS5jb20uY24iIDx3YW5nLmp1bjE3QHp0ZS5jb20uY24+IA0K 5oqE6YCBDQoicDJwc2lwQGlldGYub3JnIiA8cDJwc2lwQGlldGYub3JnPiANCuS4u+mimA0KUkU6 IFtQMlBTSVBdIE5ldyBMb2FkIGJhbGFuY2luZyBpbiBSRUxPQUQgZHJhZnQNCg0KDQoNCg0KDQoN Cg0KSnVzdCBhIGNsYXJpZmljYXRpb24NCg0KMylDb3VsZCB0aGUgaW1iYWxhbmNlIGZhY3RvciBi ZSByZWR1Y2VkIGZ1cnRoZXI/IA0KDQpZZXMuIFRoZSBzaW1wbGVzdCB3YXkgaXMgYnkgaW5jcmVh c2luZyBhbHBoYSBvciBieSBpbmNyZWFzaW5nIGRlbHRhLiBIb3dldmVyLCBpZiB5b3UgaW5jcmVh c2UgYWxwaGEgb3IgZGVsdGEgdG9vIG11Y2ggdGhlbiByb3V0aW5nIHdvdWxkIGJlY29tZSBsZXNz IGVmZmljaWVudCByZXF1aXJpbmcgbW9yZSB0aGFuIE8obG9nIE4pIGhvcHMuIEEgbW9yZSBjb21w bGljYXRlZCB3YXkgdG8gcmVkdWNlIHRoZSBpbWJhbGFuY2UgZmFjdG9yIGlzIGJ5IGVtcGxveWlu ZyBhIGhpZXJhcmNoaWNhbCBhcHByb2FjaCBieSBjbHVzdGVyaW5nIG5vZGVzIGludG8gZ3JvdXBz IChkb2luZyB0aGUgc2NoZW1lIGluIHRoYXQgZ3JvdXApIGFuZCB0aGVuIGRvIHRoZSBzYW1lIHNj aGVtZSBvbiB0aGUgc3VwZXJncm91cHMgYXMgYSB3aG9sZS4gVGhpcyBjYW4gZ2V0IGNvbXBsaWNh dGVkIGFuZCB3ZSBzdGF5ZWQgYXdheSBmcm9tIGl0IHRvIGtlZXAgdGhlIHByb3Bvc2FsIHNpbXBs ZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHAycHNpcC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXMs IFNhdW1pdHJhDQpTZW50OiBGcmlkYXksIE1hcmNoIDA2LCAyMDA5IDEyOjU4IFBNDQpUbzogd2Fu Zy5qdW4xN0B6dGUuY29tLmNuDQpDYzogcDJwc2lwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1Ay UFNJUF0gTmV3IExvYWQgYmFsYW5jaW5nIGluIFJFTE9BRCBkcmFmdA0KDQpIaSBSdXNzZWxsLA0K DQrCoFRoYW5rcyBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgZHJhZnQuDQoNCsKgMSlEb2VzIHRoZSBm aW5nZXIgdGFibGUgb25seSBpbmNsdWRlIHRoZSBwcmltYXJ5IHZpcnR1YWwgbm9kZSBJRD8gDQoN CsKgVGhlIGZpbmdlciB0YWJsZSBvbmx5IGluY2x1ZGVzIHRoZSBwcmltYXJ5IHZpcnR1YWwgSURz LiBSb3V0aW5nIGFsd2F5cyBoYXBwZW5zIGluIHR3byBzdGVwcy4gSW4gdGhlIGZpcnN0IHN0ZXAs IHlvdSBjYW4ganVzdCBpbWFnaW5lIHRoYXQgeW91IGRvbuKAmXQgaGF2ZSB0aGUgc2Vjb25kYXJ5 IHZpcnR1YWwgbm9kZSBJRHMgYW5kIGp1c3QgaGF2ZSB0aGUgcHJpbWFyeSBvbmVzLiBUaGVuLCBh cyBpbiB0aGUgY2FzZSBvZiBDaG9yZCwgeW91IHdvdWxkIHVzZSB0aGUgcHJpbWFyeSBJRHMgdG8g cm91dGUgdGhlIHJlcXVlc3QgdG8gdGhlIHByaW1hcnkgSUQgY2xvc2VzdCB0byB0aGUgb2JqZWN0 LiBBdCB0aGlzIHBvaW50LCB0aGUgbm9kZSB0aGF0IHJlY2VpdmVzIHRoZSByZXF1ZXN0IGNoZWNr cyBpZiBpdCBvd25zIHRoYXQgcGFydCBvZiB0aGUgSUQgc3BhY2UuIElmIHllcywgaXQgc2ltcGx5 IHJldHVybnMgdGhlIG9iamVjdC9yZXNwb25zZS4gSWYgbm8sIHRoZW4gaXQgdXNlcyB0aGUgbmVp Z2hib3IgdGFibGVzIHRvIHJvdXRlIHRoZSByZXF1ZXN0cy4gVGhpcyB3b3VsZCB0YWtlIGEgbWF4 aW11bSBvZiBPKGxvZyBOKSBhZGRpdGlvbmFsIGhvcHMuDQoNCjIpSG93IHRvIGNoYW5nZSB0aGUg ZXN0aW1hdGVkIE4gcGFyYW1ldGVyIMKgYW5kIGtlZXAgdGhlIHNlcnZpY2VzIG5vbi1zdG9wcGlu Zz8gU3VwcG9zaW5nIHRoYXQgaXQgaGFzIGJlZW4gZmFyIGF3YXkgZnJvbSB0aGUgYWN0dWFsIG5l dHdvcmsgc2NhbGUuIA0KDQrCoEkgZG9u4oCZdCB0aGluayB0aGVyZSB3aWxsIGJlIGEgc2l0dWF0 aW9uIHdoZXJlIGl0IGlzIGZhciBhd2F5IGZyb20gdGhlIGFjdHVhbCBuZXR3b3JrIHNjYWxlIHNp bmNlIHRoZSBmaW5nZXJzIGtlZXAgdXBkYXRpbmcgYXMgYW5kIHdoZW4gdGhlIG5ldHdvcmsgZ3Jv d3MuIEluIHNvbWUgd2F5cywgdGhlIHVwZGF0ZSBhbGdvcml0aG0gd2lsbCBlbnN1cmUgdGhhdCB0 aGlzIHNpdHVhdGlvbiB3b3VsZCBub3QgYXJpc2UuIEluIHRoZSB3b3JzdCBjYXNlLCBpZiB0aGUg c2l0dWF0aW9uIGhhcHBlbnMgdG8gYXJpc2UsIHRoZW4gdGhhdCB3b3VsZCBpbXBseSB0aGF0IHRo aXMgcGFydGljdWxhciBub2RlIGlzIGhpZ2hseSBpbWJhbGFuY2VkIGFuZCBpcyBoYW5kbGluZyBh IHZlcnkgbGFyZ2UgYW1vdW50IG9mIGxvYWQuIFRoZXJlZm9yZSwgaXQgd291bGQgYmUgb2YgYmVu ZWZpdCBmb3IgdGhlIG5vZGUgdG8gb2ZmbG9hZCBzb21lIG9mIGl0cyBsb2FkLiBUaGUgY2hhbmdl IGNhbiBiZSBkb25lIGJ5IGxlYXZpbmcgam9pbmluZyB0aGUgbmV0d29yayB3aXRoIGEgbmV3IHNl dCBvZiB2aXJ0dWFsIGlkcyBhbmQgbGVhdmluZyB0aGUgbmV0d29yayB3aXRoIHRoZSBvbGQgb25l cy4gVGhpcyBjYW4gYmUgZG9uZSBzbG93bHkgd2l0aG91dCBhZmZmZWN0aW5nIHNlcnZpY2VzIChu b3QgbGVhdmUgYW5kIGpvaW4gYXQgdGhlIHNhbWUgdGltZSB3aXRoIGFsbCB0aGUgdmlydHVhbCBu b2RlIGlkcykuDQoNCjMpQ291bGQgdGhlIGltYmFsYW5jZSBmYWN0b3IgYmUgcmVkdWNlZCBmdXJ0 aGVyPyANCg0KWWVzLiBUaGUgc2ltcGxlc3Qgd2F5IGlzIGJ5IGluY3JlYXNpbmcgYWxwaGEgb3Ig YnkgaW5jcmVhc2luZyBkZWx0YS4gSG93ZXZlciwgaWYgeW91IGluY3JlYXNlIGFscGhhIG9yIGRl bHRhIHRvbyBtdWNoIHRoZW4gcm91dGluZyB3b3VsZCBiZWNvbWUgbGVzcyBlZmZpY2llbnQgcmVx dWlyaW5nIG1vcmUgdGhhbiBPKGxvZyBOKSBob3BzLiBBIG1vcmUgY29tcGxpY2F0ZWQgd2F5IHRv IHJlZHVjZSB0aGUgaW1iYWxhbmNlIGZhY3RvciBpcyBieSBlbXBsb3lpbmcgYSBoaWVyYXJjaGlj YWwgYXBwcm9hY2ggYW5kIGJ1aWxkaW5nIFkwIG92ZXIgYW5vdGhlciBZMC4NCg0KVGhhbmtzDQpT YXVtaXRyYQ0KDQpGcm9tOiB3YW5nLmp1bjE3QHp0ZS5jb20uY24gW21haWx0bzp3YW5nLmp1bjE3 QHp0ZS5jb20uY25dIA0KU2VudDogVHVlc2RheSwgTWFyY2ggMDMsIDIwMDkgMTA6NTkgUE0NClRv OiBEYXMsIFNhdW1pdHJhDQpDYzogcDJwc2lwQGlldGYub3JnOyBwMnBzaXAtYm91bmNlc0BpZXRm Lm9yZw0KU3ViamVjdDog562U5aSNOiBbUDJQU0lQXSBOZXcgTG9hZCBiYWxhbmNpbmcgaW4gUkVM T0FEIGRyYWZ0DQoNCg0KSSBoYXZlIHJlYWQgeW91ciBhcnRpY2xlLCBhbmQgYWdyZWUgdGhhdCBs b2FkIGJhbGFuY2luZyBpcyBhIGtleSBpc3N1ZSBlc3BlY2lhbGx5IHdoZW4gd2UgZGVwbG95IHRo ZSBiYWNrZW5kIHNlcnZlciBzeXN0ZW1zIGJ1aWx0IGJ5IHAycCB0ZWNobm9sb2d5LiANClNvbWUg cXVlc3Rpb25zIGZvbGxvd2luZzogDQoxKURvZXMgdGhlIGZpbmdlciB0YWJsZSBvbmx5IGluY2x1 ZGUgdGhlIHByaW1hcnkgdmlydHVhbCBub2RlIElEPyANCjIpSG93IHRvIGNoYW5nZSB0aGUgZXN0 aW1hdGVkIE4gcGFyYW1ldGVyIMKgYW5kIGtlZXAgdGhlIHNlcnZpY2VzIG5vbi1zdG9wcGluZz8g U3VwcG9zaW5nIHRoYXQgaXQgaGFzIGJlZW4gZmFyIGF3YXkgZnJvbSB0aGUgYWN0dWFsIG5ldHdv cmsgc2NhbGUuIA0KMylDb3VsZCB0aGUgaW1iYWxhbmNlIGZhY3RvciBiZSByZWR1Y2VkIGZ1cnRo ZXI/IA0KDQoNClJ1c3NlbGwgV2FuZw0KDQoNCg0KcDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmcg5YaZ 5LqOIDIwMDktMDMtMDQgMDk6MTA6NTE6DQoNCj4gSGkgYWxsLA0KPiANCj4gSSBqdXN0IHN1Ym1p dHRlZCBhIGRyYWZ0IHRoYXQgcHJvcG9zZXMgYSBsb2FkIGJhbGFuY2luZyBzb2x1dGlvbiBmb3IN Cj4gdGhlIGRlZmF1bHQgREhUIGluIFJFTE9BRC4gQ29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0K PiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2F1bWl0cmEt cDJwc2lwLWxvYWRiYWxhbmNlLTAwLnR4dCANCj4gDQo+IEJlc3QsDQo+IFNhdW1pdHJhDQo+IA0K PiANCj4gDQo+IA0KPiB3d3cuc2F1bWl0cmEuaW5mbyANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPiBQMlBT SVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBz aXANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURcKgSW5mb3JtYXRpb27CoFNlY3VyaXR5wqBOb3RpY2U6wqBUaGXCoGluZm9ybWF0 aW9uwqBjb250YWluZWTCoGluwqB0aGlzwqBtYWlswqBpc8Kgc29sZWx5wqBwcm9wZXJ0ecKgb2bC oHRoZcKgc2VuZGVyJ3PCoG9yZ2FuaXphdGlvbi7CoFRoaXPCoG1haWzCoGNvbW11bmljYXRpb27C oGlzwqBjb25maWRlbnRpYWwuwqBSZWNpcGllbnRzwqBuYW1lZMKgYWJvdmXCoGFyZcKgb2JsaWdh dGVkwqB0b8KgbWFpbnRhaW7CoHNlY3JlY3nCoGFuZMKgYXJlwqBub3TCoHBlcm1pdHRlZMKgdG/C oGRpc2Nsb3NlwqB0aGXCoGNvbnRlbnRzwqBvZsKgdGhpc8KgY29tbXVuaWNhdGlvbsKgdG/CoG90 aGVycy4NClRoaXPCoGVtYWlswqBhbmTCoGFuecKgZmlsZXPCoHRyYW5zbWl0dGVkwqB3aXRowqBp dMKgYXJlwqBjb25maWRlbnRpYWzCoGFuZMKgaW50ZW5kZWTCoHNvbGVsecKgZm9ywqB0aGXCoHVz ZcKgb2bCoHRoZcKgaW5kaXZpZHVhbMKgb3LCoGVudGl0ecKgdG/CoHdob23CoHRoZXnCoGFyZcKg YWRkcmVzc2VkLsKgSWbCoHlvdcKgaGF2ZcKgcmVjZWl2ZWTCoHRoaXPCoGVtYWlswqBpbsKgZXJy b3LCoHBsZWFzZcKgbm90aWZ5wqB0aGXCoG9yaWdpbmF0b3LCoG9mwqB0aGXCoG1lc3NhZ2UuwqBB bnnCoHZpZXdzwqBleHByZXNzZWTCoGluwqB0aGlzwqBtZXNzYWdlwqBhcmXCoHRob3NlwqBvZsKg dGhlwqBpbmRpdmlkdWFswqBzZW5kZXIuDQpUaGlzwqBtZXNzYWdlwqBoYXPCoGJlZW7CoHNjYW5u ZWTCoGZvcsKgdmlydXNlc8KgYW5kwqBTcGFtwqBiecKgWlRFwqBBbnRpLVNwYW3CoHN5c3RlbS4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQMlBTSVAg bWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcDJwc2lwDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURcKgSW5mb3JtYXRpb27CoFNlY3VyaXR5wqBOb3Rp Y2U6wqBUaGXCoGluZm9ybWF0aW9uwqBjb250YWluZWTCoGluwqB0aGlzwqBtYWlswqBpc8Kgc29s ZWx5wqBwcm9wZXJ0ecKgb2bCoHRoZcKgc2VuZGVyJ3PCoG9yZ2FuaXphdGlvbi7CoFRoaXPCoG1h aWzCoGNvbW11bmljYXRpb27CoGlzwqBjb25maWRlbnRpYWwuwqBSZWNpcGllbnRzwqBuYW1lZMKg YWJvdmXCoGFyZcKgb2JsaWdhdGVkwqB0b8KgbWFpbnRhaW7CoHNlY3JlY3nCoGFuZMKgYXJlwqBu b3TCoHBlcm1pdHRlZMKgdG/CoGRpc2Nsb3NlwqB0aGXCoGNvbnRlbnRzwqBvZsKgdGhpc8KgY29t bXVuaWNhdGlvbsKgdG/CoG90aGVycy4NClRoaXPCoGVtYWlswqBhbmTCoGFuecKgZmlsZXPCoHRy YW5zbWl0dGVkwqB3aXRowqBpdMKgYXJlwqBjb25maWRlbnRpYWzCoGFuZMKgaW50ZW5kZWTCoHNv bGVsecKgZm9ywqB0aGXCoHVzZcKgb2bCoHRoZcKgaW5kaXZpZHVhbMKgb3LCoGVudGl0ecKgdG/C oHdob23CoHRoZXnCoGFyZcKgYWRkcmVzc2VkLsKgSWbCoHlvdcKgaGF2ZcKgcmVjZWl2ZWTCoHRo aXPCoGVtYWlswqBpbsKgZXJyb3LCoHBsZWFzZcKgbm90aWZ5wqB0aGXCoG9yaWdpbmF0b3LCoG9m wqB0aGXCoG1lc3NhZ2UuwqBBbnnCoHZpZXdzwqBleHByZXNzZWTCoGluwqB0aGlzwqBtZXNzYWdl wqBhcmXCoHRob3NlwqBvZsKgdGhlwqBpbmRpdmlkdWFswqBzZW5kZXIuDQpUaGlzwqBtZXNzYWdl wqBoYXPCoGJlZW7CoHNjYW5uZWTCoGZvcsKgdmlydXNlc8KgYW5kwqBTcGFtwqBiecKgWlRFwqBB bnRpLVNwYW3CoHN5c3RlbS4NCg== From melodysong@huawei.com Tue Mar 10 23:46:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A549F3A6985 for ; Tue, 10 Mar 2009 23:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3cmL7tPhT6s for ; Tue, 10 Mar 2009 23:46:17 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id AC56B3A683F for ; Tue, 10 Mar 2009 23:46:17 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGB00G0HXI1MN@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 14:46:49 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGB00KCMXI1UJ@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 14:46:49 +0800 (CST) Received: from s64081 ([10.164.12.16]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGB00AHAXI0XZ@szxml06-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 14:46:49 +0800 (CST) Date: Wed, 11 Mar 2009 14:46:48 +0800 From: Song Haibin To: 'P2PSIP WG' Message-id: <005601c9a215$26abb550$100ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmiFSZtuUL+qKP/TXqww/o+QPn94g== Subject: [P2PSIP] Error code and its subcode X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2009 06:46:18 -0000 Dear all, As the authors pointed out in section 5.2.1 of diagnostics draft, do we need to define a sub-code field in the Error response? There maybe various causes for some type of Error, with introducing sub-code it is easier for the machine to process while various text is comfortable for a man to read. I'd like to hear the comments in the mailing list and then it will be clear whether we should incorporate that to the diagnostics draft. Best Regards, Haibin Skype: alexsonghw From melodysong@huawei.com Wed Mar 11 00:10:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EAB3A6AA8 for ; Wed, 11 Mar 2009 00:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIVzrY2MVXSN for ; Wed, 11 Mar 2009 00:10:31 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BC87F3A6A34 for ; Wed, 11 Mar 2009 00:10:30 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGB0081AYMGX6@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 15:11:04 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGB00KLOYMGUJ@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 15:11:04 +0800 (CST) Received: from s64081 ([10.164.12.16]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGB00AP0YMFXZ@szxml06-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 15:11:04 +0800 (CST) Date: Wed, 11 Mar 2009 15:11:03 +0800 From: Song Haibin To: 'P2PSIP WG' Message-id: <006201c9a218$8a0d92f0$100ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmiGImkMqp6MEtjSvaoVhgHIMO2Qg== Subject: [P2PSIP] diagnostic information by ALTO? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2009 07:10:32 -0000 Dear all, This email is aimed to start a discussion of whether ALTO can be used to provide the diagnostic information for p2psip diagnostics. But at present, I'm not sure how it works, maybe it can be used to measure the path between two peers or something else. Best Regards, Haibin Skype: alexsonghw From saumitra@qualcomm.com Wed Mar 11 00:39:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C303A691E for ; Wed, 11 Mar 2009 00:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.25 X-Spam-Level: X-Spam-Status: No, score=-105.25 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy33RyVaur0N for ; Wed, 11 Mar 2009 00:39:14 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A04283A6818 for ; Wed, 11 Mar 2009 00:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1236757190; x=1268293190; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20Song=20Haibin=20,=20"'P2PSIP=20 WG'"=20|Date:=20Wed,=2011=20Mar=202009 =2000:39:48=20-0700|Subject:=20RE:=20[P2PSIP]=20diagnosti c=20information=20by=20ALTO?|Thread-Topic:=20[P2PSIP]=20d iagnostic=20information=20by=20ALTO?|Thread-Index:=20Acmi GImkMqp6MEtjSvaoVhgHIMO2QgAA0sIw|Message-ID:=20<2D06DE445 C2ADE44890118C3F449B963401B4854@NASANEXMB12.na.qualcomm.c om>|References:=20<006201c9a218$8a0d92f0$100ca40a@china.h uawei.com>|In-Reply-To:=20<006201c9a218$8a0d92f0$100ca40a @china.huawei.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5549"=3B=20a=3D"16165882"; bh=afi7r/xBXE5ywstamPZImx9v9Er876s7tqaLeDQ+gg4=; b=cKisf+ktREwxCuzF04xuJ8Ns1oWX+TZkQ52ah7pemw/HPfxsP9eDlsQR qXA4B2doICtq6brhlIN3nvZpdOO86U7TgHZ61MqzAoVLeiETG0XbFON1c qMyig4fB83ieylLCv/wqtlCXUKO1zqWdHbX30cLihq0bym1/yR8rdG3az E=; X-IronPort-AV: E=McAfee;i="5300,2777,5549"; a="16165882" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Mar 2009 00:39:50 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2B7dobY013588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Mar 2009 00:39:50 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2B7dnMd015267 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Mar 2009 00:39:49 -0700 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Wed, 11 Mar 2009 00:39:49 -0700 From: "Das, Saumitra" To: Song Haibin , "'P2PSIP WG'" Date: Wed, 11 Mar 2009 00:39:48 -0700 Thread-Topic: [P2PSIP] diagnostic information by ALTO? Thread-Index: AcmiGImkMqp6MEtjSvaoVhgHIMO2QgAA0sIw Message-ID: <2D06DE445C2ADE44890118C3F449B963401B4854@NASANEXMB12.na.qualcomm.com> References: <006201c9a218$8a0d92f0$100ca40a@china.huawei.com> In-Reply-To: <006201c9a218$8a0d92f0$100ca40a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [P2PSIP] diagnostic information by ALTO? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2009 07:39:15 -0000 I would think that this should still be done by p2psip diagnostics. This is= node specific information that is being pulled from the overlay nodes. Suc= h information gathering is not currently in the scope of ALTO afaik. ALTO information provides peer selection guidance and the information about= that guidance may not be available to end applications (e.g. how an ISP ra= nks peers may be based on internal data that is not for public consumption)= . So I do not think that having ALTO information about peers would suffice = for diagnostics. There are definitely diagnostics required in the overlay i= tself to debug problems, make dynamic adjustments to algorithms etc. Best, Saumitra -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Song Haibin Sent: Wednesday, March 11, 2009 12:11 AM To: 'P2PSIP WG' Subject: [P2PSIP] diagnostic information by ALTO? Dear all, This email is aimed to start a discussion of whether ALTO can be used to provide the diagnostic information for p2psip diagnostics. But at present, I'm not sure how it works, maybe it can be used to measure the path between two peers or something else. Best Regards, Haibin Skype: alexsonghw _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From melodysong@huawei.com Wed Mar 11 01:58:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2638A3A6B02 for ; Wed, 11 Mar 2009 01:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj3tcQQN2WzZ for ; Wed, 11 Mar 2009 01:58:50 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 264003A67A1 for ; Wed, 11 Mar 2009 01:58:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGC00EN73KIY2@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 16:57:54 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGC009SK3KHZL@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 16:57:53 +0800 (CST) Received: from s64081 ([10.164.12.16]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGC00CLY3KH7R@szxml06-in.huawei.com> for p2psip@ietf.org; Wed, 11 Mar 2009 16:57:53 +0800 (CST) Date: Wed, 11 Mar 2009 16:57:51 +0800 From: Song Haibin In-reply-to: <2D06DE445C2ADE44890118C3F449B963401B4854@NASANEXMB12.na.qualcomm.com> To: "'Das, Saumitra'" , 'P2PSIP WG' Message-id: <006601c9a227$758933c0$100ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmiGImkMqp6MEtjSvaoVhgHIMO2QgAA0sIwAAJaU/A= Subject: Re: [P2PSIP] diagnostic information by ALTO? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2009 08:58:51 -0000 >-----Original Message----- >From: Das, Saumitra [mailto:saumitra@qualcomm.com] >Sent: Wednesday, March 11, 2009 3:40 PM >To: Song Haibin; 'P2PSIP WG' >Subject: RE: [P2PSIP] diagnostic information by ALTO? > >I would think that this should still be done by p2psip diagnostics. This is node >specific information that is being pulled from the overlay nodes. Such >information gathering is not currently in the scope of ALTO afaik. I agree. If ALTO can provide some kind of node information that can be used for p2psip diagnostics, I think it is meaningful to take it into account and such kind of diagnostic information can be retrieved by peers using p2psip diagnostics method. But IMO most of the node information is dynamic and ALTO has not considered that by this time (or in the near future). >ALTO information provides peer selection guidance and the information about that >guidance may not be available to end applications (e.g. how an ISP ranks peers >may be based on internal data that is not for public consumption). So I do not >think that having ALTO information about peers would suffice for diagnostics. Agree. >There are definitely diagnostics required in the overlay itself to debug >problems, make dynamic adjustments to algorithms etc. > >Best, >Saumitra > >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >Song Haibin >Sent: Wednesday, March 11, 2009 12:11 AM >To: 'P2PSIP WG' >Subject: [P2PSIP] diagnostic information by ALTO? > >Dear all, > >This email is aimed to start a discussion of whether ALTO can be used to >provide the diagnostic information for p2psip diagnostics. But at present, >I'm not sure how it works, maybe it can be used to measure the path between >two peers or something else. > >Best Regards, >Haibin >Skype: alexsonghw > > > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip From davidbryan@gmail.com Wed Mar 11 11:43:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E214D28C17F for ; Wed, 11 Mar 2009 11:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGin5PffWXZy for ; Wed, 11 Mar 2009 11:43:36 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 35F2428C180 for ; Wed, 11 Mar 2009 11:43:24 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so805660ywh.49 for ; Wed, 11 Mar 2009 11:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3pvhbwUcFWP2OYgGUmW9ucHhHdWLG83r9VoFRS0MewM=; b=OyzMmL6SjnpPNCmLkXwJMEIHpDyaCsfMGlIrfj1NZ+ICOnSvO0X6fnse0RCx0OZ7vb TAIGGuCcM4AvMLlbXsHys7odPtsFur/9fjgL9lLi0tOfLg/9pAOGG5k73pM5jALVuYTe bcbnOu+0B/E8st5ElLqp+iKxdBtYUcwiN9pnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=ZKMTRUB/ufhhRrooh3NXCEKFYV6jKKfI0kunmzEt4eAT+ItqRpPLwM7anwyYDkDOR4 E8TVLs7lGDwsWEk8FEyOX9fJYzKd4ZQVrvs+81EDFxAGEGe9ml+zw6y022ar6V6KsUgm 2f/Ti23W07oRe6g7Z0PL7Zxf5l7rrHYuEJ7XU= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.143.28.8 with SMTP id f8mr3807052wfj.204.1236797039784; Wed, 11 Mar 2009 11:43:59 -0700 (PDT) Date: Wed, 11 Mar 2009 14:43:59 -0400 X-Google-Sender-Auth: f39ca36b8bc600ed Message-ID: <8b2769930903111143p14619ddcsabf836b51ac307a6@mail.gmail.com> From: "David A. Bryan" To: "p2psip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Draft Agenda for IETF 74 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2009 18:43:37 -0000 All, Brian and I have discussed the agenda requests (there were many) and have the following draft agenda: Agenda Bash, chairs, :10 Eric Rescorla, draft-ietf-p2psip-base-02, 1:00 Song Haibin, draft-ietf-p2psip-diagnostics-00, :15 Roni Evans, draft-jiang-p2psip-relay-01, :15 Jouni Maenpaa, draft-maenpaa-p2psip-self-tuning-00, :15 Saumitra Das draft-saumitra-p2psip-loadbalance-00, :15 In making the agenda, we weren't able to give time to every draft that requested it -- we only have 2:15. We tried to use the amount (or lack of) list discussion as our criteria for selecting topics. Thanks, David (as chair) From hardie@qualcomm.com Wed Mar 11 11:58:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D131F28C0EB for ; Wed, 11 Mar 2009 11:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.541 X-Spam-Level: X-Spam-Status: No, score=-104.541 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lynhdjUh0OVp for ; Wed, 11 Mar 2009 11:58:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C7D9A3A684C for ; Wed, 11 Mar 2009 11:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1236797955; x=1268333955; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<8b2769930903111143p1461 9ddcsabf836b51ac307a6@mail.gmail.com>|References:=20<8b27 69930903111143p14619ddcsabf836b51ac307a6@mail.gmail.com> |Date:=20Wed,=2011=20Mar=202009=2011:59:10=20-0700|To:=20 "David=20A.=20Bryan"=20,=0D=0A=20=20 =20=20=20=20=20=20"p2psip@ietf.org"=0D=0A=09|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[P2PSIP]=20Draft=20Agenda=20for=20IETF =2074|Content-Type:=20text/plain=3B=20charset=3D"us-ascii "|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5549"=3B =20a=3D"16183635"; bh=ovzS892cWDG5otXFmAyaD38U9FK+xF6ee7bXbBsXi64=; b=DpEMfD1KAZWArSld+Da1u+SH0lOaMoOetgZk5qWHIrezvpoA1qdq7zvA u/QMvjRTVEzjj5hrnp7uX4wpIEaysRrqI54lLnn56PjxsJlkU/Ohlpqdm DsVGdAVHOe2gjHleQZrHKYM+zGsKRThJcU8xx/H0LNHGjl75LzkI/qAln 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5549"; a="16183635" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Mar 2009 11:59:15 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2BIxERn023487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Mar 2009 11:59:15 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2BIxEu2027367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Mar 2009 11:59:14 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 11 Mar 2009 11:59:13 -0700 Received: from [10.227.50.166] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 11:59:12 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <8b2769930903111143p14619ddcsabf836b51ac307a6@mail.gmail.com> References: <8b2769930903111143p14619ddcsabf836b51ac307a6@mail.gmail.com> Date: Wed, 11 Mar 2009 11:59:10 -0700 To: "David A. Bryan" , "p2psip@ietf.org" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [P2PSIP] Draft Agenda for IETF 74 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2009 18:58:39 -0000 At 11:43 AM -0700 3/11/09, David A. Bryan wrote: >All, > >Brian and I have discussed the agenda requests (there were many) and Howdy, As one of those whose questions can be answered outside of meeting time, I would like folks to send me any issues with or suggested updates you'd like to see to draft-hardie-p2psip-p2p-pointers. I'll try to incorporate any that come in; then I'll likely ask for the provisional URI registrations (during the meeting, or just after). As a reminder, here's my text about the update: thanks, Ted >So, I have updated draft-hardie-p2psip-p2p-pointers to 01, eliminating the >MIME type and focusing on the URIs. I would like to ask two questions: > >1) Does anyone object to a request for provisional registration at this point, >so we can start experimenting with these? As a sub bullet, does >anyone have feedback on the IANA registries requested by this doc and >have any objections/input/better ideas? > >2) Is anyone interested in progressing the MIME type work? I took it out >because it seemed to overlap the application/p2p-overlay+xml stuff in >the reload base draft, and I didn't want too much confusion. I think the cases >are distinguishable, but I wasn't sure anyone wanted the pointers to be that >distinct from bootstrap information. If anyone does care, speaking up now would >be handy. > >A short discussion during the meeting would resolve this, but if folks have opinions >now and want to put them onto the mailing list, we can also likely resolve it here. >If we do want to go forward on the URI side now, the next steps would be discussion >on the uri-review and uri mailing lists. > regards, > Ted From licanhuang@zist.edu.cn Sat Mar 14 17:50:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AEF43A6B13 for ; Sat, 14 Mar 2009 17:50:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.119 X-Spam-Level: ** X-Spam-Status: No, score=2.119 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_RECV_IP_FROMIP1=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHXa8NiFPd7y for ; Sat, 14 Mar 2009 17:50:55 -0700 (PDT) Received: from zist.edu.cn (mailgw.zstu.edu.cn [218.108.82.171]) by core3.amsl.com (Postfix) with SMTP id 928643A6839 for ; Sat, 14 Mar 2009 17:50:53 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EYOU-DEALDRC: Received: (eyou anti_spam gateway 3.0); Sun, 15 Mar 2009 08:09:59 +0800 Message-ID: <437075799.23613@zist.edu.cn> X-EYOUMAIL-SMTPAUTH: licanhuang@zstu.edu.cn Received: from 219.82.49.14 by 192.168.101.2 with SMTP; Sun, 15 Mar 2009 08:09:59 +0800 From: "huang lican" To: "'P2PSIP WG'" Date: Sun, 15 Mar 2009 08:52:58 +0800 Message-ID: <000301c9a508$62f032c0$f40015ac@benq44baf9946b> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmiGImkMqp6MEtjSvaoVhgHIMO2QgC7zCAg In-Reply-To: <436752847.06983@zstu.edu.cn> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [P2PSIP] hi X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 15 Mar 2009 00:50:56 -0000 Call paper, The First International Workshop on Semantic P2P Networks (SP2PN 01) (http://virgo.sourceforge.net/SP2PN01.html) In conjunction with 2009 International Conference on New Trends in Information and Service Science (http://www.aicit.org/niss/) NISS 2009: June 30- July 2, 2009 - Beijing, China. Aims and scope Although client/server technology has been successful in many IT fields, it has many shortcomings. P2P technology is now considered as the next generation computing model. The P2P technologies are used in file sharing applications in the beginning to various general-purpose applications today. There are mainly two types of P2P technologies. The unstructured approach routes nodes by a "flooding algorithm". The structured approach is mostly based on Distributed Hash Table (DHT) technologies. However, these two kinds of P2P approaches do not care about the semantic meaning of the nodes. They do not care about the nodes whose users may take different roles in social groups in the communities. This workshop aims to address the need for more research into the theory and applicability of semantic P2P networks. Areas of interest include, but are not limited to, the following: - Search mechanisms and heuristics for computational resources based on semantic P2P network - Service discovery & utilization based on semantic P2P network - Semantic P2P models of deployment and management of Web Services - Semantic P2P storage systems - Semantic computational sharing and cloud computing over P2P networks - Semantic Peer-to-Peer workflow management systems - Overlay self-organization and management - Semantic computational P2P networks - Semantic P2P networks for scientific workflow - Semantic P2P systems related to social science Important dates SP2PN 01; June 30- July 2, 2009, Beijing, China. Deadline for Paper submission: April 7, 2009 Paper acceptance notification: April 17, 2009 Paper submission and publication The papers are limited to 3-4 pages for short paper and 6-8 for full paper, and they must follow the IEEE 8.5"x11" two-column format guidelines described at http://www.computer.org/portal/pages/cscps/cps/cps_forms.html. The papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of expression. For accepted papers, advance registration is required in order to include the final camera ready version in the proceedings which will be published by IEEE Computer Society. And at least one author should be registered in advance and will present the paper in the workshop (Presentation Types: Oral/ Poster/UCC Oral). . The paper has to be submitted via online submission system as the following address: http://www.easychair.org/conferences/?conf=sp2pn01 * Proceedings will be published by IEEE CS series * Selected papers will be fast-track reviewed for special issues in some eminent international journals. 1) Prelimenary Paper Types (for submission and review): - Full paper (6-8 pages) - Short paper (3-4 pages) 2) Final Paper Types (for publishing): For inclusion of the accepted papers into IEEE CS proceedings please follow the guideline*: Full paper ( 6-8 pages) / Short Paper (3-4 pages) Accepted papers' authors will be able to upload the final paper to the IEEE system. International Committee: Dr. Maozhen Li (Brunel University, UK) Prof. Omer F. Rana (Cardiff University, UK) Dr. Xiaodong Wang (STFC, Daresbury Laboratory, UK) Dr. Zhiming Zhao (University of Amsterdam, Netherlands) To be added. Organizers: Prof. Lican Huang (Zhejiang Sci-Tech University, China) Contact Information Dr. Lican Huang (Zhejiang Sci-Tech University, China) Email: huang_lican@yahoo.co.uk Address : Xiasha, Higher Education Zone, hangzhou, 310018 Affiliation : Zhejiang Sci-Tech university From ietf@myfred.net Sun Mar 15 02:35:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEE93A6979 for ; Sun, 15 Mar 2009 02:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXjEqLRZRFaM for ; Sun, 15 Mar 2009 02:35:02 -0700 (PDT) Received: from miro.myfred.net (miro.myfred.net [212.43.80.19]) by core3.amsl.com (Postfix) with ESMTP id 25BF13A695E for ; Sun, 15 Mar 2009 02:35:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by miro.myfred.net (Postfix) with ESMTP id 7ABD2344001 for ; Sun, 15 Mar 2009 10:35:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at miro.myfred.de Received: from miro.myfred.net ([127.0.0.1]) by localhost (miro.myfred.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdpzbxSwz0vc for ; Sun, 15 Mar 2009 10:35:42 +0100 (CET) Received: from kalimera (e180170193.adsl.alicedsl.de [85.180.170.193]) by miro.myfred.net (Postfix) with ESMTPA id 4016A1B0026 for ; Sun, 15 Mar 2009 10:35:42 +0100 (CET) From: =?iso-8859-1?Q?Fr=E9d=E9ric-Philippe_Metz?= To: Date: Sun, 15 Mar 2009 10:35:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-index: AcmlUWsqnXP3wsS8R3CsjAXA4Z4lEg== Message-Id: <20090315093542.4016A1B0026@miro.myfred.net> Subject: [P2PSIP] Question: Security issue resp. RELOAD and SIP usage draft-ietf-p2psip-sip-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 15 Mar 2009 09:35:02 -0000 Hi all, RELOAD with SIP Usage is for setting up a direct connection between = Alice and Bob. Hence SIP traffic flows through RELOAD mechanisms directly from Alice to BoB, right ? Furthermore security mechanisms from RELOAD are = used and no particular SIP-Header extension (i.e. signature) is needed ? Cheers, Fr=E9d=E9ric From bbl@lowekamp.net Sun Mar 15 10:08:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF123A677D for ; Sun, 15 Mar 2009 10:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiXl1bP2+t9M for ; Sun, 15 Mar 2009 10:08:41 -0700 (PDT) Received: from mail-qy0-f108.google.com (mail-qy0-f108.google.com [209.85.221.108]) by core3.amsl.com (Postfix) with ESMTP id CBAB33A6BA1 for ; Sun, 15 Mar 2009 10:08:40 -0700 (PDT) Received: by qyk6 with SMTP id 6so3745050qyk.29 for ; Sun, 15 Mar 2009 10:09:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.74.79 with SMTP id t15mr1604505qcj.2.1237136961380; Sun, 15 Mar 2009 10:09:21 -0700 (PDT) In-Reply-To: <20090315093542.4016A1B0026@miro.myfred.net> References: <20090315093542.4016A1B0026@miro.myfred.net> Date: Sun, 15 Mar 2009 13:09:21 -0400 Message-ID: From: Bruce Lowekamp To: =?UTF-8?B?RnLDqWTDqXJpYy1QaGlsaXBwZSBNZXR6?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP usage draft-ietf-p2psip-sip-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 15 Mar 2009 17:08:42 -0000 RELOAD provides a rendezvous mechanism to use ICE to set up a direct connection between Alice and Bob. But after the initial setup, RELOAD is out of the picture and the actual SIP traffic flows directly between the two SIP UAs without any RELOAD involvement. Bruce On Sun, Mar 15, 2009 at 5:35 AM, Fr=C3=A9d=C3=A9ric-Philippe Metz wrote: > Hi all, > > RELOAD with SIP Usage is for setting up a direct connection between Alice > and Bob. Hence SIP traffic flows through RELOAD mechanisms directly from > Alice to BoB, right ? Furthermore security mechanisms from RELOAD are use= d > and no particular SIP-Header extension (i.e. signature) is needed ? > > Cheers, > =C2=A0 Fr=C3=A9d=C3=A9ric > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From ietf@myfred.net Sun Mar 15 11:36:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8F828C101 for ; Sun, 15 Mar 2009 11:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e5LDbJUfY1u for ; Sun, 15 Mar 2009 11:36:13 -0700 (PDT) Received: from miro.myfred.net (miro.myfred.net [212.43.80.19]) by core3.amsl.com (Postfix) with ESMTP id 3052028C0DD for ; Sun, 15 Mar 2009 11:36:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by miro.myfred.net (Postfix) with ESMTP id EEE8E344001 for ; Sun, 15 Mar 2009 19:36:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at miro.myfred.de Received: from miro.myfred.net ([127.0.0.1]) by localhost (miro.myfred.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdEp5O41cmm9 for ; Sun, 15 Mar 2009 19:36:52 +0100 (CET) Received: from kalimera (e180170193.adsl.alicedsl.de [85.180.170.193]) by miro.myfred.net (Postfix) with ESMTPA id 0554E1B0026 for ; Sun, 15 Mar 2009 19:36:51 +0100 (CET) From: =?iso-8859-1?Q?Fr=E9d=E9ric-Philippe_Metz?= To: Date: Sun, 15 Mar 2009 19:36:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-index: AcmlkMxn7ZQZSN0ETVGx3oNvnZji0QACwQYA In-Reply-To: Message-Id: <20090315183652.0554E1B0026@miro.myfred.net> Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP usage draft-ietf-p2psip-sip-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 15 Mar 2009 18:36:14 -0000 Hi, Since the connection is established end-to-end then without RELOAD, how = can you rely on - as the receiver of i.e. INVITE - that the identity of the = the .. let's say "message elements" such as "From"-Header ... is really the person providing this information ? What I mean is: Then, is there any need of an SIP-header extension = providing the signature of the sending party ? Cheers, Frederic -----Original Message----- From: Bruce Lowekamp [mailto:bbl@lowekamp.net]=20 Sent: Sonntag, 15. M=E4rz 2009 18:09 To: Fr=E9d=E9ric-Philippe Metz Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP = usage draft-ietf-p2psip-sip-00 RELOAD provides a rendezvous mechanism to use ICE to set up a direct connection between Alice and Bob. But after the initial setup, RELOAD is out of the picture and the actual SIP traffic flows directly between the two SIP UAs without any RELOAD involvement. Bruce On Sun, Mar 15, 2009 at 5:35 AM, Fr=E9d=E9ric-Philippe Metz = wrote: > Hi all, > > RELOAD with SIP Usage is for setting up a direct connection between = Alice > and Bob. Hence SIP traffic flows through RELOAD mechanisms directly = from > Alice to BoB, right ? Furthermore security mechanisms from RELOAD are = used > and no particular SIP-Header extension (i.e. signature) is needed ? > > Cheers, > =A0 Fr=E9d=E9ric > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From weigengyu@vip.sina.com Sun Mar 15 18:06:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EC03A6B92 for ; Sun, 15 Mar 2009 18:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.369 X-Spam-Level: X-Spam-Status: No, score=0.369 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vyL3xIJUgRW for ; Sun, 15 Mar 2009 18:06:49 -0700 (PDT) Received: from smtp-6-99.vip.sina.com (mail3-172.sinamail.sina.com.cn [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 779333A6B85 for ; Sun, 15 Mar 2009 18:06:48 -0700 (PDT) Received: from mail5-204.sinamail.sina.com.cn (unknown [10.55.5.204]) by smtp-6-99.vip.sina.com (SINAMAIL) with ESMTP id 5B2EC2863B for ; Mon, 16 Mar 2009 09:07:27 +0800 (CST) X-Auth-ID: weigengyu@vip.sina.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEANMKvUk7QJzW/3poAI14whiCPIFDBg Received: from unknown (HELO ibmPC) ([59.64.156.214]) by mail5-204.sinamail.sina.com.cn with ESMTP; 16 Mar 2009 09:07:09 +0800 Message-ID: From: "Wei Gengyu" To: "Bruce Lowekamp" References: <20090315093542.4016A1B0026@miro.myfred.net> In-Reply-To: Date: Mon, 16 Mar 2009 09:06:54 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP usagedraft-ietf-p2psip-sip-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 01:06:51 -0000 Bruce, If considering the P2PSIP overlay and RELOAD as signalling facilities, some service or resource control are required during communications. In this case, RELOAD might be needed after the initial setup. Regards, Gengyu ----- Original Message ----- From: "Bruce Lowekamp" To: "Frédéric-Philippe Metz" Cc: Sent: Monday, March 16, 2009 1:09 AM Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP usagedraft-ietf-p2psip-sip-00 > RELOAD provides a rendezvous mechanism to use ICE to set up a direct > connection between Alice and Bob. But after the initial setup, RELOAD > is out of the picture and the actual SIP traffic flows directly > between the two SIP UAs without any RELOAD involvement. > > Bruce > From ekr@networkresonance.com Mon Mar 16 09:08:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDBB28C1A1 for ; Mon, 16 Mar 2009 09:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXP9+k3UCRDr for ; Mon, 16 Mar 2009 09:08:15 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3C15328C149 for ; Mon, 16 Mar 2009 09:08:15 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9926950846; Mon, 16 Mar 2009 09:31:51 -0700 (PDT) Date: Mon, 16 Mar 2009 09:31:51 -0700 From: Eric Rescorla To: =?ISO-8859-1?Q?Fr=E9d=E9ric-Philippe?= Metz In-Reply-To: <20090315183652.0554E1B0026@miro.myfred.net> References: <20090315183652.0554E1B0026@miro.myfred.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20090316163151.9926950846@romeo.rtfm.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP usage draft-ietf-p2psip-sip-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 16:08:16 -0000 At Sun, 15 Mar 2009 19:36:56 +0100, Fr=E9d=E9ric-Philippe Metz wrote: >=20 > Hi, >=20 > Since the connection is established end-to-end then without RELOAD, how c= an > you rely on - as the receiver of i.e. INVITE - that the identity of the t= he > .. let's say "message elements" such as "From"-Header ... is really the > person providing this information ? It's carried over a TLS connection, so you should have client auth. -Ekr From ietf@myfred.net Mon Mar 16 10:52:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0241928C183 for ; Mon, 16 Mar 2009 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVzmQMEZMNvu for ; Mon, 16 Mar 2009 10:52:40 -0700 (PDT) Received: from miro.myfred.net (miro.myfred.net [212.43.80.19]) by core3.amsl.com (Postfix) with ESMTP id 2DEC128C16D for ; Mon, 16 Mar 2009 10:52:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by miro.myfred.net (Postfix) with ESMTP id B1428344002; Mon, 16 Mar 2009 18:53:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at miro.myfred.de Received: from miro.myfred.net ([127.0.0.1]) by localhost (miro.myfred.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43+mea54CcWp; Mon, 16 Mar 2009 18:53:20 +0100 (CET) Received: from kalimera (e180149190.adsl.alicedsl.de [85.180.149.190]) by miro.myfred.net (Postfix) with ESMTPA id EA24E344001; Mon, 16 Mar 2009 18:53:19 +0100 (CET) From: =?iso-8859-1?Q?Fr=E9d=E9ric-Philippe_Metz?= To: "'Eric Rescorla'" Date: Mon, 16 Mar 2009 18:52:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 thread-index: AcmmUYkh4e6HL7YmREmsMpTQ7YKgAwADcuNg In-Reply-To: <20090316163151.9926950846@romeo.rtfm.com> Message-Id: <20090316175319.EA24E344001@miro.myfred.net> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP usage draft-ietf-p2psip-sip-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 17:52:41 -0000 Hi, Thanks. This implies that the peers then directly open a tcp connection = and SIP is transported over tls with that connection.=20 UDP in that case can't be used, right ? Within TLS, it may be neccessary to have a CA for certificates as an enrollment server, right ? Best Regards Fr=E9d=E9ric -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Montag, 16. M=E4rz 2009 17:32 To: Fr=E9d=E9ric-Philippe Metz Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP = usage draft-ietf-p2psip-sip-00 At Sun, 15 Mar 2009 19:36:56 +0100, Fr=E9d=E9ric-Philippe Metz wrote: >=20 > Hi, >=20 > Since the connection is established end-to-end then without RELOAD, = how can > you rely on - as the receiver of i.e. INVITE - that the identity of = the the > .. let's say "message elements" such as "From"-Header ... is really = the > person providing this information ? It's carried over a TLS connection, so you should have client auth. -Ekr From sa2086@columbia.edu Mon Mar 16 12:35:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFFB3A6B1C for ; Mon, 16 Mar 2009 12:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6svKMIJuyZz for ; Mon, 16 Mar 2009 12:35:30 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 98B4C3A6855 for ; Mon, 16 Mar 2009 12:35:30 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2GJaBwT021758 for ; Mon, 16 Mar 2009 15:36:11 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2GJaBYj010786 for ; Mon, 16 Mar 2009 15:36:11 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2GJaB65010783 for ; Mon, 16 Mar 2009 15:36:11 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Mon, 16 Mar 2009 15:36:11 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: "p2psip@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 19:35:31 -0000 I have tried to summarize the solution space for addressing fragmentation, congestion control and reliability issues when using an unreliable transport. This includes the proposal by Bruce. I think that the WG needs to contrast their complexity with the use of a reliable transport (TCP), and consider whether to specify these mechanisms in a separate document or the base document. Fragmentation ------------- *Hop-by-hop fragmentation, hop-by-hop complete reassembly *Hop-by-hop fragmentation and end-to-end reassembly -When RELOAD header exceeds MTU --> do IP fragmentation -When RELOAD header does not exceed MTU --> do RELOAD fragmentation Congestion control and hop-by-hop reliability of a message fragment ------------------ *Stop-and-wait -send a packet and wait for a response before transmitting next packet. -retransmit lost packets at RTO. -introduce gap of 10ms btw packet transmissions. *AIMD-like -transmit packets as permitted by a congestion window. -No slow start, fast retransmit, or recovery. -always in congestion avoidance, at every loss, reduce window by half. -retransmit at RTO if permitted by congestion window. *TFRC -TFRC for congestion control -retransmission at RTO intervals -needs careful consideration whether TFRC can be implemented using existing message parameters. (The above methods require RTO estimation with some caveats. See Bruce's email: http://www.ietf.org/mail-archive/web/p2psip/current/msg04697.html) *Use TCP -use TCP if expecting fragmentation, otherwise use UDP -issue: TCP may not work behind some NATs for setting up direct connections, however: --UDP may also be blocked by firewalls-- --and nodes behind restrictive NATs can act as clients. -salman From davidbryan@gmail.com Mon Mar 16 13:29:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163A228C1FB for ; Mon, 16 Mar 2009 13:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17aibGDh6F3F for ; Mon, 16 Mar 2009 13:29:05 -0700 (PDT) Received: from mail-gx0-f165.google.com (mail-gx0-f165.google.com [209.85.217.165]) by core3.amsl.com (Postfix) with ESMTP id 8C2983A6987 for ; Mon, 16 Mar 2009 13:29:05 -0700 (PDT) Received: by gxk9 with SMTP id 9so2197692gxk.13 for ; Mon, 16 Mar 2009 13:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=GHUAVL4g2ECRLv3O9b1VQQ4qjTYO29kd4HFq88hIHOw=; b=mruXBzl7NE0FXZjh+I4GZ76OyjoTQWIX6u4x8Y8C8izEYAA8f+oaN6GC4jwTPkV8Js kKFC1ldlFyn4u6DBk5HqLcXmH3LMBhKHIAPGwrEqPH5VOCskELrkJD9xAoGny5RrdEJ6 tj3IwmBurgA1CrNC+6OuDwscxnbybkz0e5/jk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=V4/nKhWllCOHIaUYmQQIKibTprFhmIZ9CTrCeuwlBwaUrZbvco598Do0Ymm9lIWkJ7 M7/zmP4QEz+smYrrHioISl6baxpyUCRs9j4/RA4S1bC3JuzJXej3WtvXD9+AOU7Xqdg4 oJNtn6hlDHj2CvHCenawkZS10HFjX/c47YvsE= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.142.141.21 with SMTP id o21mr2308961wfd.79.1237235387125; Mon, 16 Mar 2009 13:29:47 -0700 (PDT) In-Reply-To: <01b601c99bc9$0536a990$100ca40a@china.huawei.com> References: <72FB0F54-0357-4D72-8E74-EFC94E874379@cisco.com> <01b601c99bc9$0536a990$100ca40a@china.huawei.com> Date: Mon, 16 Mar 2009 16:29:47 -0400 X-Google-Sender-Auth: 9c5fb7ba75e12de5 Message-ID: <8b2769930903161329y6970808ekf892b9594ee79c06@mail.gmail.com> From: "David A. Bryan" To: Song Haibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 20:29:07 -0000 So I wanted to pick back up on this thread since it didn't go too far, but I think this is a very important area. I think that the diagnostic mechanisms are something we really need to have, and I have been re-reading and think that the work in the diagnostic draft is the right direction, so I wanted to get a bit more discussion going on this item before the meeting, hoping that we can resolve this and have a good path for the authors on the diagnostics draft to go forward with for a new version coming out of San Francisco. For those of you who aren't familiar, the basic idea is that you want some mechanism to be able to collect diagnostic information from each peer that comprises a path through the overlay, in order to be able to diagnose any problems that may exist in that path/evaluate the peers/etc., so there is a problem that you really do want information from each peer along the path. Cullen's concern here is with the mechanism described in 4 (1) of the draft: ECHO message being sent out, and getting back a response from each peer along the path. You have something like this: a->b->c->d->e but generate responses at each hop: b->a c->a d->a e->a Hence a ddos risk if I send out a bunch of messages randomly and claim they are all from a...(understanding that other mechanisms in RELOAD may prevent that of course) The alternative in 4 (2) is an iterative mechanism: a->b b->a (and suggests c) a->c c->a (and suggests d) a->d d->a (and suggest e) e->a In the draft, the suggestion is that 4 (1) may be appropriate in a managed network. I think that we would want to clarify the definition of managed network, for example perhaps these type of requests are only valid when signed by a? This may still be problematic (I can no longer dos someone else, but I may be able to generate a lot of unneeded traffic, which still could severely compromise the overlay) in terms of generating lots of traffic. Perhaps even a stronger requirement that the signer be an admin of some sort (although now determining who is an admin and the mechanisms for deciding that a message is signed by the admin crop up -- this starts to be in BCP land) 4 (2), using the recursive mechanism eliminates the specific issue I think Cullen brought up, but of course opens the problems of NAT traversal. Another idea that struck me (rather complex timer issues make it rather ugly) was to have the request go out using standard symmetric recursive routing, with each peer appending information as it returns. There is a timer issue here in that if the message fails on some leg, the last one to send it needs to send back a response anyway. In otherwords if the path should have been: a->b->c->d->e->d->c->b->a but d is dead, you still need that as diagnostic information, and need something like: a->b->c->XXX ...some time passes... c(w/XXX)->b->a The timers there look ugly (a is likely to time out first, not c, and if c times out last and sends, how do we prevent this turning into recursive (i.e., b fails and sends back, then c fails and sends, etc), and also the messages could be very large for large path lengths (good thing we are talking about fragmentation now :) ) I don't have a particular solution I think makes sense here, and it may be that we want to offer each as a mechanism. However, I think that having something like what is in the diagnostics draft is essential, but I read Cullen's email and he certainly has some valid ddos issues with the echo approach. I wanted to share my thoughts and see if we could get some list discussion here to try to get this one ironed out... David (as individual) On Tue, Mar 3, 2009 at 2:26 AM, Song Haibin wrote: > Dear Cullen, > > You have the same concern with Bruce and Henning. The authors do not think > this method is broadly suitable for the diagnostics in the open Internet > environment either. However, it may be used in some administrative p2p > overlays. The usage of Echo method is limited to certain application > scenarios. > > As we said in the draft: "An Echo request message is used to retrieve the > diagnostic information of the specified path in administrative p2p overlays > where all the peers in the overlay are trusted or based on specific > authorization. For example, it can be used in a p2p overlay where all peers > deployed by the operator to provide services to the customers (clients), > where the diagnostics happens between peers in the p2p overlay. For the > untrusted p2p overlays, e.g. some end user equipments can be the peers in > the overlay network, then the Echo method must be used with care for the > consideration of potential DoS attack. Compared with Path_Track method, > Echo method brings less messages to the p2p overlay network." > > > Best Regards, > Haibin > Skype: alexsonghw > > >>-----Original Message----- >>From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >>Cullen Jennings >>Sent: Tuesday, March 03, 2009 5:23 AM >>To: P2PSIP WG >>Subject: [P2PSIP] Comment on p2psip-diagnostics >> >> >>One comment on the Echo design.... I'm worried about a method where >>sending a single request can cause a whole bunch of responses. This >>has congestion and DOS issues. It is also not clear how all the >>retransmissions timers would work with it. >> >>We should think about if it is possible to move away from the one >>request, multiple responses design. >> >>Cullen >> >> >> >> >>_______________________________________________ >>P2PSIP mailing list >>P2PSIP@ietf.org >>https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From hsinnrei@adobe.com Mon Mar 16 14:02:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D1C3A6C10 for ; Mon, 16 Mar 2009 14:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g6tJUf-wgTK for ; Mon, 16 Mar 2009 14:02:06 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by core3.amsl.com (Postfix) with ESMTP id F1CE53A688B for ; Mon, 16 Mar 2009 14:02:05 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKSb6+c3HHzWZczjIBBzBhO1I79dNYLFrh@postini.com; Mon, 16 Mar 2009 14:02:48 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n2GKvEeM023504; Mon, 16 Mar 2009 13:57:15 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n2GL2dY2009000; Mon, 16 Mar 2009 14:02:39 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 16 Mar 2009 14:02:38 -0700 From: Henry Sinnreich To: "David A. Bryan" , Song Haibin Date: Mon, 16 Mar 2009 14:02:36 -0700 Thread-Topic: [P2PSIP] Comment on p2psip-diagnostics Thread-Index: Acmmdfdj4bnaNMtATfaUtfBBOihVlgABJDtn Message-ID: In-Reply-To: <8b2769930903161329y6970808ekf892b9594ee79c06@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5E4289CC4EChsinnreiadobecom_" MIME-Version: 1.0 Cc: P2PSIP WG Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 21:02:09 -0000 --_000_C5E4289CC4EChsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >I think that we would want to clarify the definition >of managed network I fully agree, since some na=EFve folks out there (including me) think that= : 1. p2p is self organizing - not managed - unless fixing node software is = called management. 2. p2p works across the Internet and crosses many ISP networks, several = times even for any one ISP. The p2p operator may not even be in friendly re= lations with some the ISPs and compete with them. Item 2. has prevented me to understand how in the world ALTO may work, but = that's another story. Note: I contributed to some of the diagnostic scenarios, but not anything a= bout management of p2p. Henry On 3/16/09 3:29 PM, "David A. Bryan" wrote: I think that we would want to clarify the definition of managed network --_000_C5E4289CC4EChsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] Comment on p2psip-diagnostics >I think that we would want to clarify the definition
>of managed network

I fully agree, since some naïve folks out there (including me) think t= hat:

  1. p2p is self organizing – not managed R= 11; unless fixing node software is called management.
  2. p2p works across the Internet and crosses many ISP = networks,  several times even for any one ISP. The p2p operator may no= t even be in friendly relations with some the ISPs and compete with them.

Item 2. has prevented me to understand how in the world ALTO may work, but = that’s another story.

Note: I contributed to some of the diagnostic scenarios, but not anything a= bout management of p2p.

Henry


On 3/16/09 3:29 PM, "David A. Bryan" <dbryan@ethernot.org> wrote:

I think that we would want to clarify the d= efinition
of managed network
--_000_C5E4289CC4EChsinnreiadobecom_-- From davidbryan@gmail.com Mon Mar 16 14:16:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D295D3A68ED for ; Mon, 16 Mar 2009 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMic+ifAPASW for ; Mon, 16 Mar 2009 14:16:15 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 1591C3A6829 for ; Mon, 16 Mar 2009 14:16:15 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3391074wfd.31 for ; Mon, 16 Mar 2009 14:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=LvVn/uUl9O/OifEvHuRRjT6Bej6gy+f3xHNMPPwpZOg=; b=FZuIKLmtVYcB4kqvow7Yaa9lG2clc3AYiwISPVR0FWamV8LEt+FBhD1sC+XSl0Rq4Q j+EKloBfOWdjEowI8LlCrEqgFSK08YgeiRBS9AxWgS51McGsqKgiVAG0sU+njKcmUgzK 9V4I7S3H36/ymSYnOcQO0LA3QcV/qgwC0zXwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MBnxdmS4qqXIAkzBXXOSPUK5w6q4soPEx00PpW8TuZMBu0Brts+If9qwc116elHSHV 43L9jC8SfiyTHkYWj7FgtDq2VFSTSUCS8IbpBww/Rt3rUN9x8k1gd78ozW2pRTZSGL+W Yzymw4xX9sL10asxsZZntcQrP5CfBDjPIn6ZY= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.142.13.13 with SMTP id 13mr367860wfm.150.1237238217314; Mon, 16 Mar 2009 14:16:57 -0700 (PDT) In-Reply-To: References: <8b2769930903161329y6970808ekf892b9594ee79c06@mail.gmail.com> Date: Mon, 16 Mar 2009 17:16:57 -0400 X-Google-Sender-Auth: 8dac4aecdd5d8788 Message-ID: <8b2769930903161416o2ba1075br996bd8d5bda642ed@mail.gmail.com> From: "David A. Bryan" To: Henry Sinnreich Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 21:16:15 -0000 Hi Henry: I think there are many possible levels of "management" here from central to none. In the case I was talking about in this email, I'm think the authors were talking about a system where there is a central manager and they are using a mechanism (certificates?) to limit who can join, who can manage etc.. It may even not go outside a particular provider or enterprise. Obviously many of us (myself included) want to see some nice open P2P network out there, but I am quite certain there will be managed uses of this technology as well, and I think we are better off considering them, and providing mechanisms that are standardized that recognize they will exist than pretending they don't, and having non-standard implementations, so I think it makes sense that the authors are considering that. Obviously there are many case like what you describe, where the system will span the internet and have no admin, and I think we need a diagnostic package that works for those, so it is very important to find an approach that allows one to diagnose a network just as you describe -- one that is open, and self organized. That is actually the harder part of this problem, and the one I want to discuss. We don't want to take the easy way out and only design for managed either. Thanks for reminding us! David On Mon, Mar 16, 2009 at 5:02 PM, Henry Sinnreich wrote= : >>I think that we would want to clarify the definition >>of managed network > > I fully agree, since some na=EFve folks out there (including me) think th= at: > > p2p is self organizing =96 not managed =96 unless fixing node software is= called > management. > p2p works across the Internet and crosses many ISP networks, several tim= es > even for any one ISP. The p2p operator may not even be in friendly relati= ons > with some the ISPs and compete with them. > > Item 2. has prevented me to understand how in the world ALTO may work, bu= t > that=92s another story. > > Note: I contributed to some of the diagnostic scenarios, but not anything > about management of p2p. > > Henry > > > On 3/16/09 3:29 PM, "David A. Bryan" wrote: > > I think that we would want to clarify the definition > of managed network > From hgs@cs.columbia.edu Mon Mar 16 14:31:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56D63A68C7 for ; Mon, 16 Mar 2009 14:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkGn3OBjqlKi for ; Mon, 16 Mar 2009 14:31:47 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id B15F33A6C0D for ; Mon, 16 Mar 2009 14:31:47 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2GLWSMU021757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Mar 2009 17:32:28 -0400 (EDT) Message-Id: <199F45E9-2B61-4FC2-B490-518762D63C5B@cs.columbia.edu> From: Henning Schulzrinne To: Salman Abdul Baset In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Mar 2009 17:32:28 -0400 References: X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2009 21:31:48 -0000 Another related option: Use TCP-tunneled-over-UDP for those cases where "native" TCP fails. There are plenty of UDP tunneling protocols around to choose from, so the amount of stuff to be invented or standardized may be relatively small. On Mar 16, 2009, at 3:36 PM, Salman Abdul Baset wrote: > I have tried to summarize the solution space for addressing > fragmentation, congestion control and reliability issues when using > an unreliable transport. This includes the proposal by Bruce. I > think that the WG needs to contrast their complexity with the use of > a reliable transport (TCP), and consider whether to specify these > mechanisms in a separate document or the base document. > > > > Fragmentation > ------------- > > *Hop-by-hop fragmentation, hop-by-hop complete reassembly > > *Hop-by-hop fragmentation and end-to-end reassembly > -When RELOAD header exceeds MTU --> do IP fragmentation > -When RELOAD header does not exceed MTU --> do RELOAD fragmentation > > > Congestion control and hop-by-hop reliability of a message fragment > ------------------ > > *Stop-and-wait > -send a packet and wait for a response before transmitting next > packet. > -retransmit lost packets at RTO. > -introduce gap of 10ms btw packet transmissions. > > *AIMD-like > -transmit packets as permitted by a congestion window. > -No slow start, fast retransmit, or recovery. > -always in congestion avoidance, at every loss, reduce window by half. > -retransmit at RTO if permitted by congestion window. > > *TFRC > -TFRC for congestion control > -retransmission at RTO intervals > -needs careful consideration whether TFRC can be implemented using > existing message parameters. > > (The above methods require RTO estimation with some caveats. See > Bruce's email: > http://www.ietf.org/mail-archive/web/p2psip/current/msg04697.html) > > *Use TCP > -use TCP if expecting fragmentation, otherwise use UDP > -issue: TCP may not work behind some NATs for setting up > direct connections, however: > --UDP may also be blocked by firewalls-- > --and nodes behind restrictive NATs can act as clients. > > > -salman > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From ekr@networkresonance.com Mon Mar 16 21:28:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFCF3A68C5 for ; Mon, 16 Mar 2009 21:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrRGnq86EV9J for ; Mon, 16 Mar 2009 21:28:55 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 91E703A6895 for ; Mon, 16 Mar 2009 21:28:55 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B2A2750846; Mon, 16 Mar 2009 21:52:32 -0700 (PDT) Date: Mon, 16 Mar 2009 21:52:32 -0700 From: Eric Rescorla To: =?ISO-8859-1?Q?Fr=E9d=E9ric-Philippe?= Metz In-Reply-To: <20090316175319.EA24E344001@miro.myfred.net> References: <20090316163151.9926950846@romeo.rtfm.com> <20090316175319.EA24E344001@miro.myfred.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20090317045232.B2A2750846@romeo.rtfm.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question: Security issue resp. RELOAD and SIP usage draft-ietf-p2psip-sip-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 17 Mar 2009 04:28:56 -0000 At Mon, 16 Mar 2009 18:52:49 +0100, Fr=E9d=E9ric-Philippe Metz wrote: >=20 > Hi, >=20 > Thanks. This implies that the peers then directly open a tcp connection a= nd > SIP is transported over tls with that connection.=20 >=20 > UDP in that case can't be used, right ? With DTLS. > Within TLS, it may be neccessary to have a CA for certificates as an > enrollment server, right ? This is a general property of RELOAD. -Ekr From bbl@lowekamp.net Tue Mar 17 03:24:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93943A68D1 for ; Tue, 17 Mar 2009 03:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijkQ5Soz55op for ; Tue, 17 Mar 2009 03:24:50 -0700 (PDT) Received: from mail-qy0-f108.google.com (mail-qy0-f108.google.com [209.85.221.108]) by core3.amsl.com (Postfix) with ESMTP id E5E7E3A67DA for ; Tue, 17 Mar 2009 03:24:49 -0700 (PDT) Received: by qyk6 with SMTP id 6so4600526qyk.29 for ; Tue, 17 Mar 2009 03:25:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.100.5 with SMTP id w5mr2205454qcn.100.1237285532315; Tue, 17 Mar 2009 03:25:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Mar 2009 06:25:32 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 17 Mar 2009 10:24:50 -0000 Salman, Unfortunately, the conversation is dominated by the need to work in the real Internet, where the dominant situation is that UDP will work and TCP won't. We do have the advantage that we don't have to match TCP in performance, although the exact requirement will of course vary by the particular deployment. Also, a TCP overlay link will also need to estimate RTO to determine when the link has failed. Bruce On Mon, Mar 16, 2009 at 3:36 PM, Salman Abdul Baset w= rote: > I have tried to summarize the solution space for addressing fragmentation= , > congestion control and reliability issues when using an unreliable > transport. This includes the proposal by Bruce. I think that the WG needs= to > contrast their complexity with the use of a reliable transport (TCP), and > consider whether to specify these mechanisms in a separate document or th= e > base document. > > > > Fragmentation > ------------- > > *Hop-by-hop fragmentation, hop-by-hop complete reassembly > > *Hop-by-hop fragmentation and end-to-end reassembly > =C2=A0-When RELOAD header exceeds MTU --> do IP fragmentation > =C2=A0-When RELOAD header does not exceed MTU --> do RELOAD fragmentation > > > Congestion control and hop-by-hop reliability of a message fragment > ------------------ > > *Stop-and-wait > =C2=A0-send a packet and wait for a response before transmitting next pac= ket. > =C2=A0-retransmit lost packets at RTO. > =C2=A0-introduce gap of 10ms btw packet transmissions. > > *AIMD-like > =C2=A0-transmit packets as permitted by a congestion window. > =C2=A0-No slow start, fast retransmit, or recovery. > =C2=A0-always in congestion avoidance, at every loss, reduce window by ha= lf. > =C2=A0-retransmit at RTO if permitted by congestion window. > > *TFRC > =C2=A0-TFRC for congestion control > =C2=A0-retransmission at RTO intervals > =C2=A0-needs careful consideration whether TFRC can be implemented using > =C2=A0existing message parameters. > > (The above methods require RTO estimation with some caveats. See Bruce's > email: > http://www.ietf.org/mail-archive/web/p2psip/current/msg04697.html) > > *Use TCP > =C2=A0-use TCP if expecting fragmentation, otherwise use UDP > =C2=A0-issue: TCP may not work behind some NATs for setting up > =C2=A0direct connections, however: > =C2=A0--UDP may also be blocked by firewalls-- > =C2=A0--and nodes behind restrictive NATs can act as clients. > > > -salman > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From bbl@lowekamp.net Tue Mar 17 03:25:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0EE3A684C for ; Tue, 17 Mar 2009 03:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOP6MIVJN3PK for ; Tue, 17 Mar 2009 03:25:50 -0700 (PDT) Received: from mail-qy0-f108.google.com (mail-qy0-f108.google.com [209.85.221.108]) by core3.amsl.com (Postfix) with ESMTP id CC08B3A6A1A for ; Tue, 17 Mar 2009 03:25:49 -0700 (PDT) Received: by qyk6 with SMTP id 6so4600690qyk.29 for ; Tue, 17 Mar 2009 03:26:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.98.195 with SMTP id r3mr2520567qcn.88.1237285592464; Tue, 17 Mar 2009 03:26:32 -0700 (PDT) In-Reply-To: <199F45E9-2B61-4FC2-B490-518762D63C5B@cs.columbia.edu> References: <199F45E9-2B61-4FC2-B490-518762D63C5B@cs.columbia.edu> Date: Tue, 17 Mar 2009 06:26:32 -0400 Message-ID: From: Bruce Lowekamp To: Henning Schulzrinne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 17 Mar 2009 10:25:50 -0000 Henning, I agree. My recollection is that TSV wasn't too fond of this idea the last time it came up at an area meeting, so I wouldn't expect it to happen quickly, but maybe I'm wrong. Would certainly be an easy drop-in if it were available. Bruce On Mon, Mar 16, 2009 at 5:32 PM, Henning Schulzrinne wrote: > Another related option: Use TCP-tunneled-over-UDP for those cases where > "native" TCP fails. There are plenty of UDP tunneling protocols around to > choose from, so the amount of stuff to be invented or standardized may be > relatively small. > > On Mar 16, 2009, at 3:36 PM, Salman Abdul Baset wrote: > >> I have tried to summarize the solution space for addressing fragmentatio= n, >> congestion control and reliability issues when using an unreliable >> transport. This includes the proposal by Bruce. I think that the WG need= s to >> contrast their complexity with the use of a reliable transport (TCP), an= d >> consider whether to specify these mechanisms in a separate document or t= he >> base document. >> >> >> >> Fragmentation >> ------------- >> >> *Hop-by-hop fragmentation, hop-by-hop complete reassembly >> >> *Hop-by-hop fragmentation and end-to-end reassembly >> =C2=A0-When RELOAD header exceeds MTU --> do IP fragmentation >> =C2=A0-When RELOAD header does not exceed MTU --> do RELOAD fragmentatio= n >> >> >> Congestion control and hop-by-hop reliability of a message fragment >> ------------------ >> >> *Stop-and-wait >> -send a packet and wait for a response before transmitting next packet. >> -retransmit lost packets at RTO. >> -introduce gap of 10ms btw packet transmissions. >> >> *AIMD-like >> -transmit packets as permitted by a congestion window. >> -No slow start, fast retransmit, or recovery. >> -always in congestion avoidance, at every loss, reduce window by half. >> -retransmit at RTO if permitted by congestion window. >> >> *TFRC >> -TFRC for congestion control >> -retransmission at RTO intervals >> -needs careful consideration whether TFRC can be implemented using >> =C2=A0existing message parameters. >> >> (The above methods require RTO estimation with some caveats. See Bruce's >> email: >> http://www.ietf.org/mail-archive/web/p2psip/current/msg04697.html) >> >> *Use TCP >> -use TCP if expecting fragmentation, otherwise use UDP >> -issue: TCP may not work behind some NATs for setting up >> =C2=A0direct connections, however: >> =C2=A0--UDP may also be blocked by firewalls-- >> =C2=A0--and nodes behind restrictive NATs can act as clients. >> >> >> -salman >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From hgs@cs.columbia.edu Tue Mar 17 05:09:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03133A6971 for ; Tue, 17 Mar 2009 05:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfvg341Kyj71 for ; Tue, 17 Mar 2009 05:09:59 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 1C3163A6893 for ; Tue, 17 Mar 2009 05:09:59 -0700 (PDT) Received: from Upstairs.home (pool-98-109-204-63.nwrknj.fios.verizon.net [98.109.204.63]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2HCAe8d018200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Mar 2009 08:10:40 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Mar 2009 08:10:40 -0400 References: X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 17 Mar 2009 12:10:00 -0000 On Mar 17, 2009, at 6:25 AM, Bruce Lowekamp wrote: > Salman, > > Unfortunately, the conversation is dominated by the need to work in > the real Internet, where the dominant situation is that UDP will work > and TCP won't. I'm curious: Is there data indicating the problem? I've heard of problems with *inbound* connections via NATs, but the likelihood that outbound TCP from behind a NAT doesn't work seems low, given that this would essentially kill all consumer applications, from shiny web 2.0 to dusty IMAP. Henning From zongning@huawei.com Tue Mar 17 17:54:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372143A681D for ; Tue, 17 Mar 2009 17:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.195 X-Spam-Level: X-Spam-Status: No, score=-90.195 tagged_above=-999 required=5 tests=[AWL=-2.558, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6, MANGLED_EMAIL=2.3, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+XRwxYvW+0r for ; Tue, 17 Mar 2009 17:54:26 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2576E3A6822 for ; Tue, 17 Mar 2009 17:54:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGO00D54FVVV5@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 18 Mar 2009 08:55:08 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGO00BCYFVV33@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 18 Mar 2009 08:55:07 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.81]) by szxmc04-in.huawei.com (mshttpd); Wed, 18 Mar 2009 08:55:07 +0800 Date: Wed, 18 Mar 2009 08:55:07 +0800 From: zongning 63316 To: p2psip@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_CXAE3vn2rEMWVE514XFN0g)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [P2PSIP] =?gb2312?b?16q3oiA6W2FsdG9dIEZ3OiBbcHBzcF0gcHBzcChwZWVy?= =?gb2312?b?IHRvIHBlZXIgc3RyZWFtaW5nIHByb3RvY29sKSBiYXIgYm9mCWFnZW5kYQ==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 00:54:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CXAE3vn2rEMWVE514XFN0g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or em ail immediately and delete it! ***************************************************************************************** --Boundary_(ID_CXAE3vn2rEMWVE514XFN0g) Content-type: message/rfc822 Content-disposition: inline Return-path: Received: from huawei.com ([172.24.2.9]) by szxmc04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGM00L9RZN6WD@szxmc04-in.huawei.com> for zongning@huawei.com; Tue, 17 Mar 2009 14:06:42 +0800 (CST) Received: from szxga03-in (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGM009BJZKVLN@szxga03-in.huawei.com> for zongning@huawei.com; Tue, 17 Mar 2009 14:06:42 +0800 (CST) Received: from szxrg01-in.huawei.com ([172.24.1.38]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGM0044KZKNM4@szxga03-in.huawei.com> for zongning@huawei.com (ORCPT zongning@huawei.com); Tue, 17 Mar 2009 14:05:11 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by szxrg01-in.huawei.com (MOS 3.8.4-GA) id CKY06149; Tue, 17 Mar 2009 14:05:11 +0800 (CST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by szxrg01-in.huawei.com (MOS 3.8.4-GA) with ESMTP id CKY06112; Tue, 17 Mar 2009 14:05:05 +0800 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770ED3A6827; Mon, 16 Mar 2009 23:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995A83A67DD for ; Mon, 16 Mar 2009 23:04:18 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQrd8cUl-VM2 for ; Mon, 16 Mar 2009 23:04:17 -0700 (PDT) Received: from cmccmta (unknown [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 0E36F3A6452 for ; Mon, 16 Mar 2009 23:03:45 -0700 (PDT) Received: from LENOVO-917FFE55 ([10.1.4.31]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009031714042504-8593 ; Tue, 17 Mar 2009 14:04:25 +0800 Date: Tue, 17 Mar 2009 14:04:16 +0800 From: Yunfei Zhang Subject: [alto] Fw: [ppsp] ppsp(peer to peer streaming protocol) bar bof agenda Sender: alto-bounces@ietf.org To: alto Errors-to: alto-bounces@ietf.org Message-id: <200903171404157507460@chinamobile.com> Organization: China Mobile,R&D MIME-version: 1.0 X-Mailer: Foxmail 6, 2, 103, 20 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-03-17 14:04:25, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-03-17 14:04:29, Serialize complete at 2009-03-17 14:04:29 Precedence: list X-BeenThere: alto@ietf.org Delivered-to: alto@core3.amsl.com X-Original-To: alto@core3.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.92 X-Spam-Status: No, score=-92.92 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] X-Junkmail-Whitelist: YES (by domain whitelist at szxrg01-in.huawei.com) X-Mirapoint-Loop-Id: b32150cf38461454a021da6163bfad3e X-Mailman-Version: 2.1.9 List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" Original-recipient: rfc822;@szxmc04-in.huawei.com:zongning@huawei.com SGksYWxsLA0KICAgVGhlIHByaW1hcnkgUFBTUChwMnAgc3RyZWFtaW5nIHByb3RvY29sKSBiYXIg Ym9mIGFnZW5kYSBpcyBhcyBmb2xsb3dzLkFueSBzdWdnZXN0aW9ucyBhbmQgY29udHJpYnV0aW9u cyBhcmUgd2VsY29tZS4NCiAgIA0KUFBTUCBCYXIgQm9GLS0gSUVURiA3NCwgU2FuIEZyYW5jaXNj bw0KICAyMDAwLTIyMDAgTW9uZGF5LE1hcmNoIDIzLENvbnRpbmVudGFsIDMuIA0KICBNYWlsaW5n IGxpc3SjunBwc3BAaWV0Zi5vcmcgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bwc3ANCiANCkFnZW5kYQ0KLSBJbnRyb2R1Y3Rpb24gICAgICAgICAgICAgICAgICAgICAgKFl1 bmZlaSBaaGFuZyw1MCcpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCi0gUHJvYmxlbSBTdGF0ZW1l bnQgICAgICAgICAgICAgICAgIChZdW5mZWkgWmhhbmcsIDUwJykNCiAgZHJhZnQtemhhbmctcHBz cC1wcm9ibGVtIHN0YXRlbWVudC0wMShodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC16aGFuZy1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dCkNCi0gUHJvdG9jb2wg UmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKE5pbmcgWm9uZywg MzUnKQ0KICBkcmFmdC16b25nLXBwc3AtcmVxcy0wMChodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC16b25nLXBwc3AtcmVxcy0wMC50eHQpDQoNCi0gUHJvdG9jb2wgQW5h bHlzaXMgb2YgUFBsaXZlIGFuZCBQUFN0cmVhbSBieSBJbnRlcmVudCBNZWFzdXJlbWVudCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKFl1bmZlaSBaaGFuZywx NScpDQogIGRyYWZ0LXpoYW5nLXBwc3AtcHJvdG9jb2wtY29tcGFyaXNvbi1tZWFzdXJlbWVudC0w MChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1wcHNwLXBy b3RvY29sLWNvbXBhcmlzb24tbWVhc3VyZW1lbnQtMDAudHh0KQ0KIA0KLSBJbnRyb2R1Y3Rpb24g b2YgRGlzdHJpYnV0ZWQgU2VydmljZXMgTmV0d29yaywgYSB2aXNpb24gb2YgbWFraW5nIFBQU1Ag YW5kIFAyUFNJUCBpbnRvIHJlYWxpdHkgICAgICAgICAgKFl1bmZlaSBaaGFuZywgMTUnKQ0KICBk cmFmdC16aGFuZy1wcHNwLWRzbi1pbnRyb2R1Y3Rpb24tMDAoaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctcHBzcC1kc24taW50cm9kdWN0aW9uLTAwLnR4dCkN Cg0KDQogCaGhICAgICANCiAgICAgICANCiAgICAgICAgIA0KDQogIEJlc3QgcmVnYXJkcyENCiAg U2luY2VyZWx5IHlvdXJzLA0KICAgICAgWXVuZmVpIA0KICAgICAgIDIwMDktMDMtMTcNCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCll1bmZl aSBaaGFuZywgUGguRC4NCg0KUiZELCBDSElOQSBNT0JJTEUgQ09NTVVOSUNBVElPTlMgQ09SUE9S QVRJT04NCg0KVGVsOiArODYgMTAgMTU4MDE2OTY2Njg4IGV4dC4gMzI0Nw0KDQpGYXg6ICs4NiAx MCA2MzYwMTA4Nw0KDQpNT0JJTEU6IDEzNjAtMTAzMi0xMTkNCg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYWx0byBtYWlsaW5nIGxpc3QKYWx0b0BpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FsdG8K --Boundary_(ID_CXAE3vn2rEMWVE514XFN0g)-- From bbl@lowekamp.net Tue Mar 17 19:35:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48633A69E7 for ; Tue, 17 Mar 2009 19:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8me3z3Tl8vbD for ; Tue, 17 Mar 2009 19:35:36 -0700 (PDT) Received: from mail-qy0-f108.google.com (mail-qy0-f108.google.com [209.85.221.108]) by core3.amsl.com (Postfix) with ESMTP id 2E4263A6873 for ; Tue, 17 Mar 2009 19:35:36 -0700 (PDT) Received: by qyk6 with SMTP id 6so566107qyk.29 for ; Tue, 17 Mar 2009 19:36:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.74.77 with SMTP id t13mr611276qcj.58.1237343779706; Tue, 17 Mar 2009 19:36:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Mar 2009 22:36:19 -0400 Message-ID: From: Bruce Lowekamp To: Henning Schulzrinne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 02:35:37 -0000 You're right, I'm referring to inbound connections, which are necessary to support peers behind NATs, as we're required to do. One could certainly set up an overlay where NATed nodes cannot be peers, and so I'm happy to say an overlay should be able to specify such a configuration, but we can't restrict ourselves to that solution. Bruce On Tue, Mar 17, 2009 at 8:10 AM, Henning Schulzrinne wrote: > > On Mar 17, 2009, at 6:25 AM, Bruce Lowekamp wrote: > >> Salman, >> >> Unfortunately, the conversation is dominated by the need to work in >> the real Internet, where the dominant situation is that UDP will work >> and TCP won't. > > I'm curious: Is there data indicating the problem? I've heard of problems > with *inbound* connections via NATs, but the likelihood that outbound TCP > from behind a NAT doesn't work seems low, given that this would essentially > kill all consumer applications, from shiny web 2.0 to dusty IMAP. > > Henning > From hishigh@gmail.com Wed Mar 18 01:45:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1743A69C2 for ; Wed, 18 Mar 2009 01:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj2f7A7Kn8bf for ; Wed, 18 Mar 2009 01:45:16 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 5AA7E3A6819 for ; Wed, 18 Mar 2009 01:45:16 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so105373eyf.31 for ; Wed, 18 Mar 2009 01:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=j2CMyW17UJ+ABFXob9bi1LdEZpCYs9CNFLlKHV6CZuE=; b=pVMaDYv2g5ohyBHtccX8rFV6W2oVAHmT2CEY1N/JnFgLE8D8fDDlQG2VjOg7aRzNug EnIfURxiIDE05VkUXqVziClYbPpae8msghAhNNoFrkZ6gwvnrHMynqEmt+zsZt+FbZvp l+7wC465vg9HUyLYNdmfP2iiIVuBFrRkYllgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iw92gHKvrNdwDJOQT7t802hRYDg1mXW+zVjDZKs59f8JwSKtHLtvTc7LVDHufmjJps KF7PrZxRaTNg5mjtfLyTf4a+TQTu/tVrnB5Nuk571UiUQnLdm3sFoW6AnlPqjDDcn8tM b/DYVsdDUpKCg2ZJfr2mVcVr5soGqWLASrabo= MIME-Version: 1.0 Received: by 10.210.127.13 with SMTP id z13mr126876ebc.93.1237365959341; Wed, 18 Mar 2009 01:45:59 -0700 (PDT) Date: Wed, 18 Mar 2009 16:45:59 +0800 Message-ID: <8bd755250903180145q717d2214l41bc0c1bbbd0d9e4@mail.gmail.com> From: yunfei zhang To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=0015174c10a076b765046560b614 Subject: [P2PSIP] PPSP(p2p streaming protocol) bar bof agenda X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 08:45:17 -0000 --0015174c10a076b765046560b614 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,all, The primary PPSP(p2p streaming protocol) bar bof agenda is as follows.An= y suggestions and contributions are welcome. PPSP Bar BoF-- IETF 74, San Francisco 2000-2200 Monday,March 23,Continental 3. Mailing list=A3=BAppsp@ietf.org http://www.ietf.org/mailman/listinfo/ppsp Agenda - Introduction (Yunfei Zhang, 5') - Problem Statement (Yunfei Zhang, 50') draft-zhang-ppsp-problem statement-01 - Protocol Requirements (Ning Zong, 35') draft-zong-ppsp-reqs-00 - Protocol Analysis of PPlive and PPStream by Interent Measurement (Yunfei Zhang,15') draft-zhang-ppsp-protocol-comparison-measurement-00 - Introduction of Distributed Services Network, a vision of making PPSP and P2PSIP into reality (Yunfei zhang, 15') draft-zhang-ppsp-dsn-introduction-00 --0015174c10a076b765046560b614 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi,all,
   The primary PPSP(p= 2p streaming protocol) bar bof agenda is as follows.Any suggestions and con= tributions are welcome.
  
PPSP Bar BoF-- IETF 74, San Francisc= o
  2000-2200 Monday,March 2= 3,Continental 3.
 
Agenda
- Introduction &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        (Yunfei Zhang, 5')=

- Problem Statement        =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;     (Yunfei Zhang, 50')
  draft-zhang-= ppsp-problem statement-01

- Protocol Requirements        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       (Ning Zong, 35')
  draft-zong-ppsp-reqs-00
- Protocol Analysis = of PPlive and PPStream by Interent Measurement    =             &nb= sp;            =            (Yunfei Z= hang,15')
 
- Introduction of Distributed S= ervices Network, a vision of making PPSP and P2PSIP into reality  = ;    (Yunfei zhang, 15')
  draft-zhang-ppsp-dsn-introduction-= 00
 
--0015174c10a076b765046560b614-- From hishigh@gmail.com Wed Mar 18 01:54:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7603A6822 for ; Wed, 18 Mar 2009 01:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=2.062, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YypC474iYHM for ; Wed, 18 Mar 2009 01:54:44 -0700 (PDT) Received: from mail-ew0-f168.google.com (mail-ew0-f168.google.com [209.85.219.168]) by core3.amsl.com (Postfix) with ESMTP id 2328A3A67FC for ; Wed, 18 Mar 2009 01:54:43 -0700 (PDT) Received: by ewy12 with SMTP id 12so338224ewy.37 for ; Wed, 18 Mar 2009 01:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=P3I3LepHgdY5n7nmH8Heck1FT+Qe+eE8xqPLWaB7whI=; b=gy6QsFK+ujS5CAsN5kIFTqxMBihv1GDroqsTI4BqIDlNav/rgW3UTJjCv7PYxN6nan 17sr5IJZfUvdyaIn2mxdHCr0VErqKXkli7BIBzNyWUHdao1ABlcsh8flVZ+fgnN3eOsK Pzqq8whpVkXU06WqDfrkZgCQLP5hvxSjJQoPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZdeQ01vXD7HcowmohBLoRQqGfrzdpc6oJ7qrBykXkstXAkG+JoyhaAIsEQyEOfUkgI t58MwCaXK+NCz817Lmgdnr122HsMglhgYbwPR5iZFhASL81CBrHZNKPsfru4f9gzbdlb xViyGEnkneWkYuR8YkUoy9XsZ52z2mmSl0/Gc= MIME-Version: 1.0 Received: by 10.210.20.17 with SMTP id 17mr778171ebt.45.1237366527383; Wed, 18 Mar 2009 01:55:27 -0700 (PDT) Date: Wed, 18 Mar 2009 16:55:27 +0800 Message-ID: <8bd755250903180155k7c27a7b1j3927edbfc1159fe9@mail.gmail.com> From: yunfei zhang To: p2psip@ietf.org Content-Type: multipart/mixed; boundary=0015174be732525b48046560d829 Subject: [P2PSIP] a new draft on P2PSIP Security Requirements X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 08:54:47 -0000 --0015174be732525b48046560d829 Content-Type: multipart/alternative; boundary=0015174be732525b3b046560d827 --0015174be732525b3b046560d827 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, There is an attached new draft on P2PSIP Security Requirements which is complementary to the exisiting security requirement draft.And most of the new points are from when to operate a P2PSIP service. The abstract of the draft is as follows: This draft discusses the security requirements in Peer-to-Peer (P2P) SIP system. As the P2P SIP is distributed and each peer is equal in it, it should face the extra security threat from traditional system. This draft introduces these security threats at first. After that, the security requirements of P2P SIP system were brought up. Any suggestion and comments are welcome. --0015174be732525b3b046560d827 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,
=A0=A0 There is an attached new draft on P2PSIP Security Requirements = which is complementary to the exisiting security requirement draft.And most= of the new points are from=A0when to operate a P2PSIP service.
The abstract of the draft is as follows:

This draft discusses the security requirements in Peer-to-Peer (P2P) =A0=A0 SIP system. As the P2P SIP is distributed and each peer is equal in=
=A0=A0 it, it should face the extra security threat from traditional s= ystem.
=A0=A0 This draft introduces these security threats at first. After that, <= br>=A0=A0 the security requirements of P2P SIP system were brought up.=A0 <= /p>

=A0Any suggestion and comments are welcome.

--0015174be732525b3b046560d827-- --0015174be732525b48046560d829 Content-Type: text/plain; charset=US-ASCII; name="draft-zhu-p2psip-security-requirements-01.txt" Content-Disposition: attachment; filename="draft-zhu-p2psip-security-requirements-01.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fsfs15g5 UDJQU0lQIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSi4gWmh1IApJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTS4gUWkgCkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25h bCAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGluYSBNb2JpbGUgCkV4cGlyZXM6IFNlcHRl bWJlciAyMDA5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDksIDIwMDkg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICBQMlBTSVAgU2VjdXJp dHkgUmVxdWlyZW1lbnRzIAogICAgICAgICAgICAgICBkcmFmdC16aHUtcDJwc2lwLXNlY3VyaXR5 cmVxdWlyZW1lbnRzLTAxLnR4dCAKCgpTdGF0dXMgb2YgdGhpcyBNZW1vIAoKICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgg dGhlIAogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiAKCiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIAog ICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAg Tm90ZSB0aGF0IAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuIAoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIAogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueSAKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcyByZWZlcmVuY2UgCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiIgCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURy YWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQt YWJzdHJhY3RzLnR4dCAKCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJl Y3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQgCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93 Lmh0bWwgCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciA5 LCAyMDA5LiAKCkNvcHlyaWdodCBOb3RpY2UgCgogICBDb3B5cmlnaHQgKEMpIDIwMDkgSUVURiBU cnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUgCiAgIGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLiAgCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsICAgCiAgIFByb3Zpc2lvbnMgUmVs YXRpbmcgdG8gSUVURiBEb2N1bWVudHMgICAgCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZiAgICAKICAgcHVibGljYXRpb24g b2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIAogICBjYXJl ZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRo IHJlc3BlY3QgICAgCiAgIHRvIHRoaXMgZG9jdW1lbnQuIAoKICAgIAoKICAgIAogCiAKIApKdWR5 ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwOSAgICAgICAgICAgICAg IFtQYWdlIDFdIAoMCkludGVybmV0LURyYWZ0ICAgICAgUDJQU0lQIFNlY3VyaXR5IFJlcXVpcmVt ZW50cyAgICAgICAgICAgIE1hcmNoIDIwMDkgCiAgICAKCkFic3RyYWN0IAoKICAgVGhpcyBkcmFm dCBkaXNjdXNzZXMgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBpbiBQZWVyLXRvLVBlZXIgKFAy UCkgCiAgIFNJUCBzeXN0ZW0uIEFzIHRoZSBQMlAgU0lQIGlzIGRpc3RyaWJ1dGVkIGFuZCBlYWNo IHBlZXIgaXMgZXF1YWwgaW4gCiAgIGl0LCBpdCBzaG91bGQgZmFjZSB0aGUgZXh0cmEgc2VjdXJp dHkgdGhyZWF0IGZyb20gdHJhZGl0aW9uYWwgc3lzdGVtLiAKICAgVGhpcyBkcmFmdCBpbnRyb2R1 Y2VzIHRoZXNlIHNlY3VyaXR5IHRocmVhdHMgYXQgZmlyc3QuIEFmdGVyIHRoYXQsIAogICB0aGUg c2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIFAyUCBTSVAgc3lzdGVtIHdlcmUgYnJvdWdodCB1cC4g IAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogCiAKSnVkeSAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAy XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgIFAyUFNJUCBTZWN1cml0eSBSZXF1aXJlbWVudHMgICAg ICAgICAgICBNYXJjaCAyMDA5IAogICAgCgpUYWJsZSBvZiBDb250ZW50cyAKCiAgICAKICAgMS4g SW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uNCAKICAgMi4gRGVmaW5pdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uNSAKICAgICAgMi4xLiBHZW5lcmFsLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSAKICAgICAgMi4yLiBOZXR3b3JrIEVudGl0aWVz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSAKICAgICAgMi4zLiBOZXR3 b3JrIEFyY2hpdGVjdHVyZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSAKICAg My4gU2VjdXJpdHkgU2NlbmFyaW9zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uNyAKICAgICAgMy4xLiBWb0lQLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNyAKICAgNC4gU2VjdXJpdHkgVGhyZWF0cy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCAKICAgICAgNC4xLiBXZWFrIFNlY3VyaXR5 IFByb3RlY3Rpb24gQ2F1c2VkIGJ5IG5vIHRydXN0Li4uLi4uLi4uLi4xMCAKICAgICAgNC4yLiBS b3V0aW5nIE1vZGlmaWNhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCAK ICAgICAgNC4zLiBNYWxpY2lvdXMgQ29kZSBTcHJlYWRpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xMSAKICAgNS4gU2VjdXJpdHkgUmVxdWlyZW1lbnRzLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xMiAKICAgICAgNS4xLiBUcnVzdCBNb2RlbC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMiAKICAgICAgNS4yLiBBdXRoZW50aWNh dGlvbiBJbmZyYXN0cnVjdHVyZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyAKICAgICAgICAg NS4yLjEuIENlbnRyYWxpemVkIEF1dGhlbnRpY2F0aW9uIEluZnJhc3RydWN0dXJlLi4uLi4uLi4x MyAKICAgICAgICAgNS4yLjIuIERpc3RyaWJ1dGVkIEF1dGhlbnRpY2F0aW9uIEluZnJhc3RydWN0 dXJlLi4uLi4uLi4xMyAKICAgICAgNS4zLiBQcm90ZWN0aW9uIGFnYWluc3QgTWFsaWNpb3VzIENv ZGUgU3ByZWFkaW5nLi4uLi4uLi4uLi4xNCAKICAgNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNiAKICAgNy4gSUFOQSBDb25zaWRl cmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNyAKICAgOC4g Q29uY2x1c2lvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xOCAKICAgOS4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xOSAKICAgICAgOS4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOSAKICAgIAoKCgoKCgoKCgoKCgoKCgoKCgoKCiAK IApKdWR5ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwOSAgICAgICAg ICAgICAgIFtQYWdlIDNdIAoMCkludGVybmV0LURyYWZ0ICAgICAgUDJQU0lQIFNlY3VyaXR5IFJl cXVpcmVtZW50cyAgICAgICAgICAgIE1hcmNoIDIwMDkgCiAgICAKCjEuIEludHJvZHVjdGlvbiAK CiAgIFRoaXMgZHJhZnQgaW50cm9kdWNlIHRoZSBtYWluIHNlY3VyaXR5IGNvbmNlcm5zIGFuZCBz ZWN1cml0eSAKICAgcmVxdWlyZW1lbnRzIGluIFBlZXItdG8tUGVlciBTSVAgYXJjaGl0ZWN0dXJl IFsxXS4gIFNJUCB3aWxsIGJlIHVzZWQgCiAgIGluIGEgcGVlci10by1wZWVyIGVudmlyb25tZW50 IHdpdGggdGhlIG5ldHdvcmsgZGV2ZWxvcG1lbnQuIFRoZSAKICAgdHJhZGl0aW9uYWwgbWVjaGFu aXNtIHVzZWQgaW4gU0lQIHNob3VsZCBiZSByZXBsYWNlZCBieSBkaXN0cmlidXRlZCAKICAgbWVj aGFuaXNtIHRvIGZpdCBmb3IgdGhlIFAyUCBuZXR3b3JrIHN5c3RlbS4gQXMgYSByZXN1bHQsIFAy UCBTSVAgCiAgIGFyY2hpdGVjdHVyZSBzaG91bGQgZmFjZSBuZXcgc2VjdXJpdHkgdGhyZWF0cyBh bmQgbmV3IHNlY3VyaXR5IAogICByZXF1aXJlbWVudHMuIFRoZSBwdXJwb3NlIG9mIHRoaXMgZHJh ZnQgaXMgdG8gbGlzdCB0aGUgc2VjdXJpdHkgCiAgIHJlcXVpcmVtZW50cyBhbmQgbWFrZSByZWZl cmVuY2VzIGZvciB0aGUgZnV0dXJlIHNlY3VyaXR5IHNvbHV0aW9uIAogICBzdHVkeS4gCgogICAg CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiAKIApKdWR5ICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDRdIAoMCklu dGVybmV0LURyYWZ0ICAgICAgUDJQU0lQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAg IE1hcmNoIDIwMDkgCiAgICAKCjIuIERlZmluaXRpb24gCgogICBUbyBzdHVkeSB0aGUgc2VjdXJp dHkgb2YgUDJQIFNJUCBzeXN0ZW0sIHRoZXJlIG11c3QgYmUgYSBzZWN1cml0eSAKICAgbW9kZWwg dG8gZGVzY3JpYmUgdGhlIHN5c3RlbS4gCgoyLjEuIEdlbmVyYWwgCgogICBUaGUga2V5IHdvcmRz ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIAog ICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJ T05BTCIgaW4gdGhpcyAKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2Ny aWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uIAoKMi4yLiBOZXR3b3JrIEVudGl0aWVzIAoKICAg VGhlIG5ldHdvcmsgZW50aXRpZXMgYXJlIHBlZXJzLCBjbGllbnRzIG9yIG90aGVyIGZ1bmN0aW9u YWwgbm9kZXMgCiAgIHdoaWNoIGFyZSBkZWZpbmVkIGluIHJlZmVyZW5jZSBbMV0uIFRoZXJlIFNI T1VMRCBiZSBhIHNwZWNpYWwga2luZCBvZiAKICAgZnVuY3Rpb25hbCBub2RlcyBuYW1lZCBlbnJv bGxtZW50IHNlcnZlciB0byBwZXJmb3JtIAogICBhdXRoZW50aWNhdGlvbi9lbnJvbGxtZW50IHNl cnZpY2UgZm9yIG90aGVycy4gCgoyLjMuIE5ldHdvcmsgQXJjaGl0ZWN0dXJlIAoKICAgVGhlIGZv bGxvd2luZyBmZWF0dXJlIHNob3dzIGEgUDJQIFNJUCBuZXR3b3JrIGFyY2hpdGVjdHVyZSBiYXNl ZCBvbiAKICAgcmVmZXJlbmNlIG1vZGVsIGZyb20gcmVmZXJlbmNlIFsxXS4gSW4gdGhpcyBzdHVk eSwgdGhyZWUga2luZHMgb2YgCiAgIG5vZGVzIG1lbnRpb25lZCBhYm92ZSBhcmUgdG8gYmUgY29u c2lkZXJlZC4gVGhlIHBlZXIgbm9kZSBpcyBiYXNpYyAKICAgbm9kZSB3aGljaCBjb25zdHJ1Y3Rz IHRoZSBib2R5IG9mIG5ldHdvcmsuIEEgcGVlciBjYW4gY29ubmVjdCB0byAKICAgc2V2ZXJhbCBu b2RlcyBubyBtYXR0ZXIgd2hhdCBraW5kIG9mIHRoZXNlIG5vZGVzIGFyZS4gQSBjbGllbnQgd2ls bCAKICAgYmUgY29ubmVjdGVkIGRpcmVjdGx5IHRvIHBlZXIgZXhjZXB0IGVucm9sbG1lbnQgc2Vy dmVyIHdoaWNoIGNhbiBhY3QgCiAgIGFzIGEgbm9ybWFsIHBlZXIuIFRoZSBlbnJvbGxtZW50IHNl cnZlciB3aWxsIGJlIGNvbm5lY3RlZCB3aXRoIAogICBzZXZlcmFsIHBlZXJzLiAKCgoKCgoKCgoK CgoKCgoKCgoKIAogCkp1ZHkgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA5LCAy MDA5ICAgICAgICAgICAgICAgW1BhZ2UgNV0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICBQMlBTSVAg U2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAgTWFyY2ggMjAwOSAKICAgIAoKICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICB8ICstLS0t LS0tKyAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgfCAKICAgfCB8Q2xpZW50 IHwgICAgICAgICAgViAgICAgICAgICAgICAgICBWICAgICAgICAgIHwgCiAgIHwgKy0tLS0tLS0r ICAgICAgICstLS0tKyAgICAgICArLS0tLS0tLS0tLSsgICAgICB8IAogICB8ICAgICAgXiArLS0t LS0tLT58UGVlcnw8LS0rICAgfEVucm9sbG1lbnR8ICAgICAgfCAKICAgfCAgICAgIHwgfCAgICAg ICAgKy0tLS0rICAgfCAgIHwgIFNlcnZlciAgfCAgICAgIHwgCiAgIHwgICAgICB8IHwgICAgICAg ICAgIF4gICAgIHwgICArLS0tLS0tLS0tLSsgICAgICB8IAogICB8ICAgICAgfCB8ICAgICAgICAg ICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAKICAgfCAgICAgIHwgfCAgICAgICAgICAg fCAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgCiAgIHwgICAgICB8IHwgICAgICAgICAgIHwg ICAgIHwgICAgICAgICAgICAgICAgICAgICB8IAogICB8ICAgICAgViBWICAgICAgICAgICBWICAg ICB8ICAgICAgICAgICAgICAgICAgICAgfCAKICAgfCAgICArLS0tLSsgICAgICAgKy0tLS0rICAg fCAgKy0tLS0rICAgICstLS0tLS0rIHwgCiAgIHwgICAgfFBlZXJ8PC0tLS0tPnxQZWVyfDwtLS0t PnxQZWVyfDwtLT58Q2xpZW50fCB8IAogICB8ICAgICstLS0tKyAgICAgICArLS0tLSsgICB8ICAr LS0tLSsgICAgKy0tLS0tLSsgfCAKICAgfCAgICAgXiAgICAgICAgICAgXiAgXiAgICAgfCAgICBe XiAgICAgICAgICAgICAgIHwgCiAgIHwgICAgIHwgICAgICAgICAgIHwgIHwgICAgIFYgICAgfHwg ICAgICAgICAgICAgICB8IAogICB8ICAgICB8ICAgICAgICAgICB8ICB8ICArLS0tLSsgIHx8ICAg ICAgICAgICAgICAgfCAKICAgfCAgICAgfCAgICAgICAgICAgfCAgKy0+fFBlZXJ8PC0rfCAgICAg ICAgICAgICAgIHwgCiAgIHwgICAgIHwgICAgICAgICAgIFYgICAgICstLS0tKyAgIHwgICAgICAg ICAgICAgICB8IAogICB8ICAgICBWICAgICArLS0tLS0tLS1fLSsgICAgICAgICB8ICAgICAgICAg ICAgICAgfCAKICAgfCAgKy0tLS0tLSsgfEVucm9sbG1lbnR8ICAgICAgICAgfCAgICAgICAgICAg ICAgIHwgCiAgIHwgIHxDbGllbnR8IHwgIFNlcnZlciAgfDwtLS0tLS0tLSsgICAgICAgICAgICAg ICB8IAogICB8ICArLS0tLS0tKyArLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAg fCAKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsg CiAgICAKICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxIFAyUCBTSVAgTmV0d29yayBBcmNoaXRl Y3R1cmUgCgoKCgoKCgoKCgoKCgoKCgoKCgogCiAKSnVkeSAgICAgICAgICAgICAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDksIDIwMDkgICAgICAgICAgICAgICBbUGFnZSA2XSAKDApJbnRlcm5ldC1E cmFmdCAgICAgIFAyUFNJUCBTZWN1cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgICBNYXJjaCAy MDA5IAogICAgCgozLiBTZWN1cml0eSBTY2VuYXJpb3MgCgogICBUbyBkZXRlcm1pbmUgdGhlIHNl Y3VyaXR5IGlzc3VlcyBpbiBQMlAgU0lQIHN5c3RlbSwgdGhlcmUgc2hvdWxkIGJlIAogICBzb21l IGFwcGxpY2F0aW9uIHNjZW5hcmlvcyBpbiBQMlAgU0lQIGVudmlyb25tZW50LiBXZSB3aWxsIGRl c2NyaWJlIAogICB0aGVzZSBzZWN1cml0eSBzY2VuYXJpb3MgZmlyc3QgYW5kIHR1cm4gdG8gZGlz Y3Vzc2lvbiBhYm91dCBzZWN1cml0eSAKICAgcHJvYmxlbXMgYW5kIHNlY3VyaXR5IHJlcXVpcmVt ZW50cy4gCgozLjEuIFZvSVAgCgogICBWb0lQIGlzIGFuIGltcG9ydGFudCBhcHBsaWNhdGlvbiBz Y2VuYXJpbyBpbiBQMlAgU0lQIHN5c3RlbS4gCgogICBJbiB0aGlzIHNjZW5hcmlvLCBjbGllbnQg bm9kZSBpcyB0aGUgVm9JUCBlbmQgdXNlci4gSXQgd2lsbCBiZSAKICAgYXV0aGVudGljYXRlZCBi eSB0aGUgcGVlciwgd2hpY2ggaXMgZGlyZWN0bHkgY29ubmVjdGVkIHRvLCB3aXRoIHRoZSAKICAg YXV0aGVudGljYXRpb24gdmVjdG9yIGZyb20gZW5yb2xsbWVudCBzZXJ2ZXIgYW5kIGluIHRoZSBz YW1lIHRpbWUgaXQgCiAgIHNoYWxsIGF1dGhlbnRpY2F0ZSB0aGUgcGVlciwgYW5kIHRoZSBjbGll bnQgY2FuIGNvbW11bmljYXRlIHdpdGggCiAgIGFub3RoZXIgY2xpZW50IHRocm91Z2ggdGhlIHNl Y3VyaXR5IHBhdGggc2V0IHVwIGJ5IHBlZXJzLiBQZWVyIG5vZGUgCiAgIGlzIHJlc3BvbnNpYmxl IGZvciBhdXRoZW50aWNhdGluZyBmcmVzaCBWb0lQIGNsaWVudCBvbiBiZWhhbGYgb2YgCiAgIGVu cm9sbWVudCBzZXJ2ZXIgYW5kIHN1cHBvcnQgdG8gbmVnb3RpYXRlIGFuZCB0aGVuIHByb3ZpZGUg c2VjdXJpdHkgCiAgIGxpbmsgYmV0d2VlbiB0aGUgcGVlciBhbmQgdGhlIGNsaWVudC4gUGVlciBp cyBhbHNvIHJlc3BvbnNpYmxlIGZvciAKICAgbG9jYXRpbmcgdGhlIG90aGVyIGVuZCBjbGllbnQg YW5kIGFsc28gcmVzcG9uc2libGUgZm9yIGVzdGFibGlzaGluZyBhIAogICBzZWN1cmUgbGluayBi ZXR3ZWVuIHRoZSBwZWVycyBhbmQgdHJhbnNmZXJyaW5nIGRhdGEgZm9yIGVuZCB0byBlbmQgCiAg IGNsaWVudHMnIGNvbW11bmljYXRpb24uIElmIGEgbmV3IHBlZXIgZW50ZXJzIHRoZSBuZXR3b3Jr IG9yIG9sZCBwZWVyIAogICBleGl0cywgdGhlIHNlY3VyZSBsaW5rIHdpbGwgYmUgY2hhbmdlZCBi ZWNhdXNlIHRoZSBuZXR3b3JrIHRvcG9sb2d5IAogICBpcyBjaGFuZ2VkIHdpdGggdGhlIG5ldyBw ZWVyLiBFbnJvbGxtZW50IHNlcnZlciBnZW5lcmF0ZXMgCiAgIGF1dGhlbnRpY2F0aW9uIHZlY3Rv cnMgYmFzZWQgb24gdGhlIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QgcmVjZWl2ZWQgCiAgIGZyb20g dGhlIHBlZXIgd2hvIGlzIGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgY2xpZW50IGFuZCBzZW5k cyAKICAgdmVjdG9ycyB0byB0aGUgcGVlciBpbiByZXNwb25zZS4gCgogICBJbiB0aGlzIHNjZW5h cmlvLCBzZWN1cml0eSBhc3NvY2lhdGlvbiBzaG91bGQgYmUgZXN0YWJsaXNoZWQgYmV0d2VlbiAK ICAgcGVlciBhbmQgcGVlci9lbnJvbGxtZW50IHNlcnZlciBmb3IgaW50ZWdyaXR5LCBjb25maWRl bnRpYWxpdHkgYW5kIAogICBhbnRpLXJlcGxheSBhYm91dCB0aGUgc2lnbmFsaW5nIGFuZCB1c2Vy IGRhdGEuIAoKICAgVGhlIGZvbGxvd2luZyBmaWd1cmUgc2hvd3MgaG93IGEgY2xpZW50IChuYW1l ZCBjbGllbnQgQSkgY2FsbHMgCiAgIGFub3RoZXIgY2xpZW50IChuYW1lZCBjbGllbnQgQikgYnkg dGhyb3VnaCB0aGUgUDJQIFNJUCBuZXR3b3JrLiAKCiAgICAKCgoKCgoKCgoKCiAKIApKdWR5ICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwOSAgICAgICAgICAgICAgIFtQ YWdlIDddIAoMCkludGVybmV0LURyYWZ0ICAgICAgUDJQU0lQIFNlY3VyaXR5IFJlcXVpcmVtZW50 cyAgICAgICAgICAgIE1hcmNoIDIwMDkgCiAgICAKCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAKICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IAogICB8ICstLS0tLS0tKyAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLSsgICAgICAgICAgIHwgCiAgIHwgfENsaWVudCB8ICAgICAgICAgIFYgICAg ICAgICAgICAgICAgViAgICAgICAgICAgfCAKICAgfCArLS0tLS0tLSsgICAgICAgKy0tLS0rICAg ICAgICstLS0tLS0tLS0tKyAgICAgICB8IAogICB8ICAgICAgXiArLS0tLS0tLT58UGVlcnw8LS0r ICAgfEVucm9sbG1lbnR8ICAgICAgIHwgCiAgIHwgICAgICB8IHwgICAgICAgICstLS0tKyAgIHwg ICB8ICBTZXJ2ZXIgIHwgICAgICAgfCAKICAgfCAgICAgIHwgfCAgICAgICAgICAgXiAgICAgfCAg ICstLS0tLS0tLS0tKyAgICAgICB8IAogICB8ICAgICAgfCB8ICAgICAgICAgICB8ICAgICB8ICAg ICAgICAgICAgICAgICAgICAgIHwgCiAgIHwgICAgICB8IHwgICAgICAgICAgIHwgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgfCAKICAgfCAgICAgIHwgfCAgICAgICAgICAgfCAgICAgfCAgICAg ICAgICAgICAgICAgICAgICB8IAogICB8ICAgICAgViBWICAgICAgICAgICBWICAgICB8ICAgICAg ICAgNCAgICAgICAgICAgIHwgCiAgIHwgICAgKy0tLS0rICAzICAgICstLS0tKyAgIHwgICstLS0t Ky0tLT4rLS0tLS0tLSsgfCAKICAgfCAgICB8UGVlcnw8PT09PT0+fFBlZXJ8PD09PT0+fFBlZXJ8 ICAgIHxDbGllbnRCfCB8IAogICB8ICAgICstLS0tKyAgICAgICArLS0tLSsgICB8ICArLS0tLSs8 LS0tKy0tLS0tLS0rIHwgCiAgIHwgICAgIF4gICstLS0tLSsgIF4gIF4gICAgIHwgICAgXl4gICA1 ICAgICAgICAgICAgfCAKICAgfCAgICAgfCAgfCAgMSAgfCAgfCAgfCAgICAgViAgICB8fCAgICAg ICAgICAgICAgICB8IAogICB8ICAgIDJ8ICB8ICAgICB8ICB8ICB8ICArLS0tLSsgIHx8ICAgICAg ICAgICAgICAgIHwgCiAgIHwgICAgIHwgIHwgICAgIHwgIHwgICstPnxQZWVyfDwtK3wgICAgICAg ICAgICAgICAgfCAKICAgfCAgICAgfCAgfCAgICAgViAgViAgICAgKy0tLS0rICAgfCAgICAgICAg ICAgICAgICB8IAogICB8ICAgICBWICB8ICArLS0tLS0tLS1fLSsgICAgICAgICB8ICAgICAgICAg ICAgICAgIHwgCiAgIHwgKy0tLS0tLS0rIHxFbnJvbGxtZW50fCAgICAgICAgIHwgICAgICAgICAg ICAgICAgfCAKICAgfCB8Q2xpZW50QXwgfCAgU2VydmVyICB8PC0tLS0tLS0tKyAgICAgICAgICAg ICAgICB8IAogICB8ICstLS0tLS0tKyArLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKyAKICAgIAogICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIgVm9JUCBpbiBQMlAgU0lQ IHN5c3RlbSAKCiAgIDEuIFRoZSBjbGllbnQgc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQgZmlyc3Rs eS4gVGhlIHBlZXIgc2hvdWxkIHNlbmQgCiAgIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QgdG8gdGhl IGNsaWVudCB3aGljaCBpdCBkaXJlY3RseSBjb25uZWN0cyB0by4gCiAgIFRoZSBwZWVyIHdpbGwg Zm9yd2FyZCB0aGlzIHNlc3Npb24gcmVxdWVzdCB0byBlbnJvbGxtZW50IHNlcnZlci4gV2hlbiAK ICAgdGhlIGVucm9sbG1lbnQgc2VydmVyIHJlY2VpdmVkIHJlcXVlc3QsIGl0IGdlbmVyYXRlcyBh dXRoZW50aWNhdGlvbiAKICAgdmVjdG9yIGZvciB0aGUgY2xpZW50IEEgYW5kIHNlbmRzIGl0IGJh Y2sgdG8gdGhlIHBlZXIuIAoKICAgMi4gVGhlIHBlZXIgd2lsbCBhdXRoZW50aWNhdGUgY2xpZW50 IGJ5IHVzaW5nIHRoZSBhdXRoZW50aWNhdGlvbiAKICAgdmVjdG9ycy4gQXQgdGhlIHNhbWUgdGlt ZSwgdGhlIGNsaWVudCBBIHNob3VsZCBhdXRoZW50aWNhdGUgdGhlIHBlZXIgCiAgIHRvby4gVGhl biB0aGlzIHdheSwgdGhlIHBlZXIgYW5kIGNsaWVudCBwZXJmb3JtcyB0aGUgbXV0dWFsIAogICBh dXRoZW50aWNhdGlvbi4gSXQgaXMgc2hvd24gYXMgc3RlcCAyIGluIHRoZSBmaWd1cmUuIFRoaXMg cHJvY2VzcyAKICAgTVVTVCBiZSBkb25lIGp1c3QgYmVjYXVzZSBpdCBpcyB0aGUgYmFzaWMgb2Yg c2VjdXJpdHkgZW52aXJvbm1lbnQuIAogICBCZXNpZGVzIHRoaXMgYXV0aGVudGljYXRpb24gZnVu Y3Rpb24sIHRoZSBvdGhlciBzZWN1cml0eSBwcm90ZWN0aW9uIAogICBiZXR3ZWVuIHBlZXIgYW5k IGNsaWVudCBzdWNoIGFzIGludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5IHdpbGwgYmUgCiAg IHByb3ZpZGVkIGFmdGVyIHRoZSBzZWN1cml0eSBtb2RlIG5lZ290aWF0aW9uIGJldHdlZW4gdGhl bS4gCgogICAzLiBUaGUgcGVlciB3aXRoIGNsaWVudCBBIHdpbGwgZXN0YWJsaXNoIFNBIHdpdGgg dGhlIHBlZXIgd2l0aCBjbGllbnQgCiAgIEIuIHNvIHRoZSBzZWN1cml0eSBsaW5rIHdpbGwgYmUg c2V0IHVwIGJldHdlZW4gdGhlIHJlbGF0ZWQgcGVlcnMuIAoKCiAKIApKdWR5ICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDhdIAoM CkludGVybmV0LURyYWZ0ICAgICAgUDJQU0lQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgICAgICAg ICAgIE1hcmNoIDIwMDkgCiAgICAKCiAgIDQuIEluIHRoaXMgc3RlcCwgdGhlIHBlZXIgd2l0aCB0 aGUgY2xpZW50IEIgdGVybWluYXRpb24gd2lsbCAKICAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQg QiBieSB1c2luZyB0aGUgYXV0aGVudGljYXRpb24gdmVjdG9ycyBmcm9tIAogICB0aGUgZW5yb2xs bWVudCBzZXJ2ZXIuIAoKICAgNS4gQ2xpZW50IEIgcGVyZm9ybXMgdGhlIGF1dGhlbnRpY2F0aW9u IGZvciB0aGUgcGVlciBhcyB3ZWxsLiBBbmQgCiAgIHRoZW4gdGhleSBuZWdvdGlhdGUgdGhlIHNl Y3VyaXR5IGFzc29jaWF0aW9uIHRvIHByb3ZpZGUgdGhlIHNlY3VyaXR5IAogICB0cmFuc2ZlciBv biB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZW0uIAoKICAgQXQgdGhlIGVuZCBvZiB0aGlz IHByb2NlZHVyZSwgaG9wLWJ5LWhvcCBzZWN1cml0eSBsaW5rIGhhcyBiZWVuIAogICBwZXJmb3Jt ZWQgaW4gdGhlIGNvbW11bmljYXRpb24gZnJvbSB0aGUgZW5kIHRvIGVuZCB1c2VyIHN1Y2ggYXMg CiAgIGNsaWVudCBBIHRvIGNsaWVudCBCLiAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgogCiAKSnVkeSAgICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMDkg ICAgICAgICAgICAgICBbUGFnZSA5XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgIFAyUFNJUCBTZWN1 cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgICBNYXJjaCAyMDA5IAogICAgCgo0LiBTZWN1cml0 eSBUaHJlYXRzIAoKICAgVGhpcyBzZWN0aW9uIGFuYWx5emVzIHRoZSBzZWN1cml0eSB0aHJlYXRz IGFib3V0IFAyUC1TSVAgc3lzdGVtLiAKCjQuMS4gV2VhayBTZWN1cml0eSBQcm90ZWN0aW9uIENh dXNlZCBieSBubyB0cnVzdCAKCiAgIEluIFAyUCBTSVAgbmV0d29yaywgdGhlIHRyYWRpdGlvbmFs IHNlY3VyaXR5IG1lY2hhbmlzbSBpcyBub3QgdXNlZCB0byAKICAgdGhpcyBuZXR3b3JrIGJlY2F1 c2Ugb2YgdGhlIG5ldHdvcmsgaXMgZGlzdHJpYnV0ZWQgYW5kIGhhcyBubyAKICAgY2VudHJhbGl6 ZWQgcG9pbnQuIEFzIHRoZSB0b3BvbG9neSBvZiBQMlAgU0lQIG5ldHdvcmsgaXMgZGlmZmVyZW50 IAogICBiZXR3ZWVuIHRyYWRpdGlvbmFsIEMvUyBuZXR3b3JrcywgaXQgd2lsbCBjYXVzZSBzb21l IHByb2JsZW1zIAogICBtZW50aW9uZWQgYXMgZm9sbG93aW5nOiAKCiAgIG8gU2VjdXJpdHkgZG9t YWluIHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQgdG8gYmUgZGl2aWRlZCBjbGVhcmx5IAoKICAgbyBB Y2NlbGVyYXRpb24gb2YgdGhlIHNlY3VyaXR5IHRocmVhdHMgYW5kIG1ha2UgdGhlIGF0dGFja3Mg ZWFzeSBhbmQgCiAgICAgIGltcGFjdCBtdWNoIG1vcmUgd2lkZSBhcmVhcyB0aGFuIGJlZm9yZSAK CiAgIFRoZSBmaXJzdCBidWxsZXQgcG9pbnQgZGVzY3JpYmVzIHRoYXQgaW4gdGhlIFAyUCBTSVAg bmV0d29yaywgCiAgIHNlY3VyaXR5IGRvbWFpbiBjaGFuZ2VzIGFsb25nIHdpdGggbmV3IG5vZGVz IGVudGVyIHRoZSBzeXN0ZW0gYW5kL29yIAogICBvbGQgbm9kZXMgbGVhdmUgdGhlIHN5c3RlbS4g VGhlIHRyYWRpdGlvbmFsIHNlY3VyaXR5IGRvbWFpbiBkaXZpc2lvbiAKICAgZnVuY3Rpb24gaXMg bm8gbG9uZ2VyIGZpdCBmb3IgUDJQIFNJUCBuZXR3b3JrLiBObyBub2RlIGNhbiBndWFyYW50ZWUg CiAgIHRoZSBub2RlIHRoYXQgaGFkIHNhbWUgc2VjdXJpdHkgZG9tYWluIHN0aWxsIGNhbiBiZSB0 cnVzdCB3aGVuIHRoZSAKICAgbmV0d29yayB0b3BvbG9neSBjaGFuZ2VzLiAKCiAgIFRoZSBzZWNv bmQgYnVsbGV0IHBvaW50IGRlc2NyaWJlcyB0aGF0IG5vZGVzIHdpbGwgc3VmZmVyIGxlc3MgCiAg IHB1bmlzaG1lbnQgZm9yIG1hbGljaW91cyBhY3Rpb24gaW4gUDJQIFNJUCBuZXR3b3Jrcy4gU28g bm9kZXMgd2lsbCAKICAgc3VmZmVyIG1vcmUgYXR0YWNraW5nIGluIHRoZSBzeXN0ZW0gYW5kIHdp bGwgcmVkdWNlIHRoZSB0cnVzdCBsZXZlbCAKICAgdG8gb3RoZXIgbm9kZXMuIAoKICAgQXMgbWVu dGlvbmVkIGFib3ZlLCBQMlAgU0lQIG5vZGVzIGhhdmUgbGVzcyB0cnVzdCB3aXRoIG90aGVyIG5v ZGVzLiAKICAgU28gdGhlIG5ldHdvcmsgc2VjdXJpdHkgcHJvdGVjdGlvbiBpcyB3ZWFrZW5lZC4g Cgo0LjIuIFJvdXRpbmcgTW9kaWZpY2F0aW9uIAoKICAgUm91dGluZyBwcm90b2NvbCBpcyB0aGUg a2V5IHByb3RvY29sIGFuZCBjb3JlIHNlY3VyaXR5IG1lY2hhbmlzbSBmb3IgCiAgIFAyUCBTSVAg YXJjaGl0ZWN0dXJlLiBJdCBwcm92aWRlcyBzb21lIG1lY2hhbmlzbXMsIHN1Y2ggYXMgCiAgIGFk ZGluZy9kZWxldGluZyBwZWVycyBpbnRvIHN5c3RlbSwgbG9jYXRpbmcgc3BlY2lmaWMgcGVlciwg dXBkYXRpbmcgCiAgIG5ldHdvcmsgc3RhdHVzLCBzZWFyY2hpbmcgc291cmNlIGFuZCB0aGUgZmFp bHVyZSBtYW5hZ2VtZW50LiBUaGlzIAogICB3aWxsIGFmZmVjdCB0aGUgbmV0d29yayByb2J1c3Qs IHJlZHVjZSBlZmZpY2llbmN5IG9mIHRoZSBuZXR3b3JrLiAKCiAgIElmIHRoZSByb3V0aW5nIG1l c3NhZ2UgaXMgbm90IHByb3RlY3RlZCwgaXQgd2lsbCBjYXVzZSBwcm9ibGVtIAogICBkZXNjcmli ZWQgYXMgZm9sbG93aW5nOiAKCiAgIG8gQXR0YWNrZXIgY2FuIHNwcmVhZCBmYWtlIGluZm9ybWF0 aW9uIGluIHRoZSBuZXR3b3JrLiBJdCB3aWxsIAogICAgICByZXN1bHQgcGVlcnMgbW9kaWZ5IHRo ZWlyIHJvdXRpbmcgaW5mb3JtYXRpb24gYW5kIG1ha2UgYSB3cm9uZyB3YXkgCiAgICAgIHBhdGgg dG8gY29ubmVjdCBhbiB1bmF2YWlsYWJsZSBwZWVyIG9yIHRvIGFjaGlldmUgYSB3cm9uZyBwb3Np dGlvbi4gCgogCiAKSnVkeSAgICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDksIDIw MDkgICAgICAgICAgICAgIFtQYWdlIDEwXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgIFAyUFNJUCBT ZWN1cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgICBNYXJjaCAyMDA5IAogICAgCgo0LjMuIE1h bGljaW91cyBDb2RlIFNwcmVhZGluZyAKCiAgIEluIHRoZSBQMlAgU0lQIGVudmlyb25tZW50LCBt YWxpY2lvdXMgY29kZSBzdWNoIGFzIHdvcm0gYW5kIFRyb2phbiAKICAgaG9yc2UgY2FuIHNwcmVh ZCBpbiB0aGUgc3lzdGVtIGVhc2lseSBiZWNhdXNlIG9mIHRoZSBjb252ZW5pZW50IAogICBzaGFy aW5nIGFuZCByb3V0aW5nIG1lY2hhbmlzbS4gTWFsaWNpb3VzIGNvZGUgd2lsbCBjYXVzZSBzZXZl cmUgCiAgIGRpc2FzdGVyIGJlY2F1c2Ugb2Ygd2hhdCB3ZSBwb2ludGVkIG91dCBhcyBmb2xsb3dp bmcuIAoKICAgbyBJbiB0aGUgUDJQIFNJUCBlbnZpcm9ubWVudCwgZWFjaCBwZWVyIGhhcyBhYmls aXR5IHRvIGdldCAKICAgICAgaW5mb3JtYXRpb24gYWJvdXQgaXRzIG5laWdoYm9yIG5vZGUuIFNv IG1hbGljaW91cyBjb2RlIGNhbiBtYWtlIAogICAgICBhdHRhY2sgYmFzZWQgb24gdGhlIGV4aXN0 ZWQgaW5mb3JtYXRpb24uIFRoaXMgd2lsbCByZWR1Y2UgdGhlIAogICAgICBkaWZmaWN1bHR5IHRv IGxhdW5jaCBhbiBhdHRhY2suIAoKICAgbyBJbiB0aGUgUDJQIFNJUCBlbnZpcm9ubWVudCwgcGVl cnMgbWFrZSBjb21tdW5pY2F0aW9uIHdpdGggZWFjaCAKICAgICAgb3RoZXIgZGlyZWN0bHkgYW5k IGRvbid0IG5lZWQgdG8gYmUgdHJhbnNmZXJyZWQgYnkgc2VydmVycy4gUGVlcnMgCiAgICAgIGhh dmUgZGlmZmVyZW50IHNlY3VyaXR5IGxldmVscyBhbmQgd2lsbCBzdWZmZXIgYXR0YWNraW5nIG1v cmUgCiAgICAgIGVhc2lseS4gSW4gdGhpcyBzaXR1YXRpb24sIG9uZSBub2RlIHdpbGwgYmUgaW5m ZWN0ZWQgd2l0aCAKICAgICAgbWFsaWNpb3VzIGNvZGUgYnkgc2V2ZXJhbCBvdGhlciBwZWVycyBh bmQgd2lsbCBpbmZlY3QgbWFueSBvdGhlciAKICAgICAgcGVlcnMgYXMgdGhlIG1hbGljaW91cyBy ZXNvdXJjZS4gCgogICBvIEFzIHRoZSBsb2dpY2FsLWFkamFjZW50IHBlZXJzIG1heSBiZSBmYXIg YXdheSBpbiBnZW9ncmFwaGljYWwgaW4gCiAgICAgIHRoZSBwMnAgc2lwIG5ldHdvcmssIHRoZSBt YWxpY2lvdXMgY29kZSBjYW4gYWZmZWN0IGEgbGFyZ2VyIHNjb3BlLCAKICAgICAgYW5kIHRoaXMg d2lsbCBjYXVzZSBncmVhdCBkYW1hZ2UgZm9yIHRoZSBzeXN0ZW0uIAoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgogCiAKSnVkeSAgICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDksIDIw MDkgICAgICAgICAgICAgIFtQYWdlIDExXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgIFAyUFNJUCBT ZWN1cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgICBNYXJjaCAyMDA5IAogICAgCgo1LiBTZWN1 cml0eSBSZXF1aXJlbWVudHMgCgogICBXaXRoIHRoZSBzZWN1cml0eSB0aHJlYXRzIGFuYWx5c2lz LCB3ZSBjYW4gZmluZCBvdXQgd2hhdCB0aGUgc2VjdXJpdHkgCiAgIHJlcXVpcmVtZW50cyB0aGUg UDJQIFNJUCBzeXN0ZW0gcmVhbGx5IG5lZWRzLiAKCjUuMS4gVHJ1c3QgTW9kZWwgCgogICBUaGUg c2VjdGlvbiA0LjEgYW5hbHl6ZXMgdGhlIHByb2JsZW1zIGFuZCBpbmZsdWVuY2VzIGluIHNpdHVh dGlvbiAKICAgdGhhdCBQMlAgU0lQIHN5c3RlbSBsYWNrIG9mIHRydXN0LiBJdCBNVVNUIG5lZWQg dG8gY3JlYXRlIGEgdHJ1c3QgCiAgIG1vZGVsIGluIHRoZSBsaWdodCBvZiB0aGUgdHJ1c3QgYXJj aGl0ZWN0dXJlIGluIHRoZSByZWFsIHdvcmxkLiAKCiAgIFAyUCBTSVAgbmV0d29yayB3aWxsIGJl bmVmaXQgZnJvbSB0cnVzdCBpbmNlbnRpdmUgc3lzdGVtLiBUaGVyZSBhcmUgCiAgIHNvbWUgcmVh c29ucyBkZXNjcmliZWQgYXMgZm9sbG93aW5nOiAKCiAgIG8gVHJ1c3QgbWVjaGFuaXNtIGNhbiBi ZSBhbiBlZmZlY3RpdmUgbWVjaGFuaXNtIHRvIG1lYXN1cmUgdGhlIAogICAgICBzZWN1cml0eSBz dGF0dXMgb2Ygbm9kZXMuIAoKICAgbyBTZWN1cml0eSBkb21haW4gY2FuIGJlIG1hZGUgYW5kIHVw ZGF0ZWQgZHluYW1pY2FsbHkgd2l0aCB0cnVzdCAKICAgICAgbWVjaGFuaXNtLiBQMlAgU0lQIG5l dHdvcmsgY2FuIGJlIGRpdmlkZWQgaW50byBzb21lIHNlY3VyaXR5IAogICAgICBkb21haW5zIGRl cGVuZCBvbiB0aGUgY29ycmVzcG9uZGluZyB0cnVzdCBsZXZlbHMuIFRoZSB1bmlxdWUgCiAgICAg IHNlY3VyaXR5IHBvbGljeSBjYW4gYmUgbWFkZSBmb3IgYSBzZWN1cml0eSBkb21haW4gYXMgbm9k ZXMgaW4gdGhlIAogICAgICBzYW1lIGRvbWFpbiBoYXZlIHRoZSBzYW1lIHRydXN0IGxldmVsLiBN b3Jlb3ZlciwgaWYgdGhlIG5ldHdvcmsgCiAgICAgIGNoYW5nZXMsIHRoZSB0cnVzdCBsZXZlbCBv ZiByZWxhdGVkIG5vZGVzIHdpbGwgY2hhbmdlIGFzIHdlbGwuIEl0IAogICAgICB3aWxsIGNhdXNl IHRoZSBzZWN1cml0eSBkb21haW4gdXBkYXRlLiAKCiAgIG8gVHJ1c3QgbWVjaGFuaXNtIGNhbiBl ZmZlY3RpdmVseSBpbmhpYml0IG1hbGljaW91cyBtb3RpdmF0aW9uIGZvciAKICAgICAgdGhlIGF0 dGFja2luZy4gRWFjaCBub2RlIGNhbiBnZXQgaW5mb3JtYXRpb24gYWJvdXQgYW5vdGhlciBub2Rl J3MgCiAgICAgIHRydXN0IGluZm9ybWF0aW9uIHNvIGl0IGNhbiBqdWRnZSB0aGUgcG9zc2liaWxp dHkgb2YgbGF1bmNoaW5nIAogICAgICBtYWxpY2lvdXMgYXR0YWNrIHRoZSBub2RlIGlzLiBXaXRo IHRoZSBpbmZvcm1hdGlvbiwgaXQgY2FuIAogICAgICBkZXRlcm1pbmUgd2hldGhlciB0aGUgbm9k ZSBzaG91bGQgYmUgY29ubmVjdGVkLiBTbyB0cnVzdCBtZWNoYW5pc20gCiAgICAgIGNhbiBlbmNv dXJhZ2Ugbm9kZXMgdG8gcmVkdWNlIHRoZSBtYWxpY2lvdXMgbW90aXZhdGlvbiBhbmQgYWN0aW9u cyAKICAgICAgYW5kIGVuaGFuY2UgbmV0d29yayBzZWN1cml0eSBsZXZlbC4gCgogICBGb3IgZXhh bXBsZSwgZm9yIHRoZSBkaWZmZXJlbnQga2luZHMgb2Ygbm9kZXMsIGl0IHNob3VsZCBzZXQgdGhy ZWUgCiAgIGtpbmRzIG9mIG1lYXN1cmUgZnVuY3Rpb24gZm9yIHRoZSB0aHJlZSBraW5kcyBvZiBu b2RlcyBhcyBmb2xsb3dpbmc6IAoKICAgbyBFbnJvbGxtZW50IHNlcnZlciBpcyBhIGtleSBub2Rl IGluIHRoZSBuZXR3b3JrIGZvciBhdXRoZW50aWNhdGlvbiAKICAgICAgYW5kIGF1dGhvcml6YXRp b24uIEl0IHdpbGwgYmUgcHJvdmlkZWQgdGhlIGhpZ2hlc3QgbGV2ZWwgc2VjdXJpdHkgCiAgICAg IHByb3RlY3Rpb24gYW5kIHN1ZmZlciBsZXN0IGF0dGFjay4gU28gaW5pdGlhbCB0cnVzdCBsZXZl bCBvZiAKICAgICAgZW5yb2xsbWVudCBzZXJ2ZXIgY2FuIGJlIHNldCBoaWdoZXN0IGxldmVsIHRy dXN0ZWQuIEJ1dCBpZiAKICAgICAgbWFsaWNpb3VzIGFjdGlvbiBpcyBkZXRlY3RlZCB3aXRoIHNw ZWNpZmljIGVucm9sbG1lbnQgc2VydmVyLCBpdHMgCiAgICAgIHRydXN0IGxldmVsIHNob3VsZCBi ZSByZWR1Y2VkIHJhcGlkbHkgYW5kIGdyZWF0bHkgdG8gbGltaXQgdGhlIAogICAgICBpbmZsdWVu Y2Ugb2YgaXRzIG1hbGljaW91cyBhdHRhY2suIAoKCgoKIAogCkp1ZHkgICAgICAgICAgICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDA5ICAgICAgICAgICAgICBbUGFnZSAxMl0gCgwKSW50 ZXJuZXQtRHJhZnQgICAgICBQMlBTSVAgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAg TWFyY2ggMjAwOSAKICAgIAoKICAgbyBQZWVyIGlzIHRoZSBiYXNpYyBub2RlIHRvIGNvbnN0cnVj dCBQMlAgU0lQIG5ldHdvcmsuIFBlZXJzIGhhdmUgCiAgICAgIHRoZSBtb3N0IGNvbXBsZXggc2Vj dXJpdHkgcmVxdWlyZW1lbnRzLiBFYWNoIHBlZXIgc2hvdWxkIGJlIAogICAgICBpbml0aWF0ZWQg d2l0aCBtaWRkbGUgbGV2ZWwgb2YgdHJ1c3QgYW5kIGFkanVzdCB0cnVzdCBsZXZlbCBieSAKICAg ICAgcGVlciBpbmZvcm1hdGlvbiBzdWNoIGFzIGxpbmsgaW5mb3JtYXRpb24sIHBlZXIgYWN0aW9u LCBhY3Rpdml0eSAKICAgICAgYWJpbGl0eSBvciBhbnkgb3RoZXIgaW5mb3JtYXRpb24uIAoKICAg byBDbGllbnQgaXMgdGhlIGVuZCBvZiBQMlAgU0lQIG5ldHdvcmsuIEl0IHdhcyBjb250cm9sbGVk IGJ5IGVuZCAKICAgICAgdXNlciBhbmQgY2FuIGVudGVyIGFuZCBleGl0IG5ldHdvcmsgYXQgYW55 IHRpbWUuIFNvIHRoZSBpbml0aWF0aW5nIAogICAgICB0cnVzdCBsZXZlbCBzaG91bGQgYmUgbG93 LiBJdCBjYW4gYmUgdXBkYXRlZCBieSBjbGllbnQgYmVoYXZpb3JzIAogICAgICBhbmQgaW5mb3Jt YXRpb24gYXMgY2xpZW50IGFjdGlvbnMsIHJlc291cmNlIG9jY3VwYW5jeSBhbmQgYW55IAogICAg ICBvdGhlcnMuIAoKNS4yLiBBdXRoZW50aWNhdGlvbiBJbmZyYXN0cnVjdHVyZSAKCiAgIEluIHRo ZSB0cmFkaXRpb25hbCBuZXR3b3JrLCBhIGNsaWVudCB3aG8gd2FudHMgdG8gdXNlIHNlcnZpY2Ug ZnJvbSAKICAgc2VydmVyIG11c3QgYmUgYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCBieSBy ZWxhdGVkIHNlcnZlci4gQnV0IAogICBQMlAgU0lQIHN5c3RlbSBpcyBhIGRpc3RyaWJ1dGVkIG5l dHdvcmsuIFRoaXMgbmV0d29yayBoYXMgbm8gCiAgIGNlbnRyYWxpemVkIG5vZGVzLiBFYWNoIHBl ZXIgY2FuIHByb3ZpZGUgc2VydmljZXMgZm9yIG90aGVyIGVudGl0aWVzLiAKICAgV2hlbiBhIG5v ZGUgc2VuZHMgc2VydmljZSByZXF1ZXN0IHRvIG5ldHdvcmtzLCBidXQgcGVlciBjYW5ub3QgZG8g dGhlIAogICBhdXRoZW50aWNhdGlvbiBwcm9jZXNzLiBJdCBzaG91bGQgYmUgZW5yb2xsbWVudCBy ZXNwb25zaWJpbGl0eS4gQXMgYSAKICAgcmVzdWx0LCBhIHNwZWNpYWwga2luZCBvZiBub2RlcyBT SE9VTEQgYmUgbWFkZSBmb3IgcHJvdmlkaW5nIAogICBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIGZv ciBvdGhlciBlbnRpdGllcy4gVGhlc2Ugbm9kZXMgYXJlIGVucm9sbG1lbnQgCiAgIHNlcnZlcnMu IAoKICAgRm9yIHRoaXMgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLCBlbnJvbGxtZW50IHNlcnZl cnMgY2FuIGJlIAogICBvcmdhbml6ZWQgYXMgdHdvIG9wdGlvbnMgYXMgZm9sbG93aW5nLiAKCjUu Mi4xLiBDZW50cmFsaXplZCBBdXRoZW50aWNhdGlvbiBJbmZyYXN0cnVjdHVyZSAKCiAgIEluIFAy UCBTSVAgbmV0d29yaywgYSBjZW50cmFsaXplZCBhdXRoZW50aWNhdGlvbiBpbmZyYXN0cnVjdHVy ZSBNQVkgCiAgIGJlIGltcGxlbWVudGVkLiBJbiB0aGlzIHNjZW5hcmlvLCB0aGVyZSBpcyBhIHN1 cGVyIHBlZXIgaW4gUDJQIFNJUCAKICAgbmV0d29yaywgYWN0IGFzIGVucm9sbG1lbnQgc2VydmVy LiBJdCBTSE9VTEQgc3RvcmVzIGFsbCBlbnJvbGxtZW50IAogICBpbmZvcm1hdGlvbiBhYm91dCBl YWNoIG5vZGUsIGVpdGhlciBwZWVyIG9yIGNsaWVudC4gRXZlcnkgbm9kZSB3aG8gCiAgIHdhbnRz IHRvIGpvaW4gdGhpcyBuZXR3b3JrIFNIT1VMRCBiZSBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3Jp emVkIGJ5IAogICB0aGlzIHNlcnZlci4gSWYgaXQgaXMgam9pbmluZyBwZWVyLCBpdCBTSE9VTEQg bWFrZSBhdXRoZW50aWNhdGlvbiAKICAgcHJvY2VzcyB3aXRoIGVucm9sbG1lbnQgc2VydmVyIGRp cmVjdGx5LiBPciBpdCBTSE9VTEQgbWFrZSAKICAgYXV0aGVudGljYXRpb24gcHJvY2VzcyB3aXRo IHByb3h5IHBlZXIgaW5kaXJlY3RseSBpZiBub3QuIAoKNS4yLjIuIERpc3RyaWJ1dGVkIEF1dGhl bnRpY2F0aW9uIEluZnJhc3RydWN0dXJlIAoKICAgQXMgUDJQIFNJUCBzeXN0ZW0gaXMgYSBkaXN0 cmlidXRlZCBuZXR3b3JrLCBhIGRpc3RyaWJ1dGVkIAogICBhdXRoZW50aWNhdGlvbiBpbmZyYXN0 cnVjdHVyZSB3aGljaCB3aWxsIGZpdCBmb3IgdGhlIHN5c3RlbSBiZXR0ZXIgCiAgIE1BWSBiZSBp bXBsZW1lbnRlZC4gQXMgZGlzdHJpYnV0ZWQgYXV0aGVudGljYXRpb24gaW5mcmFzdHJ1Y3R1cmUg aXMgCiAgIHNldCwgdGhlcmUgYXJlIHR3byBwcm9ibGVtcyBzaG91bGQgYmUgY29uc2lkZXJlZDog CgogICBvIFRoZSBjcmVkZW50aWFscyBzdG9yYWdlIG9uIHRoZSBkaXN0cmlidXRlZCBzZXJ2ZXJz LiAKCiAKIApKdWR5ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwOSAg ICAgICAgICAgICAgW1BhZ2UgMTNdIAoMCkludGVybmV0LURyYWZ0ICAgICAgUDJQU0lQIFNlY3Vy aXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAgIE1hcmNoIDIwMDkgCiAgICAKCiAgIG8gVGhlIHBy b2NlZHVyZSBob3cgYSBuZXcgdmlzaXRvciBtYWtlcyBtdXR1YWwgYXV0aGVudGljYXRpb24gd2l0 aCAKICAgICAgbmV0d29yay4gCgogICBGb3IgdGhlIGZpcnN0IHByb2JsZW0sIHRoZSBjcmVkZW50 aWFsIGZvciBhbGwgbm9kZXMgY2FuIGJlIGRpdmlkZWQgCiAgIGludG8gc29tZSBjYXRlZ29yaWVz LiBBZnRlciB0aGF0LCB0aGUgY3JlZGVudGlhbHMgc2hvdWxkIGJlIHBsYWNlZCAKICAgaW50byBz ZWxlY3RlZCBlbnJvbGxtZW50IHNlcnZlciBieSBzcGVjaWZpYyBhbGdvcml0aG0uIFRoZSBESFQg CiAgIGFsZ29yaXRobSBpcyBwcmVmZXJyZWQgYmVjYXVzZSBpdCB3aWxsIGJlbmVmaXQgd2hlbiBh IG5ldyB2aXNpdG9yIAogICBmaW5kIG91dCB3aGVyZSBpdHMgY3JlZGVudGlhbCBpcyBpbiBhdXRo ZW50aWNhdGlvbiBwcm9jZWR1cmUuIAoKICAgRm9yIGV4YW1wbGUsIHRvIGRlYWwgd2l0aCB0aGUg bXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBpdCBzaG91bGQgZGl2aWRlIAogICBiYXNlIG9uIHdoZXRo ZXIgdGhlIG5ldyB2aXNpdG9yIGlzIGNsaWVudCBvciBub3QuIAoKICAgbyBJZiB0aGUgbmV3IHZp c2l0b3IgaXMgcGVlciwgaXQgc2hvdWxkIGZpbmQgdGhlIG5lYXJlc3QgZW5yb2xsbWVudCAKICAg ICAgc2VydmVyIGJhc2VkIG9uIHRoZSBhbGdvcml0aG0gbGlrZSBESFQgYW5kIHNlbmQgYXV0aGVu dGljYXRpb24gCiAgICAgIHJlcXVlc3QgdG8gdGhlIGVucm9sbG1lbnQgc2VydmVyLiBFbnJvbGxt ZW50IHNlcnZlciB3aWxsIHNlYXJjaCAKICAgICAgcGVlcidzIGNyZWRlbnRpYWwgaW4gbG9jYWwg ZGF0YWJhc2UgYWZ0ZXIgaXQgcmVjZWl2ZWQgCiAgICAgIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3Qu IElmIHBlZXIncyBjcmVkZW50aWFsIGlzIG5vdCBpbiB0aGUgCiAgICAgIGRhdGFiYXNlLCBzZXJ2 ZXIgc2hvdWxkIGdldCBjcmVkZW50aWFsIGZyb20gb3RoZXIgZW5yb2xsbWVudCAKICAgICAgc2Vy dmVycyBhbmQgc3RvcmVzIGl0IHRlbXBvcmFyaWx5LiBUaGVuIGl0IHdpbGwgZ2VuZXJhdGUgCiAg ICAgIGF1dGhlbnRpY2F0aW9uIHZlY3RvciBhbmQgbWFrZSBub3JtYWwgYXV0aGVudGljYXRpb24g cHJvY2VkdXJlIAogICAgICBiZXR3ZWVuIHBlZXIgYW5kIGVucm9sbG1lbnQgc2VydmVyLiBJZiB0 aGUgY3JlZGVudGlhbCBpcyBzdG9yZWQgCiAgICAgIHRlbXBvcmFyaWx5IGluIHRoZSBlbnJvbGxt ZW50IHNlcnZlciwgaXQgTVVTVCBiZSBkZWxldGVkIGFmdGVyIHRoZSAKICAgICAgcGVlciBleGl0 cyB0aGlzIG5ldHdvcmsuIAoKICAgbyBJZiB0aGUgbmV3IHZpc2l0b3IgaXMgYSBjbGllbnQuIEl0 IHNob3VsZCBzZW5kIGF1dGhlbnRpY2F0aW9uIAogICAgICByZXF1ZXN0IHRvIG5lYXJlc3QgZW5y b2xsbWVudCBzZXJ2ZXIgdGhyb3VnaCB0aGUgcGVlciBpdCBpcyAKICAgICAgZGlyZWN0bHkgY29u bmVjdGVkLiBFbnJvbGxtZW50IHNlcnZlciB3aWxsIGdlbmVyYXRlIGF1dGhlbnRpY2F0aW9uIAog ICAgICB2ZWN0b3IgYW5kIHNlbmQgaXQgdG8gcGVlci4gUGVlciBvbiBiZWhhbGYgb2YgZW5yb2xs bWVudCBzZXJ2ZXIgCiAgICAgIG1ha2UgYXV0aGVudGljYXRpb24gcHJvY2VkdXJlIHdpdGggY2xp ZW50LiBBZnRlciB0aGUgZHVwbGV4IAogICAgICBhdXRoZW50aWNhdGlvbiBiZXR3ZWVuIGNsaWVu dCBhbmQgcGVlciwgaXQgc2hvdWxkIHNlbmQgcmVzdWx0IHRvIAogICAgICBlbnJvbGxtZW50IHNl cnZlciBubyBtYXR0ZXIgaXQgc3VjY2VlZGVkIG9yIGZhaWxlZC4gCgo1LjMuIFByb3RlY3Rpb24g YWdhaW5zdCBNYWxpY2lvdXMgQ29kZSBTcHJlYWRpbmcgCgogICBJbiBQMlAgU0lQIHN5c3RlbSBl dmVyeSBub2RlcyBhcmUgZXF1YWwuIEVhY2ggcGVlciBoYXMgYWJpbGl0eSB0byAKICAgc2hhcmUg YW5kIHNwcmVhZCBpbmZvcm1hdGlvbiBpdCBoYXMuIFNvIGlmIG1hbGljaW91cyBjb2RlIGluZmVj dHMgYSAKICAgd2VhayBzZWN1cml0eSBwZWVyLCBpdCB3aWxsIHNwcmVhZCByYXBpZGx5LiBGb3Ig dGhpcyByZWFzb24sIHRoZXJlIAogICBTSE9VTEQgYmUgYSBtZWNoYW5pc20gb3Igc29tZSB0ZWNo bm9sb2d5IHRvIHByZXZlbnQgYW5kIGRpbWluaXNoIAogICBtYWxpY2lvdXMgY29kZSBzcHJlYWRp bmcuIAoKICAgU29tZSBwcm90ZWN0aW9uIHBvbGljeSBjYW4gYmUgZGVmaW5lZCBhczogCgogICBv IFRoZSB1bm5lY2Vzc2FyeSBwb3J0IGFuZCBhcHBsaWNhdGlvbiBzZXJ2ZXIgc2hvdWxkIGJlIGNs b3NlZCBpbiAKICAgICAgZWFjaCBub2RlIHRvIHJlZHVjZSB0aGUgcG9zc2liaWxpdHkgb2Ygc3Vm ZmVyaW5nIG1hbGljaW91cyBhdHRhY2suIAoKCgogCiAKSnVkeSAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDksIDIwMDkgICAgICAgICAgICAgIFtQYWdlIDE0XSAKDApJbnRlcm5l dC1EcmFmdCAgICAgIFAyUFNJUCBTZWN1cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgICBNYXJj aCAyMDA5IAogICAgCgogICBvIFRoZSBwcm90ZWN0aW9uIHdpbGwgYmVuZWZpdCBmcm9tIHRoZSB0 cnVzdCBtZWNoYW5pc20uIEl0IGlzIAogICAgICBiZWNhdXNlIHRoZSB0cnVzdCBtZWNoYW5pc20g bWFya3Mgbm9kZXMgd2l0aCBoaWdoIGF0dGFja2luZyAKICAgICAgcG9zc2liaWxpdHkgaW4gbG93 IHRydXN0IGxldmVsIHNvIHRoYXQgZmV3IG9mIG5vZGVzIHdpbGwgY29ubmVjdCAKICAgICAgdG8g dGhlIGxvdyB0cnVzdCBsZXZlbCBub2Rlcy4gCgogICBNb3Jlb3ZlciwgYXR0YWNraW5nIHNvdXJj ZSBzaG91bGQgYmUgZmFzdCBsb2NhdGVkIGFuZCBpZGVudGlmaWVkLiBUaGUgCiAgIGVhcmxpZXIg YXR0YWNrZXIgd2FzIGxvY2F0ZWQsIHRoZSBsZXNzIGxvc3QgaW4gdGhlIFAyUCBzeXN0ZW0gd2Fz IAogICBzdWZmZXJlZC4gVG8gYWNoaWV2ZSB0aGlzIGdvYWwsIGZvciBleGFtcGxlLCBzb21lIG1l Y2hhbmlzbXMgY2FuIGJlIAogICBjb25zaWRlcmVkIGhlcmUuIAoKICAgbyBVbmRlbmlhYmxlIG1l Y2hhbmlzbS4gVW5kZW5pYWJsZSBtZWNoYW5pc20gZm9yY2VzIGVhY2ggbm9kZSBpbiB0aGUgCiAg ICAgIG5ldHdvcmsgdG8gYmUgcmVzcG9uc2libGUgZm9yIGl0cyBiZWhhdmlvci4gV2hlbiB0aGUg bWVjaGFuaXNtIGlzIAogICAgICBkZXBsb3llZCwgcHJvb2ZzIG9mIG1hbGljaW91cyBhdHRhY2tp bmcgY2FuIGJlIGNvbGxlY3RlZCBlYXNpbHkuIAogICAgICBTbyB0aGUgbG9jYXRpb24gYW5kIGlk ZW50aWZpY2F0aW9uIG9mIGF0dGFja2VyIGNhbiBiZSBnb3QgZmFzdCBhbmQgCiAgICAgIGV4YWN0 IGJhc2VkIG9uIHRoZXNlIHByb29mcy4gCgogICBvIFJlc3BvbnNpYmlsaXR5IENoYWluaW5nLiBB IHJlc3BvbnNpYmlsaXR5IGNoYWluaW5nIGlzIHVzZWQgYXMgYW4gCiAgICAgIGF0dGFjaG1lbnQg b2YgdGhlIHBhY2tldHMgdHJhbnNmZXJyZWQgaW4gdGhlIG5ldHdvcmsuIEl0IGNhbiAKICAgICAg aW5mb3JtIHJlY2VpdmVyIHdoZXJlIHRoZSBwYWNrZXQgaXMgc2VudCBvdXQgYW5kIHdoaWNoIG5v ZGUgaXQgaGFzIAogICAgICBwYXNzZWQuIFdpdGggaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhp cyBjaGFpbmluZywgaXQgaXMgZWFzeSB0byAKICAgICAgZmluZCBvdXQgd2hlcmUgYW5kIHdoYXQg aWRlbnRpdHkgdGhlIGF0dGFja2VyIGlzIGJ5IHRyYWNpbmcgYmFjayAKICAgICAgc3RlcCBieSBz dGVwLiAKCiAgICAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiAKIApKdWR5ICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAwOSAgICAgICAgICAgICAgW1BhZ2UgMTVdIAoMCklu dGVybmV0LURyYWZ0ICAgICAgUDJQU0lQIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgICAgICAgICAg IE1hcmNoIDIwMDkgCiAgICAKCjYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIAoKICAgVGhpcyBt ZW1vIGNvbnNpZGVycyB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHNlY3VyaXR5IHJlcXVpcmVt ZW50cyAKICAgYWJvdXQgUDJQIFNJUCBzeXN0ZW0uIFNvIGl0IHdvdWxkIG5vdCBpbnRyb2R1Y2Ug YW55IGFkZGl0aW9uYWwgCiAgIHNlY3VyaXR5IHByb2JsZW1zLiAKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogCiAKSnVkeSAgICAgICAgICAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDksIDIwMDkgICAgICAgICAgICAgIFtQYWdlIDE2XSAKDApJbnRlcm5ldC1EcmFm dCAgICAgIFAyUFNJUCBTZWN1cml0eSBSZXF1aXJlbWVudHMgICAgICAgICAgICBNYXJjaCAyMDA5 IAogICAgCgo3LiBJQU5BIENvbnNpZGVyYXRpb25zIAoKICAgVGhlcmUgYXJlIG5vIElBTkEgY29u c2lkZXJhdGlvbnMgYXNzb2NpYXRlZCB0byB0aGlzIG1lbW8uIAoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIAogCkp1ZHkgICAgICAgICAgICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciA5LCAyMDA5ICAgICAgICAgICAgICBbUGFnZSAxN10gCgwKSW50ZXJuZXQtRHJh ZnQgICAgICBQMlBTSVAgU2VjdXJpdHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAgTWFyY2ggMjAw OSAKICAgIAoKOC4gQ29uY2x1c2lvbnMgCgogICBUaGlzIG1lbW8gZGVzY3JpYmVzIHZhcmlldHkg b2Ygc2VjdXJpdHkgdGhyZWF0cyBpbiBQMlAgU0lQIHN5c3RlbSAKICAgZmlyc3QuIEFjY29yZGlu ZyB0aGVzZSBzZWN1cml0eSB0aHJlYXRzLCBQMlAgU0lQIHNlY3VyaXR5IAogICByZXF1aXJlbWVu dHMgaXMgYnJvdWdodCB1cC4gCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKIAogCkp1ZHkgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDA5ICAg ICAgICAgICAgICBbUGFnZSAxOF0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICBQMlBTSVAgU2VjdXJp dHkgUmVxdWlyZW1lbnRzICAgICAgICAgICAgTWFyY2ggMjAwOSAKICAgIAoKOS4gUmVmZXJlbmNl cyAKCjkuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgCgogICBbMV0gIEJyeWFuLCBELiwgTWF0dGhl d3MsIFAuLCBTaGltLCBQLiwgYW5kIEQuIFdpbGxpcywgIkNvbmNlcHRzIGFuZCAKICAgICAgICAg VGVybWlub2xvZ3kgZm9yIFBlZXIgdG8gUGVlciBTSVAiLCBkcmFmdC1pZXRmLXAycHNpcC1jb25j ZXB0cy0KICAgICAgICAgMDIudHh0ICh3b3JrIGluIHByb2dyZXNzKSwgSnVseSAyMDA4LiAKCiAg IFsyXSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1hcmlsbG8sIEcuLCBKb2hu c3RvbiwgCiAgICAgICAgIEEuLFBldGVyc29uLCBKLiwgU3BhcmtzLCBSLiwgSGFuZGxleSwgTS4s IGFuZCBFLiBTY2hvb2xlciwgCiAgICAgICAgICJTSVA6U2Vzc2lvbiBJbml0aWF0aW9uIFByb3Rv Y29sIiwgUkZDIDMyNjEsIEp1bmUgMjAwMi4gCgogICBbM10gIE1hdHVzemV3c2tpLCBNLiwgRWti ZXJnLCBKLUUuIGFuZCBMYWl0aW5lbiwgUC4sICJTZWN1cml0eSAKICAgICAgICAgcmVxdWlyZW1l bnRzIGluIFBlZXItdG8tUGVlciBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wiLCAKICAgICAg ICAgZHJhZnQtbWF0dXN6ZXdza2ktcDJwc2lwLXNlY3VyaXR5LXJlcXVpcmVtZW50cy0wNC50eHQK ICAgICAgICAgKHdvcmstaW4tcHJvZ3Jlc3MpLCBOb3ZlbWJlciAyMDA4LiAKCiAgIFtSRkMyMTE5 XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIAog ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJj aCAxOTk3IAoKQXV0aG9yJ3MgQWRkcmVzc2VzIAoKICAgSnVkeSBaaHUgCiAgIENoaW5hIE1vYmls ZSAKICAgVW5pdCAyLCAyOCBYdWFud3VtZW54aSBBdmUsIAogICBYdWFud3UgRGlzdHJpY3QsIAog ICBCZWlqaW5nIDEwMDA1MywgQ2hpbmEgCiAgICAgIAogICBFbWFpbDogemh1aG9uZ3J1QGNoaW5h bW9iaWxlLmNvbSAKICAgIAoKICAgTWlucGVuZyBRaSAKICAgQ2hpbmEgTW9iaWxlIAogICBVbml0 IDIsIDI4IFh1YW53dW1lbnhpIEF2ZSwgCiAgIFh1YW53dSBEaXN0cmljdCwgCiAgIEJlaWppbmcg MTAwMDUzLCBDaGluYSAKICAgICAgCiAgIEVtYWlsOiBxaW1pbnBlbmdAY2hpbmFtb2JpbGUuY29t IAogICAgCgoKCgoKCgoKIAogCkp1ZHkgICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciA5LCAyMDA5ICAgICAgICAgICAgICBbUGFnZSAxOV0gCgwK --0015174be732525b48046560d829-- From hgs@cs.columbia.edu Wed Mar 18 05:17:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8438E3A6A3E for ; Wed, 18 Mar 2009 05:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=1.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD+ePnxeOu+Y for ; Wed, 18 Mar 2009 05:17:05 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id A69883A69FF for ; Wed, 18 Mar 2009 05:17:05 -0700 (PDT) Received: from Upstairs.home (pool-98-109-204-63.nwrknj.fios.verizon.net [98.109.204.63]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2ICHleE019810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2009 08:17:47 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 08:17:47 -0400 References: X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 12:17:06 -0000 True peers (not clients) behind NATs won't work unless they initiate the connection anyway, so I'm a bit confused by the model you have in mind. On Mar 17, 2009, at 10:36 PM, Bruce Lowekamp wrote: > You're right, I'm referring to inbound connections, which are > necessary to support peers behind NATs, as we're required to do. One > could certainly set up an overlay where NATed nodes cannot be peers, > and so I'm happy to say an overlay should be able to specify such a > configuration, but we can't restrict ourselves to that solution. > > Bruce > > > On Tue, Mar 17, 2009 at 8:10 AM, Henning Schulzrinne > wrote: >> >> On Mar 17, 2009, at 6:25 AM, Bruce Lowekamp wrote: >> >>> Salman, >>> >>> Unfortunately, the conversation is dominated by the need to work in >>> the real Internet, where the dominant situation is that UDP will >>> work >>> and TCP won't. >> >> I'm curious: Is there data indicating the problem? I've heard of >> problems >> with *inbound* connections via NATs, but the likelihood that >> outbound TCP >> from behind a NAT doesn't work seems low, given that this would >> essentially >> kill all consumer applications, from shiny web 2.0 to dusty IMAP. >> >> Henning >> > From john.buford@gmail.com Wed Mar 18 09:00:38 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987A63A6880 for ; Wed, 18 Mar 2009 09:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.363 X-Spam-Level: * X-Spam-Status: No, score=1.363 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3ZBkh+cbJnM for ; Wed, 18 Mar 2009 09:00:37 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 589813A67A5 for ; Wed, 18 Mar 2009 09:00:37 -0700 (PDT) Received: by qyk36 with SMTP id 36so114561qyk.29 for ; Wed, 18 Mar 2009 09:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=yTYELay2hIiQ/fciid8DMn7l8H7QTvri5ukNZa91+2I=; b=nknAep6LaOt/ZuORQr+Qp5ca6GrjzZqUF51pb6nvwQ+Y/psdYX3ZhYrU5qi2Zfu6H8 FabLz8RURXexE2KfFMTkme37nK3PlucxrJJrdAZ+w3iHYh9Y7lBezHzEtD25KgDWxk7W /WasQjMHuZK4cKKaYeH7zCJ/NSrv+hN08K1Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=orr9SsPL024sN5zk9IV4H1NGng7kV+bJvJJXbQACZaujRVZBkSjnKDtWcpTBXb6D+c CTSeBsHA9oN7RYvj0F/SjBWto+jm/g85EJ6ieCVecVAHvnQW4PNHAMKIFbYB/3kON8kz Uj+6i3b43zIM2dNdoSCBH1NfFQlcc48HDVkxU= MIME-Version: 1.0 Sender: john.buford@gmail.com Received: by 10.220.92.139 with SMTP id r11mr271292vcm.15.1237392081301; Wed, 18 Mar 2009 09:01:21 -0700 (PDT) In-Reply-To: References: <8b2769930903161329y6970808ekf892b9594ee79c06@mail.gmail.com> Date: Wed, 18 Mar 2009 12:01:21 -0400 X-Google-Sender-Auth: 2a5909b5b2609fa8 Message-ID: <4ce32a820903180901n1fd46b42p47ae6808ddf9dc0@mail.gmail.com> From: John Buford To: Henry Sinnreich Content-Type: multipart/alternative; boundary=001636284c74743473046566cbeb Cc: P2PSIP WG Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: buford@samrg.org 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, 18 Mar 2009 16:00:38 -0000 --001636284c74743473046566cbeb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2009/3/16 Henry Sinnreich hsinnrei@adobe.com I fully agree, since some na=EFve folks out there (including me) think tha= t: > > 1. p2p is self organizing =96 not managed =96 unless fixing node softw= are > is called management. > 2. p2p works across the Internet and crosses many ISP networks, > several times even for any one ISP. The p2p operator may not even be = in > friendly relations with some the ISPs and compete with them. > > Henry, Current overlays have limitations. Here's a partial list of problems, I expect others on this list can add more: - potentially long delays to respond to and correct from network partitions - inability to detect and correct load imbalance, such as flash crowd effec= t - inability to detect and respond to DDOS attacks - inability to enforce different classes of service for different peers - overlay instability at high churn rates, that might be caused by increases in the number of mobile peers - no one knows what happens if the overlay population exceeds some large number, say 100M, sinces no overlays have been deployed or simulated at tha= t size - does it degrade gracefully or become inoperable While there are some research proposals to address some of these problems individually, it is safe to say that no single design covers all of them. In general as long as there are overlay algorithm performance areas which c= an not be automatically detected and corrected by self-organizing algorithms, = then there is a need for management agent(s) to be able to monitor and intervene= . Sure this boundary is likely to shift over time as algorithms get better. And monitoring the overlay can help the development of better algorithms. Here's a detailed discussion of the limits of today's P2P systems w.r.t. self-organization: B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, 1 (March 2007), 34 pp. Here's a look at how overlay management might work: J. Buford, Management of peer-to-peer overlays, International J. of Interne= t Protocol Technology, Special Issue on Management of IP Networks and Services, Vol. 3, No.1, 2008, 2=9612. Bottom line, ideally P2P doesn't need to be managed, but depending on user expectations for service quality and willingness to pay, there could be deployments with overlay operators who provide this for users by managing the overlay. John > --001636284c74743473046566cbeb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

=A0
2009/3/16 Henry Sinnreich hsinnrei@adobe.com

I fully agree, since some na=EFve folks out there (including me) think= that:
  1. p2p is self organizing =96 not managed =96 unless fixing node so= ftware is called management.
  2. p2p works across the Internet and crosses many ISP networks, =A0= several times even for any one ISP. The p2p operator may not even be in fri= endly relations with some the ISPs and compete with them.
Henry,
=A0
Current overlays have limitat= ions.=A0 Here's a partial list of problems, I expect others on this lis= t can add more:
=A0
- potentially long delays to respond to and correct f= rom network partitions
- inability to detect and correct load imbalance, suc= h as flash crowd effect
- inability to detect and respond to DDOS attacks
- inability to enforce different classes of service f= or different peers=A0
- overlay instability at high churn rates, that might= be caused by increases=A0 in the number of mobile = peers
- no one knows what happens if the overlay population= exceeds some large number, say 100M, sinces no overlays have been deployed= or simulated at that size - does it degrade gracefully or become inoperabl= e
While there are some research proposals to address so= me of these problems individually, it is safe to say that no single design = covers all of them.
=A0
In general as long as there are overlay algorithm per= formance areas which can not be automatically detec= ted and corrected by self-organizing algorithms, th= en there is a=A0need for management agent(s) to be able to monitor and inte= rvene.
=A0
Sure this boundary is likely to shift over time as al= gorithms get better.
And monitoring the overlay can help the development o= f better algorithms.
=A0
Here's a detailed discussion of the limits of tod= ay's=A0P2P systems w.r.t. self-organization:

B. Biskupski, J. Dowling, and J. Sacha, Properties and me= chanisms of self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt.= Syst. 2, 1 (March 2007), 34 pp.

Here's a look at how overlay management might wor= k:
=A0
J. Buford, = Management of peer-to-peer overlays, International J. of Internet Protocol = Technology, Special Issue on Management of IP Networks and Services, Vol. 3= , No.1, 2008, 2=9612.
=A0
Bottom line,=A0ideally P2P doesn't need to be man= aged, but depending on user expectations for service quality and willingnes= s to pay, there could=A0=A0be deployments with overlay operators who provid= e this for users by managing the overlay.
=A0
John
=A0
--001636284c74743473046566cbeb-- From ekr@networkresonance.com Wed Mar 18 09:32:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90983A6A9A for ; Wed, 18 Mar 2009 09:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF8wnzdjVTUe for ; Wed, 18 Mar 2009 09:32:39 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3B0A73A6A6B for ; Wed, 18 Mar 2009 09:32:39 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id AC4A150822; Wed, 18 Mar 2009 09:56:18 -0700 (PDT) Date: Wed, 18 Mar 2009 09:56:18 -0700 From: Eric Rescorla To: Henning Schulzrinne In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090318165618.AC4A150822@romeo.rtfm.com> Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 16:32:40 -0000 At Wed, 18 Mar 2009 08:17:47 -0400, Henning Schulzrinne wrote: > > True peers (not clients) behind NATs won't work unless they initiate > the connection anyway, so I'm a bit confused by the model you have in > mind. I'm not Bruce, but the model *I* had in mind was that you would use your existing connections to route rendezvous messages through the overlay and then use ICE to set up the connections, thus avoiding the "initiate" issue. Obviously this in principle works for TCP, except that the future (and effectiveness) of ICE-TCP are uncertain at best. -Ekr From dean.willis@softarmor.com Wed Mar 18 12:12:23 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6A23A6B86 for ; Wed, 18 Mar 2009 12:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoHBfNGYNXr2 for ; Wed, 18 Mar 2009 12:12:22 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A873A3A6B80 for ; Wed, 18 Mar 2009 12:12:22 -0700 (PDT) Received: from [192.168.2.110] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2IJCxlY030102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2009 14:13:00 -0500 Message-Id: From: Dean Willis To: Henning Schulzrinne In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 14:12:54 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 19:12:23 -0000 On Mar 18, 2009, at 7:17 AM, Henning Schulzrinne wrote: > True peers (not clients) behind NATs won't work unless they initiate > the connection anyway, so I'm a bit confused by the model you have > in mind. > A signal comes over an existing connection, causing the peer to send UDP out to a node that can report the address/port number in use. This address/port set is exchanged with the other peer via the existing connection, then the peers contact each other directly using the discovered address/ports. Doesn't work for all NATs, but does for many. And we don't have a trick for doing that with TCP yet, although I'm working on one. And if this doesn't work, we can fall back to using a relay. Barring elimination of NATs, the next best trick would be to build ICE directly into the TCP stack. That would be interesting. But talk about a forklift upgrade! OTOH, it might be possible to do this in such a way that it is backward compatible with TCP; that is, a node using iced-TCP could talk to one using standard TCP. Additional behavior would be required in the NAT, but that's not entirely out of the question. More thought required to keep from reinventing RSIP. -- Dean From hsinnrei@adobe.com Wed Mar 18 12:36:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2348A3A6AD2 for ; Wed, 18 Mar 2009 12:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_05=-1.11, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4WA9y1yuwvY for ; Wed, 18 Mar 2009 12:36:43 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id 13A803A6B97 for ; Wed, 18 Mar 2009 12:36:43 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKScFNdekKaDg5Jvlhl7/yQUbL8MjsbFam@postini.com; Wed, 18 Mar 2009 12:37:28 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n2IJVseM021522; Wed, 18 Mar 2009 12:31:54 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n2IJbLY2018610; Wed, 18 Mar 2009 12:37:22 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Wed, 18 Mar 2009 12:37:20 -0700 From: Henry Sinnreich To: "buford@samrg.org" Date: Wed, 18 Mar 2009 12:37:18 -0700 Thread-Topic: [P2PSIP] Comment on p2psip-diagnostics Thread-Index: Acmn4sveZbdshaUyQC2WJwVphK5GugAHia0t Message-ID: In-Reply-To: <4ce32a820903180901n1fd46b42p47ae6808ddf9dc0@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5E6B79EC5CAhsinnreiadobecom_" MIME-Version: 1.0 Cc: P2PSIP WG Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 19:36:50 -0000 --_000_C5E6B79EC5CAhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, maybe management of overlays works and also maybe it makes economic s= ense (for who?). This would have to be proven however not in papers, but in running systems = as well in market for acceptance. Too bad the Skype and Bittorrent folks who have proven both do not care to = participate in this debate. As an engineer, I may be excused for not believing in p2p management, until= I see the measurements and numbers. > no one knows what happens if the overlay population exceeds some large nu= mber, say >100M, sinces no overlays have been deployed or simulated at that= size - does it degrade >gracefully or become inoperable My Skype panel shows right now 16,659,464 people on line and I believe they= have 400 million subscribers. Skype works exceedingly well for our daily family a/v sessions, coast to co= ast. Does Skype have network management agreements with all the ISPs their p2p i= s crossing? :-) >but depending on user expectations for service quality and willingness to = pay This alone is worth a good beer BOF. Let's plan for one. Henry On 3/18/09 11:01 AM, "John Buford" wrote: 2009/3/16 Henry Sinnreich hsinnrei@adobe.com I fully agree, since some na=EFve folks out there (including me) think that= : 1. p2p is self organizing - not managed - unless fixing node software is = called management. 2. p2p works across the Internet and crosses many ISP networks, several = times even for any one ISP. The p2p operator may not even be in friendly re= lations with some the ISPs and compete with them. Henry, Current overlays have limitations. Here's a partial list of problems, I ex= pect others on this list can add more: - potentially long delays to respond to and correct from network partitions - inability to detect and correct load imbalance, such as flash crowd effec= t - inability to detect and respond to DDOS attacks - inability to enforce different classes of service for different peers - overlay instability at high churn rates, that might be caused by increase= s in the number of mobile peers - no one knows what happens if the overlay population exceeds some large nu= mber, say 100M, sinces no overlays have been deployed or simulated at that = size - does it degrade gracefully or become inoperable While there are some research proposals to address some of these problems i= ndividually, it is safe to say that no single design covers all of them. In general as long as there are overlay algorithm performance areas which c= an not be automatically detected and corrected by self-organizing algorithm= s, then there is a need for management agent(s) to be able to monitor and i= ntervene. Sure this boundary is likely to shift over time as algorithms get better. And monitoring the overlay can help the development of better algorithms. Here's a detailed discussion of the limits of today's P2P systems w.r.t. se= lf-organization: B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of self-o= rganizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, 1 (March= 2007), 34 pp. Here's a look at how overlay management might work: J. Buford, Management of peer-to-peer overlays, International J. of Interne= t Protocol Technology, Special Issue on Management of IP Networks and Servi= ces, Vol. 3, No.1, 2008, 2-12. Bottom line, ideally P2P doesn't need to be managed, but depending on user = expectations for service quality and willingness to pay, there could be de= ployments with overlay operators who provide this for users by managing the= overlay. John --_000_C5E6B79EC5CAhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] Comment on p2psip-diagnostics Well, maybe management of overlays works and also maybe= it makes economic sense (for who?).
This would have to be proven however not in papers, but in running systems = as well in market for acceptance.
Too bad the Skype and Bittorrent folks who have proven both do not care to = participate in this debate.
As an engineer, I may be excused for not believing in p2p management, until= I see the measurements and numbers.

> no one knows wh= at happens if the overlay population exceeds some large number, say >100= M, sinces no overlays have been deployed or simulated at that size - does i= t degrade >gracefully or become inoperable

My Skype panel shows right now 16,659,464 people on line and I believe they= have 400 million subscribers.
Skype works exceedingly well for our daily family a/v sessions, coast to co= ast.
Does Skype have network management agreements with all the ISPs their p2p i= s crossing? :-)

>but depending on= user expectations for service quality and willingness to pay
This alone is worth a good bee= r BOF.
Let’s plan for one.

Henry


On 3/18/09 11:01 AM, "John Buford" <buford@samrg.org> wrote:


=A0
2009/3/16 Henry Sinn= reich hsinnrei@adobe.com

I fully agree, since some naïve folks = out there (including me) think that:
  1. p2p is self organizing – not managed R= 11; unless fixing node software is called management.=20
  2. p2p works across the Internet and crosses many ISP = networks, =A0several times even for any one ISP. The p2p operator may not e= ven be in friendly relations with some the ISPs and compete with them.
Henry,
=A0
Current overlays hav= e limitations.=A0 Here's a partial list of problems, I expect others on thi= s list can add more:
=A0
- potentially long delays to respond to and correct from network partitions=
- inability to detect and correct load imbalance, such as flash crowd effec= t
- inability to detect and respond to DDOS attacks
- inability to enforce different classes of service for different peers=A0<= BR> - overlay instability at high churn rates, that might be caused by increase= s=A0 in the number of mobile peers
- no one knows what happens if the overlay population exceeds some large nu= mber, say 100M, sinces no overlays have been deployed or simulated at that = size - does it degrade gracefully or become inoperable
While there are some research proposals to address some of these problems i= ndividually, it is safe to say that no single design covers all of them. =A0
In general as long a= s there are overlay algorithm performance areas which can not be automatica= lly detected and corrected by self-organizing algorithms, then there is a= =A0need for management agent(s) to be able to monitor and intervene.
=A0
Sure this boundary i= s likely to shift over time as algorithms get better.
And monitoring the overlay can help the development of better algorithms. =A0
Here's a detailed discussion of the limits of today's=A0P2P systems w.r.t. = self-organization:
B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of self-o= rganizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, 1 (March= 2007), 34 pp.

Here's a look at how= overlay management might work:
=A0
J. Buford, Management of peer-to-peer overlays, International J. of Interne= t Protocol Technology, Special Issue on Management of IP Networks and Servi= ces, Vol. 3, No.1, 2008, 2–12.
=A0
Bottom line,=A0ideal= ly P2P doesn't need to be managed, but depending on user expectations for s= ervice quality and willingness to pay, there could=A0=A0be deployments with= overlay operators who provide this for users by managing the overlay.
=A0
John
=A0
wrote: > This sounds like a discussion for which the beer part is an order of > magnitude more important than the BOF part. > > I=92m not sure we=92re going to get anywhere arguing whether management i= s a > good or bad thing. > > Can we get back to the discussion about p2psip-diagnostics? > > Brian > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf > Of > Henry Sinnreich > Sent: Wednesday, March 18, 2009 3:37 PM > To: buford@samrg.org > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Comment on p2psip-diagnostics > > Well, maybe management of overlays works and also maybe it makes economi= c > sense (for who?). > This would have to be proven however not in papers, but in running system= s > as well in market for acceptance. > Too bad the Skype and Bittorrent folks who have proven both do not care t= o > participate in this debate. > As an engineer, I may be excused for not believing in p2p management, unt= il > I see the measurements and numbers. > > > no one knows what happens if the overlay population exceeds some large > number, say >100M, sinces no overlays have been deployed or simulated at > that size - does it degrade >gracefully or become inoperable > > My Skype panel shows right now 16,659,464 people on line and I believe th= ey > have 400 million subscribers. > Skype works exceedingly well for our daily family a/v sessions, coast to > coast. > Does Skype have network management agreements with all the ISPs their p2p > is > crossing? :-) > > >but depending on user expectations for service quality and willingness t= o > pay > This alone is worth a good beer BOF. > Let=92s plan for one. > > Henry > > > On 3/18/09 11:01 AM, "John Buford" wrote: > > > 2009/3/16 Henry Sinnreich hsinnrei@adobe.com > I fully agree, since some na=EFve folks out there (including me) think th= at: > 1. p2p is self organizing =96 not managed =96 unless fixing node software= is > called management. > 2. p2p works across the Internet and crosses many ISP networks, several > times even for any one ISP. The p2p operator may not even be in friendly > relations with some the ISPs and compete with them. > Henry, > > Current overlays have limitations. Here's a partial list of problems, I > expect others on this list can add more: > > - potentially long delays to respond to and correct from network partitio= ns > - inability to detect and correct load imbalance, such as flash crowd > effect > - inability to detect and respond to DDOS attacks > - inability to enforce different classes of service for different peers > - overlay instability at high churn rates, that might be caused by > increases in the number of mobile peers > - no one knows what happens if the overlay population exceeds some large > number, say 100M, sinces no overlays have been deployed or simulated at > that > size - does it degrade gracefully or become inoperable > While there are some research proposals to address some of these problems > individually, it is safe to say that no single design covers all of them. > > In general as long as there are overlay algorithm performance areas which > can not be automatically detected and corrected by self-organizing > algorithms, then there is a need for management agent(s) to be able to > monitor and intervene. > > Sure this boundary is likely to shift over time as algorithms get better. > And monitoring the overlay can help the development of better algorithms. > > Here's a detailed discussion of the limits of today's P2P systems w.r.t. > self-organization: > B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of > self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, = 1 > (March 2007), 34 pp. > > Here's a look at how overlay management might work: > > J. Buford, Management of peer-to-peer overlays, International J. of > Internet > Protocol Technology, Special Issue on Management of IP Networks and > Services, Vol. 3, No.1, 2008, 2=9612. > > Bottom line, ideally P2P doesn't need to be managed, but depending on use= r > expectations for service quality and willingness to pay, there could be > deployments with overlay operators who provide this for users by managing > the overlay. > > John > > > > --0016e64763d89a824504656a5d36 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I am starting a thread on the samrg mailing list entitled
"Can Managed Overlays Prevent 2-Day Outages Such as Skype's i= n 2007"
to discuss the engineering/econonic issues.=A0 Please join
if you are interested in such a discussion.=A0
=A0
Thanks,
John

On Wed, Mar 18, 2009 at 3:51 PM, Brian Rosen <br@brianrosen.net> wrote:
This sounds like a discussion fo= r which the beer part is an order of
magnitude more important than the B= OF part.

I=92m not sure we=92re going to get anywhere arguing whether management= is a
good or bad thing.

Can we get back to the discussion about = p2psip-diagnostics?

Brian

From: p2ps= ip-bounces@ietf.org [mailto:= p2psip-bounces@ietf.org] On Behalf Of
Henry Sinnreich
Sent:= Wednesday, March 18, 2009 3:37 PM
To: buford@samrg.org
Cc: P2PSIP = WG
Subject: Re: [P2PSIP] Comment on p2psip-diagnostics
Well, maybe management of overlays works and also maybe i= t makes economic
sense (for who?).
This would have to be proven howev= er not in papers, but in running systems
as well in market for acceptanc= e.
Too bad the Skype and Bittorrent folks who have proven both do not care to<= br>participate in this debate.
As an engineer, I may be excused for not = believing in p2p management, until
I see the measurements and numbers.
> no one knows what happens if the overlay population exceeds some l= arge
number, say >100M, sinces no overlays have been deployed or simu= lated at
that size - does it degrade >gracefully or become inoperable=

My Skype panel shows right now 16,659,464 people on line and I believe = they
have 400 million subscribers.
Skype works exceedingly well for o= ur daily family a/v sessions, coast to
coast.
Does Skype have network= management agreements with all the ISPs their p2p is
crossing? :-)

>but depending on user expectations for service qua= lity and willingness to
pay
This alone is worth a good beer BOF.
L= et=92s plan for one.

Henry


On 3/18/09 11:01 AM, "Joh= n Buford" <buford@samrg.org= > wrote:

=A0
2009/3/16 Henry Sinnreich = hsinnrei@adobe.com
I fully agree, since some na=EFve folks out there= (including me) think that:
1. p2p is self organizing =96 no= t managed =96 unless fixing node software is
called management.
2. p2p works across the Internet and crosses many ISP= networks, =A0several
times even for any one ISP. The p2p operator may not even= be in friendly
relations with some the ISPs and compete with them.
H= enry,
=A0
Current overlays have limitations.=A0 Here's a partial = list of problems, I
expect others on this list can add more:
=A0
- potentially long delay= s to respond to and correct from network partitions
- inability to detec= t and correct load imbalance, such as flash crowd effect
- inability to = detect and respond to DDOS attacks
- inability to enforce different classes of service for different peers=A0<= br>- overlay instability at high churn rates, that might be caused by
in= creases=A0 in the number of mobile peers
- no one knows what happens if = the overlay population exceeds some large
number, say 100M, sinces no overlays have been deployed or simulated at tha= t
size - does it degrade gracefully or become inoperable
While there = are some research proposals to address some of these problems
individual= ly, it is safe to say that no single design covers all of them.
=A0
In general as long as there are overlay algorithm performance areas = which
can not be automatically detected and corrected by self-organizing=
algorithms, then there is a=A0need for management agent(s) to be able t= o
monitor and intervene.
=A0
Sure this boundary is likely to shift over= time as algorithms get better.
And monitoring the overlay can help the = development of better algorithms.
=A0
Here's a detailed discussio= n of the limits of today's=A0P2P systems w.r.t.
self-organization:
B. Biskupski, J. Dowling, and J. Sacha, Properties an= d mechanisms of
self-organizing MANET and P2P systems, ACM Trans. Auton.= Adapt. Syst. 2, 1
(March 2007), 34 pp.

Here's a look at how = overlay management might work:
=A0
J. Buford, Management of peer-to-peer overlays, International J. of = Internet
Protocol Technology, Special Issue on Management of IP Networks= and
Services, Vol. 3, No.1, 2008, 2=9612.
=A0
Bottom line,=A0idea= lly P2P doesn't need to be managed, but depending on user
expectations for service quality and willingness to pay, there could=A0=A0b= e
deployments with overlay operators who provide this for users by manag= ing
the overlay.
=A0
John
=A0





--0016e64763d89a824504656a5d36-- From sa2086@columbia.edu Wed Mar 18 13:32:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B87928C230 for ; Wed, 18 Mar 2009 13:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7j2EkFlF+GR for ; Wed, 18 Mar 2009 13:32:01 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 5937528C231 for ; Wed, 18 Mar 2009 13:32:01 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2IKWipJ017419; Wed, 18 Mar 2009 16:32:44 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2IKWiZe023716; Wed, 18 Mar 2009 16:32:44 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2IKWi05023713; Wed, 18 Mar 2009 16:32:44 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 18 Mar 2009 16:32:44 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Dean Willis In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 20:32:02 -0000 On Wed, 18 Mar 2009, Dean Willis wrote: > > On Mar 18, 2009, at 7:17 AM, Henning Schulzrinne wrote: > >> True peers (not clients) behind NATs won't work unless they initiate the >> connection anyway, so I'm a bit confused by the model you have in mind. >> > > A signal comes over an existing connection, causing the peer to send UDP out > to a node that can report the address/port number in use. This address/port > set is exchanged with the other peer via the existing connection, then the > peers contact each other directly using the discovered address/ports. Doesn't > work for all NATs, but does for many. And we don't have a trick for doing > that with TCP yet, although I'm working on one. A related question is what is the percentage of deployed NATs that support direct TCP connection establishment using techniques such as Simultaneous-TCP-open? According to "Characterization and Measurement of TCP Traversal through NATs and Firewalls", (IMC'05), 88% of the deployed NATs support direct TCP connection, and 100% for certain common types of NATs. It will be interesting to see a more recent data on this. When NATs are cascaded, the direct TCP connections are a problem as hairpinning support is needed. However, this problem also occurs for UDP (Section 4, RFC 5128). The reliability and congestion control discussion for RELOAD revolves around the notion that direct connection establishment using TCP is orders of magnitude worse than UDP. It is not clear to me if this is the case, unless there is data indicating otherwise. It is also not clear to me whether building a TCP-over-UDP solution will solve the problem of direct connection establishment, as direct 'connection establishment' over UDP does not always work. -salman From ekr@networkresonance.com Wed Mar 18 13:49:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8CE28C0F5 for ; Wed, 18 Mar 2009 13:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz3a2qUnn1lo for ; Wed, 18 Mar 2009 13:49:07 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C251928C226 for ; Wed, 18 Mar 2009 13:49:07 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 74FE250822; Wed, 18 Mar 2009 14:12:47 -0700 (PDT) Date: Wed, 18 Mar 2009 14:12:47 -0700 From: Eric Rescorla To: Salman Abdul Baset In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090318211247.74FE250822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 20:49:08 -0000 At Wed, 18 Mar 2009 16:32:44 -0400 (EDT), Salman Abdul Baset wrote: > The reliability and congestion control discussion for RELOAD revolves > around the notion that direct connection establishment using TCP is orders > of magnitude worse than UDP. No, it does not. If UDP was 99% and TCP was 50% (<< 1 order), then this would pretty clearly require UDP support. -Ekr From sa2086@columbia.edu Wed Mar 18 14:18:43 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51A928C0F5 for ; Wed, 18 Mar 2009 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBSe9L7tIQCd for ; Wed, 18 Mar 2009 14:18:43 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id EA43B28C0E9 for ; Wed, 18 Mar 2009 14:18:42 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2ILJPni022008; Wed, 18 Mar 2009 17:19:25 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2ILJPX6028721; Wed, 18 Mar 2009 17:19:25 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2ILJP6v028718; Wed, 18 Mar 2009 17:19:25 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 18 Mar 2009 17:19:25 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Eric Rescorla In-Reply-To: <20090318211247.74FE250822@romeo.rtfm.com> Message-ID: References: <20090318211247.74FE250822@romeo.rtfm.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2009 21:18:43 -0000 > At Wed, 18 Mar 2009 16:32:44 -0400 (EDT), > Salman Abdul Baset wrote: >> The reliability and congestion control discussion for RELOAD revolves >> around the notion that direct connection establishment using TCP is orders >> of magnitude worse than UDP. > > No, it does not. If UDP was 99% and TCP was 50% (<< 1 order), > then this would pretty clearly require UDP support. Sure. This is why it is helpful to have data indicating the problem. The paper I cited indicates that direct TCP connection can be established for 88 percent of deployed NATs and 100% for common NAT types. -s From br@brianrosen.net Wed Mar 18 18:03:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CBD3A6B83 for ; Wed, 18 Mar 2009 18:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRpI8JsNq2uG for ; Wed, 18 Mar 2009 18:03:52 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0C35C3A695E for ; Wed, 18 Mar 2009 18:03:52 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lk1ne-0000ok-3B; Wed, 18 Mar 2009 14:51:38 -0500 From: "Brian Rosen" To: "'Henry Sinnreich'" , References: <4ce32a820903180901n1fd46b42p47ae6808ddf9dc0@mail.gmail.com> In-Reply-To: Date: Wed, 18 Mar 2009 15:51:46 -0400 Message-ID: <012b01c9a802$fa7bd430$ef737c90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmn4sveZbdshaUyQC2WJwVphK5GugAHia0tAABoIKA= Content-language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 19 Mar 2009 01:03:53 -0000 This sounds like a discussion for which the beer part is an order of magnitude more important than the BOF part. I=92m not sure we=92re going to get anywhere arguing whether management = is a good or bad thing.=20 Can we get back to the discussion about p2psip-diagnostics? Brian=20 From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Wednesday, March 18, 2009 3:37 PM To: buford@samrg.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Comment on p2psip-diagnostics Well, maybe management of overlays works and also maybe it makes = economic sense (for who?). This would have to be proven however not in papers, but in running = systems as well in market for acceptance. Too bad the Skype and Bittorrent folks who have proven both do not care = to participate in this debate. As an engineer, I may be excused for not believing in p2p management, = until I see the measurements and numbers. > no one knows what happens if the overlay population exceeds some large number, say >100M, sinces no overlays have been deployed or simulated at that size - does it degrade >gracefully or become inoperable My Skype panel shows right now 16,659,464 people on line and I believe = they have 400 million subscribers.=20 Skype works exceedingly well for our daily family a/v sessions, coast to coast. Does Skype have network management agreements with all the ISPs their = p2p is crossing? :-) >but depending on user expectations for service quality and willingness = to pay This alone is worth a good beer BOF. Let=92s plan for one. Henry On 3/18/09 11:01 AM, "John Buford" wrote: =A0 2009/3/16 Henry Sinnreich hsinnrei@adobe.com I fully agree, since some na=EFve folks out there (including me) think = that: 1. p2p is self organizing =96 not managed =96 unless fixing node = software is called management.=20 2. p2p works across the Internet and crosses many ISP networks, = =A0several times even for any one ISP. The p2p operator may not even be in friendly relations with some the ISPs and compete with them. Henry, =A0 Current overlays have limitations.=A0 Here's a partial list of problems, = I expect others on this list can add more: =A0 - potentially long delays to respond to and correct from network = partitions - inability to detect and correct load imbalance, such as flash crowd = effect - inability to detect and respond to DDOS attacks - inability to enforce different classes of service for different = peers=A0 - overlay instability at high churn rates, that might be caused by increases=A0 in the number of mobile peers - no one knows what happens if the overlay population exceeds some large number, say 100M, sinces no overlays have been deployed or simulated at = that size - does it degrade gracefully or become inoperable While there are some research proposals to address some of these = problems individually, it is safe to say that no single design covers all of = them. =A0 In general as long as there are overlay algorithm performance areas = which can not be automatically detected and corrected by self-organizing algorithms, then there is a=A0need for management agent(s) to be able to monitor and intervene. =A0 Sure this boundary is likely to shift over time as algorithms get = better. And monitoring the overlay can help the development of better = algorithms. =A0 Here's a detailed discussion of the limits of today's=A0P2P systems = w.r.t. self-organization: B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, = 1 (March 2007), 34 pp. Here's a look at how overlay management might work: =A0 J. Buford, Management of peer-to-peer overlays, International J. of = Internet Protocol Technology, Special Issue on Management of IP Networks and Services, Vol. 3, No.1, 2008, 2=9612. =A0 Bottom line,=A0ideally P2P doesn't need to be managed, but depending on = user expectations for service quality and willingness to pay, there = could=A0=A0be deployments with overlay operators who provide this for users by = managing the overlay. =A0 John =A0 From bbl@lowekamp.net Wed Mar 18 19:58:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821033A6BB6 for ; Wed, 18 Mar 2009 19:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grg23bpc8Ogc for ; Wed, 18 Mar 2009 19:58:06 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id C334A3A6B36 for ; Wed, 18 Mar 2009 19:58:06 -0700 (PDT) Received: by qyk36 with SMTP id 36so448498qyk.29 for ; Wed, 18 Mar 2009 19:58:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.96.132 with SMTP id h4mr1254165qcn.65.1237431531392; Wed, 18 Mar 2009 19:58:51 -0700 (PDT) In-Reply-To: References: <20090318211247.74FE250822@romeo.rtfm.com> Date: Wed, 18 Mar 2009 22:58:51 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 19 Mar 2009 02:58:07 -0000 That paper in particular, and the reasons UDP connections are more reliably formed than TCP, have been discussed numerous times in MMUSIC, and I really don't think we should be repeating the whole conversation here. But the summary is that it's not nearly as universal a solution as indicated in that paper. Bruce On Wed, Mar 18, 2009 at 5:19 PM, Salman Abdul Baset wrote: > >> At Wed, 18 Mar 2009 16:32:44 -0400 (EDT), >> Salman Abdul Baset wrote: >>> >>> The reliability and congestion control discussion for RELOAD revolves >>> around the notion that direct connection establishment using TCP is >>> orders >>> of magnitude worse than UDP. >> >> No, it does not. If UDP was 99% and TCP was 50% (<< 1 order), >> then this would pretty clearly require UDP support. > > Sure. This is why it is helpful to have data indicating the problem. The > paper I cited indicates that direct TCP connection can be established for 88 > percent of deployed NATs and 100% for common NAT types. > > -s > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From melodysong@huawei.com Wed Mar 18 20:27:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5EB28C163 for ; Wed, 18 Mar 2009 20:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.977 X-Spam-Level: X-Spam-Status: No, score=0.977 tagged_above=-999 required=5 tests=[AWL=-1.869, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_ADOBE2=2.455, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW6p7HNSpdRN for ; Wed, 18 Mar 2009 20:27:24 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B25833A6BBB for ; Wed, 18 Mar 2009 20:27:23 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGQ00FRXHMLAL@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 19 Mar 2009 11:27:58 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGQ00MBDHML64@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 19 Mar 2009 11:27:57 +0800 (CST) Received: from s64081 ([10.164.12.16]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGQ00HRSHMKCZ@szxml05-in.huawei.com> for p2psip@ietf.org; Thu, 19 Mar 2009 11:27:57 +0800 (CST) Date: Thu, 19 Mar 2009 11:27:56 +0800 From: Song Haibin In-reply-to: To: 'Henry Sinnreich' , buford@samrg.org Message-id: <006701c9a842$b245b330$100ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_rFk1V4KUYS3W2qRXWToQGA)" Thread-index: Acmn4sveZbdshaUyQC2WJwVphK5GugAHia0tAA+LwfA= Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Comment on p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 19 Mar 2009 03:27:32 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rFk1V4KUYS3W2qRXWToQGA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi Henry, =20 I have seen that the management of overlays has been a hot topic for = ISPs and telecom equipment vendors. Some of the thought is to use p2p = technology in the ISP=92s network to manage their network equipments. I would like = to invite you to the PPSP bar bof meeting which will be held on Monday 8PM = to 10 PM at Continental 3, and there the guys from China Mobile will give a great introduction to their ongoing DSN network project which utilize = the p2p technology. It is exactly a good example of management of overlay. Please refer to this draft:=20 =20 http://www.ietf.org/internet-drafts/draft-zhang-ppsp-dsn-introduction-00.= txt =20 Hope this can help to clarify your doubt.=20 =20 Dear Henry, the authors are really appreciated to your contribution to = the p2psip diagnostics draft, and we would like to see more comments to the p2psip diagnostics draft. Best Regards, Haibin Skype: alexsonghw _____ =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, March 19, 2009 3:37 AM To: buford@samrg.org Cc: David A. Bryan; Song Haibin; P2PSIP WG Subject: Re: [P2PSIP] Comment on p2psip-diagnostics =20 Well, maybe management of overlays works and also maybe it makes = economic sense (for who?). This would have to be proven however not in papers, but in running = systems as well in market for acceptance. Too bad the Skype and Bittorrent folks who have proven both do not care = to participate in this debate. As an engineer, I may be excused for not believing in p2p management, = until I see the measurements and numbers. > no one knows what happens if the overlay population exceeds some large number, say >100M, sinces no overlays have been deployed or simulated at that size - does it degrade >gracefully or become inoperable My Skype panel shows right now 16,659,464 people on line and I believe = they have 400 million subscribers.=20 Skype works exceedingly well for our daily family a/v sessions, coast to coast. Does Skype have network management agreements with all the ISPs their = p2p is crossing? :-) >but depending on user expectations for service quality and willingness = to pay This alone is worth a good beer BOF. Let=92s plan for one. Henry On 3/18/09 11:01 AM, "John Buford" wrote: =20 2009/3/16 Henry Sinnreich hsinnrei@adobe.com I fully agree, since some na=EFve folks out there (including me) think = that: 1. p2p is self organizing =96 not managed =96 unless fixing node = software is called management.=20 2. p2p works across the Internet and crosses many ISP networks, several times even for any one ISP. The p2p operator may not even be in friendly relations with some the ISPs and compete with them. Henry, =20 Current overlays have limitations. Here's a partial list of problems, I expect others on this list can add more: =20 - potentially long delays to respond to and correct from network = partitions - inability to detect and correct load imbalance, such as flash crowd = effect - inability to detect and respond to DDOS attacks - inability to enforce different classes of service for different peers=20 - overlay instability at high churn rates, that might be caused by = increases in the number of mobile peers - no one knows what happens if the overlay population exceeds some large number, say 100M, sinces no overlays have been deployed or simulated at = that size - does it degrade gracefully or become inoperable While there are some research proposals to address some of these = problems individually, it is safe to say that no single design covers all of = them. =20 In general as long as there are overlay algorithm performance areas = which can not be automatically detected and corrected by self-organizing algorithms, then there is a need for management agent(s) to be able to monitor and intervene. =20 Sure this boundary is likely to shift over time as algorithms get = better. And monitoring the overlay can help the development of better = algorithms. =20 Here's a detailed discussion of the limits of today's P2P systems w.r.t. self-organization: B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, = 1 (March 2007), 34 pp. Here's a look at how overlay management might work: =20 J. Buford, Management of peer-to-peer overlays, International J. of = Internet Protocol Technology, Special Issue on Management of IP Networks and Services, Vol. 3, No.1, 2008, 2=9612. =20 Bottom line, ideally P2P doesn't need to be managed, but depending on = user expectations for service quality and willingness to pay, there could be deployments with overlay operators who provide this for users by = managing the overlay. =20 John =20 =20 --Boundary_(ID_rFk1V4KUYS3W2qRXWToQGA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Re: [P2PSIP] Comment on p2psip-diagnostics

Hi = Henry,

 <= /span>

I have seen that = the management of overlays has been a hot topic for ISPs and telecom = equipment vendors. Some of the thought is to use p2p technology in the ISP’s network to manage their network equipments. I would like to invite you = to the PPSP bar bof meeting which will be held on Monday 8PM to 10 PM at = Continental 3, and there the guys from China Mobile will give a great introduction to = their ongoing DSN network project which utilize the p2p technology. =A0It is exactly a = good example of management of overlay. Please refer to this draft: =

 <= /span>

http://www.ietf.org/internet-drafts/draft-zhang-ppsp-dsn-int= roduction-00.txt

 <= /span>

Hope this can = help to clarify your doubt.

 <= /span>

Dear Henry, the = authors are really appreciated to your contribution to the p2psip diagnostics = draft, and we would like to see more comments to the p2psip diagnostics = draft.

Best Regards,
Haibin
Skype: alexsonghw

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, March 19, = 2009 3:37 AM
To: buford@samrg.org
Cc: David A. Bryan; Song = Haibin; P2PSIP WG
Subject: Re: [P2PSIP] = Comment on p2psip-diagnostics

 

Well, maybe management of overlays works and also maybe it makes economic sense = (for who?).
This would have to be proven however not in papers, but in running = systems as well in market for acceptance.
Too bad the Skype and Bittorrent folks who have proven both do not care = to participate in this debate.
As an engineer, I may be excused for not believing in p2p management, = until I see the measurements and numbers.

> no one knows what happens if the overlay = population exceeds some large number, say >100M, sinces no overlays have been = deployed or simulated at that size - does it degrade >gracefully or become = inoperable

My Skype panel shows right now 16,659,464 people on line and I believe = they have 400 million subscribers.
Skype works exceedingly well for our daily family a/v sessions, coast to = coast.
Does Skype have network management agreements with all the ISPs their = p2p is crossing? :-)

>but depending on user expectations for = service quality and willingness to pay
This alone is worth a good beer BOF.
Let’s plan for one.

Henry


On 3/18/09 11:01 AM, "John Buford" <buford@samrg.org> wrote:


 
2009/3/16 Henry Sinnreich hsinnrei@adobe.com

I fully agree, since some na=EFve folks out = there (including me) think that:

  1. p2p is self = organizing – not managed – unless fixing node software is called management.
  2. p2p works across the = Internet and crosses many ISP networks,  several times even for any one = ISP. The p2p operator may not even be in friendly relations with some = the ISPs and compete with them.

Henry,
 
Current overlays have limitations.  Here's a = partial list of problems, I expect others on this list can add more:
 
- potentially long delays to respond to and correct from network = partitions
- inability to detect and correct load imbalance, such as flash crowd = effect
- inability to detect and respond to DDOS attacks
- inability to enforce different classes of service for different = peers 
- overlay instability at high churn rates, that might be caused by increases  in the number of mobile peers
- no one knows what happens if the overlay population exceeds some large number, say 100M, sinces no overlays have been deployed or simulated at = that size - does it degrade gracefully or become inoperable
While there are some research proposals to address some of these = problems individually, it is safe to say that no single design covers all of = them.
 
In general as long as there are overlay algorithm performance areas which can not be automatically detected and corrected = by self-organizing algorithms, then there is a need for management = agent(s) to be able to monitor and intervene.
 
Sure this boundary is likely to shift over time as algorithms get better.
And monitoring the overlay can help the development of better = algorithms.
 
Here's a detailed discussion of the limits of today's P2P systems = w.r.t. self-organization:
B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, = 1 (March 2007), 34 pp.

Here's a look at how overlay management might = work:
 
J. Buford, Management of peer-to-peer overlays, International J. of = Internet Protocol Technology, Special Issue on Management of IP Networks and = Services, Vol. 3, No.1, 2008, 2–12.
 
Bottom line, ideally P2P doesn't need to be = managed, but depending on user expectations for service quality and willingness = to pay, there could  be deployments with overlay operators who provide = this for users by managing the overlay.
 
John

 

 

--Boundary_(ID_rFk1V4KUYS3W2qRXWToQGA)-- From sa2086@columbia.edu Wed Mar 18 21:12:46 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C2C3A689F for ; Wed, 18 Mar 2009 21:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ComW98QIBdZU for ; Wed, 18 Mar 2009 21:12:45 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 108F43A657C for ; Wed, 18 Mar 2009 21:12:44 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2J4DSeK001313; Thu, 19 Mar 2009 00:13:28 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2J4DSds005637; Thu, 19 Mar 2009 00:13:28 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2J4DSXT005634; Thu, 19 Mar 2009 00:13:28 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 19 Mar 2009 00:13:28 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <20090318211247.74FE250822@romeo.rtfm.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 19 Mar 2009 04:12:46 -0000 On Wed, 18 Mar 2009, Bruce Lowekamp wrote: > That paper in particular, and the reasons UDP connections are more > reliably formed than TCP, have been discussed numerous times in > MMUSIC, and I really don't think we should be repeating the whole > conversation here. But the summary is that it's not nearly as > universal a solution as indicated in that paper. > > Bruce Sure. I have already mentioned that this is a IMC'05 paper and more recent data, if available, is helpful and needed. There are at least four solutions to the hop-by-hop reliability problem: (1) Clients Nodes behind TCP *un*friendly NATs can always act as clients and establish a TCP connection(s) with reachable node(s). The reachable nodes can be behind friendly NATs or they can have a public IP address. (2) Full peer but use relay peer(s) A node participates as a peer. It establishes TCP connection with reachable peers, which inturn establish a TCP connection with the nodes' connection table entries. (3) Full peer with techniques for direct TCP connection establishment A node participates as a peer and uses TCP traversal techniques for establishing direct connection (including Dean's upcoming ones:) (4) Full peer with TCP-over-UDP Since TCP traversal may fail, design/reuse a reliable congestion control protocol over UDP. Note that: (1) and (2) always work. (3) and (4) do not work well behind cascaded NATs. (4) fails behind UDP-blocking firewalls. (4) is feasible over (3) since UDP has a better chance of connection establishment when NATs are not cascaded. However, UDP blocking firewalls need to be factored in this feasible discussion. Again, any recent data is helpful. For (4), the TCP-over-UDP protocol needs to be well-designed and well-implemented. Otherwise, peers doing TCP-over-UDP may be the weakest link in the routing chain. Approaches which recover every loss using timeout may not be the most feasible ones. -salman From fluffy@cisco.com Sun Mar 22 07:35:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A39A28C0FC for ; Sun, 22 Mar 2009 07:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.441 X-Spam-Level: X-Spam-Status: No, score=-105.441 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48YSve44mCSr for ; Sun, 22 Mar 2009 07:35:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A41733A6B33 for ; Sun, 22 Mar 2009 07:35:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,402,1233532800"; d="scan'208";a="272052233" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2009 14:36:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2MEaZZY027263; Sun, 22 Mar 2009 07:36:35 -0700 Received: from dhcp-17e6.meeting.ietf.org (sjc-vpn7-848.cisco.com [10.21.147.80]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2MEaMv1025552; Sun, 22 Mar 2009 14:36:35 GMT Message-Id: From: Cullen Jennings To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Mar 2009 07:36:40 -0700 References: X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1932; t=1237732595; x=1238596595; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20possible=20agenda=20request |Sender:=20; bh=4kN3VgXH0r/uSEoT18kVIgpk61kzG+gHtkuwhITBbUM=; b=mJ8yXqnfmbMqsaUpl0vf+szqfQDMbawYNjPc7q9T8VIH8X/BDWh1fMC/+/ Qt6uiR40Tg2kZMLdcpU/S6RKMCFdUOQTZz0D1Brnxcby1HsQxOaZlD9UURwr qMckN6FR/8; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: p2psip@ietf.org Subject: Re: [P2PSIP] possible agenda request X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 22 Mar 2009 14:35:47 -0000 Ted, I remember having a some concerns and suggestions about these long ago and unfortunately since this was not on the agenda, I did not read them before the meeting. I'd be glad to go and dig up notes and try and review these but unlikely to really do anything until after the meeting. Sorry for the late review but thought I would at least say I will read it all soon. I'd like to get the base spec changed to be unified with whatever we do here. Cullen On Mar 9, 2009, at 12:04 , Ted Hardie wrote: > So, I have updated draft-hardie-p2psip-p2p-pointers to 01, > eliminating the > MIME type and focusing on the URIs. I would like to ask two > questions: > > 1) Does anyone object to a request for provisional registration at > this point, > so we can start experimenting with these? As a sub bullet, does > anyone have feedback on the IANA registries requested by this doc and > have any objections/input/better ideas? > > 2) Is anyone interested in progressing the MIME type work? I took > it out > because it seemed to overlap the application/p2p-overlay+xml stuff in > the reload base draft, and I didn't want too much confusion. I > think the cases > are distinguishable, but I wasn't sure anyone wanted the pointers to > be that > distinct from bootstrap information. If anyone does care, speaking > up now would > be handy. > > A short discussion during the meeting would resolve this, but if > folks have opinions > now and want to put them onto the mailing list, we can also likely > resolve it here. > If we do want to go forward on the URI side now, the next steps > would be discussion > on the uri-review and uri mailing lists. > regards, > Ted > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From vidyan@qualcomm.com Sun Mar 22 19:31:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BFB3A6AEC for ; Sun, 22 Mar 2009 19:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ippdta08JrK9 for ; Sun, 22 Mar 2009 19:31:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DBA083A67F0 for ; Sun, 22 Mar 2009 19:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237775511; x=1269311511; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"p2psip@ietf.org"=20|Date:=20Sun,=202 2=20Mar=202009=2019:31:48=20-0700|Subject:=20Access=20con trol=20rule=20in=20RELOAD=20to=20support=20generic=20keyw ord-like=0D=0A=20storage|Thread-Topic:=20Access=20control =20rule=20in=20RELOAD=20to=20support=20generic=20keyword- like=0D=0A=20storage|Thread-Index:=20AcmrWq3zRmMWWcvFShWz PTarvKjVgg=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5561"=3B=20a=3D"16485652"; bh=+tIBbKsgcPDuxcG0i6RqwIMmUrHpeCW1TFwtFs1L2M4=; b=RpnuaasCgcqNPdw3PiXh7aVpik4k76zdHNrqUYVvb2HdvV4d9ZPtFE7/ 8v0KZKF8Hbd1DNOG16qoBCYkrUFTKg3BhPJlwabcA+r+QjZ/yizaBw5nx VUWgCtTI07iA8Fq8rMbX3s3bQek1pFQYK0ZCjr9zG+CCQaTBeAvKaMkLO w=; X-IronPort-AV: E=McAfee;i="5300,2777,5561"; a="16485652" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2009 19:31:51 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2N2VoXS025558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 22 Mar 2009 19:31:51 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2N2VoUY017812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 22 Mar 2009 19:31:50 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sun, 22 Mar 2009 19:31:50 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Sun, 22 Mar 2009 19:31:49 -0700 From: "Narayanan, Vidya" To: "p2psip@ietf.org" Date: Sun, 22 Mar 2009 19:31:48 -0700 Thread-Topic: Access control rule in RELOAD to support generic keyword-like storage Thread-Index: AcmrWq3zRmMWWcvFShWzPTarvKjVgg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] Access control rule in RELOAD to support generic keyword-like storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 02:31:03 -0000 In addition to the access control rules defined in section 6.3 of the draft= , I think there is a need for a rule, where any node is allowed to write to= a Resource ID, but, only the creator is allowed to modify or overwrite the= entry by default. This allows for generic keyword-like storage on the ove= rlay which will eventually be needed to support various types of kinds and = usages on the overlay effectively. The notion here is that no authorizatio= n is needed on the Resource ID, but access control is applied to the data o= perations, once it exists. Here is suggestive text for supporting this:=20 "6.3.6. NO-MATCH-CREATE-WITH-RESTRICTED-UDPATE This policy allows storage of data with no constraints on choosing a Resour= ce ID. However, by default, only the creator of the entry is allowed to mo= dify or overwrite the stored data once created. The user name and/or node i= d present in the certificate of the requesting node MUST be used as the cre= ator of the data. Upon receiving a request to store, a node MUST verify if= it already has an entry present for the particular kind and Resource ID co= rresponding to the same user name or node id that is contained in the Store= Request. If so, the received Store Request MUST be treated as an update t= o the existing data and the appropriate checks as described in section 6.4 = must be applied. If no corresponding match is found, the StoredData contai= ned in the Store Request message MUST be stored as a new entry in accordanc= e with section 6.4. This rule is useful for generic keyword-like storage o= n the overlay, which is likely to be useful for several classes of applicat= ions that may be defined for use with RELOAD. The access control allows en= suring that the data created by a given node is not randomly overwritten by= any other node." It may be good to include the Resource Name in the StoredData structure as = well. This will allow the storing node to more easily create an index of t= he resources it is storing, which can then be used for retrieval of data. = However, I think it will work even without it - I'm looking for other thoug= hts on this. =20 Thanks, Vidya From vidyan@qualcomm.com Mon Mar 23 11:00:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62853A6B26 for ; Mon, 23 Mar 2009 11:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBstpehRYO9e for ; Mon, 23 Mar 2009 11:00:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DAA923A6BBF for ; Mon, 23 Mar 2009 11:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237831253; x=1269367253; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"p2psip@ietf.org"=20|Date:=20Mon,=202 3=20Mar=202009=2011:00:51=20-0700|Subject:=20Configuratio n=20Updates=20in=20RELOAD|Thread-Topic:=20Configuration =20Updates=20in=20RELOAD|Thread-Index:=20Acmr4U1UCGpDcHi7 QOqU7Z5Blyoegw=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_BE82361A0E26874DBC2ED1BA244866B938073 3BDNALASEXMB08naqu_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5562"=3B=20a=3D"16506474"; bh=isHPGipfTCy3dioUURj/2n0e1XcSUbUgrY4yP5DnXMU=; b=F5SBHmJctwz9TePawh/YQQn4WMEOAUv4HEOV1XZiKDP4V35rglMfTUYU v81FPmTCVwYuHjuff0cxkMlInV/c3JipSqkh7e8ICa55SteyN60+sXRQC hBUprPNcWqACdsZO4hKK8aBnWwKi/PM75IyVo67hmQsNNBcdKh2cgf7uw 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5562"; a="16506474" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Mar 2009 11:00:52 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2NI0qwC020459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 23 Mar 2009 11:00:52 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2NI0qLu024001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 23 Mar 2009 11:00:52 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 23 Mar 2009 11:00:52 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 23 Mar 2009 11:00:48 -0700 From: "Narayanan, Vidya" To: "p2psip@ietf.org" Date: Mon, 23 Mar 2009 11:00:51 -0700 Thread-Topic: Configuration Updates in RELOAD Thread-Index: Acmr4U1UCGpDcHi7QOqU7Z5Blyoegw== 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_BE82361A0E26874DBC2ED1BA244866B9380733BDNALASEXMB08naqu_" MIME-Version: 1.0 Subject: [P2PSIP] Configuration Updates in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2009 18:00:09 -0000 --_000_BE82361A0E26874DBC2ED1BA244866B9380733BDNALASEXMB08naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current RELOAD draft assumes that the configuration document specifies = the kinds, the associated data models and authorization rules that are appl= icable for the overlay. While it may be okay to specify the kinds the over= lay supports (thereby giving a notion of available services and application= s on the overlay), the other two things make this configuration document re= levant during the operation of an overlay itself (rather than configuration= just being a one-time thing prior to joining the overlay). This is undesi= rable in my view. For one, this involves the enrollment server into the ov= erlay functional aspects, which departs from the notion of enrollment being= a one-time thing (and the enrollment server itself not being a part of the= overlay). It also brings the question of how the latest configuration doc= ument is made available on the overlay - the enrollment server is not neces= sarily a peer or a client that can publish information on the overlay. On the other hand, I think that this role for the configuration document in= normal overlay operations can be eliminated if the requirement for knowled= ge of kind to authorization rule mapping is lifted for performing the autho= rization itself. The storing node technically only needs to know the parti= cular authorization rule that has been used for the data to be stored and v= erify that it passes authorization. The enforcement of whether that is the= right authorization for that kind can be done by the actual kind itself (o= r the usage that uses that kind). The downside of this is that a particula= r misbehaving node may use a different authorization rule than what is expe= cted for a given kind. This may at best result in garbage being stored alo= ng with other data at a particular resource id. For instance, if Alice is = well behaved, h(alice@example.org) may contain an= IP address to reach that AOR. Eve, a misbehaving user, may store some oth= er junk at h(alice@example.org) using a more flex= ible authorization rule (at the moment, assuming a good hash function, I ca= n only see this being feasible using the rule that places no constraints on= resource id generation). By ensuring that data from one creator doesn't o= verwrite data from another node, except explicitly authorized by the creato= r, h(alice@example.org) will now have data corres= ponding to multiple creators. When the data is retrieved for consumption b= y a usage, it can apply an additional check to ensure that only the data wi= th the correct authorization model is actually consumed. It is also possi= ble to place that restriction at the time of retrieval to prevent all junk = from being transported (to save bandwidth, for e.g.). There doesn't appear to be much downside in doing the above. However, I'm = open to other solutions that can take the configuration document out of the= overlay operation semantics. I'd like to keep the enrollment server (or = any other centralized entity) to the role it is actually meant for - the mo= re we engage these entities in overlay operations or kinds or usages, we st= art placing more restrictions and make it difficult to use the same design = with self-signed certs and so on. Vidya --_000_BE82361A0E26874DBC2ED1BA244866B9380733BDNALASEXMB08naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The current RELOAD draft assumes that the configuratio= n document specifies the kinds, the associated data models and authorization rules that are applicable for the overlay.  While it may be okay to specify the kinds the overlay supports (thereby giving a notion of availabl= e services and applications on the overlay), the other two things make this configuration document relevant during the operation of an overlay itself (rather than configuration just being a one-time thing prior to joining the= overlay).  This is undesirable in my view.  For one, this involves the enrollment server into the overlay functional aspects, which departs from the notion o= f enrollment being a one-time thing (and the enrollment server itself not bei= ng a part of the overlay).  It also brings the question of how the latest configuration document is made available on the overlay – the enrollm= ent server is not necessarily a peer or a client that can publish information o= n the overlay. 

 

On the other hand, I think that this role for the conf= iguration document in normal overlay operations can be eliminated if the requirement = for knowledge of kind to authorization rule mapping is lifted for performing th= e authorization itself.  The storing node technically only needs to know= the particular authorization rule that has been used for the data to be stored = and verify that it passes authorization.  The enforcement of whether that = is the right authorization for that kind can be done by the actual kind itself= (or the usage that uses that kind).  The downside of this is that a partic= ular misbehaving node may use a different authorization rule than what is expect= ed for a given kind.  This may at best result in garbage being stored alo= ng with other data at a particular resource id.  For instance, if Alice i= s well behaved, h(alice@example.org)= may contain an IP address to reach that AOR.  Eve, a misbehaving user, may store some other junk at h(alice@examp= le.org) using a more flexible authorization rule (at the moment, assuming a good ha= sh function, I can only see this being feasible using the rule that places no constraints on resource id generation).  By ensuring that data from on= e creator doesn’t overwrite data from another node, except explicitly authorized by the creator, h(alice@exa= mple.org) will now have data corresponding to multiple creators.  When the data = is retrieved for consumption by a usage, it can apply an additional check to ensure that only the data with the correct authorization model is actually consumed.   It is also possible to place that restriction at the = time of retrieval to prevent all junk from being transported (to save bandwidth,= for e.g.). 

 

There doesn’t appear to be much downside in doin= g the above.  However, I’m open to other solutions that can take the configuration document out of the overlay operation semantics.   = I’d like to keep the enrollment server (or any other centralized entity) to the role it is actually meant for – the more we engage these entities in overlay operations or kinds or usages, we start placing more restrictions a= nd make it difficult to use the same design with self-signed certs and so on. 

 

Vidya

--_000_BE82361A0E26874DBC2ED1BA244866B9380733BDNALASEXMB08naqu_-- From weber@e-technik.org Tue Mar 24 06:52:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639A928C289 for ; Tue, 24 Mar 2009 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMwfb2TlLgrZ for ; Tue, 24 Mar 2009 06:52:28 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by core3.amsl.com (Postfix) with ESMTP id 4F82028C28F for ; Tue, 24 Mar 2009 06:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1237902798; l=498; s=domk; d=e-technik.org; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Subject:To: From:X-RZG-CLASS-ID:X-RZG-AUTH; bh=hXp4umpH0SWv44INUbuk/UuTUN8M3pX5pkjOd8ngmT4=; b=dXLfeUGh3/YNbER7bkFnz8O+PAWNAgsVIQCWEHQEqoCmGEMpX2So1iLmJlF8dy+rwmX gCqtnm3DMNTckeBO72PJgeR0V+/oB9Dg8Qshij+yC4Kc+N6jqdhFtijBVb1fN3RR/xlzu zhbj9GzsBAE11bX95PFzK6l+zNihi1aOYSk= X-RZG-AUTH: :O2kGcFKIfrJESOE5Y4ECPJnapYVJq64x3Z+zRjZucC2ZWmb5tXZfWIGZK4o= X-RZG-CLASS-ID: mo00 Received: from dellweber (tklabor.fb2.fh-frankfurt.de [194.94.80.16]) by post.strato.de (mrclete mo20) (RZmta 18.28) with ESMTP id z0716el2ODbvWj for ; Tue, 24 Mar 2009 14:53:18 +0100 (MET) Message-ID: From: "Frank Weber" To: Date: Tue, 24 Mar 2009 14:53:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [P2PSIP] Expired draft-ietf-p2psip-concepts-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 24 Mar 2009 13:52:29 -0000 In draft-ietf-p2psip-concepts-02, a substantial revision is denoted for future versions of this draft. As the 02 version of this draft has already expired, could anybody please state whether (and maybe when?) a revised draft version is in sight? Thanks and best regards Frank ----------------------------------------------------------- Dipl.-Ing. (FH) Frank Weber FH Frankfurt/M. - University of Applied Sciences Research Group for Telecommunication Networks Frankfurt/M., Germany From saumitra@qualcomm.com Tue Mar 24 14:01:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0AD23A6B1E for ; Tue, 24 Mar 2009 14:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.418 X-Spam-Level: X-Spam-Status: No, score=-105.418 tagged_above=-999 required=5 tests=[AWL=1.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZP8j6iEk08X for ; Tue, 24 Mar 2009 14:01:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6CAED3A6989 for ; Tue, 24 Mar 2009 14:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1237928540; x=1269464540; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Tue,=202 4=20Mar=202009=2014:02:04=20-0700|Subject:=20targeted=20r equests|Thread-Topic:=20targeted=20requests|Thread-Index: =20Acmsw8jrNsqcCOqSSVOK103I/EC0cg=3D=3D|Message-ID:=20<2D 06DE445C2ADE44890118C3F449B9636D582DD6@NASANEXMB12.na.qua lcomm.com>|Accept-Language:=20en-US|Content-Language:=20e n-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20multipart/altern ative=3B=0D=0A=09boundary=3D"_000_2D06DE445C2ADE44890118C 3F449B9636D582DD6NASANEXMB12naqu_"|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5563"=3B=20 a=3D"16565668"; bh=JIGBG+z2Zqao8nEvO88GOBbnyUxOaHW+ch/4divXxS8=; b=lD9zpqG1mkTf4pBjHay6akrFR8lqP24A5+f9dyUX4z0hBogKi+YJJ50k US2ROALac/gLWIdbRB+diTp8eRRck2VSTh0z2EH9OJYpqTLTqFnX5vw85 5CCmVMEy8CbpYtHLowCc5veAipHw1fetTud262aY3M77HumQbOMtWd/vj k=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16565668" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 14:02:07 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2OL27eS022820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Mar 2009 14:02:07 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2OL26SS023723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Mar 2009 14:02:06 -0700 (PDT) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.33]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Tue, 24 Mar 2009 14:02:06 -0700 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Tue, 24 Mar 2009 14:02:04 -0700 Thread-Topic: targeted requests Thread-Index: Acmsw8jrNsqcCOqSSVOK103I/EC0cg== Message-ID: <2D06DE445C2ADE44890118C3F449B9636D582DD6@NASANEXMB12.na.qualcomm.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_2D06DE445C2ADE44890118C3F449B9636D582DD6NASANEXMB12naqu_" MIME-Version: 1.0 Subject: [P2PSIP] targeted requests X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 24 Mar 2009 21:01:29 -0000 --_000_2D06DE445C2ADE44890118C3F449B9636D582DD6NASANEXMB12naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One point I would like to confirm from the current draft is the separation = of the routing key from the storage and retrieval key. By routing key I mea= n the resource id/node id in the destination list and storage/retrieval key= I mean the resource id in the storereq or fetchreq. There are several impo= rtant reasons why we may want to store/fetch a data value with resource id = X on a node with node id Y where Y is not the owner of X. This can be consi= dered as a targeted STORE than a routed STORE. This is important for the following immediate reasons: 1. Successor replication which is important to have for data availability. = Some of the extensions such as the self tuning draft require successor repl= ication (a targeted STORE of resource id X on node id Y where Y is not the = owner of X) 2. Caching is likely to be an important part of a successful p2p system and= this enables targeted STOREs to be performed to nodes that will cache info= rmation. Just wanted to confirm that this is intended as part of the draft. Thanks Saumitra --_000_2D06DE445C2ADE44890118C3F449B9636D582DD6NASANEXMB12naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One point I would like to confirm from the current dra= ft is the separation of the routing key from the storage and retrieval key. By ro= uting key I mean the resource id/node id in the destination list and storage/retr= ieval key I mean the resource id in the storereq or fetchreq. There are several important reasons why we may want to store/fetch a data value with resource= id X on a node with node id Y where Y is not the owner of X. This can be considered as a targeted STORE than a routed STORE.

 

This is important for the following immediate reasons:=

1. Successor replication which is important to have fo= r data availability. Some of the extensions such as the self tuning draft require successor replication (a targeted STORE of resource id X on node id Y where= Y is not the owner of X)

2. Caching is likely to be an important part of a succ= essful p2p system and this enables targeted STOREs to be performed to nodes that w= ill cache information.

 

Just wanted to confirm that this is intended as part o= f the draft.

 

Thanks

Saumitra

--_000_2D06DE445C2ADE44890118C3F449B9636D582DD6NASANEXMB12naqu_-- From saumitra@qualcomm.com Tue Mar 24 16:37:01 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA513A63CB for ; Tue, 24 Mar 2009 16:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.549 X-Spam-Level: X-Spam-Status: No, score=-105.549 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha36unAioPXK for ; Tue, 24 Mar 2009 16:37:00 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 33B103A6863 for ; Tue, 24 Mar 2009 16:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1237937872; x=1269473872; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Tue,=202 4=20Mar=202009=2016:37:49=20-0700|Subject:=20direct=20rou ting=20support|Thread-Topic:=20direct=20routing=20support |Thread-Index:=20Acms2YrQTb19YsufSNqWTMHALbNMpw=3D=3D |Message-ID:=20<2D06DE445C2ADE44890118C3F449B9636D582DF9@ NASANEXMB12.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_2D06DE445C2ADE44890118C3F449B9636D582DF9NASANEX MB12naqu_"|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfe e=3Bi=3D"5300,2777,5563"=3B=20a=3D"16570878"; bh=uzDkID4uz0YmemPRYx35CazHP2fxqDbvZwbsjMObkY4=; b=ZS6CayrTnNzanBL6p2JhchpmbJ9Rfm3BcJKdl8vgnw/GTWQ3QmcW1k+P ifir6mDb//o0AULHbO/nbSyAuOWLVd3S/T7MzGsS+HfFA+lqUF+Kc63PJ 3otdmvcQrn5d3VG//Ejkj2JvlHS17JmJ4XjQFT4DQje+KCg7BzBuRYYk7 o=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16570878" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 16:37:51 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2ONbp1F012819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Mar 2009 16:37:51 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2ONbo9I009777 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Mar 2009 16:37:51 -0700 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.33]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 24 Mar 2009 16:37:50 -0700 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Tue, 24 Mar 2009 16:37:49 -0700 Thread-Topic: direct routing support Thread-Index: Acms2YrQTb19YsufSNqWTMHALbNMpw== Message-ID: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.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_2D06DE445C2ADE44890118C3F449B9636D582DF9NASANEXMB12naqu_" MIME-Version: 1.0 Subject: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 24 Mar 2009 23:37:01 -0000 --_000_2D06DE445C2ADE44890118C3F449B9636D582DF9NASANEXMB12naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the previous IETF there was consensus to add direct response routing as = an option in the protocol. See: http://tools.ietf.org/wg/p2psip/minutes?item=3Dminutes73.html This is not yet reflected in the base draft. My previous post to this effect with some changes is below "I would like to propose we add a flag bit in the forwarding/common header = that indicates that a direct routing response to a message be used by the r= esponding node. As a policy, implementations in certain scenarios would ena= ble the flag as necessary. If the flag is set, the requesting node also nee= ds to include its reachable address in the forwarding header. We can indicate that the responding node need not keep state to minimize co= mplications. The sending node can simply resend a request (e.g STORE) with = the flag turned off if does not receive a response to the initial STORE req= uest with the flag turned on. This allows direct routing support in scenarios where the deployer or the i= mplementation knows it is dealing with reachable IP addresses and can confi= gure the implementation to behave accordingly." Thanks Saumitra --_000_2D06DE445C2ADE44890118C3F449B9636D582DF9NASANEXMB12naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the previous IETF there was consensus to add direct response routing as an option in the protocol.

 

See: http://tools.ietf.org/wg/p2psip/minutes?item=3Dminutes73.html

 

This is not yet reflected in the base draft.

 

My previous post to this effect with some changes is &= nbsp;below

 

"I would like to propose we add a flag bit in the forwarding/common header that indicates that a direct routing response to a message be used by the responding node. As a policy, implementations in cer= tain scenarios would enable the flag as necessary. If the flag is set, the requesting node also needs to include its reachable address in the forwardi= ng header.

 

We can indicate that the responding node need not keep= state to minimize complications. The sending node can simply resend a request (e.= g STORE) with the flag turned off if does not receive a response to the initi= al STORE request with the flag turned on.

 

This allows direct routing support in scenarios where = the deployer or the implementation knows it is dealing with reachable IP addres= ses and can configure the implementation to behave accordingly."

 

Thanks

Saumitra

--_000_2D06DE445C2ADE44890118C3F449B9636D582DF9NASANEXMB12naqu_-- From vidyan@qualcomm.com Tue Mar 24 18:20:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0F93A6868 for ; Tue, 24 Mar 2009 18:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.311 X-Spam-Level: X-Spam-Status: No, score=-105.311 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9pPLjEnEsSf for ; Tue, 24 Mar 2009 18:20:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D02683A6848 for ; Tue, 24 Mar 2009 18:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237944102; x=1269480102; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Das,=20Saumitra"=20,=0D=0A=20 =20=20=20=20=20=20=20"p2psip@ietf.org"=0D=0A=09|Date:=20Tue,=2024=20Mar=202009=2018:21:09=20-0700 |Subject:=20RE:=20targeted=20requests|Thread-Topic:=20tar geted=20requests|Thread-Index:=20Acmsw8jrNsqcCOqSSVOK103I /EC0cgAI3b4w|Message-ID:=20|References:=20<2 D06DE445C2ADE44890118C3F449B9636D582DD6@NASANEXMB12.na.qu alcomm.com>|In-Reply-To:=20<2D06DE445C2ADE44890118C3F449B 9636D582DD6@NASANEXMB12.na.qualcomm.com>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5563"=3B=20a=3D"16573504"; bh=PogT/iuo9u1iximlMfsbUL0UbK7O9jeN1HKzUcdBkH4=; b=kCwTeHt8pNWq8e9zt1xNYc0Bs9h1LcmSLWXSw+XWOTsDgfNKMfQHumtM RU2T9TrornYuno61BJjCWKbE4kJkQnsCpy1HdaakuJbfBAUrAF0YNXMje 85iccxWk1WBSpkYPpBXNM4YggGH+TsyGtw2RAemVvZ32UFQd7a2En+ktf k=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16573504" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 18:21:40 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P1Leke027646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Mar 2009 18:21:40 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P1LdCY021853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Mar 2009 18:21:39 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 18:21:38 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 24 Mar 2009 18:21:10 -0700 From: "Narayanan, Vidya" To: "Das, Saumitra" , "p2psip@ietf.org" Date: Tue, 24 Mar 2009 18:21:09 -0700 Thread-Topic: targeted requests Thread-Index: Acmsw8jrNsqcCOqSSVOK103I/EC0cgAI3b4w Message-ID: References: <2D06DE445C2ADE44890118C3F449B9636D582DD6@NASANEXMB12.na.qualcomm.com> In-Reply-To: <2D06DE445C2ADE44890118C3F449B9636D582DD6@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [P2PSIP] targeted requests X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 01:20:51 -0000 Based on section 9.4, successor replication is already supported in RELOAD.= However, the following sentence makes it unsuitable for a generic targete= d STORE request, such as would be needed for caching:=20 "The peers receiving these check they came from an appropriate predecessor in their neighbor table and that they are in a range that this predecessor is responsible for, and then they store the data." I am not sure that the above check really buys much anyway. So, perhaps we= can do without it. Any node may reject a STORE request that it is unable = to honor anyway. =20 Also, I notice that section 9 is a little light on normative text. It prob= ably needs a further scrub to ensure it is implementable in an interoperabl= e fashion.=20 Thanks, Vidya From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Das, Saumitra Sent: Tuesday, March 24, 2009 2:02 PM To: p2psip@ietf.org Subject: [P2PSIP] targeted requests One point I would like to confirm from the current draft is the separation = of the routing key from the storage and retrieval key. By routing key I mea= n the resource id/node id in the destination list and storage/retrieval key= I mean the resource id in the storereq or fetchreq. There are several impo= rtant reasons why we may want to store/fetch a data value with resource id = X on a node with node id Y where Y is not the owner of X. This can be consi= dered as a targeted STORE than a routed STORE. This is important for the following immediate reasons: 1. Successor replication which is important to have for data availability. = Some of the extensions such as the self tuning draft require successor repl= ication (a targeted STORE of resource id X on node id Y where Y is not the = owner of X) 2. Caching is likely to be an important part of a successful p2p system and= this enables targeted STOREs to be performed to nodes that will cache info= rmation. Just wanted to confirm that this is intended as part of the draft. Thanks Saumitra From bbl@lowekamp.net Tue Mar 24 18:53:58 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67553A68B0 for ; Tue, 24 Mar 2009 18:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM4sox7H7Cmk for ; Tue, 24 Mar 2009 18:53:57 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 9D83C3A6881 for ; Tue, 24 Mar 2009 18:53:57 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so2068307qwb.31 for ; Tue, 24 Mar 2009 18:54:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.81.139 with SMTP id x11mr4137838qck.14.1237946088875; Tue, 24 Mar 2009 18:54:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2009 21:54:48 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Configuration Updates in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 01:53:58 -0000 Hi Vidya, So one of the key questions here is what are the use cases for updating configuration documents. - a managed overlay, where what the overlay supports is determined by the entity managing the overlay. In this case, the manager is the only entity that should be able to authorize new kinds on the overlay. Such a manager would also have contact with the overlay and the ability to inject a new configuration document. Such a document will propagate very fast once it is introduced on only a single peer. There's no requirement that the actual "enrollment server" be on the overlay, only that a document signed with the appropriate key can be introduced onto a peer. Given a CE overlay, for example, one could imagine new versions of the product (or products) being issued new configuration documents as new kinds are required. The result is that the CE devices automatically update to the newest config document whenever a new device appears on the overlay, and thus before any new kind is used on the overlay. - The choice of self-signed peer certificates is orthogonal to the question of the key used to sign the configuration document. However, if you choose to deploy an overlay where anyone can generate a new config document, I think you're right that there could be a problem. I could imagine a solution where any peer that notices its resource is not in the current configuration updates the config file, but I'm not convinced there is a significant need for this type of scenario. I'd be interested in use cases you believe would be deployed this way. I don't believe that the security issues of not having a list of auhorized kinds, even simply registering garbage in the overlay, can be ignored for many or even most overlays. Bruce 2009/3/23 Narayanan, Vidya : > The current RELOAD draft assumes that the configuration document specifie= s > the kinds, the associated data models and authorization rules that are > applicable for the overlay.=C2=A0 While it may be okay to specify the kin= ds the > overlay supports (thereby giving a notion of available services and > applications on the overlay), the other two things make this configuratio= n > document relevant during the operation of an overlay itself (rather than > configuration just being a one-time thing prior to joining the overlay). > This is undesirable in my view.=C2=A0 For one, this involves the enrollme= nt > server into the overlay functional aspects, which departs from the notion= of > enrollment being a one-time thing (and the enrollment server itself not > being a part of the overlay).=C2=A0 It also brings the question of how th= e latest > configuration document is made available on the overlay =E2=80=93 the enr= ollment > server is not necessarily a peer or a client that can publish information= on > the overlay. > > > > On the other hand, I think that this role for the configuration document = in > normal overlay operations can be eliminated if the requirement for knowle= dge > of kind to authorization rule mapping is lifted for performing the > authorization itself.=C2=A0 The storing node technically only needs to kn= ow the > particular authorization rule that has been used for the data to be store= d > and verify that it passes authorization.=C2=A0 The enforcement of whether= that is > the right authorization for that kind can be done by the actual kind itse= lf > (or the usage that uses that kind).=C2=A0 The downside of this is that a > particular misbehaving node may use a different authorization rule than w= hat > is expected for a given kind.=C2=A0 This may at best result in garbage be= ing > stored along with other data at a particular resource id.=C2=A0 For insta= nce, if > Alice is well behaved, h(alice@example.org) may contain an IP address to > reach that AOR.=C2=A0 Eve, a misbehaving user, may store some other junk = at > h(alice@example.org) using a more flexible authorization rule (at the > moment, assuming a good hash function, I can only see this being feasible > using the rule that places no constraints on resource id generation).=C2= =A0 By > ensuring that data from one creator doesn=E2=80=99t overwrite data from a= nother > node, except explicitly authorized by the creator, h(alice@example.org) w= ill > now have data corresponding to multiple creators.=C2=A0 When the data is > retrieved for consumption by a usage, it can apply an additional check to > ensure that only the data with the correct authorization model is actuall= y > consumed.=C2=A0=C2=A0 It is also possible to place that restriction at th= e time of > retrieval to prevent all junk from being transported (to save bandwidth, = for > e.g.). > > > > There doesn=E2=80=99t appear to be much downside in doing the above.=C2= =A0 However, I=E2=80=99m > open to other solutions that can take the configuration document out of t= he > overlay operation semantics.=C2=A0 =C2=A0I=E2=80=99d like to keep the enr= ollment server (or > any other centralized entity) to the role it is actually meant for =E2=80= =93 the > more we engage these entities in overlay operations or kinds or usages, w= e > start placing more restrictions and make it difficult to use the same des= ign > with self-signed certs and so on. > > > > Vidya > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From bbl@lowekamp.net Tue Mar 24 18:58:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2E93A6A9D for ; Tue, 24 Mar 2009 18:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRWEYRJZj67c for ; Tue, 24 Mar 2009 18:58:19 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 9F73D3A6A31 for ; Tue, 24 Mar 2009 18:58:19 -0700 (PDT) Received: by qyk36 with SMTP id 36so3563676qyk.29 for ; Tue, 24 Mar 2009 18:59:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.82.9 with SMTP id z9mr4034560qck.79.1237946350866; Tue, 24 Mar 2009 18:59:10 -0700 (PDT) In-Reply-To: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> Date: Tue, 24 Mar 2009 21:59:10 -0400 Message-ID: From: Bruce Lowekamp To: "Das, Saumitra" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 01:58:20 -0000 There was no consensus to include direct response in the base draft. Here's the text of the hum from the notes you point to: -------- First hum: whether or not we include direct routing as an option in the protocol (not worrying about what draft): result was consensus for including it in the protocol. -------- Direct response routing can be implemented as a forwarding option as described in the base. http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4 So while it's possible to do it in other ways, and to include those techniques in the base draft, it's not required. (obviously it's a question of group consensus on whether it should be added to the base draft) Bruce 2009/3/24 Das, Saumitra : > At the previous IETF there was consensus to add direct response routing a= s > an option in the protocol. > > > > See: http://tools.ietf.org/wg/p2psip/minutes?item=3Dminutes73.html > > > > This is not yet reflected in the base draft. > > > > My previous post to this effect with some changes is =C2=A0below > > > > "I would like to propose we add a flag bit in the forwarding/common heade= r > that indicates that a direct routing response to a message be used by the > responding node. As a policy, implementations in certain scenarios would > enable the flag as necessary. If the flag is set, the requesting node als= o > needs to include its reachable address in the forwarding header. > > > > We can indicate that the responding node need not keep state to minimize > complications. The sending node can simply resend a request (e.g STORE) w= ith > the flag turned off if does not receive a response to the initial STORE > request with the flag turned on. > > > > This allows direct routing support in scenarios where the deployer or the > implementation knows it is dealing with reachable IP addresses and can > configure the implementation to behave accordingly." > > > > Thanks > > Saumitra > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From vidyan@qualcomm.com Tue Mar 24 22:03:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B66B3A68A0 for ; Tue, 24 Mar 2009 22:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.454 X-Spam-Level: X-Spam-Status: No, score=-105.454 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek-ewaNfgi3t for ; Tue, 24 Mar 2009 22:03:12 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9C29C3A68B1 for ; Tue, 24 Mar 2009 22:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237957444; x=1269493444; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Tue,=2024=20Mar=20200 9=2022:04:00=20-0700|Subject:=20RE:=20[P2PSIP]=20Configur ation=20Updates=20in=20RELOAD|Thread-Topic:=20[P2PSIP]=20 Configuration=20Updates=20in=20RELOAD|Thread-Index:=20Acm s7LKGFft55R1fREWtNklcK3AaWQAF1iJw|Message-ID:=20|References:=20 =0D=0A=09=20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5563"=3B=20 a=3D"16582612"; bh=dwK0rJiumrCiMhNivs9Soau6fgU+NokU24EEXanNXAo=; b=hUb/nc7GlNlOm3Z1ZCVdSScMHRDIkOKT3XsO5aDV7ZXPMCFRn2BH7hue sGOuAfYkGEmD4mIh1UyA4bFrgFFoqLhNxOJJ3EwXGhewGYMqrhrtG8G4V ucSy7ReaP4jYebdsfZNGwS3wyajzjQy8eDWWf9UgHa4uT97idonrfKzFX M=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16582612" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 22:04:04 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P544eq000644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 22:04:04 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P543sB030291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 22:04:03 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 22:04:03 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Tue, 24 Mar 2009 22:04:02 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp Date: Tue, 24 Mar 2009 22:04:00 -0700 Thread-Topic: [P2PSIP] Configuration Updates in RELOAD Thread-Index: Acms7LKGFft55R1fREWtNklcK3AaWQAF1iJw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Configuration Updates in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 05:03:14 -0000 SGkgQnJ1Y2UsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJ1Y2Ug TG93ZWthbXAgW21haWx0bzpiYmxAbG93ZWthbXAubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBNYXJj aCAyNCwgMjAwOSA2OjU1IFBNDQo+IFRvOiBOYXJheWFuYW4sIFZpZHlhDQo+IENjOiBwMnBzaXBA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtQMlBTSVBdIENvbmZpZ3VyYXRpb24gVXBkYXRlcyBp biBSRUxPQUQNCj4gDQo+IEhpIFZpZHlhLA0KPiANCj4gU28gb25lIG9mIHRoZSBrZXkgcXVlc3Rp b25zIGhlcmUgaXMgd2hhdCBhcmUgdGhlIHVzZSBjYXNlcyBmb3INCj4gdXBkYXRpbmcgY29uZmln dXJhdGlvbiBkb2N1bWVudHMuDQo+IA0KPiAtIGEgbWFuYWdlZCBvdmVybGF5LCB3aGVyZSB3aGF0 IHRoZSBvdmVybGF5IHN1cHBvcnRzIGlzIGRldGVybWluZWQgYnkNCj4gdGhlIGVudGl0eSBtYW5h Z2luZyB0aGUgb3ZlcmxheS4gIEluIHRoaXMgY2FzZSwgdGhlIG1hbmFnZXIgaXMgdGhlDQo+IG9u bHkgZW50aXR5IHRoYXQgc2hvdWxkIGJlIGFibGUgdG8gYXV0aG9yaXplIG5ldyBraW5kcyBvbiB0 aGUgb3ZlcmxheS4NCg0KVGhpcyBtYXkgYmUgb25lIG1vZGVsLCBidXQgSSBjZXJ0YWlubHkgZG9u J3QgdGhpbmsgdGhpcyBpcyB0aGUgb25seSBtb2RlbCBwb3NzaWJsZSBmb3IgbWFuYWdlZCBvdmVy bGF5cy4gSSB0aGluayB3ZSBhcmUgYmVpbmcgd2F5IHRvbyBuYXJyb3cgaGVyZSB3aXRoIG91ciB2 aWV3cyBvbiBob3cgdGhpcyBtYXkgZ2V0IGRlcGxveWVkLiBJIGNhbiBlbnZpc2lvbiBzZXZlcmFs IHR5cGVzIG9mIG1hbmFnZWQgb3ZlcmxheXMsIGVzcGVjaWFsbHkgb25lcyB3aGVyZSB0aGUgZW5y b2xsbWVudCwgYXMgYSBmdW5jdGlvbiwgbWF5IGJlIHByb3ZpZGVkIGJ5IHNvbWUgZW50aXR5IHRo YXQgaXMgY29tcGxldGVseSBkaWZmZXJlbnQgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlcnMgb24g dGhvc2Ugb3ZlcmxheXMgdGhhdCBhcmUgb2ZmZXJpbmcgc2VydmljZXMvYXBwbGljYXRpb25zLiAg SSdkIGxpa2UgdG8gc2VlIGEgY2xlYXIgc2VwYXJhdGlvbiBpbiBmdW5jdGlvbmFsaXR5IGJldHdl ZW4gdGhlIGVucm9sbG1lbnQgc2VydmVyIGFuZCBhbnkgaW52b2x2ZW1lbnQgaW4gYWN0dWFsIG9w ZXJhdGlvbnMgb2YgdGhlIG92ZXJsYXksIGluY2x1ZGluZyB0aGUgdHlwZXMgb2Ygc2VydmljZXMg dGhhdCBhcmUgb2ZmZXJlZCBvbiB0aGUgb3ZlcmxheS4gIEkgdGhpbmsgdGhpcyBmdW5jdGlvbmFs IHNlcGFyYXRpb24gaXMgZXNzZW50aWFsIHRvIGVuc3VyZSB0aGF0IHdlIHByb3ZpZGUgZmxleGli bGUgZGVwbG95bWVudCBvcHRpb25zLiAgDQoNCj4gIFN1Y2ggYSBtYW5hZ2VyIHdvdWxkIGFsc28g aGF2ZSBjb250YWN0IHdpdGggdGhlIG92ZXJsYXkgYW5kIHRoZQ0KPiBhYmlsaXR5IHRvIGluamVj dCBhIG5ldyBjb25maWd1cmF0aW9uIGRvY3VtZW50LiAgDQoNCllvdSBhcmUgYXNzdW1pbmcgaGVy ZSB0aGF0IHRoZSBtYW5hZ2VyIGNvbW11bmljYXRlcyB3aXRoIGEgbm9kZSBvbiB0aGUgb3Zlcmxh eSBwb3RlbnRpYWxseSB2aWEgb3V0LW9mLWJhbmQgbWVhbnMgdG8gZG8gdGhpcy4gIA0KDQo+IFN1 Y2ggYSBkb2N1bWVudCB3aWxsDQo+IHByb3BhZ2F0ZSB2ZXJ5IGZhc3Qgb25jZSBpdCBpcyBpbnRy b2R1Y2VkIG9uIG9ubHkgYSBzaW5nbGUgcGVlci4NCj4gVGhlcmUncyBubyByZXF1aXJlbWVudCB0 aGF0IHRoZSBhY3R1YWwgImVucm9sbG1lbnQgc2VydmVyIiBiZSBvbiB0aGUNCj4gb3ZlcmxheSwg b25seSB0aGF0IGEgZG9jdW1lbnQgc2lnbmVkIHdpdGggdGhlIGFwcHJvcHJpYXRlIGtleSBjYW4g YmUNCj4gaW50cm9kdWNlZCBvbnRvIGEgcGVlci4gIEdpdmVuIGEgQ0Ugb3ZlcmxheSwgZm9yIGV4 YW1wbGUsIG9uZSBjb3VsZA0KPiBpbWFnaW5lIG5ldyB2ZXJzaW9ucyBvZiB0aGUgcHJvZHVjdCAo b3IgcHJvZHVjdHMpIGJlaW5nIGlzc3VlZCBuZXcNCj4gY29uZmlndXJhdGlvbiBkb2N1bWVudHMg YXMgbmV3IGtpbmRzIGFyZSByZXF1aXJlZC4gIFRoZSByZXN1bHQgaXMgdGhhdA0KPiB0aGUgQ0Ug ZGV2aWNlcyBhdXRvbWF0aWNhbGx5IHVwZGF0ZSB0byB0aGUgbmV3ZXN0IGNvbmZpZyBkb2N1bWVu dA0KPiB3aGVuZXZlciBhIG5ldyBkZXZpY2UgYXBwZWFycyBvbiB0aGUgb3ZlcmxheSwgYW5kIHRo dXMgYmVmb3JlIGFueSBuZXcNCj4ga2luZCBpcyB1c2VkIG9uIHRoZSBvdmVybGF5Lg0KPiANCg0K UGFyZG9uIG15IGlnbm9yYW5jZSAtIHdoYXQncyBhIENFIG92ZXJsYXk/IA0KDQo+IC0gVGhlIGNo b2ljZSBvZiBzZWxmLXNpZ25lZCBwZWVyIGNlcnRpZmljYXRlcyBpcyBvcnRob2dvbmFsIHRvIHRo ZQ0KPiBxdWVzdGlvbiBvZiB0aGUga2V5IHVzZWQgdG8gc2lnbiB0aGUgY29uZmlndXJhdGlvbiBk b2N1bWVudC4NCj4gSG93ZXZlciwgaWYgeW91IGNob29zZSB0byBkZXBsb3kgYW4gb3ZlcmxheSB3 aGVyZSBhbnlvbmUgY2FuIGdlbmVyYXRlDQo+IGEgbmV3IGNvbmZpZyBkb2N1bWVudCwgSSB0aGlu ayB5b3UncmUgcmlnaHQgdGhhdCB0aGVyZSBjb3VsZCBiZSBhDQo+IHByb2JsZW0uICBJIGNvdWxk IGltYWdpbmUgYSBzb2x1dGlvbiB3aGVyZSBhbnkgcGVlciB0aGF0IG5vdGljZXMgaXRzDQo+IHJl c291cmNlIGlzIG5vdCBpbiB0aGUgY3VycmVudCBjb25maWd1cmF0aW9uIHVwZGF0ZXMgdGhlIGNv bmZpZyBmaWxlLA0KPiBidXQgSSdtIG5vdCBjb252aW5jZWQgdGhlcmUgaXMgYSBzaWduaWZpY2Fu dCBuZWVkIGZvciB0aGlzIHR5cGUgb2YNCj4gc2NlbmFyaW8uICBJJ2QgYmUgaW50ZXJlc3RlZCBp biB1c2UgY2FzZXMgeW91IGJlbGlldmUgd291bGQgYmUNCj4gZGVwbG95ZWQgdGhpcyB3YXkuDQo+ IA0KDQpBcmUgeW91IGFza2luZyBmb3IgdXNlIGNhc2VzIHRoYXQgd2lsbCBiZSBkZXBsb3llZCB3 aXRoIHNlbGYtc2lnbmVkIGNlcnRzIGF0IGFsbCBvciB1c2UgY2FzZXMgdGhhdCBvcGVyYXRlIHdp dGggc2VsZi1zaWduZWQgY2VydHMgd2hlcmUgdGhlIHBlZXJzIGFyZSB1cGRhdGluZyBjb25maWcg ZmlsZXM/ICBPZiBjb3Vyc2UsIHRoZXJlIGFyZSBwbGVudHkgb2YgdXNlIGNhc2VzIGZvciBqdXN0 IHRoZSBmb3JtZXIuICBGb3IgdGhlIGxhdHRlciwgSSdkIGFyZ3VlIHRoYXQgdGhlIGNvbmZpZyBm aWxlIHNlcnZlcyBubyBwdXJwb3NlIG90aGVyIHRoYW4gc3RyaWN0IGNvbmZpZyBwYXJhbWV0ZXJz IGFuZCBoZW5jZSwgc2hvdWxkIG5ldmVyIG5lZWQgdG8gYmUgdXBkYXRlZCBhcyBwYXJ0IG9mIHRo ZSBvdmVybGF5IG9wZXJhdGlvbnMuIA0KDQo+IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoZSBzZWN1 cml0eSBpc3N1ZXMgb2Ygbm90IGhhdmluZyBhIGxpc3Qgb2YNCj4gYXVob3JpemVkIGtpbmRzLCBl dmVuIHNpbXBseSByZWdpc3RlcmluZyBnYXJiYWdlIGluIHRoZSBvdmVybGF5LCBjYW4NCj4gYmUg aWdub3JlZCBmb3IgbWFueSBvciBldmVuIG1vc3Qgb3ZlcmxheXMuDQo+IA0KDQpBY3R1YWxseSwg SSBkb24ndCB0aGluayBzby4gIFN0b3JpbmcgZ2FyYmFnZSBvbiB0aGUgb3ZlcmxheSBpcyBmZWFz aWJsZSBhbnl3YXkgYW5kIGFuIGF1dGhvcml6ZWQgbm9kZSBjb3VsZCBhbHNvIGRvIHRoaXMuICBT bywgSSBkb24ndCB0aGluayByZW1vdmluZyB0aGlzIGtpbmQtc3BlY2lmaWMgYXV0aG9yaXphdGlv biByZXF1aXJlbWVudCBhdCB0aGUgb3ZlcmxheSBsZXZlbCBpcyBnb2luZyB0byBtYWtlIGFueSBz aWduaWZpY2FudGx5IHdvcnNlLiAgVGhlIGFkZGl0aW9uYWwgYXV0aG9yaXphdGlvbiBzdGVwcyB0 aGF0IGNhbiBiZSBhcHBsaWVkIGF0IHRoZSBraW5kIGFuZC9vciBkYXRhIHJldHJpZXZhbCBsZXZl bCBjYW4gYWx3YXlzIHJlbWVkeSBpdCB0b28gLSBzbywgSSBhbSBub3Qgc2VlaW5nIGEgZ3JlYXQg cmlzayBoZXJlLiANCg0KVmlkeWEgDQoNCj4gQnJ1Y2UNCj4gDQo+IA0KPiANCj4gMjAwOS8zLzIz IE5hcmF5YW5hbiwgVmlkeWEgPHZpZHlhbkBxdWFsY29tbS5jb20+Og0KPiA+IFRoZSBjdXJyZW50 IFJFTE9BRCBkcmFmdCBhc3N1bWVzIHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24gZG9jdW1lbnQNCj4g c3BlY2lmaWVzDQo+ID4gdGhlIGtpbmRzLCB0aGUgYXNzb2NpYXRlZCBkYXRhIG1vZGVscyBhbmQg YXV0aG9yaXphdGlvbiBydWxlcyB0aGF0DQo+IGFyZQ0KPiA+IGFwcGxpY2FibGUgZm9yIHRoZSBv dmVybGF5LsKgIFdoaWxlIGl0IG1heSBiZSBva2F5IHRvIHNwZWNpZnkgdGhlDQo+IGtpbmRzIHRo ZQ0KPiA+IG92ZXJsYXkgc3VwcG9ydHMgKHRoZXJlYnkgZ2l2aW5nIGEgbm90aW9uIG9mIGF2YWls YWJsZSBzZXJ2aWNlcyBhbmQNCj4gPiBhcHBsaWNhdGlvbnMgb24gdGhlIG92ZXJsYXkpLCB0aGUg b3RoZXIgdHdvIHRoaW5ncyBtYWtlIHRoaXMNCj4gY29uZmlndXJhdGlvbg0KPiA+IGRvY3VtZW50 IHJlbGV2YW50IGR1cmluZyB0aGUgb3BlcmF0aW9uIG9mIGFuIG92ZXJsYXkgaXRzZWxmIChyYXRo ZXINCj4gdGhhbg0KPiA+IGNvbmZpZ3VyYXRpb24ganVzdCBiZWluZyBhIG9uZS10aW1lIHRoaW5n IHByaW9yIHRvIGpvaW5pbmcgdGhlDQo+IG92ZXJsYXkpLg0KPiA+IFRoaXMgaXMgdW5kZXNpcmFi bGUgaW4gbXkgdmlldy7CoCBGb3Igb25lLCB0aGlzIGludm9sdmVzIHRoZQ0KPiBlbnJvbGxtZW50 DQo+ID4gc2VydmVyIGludG8gdGhlIG92ZXJsYXkgZnVuY3Rpb25hbCBhc3BlY3RzLCB3aGljaCBk ZXBhcnRzIGZyb20gdGhlDQo+IG5vdGlvbiBvZg0KPiA+IGVucm9sbG1lbnQgYmVpbmcgYSBvbmUt dGltZSB0aGluZyAoYW5kIHRoZSBlbnJvbGxtZW50IHNlcnZlciBpdHNlbGYNCj4gbm90DQo+ID4g YmVpbmcgYSBwYXJ0IG9mIHRoZSBvdmVybGF5KS7CoCBJdCBhbHNvIGJyaW5ncyB0aGUgcXVlc3Rp b24gb2YgaG93IHRoZQ0KPiBsYXRlc3QNCj4gPiBjb25maWd1cmF0aW9uIGRvY3VtZW50IGlzIG1h ZGUgYXZhaWxhYmxlIG9uIHRoZSBvdmVybGF5IOKAkyB0aGUNCj4gZW5yb2xsbWVudA0KPiA+IHNl cnZlciBpcyBub3QgbmVjZXNzYXJpbHkgYSBwZWVyIG9yIGEgY2xpZW50IHRoYXQgY2FuIHB1Ymxp c2gNCj4gaW5mb3JtYXRpb24gb24NCj4gPiB0aGUgb3ZlcmxheS4NCj4gPg0KPiA+DQo+ID4NCj4g PiBPbiB0aGUgb3RoZXIgaGFuZCwgSSB0aGluayB0aGF0IHRoaXMgcm9sZSBmb3IgdGhlIGNvbmZp Z3VyYXRpb24NCj4gZG9jdW1lbnQgaW4NCj4gPiBub3JtYWwgb3ZlcmxheSBvcGVyYXRpb25zIGNh biBiZSBlbGltaW5hdGVkIGlmIHRoZSByZXF1aXJlbWVudCBmb3INCj4ga25vd2xlZGdlDQo+ID4g b2Yga2luZCB0byBhdXRob3JpemF0aW9uIHJ1bGUgbWFwcGluZyBpcyBsaWZ0ZWQgZm9yIHBlcmZv cm1pbmcgdGhlDQo+ID4gYXV0aG9yaXphdGlvbiBpdHNlbGYuwqAgVGhlIHN0b3Jpbmcgbm9kZSB0 ZWNobmljYWxseSBvbmx5IG5lZWRzIHRvDQo+IGtub3cgdGhlDQo+ID4gcGFydGljdWxhciBhdXRo b3JpemF0aW9uIHJ1bGUgdGhhdCBoYXMgYmVlbiB1c2VkIGZvciB0aGUgZGF0YSB0byBiZQ0KPiBz dG9yZWQNCj4gPiBhbmQgdmVyaWZ5IHRoYXQgaXQgcGFzc2VzIGF1dGhvcml6YXRpb24uwqAgVGhl IGVuZm9yY2VtZW50IG9mIHdoZXRoZXINCj4gdGhhdCBpcw0KPiA+IHRoZSByaWdodCBhdXRob3Jp emF0aW9uIGZvciB0aGF0IGtpbmQgY2FuIGJlIGRvbmUgYnkgdGhlIGFjdHVhbCBraW5kDQo+IGl0 c2VsZg0KPiA+IChvciB0aGUgdXNhZ2UgdGhhdCB1c2VzIHRoYXQga2luZCkuwqAgVGhlIGRvd25z aWRlIG9mIHRoaXMgaXMgdGhhdCBhDQo+ID4gcGFydGljdWxhciBtaXNiZWhhdmluZyBub2RlIG1h eSB1c2UgYSBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbiBydWxlDQo+IHRoYW4gd2hhdA0KPiA+IGlz IGV4cGVjdGVkIGZvciBhIGdpdmVuIGtpbmQuwqAgVGhpcyBtYXkgYXQgYmVzdCByZXN1bHQgaW4g Z2FyYmFnZQ0KPiBiZWluZw0KPiA+IHN0b3JlZCBhbG9uZyB3aXRoIG90aGVyIGRhdGEgYXQgYSBw YXJ0aWN1bGFyIHJlc291cmNlIGlkLsKgIEZvcg0KPiBpbnN0YW5jZSwgaWYNCj4gPiBBbGljZSBp cyB3ZWxsIGJlaGF2ZWQsIGgoYWxpY2VAZXhhbXBsZS5vcmcpIG1heSBjb250YWluIGFuIElQIGFk ZHJlc3MNCj4gdG8NCj4gPiByZWFjaCB0aGF0IEFPUi7CoCBFdmUsIGEgbWlzYmVoYXZpbmcgdXNl ciwgbWF5IHN0b3JlIHNvbWUgb3RoZXIganVuaw0KPiBhdA0KPiA+IGgoYWxpY2VAZXhhbXBsZS5v cmcpIHVzaW5nIGEgbW9yZSBmbGV4aWJsZSBhdXRob3JpemF0aW9uIHJ1bGUgKGF0IHRoZQ0KPiA+ IG1vbWVudCwgYXNzdW1pbmcgYSBnb29kIGhhc2ggZnVuY3Rpb24sIEkgY2FuIG9ubHkgc2VlIHRo aXMgYmVpbmcNCj4gZmVhc2libGUNCj4gPiB1c2luZyB0aGUgcnVsZSB0aGF0IHBsYWNlcyBubyBj b25zdHJhaW50cyBvbiByZXNvdXJjZSBpZA0KPiBnZW5lcmF0aW9uKS7CoCBCeQ0KPiA+IGVuc3Vy aW5nIHRoYXQgZGF0YSBmcm9tIG9uZSBjcmVhdG9yIGRvZXNu4oCZdCBvdmVyd3JpdGUgZGF0YSBm cm9tDQo+IGFub3RoZXINCj4gPiBub2RlLCBleGNlcHQgZXhwbGljaXRseSBhdXRob3JpemVkIGJ5 IHRoZSBjcmVhdG9yLA0KPiBoKGFsaWNlQGV4YW1wbGUub3JnKSB3aWxsDQo+ID4gbm93IGhhdmUg ZGF0YSBjb3JyZXNwb25kaW5nIHRvIG11bHRpcGxlIGNyZWF0b3JzLsKgIFdoZW4gdGhlIGRhdGEg aXMNCj4gPiByZXRyaWV2ZWQgZm9yIGNvbnN1bXB0aW9uIGJ5IGEgdXNhZ2UsIGl0IGNhbiBhcHBs eSBhbiBhZGRpdGlvbmFsDQo+IGNoZWNrIHRvDQo+ID4gZW5zdXJlIHRoYXQgb25seSB0aGUgZGF0 YSB3aXRoIHRoZSBjb3JyZWN0IGF1dGhvcml6YXRpb24gbW9kZWwgaXMNCj4gYWN0dWFsbHkNCj4g PiBjb25zdW1lZC7CoMKgIEl0IGlzIGFsc28gcG9zc2libGUgdG8gcGxhY2UgdGhhdCByZXN0cmlj dGlvbiBhdCB0aGUgdGltZQ0KPiBvZg0KPiA+IHJldHJpZXZhbCB0byBwcmV2ZW50IGFsbCBqdW5r IGZyb20gYmVpbmcgdHJhbnNwb3J0ZWQgKHRvIHNhdmUNCj4gYmFuZHdpZHRoLCBmb3INCj4gPiBl LmcuKS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGVyZSBkb2VzbuKAmXQgYXBwZWFyIHRvIGJlIG11 Y2ggZG93bnNpZGUgaW4gZG9pbmcgdGhlIGFib3ZlLg0KPiBIb3dldmVyLCBJ4oCZbQ0KPiA+IG9w ZW4gdG8gb3RoZXIgc29sdXRpb25zIHRoYXQgY2FuIHRha2UgdGhlIGNvbmZpZ3VyYXRpb24gZG9j dW1lbnQgb3V0DQo+IG9mIHRoZQ0KPiA+IG92ZXJsYXkgb3BlcmF0aW9uIHNlbWFudGljcy7CoCDC oEnigJlkIGxpa2UgdG8ga2VlcCB0aGUgZW5yb2xsbWVudCBzZXJ2ZXINCj4gKG9yDQo+ID4gYW55 IG90aGVyIGNlbnRyYWxpemVkIGVudGl0eSkgdG8gdGhlIHJvbGUgaXQgaXMgYWN0dWFsbHkgbWVh bnQgZm9yIOKAkw0KPiB0aGUNCj4gPiBtb3JlIHdlIGVuZ2FnZSB0aGVzZSBlbnRpdGllcyBpbiBv dmVybGF5IG9wZXJhdGlvbnMgb3Iga2luZHMgb3INCj4gdXNhZ2VzLCB3ZQ0KPiA+IHN0YXJ0IHBs YWNpbmcgbW9yZSByZXN0cmljdGlvbnMgYW5kIG1ha2UgaXQgZGlmZmljdWx0IHRvIHVzZSB0aGUg c2FtZQ0KPiBkZXNpZ24NCj4gPiB3aXRoIHNlbGYtc2lnbmVkIGNlcnRzIGFuZCBzbyBvbi4NCj4g Pg0KPiA+DQo+ID4NCj4gPiBWaWR5YQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+ID4gUDJQ U0lQQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w MnBzaXANCj4gPg0KPiA+DQo= From vidyan@qualcomm.com Tue Mar 24 22:07:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B033A68A0 for ; Tue, 24 Mar 2009 22:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNhVXMyrX5ay for ; Tue, 24 Mar 2009 22:07:25 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5776D3A6818 for ; Tue, 24 Mar 2009 22:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237957697; x=1269493697; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20,=20"Das,=20Saumi tra"=20|CC:=20"p2psip@ietf.org"=20 |Date:=20Tue,=2024=20Mar=202009=2022:08: 12=20-0700|Subject:=20RE:=20[P2PSIP]=20direct=20routing =20support|Thread-Topic:=20[P2PSIP]=20direct=20routing=20 support|Thread-Index:=20Acms7VXapjO/4qNDTRuUoBHQEXnQNwAGc uVg|Message-ID:=20|References:=20<2D06DE445C 2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.co m>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en -US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5563"=3B=20 a=3D"16567646"; bh=BFbQd/3RakPTNtOSXEiEx7mzyj8ZdLuvCmjMqkgpY6M=; b=yumadR189om33pO83VogKqW0mndpNMJN1LLSWvcUPhVcoIcurV2e6eNa 9+u3ajOnVJWvKvNPlCXmniyUJ8sM+tWximxo0koWCIg4O3wBj/EPTdfHj IE4Bx/U9VB0lSAdw/gdKRS5hRb9/f7D7BnR1WjpsGBzqt+crYuFEboSVy 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16567646" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 22:08:17 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P58G5k001070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 22:08:17 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P58ELG027786 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 22:08:16 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 22:08:14 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 24 Mar 2009 22:08:13 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp , "Das, Saumitra" Date: Tue, 24 Mar 2009 22:08:12 -0700 Thread-Topic: [P2PSIP] direct routing support Thread-Index: Acms7VXapjO/4qNDTRuUoBHQEXnQNwAGcuVg Message-ID: References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 05:07:27 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcDJwc2lwLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpwMnBzaXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9m IEJydWNlIExvd2VrYW1wDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI0LCAyMDA5IDY6NTkgUE0N Cj4gVG86IERhcywgU2F1bWl0cmENCj4gQ2M6IHAycHNpcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW1AyUFNJUF0gZGlyZWN0IHJvdXRpbmcgc3VwcG9ydA0KPiANCj4gVGhlcmUgd2FzIG5vIGNv bnNlbnN1cyB0byBpbmNsdWRlIGRpcmVjdCByZXNwb25zZSBpbiB0aGUgYmFzZSBkcmFmdC4NCj4g SGVyZSdzIHRoZSB0ZXh0IG9mIHRoZSBodW0gZnJvbSB0aGUgbm90ZXMgeW91IHBvaW50IHRvOg0K PiANCj4gLS0tLS0tLS0NCj4gRmlyc3QgaHVtOiAgd2hldGhlciBvciBub3Qgd2UgaW5jbHVkZSBk aXJlY3Qgcm91dGluZyBhcyBhbiBvcHRpb24gaW4NCj4gdGhlIHByb3RvY29sIChub3Qgd29ycnlp bmcgYWJvdXQgd2hhdCBkcmFmdCk6ICByZXN1bHQgd2FzIGNvbnNlbnN1cw0KPiBmb3IgaW5jbHVk aW5nIGl0IGluIHRoZSBwcm90b2NvbC4NCj4gLS0tLS0tLS0NCj4gDQoNClJpZ2h0LCB0aGVyZSB3 YXMgY29uc2Vuc3VzIHRvIGluY2x1ZGUgaXQgaW4gdGhlIGJhc2UgcHJvdG9jb2wuICBUbyBtZSwg aXQgd291bGQgbWFrZSBzZW5zZSB0byBhZGQgaXQgdG8gdGhlIGJhc2UgZHJhZnQsIHNpbmNlIGl0 IGRvZXNuJ3Qgc2VlbSB0byBtYWtlIHNlbnNlIHRvIHNheSBpbiB0aGUgYmFzZSBkcmFmdCB0aGF0 IGl0IGlzIG5vdCBwZXJtaXR0ZWQgYW5kIHlldCBoYXZlIHRoZSBub3Rpb24gb2YgYWxsb3dpbmcg aXQgaW4gdGhlIGJhc2UgcHJvdG9jb2wuICANCg0KPiBEaXJlY3QgcmVzcG9uc2Ugcm91dGluZyBj YW4gYmUgaW1wbGVtZW50ZWQgYXMgYSBmb3J3YXJkaW5nIG9wdGlvbiBhcw0KPiBkZXNjcmliZWQg aW4gdGhlIGJhc2UuDQo+IA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXAycHNpcC1iYXNlLTAyI3NlY3Rpb24tNS4zLjIuNA0KPiANCg0KSSdtIGFzc3VtaW5nIHRoYXQg eW91IGFyZSB0YWxraW5nIGFib3V0IGEgeWV0LXRvLWJlLWRlZmluZWQgZm9yd2FyZGluZyBvcHRp b24/ICBPciwgZGlkIEkgbWlzcyBzb21ldGhpbmcgdGhhdCBpcyBhbHJlYWR5IHNwZWNpZmllZCB0 aGF0IGNhbiBiZSB1c2VkIGZvciB0aGlzIHB1cnBvc2U/IA0KDQpJIHRoaW5rIGRlZmluaW5nIGEg Zm9yd2FyZGluZyBvcHRpb24gZm9yIHRoaXMgZG9lcyBtYWtlIHNlbnNlIGFuZCBjb3JyZXNwb25k aW5nIHRvIHRoYXQgb3B0aW9uLCB3ZSBuZWVkIHRvIHNheSB3aGF0IHRoZSBmb3J3YXJkaW5nIGJl aGF2aW9yIHNob3VsZCBiZS4gIFRoZSBub2RlIHNlbmRpbmcgdGhlIHJlcXVlc3QgYWxzbyBuZWVk cyB0byBwcm92aWRlIGl0cyBkaXJlY3QgcmVhY2hhYmlsaXR5IHBhcmFtZXRlcnMgaW4gdGhlIG1l c3NhZ2UuICANCg0KV2hpbGUgd2UgYXJlIG9uIHRoZSB0b3BpYyBvZiBmb3J3YXJkaW5nIG9wdGlv bnMsIGNvdWxkIGFueW9uZSBkZXNjcmliZSB0aGUgcHVycG9zZSBvZiB0aGUgb25lcyB0aGF0IGFy ZSBhbHJlYWR5IGRlZmluZWQgaW4gc2VjdGlvbiA1LjMuMi40PyAgSSBkb27igJl0IHF1aXRlIHNl ZSBhbiBleHBsYW5hdGlvbiBhbmQgSSBhbSBxdWl0ZSBwZXJwbGV4ZWQgYnkgdGhlbSA6KSANCg0K VGhhbmtzLA0KVmlkeWENCg0KPiBTbyB3aGlsZSBpdCdzIHBvc3NpYmxlIHRvIGRvIGl0IGluIG90 aGVyIHdheXMsIGFuZCB0byBpbmNsdWRlIHRob3NlDQo+IHRlY2huaXF1ZXMgaW4gdGhlIGJhc2Ug ZHJhZnQsIGl0J3Mgbm90IHJlcXVpcmVkLg0KPiANCj4gKG9idmlvdXNseSBpdCdzIGEgcXVlc3Rp b24gb2YgZ3JvdXAgY29uc2Vuc3VzIG9uIHdoZXRoZXIgaXQgc2hvdWxkIGJlDQo+IGFkZGVkIHRv IHRoZSBiYXNlIGRyYWZ0KQ0KPiANCj4gQnJ1Y2UNCj4gDQo+IA0KPiAyMDA5LzMvMjQgRGFzLCBT YXVtaXRyYSA8c2F1bWl0cmFAcXVhbGNvbW0uY29tPjoNCj4gPiBBdCB0aGUgcHJldmlvdXMgSUVU RiB0aGVyZSB3YXMgY29uc2Vuc3VzIHRvIGFkZCBkaXJlY3QgcmVzcG9uc2UNCj4gcm91dGluZyBh cw0KPiA+IGFuIG9wdGlvbiBpbiB0aGUgcHJvdG9jb2wuDQo+ID4NCj4gPg0KPiA+DQo+ID4gU2Vl OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcDJwc2lwL21pbnV0ZXM/aXRlbT1taW51dGVzNzMu aHRtbA0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoaXMgaXMgbm90IHlldCByZWZsZWN0ZWQgaW4gdGhl IGJhc2UgZHJhZnQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gTXkgcHJldmlvdXMgcG9zdCB0byB0aGlz IGVmZmVjdCB3aXRoIHNvbWUgY2hhbmdlcyBpcyDCoGJlbG93DQo+ID4NCj4gPg0KPiA+DQo+ID4g Ikkgd291bGQgbGlrZSB0byBwcm9wb3NlIHdlIGFkZCBhIGZsYWcgYml0IGluIHRoZSBmb3J3YXJk aW5nL2NvbW1vbg0KPiBoZWFkZXINCj4gPiB0aGF0IGluZGljYXRlcyB0aGF0IGEgZGlyZWN0IHJv dXRpbmcgcmVzcG9uc2UgdG8gYSBtZXNzYWdlIGJlIHVzZWQgYnkNCj4gdGhlDQo+ID4gcmVzcG9u ZGluZyBub2RlLiBBcyBhIHBvbGljeSwgaW1wbGVtZW50YXRpb25zIGluIGNlcnRhaW4gc2NlbmFy aW9zDQo+IHdvdWxkDQo+ID4gZW5hYmxlIHRoZSBmbGFnIGFzIG5lY2Vzc2FyeS4gSWYgdGhlIGZs YWcgaXMgc2V0LCB0aGUgcmVxdWVzdGluZyBub2RlDQo+IGFsc28NCj4gPiBuZWVkcyB0byBpbmNs dWRlIGl0cyByZWFjaGFibGUgYWRkcmVzcyBpbiB0aGUgZm9yd2FyZGluZyBoZWFkZXIuDQo+ID4N Cj4gPg0KPiA+DQo+ID4gV2UgY2FuIGluZGljYXRlIHRoYXQgdGhlIHJlc3BvbmRpbmcgbm9kZSBu ZWVkIG5vdCBrZWVwIHN0YXRlIHRvDQo+IG1pbmltaXplDQo+ID4gY29tcGxpY2F0aW9ucy4gVGhl IHNlbmRpbmcgbm9kZSBjYW4gc2ltcGx5IHJlc2VuZCBhIHJlcXVlc3QgKGUuZw0KPiBTVE9SRSkg d2l0aA0KPiA+IHRoZSBmbGFnIHR1cm5lZCBvZmYgaWYgZG9lcyBub3QgcmVjZWl2ZSBhIHJlc3Bv bnNlIHRvIHRoZSBpbml0aWFsDQo+IFNUT1JFDQo+ID4gcmVxdWVzdCB3aXRoIHRoZSBmbGFnIHR1 cm5lZCBvbi4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGlzIGFsbG93cyBkaXJlY3Qgcm91dGluZyBz dXBwb3J0IGluIHNjZW5hcmlvcyB3aGVyZSB0aGUgZGVwbG95ZXIgb3INCj4gdGhlDQo+ID4gaW1w bGVtZW50YXRpb24ga25vd3MgaXQgaXMgZGVhbGluZyB3aXRoIHJlYWNoYWJsZSBJUCBhZGRyZXNz ZXMgYW5kDQo+IGNhbg0KPiA+IGNvbmZpZ3VyZSB0aGUgaW1wbGVtZW50YXRpb24gdG8gYmVoYXZl IGFjY29yZGluZ2x5LiINCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MNCj4gPg0KPiA+IFNhdW1p dHJhDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gPiBQMlBTSVBAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPiA+DQo+ID4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUDJQU0lQ IG1haWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg== From vidyan@qualcomm.com Tue Mar 24 22:33:28 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C93F3A6AE6 for ; Tue, 24 Mar 2009 22:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOlHnymNCaUp for ; Tue, 24 Mar 2009 22:33:27 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A750E3A6AD7 for ; Tue, 24 Mar 2009 22:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237959259; x=1269495259; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-cr-puzzleid: x-cr-hashedpuzzle:acceptlanguage:content-type: content-transfer-encoding:mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"p2psip@ietf.org"=20|Date:=20Tue,=202 4=20Mar=202009=2022:34:15=20-0700|Subject:=20TURN=20usage =20in=20RELOAD|Thread-Topic:=20TURN=20usage=20in=20RELOAD |Thread-Index:=20AcmtC1YRFtnOHhtVRAK0dDnSdLL8gg=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-cr-puzzleid:=20{611F70D3-3BE6-48 FC-B1A7-26F03864F56E}|x-cr-hashedpuzzle:=20ACBS=20Athy=20 A0tr=20CQgx=20CdUq=20DnUk=20Dujk=20ED1R=20EYRu=20E/VP=20F l9E=0D=0A=20FtuQ=20HkjW=20HpKX=20IQK5=0D=0A=20IbNJ=3B1=3B cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA=3BSosha1_v1=3B7 =3B{611F70D3-3BE6-48FC-B1A7-26F03864F56E}=3BdgBpAGQAeQBhA G4AQABxAHUAYQBsAGMAbwBtAG0ALgBjAG8AbQA=3D=3BWed,=0D=0A=20 25=20Mar=202009=2005:34:15=0D=0A=20GMT=3BVABVAFIATgAgAHUA cwBhAGcAZQAgAGkAbgAgAFIARQBMAE8AQQBEAA=3D=3D |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"iso-8859-1"|Content-Transfer-Encoding:=20quote d-printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAf ee=3Bi=3D"5300,2777,5563"=3B=20a=3D"16569381"; bh=KdyEomRnuoOc9LGADEd/HH41MADZtki7go79o8l7Nq0=; b=jbWXSWMZQqQv5tTfjRNGpJ4Jpso0MaaDoy/InSVL2MOyYiiE+WKUgeMh Ay1XT6/0L9CgJ9ckc1cgGJGV0mbuM2P/b4mo+4VNpL1rcVAcQNb/56Ztv q3M2C0rAdnR4jk0RdW3OsH4vOYqBTjqly/m4MiwAscQd0Yn81Vf4XSaF+ Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16569381" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 22:34:19 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P5YJKA017529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Mar 2009 22:34:19 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P5YIcW002508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Mar 2009 22:34:18 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 22:34:18 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 24 Mar 2009 22:34:17 -0700 From: "Narayanan, Vidya" To: "p2psip@ietf.org" Date: Tue, 24 Mar 2009 22:34:15 -0700 Thread-Topic: TURN usage in RELOAD Thread-Index: AcmtC1YRFtnOHhtVRAK0dDnSdLL8gg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {611F70D3-3BE6-48FC-B1A7-26F03864F56E} x-cr-hashedpuzzle: ACBS Athy A0tr CQgx CdUq DnUk Dujk ED1R EYRu E/VP Fl9E FtuQ HkjW HpKX IQK5 IbNJ; 1; cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {611F70D3-3BE6-48FC-B1A7-26F03864F56E}; dgBpAGQAeQBhAG4AQABxAHUAYQBsAGMAbwBtAG0ALgBjAG8AbQA=; Wed, 25 Mar 2009 05:34:15 GMT;VABVAFIATgAgAHUAcwBhAGcAZQAgAGkAbgAgAFIARQBMAE8AQQBEAA== acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] TURN usage in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 05:33:28 -0000 The currently specified TURN usage in RELOAD is rather odd to me. I suppos= e it tries to load balance and spread the storage of TURN server informatio= n in various parts of the overlay. But then, load balancing and distributi= on of popular data is a much more generic problem that needs to be handled = in a fashion independent of the usage anyway. =20 In the current definition, a node looking for a TURN server keeps looking u= p a random resource ID until it finds a match for data corresponding to the= TURN-SERVICE type.=A0 This seems rather inefficient to me. It also puts y= et another somewhat dynamic parameter into the configuration document (turn= Density). =20 It seems that a far simpler design would be to treat it like a generic keyw= ord storage, where a TURN-SERVICE kind stores data at a location correspond= ing to, say, h(TURN). It is a well-known resource name that will allow nod= es to find a TURN server in a deterministic fashion. This can utilize the = authorization model where any node can write to that resource id, but only = the creator is allowed to modify its own entry. In any event, a node-id ba= sed authorization is quite irrelevant for this service. =20 Any load balancing or caching of information at other points in the overlay= should be handled by generic mechanisms that can be used by any usage on t= he overlay. In fact, simple on-path caching will allow permeation of this = data in various parts of the overlay rather quickly, since many nodes are l= ikely to look for TURN services. =20 Vidya From sa2086@columbia.edu Tue Mar 24 23:13:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1AC3A696E for ; Tue, 24 Mar 2009 23:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBCCfCSkAK9V for ; Tue, 24 Mar 2009 23:13:29 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 849813A693C for ; Tue, 24 Mar 2009 23:13:29 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2P6EJBi018706; Wed, 25 Mar 2009 02:14:19 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2P6EJ2L005773; Wed, 25 Mar 2009 02:14:19 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2P6EJdb005770; Wed, 25 Mar 2009 02:14:19 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 25 Mar 2009 02:14:19 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: "Narayanan, Vidya" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1483920592-1237961659=:2033" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] TURN usage in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 06:13:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1483920592-1237961659=:2033 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Multiple peers can provide the TURN service. Using a single name for TURN service has the problem that H(turn_service_name) maps to a single node. This implies that all STORE and FIND requests can potentially terminate at a single node, overburderning it, and creating a single point of failure. 1) The written text is one way to address this problem. 2) The ReDiR approach proposed in OpenDHT paper also addresses this problem. It stores the TURN record under a two-dimensional tree. A TURN record is stored under H(turn_service_name + L + rand[1,2^L) ) where L is the level of the tree, starting from 0. 3) Another approach is to only admit nodes in the overlay that can provide the TURN service. This means that all peers in the routing table of a peer can potentially provide the TURN service. A client looking for a TURN server asks its peer, which returns a peer providing the TURN service from its routing table. This approach works both for DHTs and unstructured networks. Assuming the default overlay algorithm is a DHT, I prefer the ReDiR approach as the generic mechanism for TURN server discovery because it is deterministic in nature than (1). However, this is something the WG can discuss. For Internet deployments with sufficient number of peers with public IP addresses, I prefer (3) because the lookup time is O(1). -s On Tue, 24 Mar 2009, Narayanan, Vidya wrote: > The currently specified TURN usage in RELOAD is rather odd to me. I suppose it tries to load balance and spread the storage of TURN server information in various parts of the overlay. But then, load balancing and distribution of popular data is a much more generic problem that needs to be handled in a fashion independent of the usage anyway. > > In the current definition, a node looking for a TURN server keeps looking up a random resource ID until it finds a match for data corresponding to the TURN-SERVICE type.  This seems rather inefficient to me. It also puts yet another somewhat dynamic parameter into the configuration document (turnDensity). > > It seems that a far simpler design would be to treat it like a generic keyword storage, where a TURN-SERVICE kind stores data at a location corresponding to, say, h(TURN). It is a well-known resource name that will allow nodes to find a TURN server in a deterministic fashion. This can utilize the authorization model where any node can write to that resource id, but only the creator is allowed to modify its own entry. In any event, a node-id based authorization is quite irrelevant for this service. > > Any load balancing or caching of information at other points in the overlay should be handled by generic mechanisms that can be used by any usage on the overlay. In fact, simple on-path caching will allow permeation of this data in various parts of the overlay rather quickly, since many nodes are likely to look for TURN services. > > Vidya > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > ---559023410-1483920592-1237961659=:2033-- From vidyan@qualcomm.com Tue Mar 24 23:39:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6EF3A6863 for ; Tue, 24 Mar 2009 23:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBJNwRRjamdM for ; Tue, 24 Mar 2009 23:39:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 37A4B3A6D13 for ; Tue, 24 Mar 2009 23:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237963159; x=1269499159; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"sa2086@columbia.edu"=20|CC:=20"p 2psip@ietf.org"=20|Date:=20Tue,=2024=20M ar=202009=2023:39:11=20-0700|Subject:=20RE:=20[P2PSIP]=20 TURN=20usage=20in=20RELOAD|Thread-Topic:=20[P2PSIP]=20TUR N=20usage=20in=20RELOAD|Thread-Index:=20AcmtEPKlVzSjAxf/Q vCatFz47TDSDgAAxH6g|Message-ID:=20 |References:=20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5563"=3B=20a=3D"16570516"; bh=hKl5kO1dmkWZld5yhZ509/QppCWLtgNNyEOUiYOls2Q=; b=BdTsPmY2UNdZTd4Z4Z5JWtk57mwmfik1Q7ciSRSGOG0oQ+IMgN4CNSzn W5XlX3+d8JPJC8AjeqZSDVEfwqJUu0zqx9/9bpQpKCtcwJhrt+8c3m8gA KmoiaLZSXFvUfbuyLwW4lS8STeRpOwod5sAD7IrfrPXORZn3d6Er+oFe5 A=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16570516" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 23:39:19 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P6dIHj009758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 23:39:19 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P6dIjL002081 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 23:39:18 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 23:39:17 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Tue, 24 Mar 2009 23:39:13 -0700 From: "Narayanan, Vidya" To: "sa2086@columbia.edu" Date: Tue, 24 Mar 2009 23:39:11 -0700 Thread-Topic: [P2PSIP] TURN usage in RELOAD Thread-Index: AcmtEPKlVzSjAxf/QvCatFz47TDSDgAAxH6g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] TURN usage in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 06:39:08 -0000 >=20 >=20 > Multiple peers can provide the TURN service. Using a single name for > TURN > service has the problem that H(turn_service_name) maps to a single > node. > This implies that all STORE and FIND requests can potentially terminate > at > a single node, overburderning it, and creating a single point of > failure. >=20 This is what I was referring to as the load balancing and distribution of d= ata problem in my email. Ultimately, to support all kinds of usages on ove= rlays, this must be generically addressed - there is always the problem tha= t a particular metadata or keyword is popular and it maps to one node. Add= ressing it with a special design for TURN doesn't seem appropriate to me. = Load balancing and caching for performance and replication for availability= must be provided as fundamental additions to RELOAD and these will help TU= RN just as they help any other usage on the overlay.=20 Thanks, Vidya=20 > 1) The written text is one way to address this problem. >=20 > 2) The ReDiR approach proposed in OpenDHT paper also addresses this > problem. It stores the TURN record under a two-dimensional tree. A TURN > record is stored under H(turn_service_name + L + rand[1,2^L) ) >=20 > where L is the level of the tree, starting from 0. >=20 > 3) Another approach is to only admit nodes in the overlay that can > provide > the TURN service. This means that all peers in the routing table of a > peer > can potentially provide the TURN service. A client looking for a TURN > server asks its peer, which returns a peer providing the TURN service > from > its routing table. This approach works both for DHTs and unstructured > networks. >=20 > Assuming the default overlay algorithm is a DHT, I prefer the ReDiR > approach as the generic mechanism for TURN server discovery because it > is > deterministic in nature than (1). However, this is something the WG can > discuss. >=20 > For Internet deployments with sufficient number of peers with public IP > addresses, I prefer (3) because the lookup time is O(1). >=20 > -s >=20 > On Tue, 24 Mar 2009, Narayanan, Vidya wrote: >=20 > > The currently specified TURN usage in RELOAD is rather odd to me. I > suppose it tries to load balance and spread the storage of TURN server > information in various parts of the overlay. But then, load balancing > and distribution of popular data is a much more generic problem that > needs to be handled in a fashion independent of the usage anyway. > > > > In the current definition, a node looking for a TURN server keeps > looking up a random resource ID until it finds a match for data > corresponding to the TURN-SERVICE type.=A0 This seems rather inefficient > to me. It also puts yet another somewhat dynamic parameter into the > configuration document (turnDensity). > > > > It seems that a far simpler design would be to treat it like a > generic keyword storage, where a TURN-SERVICE kind stores data at a > location corresponding to, say, h(TURN). It is a well-known resource > name that will allow nodes to find a TURN server in a deterministic > fashion. This can utilize the authorization model where any node can > write to that resource id, but only the creator is allowed to modify > its own entry. In any event, a node-id based authorization is quite > irrelevant for this service. > > > > Any load balancing or caching of information at other points in the > overlay should be handled by generic mechanisms that can be used by any > usage on the overlay. In fact, simple on-path caching will allow > permeation of this data in various parts of the overlay rather quickly, > since many nodes are likely to look for TURN services. > > > > Vidya > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > > From saumitra@qualcomm.com Wed Mar 25 00:39:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF9D3A6938 for ; Wed, 25 Mar 2009 00:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.655 X-Spam-Level: X-Spam-Status: No, score=-103.655 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9n9qvVxQN8D for ; Wed, 25 Mar 2009 00:39:58 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B7F463A690C for ; Wed, 25 Mar 2009 00:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1237966851; x=1269502851; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Wed,=2025=20Mar=20200 9=2000:40:47=20-0700|Subject:=20RE:=20[P2PSIP]=20direct =20routing=20support|Thread-Topic:=20[P2PSIP]=20direct=20 routing=20support|Thread-Index:=20Acms7Uz44BlM59vvSkeHrdg +Jl1y6gALstPw|Message-ID:=20<2D06DE445C2ADE44890118C3F449 B9636D582E31@NASANEXMB12.na.qualcomm.com>|References:=20< 2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.q ualcomm.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5563"=3B=20 a=3D"16571647"; bh=gkuoCSmx0uOFBdDkLvBQT0pk40gWTUk3UQIrCs8N3fc=; b=fkxBO42KCDZ8JN91njWmKvozx9T0xjy6VrUjHz59CjHJiDyEAi64YcsB Nal5551aN3LvvfVCTIr9XAtLEm4RGH527P7qu3fi1cG/13kbX6iBS7RKL decuL0jf30eJYEs8YVOxpmlVmJAXnva/jMZh4MRTUpedHydHqpA212HLC I=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16571647" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 00:40:50 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P7eoNE029784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 00:40:50 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P7enkT027468 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 00:40:50 -0700 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.33]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 25 Mar 2009 00:40:49 -0700 From: "Das, Saumitra" To: Bruce Lowekamp Date: Wed, 25 Mar 2009 00:40:47 -0700 Thread-Topic: [P2PSIP] direct routing support Thread-Index: Acms7Uz44BlM59vvSkeHrdg+Jl1y6gALstPw Message-ID: <2D06DE445C2ADE44890118C3F449B9636D582E31@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 07:39:59 -0000 SGkgQnJ1Y2UsDQoNCkkgZGlkIHNheSB0aGF0IHRoZXJlIHdhcyBjb25zZW5zdXMgb24gdGhlIGl0 IGJlaW5nIHBhcnQgb2YgdGhlIGJhc2UgcHJvdG9jb2wuIFRoZSBiYXNlIGRyYWZ0IGhvd2V2ZXIg ZXhwbGljaXRseSBwcmV2ZW50cyB0aGlzLg0KDQpNYXliZSB3ZSBzaG91bGQgcmVhY2ggY29uc2Vu c3VzIG9uIHRoZSBiYXNlIGRyYWZ0IG9uIHRoaXMgaXNzdWUuIA0KDQpJdCBtYXkgYmUgdXNlZnVs IGFsc28gdG8gbm90IGhhdmUgdGV4dCBleHBsaWNpdGx5IHNheWluZyBkaXJlY3Qgcm91dGluZyBp cyBub3Qgc3VwcG9ydGVkIGFzIGl0IGN1cnJlbnRseSBpcyBpbiB0aGUgYmFzZSBkcmFmdCBhbmQg bWVudGlvbiB0aGF0IHRoZSBmb3J3YXJkaW5nIG9wdGlvbiBjYW4gYmUgdXNlZCB0byBpbXBsZW1l bnQgdGhpcyBmdW5jdGlvbmFsaXR5IGlmIG5lZWRlZC4NCg0KVGhhbmtzDQpTYXVtaXRyYQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJ1Y2UgTG93ZWthbXAgW21haWx0bzpi YmxAbG93ZWthbXAubmV0XSANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI0LCAyMDA5IDY6NTkgUE0N ClRvOiBEYXMsIFNhdW1pdHJhDQpDYzogcDJwc2lwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1Ay UFNJUF0gZGlyZWN0IHJvdXRpbmcgc3VwcG9ydA0KDQpUaGVyZSB3YXMgbm8gY29uc2Vuc3VzIHRv IGluY2x1ZGUgZGlyZWN0IHJlc3BvbnNlIGluIHRoZSBiYXNlIGRyYWZ0Lg0KSGVyZSdzIHRoZSB0 ZXh0IG9mIHRoZSBodW0gZnJvbSB0aGUgbm90ZXMgeW91IHBvaW50IHRvOg0KDQotLS0tLS0tLQ0K Rmlyc3QgaHVtOiAgd2hldGhlciBvciBub3Qgd2UgaW5jbHVkZSBkaXJlY3Qgcm91dGluZyBhcyBh biBvcHRpb24gaW4NCnRoZSBwcm90b2NvbCAobm90IHdvcnJ5aW5nIGFib3V0IHdoYXQgZHJhZnQp OiAgcmVzdWx0IHdhcyBjb25zZW5zdXMNCmZvciBpbmNsdWRpbmcgaXQgaW4gdGhlIHByb3RvY29s Lg0KLS0tLS0tLS0NCg0KRGlyZWN0IHJlc3BvbnNlIHJvdXRpbmcgY2FuIGJlIGltcGxlbWVudGVk IGFzIGEgZm9yd2FyZGluZyBvcHRpb24gYXMNCmRlc2NyaWJlZCBpbiB0aGUgYmFzZS4NCg0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wMnBzaXAtYmFzZS0wMiNzZWN0aW9u LTUuMy4yLjQNCg0KU28gd2hpbGUgaXQncyBwb3NzaWJsZSB0byBkbyBpdCBpbiBvdGhlciB3YXlz LCBhbmQgdG8gaW5jbHVkZSB0aG9zZQ0KdGVjaG5pcXVlcyBpbiB0aGUgYmFzZSBkcmFmdCwgaXQn cyBub3QgcmVxdWlyZWQuDQoNCihvYnZpb3VzbHkgaXQncyBhIHF1ZXN0aW9uIG9mIGdyb3VwIGNv bnNlbnN1cyBvbiB3aGV0aGVyIGl0IHNob3VsZCBiZQ0KYWRkZWQgdG8gdGhlIGJhc2UgZHJhZnQp DQoNCkJydWNlDQoNCg0KMjAwOS8zLzI0IERhcywgU2F1bWl0cmEgPHNhdW1pdHJhQHF1YWxjb21t LmNvbT46DQo+IEF0IHRoZSBwcmV2aW91cyBJRVRGIHRoZXJlIHdhcyBjb25zZW5zdXMgdG8gYWRk IGRpcmVjdCByZXNwb25zZSByb3V0aW5nIGFzDQo+IGFuIG9wdGlvbiBpbiB0aGUgcHJvdG9jb2wu DQo+DQo+DQo+DQo+IFNlZTogaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3AycHNpcC9taW51dGVz P2l0ZW09bWludXRlczczLmh0bWwNCj4NCj4NCj4NCj4gVGhpcyBpcyBub3QgeWV0IHJlZmxlY3Rl ZCBpbiB0aGUgYmFzZSBkcmFmdC4NCj4NCj4NCj4NCj4gTXkgcHJldmlvdXMgcG9zdCB0byB0aGlz IGVmZmVjdCB3aXRoIHNvbWUgY2hhbmdlcyBpcyDCoGJlbG93DQo+DQo+DQo+DQo+ICJJIHdvdWxk IGxpa2UgdG8gcHJvcG9zZSB3ZSBhZGQgYSBmbGFnIGJpdCBpbiB0aGUgZm9yd2FyZGluZy9jb21t b24gaGVhZGVyDQo+IHRoYXQgaW5kaWNhdGVzIHRoYXQgYSBkaXJlY3Qgcm91dGluZyByZXNwb25z ZSB0byBhIG1lc3NhZ2UgYmUgdXNlZCBieSB0aGUNCj4gcmVzcG9uZGluZyBub2RlLiBBcyBhIHBv bGljeSwgaW1wbGVtZW50YXRpb25zIGluIGNlcnRhaW4gc2NlbmFyaW9zIHdvdWxkDQo+IGVuYWJs ZSB0aGUgZmxhZyBhcyBuZWNlc3NhcnkuIElmIHRoZSBmbGFnIGlzIHNldCwgdGhlIHJlcXVlc3Rp bmcgbm9kZSBhbHNvDQo+IG5lZWRzIHRvIGluY2x1ZGUgaXRzIHJlYWNoYWJsZSBhZGRyZXNzIGlu IHRoZSBmb3J3YXJkaW5nIGhlYWRlci4NCj4NCj4NCj4NCj4gV2UgY2FuIGluZGljYXRlIHRoYXQg dGhlIHJlc3BvbmRpbmcgbm9kZSBuZWVkIG5vdCBrZWVwIHN0YXRlIHRvIG1pbmltaXplDQo+IGNv bXBsaWNhdGlvbnMuIFRoZSBzZW5kaW5nIG5vZGUgY2FuIHNpbXBseSByZXNlbmQgYSByZXF1ZXN0 IChlLmcgU1RPUkUpIHdpdGgNCj4gdGhlIGZsYWcgdHVybmVkIG9mZiBpZiBkb2VzIG5vdCByZWNl aXZlIGEgcmVzcG9uc2UgdG8gdGhlIGluaXRpYWwgU1RPUkUNCj4gcmVxdWVzdCB3aXRoIHRoZSBm bGFnIHR1cm5lZCBvbi4NCj4NCj4NCj4NCj4gVGhpcyBhbGxvd3MgZGlyZWN0IHJvdXRpbmcgc3Vw cG9ydCBpbiBzY2VuYXJpb3Mgd2hlcmUgdGhlIGRlcGxveWVyIG9yIHRoZQ0KPiBpbXBsZW1lbnRh dGlvbiBrbm93cyBpdCBpcyBkZWFsaW5nIHdpdGggcmVhY2hhYmxlIElQIGFkZHJlc3NlcyBhbmQg Y2FuDQo+IGNvbmZpZ3VyZSB0aGUgaW1wbGVtZW50YXRpb24gdG8gYmVoYXZlIGFjY29yZGluZ2x5 LiINCj4NCj4NCj4NCj4gVGhhbmtzDQo+DQo+IFNhdW1pdHJhDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QN Cj4gUDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcDJwc2lwDQo+DQo+DQo= From saumitra@qualcomm.com Wed Mar 25 00:51:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BEF3A6863 for ; Wed, 25 Mar 2009 00:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.559 X-Spam-Level: X-Spam-Status: No, score=-105.559 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApD+dfdzqCNk for ; Wed, 25 Mar 2009 00:51:05 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B024B3A67FE for ; Wed, 25 Mar 2009 00:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1237967517; x=1269503517; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Wed,=202 5=20Mar=202009=2000:51:54=20-0700|Subject:=20Notes=20on =20section=209:=20chord|Thread-Topic:=20Notes=20on=20sect ion=209:=20chord|Thread-Index:=20AcmtHpD64+OuRYy2Rg+aV31s J2Josw=3D=3D|Message-ID:=20<2D06DE445C2ADE44890118C3F449B 9636D582E32@NASANEXMB12.na.qualcomm.com>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5563"=3B=20a=3D"16587055"; bh=u1M6frJsMAF/TsIMOWaW9nOvjuNU2VxcEJncToTdywg=; b=jwfowt9YbYH5EQAVp4Wn1cT9DcwUrWzLHG741xsfczq0ItxaEJ1gdpwY nX+qEaB8mozIbGePobnoOea0BkIHZZrab15kQMQKqxW/s+BP5PNwM4jjo XvXupiPP93LMH1y5jjyKNSCg8kZVbO1Avep8gr+8L1I8iKu7RxwpqGJrJ U=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16587055" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 00:51:57 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P7pve2017210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Mar 2009 00:51:57 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2P7pu8J025283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Mar 2009 00:51:57 -0700 (PDT) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.33]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Wed, 25 Mar 2009 00:51:56 -0700 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Wed, 25 Mar 2009 00:51:54 -0700 Thread-Topic: Notes on section 9: chord Thread-Index: AcmtHpD64+OuRYy2Rg+aV31sJ2Josw== Message-ID: <2D06DE445C2ADE44890118C3F449B9636D582E32@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] Notes on section 9: chord X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 07:51:06 -0000 I had some small comments on Section 9. 1. Why do we wait for replies from the replicas to send back STORE Response= . This will increase the amount of state on originating nodes from waiting = around for all this to get done. A STORE should be deemed complete when the= owning node has received and stored the data itself 2. Are there further thoughts on defining reactive versus proactive repair = for the base topology plugin? As Rhea2004 showed, it may be useful to have = a periodic repair in stead of reactive. This could be set statically and co= nfigurable through the overlay configuration document based on the overlay = deployment scale and expected churn. 3. The section says that every time a connection is lost, the peer should r= emove the entry from the neighbor table and replace with best match from th= e routing table. Shouldn't we try to re-establish connection or give some g= uidelines on when to remove an entry after some number of re-establishes do= n't work? Thanks Saumitra From bbl@lowekamp.net Wed Mar 25 04:47:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9064E3A6A76 for ; Wed, 25 Mar 2009 04:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvUVAjCGPhi9 for ; Wed, 25 Mar 2009 04:47:26 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id A22443A695B for ; Wed, 25 Mar 2009 04:47:26 -0700 (PDT) Received: by qyk36 with SMTP id 36so3740860qyk.29 for ; Wed, 25 Mar 2009 04:48:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.100.14 with SMTP id w14mr4156678qcn.48.1237981698395; Wed, 25 Mar 2009 04:48:18 -0700 (PDT) In-Reply-To: References: <20090318211247.74FE250822@romeo.rtfm.com> Date: Wed, 25 Mar 2009 07:48:18 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 11:47:27 -0000 Salman, Based on your list, I'm going to assume you agree with the current proposal. RELOAD supports (and prefers) a TCP overlay link protocol, and it offers a UDP-based protocol when that doesn't work. I'd fully support a simple use RFCXXXX for a TCP-over-UDP protocol, but since there isn't one, we have a goal of something that should work, even if it doesn't reach "ideal" (TCP-like) performance. If you believe more needs to be done to specify a real TCP over UDP, I fully support you advancing that in TSV. Bruce On Thu, Mar 19, 2009 at 12:13 AM, Salman Abdul Baset wrote: > On Wed, 18 Mar 2009, Bruce Lowekamp wrote: > >> That paper in particular, and the reasons UDP connections are more >> reliably formed than TCP, have been discussed numerous times in >> MMUSIC, and I really don't think we should be repeating the whole >> conversation here. =C2=A0But the summary is that it's not nearly as >> universal a solution as indicated in that paper. >> >> Bruce > > Sure. I have already mentioned that this is a IMC'05 paper and more recen= t > data, if available, is helpful and needed. > > There are at least four solutions to the hop-by-hop reliability problem: > > (1) Clients > Nodes behind TCP *un*friendly NATs can always act as clients and establis= h a > TCP connection(s) with reachable node(s). The reachable nodes can be behi= nd > friendly NATs or they can have a public IP address. > > (2) Full peer but use relay peer(s) > A node participates as a peer. It establishes TCP connection with reachab= le > peers, which inturn establish a TCP connection with the nodes' connection > table entries. > > (3) Full peer with techniques for direct TCP connection establishment > A node participates as a peer and uses TCP traversal techniques for > establishing direct connection (including Dean's upcoming ones:) > > (4) Full peer with TCP-over-UDP > Since TCP traversal may fail, design/reuse a reliable congestion control > protocol over UDP. > > > Note that: > (1) and (2) always work. > > (3) and (4) do not work well behind cascaded NATs. (4) fails behind > UDP-blocking firewalls. > > (4) is feasible over (3) since UDP has a better chance of connection > establishment when NATs are not cascaded. However, UDP blocking firewalls > need to be factored in this feasible discussion. Again, any recent data i= s > helpful. > > > For (4), the TCP-over-UDP protocol needs to be well-designed and > well-implemented. Otherwise, peers doing TCP-over-UDP may be the weakest > link in the routing chain. Approaches which recover every loss using time= out > may not be the most feasible ones. > > > -salman > From bbl@lowekamp.net Wed Mar 25 04:59:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E423A6811 for ; Wed, 25 Mar 2009 04:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW-61nxSIfo7 for ; Wed, 25 Mar 2009 04:59:35 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 240B13A67EF for ; Wed, 25 Mar 2009 04:59:34 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so2172352qwb.31 for ; Wed, 25 Mar 2009 05:00:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.79.17 with SMTP id n17mr4129603qck.82.1237982426666; Wed, 25 Mar 2009 05:00:26 -0700 (PDT) In-Reply-To: References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> Date: Wed, 25 Mar 2009 08:00:26 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 11:59:36 -0000 On Wed, Mar 25, 2009 at 1:08 AM, Narayanan, Vidya wro= te: > > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf Of Bruce Lowekamp >> Sent: Tuesday, March 24, 2009 6:59 PM >> To: Das, Saumitra >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] direct routing support >> >> There was no consensus to include direct response in the base draft. >> Here's the text of the hum from the notes you point to: >> >> -------- >> First hum: =C2=A0whether or not we include direct routing as an option i= n >> the protocol (not worrying about what draft): =C2=A0result was consensus >> for including it in the protocol. >> -------- >> > > Right, there was consensus to include it in the base protocol. The text inside the parenthesis means there was no consensus where to put it, to me at least. > =C2=A0To me, it would make sense to add it to the base draft, since it do= esn't seem to make sense to say in the base draft that it is not permitted = and yet have the notion of allowing it in the base protocol. > >> Direct response routing can be implemented as a forwarding option as >> described in the base. >> >> http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4 >> > > I'm assuming that you are talking about a yet-to-be-defined forwarding op= tion? =C2=A0Or, did I miss something that is already specified that can be = used for this purpose? > Sorry to be unclear. I meant to say that a direct response forwarding option could be defined, not that the base draft defines one. > I think defining a forwarding option for this does make sense and corresp= onding to that option, we need to say what the forwarding behavior should b= e. =C2=A0The node sending the request also needs to provide its direct reac= hability parameters in the message. > > While we are on the topic of forwarding options, could anyone describe th= e purpose of the ones that are already defined in section 5.3.2.4? =C2=A0I = don=E2=80=99t quite see an explanation and I am quite perplexed by them :) > I'm not sure what you're referring to. http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4 doesn't define any forwarding options, it defines a structure that forwarding options could use, but does not itself define a forwarding option (i.e. no values for "type" are given meaning). Bruce > Thanks, > Vidya > >> So while it's possible to do it in other ways, and to include those >> techniques in the base draft, it's not required. >> >> (obviously it's a question of group consensus on whether it should be >> added to the base draft) >> >> Bruce >> >> >> 2009/3/24 Das, Saumitra : >> > At the previous IETF there was consensus to add direct response >> routing as >> > an option in the protocol. >> > >> > >> > >> > See: http://tools.ietf.org/wg/p2psip/minutes?item=3Dminutes73.html >> > >> > >> > >> > This is not yet reflected in the base draft. >> > >> > >> > >> > My previous post to this effect with some changes is =C2=A0below >> > >> > >> > >> > "I would like to propose we add a flag bit in the forwarding/common >> header >> > that indicates that a direct routing response to a message be used by >> the >> > responding node. As a policy, implementations in certain scenarios >> would >> > enable the flag as necessary. If the flag is set, the requesting node >> also >> > needs to include its reachable address in the forwarding header. >> > >> > >> > >> > We can indicate that the responding node need not keep state to >> minimize >> > complications. The sending node can simply resend a request (e.g >> STORE) with >> > the flag turned off if does not receive a response to the initial >> STORE >> > request with the flag turned on. >> > >> > >> > >> > This allows direct routing support in scenarios where the deployer or >> the >> > implementation knows it is dealing with reachable IP addresses and >> can >> > configure the implementation to behave accordingly." >> > >> > >> > >> > Thanks >> > >> > Saumitra >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> > >> > >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From bbl@lowekamp.net Wed Mar 25 04:59:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147FB3A69EF for ; Wed, 25 Mar 2009 04:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8cEddOD9V-C for ; Wed, 25 Mar 2009 04:59:40 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 119BB3A69DF for ; Wed, 25 Mar 2009 04:59:39 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so2172352qwb.31 for ; Wed, 25 Mar 2009 05:00:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.82.76 with SMTP id a12mr4215336qcl.7.1237982432430; Wed, 25 Mar 2009 05:00:32 -0700 (PDT) In-Reply-To: <2D06DE445C2ADE44890118C3F449B9636D582E31@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> <2D06DE445C2ADE44890118C3F449B9636D582E31@NASANEXMB12.na.qualcomm.com> Date: Wed, 25 Mar 2009 08:00:32 -0400 Message-ID: From: Bruce Lowekamp To: "Das, Saumitra" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 11:59:41 -0000 On Wed, Mar 25, 2009 at 3:40 AM, Das, Saumitra wrot= e: > Hi Bruce, > > I did say that there was consensus on the it being part of the base proto= col. The base draft however explicitly prevents this. There was no consensus to include it in the base draft. That's what the part in parenthesis "((not worrying about what draft)" meant. The specific conclusion what that a more detailed direct routing proposal would be presented, and a later discussion would take place regarding where it went. Chairs, please correct me if I'm wrong on this. > > Maybe we should reach consensus on the base draft on this issue. > > It may be useful also to not have text explicitly saying direct routing i= s not supported as it currently is in the base draft and mention that the f= orwarding option can be used to implement this functionality if needed. > If there is text anywhere in the base draft that says direct routing is not supported, please cite a location (this is a general request whenever anyone says "the draft says foo"). It's a big draft and it's possible to lose track of what different sections say. I reorganized and rewrote parts of section 5 since last IETF and certainly the intro to 5 and 5.2 http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5 http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.2 say nothing that explicitly prevents direct response routing. Bruce > Thanks > Saumitra > > -----Original Message----- > From: Bruce Lowekamp [mailto:bbl@lowekamp.net] > Sent: Tuesday, March 24, 2009 6:59 PM > To: Das, Saumitra > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] direct routing support > > There was no consensus to include direct response in the base draft. > Here's the text of the hum from the notes you point to: > > -------- > First hum: =C2=A0whether or not we include direct routing as an option in > the protocol (not worrying about what draft): =C2=A0result was consensus > for including it in the protocol. > -------- > > Direct response routing can be implemented as a forwarding option as > described in the base. > > http://tools.ietf.org/html/draft-ietf-p2psip-base-02#section-5.3.2.4 > > So while it's possible to do it in other ways, and to include those > techniques in the base draft, it's not required. > > (obviously it's a question of group consensus on whether it should be > added to the base draft) > > Bruce > > > 2009/3/24 Das, Saumitra : >> At the previous IETF there was consensus to add direct response routing = as >> an option in the protocol. >> >> >> >> See: http://tools.ietf.org/wg/p2psip/minutes?item=3Dminutes73.html >> >> >> >> This is not yet reflected in the base draft. >> >> >> >> My previous post to this effect with some changes is =C2=A0below >> >> >> >> "I would like to propose we add a flag bit in the forwarding/common head= er >> that indicates that a direct routing response to a message be used by th= e >> responding node. As a policy, implementations in certain scenarios would >> enable the flag as necessary. If the flag is set, the requesting node al= so >> needs to include its reachable address in the forwarding header. >> >> >> >> We can indicate that the responding node need not keep state to minimize >> complications. The sending node can simply resend a request (e.g STORE) = with >> the flag turned off if does not receive a response to the initial STORE >> request with the flag turned on. >> >> >> >> This allows direct routing support in scenarios where the deployer or th= e >> implementation knows it is dealing with reachable IP addresses and can >> configure the implementation to behave accordingly." >> >> >> >> Thanks >> >> Saumitra >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > From bbl@lowekamp.net Wed Mar 25 05:10:34 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278A13A68A2 for ; Wed, 25 Mar 2009 05:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb0T071r1KYi for ; Wed, 25 Mar 2009 05:10:33 -0700 (PDT) Received: from mail-qy0-f108.google.com (mail-qy0-f108.google.com [209.85.221.108]) by core3.amsl.com (Postfix) with ESMTP id A7F363A6837 for ; Wed, 25 Mar 2009 05:10:32 -0700 (PDT) Received: by qyk6 with SMTP id 6so3704254qyk.32 for ; Wed, 25 Mar 2009 05:11:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.100.7 with SMTP id w7mr16804qcn.5.1237983084286; Wed, 25 Mar 2009 05:11:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2009 08:11:24 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Configuration Updates in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 12:10:34 -0000 On Wed, Mar 25, 2009 at 1:04 AM, Narayanan, Vidya wro= te: > Hi Bruce, > >> -----Original Message----- >> From: Bruce Lowekamp [mailto:bbl@lowekamp.net] >> Sent: Tuesday, March 24, 2009 6:55 PM >> To: Narayanan, Vidya >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Configuration Updates in RELOAD >> >> Hi Vidya, >> >> So one of the key questions here is what are the use cases for >> updating configuration documents. >> >> - a managed overlay, where what the overlay supports is determined by >> the entity managing the overlay. =C2=A0In this case, the manager is the >> only entity that should be able to authorize new kinds on the overlay. > > This may be one model, but I certainly don't think this is the only model= possible for managed overlays. I think we are being way too narrow here wi= th our views on how this may get deployed. I can envision several types of = managed overlays, especially ones where the enrollment, as a function, may = be provided by some entity that is completely different from the service pr= oviders on those overlays that are offering services/applications. =C2=A0I'= d like to see a clear separation in functionality between the enrollment se= rver and any involvement in actual operations of the overlay, including the= types of services that are offered on the overlay. =C2=A0I think this func= tional separation is essential to ensure that we provide flexible deploymen= t options. > There is a clear separation. The only thing linking the two is the need to have the key used to sign the configuration document. >> =C2=A0Such a manager would also have contact with the overlay and the >> ability to inject a new configuration document. > > You are assuming here that the manager communicates with a node on the ov= erlay potentially via out-of-band means to do this. > I'm assuming it has a means to communicate with a peer on the overlay. Don't particularly care what it is. >> Such a document will >> propagate very fast once it is introduced on only a single peer. >> There's no requirement that the actual "enrollment server" be on the >> overlay, only that a document signed with the appropriate key can be >> introduced onto a peer. =C2=A0Given a CE overlay, for example, one could >> imagine new versions of the product (or products) being issued new >> configuration documents as new kinds are required. =C2=A0The result is t= hat >> the CE devices automatically update to the newest config document >> whenever a new device appears on the overlay, and thus before any new >> kind is used on the overlay. >> > > Pardon my ignorance - what's a CE overlay? > Sorry, consumer electronics. So suppose KodMinNik offers both cameras and digital picture frames that form an overlay in the home. The first generation products all have the same types, and thus the same overlay config file signed by KodMinNik. When the second generation of products are released, there are a couple new types, and thus a new config file signed by KodMinNik. When a 2nd generation product is introduced into a home for the first time, the 1st generation devices will see the new config file and update their copy. Even though KodMinNik has no direct contact with the individual overlay, any device that requires the new types will have a signed config document that all the old devices would recognize, so the overlay is managed and reliability is ensured by KodMinNik without an active presence. >> - The choice of self-signed peer certificates is orthogonal to the >> question of the key used to sign the configuration document. >> However, if you choose to deploy an overlay where anyone can generate >> a new config document, I think you're right that there could be a >> problem. =C2=A0I could imagine a solution where any peer that notices it= s >> resource is not in the current configuration updates the config file, >> but I'm not convinced there is a significant need for this type of >> scenario. =C2=A0I'd be interested in use cases you believe would be >> deployed this way. >> > > Are you asking for use cases that will be deployed with self-signed certs= at all or use cases that operate with self-signed certs where the peers ar= e updating config files? =C2=A0Of course, there are plenty of use cases for= just the former. =C2=A0For the latter, I'd argue that the config file serv= es no purpose other than strict config parameters and hence, should never n= eed to be updated as part of the overlay operations. > I was asking for use cases where there is a need for multiple peers to introduce new types that would somehow not be known to the peer starting the overlay. i.e. please give a specific use case where the config update mechanism in the current base draft presents a problem. Bruce >> I don't believe that the security issues of not having a list of >> auhorized kinds, even simply registering garbage in the overlay, can >> be ignored for many or even most overlays. >> > > Actually, I don't think so. =C2=A0Storing garbage on the overlay is feasi= ble anyway and an authorized node could also do this. =C2=A0So, I don't thi= nk removing this kind-specific authorization requirement at the overlay lev= el is going to make any significantly worse. =C2=A0The additional authoriza= tion steps that can be applied at the kind and/or data retrieval level can = always remedy it too - so, I am not seeing a great risk here. > > Vidya > >> Bruce >> >> >> >> 2009/3/23 Narayanan, Vidya : >> > The current RELOAD draft assumes that the configuration document >> specifies >> > the kinds, the associated data models and authorization rules that >> are >> > applicable for the overlay.=C2=A0 While it may be okay to specify the >> kinds the >> > overlay supports (thereby giving a notion of available services and >> > applications on the overlay), the other two things make this >> configuration >> > document relevant during the operation of an overlay itself (rather >> than >> > configuration just being a one-time thing prior to joining the >> overlay). >> > This is undesirable in my view.=C2=A0 For one, this involves the >> enrollment >> > server into the overlay functional aspects, which departs from the >> notion of >> > enrollment being a one-time thing (and the enrollment server itself >> not >> > being a part of the overlay).=C2=A0 It also brings the question of how= the >> latest >> > configuration document is made available on the overlay =E2=80=93 the >> enrollment >> > server is not necessarily a peer or a client that can publish >> information on >> > the overlay. >> > >> > >> > >> > On the other hand, I think that this role for the configuration >> document in >> > normal overlay operations can be eliminated if the requirement for >> knowledge >> > of kind to authorization rule mapping is lifted for performing the >> > authorization itself.=C2=A0 The storing node technically only needs to >> know the >> > particular authorization rule that has been used for the data to be >> stored >> > and verify that it passes authorization.=C2=A0 The enforcement of whet= her >> that is >> > the right authorization for that kind can be done by the actual kind >> itself >> > (or the usage that uses that kind).=C2=A0 The downside of this is that= a >> > particular misbehaving node may use a different authorization rule >> than what >> > is expected for a given kind.=C2=A0 This may at best result in garbage >> being >> > stored along with other data at a particular resource id.=C2=A0 For >> instance, if >> > Alice is well behaved, h(alice@example.org) may contain an IP address >> to >> > reach that AOR.=C2=A0 Eve, a misbehaving user, may store some other ju= nk >> at >> > h(alice@example.org) using a more flexible authorization rule (at the >> > moment, assuming a good hash function, I can only see this being >> feasible >> > using the rule that places no constraints on resource id >> generation).=C2=A0 By >> > ensuring that data from one creator doesn=E2=80=99t overwrite data fro= m >> another >> > node, except explicitly authorized by the creator, >> h(alice@example.org) will >> > now have data corresponding to multiple creators.=C2=A0 When the data = is >> > retrieved for consumption by a usage, it can apply an additional >> check to >> > ensure that only the data with the correct authorization model is >> actually >> > consumed.=C2=A0=C2=A0 It is also possible to place that restriction at= the time >> of >> > retrieval to prevent all junk from being transported (to save >> bandwidth, for >> > e.g.). >> > >> > >> > >> > There doesn=E2=80=99t appear to be much downside in doing the above. >> However, I=E2=80=99m >> > open to other solutions that can take the configuration document out >> of the >> > overlay operation semantics.=C2=A0 =C2=A0I=E2=80=99d like to keep the = enrollment server >> (or >> > any other centralized entity) to the role it is actually meant for =E2= =80=93 >> the >> > more we engage these entities in overlay operations or kinds or >> usages, we >> > start placing more restrictions and make it difficult to use the same >> design >> > with self-signed certs and so on. >> > >> > >> > >> > Vidya >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> > >> > > From jouni.maenpaa@ericsson.com Wed Mar 25 07:42:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CDB3A690A for ; Wed, 25 Mar 2009 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.655 X-Spam-Level: X-Spam-Status: No, score=-5.655 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+zwA6HuBzl3 for ; Wed, 25 Mar 2009 07:42:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 19B1F3A68F6 for ; Wed, 25 Mar 2009 07:42:38 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9BBB520F19; Wed, 25 Mar 2009 15:43:29 +0100 (CET) X-AuditID: c1b4fb3c-ab75abb000003f6e-c4-49ca43119ecc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58B5B20F76; Wed, 25 Mar 2009 15:43:29 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 15:43:27 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 15:43:26 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B84DC245B; Wed, 25 Mar 2009 16:43:26 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7D59E219E5; Wed, 25 Mar 2009 16:43:26 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9F27A219E4; Wed, 25 Mar 2009 16:43:25 +0200 (EET) Message-ID: <49CA430B.2090206@ericsson.com> Date: Wed, 25 Mar 2009 07:43:23 -0700 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "Das, Saumitra" References: <2D06DE445C2ADE44890118C3F449B9636D582E32@NASANEXMB12.na.qualcomm.com> In-Reply-To: <2D06DE445C2ADE44890118C3F449B9636D582E32@NASANEXMB12.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 25 Mar 2009 14:43:26.0878 (UTC) FILETIME=[0E8033E0:01C9AD58] X-Brightmail-Tracker: AAAAAA== Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Notes on section 9: chord X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 14:42:40 -0000 Hi, > 2. Are there further thoughts on defining reactive versus proactive > repair for the base topology plugin? As Rhea2004 showed, it may be > useful to have a periodic repair in stead of reactive. This could be > set statically and configurable through the overlay configuration > document based on the overlay deployment scale and expected churn. Just wanted to point out that the Self-tuning DHT draft uses periodic repair: http://tools.ietf.org/html/draft-maenpaa-p2psip-self-tuning-00 -Jouni Das, Saumitra wrote: > I had some small comments on Section 9. > > 1. Why do we wait for replies from the replicas to send back STORE Response. This will increase the amount of state on originating nodes from waiting around for all this to get done. A STORE should be deemed complete when the owning node has received and stored the data itself > > 2. Are there further thoughts on defining reactive versus proactive repair for the base topology plugin? As Rhea2004 showed, it may be useful to have a periodic repair in stead of reactive. This could be set statically and configurable through the overlay configuration document based on the overlay deployment scale and expected churn. > > 3. The section says that every time a connection is lost, the peer should remove the entry from the neighbor table and replace with best match from the routing table. Shouldn't we try to re-establish connection or give some guidelines on when to remove an entry after some number of re-establishes don't work? > > Thanks > Saumitra > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From sa2086@columbia.edu Wed Mar 25 08:22:24 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F54F3A69E0 for ; Wed, 25 Mar 2009 08:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lYuMkQxJ6G4 for ; Wed, 25 Mar 2009 08:22:23 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 4BAB33A6811 for ; Wed, 25 Mar 2009 08:22:23 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2PFNDrx022256; Wed, 25 Mar 2009 11:23:13 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2PFNDXG026190; Wed, 25 Mar 2009 11:23:13 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2PFNDRe026187; Wed, 25 Mar 2009 11:23:13 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 25 Mar 2009 11:23:13 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <20090318211247.74FE250822@romeo.rtfm.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1483920592-1237993577=:17404" Content-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 15:22:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1483920592-1237993577=:17404 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: There are two proposals, one in the draft and one in your email. The general assumption behind these proposals is that a node participates in the overlay as a full peer and uses these solutions for achieving hop-by-hop reliability. I do not agree with the proposals in the draft or in your email. For simplicity, lets refer to these solutions as Lesser-reliability-over-UDP (LROU). The reasons, some of which I have stated in the earlier posts, are: 1) LSROU or even TCP-over-UDP is not a universal solution. It is well-known that TURN server use is necessary for UDP, especially when using cascaded NATs, or NATs with end-point dependent filtering. 2) Base draft has tried to incorporate solutions that work in all scenarios. This is why we have recursive routing. LSROU does not work in all scenarios. A combination of LSROU and TCP also does not work in all scenarios. Bottom line: relaying is unavoidable. Clearly, lesser the relaying the better, and LROU is considered to be one way. However, see (3) and (5). 3) TCP inbound connections through NAT are considered more problematic than UDP. The available data I am aware of (Characterizing paper, IMC'05) suggests that for 100% of common type of deployed NATs, it is possible to establish direct TCP connections. You noted that this is not as universal as discussed in the paper, but how much less? Can we put a number? Do we have data? 4) We cannot make any assumptions on the size of the data sent over LSROU. 5) LSROU only relies on *timeouts* to recover each loss. TCP recovers loss using *TDACK* and *timeout*. A node participating in the overlay as a full peer that uses LSROU to recover losses using *timeouts* is the weakest link in the routing chain. 5) Lets suppose that TCP inbound connections were much more problematic than UDP and so a lot of peers will run LSROU. Imagine that the only way these peers running LSROU recover losses is using timeouts. Can we imagine the poor routing performance of this system? Shall we standardize it? 6) The present text in the draft uses TFRC-SP. TFRC-SP mandates a gap of 10ms between each transmission. Imagine 4 packets traversing 5 hops, and each transmission delayed by 10ms. Even if there are no losses, the last packet will leave the fourth hop after 120ms. My proposal (a rough text) is as follows. "RELOAD uses TCP for achieving hop-by-hop reliability and relies on existing techniques to solve inbound TCP connection problem. When direct connection fails, the node (a) only participates as a client or (b) particpates as a peer and uses a TCP TURN server to achieve a 1-hop connection with its connection table entries. Alternatively, a peer can use a TCP-over-UDP protocol to establish direct connections and to achieve reliability. However, we do not specify such a protocol." -s On Wed, 25 Mar 2009, Bruce Lowekamp wrote: > Salman, > > Based on your list, I'm going to assume you agree with the current > proposal. RELOAD supports (and prefers) a TCP overlay link protocol, > and it offers a UDP-based protocol when that doesn't work. I'd fully > support a simple use RFCXXXX for a TCP-over-UDP protocol, but since > there isn't one, we have a goal of something that should work, even if > it doesn't reach "ideal" (TCP-like) performance. If you believe more > needs to be done to specify a real TCP over UDP, I fully support you > advancing that in TSV. > > Bruce > > > On Thu, Mar 19, 2009 at 12:13 AM, Salman Abdul Baset > wrote: >> On Wed, 18 Mar 2009, Bruce Lowekamp wrote: >> >>> That paper in particular, and the reasons UDP connections are more >>> reliably formed than TCP, have been discussed numerous times in >>> MMUSIC, and I really don't think we should be repeating the whole >>> conversation here.  But the summary is that it's not nearly as >>> universal a solution as indicated in that paper. >>> >>> Bruce >> >> Sure. I have already mentioned that this is a IMC'05 paper and more recent >> data, if available, is helpful and needed. >> >> There are at least four solutions to the hop-by-hop reliability problem: >> >> (1) Clients >> Nodes behind TCP *un*friendly NATs can always act as clients and establish a >> TCP connection(s) with reachable node(s). The reachable nodes can be behind >> friendly NATs or they can have a public IP address. >> >> (2) Full peer but use relay peer(s) >> A node participates as a peer. It establishes TCP connection with reachable >> peers, which inturn establish a TCP connection with the nodes' connection >> table entries. >> >> (3) Full peer with techniques for direct TCP connection establishment >> A node participates as a peer and uses TCP traversal techniques for >> establishing direct connection (including Dean's upcoming ones:) >> >> (4) Full peer with TCP-over-UDP >> Since TCP traversal may fail, design/reuse a reliable congestion control >> protocol over UDP. >> >> >> Note that: >> (1) and (2) always work. >> >> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >> UDP-blocking firewalls. >> >> (4) is feasible over (3) since UDP has a better chance of connection >> establishment when NATs are not cascaded. However, UDP blocking firewalls >> need to be factored in this feasible discussion. Again, any recent data is >> helpful. >> >> >> For (4), the TCP-over-UDP protocol needs to be well-designed and >> well-implemented. Otherwise, peers doing TCP-over-UDP may be the weakest >> link in the routing chain. Approaches which recover every loss using timeout >> may not be the most feasible ones. >> >> >> -salman >> > > ---559023410-1483920592-1237993577=:17404-- From worldhocs@yahoo.com.tw Wed Mar 25 08:54:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A563A693E for ; Wed, 25 Mar 2009 08:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODkuP4FOB2ai for ; Wed, 25 Mar 2009 08:54:08 -0700 (PDT) Received: from web72303.mail.tp2.yahoo.com (web72303.mail.tp2.yahoo.com [203.188.200.93]) by core3.amsl.com (Postfix) with SMTP id 3EB8E3A6810 for ; Wed, 25 Mar 2009 08:54:08 -0700 (PDT) Received: (qmail 67418 invoked by uid 60001); 25 Mar 2009 15:54:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.tw; s=s1024; t=1237996499; bh=acv5HIH+pDxS32D1SDYkQ9s9ZOQXvWbnKhNQLs0m9f4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=lTgGYy7QHpM7/bnE5qkCkEHEU5cK88VPPg84W0WrLx4RE1SZ9mE6YJ4eKxcELpi1XKYSgQt3U0adUu/hg3sdXE4vMQCFGEuSWQsyYy7auFqpPqbhd6L8hXPdE3Y/HgqzsCP9kBlqwjMQN/ete3HoupaKQDP83AX57U74fZKxSrM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.tw; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=UzJKi1fAqcC64Y8tbbMwwvJs0ToduA7P//u9MqSjaNsBKIZ2JcXtylP23jl8VK7YghyJ1UGRJr4v89m36JXW7PdWqT5tDx9/mpeucNEf40uLEgLaX6XHC/32IvgZQxm0+v53ryED0sCTdMC2X5q/twcOv6SipG55ujK7FOgHcHE=; Message-ID: <373088.66052.qm@web72303.mail.tp2.yahoo.com> X-YMail-OSG: X7P7ELoVM1mOtWbWlB1fPIZnTn12zEW6F5yL1XO6NYNsMYm8oYNJur5gB_V8U9RI2d.cbSzUQst7V6CpaQTyjb1.SzhDy3gGN2E.nCOfH.3.zaqgjiVQu1qSLRBWZTBIDRQVQrb219JkIINN9D1g0SZ9A4RtOVZY0bzJFyAEMm1MTlpk_txOhcx8G1plIRQIoISoJUHE94KBBU6Qkg6qrdWA.Q8xBVXjKtUw0jU1vbH572VL Received: from [221.169.0.252] by web72303.mail.tp2.yahoo.com via HTTP; Wed, 25 Mar 2009 23:54:59 CST X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Wed, 25 Mar 2009 23:54:59 +0800 (CST) From: Ho Jeffrey To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2010079675-1237996499=:66052" Subject: [P2PSIP] asking the difference of the definition between resource location and resource discovery in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 15:54:09 -0000 --0-2010079675-1237996499=:66052 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, =C2=A0 The P2PSIP Base Protocol, RELOAD stands for REsource LOcation and Discovery= . Could someone please explain for me what the difference of the meaning be= tween resource location and resource discovery is? Do you think both mean t= he same thing? Or Resource Discovery implies the retrieval of content of th= e resource object after doing Resource Location? Thanks for your response i= n advance. =C2=A0 BR, world=0A=0A=0A _______________________________________________________= _______________________________________________=0A=E4=BB=98=E8=B2=BB=E6=89= =8D=E5=AE=B9=E9=87=8F=E7=84=A1=E4=B8=8A=E9=99=90=EF=BC=9FYahoo!=E5=A5=87=E6= =91=A9=E9=9B=BB=E5=AD=90=E4=BF=A1=E7=AE=B12.0=E5=85=8D=E8=B2=BB=E7=B5=A6=E4= =BD=A0=EF=BC=8C=E4=BF=A1=E4=BB=B6=E6=B0=B8=E9=81=A0=E4=B8=8D=E5=BF=85=E5=88= =AA=EF=BC=81 http://tw.mg0.mail.yahoo.com/dc/landing --0-2010079675-1237996499=:66052 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear all,
 
The P2PSIP Base Protocol, RELOAD stands for REsource LOcation and Disc= overy. Could someone please explain for me what the difference of the meani= ng between resource location and resource discovery is? Do you think both m= ean the same thing? Or Resource Discovery implies the retrieval of content = of the resource object after doing Resource Location? Thanks for your respo= nse in advance.
 
BR,
world

=0A=0A=0A=0A=0A=0A =0A=E4=BB=98=E8=B2=BB=E6=89= =8D=E5=AE=B9=E9=87=8F=E7=84=A1=E4=B8=8A=E9=99=90=EF=BC=9FYahoo!=E5=A5=87=E6= =91=A9=E9=9B=BB=E5=AD=90=E4=BF=A1=E7=AE=B12.0=E5=85=8D=E8=B2=BB=E7=B5=A6=E4= =BD=A0=EF=BC=8C=E4=BF=A1=E4=BB=B6=E6=B0=B8=E9=81=A0=E4=B8=8D=E5=BF=85=E5=88= =AA=EF=BC=81 - =E9=A6=AC=E4=B8=8A= =E9=AB=94=E9=A9=97=EF=BC=81 --0-2010079675-1237996499=:66052-- From vidyan@qualcomm.com Wed Mar 25 09:50:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2883A67FD for ; Wed, 25 Mar 2009 09:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.345 X-Spam-Level: X-Spam-Status: No, score=-103.345 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDG2IGIDHVx9 for ; Wed, 25 Mar 2009 09:50:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A0A9B3A677D for ; Wed, 25 Mar 2009 09:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1237999854; x=1269535854; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Wed,=2025=20Mar=20200 9=2009:50:46=20-0700|Subject:=20RE:=20[P2PSIP]=20Configur ation=20Updates=20in=20RELOAD|Thread-Topic:=20[P2PSIP]=20 Configuration=20Updates=20in=20RELOAD|Thread-Index:=20Acm tQtLs15ZAr+2tRvqbQzklFZpmhAAJJI7A|Message-ID:=20|References:=20=0D=0A=09=20=0D=0A=09 =20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5564"=3B=20 a=3D"16584317"; bh=3ESxFtrw6TwKj5Tr6SpX0Yzw6HHybubRWEIsdNLFbZA=; b=WniCtR90HzQw9QMFaQWEFTvx55gYv2Wd3Rzv9j6J5HgXWozLbEkDkBJt qawbK8+H61IsxF7FD5aPSj6JGVtEfzGEdmjCSvMfkBM8td+vTGEz01D0n ZGc16DEkjIqhEfwCrtyNYoi0a1OlE8xfHuhx9Kno6VAgOVZFKh47Y0DwR E=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16584317" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 09:50:53 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PGortS006764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 09:50:53 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PGon02013755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 09:50:49 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 09:50:48 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 25 Mar 2009 09:50:47 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp Date: Wed, 25 Mar 2009 09:50:46 -0700 Thread-Topic: [P2PSIP] Configuration Updates in RELOAD Thread-Index: AcmtQtLs15ZAr+2tRvqbQzklFZpmhAAJJI7A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Configuration Updates in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 16:50:03 -0000 PHNuaXA+DQoNCj4gwqBJJ2QgbGlrZSB0byBzZWUgYSBjbGVhciBzZXBhcmF0aW9uDQo+IGluIGZ1 bmN0aW9uYWxpdHkgYmV0d2VlbiB0aGUgZW5yb2xsbWVudCBzZXJ2ZXIgYW5kIGFueSBpbnZvbHZl bWVudCBpbg0KPiBhY3R1YWwgb3BlcmF0aW9ucyBvZiB0aGUgb3ZlcmxheSwgaW5jbHVkaW5nIHRo ZSB0eXBlcyBvZiBzZXJ2aWNlcyB0aGF0DQo+IGFyZSBvZmZlcmVkIG9uIHRoZSBvdmVybGF5LiDC oEkgdGhpbmsgdGhpcyBmdW5jdGlvbmFsIHNlcGFyYXRpb24gaXMNCj4gZXNzZW50aWFsIHRvIGVu c3VyZSB0aGF0IHdlIHByb3ZpZGUgZmxleGlibGUgZGVwbG95bWVudCBvcHRpb25zLg0KPiA+DQo+ IA0KPiBUaGVyZSBpcyBhIGNsZWFyIHNlcGFyYXRpb24uICAgVGhlIG9ubHkgdGhpbmcgbGlua2lu ZyB0aGUgdHdvIGlzIHRoZQ0KPiBuZWVkIHRvIGhhdmUgdGhlIGtleSB1c2VkIHRvIHNpZ24gdGhl IGNvbmZpZ3VyYXRpb24gZG9jdW1lbnQuDQo+IA0KDQpUaGF0IGRvZXNuJ3Qgc291bmQgbGlrZSBj bGVhciBzZXBhcmF0aW9uIHRvIG1lLiAgTGV0IG1lIHB1dCBpdCBhbm90aGVyIHdheSAtIEknbSBs b29raW5nIGZvciBubyBkZXBlbmRlbmNpZXMgYmV0d2VlbiB0aGUgb3BlcmF0aW9uIG9mIGtpbmRz L3VzYWdlcyBvbiBhbiBvdmVybGF5IGFuZCB0aGUgb3ZlcmxheSBtYW5hZ2VtZW50IGl0c2VsZiAo Y29uZmlndXJhdGlvbiBiZWluZyBvbmUgYXNwZWN0IG9mIHRoZSBsYXR0ZXIpLiAgVGhlc2UgZnVu Y3Rpb25zIG1heSBiZSBwcm92aWRlZCBhbmQgbWFuYWdlZCBieSBkaWZmZXJlbnQgZW50aXRpZXMg YW5kIHdlIG5lZWQgdG8gYWxsb3cgZm9yIHN1Y2ggYSBtb2RlbC4gDQoNCjxzbmlwPg0KDQo+ID4N Cj4gPiBQYXJkb24gbXkgaWdub3JhbmNlIC0gd2hhdCdzIGEgQ0Ugb3ZlcmxheT8NCj4gPg0KPiAN Cj4gU29ycnksIGNvbnN1bWVyIGVsZWN0cm9uaWNzLiAgU28gc3VwcG9zZSBLb2RNaW5OaWsgb2Zm ZXJzIGJvdGggY2FtZXJhcw0KPiBhbmQgZGlnaXRhbCBwaWN0dXJlIGZyYW1lcyB0aGF0IGZvcm0g YW4gb3ZlcmxheSBpbiB0aGUgaG9tZS4gIFRoZQ0KPiBmaXJzdCBnZW5lcmF0aW9uIHByb2R1Y3Rz IGFsbCBoYXZlIHRoZSBzYW1lIHR5cGVzLCBhbmQgdGh1cyB0aGUgc2FtZQ0KPiBvdmVybGF5IGNv bmZpZyBmaWxlIHNpZ25lZCBieSBLb2RNaW5OaWsuICBXaGVuIHRoZSBzZWNvbmQgZ2VuZXJhdGlv bg0KPiBvZiBwcm9kdWN0cyBhcmUgcmVsZWFzZWQsIHRoZXJlIGFyZSBhIGNvdXBsZSBuZXcgdHlw ZXMsIGFuZCB0aHVzIGEgbmV3DQo+IGNvbmZpZyBmaWxlIHNpZ25lZCBieSBLb2RNaW5OaWsuICBX aGVuIGEgMm5kIGdlbmVyYXRpb24gcHJvZHVjdCBpcw0KPiBpbnRyb2R1Y2VkIGludG8gYSBob21l IGZvciB0aGUgZmlyc3QgdGltZSwgdGhlIDFzdCBnZW5lcmF0aW9uIGRldmljZXMNCj4gd2lsbCBz ZWUgdGhlIG5ldyBjb25maWcgZmlsZSBhbmQgdXBkYXRlIHRoZWlyIGNvcHkuICBFdmVuIHRob3Vn aA0KPiBLb2RNaW5OaWsgaGFzIG5vIGRpcmVjdCBjb250YWN0IHdpdGggdGhlIGluZGl2aWR1YWwg b3ZlcmxheSwgYW55DQo+IGRldmljZSB0aGF0IHJlcXVpcmVzIHRoZSBuZXcgdHlwZXMgd2lsbCBo YXZlIGEgc2lnbmVkIGNvbmZpZyBkb2N1bWVudA0KPiB0aGF0IGFsbCB0aGUgb2xkIGRldmljZXMg d291bGQgcmVjb2duaXplLCBzbyB0aGUgb3ZlcmxheSBpcyBtYW5hZ2VkDQo+IGFuZCByZWxpYWJp bGl0eSBpcyBlbnN1cmVkIGJ5IEtvZE1pbk5payB3aXRob3V0IGFuIGFjdGl2ZSBwcmVzZW5jZS4N Cj4gDQoNCkludGVyZXN0aW5nIHRoYXQgeW91IGV4cGxhaW4gb3ZlcmxheSBhcyBhbiBlbGVtZW50 IHByb3ZpZGVkIGFuZCBtYW5hZ2VkIGJ5IGVudGl0aWVzIHRoYXQgb2ZmZXIgZGV2aWNlcyBhbmQg c2VlIHRoZSBvdmVybGF5IGFzIG9wZXJhdGluZyBqdXN0IGFtb25nIHRob3NlIGRldmljZXMuICBJ IGxvb2sgYXQgaXQgZW50aXJlbHkgZGlmZmVyZW50bHkuICBDb25zaWRlciB0aGUgY2FzZSBvZiBh IEtvZGFrIGNhbWVyYSwgYSBTb255IFRWLCBteSBWZXJpem9uIHBob25lLCBteSBQQyBhdCBob21l IHRoYXQgaXMgb24gdGhlIENvbWNhc3QgbmV0d29yayBhbGwgZm9ybWluZyBhbiBvdmVybGF5LiAg VGhpcyBpcyBhbiBvdmVybGF5IG9mIGFsbCBteSBwZXJzb25hbCBkZXZpY2VzLiAgVGhpcyBpcyBh bHNvIGEgcGVyZmVjdCBjYW5kaWRhdGUgZm9yIG5vdCBuZWVkaW5nIGFuIGVucm9sbG1lbnQgc2Vy dmVyIGF0IGFsbCAtIGEgc2hhcmVkIHNlY3JldCBiYXNlZCBhZG1pc3Npb24gY29udHJvbCB3b3Jr cyBmaW5lLiAgSG93ZXZlciwgd2hlbiBhIG5ldyBwaG90byBkaXNwbGF5IGFwcGxpY2F0aW9uIHBv cHMgdXAsIGZvciBpbnN0YW5jZSwgSSdkIGxpa2UgbXkgY2FtZXJhIGFuZCBUViB0byBzdXBwb3J0 IGl0IHN1Y2ggdGhhdCBJIGNhbiBkaXNwbGF5IHRoZSBwaG90b3MgZnJvbSBteSBjYW1lcmEgb24g bXkgVFYuICBPbmNlIEkgZ2V0IHRoZSBuZWNlc3NhcnkgdXBncmFkZXMgdG8gc3VwcG9ydCB0aGUg bmV3IGtpbmRzLCBmcm9tIHNheSwgdGhlIHByb3ZpZGVyIG9mIHRoaXMgcGhvdG8gZGlzcGxheSBh cHAsIEZvbywgdGhlcmUgaXMgbm8gcmVhc29uIHdoeSBteSBQQyBvciBwaG9uZSBvciBhbnkgb3Ro ZXIgcGFydCBvZiB0aGUgb3ZlcmxheSBmdW5jdGlvbnMgb24gbXkgY2FtZXJhIG9yIFRWIGV2ZW4g c2hvdWxkIHRydXN0IGEgY2VydGlmaWNhdGUgc2lnbmVkIGJ5IEZvby4gIFRoZSBvbmx5IGVudGl0 aWVzIHRoYXQgbmVlZCB0byB0cnVzdCBpdCBhcmUgdGhlIG5ldyB1c2FnZSBpbnN0YW5jZXMgb24g dGhlIGNhbWVyYSBhbmQgVFYuICANCg0KSW1hZ2luZSB0aGUgb3ZlcmxheSB0byBiZSBhbmFsb2dv dXMgdG8gdGhlIEludGVybmV0LiAgQWxsIHVzYWdlcyBvbiB0aGUgb3ZlcmxheSBhcmUgbGlrZSBz ZXJ2aWNlcyBvbiB0aGUgSW50ZXJuZXQuICBZb3UgbWF5IG5lZWQgYWNjZXNzIGNvbnRyb2wgdG8g Z2V0IG9uIHRoZSBvdmVybGF5IChqdXN0IGxpa2UgeW91IG5lZWQgdG8gbG9nIGludG8gQ29tY2Fz dCBvciBZYWhvbyB0byBnZXQgb24gdGhlIEludGVybmV0KSAtIGJ1dCwgdGhhdCBwcm92aWRlciBo YXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBzZXJ2aWNlcyB0aGF0IHJ1biBvbiBpdC4gIFVsdGlt YXRlbHksIHlvdSB0cnVzdCBBbWF6b24ncyBjZXJ0aWZpY2F0ZSB3aGVuIHlvdSBhcmUgdXNpbmcg QW1hem9uJ3Mgc2VydmljZXM7IG5vdCBDb21jYXN0J3MuICANCg0KVGhlIHBvaW50IGluIGFsbCB0 aGlzIGlzIGNsZWFybHkgbm90IHRvIGRlYmF0ZSBwYXJ0aWN1bGFyIGRlcGxveW1lbnQgbW9kZWxz IG9yIHdoYXQgd2lsbCBldmVudHVhbGx5IHN1Y2NlZWQgLSBidXQsIGl0IGlzIHRoYXQgd2UgbXVz dCBiZSBtYWtpbmcgZGlmZmVyZW50IGRlcGxveW1lbnQgbW9kZWxzIGZlYXNpYmxlLiAgDQoNCkJl c3QsDQpWaWR5YSANCg== From vidyan@qualcomm.com Wed Mar 25 10:00:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57723A6BB3 for ; Wed, 25 Mar 2009 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.292 X-Spam-Level: X-Spam-Status: No, score=-103.292 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cZDNnW59hh1 for ; Wed, 25 Mar 2009 10:00:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B470F3A6BA1 for ; Wed, 25 Mar 2009 10:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238000454; x=1269536454; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20|CC:=20"Das,=20Sa umitra"=20,=0D=0A=20=20=20=20=20 =20=20=20"p2psip@ietf.org"=0D=0A=09 |Date:=20Wed,=2025=20Mar=202009=2010:00:51=20-0700 |Subject:=20RE:=20[P2PSIP]=20direct=20routing=20support |Thread-Topic:=20[P2PSIP]=20direct=20routing=20support |Thread-Index:=20AcmtQUx9S9hfU5GlRmyi6jTDPC9w9AAKYG8A |Message-ID:=20|References:=20<2D06DE445C2AD E44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> =0D=0A=09=20=0D=0A=09=20=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5564"=3B=20 a=3D"16584820"; bh=7PoKnTpv5kG/Hu9eqSQAL5ep2sMmtTazoJPZ38RsrYk=; b=uOlBJ6tk5GXxFWoo1InvueUL6iGrx4IJLHi9S7Y6A+9yj4wPx1A9BIG/ uBXN6bWWCghOr2UfxzR2O9gnvPAHaNsacMhhn4R/xwr3ul5wMjUrxT2h1 40psQ2JBfe/B4mJhR0w6hSiq1lP7DrOVVJFHKpmBr//8HCMSQ7vT4603O E=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16584820" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 10:00:54 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PH0rvd008589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 10:00:54 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PH0r6D022239 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 10:00:53 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 10:00:53 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 25 Mar 2009 10:00:51 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp Date: Wed, 25 Mar 2009 10:00:51 -0700 Thread-Topic: [P2PSIP] direct routing support Thread-Index: AcmtQUx9S9hfU5GlRmyi6jTDPC9w9AAKYG8A Message-ID: References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 17:00:02 -0000 PiA+Pg0KPiA+PiBUaGVyZSB3YXMgbm8gY29uc2Vuc3VzIHRvIGluY2x1ZGUgZGlyZWN0IHJlc3Bv bnNlIGluIHRoZSBiYXNlIGRyYWZ0Lg0KPiA+PiBIZXJlJ3MgdGhlIHRleHQgb2YgdGhlIGh1bSBm cm9tIHRoZSBub3RlcyB5b3UgcG9pbnQgdG86DQo+ID4+DQo+ID4+IC0tLS0tLS0tDQo+ID4+IEZp cnN0IGh1bTogwqB3aGV0aGVyIG9yIG5vdCB3ZSBpbmNsdWRlIGRpcmVjdCByb3V0aW5nIGFzIGFu IG9wdGlvbiBpbg0KPiA+PiB0aGUgcHJvdG9jb2wgKG5vdCB3b3JyeWluZyBhYm91dCB3aGF0IGRy YWZ0KTogwqByZXN1bHQgd2FzIGNvbnNlbnN1cw0KPiA+PiBmb3IgaW5jbHVkaW5nIGl0IGluIHRo ZSBwcm90b2NvbC4NCj4gPj4gLS0tLS0tLS0NCj4gPj4NCj4gPg0KPiA+IFJpZ2h0LCB0aGVyZSB3 YXMgY29uc2Vuc3VzIHRvIGluY2x1ZGUgaXQgaW4gdGhlIGJhc2UgcHJvdG9jb2wuDQo+IA0KPiBU aGUgdGV4dCBpbnNpZGUgdGhlIHBhcmVudGhlc2lzIG1lYW5zIHRoZXJlIHdhcyBubyBjb25zZW5z dXMgd2hlcmUgdG8NCj4gcHV0IGl0LCB0byBtZSBhdCBsZWFzdC4NCj4gDQoNCldoYXQgInByb3Rv Y29sIiBvdGhlciB0aGFuIFJFTE9BRCBpcyBiZWluZyByZWZlcnJlZCB0byBpbiB0aGF0IHN0YXRl bWVudCB0aGVuPyBJIGJlbGlldmUgdGhlIGRpc2N1c3Npb24gd2FzIGFib3V0IFJFTE9BRCwgd2l0 aG91dCB3b3JyeWluZyBhYm91dCB3aGV0aGVyIGl0IHdpbGwgYmUgYW5vdGhlciBkcmFmdCB0aGF0 IHdpbGwgYWRkIGl0IHRvIFJFTE9BRCBvciBpdCB3aWxsIGJlIHBhcnQgb2YgdGhlIGJhc2UgZHJh ZnQuICBJIHdhcyBsb29raW5nIGZvciB0aGUgY2hhaXJzIHRvIGNvbmZpcm0gdGhlIGNvbnNlbnN1 cyBvbiB0aGUgbGlzdCBhbmQgYWxzbyBhc2sgdGhlIHF1ZXN0aW9uIGFib3V0IHRoZSBkb2N1bWVu dCwgYnV0IEkgc2F3IG5vbmUgYWZ0ZXIgdGhlIG1lZXRpbmcuIA0KDQo8c25pcD4NCg0KPiA+DQo+ IA0KPiBJJ20gbm90IHN1cmUgd2hhdCB5b3UncmUgcmVmZXJyaW5nIHRvLg0KPiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXAycHNpcC1iYXNlLTAyI3NlY3Rpb24tNS4zLjIu NA0KPiBkb2Vzbid0IGRlZmluZSBhbnkgZm9yd2FyZGluZyBvcHRpb25zLCBpdCBkZWZpbmVzIGEg c3RydWN0dXJlIHRoYXQNCj4gZm9yd2FyZGluZyBvcHRpb25zIGNvdWxkIHVzZSwgYnV0IGRvZXMg bm90IGl0c2VsZiBkZWZpbmUgYSBmb3J3YXJkaW5nDQo+IG9wdGlvbiAoaS5lLiBubyB2YWx1ZXMg Zm9yICJ0eXBlIiBhcmUgZ2l2ZW4gbWVhbmluZykuDQo+IA0KPiBCcnVjZQ0KPiANCg0KU29ycnks IEkgd2FzIHJlZmVycmluZyB0byB0aGUgZmxhZ3MgZGVmaW5lZCBpbiB0aGF0IHNlY3Rpb24uICBJ J20gY29uZnVzZWQgYnkgdGhlbSBhbmQgdGhlIGRyYWZ0IGRvZXNuJ3Qgc2VlbSB0byBkZXNjcmli ZSB0aGVpciBwdXJwb3NlLiANCg0KVmlkeWENCg== From vidyan@qualcomm.com Wed Mar 25 10:07:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915C83A6A9A for ; Wed, 25 Mar 2009 10:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.246 X-Spam-Level: X-Spam-Status: No, score=-103.246 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prCcsCeeIEC5 for ; Wed, 25 Mar 2009 10:07:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B3F323A6D54 for ; Wed, 25 Mar 2009 10:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238000913; x=1269536913; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20,=20"Das,=20Saumi tra"=20|CC:=20"p2psip@ietf.org"=20 |Date:=20Wed,=2025=20Mar=202009=2010:08: 30=20-0700|Subject:=20RE:=20[P2PSIP]=20direct=20routing =20support|Thread-Topic:=20[P2PSIP]=20direct=20routing=20 support|Thread-Index:=20AcmtQbI6nqyn4DTgQRSgNGL08S3FCAAKb tsw|Message-ID:=20|References:=20<2D06DE445C 2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.co m>=0D=0A=09=0D=0A=09<2D06DE445C2ADE44890118C3F449B963 6D582E31@NASANEXMB12.na.qualcomm.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5564"=3B=20 a=3D"16585156"; bh=Djzn/gaK0YEYcPU7uQJ94yMFLdEngd4VSGeYEsb4S48=; b=FmOm7FmxYmppZgM7KOacr/1qSYYea37p8nZpLbWxYUR54KDqe/Kft92/ /ufy4ZYbTL3c/tEB27QurnTThPNK2UIAU+UHre4aMgQSizcrrGCw1Eg24 zS6Rp/+Z5fiHKGHod4RzTgSBZTMplgFT2ukNJxRRJH+KE6WolQQ+qkAFV k=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16585156" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 10:08:33 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PH8WO4009724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 10:08:33 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PH8WNE015384 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 10:08:32 -0700 (PDT) Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 10:08:31 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Wed, 25 Mar 2009 10:08:31 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp , "Das, Saumitra" Date: Wed, 25 Mar 2009 10:08:30 -0700 Thread-Topic: [P2PSIP] direct routing support Thread-Index: AcmtQbI6nqyn4DTgQRSgNGL08S3FCAAKbtsw Message-ID: References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> <2D06DE445C2ADE44890118C3F449B9636D582E31@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 17:07:44 -0000 DQogDQo+IElmIHRoZXJlIGlzIHRleHQgYW55d2hlcmUgaW4gdGhlIGJhc2UgZHJhZnQgdGhhdCBz YXlzIGRpcmVjdCByb3V0aW5nDQo+IGlzIG5vdCBzdXBwb3J0ZWQsIHBsZWFzZSBjaXRlIGEgbG9j YXRpb24gKHRoaXMgaXMgYSBnZW5lcmFsIHJlcXVlc3QNCj4gd2hlbmV2ZXIgYW55b25lIHNheXMg InRoZSBkcmFmdCBzYXlzIGZvbyIpLiAgDQoNCg0KUGxlYXNlIHNlZSB0aGlzIHRleHQgdG93YXJk cyB0aGUgZW5kIG9mIHNlY3Rpb24gQi4zOiANCg0KIiAgIEFuIGV4dGVuc2lvbiB0byBSRUxPQUQg dGhhdCBzdXBwb3J0cyBkaXJlY3QgcmVzcG9uc2Ugcm91dGluZyBidXQNCiAgIHJlbGllcyBvbiBz eW1tZXRyaWMgcmVzcG9uc2VzIGFzIGEgZmFsbGJhY2sgd291bGQgYmUgcG9zc2libGUsIGJ1dA0K ICAgZHVlIHRvIHRoZSBjb21wbGV4aXRpZXMgb2YgZGV0ZXJtaW5pbmcgd2hlbiB0byB1c2UgZGly ZWN0IHJlc3BvbnNlDQogICBhbmQgd2hlbiB0byBmYWxsYmFjayB0byBzeW1tZXRyaWMsIGFuZCB0 aGUgcmVkdWNlZCBwZXJmb3JtYW5jZSBmb3INCiAgIHJlc3BvbnNlcyB0byBwZWVycyBiZWhpbmQg cmVzdHJpY3RpdmUgTkFUcywgd2UgaGF2ZSBjaG9zZW4gbm90IHRvDQogICBpbmNsdWRlIGl0IGFz IGFuIG9wdGlvbiBhdCB0aGlzIHBvaW50LiIgDQoNCkkgYmVsaWV2ZSB0aGUgZGlzY3Vzc2lvbiBp biBNaW5uZWFwb2xpcyB3YXMgbm90IGFib3V0IG1ha2luZyBpdCBhbiBleHRlbnNpb24gdG8gUkVM T0FELCByYXRoZXIsIG1ha2luZyBpdCBhIHBhcnQgKGFuZCBhbiBvcHRpb24pIG9mIFJFTE9BRC4g IA0KDQpWaWR5YQ0K From ron.even.tlv@gmail.com Wed Mar 25 11:01:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13163A6A96 for ; Wed, 25 Mar 2009 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjuvwZJiNe52 for ; Wed, 25 Mar 2009 11:01:26 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id A7C433A67F4 for ; Wed, 25 Mar 2009 11:01:26 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so154160qwb.31 for ; Wed, 25 Mar 2009 11:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=fV5MyfMGdx29e8NchoUWARzwPrPWwxca4AGPk4X5SOg=; b=GpanVJ5UB3N7vxp9WfrqxPSHyLYtuoZ9QmpfWRFcZRWlTFmhC1c4Ru/c057xnGraVs KpQTlIrVbztZjChwDvRJLM6Mg7ur6QBGEaFT3KJrM5cIHO5IYW5310sfVgtSYG9q0jvl 0reVJML0928KKkZOU/P35u3CQshGkAHxcgA7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=XgsCJymjUWkfxoioYOXE47WNz356TYtKO1q2f+k6bj+DJDGW9hMa0C6dCJUQKtYxST cxPHzXtlA32LQMz2jNO6R4eYmUlLqnkPCR9pFLJofV06Y0dcm4L9w64sSJq4Ne/Fprb4 Z3p5xnWCzOarCuKK51FenO4PwCVzOmABHJYpw= Received: by 10.143.10.15 with SMTP id n15mr4020715wfi.319.1238004137986; Wed, 25 Mar 2009 11:02:17 -0700 (PDT) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by mx.google.com with ESMTPS id 29sm16339655wfg.53.2009.03.25.11.02.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 11:02:17 -0700 (PDT) From: "Roni Even" To: "'Narayanan, Vidya'" , "'Bruce Lowekamp'" , "'Das, Saumitra'" References: <2D06DE445C2ADE44890118C3F449B9636D582DF9@NASANEXMB12.na.qualcomm.com> <2D06DE445C2ADE44890118C3F449B9636D582E31@NASANEXMB12.na.qualcomm.com> In-Reply-To: Date: Wed, 25 Mar 2009 11:01:12 +0200 Message-ID: <49ca71a9.1d078e0a.1f0a.1857@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmtQbI6nqyn4DTgQRSgNGL08S3FCAAKbtswABEFCbA= Content-Language: en-us Cc: p2psip@ietf.org Subject: Re: [P2PSIP] direct routing support X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 18:01:27 -0000 Hi, I agree with Bruce that it was not decided where the direct response functionality will be defined. Currently http://tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt specifies the extension for direct response as well as relay response. I will present the document on Friday session since Jiang XingFeng could not attend the meeting. I have no preference where direct response or relay support is specified but the Jiang draft tries to address the fall back issues as well as the needed extensions to forwarding header for this solution to work. Roni Even -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Narayanan, Vidya Sent: Wednesday, March 25, 2009 7:09 PM To: Bruce Lowekamp; Das, Saumitra Cc: p2psip@ietf.org Subject: Re: [P2PSIP] direct routing support > If there is text anywhere in the base draft that says direct routing > is not supported, please cite a location (this is a general request > whenever anyone says "the draft says foo"). Please see this text towards the end of section B.3: " An extension to RELOAD that supports direct response routing but relies on symmetric responses as a fallback would be possible, but due to the complexities of determining when to use direct response and when to fallback to symmetric, and the reduced performance for responses to peers behind restrictive NATs, we have chosen not to include it as an option at this point." I believe the discussion in Minneapolis was not about making it an extension to RELOAD, rather, making it a part (and an option) of RELOAD. Vidya _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From davidbryan@gmail.com Wed Mar 25 17:18:12 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C781C3A67AD for ; Wed, 25 Mar 2009 17:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIfE2qrPW4iY for ; Wed, 25 Mar 2009 17:18:12 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 02DD628C171 for ; Wed, 25 Mar 2009 17:18:02 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so325016wfg.31 for ; Wed, 25 Mar 2009 17:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Q8jgNu8ZFOJz6Vwjv7XK4QDUJtx35/70NtSY9WsMmV8=; b=kAHYsolH08+w2bW3eGsKBUBUymTAHhkdIb5UTm/6CrNArWuIbUPGNDbuYMfRL8O9Yf v/OJxbxhiEVLbD0MK83VV5pJrvnekcppbW0vpPLcORBhgXrd8zH3EdlzW6oibu54b6tQ /PkWQ2G6XG1nSBvO6Ndvn9cbl7zWyvtUFjbuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xT+1rxpZ+YepRK3d1FAjCTTzh7Ka0Ws4sOuDX2vCOqlvGfcoUhYKRCdwebRiIUWVjH urIjG+bcBTdF+qEygp1D5+JbQ0EIYchIag3OtuOTHwjjvCTtqe72mG97aPnKGZ+Gomos 4fZqU3G0bj4UxSErEUhcHAUDPE6MxtuNaH77g= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.143.32.7 with SMTP id k7mr81213wfj.162.1238026735905; Wed, 25 Mar 2009 17:18:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2009 17:18:55 -0700 X-Google-Sender-Auth: 902b173b6b00889b Message-ID: <8b2769930903251718q10d6a10cx3847718856c5ee45@mail.gmail.com> From: "David A. Bryan" To: Frank Weber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Expired draft-ietf-p2psip-concepts-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 00:18:12 -0000 It has indeed expired. The plan for this document is that it will serve as a "how we got here" as well as a terminology draft, and as a result, will be updated to stay current, we just got a bit behind. You can expect to see a new version shortly. Sorry. David (as an individual) On Tue, Mar 24, 2009 at 6:53 AM, Frank Weber wrote: > In draft-ietf-p2psip-concepts-02, a substantial revision is denoted for > future versions of this draft. As the 02 version of this draft has already > expired, could anybody please state whether (and maybe when?) a revised > draft version is in sight? > > Thanks and best regards > > Frank > > ----------------------------------------------------------- > Dipl.-Ing. (FH) Frank Weber > FH Frankfurt/M. - University of Applied Sciences > Research Group for Telecommunication Networks > Frankfurt/M., Germany > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From sa2086@columbia.edu Wed Mar 25 18:12:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AAF3A6832 for ; Wed, 25 Mar 2009 18:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTL-T+B7Nkm7 for ; Wed, 25 Mar 2009 18:12:19 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id C423F3A680A for ; Wed, 25 Mar 2009 18:12:19 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2Q1DCZk019901 for ; Wed, 25 Mar 2009 21:13:12 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2Q1DB4d025694 for ; Wed, 25 Mar 2009 21:13:11 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2Q1DBuA025691 for ; Wed, 25 Mar 2009 21:13:11 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Wed, 25 Mar 2009 21:13:11 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: "p2psip@ietf.org" In-Reply-To: Message-ID: References: <20090318211247.74FE250822@romeo.rtfm.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Subject: [P2PSIP] Comments on draft-ietf-p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 01:12:20 -0000 It is necessary to clarify the scope of the problems that are being addressed and to precisly define what 'diagnostics' mean. Currently, it is very open ended and includes: -routing diagnostics -detecting malfunctioning or badly behaving peers -checking the health of overlay Overlay maintenance is central to any p2p system. How is that different from diagnostics? The suggested solution incorporates two new methods. I think we need a bit more clarity on what is that existing methods cannot achieve, for which new methods are required. As an example, one can easily implement Path_Track using RouteQuery and [Node]Fetch. What is indeed required is a mechanism to obtain the state [routing/storage] of a node. This can be done using NodeFetch and may also be accomplished using Fetch. -salman From jiang.x.f@huawei.com Wed Mar 25 18:18:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076623A6967 for ; Wed, 25 Mar 2009 18:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8om7wzzegqF for ; Wed, 25 Mar 2009 18:18:12 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D23083A6DA8 for ; Wed, 25 Mar 2009 18:18:09 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH300BDOABG3Z@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 26 Mar 2009 09:18:52 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH3003IJABGZ1@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 26 Mar 2009 09:18:52 +0800 (CST) Received: from j36340a ([10.164.12.23]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KH30028OABF9R@szxml06-in.huawei.com> for p2psip@ietf.org; Thu, 26 Mar 2009 09:18:51 +0800 (CST) Date: Thu, 26 Mar 2009 09:18:51 +0800 From: jiangxingfeng In-reply-to: To: 'Salman Abdul Baset' , "'Narayanan, Vidya'" Message-id: <007d01c9adb0$d2b5f800$170ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcmtEPitLCvaZlMZRHWJf1msz02U8AAnYzHg Cc: p2psip@ietf.org Subject: Re: [P2PSIP] TURN usage in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 01:18:13 -0000 Hi, I also like (3). But a peer can not make sure that his neighbor must have a peer of public address (i.e, its neighbor peer can act as a TURN server); so in order to improve the lookup success rate for TURN server, we can do as follows: if there is no TURN server in his neighbor peers, it can ask its neighbor peers to ask their neighbor peers until finding a TURN server or failed due to scope limit. So maybe we should extend the searching scope by defining a new message like LookUpServicePeer in SEP( http://www.p2psip.org/drafts/draft-jiang-p2psip-sep-01.txt ) to improve the searching success rate. In order to make the lookup operation successful when a peer reaches the destination peer, the key for the lookup message can be set to a key which is hashed by a standard service name, for example, turn.exaple.com; On the other hand, we can add replica parameters to a standard service name to make the resource stored in several separated locations in DHT. It may improve load balance of the look up operation. Regards Jiang XingFeng > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > Salman Abdul Baset > Sent: Wednesday, March 25, 2009 2:14 PM > To: Narayanan, Vidya > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] TURN usage in RELOAD > > > Multiple peers can provide the TURN service. Using a single name for TURN > service has the problem that H(turn_service_name) maps to a single node. > This implies that all STORE and FIND requests can potentially terminate at > a single node, overburderning it, and creating a single point of failure. > > 1) The written text is one way to address this problem. > > 2) The ReDiR approach proposed in OpenDHT paper also addresses this > problem. It stores the TURN record under a two-dimensional tree. A TURN > record is stored under H(turn_service_name + L + rand[1,2^L) ) > > where L is the level of the tree, starting from 0. > > 3) Another approach is to only admit nodes in the overlay that can provide > the TURN service. This means that all peers in the routing table of a peer > can potentially provide the TURN service. A client looking for a TURN > server asks its peer, which returns a peer providing the TURN service from > its routing table. This approach works both for DHTs and unstructured > networks. > > Assuming the default overlay algorithm is a DHT, I prefer the ReDiR > approach as the generic mechanism for TURN server discovery because it is > deterministic in nature than (1). However, this is something the WG can > discuss. > > For Internet deployments with sufficient number of peers with public IP > addresses, I prefer (3) because the lookup time is O(1). > > -s > > On Tue, 24 Mar 2009, Narayanan, Vidya wrote: > > > The currently specified TURN usage in RELOAD is rather odd to me. I suppose > it tries to load balance and spread the storage of TURN server information in > various parts of the overlay. But then, load balancing and distribution of > popular data is a much more generic problem that needs to be handled in a fashion > independent of the usage anyway. > > > > In the current definition, a node looking for a TURN server keeps looking > up a random resource ID until it finds a match for data corresponding to the > TURN-SERVICE type. This seems rather inefficient to me. It also puts yet > another somewhat dynamic parameter into the configuration document > (turnDensity). > > > > It seems that a far simpler design would be to treat it like a generic keyword > storage, where a TURN-SERVICE kind stores data at a location corresponding to, > say, h(TURN). It is a well-known resource name that will allow nodes to find > a TURN server in a deterministic fashion. This can utilize the authorization > model where any node can write to that resource id, but only the creator is > allowed to modify its own entry. In any event, a node-id based authorization > is quite irrelevant for this service. > > > > Any load balancing or caching of information at other points in the overlay > should be handled by generic mechanisms that can be used by any usage on the > overlay. In fact, simple on-path caching will allow permeation of this data > in various parts of the overlay rather quickly, since many nodes are likely > to look for TURN services. > > > > Vidya > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > > From bbl@lowekamp.net Wed Mar 25 19:15:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D4B3A6809 for ; Wed, 25 Mar 2009 19:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3fkkNqo+rb2 for ; Wed, 25 Mar 2009 19:15:39 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id A50A23A659C for ; Wed, 25 Mar 2009 19:15:39 -0700 (PDT) Received: by qyk36 with SMTP id 36so702171qyk.29 for ; Wed, 25 Mar 2009 19:16:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.110.6 with SMTP id l6mr74070qcp.52.1238033792048; Wed, 25 Mar 2009 19:16:32 -0700 (PDT) In-Reply-To: References: <20090318211247.74FE250822@romeo.rtfm.com> Date: Wed, 25 Mar 2009 22:16:31 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 02:15:40 -0000 On Wed, Mar 25, 2009 at 11:23 AM, Salman Abdul Baset wrote: > "RELOAD uses TCP for achieving hop-by-hop reliability and relies on exist= ing > techniques to solve inbound TCP connection problem. When direct connectio= n > fails, the node (a) only participates as a client or (b) particpates as a > peer and uses a TCP TURN server to achieve a 1-hop connection with its > connection table entries. > > Alternatively, a peer can use a TCP-over-UDP protocol to establish direct > connections and to achieve reliability. However, we do not specify such a > protocol." > Salman, Simply refusing to admit that use cases exist where TCP can't be used between all peers does not make them go away. Bruce > -s > > > On Wed, 25 Mar 2009, Bruce Lowekamp wrote: > >> Salman, >> >> Based on your list, I'm going to assume you agree with the current >> proposal. =C2=A0RELOAD supports (and prefers) a TCP overlay link protoco= l, >> and it offers a UDP-based protocol when that doesn't work. =C2=A0I'd ful= ly >> support a simple use RFCXXXX for a TCP-over-UDP protocol, but since >> there isn't one, we have a goal of something that should work, even if >> it doesn't reach "ideal" (TCP-like) performance. =C2=A0If you believe mo= re >> needs to be done to specify a real TCP over UDP, I fully support you >> advancing that in TSV. >> >> Bruce >> >> >> On Thu, Mar 19, 2009 at 12:13 AM, Salman =C2=A0Abdul Baset >> wrote: >>> >>> On Wed, 18 Mar 2009, Bruce Lowekamp wrote: >>> >>>> That paper in particular, and the reasons UDP connections are more >>>> reliably formed than TCP, have been discussed numerous times in >>>> MMUSIC, and I really don't think we should be repeating the whole >>>> conversation here. =C2=A0But the summary is that it's not nearly as >>>> universal a solution as indicated in that paper. >>>> >>>> Bruce >>> >>> Sure. I have already mentioned that this is a IMC'05 paper and more >>> recent >>> data, if available, is helpful and needed. >>> >>> There are at least four solutions to the hop-by-hop reliability problem= : >>> >>> (1) Clients >>> Nodes behind TCP *un*friendly NATs can always act as clients and >>> establish a >>> TCP connection(s) with reachable node(s). The reachable nodes can be >>> behind >>> friendly NATs or they can have a public IP address. >>> >>> (2) Full peer but use relay peer(s) >>> A node participates as a peer. It establishes TCP connection with >>> reachable >>> peers, which inturn establish a TCP connection with the nodes' connecti= on >>> table entries. >>> >>> (3) Full peer with techniques for direct TCP connection establishment >>> A node participates as a peer and uses TCP traversal techniques for >>> establishing direct connection (including Dean's upcoming ones:) >>> >>> (4) Full peer with TCP-over-UDP >>> Since TCP traversal may fail, design/reuse a reliable congestion contro= l >>> protocol over UDP. >>> >>> >>> Note that: >>> (1) and (2) always work. >>> >>> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >>> UDP-blocking firewalls. >>> >>> (4) is feasible over (3) since UDP has a better chance of connection >>> establishment when NATs are not cascaded. However, UDP blocking firewal= ls >>> need to be factored in this feasible discussion. Again, any recent data >>> is >>> helpful. >>> >>> >>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the weakes= t >>> link in the routing chain. Approaches which recover every loss using >>> timeout >>> may not be the most feasible ones. >>> >>> >>> -salman >>> >> > From sa2086@columbia.edu Thu Mar 26 02:35:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F763A689F for ; Thu, 26 Mar 2009 02:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJejHjvGq3-7 for ; Thu, 26 Mar 2009 02:35:14 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 601943A681C for ; Thu, 26 Mar 2009 02:35:14 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2Q9a63x028634; Thu, 26 Mar 2009 05:36:06 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2Q9a6RI014641; Thu, 26 Mar 2009 05:36:06 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2Q9a66Y014638; Thu, 26 Mar 2009 05:36:06 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 26 Mar 2009 05:36:06 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <20090318211247.74FE250822@romeo.rtfm.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 09:35:15 -0000 > > Salman > > Simply refusing to admit that use cases exist where TCP can't be used > between all peers does not make them go away. > > Bruce I think I have been pretty clear that there are scenarios where TCP cannot be used; however, it is still an open question whether they are dominant ones, and if they are, an adhoc approach with poor performance is not the answer. Further, direct connections for both UDP and TCP do not work for cascaded NATs. I have earlier outlined solutions for scenarios where TCP cannot be used (see 1-3 below) that do not require a TCP-over-UDP or a similar approach. They are a full peer with connections established over TCP through a relay peer, developing techniques for direct TCP connection establishment (in BEHAVE WG), or downgrading a peer to a client. -salman >>>> (1) Clients >>>> Nodes behind TCP *un*friendly NATs can always act as clients and >>>> establish a >>>> TCP connection(s) with reachable node(s). The reachable nodes can be >>>> behind >>>> friendly NATs or they can have a public IP address. >>>> >>>> (2) Full peer but use relay peer(s) >>>> A node participates as a peer. It establishes TCP connection with >>>> reachable >>>> peers, which inturn establish a TCP connection with the nodes' connection >>>> table entries. >>>> >>>> (3) Full peer with techniques for direct TCP connection establishment >>>> A node participates as a peer and uses TCP traversal techniques for >>>> establishing direct connection (including Dean's upcoming ones:) >>>> >>>> (4) Full peer with TCP-over-UDP >>>> Since TCP traversal may fail, design/reuse a reliable congestion control >>>> protocol over UDP. >>>> >>>> >>>> Note that: >>>> (1) and (2) always work. >>>> >>>> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >>>> UDP-blocking firewalls. >>>> >>>> (4) is feasible over (3) since UDP has a better chance of connection >>>> establishment when NATs are not cascaded. However, UDP blocking firewalls >>>> need to be factored in this feasible discussion. Again, any recent data >>>> is >>>> helpful. >>>> >>>> >>>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the weakest >>>> link in the routing chain. Approaches which recover every loss using >>>> timeout >>>> may not be the most feasible ones. >>>> >>>> >>>> -salman >>>> >>> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Thu Mar 26 05:10:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106DD3A68BC for ; Thu, 26 Mar 2009 05:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Grh7Ydl8QyUB for ; Thu, 26 Mar 2009 05:10:35 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id DD8583A6801 for ; Thu, 26 Mar 2009 05:10:34 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so486162qwb.31 for ; Thu, 26 Mar 2009 05:11:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.84.72 with SMTP id i8mr113425qcl.63.1238069487524; Thu, 26 Mar 2009 05:11:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2009 08:11:27 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Configuration Updates in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 12:10:36 -0000 On Wed, Mar 25, 2009 at 12:50 PM, Narayanan, Vidya wr= ote: > > >> =C2=A0I'd like to see a clear separation >> in functionality between the enrollment server and any involvement in >> actual operations of the overlay, including the types of services that >> are offered on the overlay. =C2=A0I think this functional separation is >> essential to ensure that we provide flexible deployment options. >> > >> >> There is a clear separation. =C2=A0 The only thing linking the two is th= e >> need to have the key used to sign the configuration document. >> > > That doesn't sound like clear separation to me. =C2=A0Let me put it anoth= er way - I'm looking for no dependencies between the operation of kinds/usa= ges on an overlay and the overlay management itself (configuration being on= e aspect of the latter). =C2=A0These functions may be provided and managed = by different entities and we need to allow for such a model. > So let's break this up into two questions: First, is the entity that forms the overlay the one that decides what goes in it? I would say the answer to this is clearly yes. I hope we can agree on that, subject to the second question. Second question is whether that entity can decide that what they really want to do is support an anything-goes overlay? I'm actually OK with this, I just think that the result of the process needs to be that there is a configuration document that gets updated reflecting what's going on in the overlay. The short summary, I think, is what we would need would be a draft specifying how a group of peers decide to update the overlay config in a completely ad hoc case where there is no central administrator of any type (not even the home owner running a control panel on their PC). Here's why I think this is important. Split the kinds into two types based on whether they're IANA registered or not. If they are IANA registered, then the data-model and access-control attributes are predefined. The only ones that are allowed to vary by overlay are max-count and max-size. Personally, I think these are useful to specify, but I don't think it would be that big a deal if they weren't in unmanaged cases. So the only purpose of the configuration file here is so that devices don't need to constantly query IANA for the complete list of all registered kinds, even ones they don't care about. More importantly, let's look at non-IANA kinds. Here the configuration file serves two purposes: - define the access control - establish the kind-id to be used on the overlay. I still disagree that access control can be defined on a per-user basis, since I think there will be lots of problems if two devices arrive expecting different access control policies for the same kind, and I think allowing this opens up a number of other security attacks that don't exist otherwise. But, more importantly, how do you determine kind-ids without a config document that is updated either by an overlay manager or by a distributed algorithm? If two devices from the same manufacturer are on the same overlay, they need to be using the same kind-id if there is any intent to share data. So, I'm OK without a central overlay manager, but I think the only alternative is to write a protocol for distributed generation of the config file. Bruce > > >> > >> > Pardon my ignorance - what's a CE overlay? >> > >> >> Sorry, consumer electronics. =C2=A0So suppose KodMinNik offers both came= ras >> and digital picture frames that form an overlay in the home. =C2=A0The >> first generation products all have the same types, and thus the same >> overlay config file signed by KodMinNik. =C2=A0When the second generatio= n >> of products are released, there are a couple new types, and thus a new >> config file signed by KodMinNik. =C2=A0When a 2nd generation product is >> introduced into a home for the first time, the 1st generation devices >> will see the new config file and update their copy. =C2=A0Even though >> KodMinNik has no direct contact with the individual overlay, any >> device that requires the new types will have a signed config document >> that all the old devices would recognize, so the overlay is managed >> and reliability is ensured by KodMinNik without an active presence. >> > > Interesting that you explain overlay as an element provided and managed b= y entities that offer devices and see the overlay as operating just among t= hose devices. =C2=A0I look at it entirely differently. =C2=A0Consider the c= ase of a Kodak camera, a Sony TV, my Verizon phone, my PC at home that is o= n the Comcast network all forming an overlay. =C2=A0This is an overlay of a= ll my personal devices. =C2=A0This is also a perfect candidate for not need= ing an enrollment server at all - a shared secret based admission control w= orks fine. =C2=A0However, when a new photo display application pops up, for= instance, I'd like my camera and TV to support it such that I can display = the photos from my camera on my TV. =C2=A0Once I get the necessary upgrades= to support the new kinds, from say, the provider of this photo display app= , Foo, there is no reason why my PC or phone or any other part of the overl= ay functions on my camera or TV even should trust a certificate signed by F= oo. =C2=A0The only entities that need to trust it are the new usage instanc= es on the camera and TV. > > Imagine the overlay to be analogous to the Internet. =C2=A0All usages on = the overlay are like services on the Internet. =C2=A0You may need access co= ntrol to get on the overlay (just like you need to log into Comcast or Yaho= o to get on the Internet) - but, that provider has nothing to do with the s= ervices that run on it. =C2=A0Ultimately, you trust Amazon's certificate wh= en you are using Amazon's services; not Comcast's. > > The point in all this is clearly not to debate particular deployment mode= ls or what will eventually succeed - but, it is that we must be making diff= erent deployment models feasible. > > Best, > Vidya > From bbl@lowekamp.net Thu Mar 26 11:04:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8683A67E6 for ; Thu, 26 Mar 2009 11:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8reJcqe-yTI for ; Thu, 26 Mar 2009 11:04:16 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 9F7623A6358 for ; Thu, 26 Mar 2009 11:04:16 -0700 (PDT) Received: by qyk36 with SMTP id 36so1301774qyk.29 for ; Thu, 26 Mar 2009 11:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.98.141 with SMTP id q13mr544901qcn.3.1238090709828; Thu, 26 Mar 2009 11:05:09 -0700 (PDT) In-Reply-To: References: <20090318211247.74FE250822@romeo.rtfm.com> Date: Thu, 26 Mar 2009 14:05:09 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 18:04:17 -0000 On Thu, Mar 26, 2009 at 5:36 AM, Salman Abdul Baset wrote: >> >> Salman >> >> Simply refusing to admit that use cases exist where TCP can't be used >> between all peers does not make them go away. >> >> Bruce > > I think I have been pretty clear that there are scenarios where TCP cannot > be used; however, it is still an open question whether they are dominant > ones, and if they are, an adhoc approach with poor performance is not the > answer. Further, direct connections for both UDP and TCP do not work for > cascaded NATs. > > I have earlier outlined solutions for scenarios where TCP cannot be used > (see 1-3 below) that do not require a TCP-over-UDP or a similar approach. > They are a full peer with connections established over TCP through a relay > peer, developing techniques for direct TCP connection establishment (in > BEHAVE WG), or downgrading a peer to a client. > - There are still people who want to run UDP between peers. Yes there are other options for some of those scenarios, but not all. Your solutions simply don't address all of the problem space. Feel free to submit a draft proposing to limit the problem space the protocol is trying to solve. - You have not demonstrated that any of the proposed UDP protocols have performance inadequate to the requirements of the scenarios in which they are likely to be needed. Sure they're not up to TCP's performance. That's not the goal. - I don't understand why you keep bringing up cascaded NATs. Yes, it's possible to come up with a NAT/Firewall configuration that will block any given solution. The point is not that there may exist systems where a particular solution won't work, it's trying to develop a solution that solves the vast majority of common cases. Bruce > -salman > > > >>>>> (1) Clients >>>>> Nodes behind TCP *un*friendly NATs can always act as clients and >>>>> establish a >>>>> TCP connection(s) with reachable node(s). The reachable nodes can be >>>>> behind >>>>> friendly NATs or they can have a public IP address. >>>>> >>>>> (2) Full peer but use relay peer(s) >>>>> A node participates as a peer. It establishes TCP connection with >>>>> reachable >>>>> peers, which inturn establish a TCP connection with the nodes' >>>>> connection >>>>> table entries. >>>>> >>>>> (3) Full peer with techniques for direct TCP connection establishment >>>>> A node participates as a peer and uses TCP traversal techniques for >>>>> establishing direct connection (including Dean's upcoming ones:) >>>>> >>>>> (4) Full peer with TCP-over-UDP >>>>> Since TCP traversal may fail, design/reuse a reliable congestion >>>>> control >>>>> protocol over UDP. >>>>> >>>>> >>>>> Note that: >>>>> (1) and (2) always work. >>>>> >>>>> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >>>>> UDP-blocking firewalls. >>>>> >>>>> (4) is feasible over (3) since UDP has a better chance of connection >>>>> establishment when NATs are not cascaded. However, UDP blocking >>>>> firewalls >>>>> need to be factored in this feasible discussion. Again, any recent data >>>>> is >>>>> helpful. >>>>> >>>>> >>>>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the >>>>> weakest >>>>> link in the routing chain. Approaches which recover every loss using >>>>> timeout >>>>> may not be the most feasible ones. >>>>> >>>>> >>>>> -salman >>>>> >>>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From sa2086@columbia.edu Thu Mar 26 13:10:01 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4483A69A3 for ; Thu, 26 Mar 2009 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS6hDyl37Hph for ; Thu, 26 Mar 2009 13:10:00 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 3C6003A698F for ; Thu, 26 Mar 2009 13:10:00 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2QKAqHU010312; Thu, 26 Mar 2009 16:10:53 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2QKAqVx008342; Thu, 26 Mar 2009 16:10:52 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2QKAqDX008338; Thu, 26 Mar 2009 16:10:52 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 26 Mar 2009 16:10:52 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: <20090318211247.74FE250822@romeo.rtfm.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 26 Mar 2009 20:10:01 -0000 > - There are still people who want to run UDP between peers. Yes there > are other options for some of those scenarios, but not all. Your > solutions simply don't address all of the problem space. Feel free to > submit a draft proposing to limit the problem space the protocol is > trying to solve. Perhaps, people who *only* want to run UDP between peers should submit a seperate draft. It is not something that should be in the base draft when there are alternate solutions. It is incorrect to say that my solutions don't address these scenarios. Establishing TCP connections through mutually reachable peers always work. Downgrading a node to a client, and establishing a TCP connection with a reachable peer always work. Again, please see (1) and (2) below. Also, people are working on techniques for establishing direct TCP connection. > - You have not demonstrated that any of the proposed UDP protocols > have performance inadequate to the requirements of the scenarios in > which they are likely to be needed. Sure they're not up to TCP's > performance. That's not the goal. I have said it repeatedly that the proposed UDP protocols only recover losses using *timeouts*. It is well known that recovering losses using timeouts is a big performance hit. Any TSV person should say this. > - I don't understand why you keep bringing up cascaded NATs. Yes, > it's possible to come up with a NAT/Firewall configuration that will > block any given solution. The point is not that there may exist > systems where a particular solution won't work, it's trying to develop > a solution that solves the vast majority of common cases. I am curious if you have data indicating that for common cases, TCP connections don't work and UDP do? You don't agree with the assertions in the 'Characterizing IMC'05' paper and that's fine. But can you point to the latest data? -- I am not religiously against running UDP between peers :). However, based on reasons stated earlier, I think that RELOAD base draft of the P2PSIP WG is the *not* right place to insert a reliable congestion control protocol. It is easy to get these protocols wrong than right. We should not abandon well designed TCP stacks so easily. As a practical insight, Skype application will not connect to the Skype network if it cannot establish a TCP connection with a Skype super node. For those who want to run UDP, I totally agree with your idea of use RFC-XXXX for a TCP-over-UDP protocol. I want to keep our focus on the issues of P2PSIP protocol such as configuration, security, and overlay maintenance. Regards, Salman >> >> >>>>>> (1) Clients >>>>>> Nodes behind TCP *un*friendly NATs can always act as clients and >>>>>> establish a >>>>>> TCP connection(s) with reachable node(s). The reachable nodes can be >>>>>> behind >>>>>> friendly NATs or they can have a public IP address. >>>>>> >>>>>> (2) Full peer but use relay peer(s) >>>>>> A node participates as a peer. It establishes TCP connection with >>>>>> reachable >>>>>> peers, which inturn establish a TCP connection with the nodes' >>>>>> connection >>>>>> table entries. >>>>>> >>>>>> (3) Full peer with techniques for direct TCP connection establishment >>>>>> A node participates as a peer and uses TCP traversal techniques for >>>>>> establishing direct connection (including Dean's upcoming ones:) >>>>>> >>>>>> (4) Full peer with TCP-over-UDP >>>>>> Since TCP traversal may fail, design/reuse a reliable congestion >>>>>> control >>>>>> protocol over UDP. >>>>>> >>>>>> >>>>>> Note that: >>>>>> (1) and (2) always work. >>>>>> >>>>>> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >>>>>> UDP-blocking firewalls. >>>>>> >>>>>> (4) is feasible over (3) since UDP has a better chance of connection >>>>>> establishment when NATs are not cascaded. However, UDP blocking >>>>>> firewalls >>>>>> need to be factored in this feasible discussion. Again, any recent data >>>>>> is >>>>>> helpful. >>>>>> >>>>>> >>>>>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>>>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the >>>>>> weakest >>>>>> link in the routing chain. Approaches which recover every loss using >>>>>> timeout >>>>>> may not be the most feasible ones. >>>>>> >>>>>> >>>>>> -salman >>>>>> >>>>> >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> > > From vidyan@qualcomm.com Thu Mar 26 17:09:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2183628C1B9 for ; Thu, 26 Mar 2009 17:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.169 X-Spam-Level: X-Spam-Status: No, score=-105.169 tagged_above=-999 required=5 tests=[AWL=1.430, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q9aG5puZu+Z for ; Thu, 26 Mar 2009 17:09:58 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 1B0DC28C1B7 for ; Thu, 26 Mar 2009 17:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238112652; x=1269648652; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Thu,=2026=20Mar=20200 9=2017:10:43=20-0700|Subject:=20Separation=20of=20identit y=20assignment=20and=20service=20provider=20roles=20(RE: =0D=0A=20[P2PSIP]=20Configuration=20Updates=20in=20RELOAD )|Thread-Topic:=20Separation=20of=20identity=20assignment =20and=20service=20provider=20roles=0D=0A=20(RE:=20[P2PSI P]=20Configuration=20Updates=20in=20RELOAD)|Thread-Index: =20AcmuDAROy0X5p/kHR6GEDwuCUgVbNQAYsoCA|Message-ID:=20|References:=20=0D=0A=09=20=0D =0A=09=20=0D=0A=09=20=0D=0A=09=20=0D=0A=20|In-Reply-To:=20|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5565"=3B=20 a=3D"16651552"; bh=1UXIHkjlVpBd0ePEfzvhPA0wtNJv5RrH51cWO+CtO0w=; b=KdocDaXauJmxhSgQrONvMJBLeEIXGb/1n6HIjM4dXwBqWNmr/LK6KKIX rTMXQeUyunuOdoHeu3tZCpN1wjX0uhfsNsbq3lx7xmD0ZU+H9AMHaOtq6 A0kickvwHJu5psjCjaRCHKUCpVKb6+i2xyMKkY8PgGu4XzlZ6pz7Z1qft 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16651552" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2009 17:10:51 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R0ApBD005294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2009 17:10:51 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R0AkPa000975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Mar 2009 17:10:47 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 17:10:47 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 26 Mar 2009 17:10:46 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp Date: Thu, 26 Mar 2009 17:10:43 -0700 Thread-Topic: Separation of identity assignment and service provider roles (RE: [P2PSIP] Configuration Updates in RELOAD) Thread-Index: AcmuDAROy0X5p/kHR6GEDwuCUgVbNQAYsoCA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: [P2PSIP] Separation of identity assignment and service provider roles (RE: Configuration Updates in RELOAD) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 00:09:59 -0000 DQo+IFNvIGxldCdzIGJyZWFrIHRoaXMgdXAgaW50byB0d28gcXVlc3Rpb25zOg0KPiANCj4gRmly c3QsIGlzIHRoZSBlbnRpdHkgdGhhdCBmb3JtcyB0aGUgb3ZlcmxheSB0aGUgb25lIHRoYXQgZGVj aWRlcyB3aGF0DQo+IGdvZXMgaW4gaXQ/DQo+IA0KPiBJIHdvdWxkIHNheSB0aGUgYW5zd2VyIHRv IHRoaXMgaXMgY2xlYXJseSB5ZXMuICBJIGhvcGUgd2UgY2FuIGFncmVlIG9uDQo+IHRoYXQsIHN1 YmplY3QgdG8gdGhlIHNlY29uZCBxdWVzdGlvbi4NCj4gDQo+IFNlY29uZCBxdWVzdGlvbiBpcyB3 aGV0aGVyIHRoYXQgZW50aXR5IGNhbiBkZWNpZGUgdGhhdCB3aGF0IHRoZXkNCj4gcmVhbGx5IHdh bnQgdG8gZG8gaXMgc3VwcG9ydCBhbiBhbnl0aGluZy1nb2VzIG92ZXJsYXk/DQo+IA0KDQpJJ20g YWZyYWlkIHRoZXJlIGlzIGEgZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBoZXJlIGJldHdlZW4gd2hh dCB3ZSBhcmUgc2F5aW5nLiAgVW5mb3J0dW5hdGVseSwgbXkgYW5zd2VyIHRvIHlvdXIgZmlyc3Qg KGFuZCBzZWNvbmQpIHF1ZXN0aW9uKHMpIGlzIG5vLiAgDQoNCkdvaW5nIGJhY2sgdG8gbXkgSW50 ZXJuZXQgYW5hbG9neSwgdGhlIGVudGl0eSBwcm92aWRpbmcgaWRlbnRpdGllcyBhbmQgY3JlZGVu dGlhbHMgdG8gYWNjZXNzIHRoZSBvdmVybGF5IG1heSBiZSBlbnRpcmVseSBkaWZmZXJlbnQgZnJv bSB0aGUgb25lIG9yIG1vcmUgZW50aXRpZXMgdGhhdCBtYXkgYmUgcHJvdmlkaW5nIHNlcnZpY2Vz IG9uIHRoZSBvdmVybGF5LiAgQ2x1YmJpbmcgdGhlIHR3byBpcyBhbmFsb2dvdXMgdG8gc2F5aW5n IHRoYXQgdGhlIGVudGl0eSB0aGF0IHByb3ZpZGVzIG1lIHdpdGggYW4gSVAgYWRkcmVzcyB0b2Rh eSBnZXRzIHRvIHRlbGwgbWUgd2hhdCBhcHBsaWNhdGlvbnMgb3Igd2ViIHNpdGVzIHRvIGFjY2Vz cyBvbiBteSBsYXB0b3AuICBDZXJ0YWlubHksIHRoYXQgd291bGQgYmUgdW5kZXNpcmFibGUuICBF dmVuIGluIHRoZSBtb2JpbGUgbWFya2V0LCB0aGluZ3MgYXJlIGdvaW5nIHRoZSBvdGhlciB3YXku ICBXaGF0IGFwcGxpY2F0aW9ucyBydW4gb24gdGhlIGlQaG9uZSBvciB0aGUgR1Bob25lIGFyZSBu b3QgcmVhbGx5IGRldGVybWluZWQgYnkgdGhlIG9wZXJhdG9yIGFueSBtb3JlIChvZiBjb3Vyc2Us IG91dHNpZGUgdGhlIE5vcnRoIEFtZXJpY2FuIG1hcmtldCwgdGhpcyBoYXMgYmVlbiB0cnVlIGZv ciBhIHdoaWxlIG5vdykuICANCg0KQW4gb3ZlcmxheSBjb25maWd1cmF0aW9uIGRvY3VtZW50IGhh bmRsZWQgYnkgdGhlIG92ZXJsYXkgcHJvdmlkZXIgbXVzdCBub3QgaGF2ZSBhbnl0aGluZyB0byBk byB3aXRoIGtpbmRzIG9yIHVzYWdlcyBvbiB0aGUgb3ZlcmxheSB3aGljaCBtYXkgYmUgY29taW5n IGZyb20gdmFyaW91cyBzZXJ2aWNlcyBvZmZlcmVkIG9uIHRoZSBvdmVybGF5IGZyb20gZGlmZmVy ZW50IHByb3ZpZGVycy4gT3RoZXJ3aXNlLCB3ZSBhcmUgY3JlYXRpbmcgYSBtb2RlbCB3aGljaCBp cyBnb2luZyB0byBsaW1pdCBkZXBsb3ltZW50IG9wdGlvbnMgYW5kIEkgZG9uJ3QgdGhpbmsgb3Vy IGludGVudCBoZXJlIGlzIHRvIGNyZWF0ZSBhIHdhbGxlZCBnYXJkZW4gZm9yIG92ZXJsYXlzLiAN Cg0KQmVzdCwNClZpZHlhIA0K From vidyan@qualcomm.com Thu Mar 26 17:56:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCBC3A6ADE for ; Thu, 26 Mar 2009 17:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.214 X-Spam-Level: X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtcNQydEdydB for ; Thu, 26 Mar 2009 17:56:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 93DD83A6893 for ; Thu, 26 Mar 2009 17:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238115469; x=1269651469; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"p2psip@ietf.org"=20|Date:=20Thu,=202 6=20Mar=202009=2017:57:48=20-0700|Subject:=20Access=20con trol=20lists=20for=20RELOAD=20storage|Thread-Topic:=20Acc ess=20control=20lists=20for=20RELOAD=20storage |Thread-Index:=20AcmudwwAz38AjKsmSvKjDkefREmATw=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_BE82361A0E26874DBC2ED1BA244866B9380736D6NALASEX MB08naqu_"|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfe e=3Bi=3D"5300,2777,5565"=3B=20a=3D"16637883"; bh=THfnQnn/Gmpcc/4AMtk5IZNlUP73Hu2uX83ZM9LGWIQ=; b=T6OrYUaq5AF7k6i1/XdBVCxZUvU3KT8IOteKzxm0w2zFVC6f1DXF9H+E HCygCct5RFRRiisSA5jJx3/xdWNyI9jVsqynbkb0TIsHVsVUEvWQqD7g6 F3+9GsovU7ULW29G4Ui2aBlxjjHG/FO4dCLCsatNv4hBgkTU3+GzImLQg c=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16637883" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2009 17:57:49 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R0vnUJ010126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Mar 2009 17:57:49 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R0vmo1012048 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 26 Mar 2009 17:57:48 -0700 (PDT) Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 17:57:48 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Thu, 26 Mar 2009 17:57:47 -0700 From: "Narayanan, Vidya" To: "p2psip@ietf.org" Date: Thu, 26 Mar 2009 17:57:48 -0700 Thread-Topic: Access control lists for RELOAD storage Thread-Index: AcmudwwAz38AjKsmSvKjDkefREmATw== 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_BE82361A0E26874DBC2ED1BA244866B9380736D6NALASEXMB08naqu_" MIME-Version: 1.0 Subject: [P2PSIP] Access control lists for RELOAD storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 00:56:58 -0000 --_000_BE82361A0E26874DBC2ED1BA244866B9380736D6NALASEXMB08naqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the moment, RELOAD defines some access control rules that allows authori= zation of a node/user to store at a particular location. However, only tha= t node/user may modify or overwrite the data. It does not allow a mechanis= m to authorize other nodes or users to modify the data. I think it is very= useful to also have provisions for authorizing other node ids or user name= s that can modify the data. As a simple use case for this, consider multip= le members of a family being able to modify the mapping for the SIP AOR of = their home phone. There are plenty of other cases as well where data crea= ted by one node may be modified by other authorized nodes. For this purpose, I think defining an ACL that is allowed to be stored with= the data might be appropriate. The creator may specify a list of node ids= or user names that are authorized to modify the data. We can discuss further on the actual solution options, but, I'd first like = to get feedback on the topic itself to see if people agree this is worth ad= dressing. Thanks, Vidya --_000_BE82361A0E26874DBC2ED1BA244866B9380736D6NALASEXMB08naqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the moment, RELOAD defines some access control rule= s that allows authorization of a node/user to store at a particular location. = ; However, only that node/user may modify or overwrite the data.  It doe= s not allow a mechanism to authorize other nodes or users to modify the data.&nbs= p; I think it is very useful to also have provisions for authorizing other node = ids or user names that can modify the data.  As a simple use case for this= , consider multiple members of a family being able to modify the mapping for = the SIP AOR of their home phone.   There are plenty of other cases as= well where data created by one node may be modified by other authorized nodes.  <= o:p>

 

For this purpose, I think defining an ACL that is allo= wed to be stored with the data might be appropriate.  The creator may specify= a list of node ids or user names that are authorized to modify the data. 

 

We can discuss further on the actual solution options,= but, I’d first like to get feedback on the topic itself to see if people a= gree this is worth addressing.

 

Thanks,
Vidya

--_000_BE82361A0E26874DBC2ED1BA244866B9380736D6NALASEXMB08naqu_-- From hgs@cs.columbia.edu Thu Mar 26 18:30:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EB53A6A7C for ; Thu, 26 Mar 2009 18:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.648 X-Spam-Level: X-Spam-Status: No, score=-6.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-CvCYQvjjX3 for ; Thu, 26 Mar 2009 18:30:43 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 2F4B13A6A7F for ; Thu, 26 Mar 2009 18:30:43 -0700 (PDT) Received: from dhcp-57e0.meeting.ietf.org (dhcp-57e0.meeting.ietf.org [130.129.87.224] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2R1VYmK004375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Mar 2009 21:31:35 -0400 (EDT) Message-Id: <8ABA6F15-BCCD-41E7-948E-B4A262CCB09E@cs.columbia.edu> From: Henning Schulzrinne To: Salman Abdul Baset In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 21:31:33 -0400 References: <20090318211247.74FE250822@romeo.rtfm.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 01:30:44 -0000 For what (little) it's worth, there are existing implementation of TCP- over-UDP. I found http://thebends.org/~allen/utunnel/ http://www.jankratochvil.net/project/tcpoverudp/ http://www.vergenet.net/linux/iproxy/iproxy_paper/stuff/iproxy_paper.pdf http://code.google.com/p/tcpoverudp/ So we have several implementations *before* an Internet draft :-) Henning On Mar 26, 2009, at 4:10 PM, Salman Abdul Baset wrote: > > I am not religiously against running UDP between peers :). However, > based on reasons stated earlier, I think that RELOAD base draft of > the P2PSIP WG is the *not* right place to insert a reliable > congestion control protocol. It is easy to get these protocols wrong > than right. We should not abandon well designed TCP stacks so easily. > > As a practical insight, Skype application will not connect to the > Skype network if it cannot establish a TCP connection with a Skype > super node. > > For those who want to run UDP, I totally agree with your idea of use > RFC-XXXX for a TCP-over-UDP protocol. > > I want to keep our focus on the issues of P2PSIP protocol such as > configuration, security, and overlay maintenance. > From bbl@lowekamp.net Thu Mar 26 19:41:43 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70B43A6807 for ; Thu, 26 Mar 2009 19:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vXOwM5gtMbT for ; Thu, 26 Mar 2009 19:41:42 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 9F8813A67D9 for ; Thu, 26 Mar 2009 19:41:42 -0700 (PDT) Received: by qyk36 with SMTP id 36so1643007qyk.29 for ; Thu, 26 Mar 2009 19:42:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.99.211 with SMTP id v19mr683418qcn.97.1238121756205; Thu, 26 Mar 2009 19:42:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2009 22:42:36 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Separation of identity assignment and service provider roles (RE: Configuration Updates in RELOAD) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 02:41:43 -0000 Let's make sure we're talking about the same thing. If someone wants to (I don't, but some do) create a competitor to Skype, and they deploy the appropriate servers, I want them to be able to specify exactly what may be stored on their overlay (in this case the resources that their application uses, with exactly their rules). Similarly, if someone wants to deploy another OpenDHT, I think they should be able to. (I don't want to do this either, FTR.) Your answer seems to say that a provider should not be able to use this protocol to deploy an overlay that only stores what they want it to do. Is that really what you're saying? Philosophically, I guess we could have a debate whether a provider *should* do this, but I don't believe we should try to forbid it within the protocol. Bruce On Thu, Mar 26, 2009 at 8:10 PM, Narayanan, Vidya wro= te: > >> So let's break this up into two questions: >> >> First, is the entity that forms the overlay the one that decides what >> goes in it? >> >> I would say the answer to this is clearly yes. =C2=A0I hope we can agree= on >> that, subject to the second question. >> >> Second question is whether that entity can decide that what they >> really want to do is support an anything-goes overlay? >> > > I'm afraid there is a fundamental difference here between what we are say= ing. =C2=A0Unfortunately, my answer to your first (and second) question(s) = is no. > > Going back to my Internet analogy, the entity providing identities and cr= edentials to access the overlay may be entirely different from the one or m= ore entities that may be providing services on the overlay. =C2=A0Clubbing = the two is analogous to saying that the entity that provides me with an IP = address today gets to tell me what applications or web sites to access on m= y laptop. =C2=A0Certainly, that would be undesirable. =C2=A0Even in the mob= ile market, things are going the other way. =C2=A0What applications run on = the iPhone or the GPhone are not really determined by the operator any more= (of course, outside the North American market, this has been true for a wh= ile now). > > An overlay configuration document handled by the overlay provider must no= t have anything to do with kinds or usages on the overlay which may be comi= ng from various services offered on the overlay from different providers. O= therwise, we are creating a model which is going to limit deployment option= s and I don't think our intent here is to create a walled garden for overla= ys. > > Best, > Vidya > From bbl@lowekamp.net Thu Mar 26 19:45:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87C53A67D9 for ; Thu, 26 Mar 2009 19:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr0mmR3vBHEJ for ; Thu, 26 Mar 2009 19:45:08 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id E812B3A693B for ; Thu, 26 Mar 2009 19:45:07 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so856143qwb.31 for ; Thu, 26 Mar 2009 19:46:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.79.19 with SMTP id n19mr692356qck.74.1238121961546; Thu, 26 Mar 2009 19:46:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2009 22:46:01 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Access control lists for RELOAD storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 02:45:08 -0000 I can see that this would be useful. I think the issue would only be whether it is worth the complexity, and whether it would be part of the base or an extension. Bruce 2009/3/26 Narayanan, Vidya : > At the moment, RELOAD defines some access control rules that allows > authorization of a node/user to store at a particular location.=C2=A0 How= ever, > only that node/user may modify or overwrite the data.=C2=A0 It does not a= llow a > mechanism to authorize other nodes or users to modify the data.=C2=A0 I t= hink it > is very useful to also have provisions for authorizing other node ids or > user names that can modify the data.=C2=A0 As a simple use case for this, > consider multiple members of a family being able to modify the mapping fo= r > the SIP AOR of their home phone.=C2=A0 =C2=A0There are plenty of other ca= ses as well > where data created by one node may be modified by other authorized nodes. > > > > For this purpose, I think defining an ACL that is allowed to be stored wi= th > the data might be appropriate.=C2=A0 The creator may specify a list of no= de ids > or user names that are authorized to modify the data. > > > > We can discuss further on the actual solution options, but, I=E2=80=99d f= irst like > to get feedback on the topic itself to see if people agree this is worth > addressing. > > > > Thanks, > Vidya > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From bbl@lowekamp.net Thu Mar 26 19:48:45 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C42F3A682F for ; Thu, 26 Mar 2009 19:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgfeGYmJqbN1 for ; Thu, 26 Mar 2009 19:48:44 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 422EE3A67D9 for ; Thu, 26 Mar 2009 19:48:44 -0700 (PDT) Received: by qyk36 with SMTP id 36so1646180qyk.29 for ; Thu, 26 Mar 2009 19:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.100.5 with SMTP id w5mr673545qcn.100.1238122175877; Thu, 26 Mar 2009 19:49:35 -0700 (PDT) In-Reply-To: <8ABA6F15-BCCD-41E7-948E-B4A262CCB09E@cs.columbia.edu> References: <8ABA6F15-BCCD-41E7-948E-B4A262CCB09E@cs.columbia.edu> Date: Thu, 26 Mar 2009 22:49:35 -0400 Message-ID: From: Bruce Lowekamp To: Henning Schulzrinne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Salman Abdul Baset , "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 02:48:45 -0000 Yeah, my recollection from the last time this was discussed in TSV gives me little hope that one would be standardized, but I would like to discover I'm wrong here. Bruce On Thu, Mar 26, 2009 at 9:31 PM, Henning Schulzrinne wrote: > For what (little) it's worth, there are existing implementation of > TCP-over-UDP. I found > > http://thebends.org/~allen/utunnel/ > http://www.jankratochvil.net/project/tcpoverudp/ > http://www.vergenet.net/linux/iproxy/iproxy_paper/stuff/iproxy_paper.pdf > http://code.google.com/p/tcpoverudp/ > > So we have several implementations *before* an Internet draft :-) > > Henning > > On Mar 26, 2009, at 4:10 PM, Salman Abdul Baset wrote: >> >> I am not religiously against running UDP between peers :). However, based >> on reasons stated earlier, I think that RELOAD base draft of the P2PSIP WG >> is the *not* right place to insert a reliable congestion control protocol. >> It is easy to get these protocols wrong than right. We should not abandon >> well designed TCP stacks so easily. >> >> As a practical insight, Skype application will not connect to the Skype >> network if it cannot establish a TCP connection with a Skype super node. >> >> For those who want to run UDP, I totally agree with your idea of use >> RFC-XXXX for a TCP-over-UDP protocol. >> >> I want to keep our focus on the issues of P2PSIP protocol such as >> configuration, security, and overlay maintenance. >> > From bbl@lowekamp.net Thu Mar 26 20:24:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A643A69D7 for ; Thu, 26 Mar 2009 20:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHssaE6HBB7s for ; Thu, 26 Mar 2009 20:24:55 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 59F233A67D9 for ; Thu, 26 Mar 2009 20:24:54 -0700 (PDT) Received: by gxk4 with SMTP id 4so1870941gxk.13 for ; Thu, 26 Mar 2009 20:25:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.58.17 with SMTP id g17mr3264280yba.54.1238124348731; Thu, 26 Mar 2009 20:25:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2009 23:25:48 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 03:24:56 -0000 On Thu, Mar 26, 2009 at 4:10 PM, Salman Abdul Baset wrote: > >> - There are still people who want to run UDP between peers. =C2=A0Yes th= ere >> are other options for some of those scenarios, but not all. Your >> solutions simply don't address all of the problem space. =C2=A0Feel free= to >> submit a draft proposing to limit the problem space the protocol is >> trying to solve. > > Perhaps, people who *only* want to run UDP between peers should submit a > seperate draft. It is not something that should be in the base draft when > there are alternate solutions. > > It is incorrect to say that my solutions don't address these scenarios. > Establishing TCP connections through mutually reachable peers always work= . > Downgrading a node to a client, and establishing a TCP connection with a > reachable peer always work. Again, please see (1) and (2) below. Also, > people are working on techniques for establishing direct TCP connection. > Your alternate solution is an assumption that the overlay will contain enough TCP open-access nodes that are able to identify themselves as open-access nodes and willing to bear the burden of their role on behalf of all the other peers. What I've seen is that UDP actually works, and TCP doesn't. > >> - You have not demonstrated that any of the proposed UDP protocols >> have performance inadequate to the requirements of the scenarios in >> which they are likely to be needed. =C2=A0Sure they're not up to TCP's >> performance. =C2=A0That's not the goal. > > I have said it repeatedly that the proposed UDP protocols only recover > losses using *timeouts*. It is well known that recovering losses using > timeouts is a big performance hit. Any TSV person should say this. > This is a bit of an oversimplification. - it's not a stream based protocol. So a timeout of one fragment doesn't have any affect on the others, like it does in TCP - Having timeout based retransmission was purely a way of simplifying the protocols to be easier to implement (correctly) - Once again, the goal isn't to achieve equal performance to TCP. The goal is to provide sufficient performance and not destroy the Internet - If you read the TFRC spec, it includes dupack calculation, which can be used to determine loss. The receiver algorithm was simplified a little bit to make this impossible, and I see the value of that simplification as more important than the lost performance, given that this isn't a stream-based protocol in the first place. The difference between an ideal overlay link protocol and a stream-based protocol (such as how the TFRC version only retransmits an individual fragment twice) is actually an important point to keep in mind, and probably means that TCP over UDP is not actually the ideal protocol. (But I don't necessarily believe it would be worthwhile to work out an appropriate spec to that level of detail. I think it's more important to have easily implementable protocols that work, and would prefer a TCP over UDP that can be included by reference.) > >> - I don't understand why you keep bringing up cascaded NATs. =C2=A0Yes, >> it's possible to come up with a NAT/Firewall configuration that will >> block any given solution. =C2=A0The point is not that there may exist >> systems where a particular solution won't work, it's trying to develop >> a solution that solves the vast majority of common cases. > > I am curious if you have data indicating that for common cases, TCP > connections don't work and UDP do? You don't agree with the assertions in > the 'Characterizing IMC'05' paper and that's fine. But can you point to t= he > latest data? > Once again, I don't believe it's worth rehashing years of conversation in MMUSIC here. But if nothing else, observe that ICE-UDP is a lot further along (finished) than ICE-TCP (trying to get restarted). Bruce > -- > > I am not religiously against running UDP between peers :). However, based= on > reasons stated earlier, I think that RELOAD base draft of the P2PSIP WG i= s > the *not* right place to insert a reliable congestion control protocol. I= t > is easy to get these protocols wrong than right. We should not abandon we= ll > designed TCP stacks so easily. > > As a practical insight, Skype application will not connect to the Skype > network if it cannot establish a TCP connection with a Skype super node. > > For those who want to run UDP, I totally agree with your idea of use > RFC-XXXX for a TCP-over-UDP protocol. > > I want to keep our focus on the issues of P2PSIP protocol such as > configuration, security, and overlay maintenance. > > Regards, > Salman > > >>> >>> >>>>>>> (1) Clients >>>>>>> Nodes behind TCP *un*friendly NATs can always act as clients and >>>>>>> establish a >>>>>>> TCP connection(s) with reachable node(s). The reachable nodes can b= e >>>>>>> behind >>>>>>> friendly NATs or they can have a public IP address. >>>>>>> >>>>>>> (2) Full peer but use relay peer(s) >>>>>>> A node participates as a peer. It establishes TCP connection with >>>>>>> reachable >>>>>>> peers, which inturn establish a TCP connection with the nodes' >>>>>>> connection >>>>>>> table entries. >>>>>>> >>>>>>> (3) Full peer with techniques for direct TCP connection establishme= nt >>>>>>> A node participates as a peer and uses TCP traversal techniques for >>>>>>> establishing direct connection (including Dean's upcoming ones:) >>>>>>> >>>>>>> (4) Full peer with TCP-over-UDP >>>>>>> Since TCP traversal may fail, design/reuse a reliable congestion >>>>>>> control >>>>>>> protocol over UDP. >>>>>>> >>>>>>> >>>>>>> Note that: >>>>>>> (1) and (2) always work. >>>>>>> >>>>>>> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >>>>>>> UDP-blocking firewalls. >>>>>>> >>>>>>> (4) is feasible over (3) since UDP has a better chance of connectio= n >>>>>>> establishment when NATs are not cascaded. However, UDP blocking >>>>>>> firewalls >>>>>>> need to be factored in this feasible discussion. Again, any recent >>>>>>> data >>>>>>> is >>>>>>> helpful. >>>>>>> >>>>>>> >>>>>>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>>>>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the >>>>>>> weakest >>>>>>> link in the routing chain. Approaches which recover every loss usin= g >>>>>>> timeout >>>>>>> may not be the most feasible ones. >>>>>>> >>>>>>> >>>>>>> -salman >>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> > From sa2086@columbia.edu Thu Mar 26 20:53:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351573A68AC for ; Thu, 26 Mar 2009 20:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXV7S24j4ZRx for ; Thu, 26 Mar 2009 20:53:13 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id E86B73A67D9 for ; Thu, 26 Mar 2009 20:52:56 -0700 (PDT) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2R3rndv011236; Thu, 26 Mar 2009 23:53:49 -0400 (EDT) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2R3rnj7019710; Thu, 26 Mar 2009 23:53:49 -0400 (EDT) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2R3rnpu019706; Thu, 26 Mar 2009 23:53:49 -0400 (EDT) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Thu, 26 Mar 2009 23:53:48 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 03:53:14 -0000 > Your alternate solution is an assumption that the overlay will contain > enough TCP open-access nodes that are able to identify themselves as > open-access nodes and willing to bear the burden of their role on > behalf of all the other peers. What I've seen is that UDP actually > works, and TCP doesn't. Skype works. It has enough nodes that can provide relay services. There are papers which suggest that a machine can handle thousands of concurrent TCP connections. >> I have said it repeatedly that the proposed UDP protocols only recover >> losses using *timeouts*. It is well known that recovering losses using >> timeouts is a big performance hit. Any TSV person should say this. >> > > This is a bit of an oversimplification. > > - it's not a stream based protocol. So a timeout of one fragment > doesn't have any affect on the others, like it does in TCP You are missing inorder delivery here. Unless the lost fragment is retransmitted and received, all the other segments in the receive buffer are useless. I think the following questions should be discussed in the WG meeting. 1) Is designing a reliable congestion protocol within scope of P2PSIP WG? 2) If yes, a) shall it be specified in the base document? b) what should be its performance if a large number of peers were to run it? c) what is the impact on routing performance? regards, salman >> -- >> >> I am not religiously against running UDP between peers :). However, based on >> reasons stated earlier, I think that RELOAD base draft of the P2PSIP WG is >> the *not* right place to insert a reliable congestion control protocol. It >> is easy to get these protocols wrong than right. We should not abandon well >> designed TCP stacks so easily. >> >> As a practical insight, Skype application will not connect to the Skype >> network if it cannot establish a TCP connection with a Skype super node. >> >> For those who want to run UDP, I totally agree with your idea of use >> RFC-XXXX for a TCP-over-UDP protocol. >> >> I want to keep our focus on the issues of P2PSIP protocol such as >> configuration, security, and overlay maintenance. >> >> Regards, >> Salman >> >> >>>> >>>> >>>>>>>> (1) Clients >>>>>>>> Nodes behind TCP *un*friendly NATs can always act as clients and >>>>>>>> establish a >>>>>>>> TCP connection(s) with reachable node(s). The reachable nodes can be >>>>>>>> behind >>>>>>>> friendly NATs or they can have a public IP address. >>>>>>>> >>>>>>>> (2) Full peer but use relay peer(s) >>>>>>>> A node participates as a peer. It establishes TCP connection with >>>>>>>> reachable >>>>>>>> peers, which inturn establish a TCP connection with the nodes' >>>>>>>> connection >>>>>>>> table entries. >>>>>>>> >>>>>>>> (3) Full peer with techniques for direct TCP connection establishment >>>>>>>> A node participates as a peer and uses TCP traversal techniques for >>>>>>>> establishing direct connection (including Dean's upcoming ones:) >>>>>>>> >>>>>>>> (4) Full peer with TCP-over-UDP >>>>>>>> Since TCP traversal may fail, design/reuse a reliable congestion >>>>>>>> control >>>>>>>> protocol over UDP. >>>>>>>> >>>>>>>> >>>>>>>> Note that: >>>>>>>> (1) and (2) always work. >>>>>>>> >>>>>>>> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >>>>>>>> UDP-blocking firewalls. >>>>>>>> >>>>>>>> (4) is feasible over (3) since UDP has a better chance of connection >>>>>>>> establishment when NATs are not cascaded. However, UDP blocking >>>>>>>> firewalls >>>>>>>> need to be factored in this feasible discussion. Again, any recent >>>>>>>> data >>>>>>>> is >>>>>>>> helpful. >>>>>>>> >>>>>>>> >>>>>>>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>>>>>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the >>>>>>>> weakest >>>>>>>> link in the routing chain. Approaches which recover every loss using >>>>>>>> timeout >>>>>>>> may not be the most feasible ones. >>>>>>>> >>>>>>>> >>>>>>>> -salman >>>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> >> > > From bbl@lowekamp.net Fri Mar 27 03:18:10 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DDF3A67FA for ; Fri, 27 Mar 2009 03:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21cS5sLskh23 for ; Fri, 27 Mar 2009 03:18:09 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 172293A69C5 for ; Fri, 27 Mar 2009 03:18:08 -0700 (PDT) Received: by qyk36 with SMTP id 36so1795262qyk.29 for ; Fri, 27 Mar 2009 03:19:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.79.19 with SMTP id n19mr728536qck.74.1238149125100; Fri, 27 Mar 2009 03:18:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Mar 2009 06:18:44 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 10:18:10 -0000 On Thu, Mar 26, 2009 at 11:53 PM, Salman Abdul Baset wrote: > >> Your alternate solution is an assumption that the overlay will contain >> enough TCP open-access nodes that are able to identify themselves as >> open-access nodes and willing to bear the burden of their role on >> behalf of all the other peers. =C2=A0 What I've seen is that UDP actuall= y >> works, and TCP doesn't. > > Skype works. It has enough nodes that can provide relay services. > Once again, I'm not saying your scenario doesn't exist. I'm just saying that there are other scenarios. > There are papers which suggest that a machine can handle thousands of > concurrent TCP connections. > The ability of a machine to handle thousands of mostly idle connections is not really relevant to whether people would participate in an overlay where they wind up consuming half of their broadband link while idle (for example). >>> I have said it repeatedly that the proposed UDP protocols only recover >>> losses using *timeouts*. It is well known that recovering losses using >>> timeouts is a big performance hit. Any TSV person should say this. >>> >> >> This is a bit of an oversimplification. >> >> - it's not a stream based protocol. =C2=A0So a timeout of one fragment >> doesn't have any affect on the others, like it does in TCP > > You are missing inorder delivery here. Unless the lost fragment is > retransmitted and received, all the other segments in the receive buffer = are > useless. > No, I'm not missing it, I'm deliberately excluding it. That's not a service the Internet guarantees, and the complexities required to guarantee it on an overlay network are too high. > > I think the following questions should be discussed in the WG meeting. > > 1) Is designing a reliable congestion protocol within scope of P2PSIP WG? > 2) If yes, > =C2=A0a) shall it be specified in the base document? > =C2=A0b) what should be its performance if a large number of peers were t= o run > it? > =C2=A0c) what is the impact on routing performance? > It's a semi-reliable congestion control protocol, but yes, that's a perfectly good topic for the wg to consider. However, so far I'm not aware of anyone but you who believes we should exclude UDP from the protocol. Bruce > > regards, > salman > > >>> -- >>> >>> I am not religiously against running UDP between peers :). However, bas= ed >>> on >>> reasons stated earlier, I think that RELOAD base draft of the P2PSIP WG >>> is >>> the *not* right place to insert a reliable congestion control protocol. >>> It >>> is easy to get these protocols wrong than right. We should not abandon >>> well >>> designed TCP stacks so easily. >>> >>> As a practical insight, Skype application will not connect to the Skype >>> network if it cannot establish a TCP connection with a Skype super node= . >>> >>> For those who want to run UDP, I totally agree with your idea of use >>> RFC-XXXX for a TCP-over-UDP protocol. >>> >>> I want to keep our focus on the issues of P2PSIP protocol such as >>> configuration, security, and overlay maintenance. >>> >>> Regards, >>> Salman >>> >>> >>>>> >>>>> >>>>>>>>> (1) Clients >>>>>>>>> Nodes behind TCP *un*friendly NATs can always act as clients and >>>>>>>>> establish a >>>>>>>>> TCP connection(s) with reachable node(s). The reachable nodes can >>>>>>>>> be >>>>>>>>> behind >>>>>>>>> friendly NATs or they can have a public IP address. >>>>>>>>> >>>>>>>>> (2) Full peer but use relay peer(s) >>>>>>>>> A node participates as a peer. It establishes TCP connection with >>>>>>>>> reachable >>>>>>>>> peers, which inturn establish a TCP connection with the nodes' >>>>>>>>> connection >>>>>>>>> table entries. >>>>>>>>> >>>>>>>>> (3) Full peer with techniques for direct TCP connection >>>>>>>>> establishment >>>>>>>>> A node participates as a peer and uses TCP traversal techniques f= or >>>>>>>>> establishing direct connection (including Dean's upcoming ones:) >>>>>>>>> >>>>>>>>> (4) Full peer with TCP-over-UDP >>>>>>>>> Since TCP traversal may fail, design/reuse a reliable congestion >>>>>>>>> control >>>>>>>>> protocol over UDP. >>>>>>>>> >>>>>>>>> >>>>>>>>> Note that: >>>>>>>>> (1) and (2) always work. >>>>>>>>> >>>>>>>>> (3) and (4) do not work well behind cascaded NATs. (4) fails behi= nd >>>>>>>>> UDP-blocking firewalls. >>>>>>>>> >>>>>>>>> (4) is feasible over (3) since UDP has a better chance of >>>>>>>>> connection >>>>>>>>> establishment when NATs are not cascaded. However, UDP blocking >>>>>>>>> firewalls >>>>>>>>> need to be factored in this feasible discussion. Again, any recen= t >>>>>>>>> data >>>>>>>>> is >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> >>>>>>>>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>>>>>>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the >>>>>>>>> weakest >>>>>>>>> link in the routing chain. Approaches which recover every loss >>>>>>>>> using >>>>>>>>> timeout >>>>>>>>> may not be the most feasible ones. >>>>>>>>> >>>>>>>>> >>>>>>>>> -salman >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> P2PSIP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>> >>>> >>> >> >> > From sa2086@columbia.edu Fri Mar 27 05:40:11 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29F13A689A for ; Fri, 27 Mar 2009 05:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epBjnBBzoF79 for ; Fri, 27 Mar 2009 05:40:10 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id C38773A68F8 for ; Fri, 27 Mar 2009 05:40:10 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2RCf4qk009630; Fri, 27 Mar 2009 08:41:04 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2RCf4hl003359; Fri, 27 Mar 2009 08:41:04 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n2RCf49e003356; Fri, 27 Mar 2009 08:41:04 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Fri, 27 Mar 2009 08:41:04 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: Bruce Lowekamp In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1841205112-1238157664=:28414" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 12:40:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1841205112-1238157664=:28414 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT >>> Your alternate solution is an assumption that the overlay will contain >>> enough TCP open-access nodes that are able to identify themselves as >>> open-access nodes and willing to bear the burden of their role on >>> behalf of all the other peers.   What I've seen is that UDP actually >>> works, and TCP doesn't. >> >> Skype works. It has enough nodes that can provide relay services. >> > > Once again, I'm not saying your scenario doesn't exist. I'm just > saying that there are other scenarios. Sure there are other scenarios, but the justification for including your TCP-over-UDP solutions in the base protocol has to be based on solid data, whether they are the *only* viable option, whether they have any performance issues, and whether P2PSIP WG is the right place for them. You have agreed in the earlier posts that there are scenarios where direct connections are not possible. Maybe, RELOAD should not be run in those scenarios, right? >>>> I have said it repeatedly that the proposed UDP protocols only recover >>>> losses using *timeouts*. It is well known that recovering losses using >>>> timeouts is a big performance hit. Any TSV person should say this. >>>> >>> >>> This is a bit of an oversimplification. >>> >>> - it's not a stream based protocol.  So a timeout of one fragment >>> doesn't have any affect on the others, like it does in TCP >> >> You are missing inorder delivery here. Unless the lost fragment is >> retransmitted and received, all the other segments in the receive buffer are >> useless. >> > > No, I'm not missing it, I'm deliberately excluding it. That's not a > service the Internet guarantees, and the complexities required to > guarantee it on an overlay network are too high. Unless a packet is deemed loss using a *timeout*, and retransmitted, and received at the receive buffer, all other packets are useless. Isn't this a big performance hit? >> I think the following questions should be discussed in the WG meeting. >> >> 1) Is designing a reliable congestion protocol within scope of P2PSIP WG? >> 2) If yes, >> a) shall it be specified in the base document? >> b) what should be its performance if a large number of peers were to run >> it? >> c) what is the impact on routing performance? >> > > It's a semi-reliable congestion control protocol, but yes, that's a > perfectly good topic for the wg to consider. However, so far I'm not > aware of anyone but you who believes we should exclude UDP from the > protocol. It is a jump in the thought to say that I am excluding UDP. I am not. UDP is perfectly suitable for messages that do not exceed MTU such as keep-alives. I will let WG discuss these questions :) -salman >>>>>>>>>> (1) Clients >>>>>>>>>> Nodes behind TCP *un*friendly NATs can always act as clients and >>>>>>>>>> establish a >>>>>>>>>> TCP connection(s) with reachable node(s). The reachable nodes can >>>>>>>>>> be >>>>>>>>>> behind >>>>>>>>>> friendly NATs or they can have a public IP address. >>>>>>>>>> >>>>>>>>>> (2) Full peer but use relay peer(s) >>>>>>>>>> A node participates as a peer. It establishes TCP connection with >>>>>>>>>> reachable >>>>>>>>>> peers, which inturn establish a TCP connection with the nodes' >>>>>>>>>> connection >>>>>>>>>> table entries. >>>>>>>>>> >>>>>>>>>> (3) Full peer with techniques for direct TCP connection >>>>>>>>>> establishment >>>>>>>>>> A node participates as a peer and uses TCP traversal techniques for >>>>>>>>>> establishing direct connection (including Dean's upcoming ones:) >>>>>>>>>> >>>>>>>>>> (4) Full peer with TCP-over-UDP >>>>>>>>>> Since TCP traversal may fail, design/reuse a reliable congestion >>>>>>>>>> control >>>>>>>>>> protocol over UDP. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note that: >>>>>>>>>> (1) and (2) always work. >>>>>>>>>> >>>>>>>>>> (3) and (4) do not work well behind cascaded NATs. (4) fails behind >>>>>>>>>> UDP-blocking firewalls. >>>>>>>>>> >>>>>>>>>> (4) is feasible over (3) since UDP has a better chance of >>>>>>>>>> connection >>>>>>>>>> establishment when NATs are not cascaded. However, UDP blocking >>>>>>>>>> firewalls >>>>>>>>>> need to be factored in this feasible discussion. Again, any recent >>>>>>>>>> data >>>>>>>>>> is >>>>>>>>>> helpful. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For (4), the TCP-over-UDP protocol needs to be well-designed and >>>>>>>>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be the >>>>>>>>>> weakest >>>>>>>>>> link in the routing chain. Approaches which recover every loss >>>>>>>>>> using >>>>>>>>>> timeout >>>>>>>>>> may not be the most feasible ones. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -salman >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> P2PSIP mailing list >>>>>>> P2PSIP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> >>>>> >>>>> >>>> >>> >>> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip ---559023410-1841205112-1238157664=:28414-- From bbl@lowekamp.net Fri Mar 27 06:34:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F5F28C140 for ; Fri, 27 Mar 2009 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xbzw4DbwPqIB for ; Fri, 27 Mar 2009 06:34:35 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id B030D3A6C3A for ; Fri, 27 Mar 2009 06:34:34 -0700 (PDT) Received: by qyk36 with SMTP id 36so1890799qyk.29 for ; Fri, 27 Mar 2009 06:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.80.18 with SMTP id r18mr749683qck.73.1238160928603; Fri, 27 Mar 2009 06:35:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Mar 2009 09:35:28 -0400 Message-ID: From: Bruce Lowekamp To: Salman Abdul Baset Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control and reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 13:34:36 -0000 On Fri, Mar 27, 2009 at 8:41 AM, Salman Abdul Baset wrote: > >>>> Your alternate solution is an assumption that the overlay will contain >>>> enough TCP open-access nodes that are able to identify themselves as >>>> open-access nodes and willing to bear the burden of their role on >>>> behalf of all the other peers. =C2=A0 What I've seen is that UDP actua= lly >>>> works, and TCP doesn't. >>> >>> Skype works. It has enough nodes that can provide relay services. >>> >> >> Once again, I'm not saying your scenario doesn't exist. I'm just >> saying that there are other scenarios. > > Sure there are other scenarios, but the justification for including your > TCP-over-UDP solutions in the base protocol has to be based on solid data= , > whether they are the *only* viable option, whether they have any performa= nce > issues, and whether P2PSIP WG is the right place for them. > > You have agreed in the earlier posts that there are scenarios where direc= t > connections are not possible. Maybe, RELOAD should not be run in those > scenarios, right? > The charter says: "The working group will assume that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible." I interpret that to mean that we should support UDP, and as long as we do so within the framework of RFC5405, which specifies guidelines for congestion control, reliability, etc., we are doing what our charter and usage scenarios require in compatibility with TSV's current view on the requirements. > >>>>> I have said it repeatedly that the proposed UDP protocols only recove= r >>>>> losses using *timeouts*. It is well known that recovering losses usin= g >>>>> timeouts is a big performance hit. Any TSV person should say this. >>>>> >>>> >>>> This is a bit of an oversimplification. >>>> >>>> - it's not a stream based protocol. =C2=A0So a timeout of one fragment >>>> doesn't have any affect on the others, like it does in TCP >>> >>> You are missing inorder delivery here. Unless the lost fragment is >>> retransmitted and received, all the other segments in the receive buffe= r >>> are >>> useless. >>> >> >> No, I'm not missing it, I'm deliberately excluding it. =C2=A0That's not = a >> service the Internet guarantees, and the complexities required to >> guarantee it on an overlay network are too high. > > > Unless a packet is deemed loss using a *timeout*, and retransmitted, and > received at the receive buffer, all other packets are useless. Isn't this= a > big performance hit? > Depends on how many fragments the typical message has, and how long the reassembly buffer is preserved on the receiver to receive the retransmission. Obviously this was a major problem for early poor ATM implementations. Going back a bit, my initial argument was that each hop should do reassembly. Numerous other people on the mailing list argued that this was too expensive, and that we should adopt a simpler approach. I tried to balance performance and simplicity in the more recent email. But there are a lot of different perspectives on what the most important features to be optimized are. I certainly consider whether such overlay link protocols must include behaviors such as dupack loss detection and fragment/message dropping to be open issues. > > >>> I think the following questions should be discussed in the WG meeting. >>> >>> 1) Is designing a reliable congestion protocol within scope of P2PSIP W= G? >>> 2) If yes, >>> =C2=A0a) shall it be specified in the base document? >>> =C2=A0b) what should be its performance if a large number of peers were= to run >>> it? >>> =C2=A0c) what is the impact on routing performance? >>> >> >> It's a semi-reliable congestion control protocol, but yes, that's a >> perfectly good topic for the wg to consider. =C2=A0However, so far I'm n= ot >> aware of anyone but you who believes we should exclude UDP from the >> protocol. > > > It is a jump in the thought to say that I am excluding UDP. I am not. UDP= is > perfectly suitable for messages that do not exceed MTU such as keep-alive= s. > keep-alives have to be run over the same channel as the main messages. (keep-alives in the NAT/firewall maintenance sense, you're right that a peer liveness check could run in a different flow.) Bruce > I will let WG discuss these questions :) > > -salman > > > >>>>>>>>>>> (1) Clients >>>>>>>>>>> Nodes behind TCP *un*friendly NATs can always act as clients an= d >>>>>>>>>>> establish a >>>>>>>>>>> TCP connection(s) with reachable node(s). The reachable nodes c= an >>>>>>>>>>> be >>>>>>>>>>> behind >>>>>>>>>>> friendly NATs or they can have a public IP address. >>>>>>>>>>> >>>>>>>>>>> (2) Full peer but use relay peer(s) >>>>>>>>>>> A node participates as a peer. It establishes TCP connection wi= th >>>>>>>>>>> reachable >>>>>>>>>>> peers, which inturn establish a TCP connection with the nodes' >>>>>>>>>>> connection >>>>>>>>>>> table entries. >>>>>>>>>>> >>>>>>>>>>> (3) Full peer with techniques for direct TCP connection >>>>>>>>>>> establishment >>>>>>>>>>> A node participates as a peer and uses TCP traversal techniques >>>>>>>>>>> for >>>>>>>>>>> establishing direct connection (including Dean's upcoming ones:= ) >>>>>>>>>>> >>>>>>>>>>> (4) Full peer with TCP-over-UDP >>>>>>>>>>> Since TCP traversal may fail, design/reuse a reliable congestio= n >>>>>>>>>>> control >>>>>>>>>>> protocol over UDP. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that: >>>>>>>>>>> (1) and (2) always work. >>>>>>>>>>> >>>>>>>>>>> (3) and (4) do not work well behind cascaded NATs. (4) fails >>>>>>>>>>> behind >>>>>>>>>>> UDP-blocking firewalls. >>>>>>>>>>> >>>>>>>>>>> (4) is feasible over (3) since UDP has a better chance of >>>>>>>>>>> connection >>>>>>>>>>> establishment when NATs are not cascaded. However, UDP blocking >>>>>>>>>>> firewalls >>>>>>>>>>> need to be factored in this feasible discussion. Again, any >>>>>>>>>>> recent >>>>>>>>>>> data >>>>>>>>>>> is >>>>>>>>>>> helpful. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> For (4), the TCP-over-UDP protocol needs to be well-designed an= d >>>>>>>>>>> well-implemented. Otherwise, peers doing TCP-over-UDP may be th= e >>>>>>>>>>> weakest >>>>>>>>>>> link in the routing chain. Approaches which recover every loss >>>>>>>>>>> using >>>>>>>>>>> timeout >>>>>>>>>>> may not be the most feasible ones. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -salman >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> P2PSIP mailing list >>>>>>>> P2PSIP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip From vidyan@qualcomm.com Fri Mar 27 10:03:45 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E5428C167 for ; Fri, 27 Mar 2009 10:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBLuBBoAe9BB for ; Fri, 27 Mar 2009 10:03:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C2B1C28C140 for ; Fri, 27 Mar 2009 10:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238173478; x=1269709478; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Fri,=2027=20Mar=20200 9=2010:04:30=20-0700|Subject:=20RE:=20Separation=20of=20i dentity=20assignment=20and=20service=20provider=20roles =0D=0A=20(RE:=20=09[P2PSIP]=20Configuration=20Updates=20i n=20RELOAD)|Thread-Topic:=20Separation=20of=20identity=20 assignment=20and=20service=20provider=20roles=0D=0A=20(RE :=20=09[P2PSIP]=20Configuration=20Updates=20in=20RELOAD) |Thread-Index:=20AcmuhjdFsTQx4ZQbSMONh6oCexEEtwAd4kDQ |Message-ID:=20|References:=20 =0D=0A=09=20=0D=0A=09=20=0D=0A=09=20 =0D=0A=09=20=0D=0A=09=20=0D=0A=09=20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5565"=3B=20 a=3D"16656122"; bh=5MXVe3vqGWcHPM5VV/OugNtdBJNhNkkXp6d0ToZkfzM=; b=i8Ge7tO8JtzUmnDutDlGZJDdmmTNgDfH3XXRiLnIngbpwivyAXHvQ98M L4+/aBAOKiNOO6J1Gx2ZZc9w62WJ1CBrZFtLfHABHCbww/nfnIRTC0Ndu sUL7VKHzZjxhZrEvJECoThL1GPnHSNXQFfUX17G1fMd3oirzPCMfp+QkA 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16656122" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2009 10:04:38 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2RH4cvH005100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2009 10:04:38 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2RH4Sk2010939 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 10:04:33 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 27 Mar 2009 10:04:30 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 27 Mar 2009 10:04:30 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp Date: Fri, 27 Mar 2009 10:04:30 -0700 Thread-Topic: Separation of identity assignment and service provider roles (RE: [P2PSIP] Configuration Updates in RELOAD) Thread-Index: AcmuhjdFsTQx4ZQbSMONh6oCexEEtwAd4kDQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Separation of identity assignment and service provider roles (RE: Configuration Updates in RELOAD) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 17:03:45 -0000 SSdtIG5vdCB0YWxraW5nIGFib3V0IHJlc3RyaWN0aW5nIHRoZSBjYXNlcyB3aGVyZSBhbiBvdmVy bGF5IG9wZXJhdG9yIGFsc28gd2FudHMgdG8gaGF2ZSBjb250cm9sIG9uIHdoYXQncyBhbGxvd2Vk IG9uIHRoZSBvdmVybGF5LiAgSG93ZXZlciwgSSdtIHRhbGtpbmcgYWJvdXQgbm90IHJlc3RyaWN0 aW5nIHRoYXQgdG8gYmUgdGhlIG9ubHkgZGVwbG95bWVudCBwb3NzaWJpbGl0eS4gDQoNCkJ5IG1p bmdsaW5nIGtpbmRzIGFuZCB1c2FnZXMgaW50byB0aGUgb3ZlcmxheSBjb25maWd1cmF0aW9uIGRv Y3VtZW50LCB3ZSBhcmUgcGxhY2luZyB0aGF0IHJlc3RyaWN0aW9uLiAgSWYgd2Ugc2VwYXJhdGVk IHRob3NlIG91dCwgYSBwYXJ0aWN1bGFyIGRlcGxveW1lbnQgY2FuIGFsd2F5cyBjb2xsb2NhdGUg aXQgaW50byB0aGUgc2FtZSBlbnRpdHkgYW5kIGl0IGlzIG5vdCBhIHByb2JsZW0uIA0KDQpWaWR5 YQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJydWNlIExvd2VrYW1w IFttYWlsdG86YmJsQGxvd2VrYW1wLm5ldF0NCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDI2LCAy MDA5IDc6NDMgUE0NCj4gVG86IE5hcmF5YW5hbiwgVmlkeWENCj4gQ2M6IHAycHNpcEBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogU2VwYXJhdGlvbiBvZiBpZGVudGl0eSBhc3NpZ25tZW50IGFuZCBz ZXJ2aWNlIHByb3ZpZGVyDQo+IHJvbGVzIChSRTogW1AyUFNJUF0gQ29uZmlndXJhdGlvbiBVcGRh dGVzIGluIFJFTE9BRCkNCj4gDQo+IExldCdzIG1ha2Ugc3VyZSB3ZSdyZSB0YWxraW5nIGFib3V0 IHRoZSBzYW1lIHRoaW5nLg0KPiANCj4gSWYgc29tZW9uZSB3YW50cyB0byAoSSBkb24ndCwgYnV0 IHNvbWUgZG8pIGNyZWF0ZSBhIGNvbXBldGl0b3IgdG8NCj4gU2t5cGUsIGFuZCB0aGV5IGRlcGxv eSB0aGUgYXBwcm9wcmlhdGUgc2VydmVycywgSSB3YW50IHRoZW0gdG8gYmUgYWJsZQ0KPiB0byBz cGVjaWZ5IGV4YWN0bHkgd2hhdCBtYXkgYmUgc3RvcmVkIG9uIHRoZWlyIG92ZXJsYXkgKGluIHRo aXMgY2FzZQ0KPiB0aGUgcmVzb3VyY2VzIHRoYXQgdGhlaXIgYXBwbGljYXRpb24gdXNlcywgd2l0 aCBleGFjdGx5IHRoZWlyIHJ1bGVzKS4NCj4gDQo+IFNpbWlsYXJseSwgaWYgc29tZW9uZSB3YW50 cyB0byBkZXBsb3kgYW5vdGhlciBPcGVuREhULCBJIHRoaW5rIHRoZXkNCj4gc2hvdWxkIGJlIGFi bGUgdG8uICAoSSBkb24ndCB3YW50IHRvIGRvIHRoaXMgZWl0aGVyLCBGVFIuKQ0KPiANCj4gWW91 ciBhbnN3ZXIgc2VlbXMgdG8gc2F5IHRoYXQgYSBwcm92aWRlciBzaG91bGQgbm90IGJlIGFibGUg dG8gdXNlDQo+IHRoaXMgcHJvdG9jb2wgdG8gZGVwbG95IGFuIG92ZXJsYXkgdGhhdCBvbmx5IHN0 b3JlcyB3aGF0IHRoZXkgd2FudCBpdA0KPiB0byBkby4gIElzIHRoYXQgcmVhbGx5IHdoYXQgeW91 J3JlIHNheWluZz8gICBQaGlsb3NvcGhpY2FsbHksIEkgZ3Vlc3MNCj4gd2UgY291bGQgaGF2ZSBh IGRlYmF0ZSB3aGV0aGVyIGEgcHJvdmlkZXIgKnNob3VsZCogZG8gdGhpcywgYnV0IEkNCj4gZG9u J3QgYmVsaWV2ZSB3ZSBzaG91bGQgdHJ5IHRvIGZvcmJpZCBpdCB3aXRoaW4gdGhlIHByb3RvY29s Lg0KPiANCj4gQnJ1Y2UNCj4gDQo+IA0KPiBPbiBUaHUsIE1hciAyNiwgMjAwOSBhdCA4OjEwIFBN LCBOYXJheWFuYW4sIFZpZHlhIDx2aWR5YW5AcXVhbGNvbW0uY29tPg0KPiB3cm90ZToNCj4gPg0K PiA+PiBTbyBsZXQncyBicmVhayB0aGlzIHVwIGludG8gdHdvIHF1ZXN0aW9uczoNCj4gPj4NCj4g Pj4gRmlyc3QsIGlzIHRoZSBlbnRpdHkgdGhhdCBmb3JtcyB0aGUgb3ZlcmxheSB0aGUgb25lIHRo YXQgZGVjaWRlcw0KPiB3aGF0DQo+ID4+IGdvZXMgaW4gaXQ/DQo+ID4+DQo+ID4+IEkgd291bGQg c2F5IHRoZSBhbnN3ZXIgdG8gdGhpcyBpcyBjbGVhcmx5IHllcy4gwqBJIGhvcGUgd2UgY2FuIGFn cmVlDQo+IG9uDQo+ID4+IHRoYXQsIHN1YmplY3QgdG8gdGhlIHNlY29uZCBxdWVzdGlvbi4NCj4g Pj4NCj4gPj4gU2Vjb25kIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhhdCBlbnRpdHkgY2FuIGRlY2lk ZSB0aGF0IHdoYXQgdGhleQ0KPiA+PiByZWFsbHkgd2FudCB0byBkbyBpcyBzdXBwb3J0IGFuIGFu eXRoaW5nLWdvZXMgb3ZlcmxheT8NCj4gPj4NCj4gPg0KPiA+IEknbSBhZnJhaWQgdGhlcmUgaXMg YSBmdW5kYW1lbnRhbCBkaWZmZXJlbmNlIGhlcmUgYmV0d2VlbiB3aGF0IHdlIGFyZQ0KPiBzYXlp bmcuIMKgVW5mb3J0dW5hdGVseSwgbXkgYW5zd2VyIHRvIHlvdXIgZmlyc3QgKGFuZCBzZWNvbmQp DQo+IHF1ZXN0aW9uKHMpIGlzIG5vLg0KPiA+DQo+ID4gR29pbmcgYmFjayB0byBteSBJbnRlcm5l dCBhbmFsb2d5LCB0aGUgZW50aXR5IHByb3ZpZGluZyBpZGVudGl0aWVzDQo+IGFuZCBjcmVkZW50 aWFscyB0byBhY2Nlc3MgdGhlIG92ZXJsYXkgbWF5IGJlIGVudGlyZWx5IGRpZmZlcmVudCBmcm9t DQo+IHRoZSBvbmUgb3IgbW9yZSBlbnRpdGllcyB0aGF0IG1heSBiZSBwcm92aWRpbmcgc2Vydmlj ZXMgb24gdGhlIG92ZXJsYXkuDQo+IMKgQ2x1YmJpbmcgdGhlIHR3byBpcyBhbmFsb2dvdXMgdG8g c2F5aW5nIHRoYXQgdGhlIGVudGl0eSB0aGF0IHByb3ZpZGVzDQo+IG1lIHdpdGggYW4gSVAgYWRk cmVzcyB0b2RheSBnZXRzIHRvIHRlbGwgbWUgd2hhdCBhcHBsaWNhdGlvbnMgb3Igd2ViDQo+IHNp dGVzIHRvIGFjY2VzcyBvbiBteSBsYXB0b3AuIMKgQ2VydGFpbmx5LCB0aGF0IHdvdWxkIGJlIHVu ZGVzaXJhYmxlLg0KPiDCoEV2ZW4gaW4gdGhlIG1vYmlsZSBtYXJrZXQsIHRoaW5ncyBhcmUgZ29p bmcgdGhlIG90aGVyIHdheS4gwqBXaGF0DQo+IGFwcGxpY2F0aW9ucyBydW4gb24gdGhlIGlQaG9u ZSBvciB0aGUgR1Bob25lIGFyZSBub3QgcmVhbGx5IGRldGVybWluZWQNCj4gYnkgdGhlIG9wZXJh dG9yIGFueSBtb3JlIChvZiBjb3Vyc2UsIG91dHNpZGUgdGhlIE5vcnRoIEFtZXJpY2FuIG1hcmtl dCwNCj4gdGhpcyBoYXMgYmVlbiB0cnVlIGZvciBhIHdoaWxlIG5vdykuDQo+ID4NCj4gPiBBbiBv dmVybGF5IGNvbmZpZ3VyYXRpb24gZG9jdW1lbnQgaGFuZGxlZCBieSB0aGUgb3ZlcmxheSBwcm92 aWRlcg0KPiBtdXN0IG5vdCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGgga2luZHMgb3IgdXNhZ2Vz IG9uIHRoZSBvdmVybGF5IHdoaWNoDQo+IG1heSBiZSBjb21pbmcgZnJvbSB2YXJpb3VzIHNlcnZp Y2VzIG9mZmVyZWQgb24gdGhlIG92ZXJsYXkgZnJvbQ0KPiBkaWZmZXJlbnQgcHJvdmlkZXJzLiBP dGhlcndpc2UsIHdlIGFyZSBjcmVhdGluZyBhIG1vZGVsIHdoaWNoIGlzIGdvaW5nDQo+IHRvIGxp bWl0IGRlcGxveW1lbnQgb3B0aW9ucyBhbmQgSSBkb24ndCB0aGluayBvdXIgaW50ZW50IGhlcmUg aXMgdG8NCj4gY3JlYXRlIGEgd2FsbGVkIGdhcmRlbiBmb3Igb3ZlcmxheXMuDQo+ID4NCj4gPiBC ZXN0LA0KPiA+IFZpZHlhDQo+ID4NCg== From vidyan@qualcomm.com Fri Mar 27 10:30:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6655B3A6855 for ; Fri, 27 Mar 2009 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.156 X-Spam-Level: X-Spam-Status: No, score=-105.156 tagged_above=-999 required=5 tests=[AWL=1.443, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWbInwzzZibl for ; Fri, 27 Mar 2009 10:30:33 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A7BEC3A6C10 for ; Fri, 27 Mar 2009 10:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1238175088; x=1269711088; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Fri,=2027=20Mar=20200 9=2010:31:23=20-0700|Subject:=20RE:=20[P2PSIP]=20Access =20control=20lists=20for=20RELOAD=20storage|Thread-Topic: =20[P2PSIP]=20Access=20control=20lists=20for=20RELOAD=20s torage|Thread-Index:=20AcmuhjR83/29rlYtQNOCZCU++xSi3gAeS0 Mw|Message-ID:=20|References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5565"=3B=20 a=3D"16672706"; bh=uTSNodVm/Lg+ER+B3XaJ3J0wK0dmKgQNPF/w0A9jh0g=; b=beD/ns03K5CZHlIz0LCOPH8KX5L9aH1oQyu5w6JyRZ8lwXEPhQPFbwPM 5JE5ACn+BFZXEUGu0J2Fed5tgreYWA9lrIie1fqLLas9BzF6vIW6yp3ND yZ+r0BC00ns67DpDUHRUODjrQp2OF18BspRBFlYCKPMc1IbS9gmXc8Er7 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16672706" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2009 10:31:28 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2RHVSpt009715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2009 10:31:28 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2RHVRI2019079 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 10:31:27 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 27 Mar 2009 10:31:25 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Fri, 27 Mar 2009 10:31:24 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp Date: Fri, 27 Mar 2009 10:31:23 -0700 Thread-Topic: [P2PSIP] Access control lists for RELOAD storage Thread-Index: AcmuhjR83/29rlYtQNOCZCU++xSi3gAeS0Mw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Access control lists for RELOAD storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 17:30:35 -0000 V2hlcmUgaXQgc2hvdWxkIGJlIHNwZWNpZmllZCBjYW4gYmUgZGlzY3Vzc2VkLCBidXQgYmVmb3Jl IHRoYXQsIEkgdGhpbmsgd2Ugc2hvdWxkIGVuc3VyZSB0aGF0IHRoZSBhdXRob3JpemF0aW9uIG1v ZGVsIHdlIGFyZSBnb2luZyB3aXRoIHdpbGwgYWxsb3cgZm9yIHRoaXMuICANCg0KTm90ZSB0aGF0 IHdoZW4gYSBub2RlIGluIHRoZSBhdXRob3JpemVkIGxpc3QgYXR0ZW1wdHMgdG8gbW9kaWZ5IHRo ZSBkYXRhLCBpdCdzIHVzZXIgbmFtZSBvciBub2RlIGlkIGNhbm5vdCBiZSB1c2VkIHRvIGF1dGhv cml6ZSB0aGUgcmVzb3VyY2UgaWQuICBBbmQgdGhlIG1vZGlmaWVkIGRhdGEgd2lsbCBub3cgbmVl ZCB0byBiZSBzdG9yZWQgd2l0aCB0aGUgbW9kaWZpZXIncyBzaWduYXR1cmUuIA0KDQpJIHRoaW5r IHRoaXMgYWJpbGl0eSBmb3IgbXVsdGlwbGUgbm9kZXMgdG8gbW9kaWZ5IGRhdGEgaXMgY3J1Y2lh bC4gIFNvLCBpdCBpcyB3b3J0aCB0aGlua2luZyBhYm91dCB0aGUgYXV0aG9yaXphdGlvbiBtb2Rl bCB0aGF0IGlzIGdvaW5nIHRvIGFsbG93IGZvciB0aGlzLCB3aGlsZSBzdGlsbCBnZXR0aW5nIHVz IHRoZSBwcm9wZXJ0aWVzIHdlIHdhbnQuIEFuZCwgSSBkb24ndCB0aGluayB0aGVzZSBhcmUgbXV0 dWFsbHkgZXhjbHVzaXZlLiAgDQoNClZpZHlhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogQnJ1Y2UgTG93ZWthbXAgW21haWx0bzpiYmxAbG93ZWthbXAubmV0XQ0KPiBT ZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMDkgNzo0NiBQTQ0KPiBUbzogTmFyYXlhbmFuLCBW aWR5YQ0KPiBDYzogcDJwc2lwQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUDJQU0lQXSBBY2Nl c3MgY29udHJvbCBsaXN0cyBmb3IgUkVMT0FEIHN0b3JhZ2UNCj4gDQo+IEkgY2FuIHNlZSB0aGF0 IHRoaXMgd291bGQgYmUgdXNlZnVsLiAgSSB0aGluayB0aGUgaXNzdWUgd291bGQgb25seSBiZQ0K PiB3aGV0aGVyIGl0IGlzIHdvcnRoIHRoZSBjb21wbGV4aXR5LCBhbmQgd2hldGhlciBpdCB3b3Vs ZCBiZSBwYXJ0IG9mDQo+IHRoZSBiYXNlIG9yIGFuIGV4dGVuc2lvbi4NCj4gDQo+IEJydWNlDQo+ IA0KPiANCj4gMjAwOS8zLzI2IE5hcmF5YW5hbiwgVmlkeWEgPHZpZHlhbkBxdWFsY29tbS5jb20+ Og0KPiA+IEF0IHRoZSBtb21lbnQsIFJFTE9BRCBkZWZpbmVzIHNvbWUgYWNjZXNzIGNvbnRyb2wg cnVsZXMgdGhhdCBhbGxvd3MNCj4gPiBhdXRob3JpemF0aW9uIG9mIGEgbm9kZS91c2VyIHRvIHN0 b3JlIGF0IGEgcGFydGljdWxhciBsb2NhdGlvbi4NCj4gSG93ZXZlciwNCj4gPiBvbmx5IHRoYXQg bm9kZS91c2VyIG1heSBtb2RpZnkgb3Igb3ZlcndyaXRlIHRoZSBkYXRhLsKgIEl0IGRvZXMgbm90 DQo+IGFsbG93IGENCj4gPiBtZWNoYW5pc20gdG8gYXV0aG9yaXplIG90aGVyIG5vZGVzIG9yIHVz ZXJzIHRvIG1vZGlmeSB0aGUgZGF0YS7CoCBJDQo+IHRoaW5rIGl0DQo+ID4gaXMgdmVyeSB1c2Vm dWwgdG8gYWxzbyBoYXZlIHByb3Zpc2lvbnMgZm9yIGF1dGhvcml6aW5nIG90aGVyIG5vZGUgaWRz DQo+IG9yDQo+ID4gdXNlciBuYW1lcyB0aGF0IGNhbiBtb2RpZnkgdGhlIGRhdGEuwqAgQXMgYSBz aW1wbGUgdXNlIGNhc2UgZm9yIHRoaXMsDQo+ID4gY29uc2lkZXIgbXVsdGlwbGUgbWVtYmVycyBv ZiBhIGZhbWlseSBiZWluZyBhYmxlIHRvIG1vZGlmeSB0aGUNCj4gbWFwcGluZyBmb3INCj4gPiB0 aGUgU0lQIEFPUiBvZiB0aGVpciBob21lIHBob25lLsKgIMKgVGhlcmUgYXJlIHBsZW50eSBvZiBv dGhlciBjYXNlcyBhcw0KPiB3ZWxsDQo+ID4gd2hlcmUgZGF0YSBjcmVhdGVkIGJ5IG9uZSBub2Rl IG1heSBiZSBtb2RpZmllZCBieSBvdGhlciBhdXRob3JpemVkDQo+IG5vZGVzLg0KPiA+DQo+ID4N Cj4gPg0KPiA+IEZvciB0aGlzIHB1cnBvc2UsIEkgdGhpbmsgZGVmaW5pbmcgYW4gQUNMIHRoYXQg aXMgYWxsb3dlZCB0byBiZQ0KPiBzdG9yZWQgd2l0aA0KPiA+IHRoZSBkYXRhIG1pZ2h0IGJlIGFw cHJvcHJpYXRlLsKgIFRoZSBjcmVhdG9yIG1heSBzcGVjaWZ5IGEgbGlzdCBvZg0KPiBub2RlIGlk cw0KPiA+IG9yIHVzZXIgbmFtZXMgdGhhdCBhcmUgYXV0aG9yaXplZCB0byBtb2RpZnkgdGhlIGRh dGEuDQo+ID4NCj4gPg0KPiA+DQo+ID4gV2UgY2FuIGRpc2N1c3MgZnVydGhlciBvbiB0aGUgYWN0 dWFsIHNvbHV0aW9uIG9wdGlvbnMsIGJ1dCwgSeKAmWQgZmlyc3QNCj4gbGlrZQ0KPiA+IHRvIGdl dCBmZWVkYmFjayBvbiB0aGUgdG9waWMgaXRzZWxmIHRvIHNlZSBpZiBwZW9wbGUgYWdyZWUgdGhp cyBpcw0KPiB3b3J0aA0KPiA+IGFkZHJlc3NpbmcuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhhbmtz LA0KPiA+IFZpZHlhDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gPiBQMlBTSVBAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPiA+ DQo+ID4NCg== From melodysong@huawei.com Fri Mar 27 10:44:00 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783273A6A36 for ; Fri, 27 Mar 2009 10:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=1.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KYdmXtA-3Wn for ; Fri, 27 Mar 2009 10:43:59 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5BFDF3A69D6 for ; Fri, 27 Mar 2009 10:43:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH600I8FELELP@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 28 Mar 2009 01:44:03 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH600ELOELER2@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 28 Mar 2009 01:44:02 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [130.129.20.123]) by szxmc03-in.huawei.com (mshttpd); Sat, 28 Mar 2009 01:44:02 +0800 Date: Sat, 28 Mar 2009 01:44:02 +0800 From: songhaibin 64081 In-reply-to: To: "Narayanan, Vidya" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Access control lists for RELOAD storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 17:44:00 -0000 =3E Where it should be specified can be discussed=2C but before that=2C I= = =3E think we should ensure that the authorization model we are going = =3E with will allow for this=2E = =3E = =3E Note that when a node in the authorized list attempts to modify = =3E the data=2C it=27s user name or node id cannot be used to authorize = =3E the resource id=2E And the modified data will now need to be stored = =3E with the modifier=27s signature=2E = =3E = =3E I think this ability for multiple nodes to modify data is crucial=2E = =3E So=2C it is worth thinking about the authorization model that is = =3E going to allow for this=2C while still getting us the properties we = =3E want=2E And=2C I don=27t think these are mutually exclusive=2E = It=27s quite useful=2E I think probably there are other ways to implement= this idea=2E =3E = =3E Vidya =3E = =3E =3E -----Original Message----- =3E =3E From=3A Bruce Lowekamp =5Bmailto=3Abbl=40lowekamp=2Enet=5D =3E =3E Sent=3A Thursday=2C March 26=2C 2009 7=3A46 PM =3E =3E To=3A Narayanan=2C Vidya =3E =3E Cc=3A p2psip=40ietf=2Eorg =3E =3E Subject=3A Re=3A =5BP2PSIP=5D Access control lists for RELOAD sto= rage =3E =3E = =3E =3E I can see that this would be useful=2E I think the issue would = =3E only be =3E =3E whether it is worth the complexity=2C and whether it would be par= t of =3E =3E the base or an extension=2E =3E =3E = =3E =3E Bruce =3E =3E = =3E =3E = =3E =3E 2009/3/26 Narayanan=2C Vidya =3Cvidyan=40qualcomm=2Ecom=3E=3A =3E =3E =3E At the moment=2C RELOAD defines some access control rules tha= t = =3E allows=3E =3E authorization of a node/user to store at a particular = =3E location=2E=3E However=2C =3E =3E =3E only that node/user may modify or overwrite the data=2E=3F It= does not =3E =3E allow a =3E =3E =3E mechanism to authorize other nodes or users to modify the = =3E data=2E=3F I =3E =3E think it =3E =3E =3E is very useful to also have provisions for authorizing other = =3E node ids =3E =3E or =3E =3E =3E user names that can modify the data=2E=3F As a simple use cas= e for = =3E this=2C=3E =3E consider multiple members of a family being able to = =3E modify the =3E =3E mapping for =3E =3E =3E the SIP AOR of their home phone=2E=3F =3FThere are plenty of = other = =3E cases as =3E =3E well =3E =3E =3E where data created by one node may be modified by other autho= rized =3E =3E nodes=2E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E For this purpose=2C I think defining an ACL that is allowed t= o be =3E =3E stored with =3E =3E =3E the data might be appropriate=2E=3F The creator may specify a= list of =3E =3E node ids =3E =3E =3E or user names that are authorized to modify the data=2E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E We can discuss further on the actual solution options=2C but=2C= = =3E I=A1=AFd first =3E =3E like =3E =3E =3E to get feedback on the topic itself to see if people agree = =3E this is =3E =3E worth =3E =3E =3E addressing=2E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E Thanks=2C =3E =3E =3E Vidya =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3E =3E P2PSIP mailing list =3E =3E =3E P2PSIP=40ietf=2Eorg =3E =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/p2psip =3E =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E P2PSIP mailing list =3E P2PSIP=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/p2psip =3E From melodysong@huawei.com Fri Mar 27 10:49:00 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBE03A6857 for ; Fri, 27 Mar 2009 10:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBvsH8TZ289g for ; Fri, 27 Mar 2009 10:49:00 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9C1813A6C94 for ; Fri, 27 Mar 2009 10:48:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH600IXDEDQLP@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 28 Mar 2009 01:39:26 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH600L02EDQYT@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 28 Mar 2009 01:39:26 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [130.129.20.123]) by szxmc03-in.huawei.com (mshttpd); Sat, 28 Mar 2009 01:39:25 +0800 Date: Sat, 28 Mar 2009 01:39:25 +0800 From: songhaibin 64081 In-reply-to: To: Salman Abdul Baset Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <20090318211247.74FE250822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Comments on draft-ietf-p2psip-diagnostics X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 17:49:00 -0000 Hi Salman, > > It is necessary to clarify the scope of the problems that are > being > addressed and to precisly define what 'diagnostics' mean. > Currently, it is > very open ended and includes: > > -routing diagnostics > -detecting malfunctioning or badly behaving peers > -checking the health of overlay Yes, the draft now has the consideration of routing diagnostics and detecting malfunctioning peers. However, checking the health of the overlay has not been considered in the draft at present, although we have some thought on it. > Overlay maintenance is central to any p2p system. How is that > different > from diagnostics? I am not quite sure about that. But I think the diagnostic information can be used for overlay maintenance. They are a little different. > > The suggested solution incorporates two new methods. I think we > need a > bit more clarity on what is that existing methods cannot achieve, > for > which new methods are required. As an example, one can easily > implement > Path_Track using RouteQuery and [Node]Fetch. > > What is indeed required is a mechanism to obtain the state > [routing/storage] of a node. This can be done using NodeFetch and > may also > be accomplished using Fetch. > The draft now is lack of consideration for storage state. It is a good suggestion to add that as one type of diagnostic information. It is very helpful in the enviroment where the peer storage is limited or hot spot. Haibin > -salman > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From saumitra@qualcomm.com Fri Mar 27 13:09:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F53228C140 for ; Fri, 27 Mar 2009 13:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.645 X-Spam-Level: X-Spam-Status: No, score=-103.645 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqtl2FhoCy0U for ; Fri, 27 Mar 2009 13:09:25 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 53F313A6974 for ; Fri, 27 Mar 2009 13:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1238184620; x=1269720620; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Fri,=2027=20Mar=20200 9=2013:09:42=20-0700|Subject:=20RE:=20[P2PSIP]=20New=20Lo ad=20balancing=20in=20RELOAD=20draft|Thread-Topic:=20[P2P SIP]=20New=20Load=20balancing=20in=20RELOAD=20draft |Thread-Index:=20AcmgtfwRO3u8Cb4QRiGj9Mgz6asjXAOYR3lA |Message-ID:=20<2D06DE445C2ADE44890118C3F449B9636D583038@ NASANEXMB12.na.qualcomm.com>|References:=20=0D=0A=09=20<2D06DE445C2ADE448901 18C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com>=0D=0A =20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5566"=3B=20 a=3D"16664734"; bh=J4fC+4KCajRce6nnMBhOzqw+BdYaT8ACeZtLsqWxhGM=; b=ixDSYHaGDLd7YtNShgGBGP74luRUR8Md+WtcUwc+Xm8kC9PpevATXhak pNlr4oZKMg8NCsWFEHY8JhAeu+6iqwCS7dNOQvc/kedfD0lcM16cUFEaz X1mtCP8ivPsf9/qXdGOXOeYxtpnTlZu1+A3limuyYXlT4MuITpf4bUaNU 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5566"; a="16664734" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2009 13:09:49 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2RK9nvB000630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2009 13:09:49 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2RK9j14016154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 13:09:49 -0700 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.33]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Fri, 27 Mar 2009 13:09:44 -0700 From: "Das, Saumitra" To: Bruce Lowekamp Date: Fri, 27 Mar 2009 13:09:42 -0700 Thread-Topic: [P2PSIP] New Load balancing in RELOAD draft Thread-Index: AcmgtfwRO3u8Cb4QRiGj9Mgz6asjXAOYR3lA Message-ID: <2D06DE445C2ADE44890118C3F449B9636D583038@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B96340099F6D@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] New Load balancing in RELOAD draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 20:09:32 -0000 SGkgQnJ1Y2UsDQoNCiAgSGF2ZSBzb21lIGFuc3dlcnMgbm93IGZvciBzb21lIG9mIHlvdXIgcXVl c3Rpb25zLg0KDQo+RG8geW91IGhhdmUgZXhwZXJpbWVudGFsIHJlc3VsdHMgb2YgaG93IHRoaXMg d29ya3MgaW4gYW4NCj5pbXBsZW1lbnRhdGlvbj8gIEluIHBhcnRpY3VsYXIsIGdpdmVuIHRoZSBz ZW5zaXRpdml0eSBvZiB0aGUgbG9hZA0KPmRpc3RyaWJ1dGlvbiBvbiBkZWx0YSwgSSdtIHdvbmRl cmluZyB3aGV0aGVyIHBlZXJzJyBkaWZmZXJlbnQNCj5wZXJjZXB0aW9ucyBvZiB0aGUgc2l6ZSBv ZiB0aGUgb3ZlcmxheSBjcmVhdGVzIGl0cyBvd24gbG9hZCBpbWJhbGFuY2UNCj5mYWN0b3IuICAo bWF5IGJlIGFibGUgdG8gZG8gdGhhdCBxdWFudGl0YXRpdmVseSwgSSBndWVzcy4pIA0KDQpUaGUg bG9hZCBpbWJhbGFuY2UgZmFjdG9yIHZhcmllcyBhcyBhIGZ1bmN0aW9uIG9mIGRlbHRhIChkZWx0 YSBpcyBjaG9zZW4gYXMgMS9OZXN0KTsgYXMgZGVsdGEgaW5jcmVhc2VzLCB0aGUgbG9hZCBpbWJh bGFuY2UgcmVkdWNlcy4gDQpNb3JlIHNwZWNpZmljYWxseSwgaWYgdGhlIG1heGltdW0gZmFjdG9y IGVycm9yIGluIGVzdGltYXRpbmcgdGhlIG5ldHdvcmsgc2l6ZSBpcyBnYW1tYV9uLCB0aGVuIGl0 IGNhbiBiZSBzaG93biB0aGF0IHdpdGg6DQphbHBoYSA9IDggeCAoZ2FtbWFfbi9lcHNpbG9uXjIp IHggbG9nIE4sIHRoZSBtYXhpbXVtIHNoYXJlIG9mIGEgbm9kZSBpcyBhdCBtb3N0IFsoMStlcHNp bG9u4oCZKS8oMS1lcHNpbG9uKV4yXSBmb3IgbGFyZ2UgTiAoZXBzaWxvbuKAmSBhbmQgZXBzaWxv biA+IDApIHdoZW4gdGhlIG5vZGUgY2FwYWNpdGllcyBhcmUgaG9tb2dlbmVvdXMuIFRoZXNlIHJl c3VsdHMgY2FuIGJlIHZlcmlmaWVkIHZpYSBzaW11bGF0aW9ucywgYW5kIGl0IGNhbiBiZSBzaG93 biB0aGF0IHRoZSBsb2FkIGltYmFsYW5jZSBmYWN0b3IgaXMgYXQgbW9zdCA0IHdpdGggYWxwaGEg PSAyIGxvZyBOLg0KDQo+SXQgYWxzbyBzZWVtcyBsaWtlIHRoZSBhcnJpdmFsIG9mIGEgbmV3IHBl ZXIgaXMgZ29pbmcgdG8gY2F1c2UgYSBzdG9ybSBvZiBkYXRhDQo+bWlncmF0aW9ucywgYW5kIHRo aXMgd291bGQgY2F1c2UgdGhlIG92ZXJsYXkgdG8gc3VmZmVyIGNvbmdlc3Rpb24NCj5jb2xsYXBz ZSBpbiBhbnl0aGluZyBidXQgYSBzdGFibGUgb3ZlcmxheS4NCg0KSW4gdGhlIGhvbW9nZW5lb3Vz IGNhc2UsIHdoZW4gYWxsIG5vZGVzIGhhdmUgZXF1YWwgY2FwYWNpdHksIHRoZSBhbW91bnQgb2Yg ZGF0YSBtaWdyYXRpb25zIHdoZW4gYSBuZXcgbm9kZSBqb2lucy9sZWF2ZXMgd291bGQgYmUgb2Yg dGhlIG9yZGVyIG9mIE8oMS9OKSB3aGljaCBpcyB0aGUgc2FtZSBhcyBDaG9yZC4gDQoNCkluIHRo ZSBzY2VuYXJpbyB3aGVuIHRoZSBub2RlcyBoYXZlIHVuZXF1YWwgY2FwYWNpdHksIGl0IGNhbiBz dGlsbCBiZSBzaG93biB0aGFuIHRoZSBhbW91bnQgb2YgZGF0YSBtaWdyYXRpb24gd2hlbiBhIG5l dyBub2RlIGpvaW5zL2xlYXZlcyB0aGUgb3ZlcmxheSBpcyBvZiB0aGUgb3JkZXIgb2YgTygoMStl cHNpbG9uKS9OKSBhcyBsb25nIGFzIHRoZSBlcnJvcnMgaW4gZXN0aW1hdGluZyB0aGUgbm9kZSBj YXBhY2l0eSBhbmQgbmV0d29yayBzaXplIGFyZSBsb3cuDQoNClNvbWUgb2YgdGhlc2UgcHJvb2Zz IGFyZSBpbiB0aGUgcGFwZXIgYnkgZ29kZnJleSBldCBhbCBjaXRlZCBpbiB0aGUgZHJhZnQuDQoN ClRoYW5rcw0KU2F1bWl0cmENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJy dWNlIExvd2VrYW1wIFttYWlsdG86YmJsQGxvd2VrYW1wLm5ldF0gDQpTZW50OiBNb25kYXksIE1h cmNoIDA5LCAyMDA5IDU6NTMgQU0NClRvOiBEYXMsIFNhdW1pdHJhDQpDYzogcDJwc2lwQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW1AyUFNJUF0gTmV3IExvYWQgYmFsYW5jaW5nIGluIFJFTE9BRCBk cmFmdA0KDQpTYXVtaXRyYSwNCg0KVmVyeSBpbnRlcmVzdGluZyBkcmFmdC4NCg0KRG8geW91IGhh dmUgZXhwZXJpbWVudGFsIHJlc3VsdHMgb2YgaG93IHRoaXMgd29ya3MgaW4gYW4NCmltcGxlbWVu dGF0aW9uPyAgSW4gcGFydGljdWxhciwgZ2l2ZW4gdGhlIHNlbnNpdGl2aXR5IG9mIHRoZSBsb2Fk DQpkaXN0cmlidXRpb24gb24gZGVsdGEsIEknbSB3b25kZXJpbmcgd2hldGhlciBwZWVycycgZGlm ZmVyZW50DQpwZXJjZXB0aW9ucyBvZiB0aGUgc2l6ZSBvZiB0aGUgb3ZlcmxheSBjcmVhdGVzIGl0 cyBvd24gbG9hZCBpbWJhbGFuY2UNCmZhY3Rvci4gIChtYXkgYmUgYWJsZSB0byBkbyB0aGF0IHF1 YW50aXRhdGl2ZWx5LCBJIGd1ZXNzLikgIEl0IGFsc28NCnNlZW1zIGxpa2UgdGhlIGFycml2YWwg b2YgYSBuZXcgcGVlciBpcyBnb2luZyB0byBjYXVzZSBhIHN0b3JtIG9mIGRhdGENCm1pZ3JhdGlv bnMsIGFuZCB0aGlzIHdvdWxkIGNhdXNlIHRoZSBvdmVybGF5IHRvIHN1ZmZlciBjb25nZXN0aW9u DQpjb2xsYXBzZSBpbiBhbnl0aGluZyBidXQgYSBzdGFibGUgb3ZlcmxheS4NCg0KRHVlIHRvIHRo b3NlIGNvbmNlcm5zLCBhbmQgaW4gcGFydGljdWxhciBiZWNhdXNlIG9mIHRoZSBjb21wbGV4aXR5 IG9mDQp0aGUgaW1wbGVtZW50YXRpb24sIEkgd291bGQgb3Bwb3NlIG1vZGlmeWluZyB0aGUgYmFz ZSBkaHQgYWxnb3JpdGhtIGluDQp0aGlzIG1hbm5lci4gIE5vdCB0aGF0IGxvYWQgaW1iYWxhbmNl IGFuZCBoYW5kbGluZyBwZWVycyB3aXRoDQpkaWZmZXJlbnQgcmVzb3VyY2UgbGV2ZWxzIGlzbid0 IGFuIGlzc3VlIHdpdGggdGhlIGJhc2UgZGh0LCBidXQNCmltcGxlbWVudGF0aW9uIGNvbXBsZXhp dHkgaXMgYWxyZWFkeSBhIHNlcmlvdXMgaXNzdWUgdGhhdCBJIHJlbWFpbg0KY29uY2VybmVkIGFi b3V0LiAgSG93ZXZlciwgSSBiZWxpZXZlIGEgZHJhZnQgbGlrZSB0aGlzIHNwZWNpZnlpbmcgYW4N CmFsdGVybmF0aXZlIGRodCBhbGdvcml0aG0gaXMgYmVuZWZpY2lhbCwgYW5kIHdvdWxkIHN1cHBv cnQgYSBmdXJ0aGVyDQpyZXZpc2lvbi4NCg0KQnJ1Y2UNCg0KDQpPbiBUdWUsIE1hciAzLCAyMDA5 IGF0IDk6MTAgUE0sIERhcywgU2F1bWl0cmEgPHNhdW1pdHJhQHF1YWxjb21tLmNvbT4gd3JvdGU6 DQo+IEhpIGFsbCwNCj4NCj4gSSBqdXN0IHN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQgcHJvcG9zZXMg YSBsb2FkIGJhbGFuY2luZyBzb2x1dGlvbiBmb3IgdGhlIGRlZmF1bHQgREhUIGluIFJFTE9BRC4g Q29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KPg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1zYXVtaXRyYS1wMnBzaXAtbG9hZGJhbGFuY2UtMDAudHh0DQo+DQo+ IEJlc3QsDQo+IFNhdW1pdHJhDQo+DQo+DQo+DQo+DQo+IHd3dy5zYXVtaXRyYS5pbmZvDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFAyUFNJUCBt YWlsaW5nIGxpc3QNCj4gUDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcDJwc2lwDQo+DQo= From apike3@csc.com Fri Mar 27 13:59:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6DF3A687C for ; Fri, 27 Mar 2009 13:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-1.521, BAYES_05=-1.11, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T05V3jk9fdOD for ; Fri, 27 Mar 2009 13:59:22 -0700 (PDT) Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.242.83]) by core3.amsl.com (Postfix) with ESMTP id E26AC3A6A93 for ; Fri, 27 Mar 2009 13:59:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-6.tower-63.messagelabs.com!1238187614!110487671!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 21641 invoked from network); 27 Mar 2009 21:00:15 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-6.tower-63.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2009 21:00:15 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2RL0ELI008944 for ; Fri, 27 Mar 2009 17:00:15 -0400 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: MIME-Version: 1.0 From: Anthony D Pike To: "p2psip@ietf.org" Message-ID: Date: Fri, 27 Mar 2009 17:00:11 -0400 X-Mailer: Lotus Domino Web Server Release 8.0.1 February 07, 2008 X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.0.1|February 07, 2008) at 03/27/2009 17:00:11, Serialize complete at 03/27/2009 17:00:12, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 03/27/2009 05:02:25 PM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [P2PSIP] draft-ietf-p2psip-base-02.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2009 20:59:22 -0000

Note to the Editor of draft-ietf-p2psip-base-02.txt,

section= 5.6.1 future support for HIP

I presume this is RFC 5201, buts thats = my assumption, please could you add a reference in the refernce sectio= n in the next rev to HIP.

Thanks Tony Pike

This is a PRIVATE message. If you are not the intended recipie= nt, please delete without copying and kindly advise us by e-mail of the mis= take in delivery.
NOTE: Regardless of content, this e-mail shall not op= erate to bind CSC to any order or other contract unless pursuant to explici= t written agreement or government initiative expressly permitting the use o= f e-mail for such purpose. =E2= =80=A2 

=