From mailman-bounces@ietf.org Mon Nov 1 07:02:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21521 for ; Mon, 1 Nov 2004 07:02:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COb7q-0005MO-0k for tsvwg-archive@ietf.org; Mon, 01 Nov 2004 07:17:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZU4-0003k7-0g for tsvwg-archive@ietf.org; Mon, 01 Nov 2004 05:32:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tsvwg-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:12:21 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for tsvwg-archive@ietf.org: List Password // URL ---- -------- tsvwg@ietf.org xeowbe https://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive%40ietf.org From tsvwg-bounces@ietf.org Mon Nov 1 20:43:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01602; Mon, 1 Nov 2004 20:43:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnx5-0003Eu-DU; Mon, 01 Nov 2004 20:59:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnUS-00080Z-G2; Mon, 01 Nov 2004 20:29:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnNl-0003ak-DB for tsvwg@megatron.ietf.org; Mon, 01 Nov 2004 20:22:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29604 for ; Mon, 1 Nov 2004 20:22:42 -0500 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COncm-0002lZ-BY for tsvwg@ietf.org; Mon, 01 Nov 2004 20:38:16 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id iA21MDOC014682; Mon, 1 Nov 2004 20:22:13 -0500 Received: from localhost (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with SMTP id CE1E33C80B4; Mon, 1 Nov 2004 20:20:19 -0500 (EST) Received: from [150.169.1.185] (dhcp185.Research.Panasonic.COM [150.169.1.185])by redwood.research.panasonic.com (Postfix) with ESMTP id 029BC3C80B4;Mon, 1 Nov 2004 20:20:12 -0500 (EST) Message-ID: <4186E12E.3060009@Research.Panasonic.COM> Date: Mon, 01 Nov 2004 20:21:50 -0500 From: Sathya Narayanan Organization: Panasonic Technologies Company User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:1.81369 C:22 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Dennis Bushmitch , "'Shiwen Mao'" , Shivendra Panwar Subject: [Tsvwg] Mutlti-Flow Real time transport protocol (MRTP) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Dear TSV-WG Members, A few of us have been working on defining a Multi-flow real-time transport protocol (MRTP) for carrying real-time transport across multiple flows/paths. We submitted a draft (http://www.ietf.org/internet-drafts/draft-narayanan-mrtp-00.txt) containing our initial thoughts on the design. We also made a short presentation in the AVT working group at IETF60. We prepared a brief motivation draft (http://www.ietf.org/internet-drafts/draft-narayanan-mrtp-motivation-00.txt) to present the background and motivation for the work. More information on related research can be found at http://theater.poly.edu/mrtp/ Please take a look at the drafts and let us know your comments/thoughts. We would like to assess interest level in developing a multi-path real time (possibily both rt and nrt) protocol. thanks & regards, Sathya _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Nov 7 16:57:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02023; Sun, 7 Nov 2004 16:57:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQv2T-0005gv-B4; Sun, 07 Nov 2004 16:57:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQuwe-0006HL-Pq; Sun, 07 Nov 2004 16:51:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQujL-0003Y7-1S for tsvwg@megatron.ietf.org; Sun, 07 Nov 2004 16:37:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29154 for ; Sun, 7 Nov 2004 16:37:44 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQujk-00053o-5Q for tsvwg@ietf.org; Sun, 07 Nov 2004 16:38:12 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA7LbCIA217464; Sun, 7 Nov 2004 21:37:12 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA7LbBsG100066; Sun, 7 Nov 2004 21:37:11 GMT Received: from zurich.ibm.com (sig-9-145-248-80.de.ibm.com [9.145.248.80]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA64226; Sun, 7 Nov 2004 22:37:07 +0100 Message-ID: <418E9581.8090701@zurich.ibm.com> Date: Sun, 07 Nov 2004 22:37:05 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Jozef Babiarz , Fred Baker , Kwok-Ho Chan References: <9671A92C3C8B5744BC97F855F7CB646501CC02D2@zcarhxm1.corp.nortel.com> <417CE51D.5050208@zurich.ibm.com> In-Reply-To: <417CE51D.5050208@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, David Black Subject: [Tsvwg] draft-baker-diffserv-basic-classes-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Hi, I find more to comment in this draft each time I look at it. Maybe it's getting longer each time... > The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in [RFC2119]. It's very strange to find this in the Abstract, not the Introduction. > 1.2 Service Class Definition > > > A "service class" represents a set of traffic that requires specific > delay, loss and jitter characteristics from the network for which a > consistent and defined per-hop behavior (PHB) [RFC2475] applies. The Proposed Standard is RFC2474 and that should surely be the primary normative reference; 2475 is Informational. Also, this section still lacks any reference to the PDB document and any explanation of the relationship between Service Class and PDB. I suspect it is something like this: A Service Class as defined here is essentially a statement of the required characteristics of a traffic aggregate; the actual specification of the expected treatment of a traffic aggregate within a domain is defined as a Per Domain Behavior [RFC3086]. You need this, since you later refer to a PDB [RFC3662]. > 1.3 Key Differentiated Services Concepts > > > The reader SHOULD be familiar with the principles of the > Differentiated Services Architecture [RFC2475]. However, we > recapitulate key concepts here to save searching. Again, the normative reference is [RFC2474]. > 1.4.1 Default Forwarding (DF) > > > The basic forwarding behavior applied to any class of traffic are > those described in [RFC2475] and [RFC2309]. And again. > 4.3 Multimedia Conferencing Service Class ... > > RECOMMENDED DSCP marking: > o Video conferencing packets are marked with AF4x > o VPN service may be marked with AF4x, depending on the service > characteristics > o Server to server data transfer with AF4x, depending on the service > characteristics It makes no sense to suddenly mention VPNs and server2server data transfer here. Either this is the multimedia conferencing service class, or it isn't. If you think this service class also contains VPN and server2server traffic, that needs stating up front. > 5.3 Explanation of Ring Clipping If we allowed such things in RFCs, this would be a footnote. I think this should either be a subsection 4.2.1, or at least it should contain a reference back to 4.2. It uses jargon and acronyms unknown in the IETF (Tandem Office??? ISUP??) and English errors. > 5.4 VPN Service Mapping You don't refer to RFC 2983 (Differentiated Services and Tunnels), and I'm not sure you are consistent with it. You should certainly indicate which of the conceptual models in 2983 you are suggesting. And of course if it's an IPSec VPN, IPSec specifies certain rules that you have to follow. Brian _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Nov 7 17:10:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03796; Sun, 7 Nov 2004 17:10:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQvEy-00068V-Ir; Sun, 07 Nov 2004 17:10:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQv8Z-0000Cp-ND; Sun, 07 Nov 2004 17:03:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQuwt-0006Oy-Mz for tsvwg@megatron.ietf.org; Sun, 07 Nov 2004 16:51:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01649 for ; Sun, 7 Nov 2004 16:51:45 -0500 (EST) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQuxJ-0005ZP-1H for tsvwg@ietf.org; Sun, 07 Nov 2004 16:52:13 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA7LpGIA218530 for ; Sun, 7 Nov 2004 21:51:16 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA7LpFsG098782 for ; Sun, 7 Nov 2004 21:51:15 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA7LpFZq013375 for ; Sun, 7 Nov 2004 21:51:15 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA7LpFW7013366; Sun, 7 Nov 2004 21:51:15 GMT Received: from zurich.ibm.com (sig-9-145-248-80.de.ibm.com [9.145.248.80]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA14388; Sun, 7 Nov 2004 22:51:12 +0100 Message-ID: <418E98CE.9060400@zurich.ibm.com> Date: Sun, 07 Nov 2004 22:51:10 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: babiarz@nortelnetworks.com, khchan@nortelnetworks.com References: <200410201429.KAA08664@ietf.org> In-Reply-To: <200410201429.KAA08664@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org Subject: [Tsvwg] Re: I-D ACTION:draft-chan-tsvwg-diffserv-class-aggr-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, I'm not sure I understand the point of this draft. I recognize that it's incomplete, but it's a trivial statement that if we send two diffserv traffic aggregates on a wire, we have built what the draft calls a treatment aggregate. Then it's a *requirement* of the diffserv architecture that the sending router has met the constraints of both PHBs corresponding to the two traffic aggregates. It's just a basic part of the diffserv architecture that different traffic aggregates on the same link share resources. How this is a achieved is an implementation issue and a possible product differentiator. So I don't see what there is to write an RFC about. IMHO, it is *not* OK to abbreviate "treatment aggregate" as "aggregate." RFC 2475 uses "aggregate" alone once or twice to refer to a traffic aggregate or behavior aggregate. We were very careful in RFC 3086 to avoid this ambiguity, and so we spelled out "traffic aggregate" or "behavior aggregate" every time. Regards Brian _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Nov 7 20:11:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18754; Sun, 7 Nov 2004 20:11:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQy4m-0001a0-PB; Sun, 07 Nov 2004 20:12:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQy2e-0007xM-3L; Sun, 07 Nov 2004 20:09:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQy1O-0007Tb-Rv for tsvwg@megatron.ietf.org; Sun, 07 Nov 2004 20:08:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18362 for ; Sun, 7 Nov 2004 20:08:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQy1p-0001TD-1Y for tsvwg@ietf.org; Sun, 07 Nov 2004 20:09:06 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2004 17:19:24 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA817NnC006053 for ; Sun, 7 Nov 2004 17:07:23 -0800 (PST) Received: from [192.168.0.2] (rtp-vpn2-513.cisco.com [10.82.242.1]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMW10392; Sun, 7 Nov 2004 20:06:51 -0500 (EST) Message-ID: <418EC6AA.6020702@cisco.com> Date: Sun, 07 Nov 2004 20:06:50 -0500 From: Philip Jacobs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Question regarding draft-baker-diffserv-basic-classes-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit I have a question regarding draft-baker-diffserv-basic-classes-04.txt It seems that there are business and unavailability cases when applications would be carried in "non-optimal" Service Classes. E.g.1. A business decision may be made such that urgent email could be sent in the "Low-latency" rather than the "High Throughput Data" Service Class used for regular email (with appropriately set higher expectations). E.g.2. During signaling, if there is no available capacity in the "Telephony" services class, a VoIP call may be carried in "Low-latency" Service Class (with appropriately set lower expectations). My question is "should this draft contain advise regarding into which Service Classes various types of application may be non-optimally placed?" It might be useful to include advice regarding: - types of application traffic which may damage Services Classes's ability to deliver as expected. Eg An email may damage the "Telephony" service class. - types of application traffic which may be carried in "non-optimal" Service Classes without negative impact. This would answer the question, which service classes a type of application may be "promoted/demoted" into, and which ones it may not. Phil _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 8 11:15:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25742; Mon, 8 Nov 2004 11:15:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCBY-0005d3-Ve; Mon, 08 Nov 2004 11:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRC09-00034K-9J; Mon, 08 Nov 2004 11:04:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBe7-0005qC-Se for tsvwg@megatron.ietf.org; Mon, 08 Nov 2004 10:41:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21557 for ; Mon, 8 Nov 2004 10:41:29 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBeW-0004VI-0l for tsvwg@ietf.org; Mon, 08 Nov 2004 10:42:06 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA8Fek10018861; Mon, 8 Nov 2004 15:40:46 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Nov 2004 10:40:46 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF433F@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Mon, 8 Nov 2004 10:40:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "'mankin@psg.com'" Subject: [Tsvwg] agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c The following is the agenda we're pursuing for Wednesday. As always, Allison and I apologize that this is so tardy. Jon Peterson NeuStar, Inc. ----- Transport Area WG (tsvwg) Wednesday, November 10 at 1530-1730 =============================== CHAIRS: Allison Mankin Jon Peterson 1530 Agenda bashing/Notetaker/Intro (chairs) 1540 RSVP Bandwidth reduction (Polk) http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.tx t 1555 Wide-Area Network (Baker) http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled-preemptio n-01.txt 1605 Diffserv Basic Classes (Chan) http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.tx t 1620 Quickstart (Jain/Floyd/Allman) http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt 1635 RSVP Aggregation (Davie) http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt 1650 XCP (Falk) http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt 1705 SCTP NAT Traversal (Xie/Stewart/Holdrege) http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt 1720 RSVP for MPLS-TE (Davie) http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 8 14:43:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19457; Mon, 8 Nov 2004 14:43:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFQn-0003Dk-Ee; Mon, 08 Nov 2004 14:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF32-0007r0-UA; Mon, 08 Nov 2004 14:19:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREyn-0005c6-Dq for tsvwg@megatron.ietf.org; Mon, 08 Nov 2004 14:15:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16210 for ; Mon, 8 Nov 2004 14:15:03 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREzN-0002IM-3s for tsvwg@ietf.org; Mon, 08 Nov 2004 14:15:42 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA8Ccfsl311460; Mon, 8 Nov 2004 12:38:41 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA8CceVr077324; Mon, 8 Nov 2004 12:38:41 GMT Received: from zurich.ibm.com (sig-9-145-251-84.de.ibm.com [9.145.251.84]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA33368; Mon, 8 Nov 2004 13:38:37 +0100 Message-ID: <418F68CC.70804@zurich.ibm.com> Date: Mon, 08 Nov 2004 13:38:36 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: tsvwg@ietf.org, pierce1m@ncr.disa.mil, choid@ncr.disa.mil References: <200410211945.PAA12440@ietf.org> In-Reply-To: <200410211945.PAA12440@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] draft-pierce-tsvwg-assured-service-req-01.txt and -arch-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit draft-pierce-tsvwg-assured-service-req-01.txt: Firstly, as I think I've said before, using the word "assured" is very confusing, since "assured forwarding" is a term of art in diffserv with a specific and different meaning. > 0. History > > Note: This section will be deleted before progressing as an RFC. > > This document has evolved through 3 different working groups: > SIPPING, IEPREP, and TSVWG. This draft was originally submitted > under SIPPING with 2 revisions and then in the IEPREP WG in order to > ensure that the Assured Service requirements are considered along > with those of the related IEPS discussions. It is not being > submitted in TSVWG. That "not" is a very confusing nit :-) > 3. High Level Requirements ... > ...For example, the > lower precedence calls may temporarily experience reduced quality as > their packets are discarded. As Fred Baker's critique of the MLEF proposal has pointed out, this is probably not acceptable, for reasons he explained in detail. > 4.3.1. Call Treatment ... > Pref-6 Preferential treatment SHOULD NOT be provided through any > scheme of dedicated or pre-reserved bandwidth or resources. That's an implementation issue, and I think it is out of place in a functional requirements document. draft-pierce-tsvwg-assured-service-arch-01.txt: > 3. Required Architecture > > In order to provide the security and feature control required for > Assured Service as defined in [Pierce1], it is necessary to utilize > the Service Provider Network Architecture in which proxies are used ... I'm unclear why this is *required* or *necessary*. I would have thought it was "recommended" or "proposed" or "appropriate" or even "sufficient." ... > There must be an edge router, as described in [RFC 2998] and RFC > [3313], generally at the boundary between the local network and the > core network. I don't see why your primary reference here is to 2998. The primary references are probably RFC 2474 and 2475, where the boxes in question are called "DS boundary nodes." 2998 builds on this for the specific case of interworking with RSVP and Integrated Services, which you don't discuss at all. > 4.3. Function of the Edge Router > > The edge router serves the functions of ingress router and egress > router referred to in various RFCs. "Edge Router" is described in > RFCs [2998], [3313], and [3521]. Same comment. Brian _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 8 15:24:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25953; Mon, 8 Nov 2004 15:24:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRG53-0004W1-Gw; Mon, 08 Nov 2004 15:25:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFoO-0000VF-OA; Mon, 08 Nov 2004 15:08:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFYL-0006iz-5u for tsvwg@megatron.ietf.org; Mon, 08 Nov 2004 14:51:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20929 for ; Mon, 8 Nov 2004 14:51:47 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFYw-0003XA-Cg for tsvwg@ietf.org; Mon, 08 Nov 2004 14:52:26 -0500 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA8JpE627177; Mon, 8 Nov 2004 14:51:14 -0500 (EST) Received: from KCHAN-2K3.nortelnetworks.com (artpt5qe.us.nortel.com [47.140.52.132]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKL3DNTB; Mon, 8 Nov 2004 14:51:13 -0500 Message-Id: <6.0.3.0.0.20041108144821.02dc7e18@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 08 Nov 2004 14:51:11 -0500 To: "Peterson, Jon" From: Kwok Ho Chan Subject: Re: [Tsvwg] agenda In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF433F@stntexch04.cis.ne ustar.com> References: <7927C67249E4AD43BC05B539AF0D129801AF433F@stntexch04.cis.neustar.com> Mime-Version: 1.0 X-Spam-Score: 1.6 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: "'tsvwg@ietf.org'" , "'mankin@psg.com'" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1528579921==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd --===============1528579921== Content-Type: multipart/alternative; boundary="=====================_6376408==.ALT" --=====================_6376408==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jon: Are the draft reference for the agenda items below correct? They are different versions of the same draft. >1635 RSVP Aggregation (Davie) >http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt > > >1720 RSVP for MPLS-TE (Davie) >http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt > Thanks! -- Kwok -- At 10:40 AM 11/8/2004, Peterson, Jon wrote: >The following is the agenda we're pursuing for Wednesday. As always, Allison >and I apologize that this is so tardy. > >Jon Peterson >NeuStar, Inc. > >----- > >Transport Area WG (tsvwg) > >Wednesday, November 10 at 1530-1730 >=============================== > >CHAIRS: Allison Mankin > Jon Peterson > >1530 Agenda bashing/Notetaker/Intro (chairs) > >1540 RSVP Bandwidth reduction (Polk) >http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.tx > >t > >1555 Wide-Area Network (Baker) >http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled-preemptio > >n-01.txt > >1605 Diffserv Basic Classes (Chan) >http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.tx > >t > >1620 Quickstart (Jain/Floyd/Allman) >http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt > > >1635 RSVP Aggregation (Davie) >http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt > > >1650 XCP (Falk) >http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt > > >1705 SCTP NAT Traversal (Xie/Stewart/Holdrege) >http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt > > >1720 RSVP for MPLS-TE (Davie) >http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > --=====================_6376408==.ALT Content-Type: text/html; charset="us-ascii" Jon:
Are the draft reference for the agenda items below correct?  They are different versions
of the same draft.

1635 RSVP Aggregation (Davie)
http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt

1720 RSVP for MPLS-TE (Davie)
http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt

Thanks!
-- Kwok --

At 10:40 AM 11/8/2004, Peterson, Jon wrote:

The following is the agenda we're pursuing for Wednesday. As always, Allison
and I apologize that this is so tardy.

Jon Peterson
NeuStar, Inc.

-----

Transport Area WG (tsvwg)

Wednesday, November 10 at 1530-1730
===============================

CHAIRS: Allison Mankin <mankin@psg.com>
              Jon Peterson <jon.peterson@neustar.biz>

1530 Agenda bashing/Notetaker/Intro (chairs)

1540 RSVP Bandwidth reduction (Polk)
http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.tx
t

1555 Wide-Area Network (Baker)
http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled-preemptio
n-01.txt

1605 Diffserv Basic Classes (Chan)
http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.tx
t

1620 Quickstart (Jain/Floyd/Allman)
http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt

1635 RSVP Aggregation (Davie)
http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt

1650 XCP (Falk)
http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt

1705 SCTP NAT Traversal (Xie/Stewart/Holdrege)
http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt

1720 RSVP for MPLS-TE (Davie)
http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
--=====================_6376408==.ALT-- --===============1528579921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1528579921==-- From tsvwg-bounces@ietf.org Mon Nov 8 16:34:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04517; Mon, 8 Nov 2004 16:34:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHAm-0006Tx-B2; Mon, 08 Nov 2004 16:35:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGpk-0001nK-LW; Mon, 08 Nov 2004 16:13:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGc6-0003PO-Cn for tsvwg@megatron.ietf.org; Mon, 08 Nov 2004 15:59:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01125 for ; Mon, 8 Nov 2004 15:59:44 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGch-0005RY-Je for tsvwg@ietf.org; Mon, 08 Nov 2004 16:00:24 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2004 22:20:27 +0100 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA8Kx4vP016029; Mon, 8 Nov 2004 21:59:09 +0100 (MET) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Nov 2004 21:59:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Tsvwg] agenda Date: Mon, 8 Nov 2004 21:58:34 +0100 Message-ID: Thread-Topic: [Tsvwg] agenda Thread-Index: AcTF0THZbHNYbEt1SuiTvZIk43tH+QAA7obQ From: "Francois Le Faucheur \(flefauch\)" To: "Kwok Ho Chan" , "Peterson, Jon" X-OriginalArrivalTime: 08 Nov 2004 20:59:02.0855 (UTC) FILETIME=[C6E0E570:01C4C5D5] X-Spam-Score: 1.4 (+) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: tsvwg@ietf.org, mankin@psg.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0028369125==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 This is a multi-part message in MIME format. --===============0028369125== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5D5.BAFDBC6B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C5D5.BAFDBC6B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kwok,Jon, =20 The agenda should have a single item and read something like: =20 RSVP Aggregation over MPLS-TE: =20 http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt=20 =20 Thanks =20 Francois =20 =20 ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Kwok Ho Chan Sent: lundi 8 novembre 2004 20:51 To: Peterson, Jon Cc: 'tsvwg@ietf.org'; 'mankin@psg.com' Subject: Re: [Tsvwg] agenda =09 =09 Jon: Are the draft reference for the agenda items below correct? They are different versions of the same draft. =09 =09 1635 RSVP Aggregation (Davie)=20 =09 http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt=20 =09 1720 RSVP for MPLS-TE (Davie)=20 =09 http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt=20 Thanks! -- Kwok -- =09 At 10:40 AM 11/8/2004, Peterson, Jon wrote: =09 =09 The following is the agenda we're pursuing for Wednesday. As always, Allison=20 and I apologize that this is so tardy.=20 =09 Jon Peterson=20 NeuStar, Inc.=20 =09 -----=20 =09 Transport Area WG (tsvwg)=20 =09 Wednesday, November 10 at 1530-1730=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=20 =09 CHAIRS: Allison Mankin =20 Jon Peterson =20 =09 1530 Agenda bashing/Notetaker/Intro (chairs)=20 =09 1540 RSVP Bandwidth reduction (Polk)=20 =09 http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-0 0.tx=20 t=20 =09 1555 Wide-Area Network (Baker)=20 =09 http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled-preem ptio=20 n-01.txt=20 =09 1605 Diffserv Basic Classes (Chan)=20 =09 http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-0 4.tx=20 t=20 =09 1620 Quickstart (Jain/Floyd/Allman)=20 =09 http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt=20 =09 1635 RSVP Aggregation (Davie)=20 =09 http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt=20 =09 1650 XCP (Falk)=20 =09 http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt=20 =09 1705 SCTP NAT Traversal (Xie/Stewart/Holdrege)=20 =09 http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt=20 =09 1720 RSVP for MPLS-TE (Davie)=20 =09 http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt=20 =09 _______________________________________________=20 tsvwg mailing list=20 tsvwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/tsvwg=20 ------_=_NextPart_001_01C4C5D5.BAFDBC6B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Kwok,Jon,
 
The agenda should have a single item and read = something=20 like:
 
    RSVP Aggregation over=20 MPLS-TE:
     http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.t= xt
 
Thanks
 
Francois
 
 
From: tsvwg-bounces@ietf.org=20 [mailto:tsvwg-bounces@ietf.org] On Behalf Of Kwok Ho=20 Chan
Sent: lundi 8 novembre 2004 20:51
To: = Peterson,=20 Jon
Cc: 'tsvwg@ietf.org'; = 'mankin@psg.com'
Subject: Re:=20 [Tsvwg] agenda

Jon:
Are the draft reference for the agenda items below=20 correct?  They are different versions
of the same = draft.

1635 = RSVP=20 Aggregation (Davie)
http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt=20

1720 RSVP for MPLS-TE (Davie) =
http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.t= xt=20

Thanks!
-- Kwok --

At 10:40 AM 11/8/2004, = Peterson,=20 Jon wrote:

The = following is the=20 agenda we're pursuing for Wednesday. As always, Allison =
and I apologize that this is so tardy.

Jon Peterson
NeuStar, Inc. =

-----

Transport = Area WG=20 (tsvwg)

Wednesday, November 10 at=20 1530-1730
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=20

CHAIRS: Allison Mankin <mankin@psg.com> =
              Jon Peterson=20 <jon.peterson@neustar.biz>

1530 = Agenda=20 bashing/Notetaker/Intro (chairs)

1540 = RSVP=20 Bandwidth reduction (Polk)
http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw= -reduction-00.tx=20
t

1555 Wide-Area = Network=20 (Baker)
http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-si= gnaled-preemptio=20
n-01.txt

1605 = Diffserv Basic=20 Classes (Chan)
http://www.ietf.org/internet-drafts/draft-baker-diffserv-bas= ic-classes-04.tx=20
t

1620 Quickstart=20 (Jain/Floyd/Allman)
http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt=20

1635 RSVP Aggregation (Davie) =
http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt=20

1650 XCP (Falk)
h= ttp://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt =

1705 SCTP NAT Traversal = (Xie/Stewart/Holdrege)=20
http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt=20

1720 RSVP for MPLS-TE (Davie) =
http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.t= xt=20

_______________________________________________=20
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/tsvwg=20
------_=_NextPart_001_01C4C5D5.BAFDBC6B-- --===============0028369125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0028369125==-- From tsvwg-bounces@ietf.org Mon Nov 8 17:33:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10976; Mon, 8 Nov 2004 17:33:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRI5a-0008IP-4H; Mon, 08 Nov 2004 17:34:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHuf-0008Mm-HG; Mon, 08 Nov 2004 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHdv-0003nF-KD for tsvwg@megatron.ietf.org; Mon, 08 Nov 2004 17:05:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07844 for ; Mon, 8 Nov 2004 17:05:40 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHeX-0007RR-UJ for tsvwg@ietf.org; Mon, 08 Nov 2004 17:06:22 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA8M5B10006655; Mon, 8 Nov 2004 22:05:11 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Nov 2004 17:05:11 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4349@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Francois Le Faucheur (flefauch)'" , Kwok Ho Chan Subject: RE: [Tsvwg] agenda Date: Mon, 8 Nov 2004 17:05:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.4 (+) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Cc: tsvwg@ietf.org, mankin@psg.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1386123941==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: e06437eb72f6703f11713d345be8298a This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1386123941== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5DE.FE8E80A0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C5DE.FE8E80A0 Content-Type: text/plain; charset="ISO-8859-1" Right, thanks for pointing this out. I was using last time's agenda as a template, and I seem to have made a cut-and-paste error. That was supposed to be a slot for Wesley Eddy. I'll send an updated agenda. Jon Peterson NeuStar, Inc. -----Original Message----- From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: Monday, November 08, 2004 3:59 PM To: Kwok Ho Chan; Peterson, Jon Cc: tsvwg@ietf.org; mankin@psg.com; Francois Le Faucheur (flefauch) Subject: RE: [Tsvwg] agenda Hi Kwok,Jon, The agenda should have a single item and read something like: RSVP Aggregation over MPLS-TE: http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt Thanks Francois _____ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Kwok Ho Chan Sent: lundi 8 novembre 2004 20:51 To: Peterson, Jon Cc: 'tsvwg@ietf.org'; 'mankin@psg.com' Subject: Re: [Tsvwg] agenda Jon: Are the draft reference for the agenda items below correct? They are different versions of the same draft. 1635 RSVP Aggregation (Davie) http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt 1720 RSVP for MPLS-TE (Davie) http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt Thanks! -- Kwok -- At 10:40 AM 11/8/2004, Peterson, Jon wrote: The following is the agenda we're pursuing for Wednesday. As always, Allison and I apologize that this is so tardy. Jon Peterson NeuStar, Inc. ----- Transport Area WG (tsvwg) Wednesday, November 10 at 1530-1730 =============================== CHAIRS: Allison Mankin Jon Peterson 1530 Agenda bashing/Notetaker/Intro (chairs) 1540 RSVP Bandwidth reduction (Polk) http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.tx t 1555 Wide-Area Network (Baker) http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled-preemptio n-01.txt 1605 Diffserv Basic Classes (Chan) http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.tx t 1620 Quickstart (Jain/Floyd/Allman) http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt 1635 RSVP Aggregation (Davie) http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt 1650 XCP (Falk) http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt 1705 SCTP NAT Traversal (Xie/Stewart/Holdrege) http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt 1720 RSVP for MPLS-TE (Davie) http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ------_=_NextPart_001_01C4C5DE.FE8E80A0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Right,=20 thanks for pointing this out. I was using last time's agenda as a = template, and=20 I seem to have made a cut-and-paste error. That was supposed to be = a slot=20 for Wesley Eddy. I'll send an updated agenda.
 
Jon=20 Peterson
NeuStar, Inc.
-----Original Message-----
From: Francois Le = Faucheur=20 (flefauch) [mailto:flefauch@cisco.com]
Sent: Monday, = November 08,=20 2004 3:59 PM
To: Kwok Ho Chan; Peterson, Jon
Cc:=20 tsvwg@ietf.org; mankin@psg.com; Francois Le Faucheur=20 (flefauch)
Subject: RE: [Tsvwg] agenda

Hi Kwok,Jon,
 
The agenda should have a single item and = read=20 something like:
 
    RSVP Aggregation over=20 MPLS-TE:
     http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01= .txt
 
Thanks
 
Francois
 
 
From: tsvwg-bounces@ietf.org=20 [mailto:tsvwg-bounces@ietf.org] On Behalf Of Kwok Ho=20 Chan
Sent: lundi 8 novembre 2004 20:51
To: = Peterson,=20 Jon
Cc: 'tsvwg@ietf.org'; = 'mankin@psg.com'
Subject: Re:=20 [Tsvwg] agenda

Jon:
Are the draft reference for the agenda items = below=20 correct?  They are different versions
of the same = draft.

1635 RSVP=20 Aggregation (Davie)
http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt=20

1720 RSVP for MPLS-TE (Davie) =
http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01= .txt=20

Thanks!
-- Kwok --

At 10:40 AM = 11/8/2004,=20 Peterson, Jon wrote:

The = following is=20 the agenda we're pursuing for Wednesday. As always, = Allison=20
and I apologize that this is so tardy.=20

Jon Peterson
NeuStar,=20 Inc.

-----

Transport Area WG (tsvwg)

Wednesday,=20 November 10 at 1530-1730
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS:=20 Allison Mankin <mankin@psg.com>=20
              Jon Peterson=20 <jon.peterson@neustar.biz>

1530 Agenda=20 bashing/Notetaker/Intro (chairs)

1540 RSVP=20 Bandwidth reduction (Polk)
http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-= bw-reduction-00.tx=20
t

1555 Wide-Area = Network=20 (Baker)
http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-= signaled-preemptio=20
n-01.txt

1605 = Diffserv Basic=20 Classes (Chan)
http://www.ietf.org/internet-drafts/draft-baker-diffserv-b= asic-classes-04.tx=20
t

1620 = Quickstart=20 (Jain/Floyd/Allman)
http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt= =20

1635 RSVP Aggregation (Davie) =
http://ietfreport.isoc.org/ids/draft-lefaucheur-rsvp-dste-00.txt=20

1650 XCP (Falk)
= http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt=20

1705 SCTP NAT Traversal = (Xie/Stewart/Holdrege)=20
http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt= =20

1720 RSVP for MPLS-TE (Davie) =
http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01= .txt=20

_______________________________________________ =
tsvwg mailing list
tsvwg@ietf.org=20
https://www1.ietf.= org/mailman/listinfo/tsvwg=20
------_=_NextPart_001_01C4C5DE.FE8E80A0-- --===============1386123941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1386123941==-- From tsvwg-bounces@ietf.org Mon Nov 8 17:37:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11290; Mon, 8 Nov 2004 17:37:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRI9A-0008Ob-W3; Mon, 08 Nov 2004 17:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHuh-0008Nn-5T; Mon, 08 Nov 2004 17:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHet-00049K-GI for tsvwg@megatron.ietf.org; Mon, 08 Nov 2004 17:06:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07959 for ; Mon, 8 Nov 2004 17:06:40 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHfV-0007SP-1J for tsvwg@ietf.org; Mon, 08 Nov 2004 17:07:22 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA8M6B10006699 for ; Mon, 8 Nov 2004 22:06:11 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Nov 2004 17:06:11 -0500 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF434A@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Mon, 8 Nov 2004 17:06:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Tsvwg] updated agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Transport Area WG (tsvwg) Wednesday, November 10 at 1530-1730 =============================== CHAIRS: Allison Mankin Jon Peterson 1530 Agenda bashing/Notetaker/Intro (chairs) 1540 RSVP Bandwidth reduction (Polk) http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.tx t 1555 Wide-Area Network (Baker) http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled-preemptio n-01.txt 1605 Diffserv Basic Classes (Chan) http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.tx t 1620 Quickstart (Jain/Floyd/Allman) http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt 1635 Transport Mobility (Eddy) http://www.ietf.org/internet-drafts/draft-eddy-tlmarch-00.txt 1650 XCP (Falk) http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt 1705 SCTP NAT Traversal (Xie/Stewart/Holdrege) http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt 1720 RSVP for MPLS-TE (Davie) http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 8 21:04:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02240; Mon, 8 Nov 2004 21:04:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRLNc-0005BJ-PJ; Mon, 08 Nov 2004 21:05:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRLCr-00022k-1X; Mon, 08 Nov 2004 20:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRLA2-000179-0W for tsvwg@megatron.ietf.org; Mon, 08 Nov 2004 20:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00679 for ; Mon, 8 Nov 2004 20:51:04 -0500 (EST) From: Mpierce1@aol.com Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRLAg-0004pR-FI for tsvwg@ietf.org; Mon, 08 Nov 2004 20:51:46 -0500 Received: from Mpierce1@aol.com by imo-d22.mx.aol.com (mail_out_v37_r3.8.) id r.1e4.2dbe56d7 (18707); Mon, 8 Nov 2004 20:50:28 -0500 (EST) Message-ID: <1e4.2dbe56d7.2ec17c64@aol.com> Date: Mon, 8 Nov 2004 20:50:28 EST Subject: Re: [Tsvwg] draft-pierce-tsvwg-assured-service-req-01.txt and -arch-01.txt To: brc@zurich.ibm.com, tsvwg@ietf.org, pierce1m@disa.mil MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0275440749==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc --===============0275440749== Content-Type: multipart/alternative; boundary="part1_1e4.2dbe56d7.2ec17c64_boundary" --part1_1e4.2dbe56d7.2ec17c64_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/8/2004 2:43:39 PM Eastern Standard Time, brc@zurich.ibm.com writes: draft-pierce-tsvwg-assured-service-req-01.txt: Firstly, as I think I've said before, using the word "assured" is very confusing, since "assured forwarding" is a term of art in diffserv with a specific and different meaning. {MAP] Yes, I understand the potential for confusion, but we can't avoid using good English words just because they were used in some other context or term. "Assured Forwarding" and "Assured Service" are two different terms, and, as long as they are always used in those ways, there should be no problem. If needed, I can add a note that "Assured Service" is not another name for "Assured Forwarding". ------------------------------------------------------------------------------ --------------------------------- > 0. History > > Note: This section will be deleted before progressing as an RFC. > > This document has evolved through 3 different working groups: > SIPPING, IEPREP, and TSVWG. This draft was originally submitted > under SIPPING with 2 revisions and then in the IEPREP WG in order to > ensure that the Assured Service requirements are considered along > with those of the related IEPS discussions. It is not being > submitted in TSVWG. That "not" is a very confusing nit :-) [MAP] That was an unfortunate typo. It should say "now being submitted". ------------------------------------------------------------------------------ ---------------- > 3. High Level Requirements ... > ...For example, the > lower precedence calls may temporarily experience reduced quality as > their packets are discarded. As Fred Baker's critique of the MLEF proposal has pointed out, this is probably not acceptable, for reasons he explained in detail. [MAP] Yes, that certainly may be true in many networks, but it can be a perfectly acceptable mechanism in other networks such as a DSN (which is intended as the purpose of this draft). Maybe I left it a little open about this draft possibly applying to other networks. I need to make it clear that the requirements apply to the specific network of the DOD. ------------------------------------------------------------------------------ ---------------- > 4.3.1. Call Treatment ... > Pref-6 Preferential treatment SHOULD NOT be provided through any > scheme of dedicated or pre-reserved bandwidth or resources. That's an implementation issue, and I think it is out of place in a functional requirements document. [MAP] Again, this draft is intended to address a specific network in which it is felt that this is the requirement. A different network may choose to not have this requirement. -------------------------------------------------------------------------- draft-pierce-tsvwg-assured-service-arch-01.txt: > 3. Required Architecture > > In order to provide the security and feature control required for > Assured Service as defined in [Pierce1], it is necessary to utilize > the Service Provider Network Architecture in which proxies are used ... I'm unclear why this is *required* or *necessary*. I would have thought it was "recommended" or "proposed" or "appropriate" or even "sufficient." [MAP] After a lot of discussion on how to acheive security, it is concluded that the network that this draft is designed to address "must" use this architecture. Other networks may not require this. ------------------------------------------------------------------------------ ------ ... > There must be an edge router, as described in [RFC 2998] and RFC > [3313], generally at the boundary between the local network and the > core network. I don't see why your primary reference here is to 2998. The primary references are probably RFC 2474 and 2475, where the boxes in question are called "DS boundary nodes." 2998 builds on this for the specific case of interworking with RSVP and Integrated Services, which you don't discuss at all. [MAP] I'll look at these. They may be better references for this device. I suspect we're really talking about a device that performs both functions. ------------------------------------------------------------------------------ ------- > 4.3. Function of the Edge Router > > The edge router serves the functions of ingress router and egress > router referred to in various RFCs. "Edge Router" is described in > RFCs [2998], [3313], and [3521]. Same comment. ------------------------------------------------------------------------------ ------- Thanks for the comments. Mike --part1_1e4.2dbe56d7.2ec17c64_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/8/2004 2:43:39 PM Eastern Standard Time, brc@zurich.ibm.com writes:


draft-pierce-tsvwg-assured-service-req-01.txt:

Firstly, as I think I've said before, using the word "assured"
is very confusing, since "assured forwarding" is a term of art
in diffserv with a specific and different meaning.


{MAP] Yes, I understand the potential for confusion, but we can't avoid=20= using good English words just because they were used in some other context o= r term. "Assured Forwarding" and "Assured Service" are two different terms,=20= and, as long as they are always used in those ways, there should be no probl= em. If needed, I can add a note that "Assured Service" is not another name f= or "Assured Forwarding".

------------------------------------------------------------------------= ---------------------------------------

> 0.   History=20
>     
>    Note: This section will be deleted before progres= sing as an RFC.=20
>     
>    This document has evolved through 3 different wor= king groups:=20
>    SIPPING, IEPREP, and TSVWG. This draft was origin= ally submitted=20
>    under SIPPING with 2 revisions and then in the IE= PREP WG in order to=20
>    ensure that the Assured Service requirements are=20= considered along=20
>    with those of the related IEPS discussions. It is= not being=20
>    submitted in TSVWG.

That "not" is a very confusing nit :-)

[MAP] That was an unfortunate typo. It should say "now being submitted".

------------------------------------------------------------------------= ----------------------
> 3.   High Level Requirements
...
>    ...For example, the=20
>    lower precedence calls may temporarily experience= reduced quality as=20
>    their packets are discarded.=20

As Fred Baker's critique of the MLEF proposal has pointed out,
this is probably not acceptable, for reasons he explained in detail.


[MAP]=20
Yes, that certainly may be true in many networks, but it can be a perfec= tly acceptable mechanism in other networks such as a DSN (which is intended=20= as the purpose of this draft). Maybe I left it a little open about this draf= t possibly applying to other networks. I need to make it clear that the requ= irements apply to the specific network of the DOD.
------------------------------------------------------------------------= ----------------------

> 4.3.1.  Call Treatment
...
>    Pref-6  Preferential treatment SHOULD NOT be= provided through any=20
>            s= cheme of dedicated or pre-reserved bandwidth or resources.=20

That's an implementation issue, and I think it is out of place in
a functional requirements document.



[MAP] Again, this draft is intended to address a specific network in whi= ch it is felt that this is the requirement. A different network may choose t= o not have this requirement.

------------------------------------------------------------------------= --
draft-pierce-tsvwg-assured-service-arch-01.txt:

> 3.   Required Architecture=20
>     
>    In order to provide the security and feature cont= rol required for=20
>    Assured Service as defined in [Pierce1], it is ne= cessary to utilize=20
>    the Service Provider Network Architecture in whic= h proxies are used=20
...

I'm unclear why this is *required* or *necessary*. I would have thought
it was "recommended" or "proposed" or "appropriate" or even "sufficient.= "


[MAP] After a lot of discussion on how to acheive security, it is conclu= ded that the network that this draft is designed to address
"must" use this architecture. Other networks may not require this.


------------------------------------------------------------------------= ------------
...
>    There must be an edge router, as described in [RF= C 2998] and RFC=20
>    [3313], generally at the boundary between the loc= al network and the=20
>    core network.

I don't see why your primary reference here is to 2998. The primary
references are probably RFC 2474 and 2475, where the boxes in question a= re
called "DS boundary nodes." 2998 builds on this for the specific case
of interworking with RSVP and Integrated Services, which you don't discu= ss
at all.


[MAP] I'll look at these. They may be better references for this device.= I suspect we're really talking about a device that performs both functions.

------------------------------------------------------------------------= -------------
> 4.3. Function of the Edge Router=20
>     
>    The edge router serves the functions of ingress r= outer and egress=20
>    router referred to in various RFCs. "Edge Router"= is described in=20
>    RFCs [2998], [3313], and [3521].=20

Same comment.

------------------------------------------------------------------------= -------------

Thanks for the comments.

Mike
--part1_1e4.2dbe56d7.2ec17c64_boundary-- --===============0275440749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0275440749==-- From tsvwg-bounces@ietf.org Tue Nov 9 15:04:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06721; Tue, 9 Nov 2004 15:04:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRcEz-00058r-Jl; Tue, 09 Nov 2004 15:05:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRcAE-0000Gn-RL; Tue, 09 Nov 2004 15:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRc3H-0005yA-PN for tsvwg@megatron.ietf.org; Tue, 09 Nov 2004 14:53:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05385 for ; Tue, 9 Nov 2004 14:53:13 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRc43-0004o3-0Z for tsvwg@ietf.org; Tue, 09 Nov 2004 14:54:06 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.8) with ESMTP id iA9JrAUw041916; Tue, 9 Nov 2004 11:53:10 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200411091953.iA9JrAUw041916@cougar.icir.org> To: tsvwg@ietf.org From: Sally Floyd Date: Tue, 09 Nov 2004 11:53:10 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Aaron Falk , kohler@icir.org Subject: [Tsvwg] VoIP mode for TFRC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 This is a heads-up that I am working on a new internet-draft about a variant on TFRC, the VoIP variant. The draft has not yet been finished or submitted, but I have posted a copy at: http://www.icir.org/floyd/papers/draft-ietf-dccp-tfrc-voip-00a.txt TFRC was standardized through tsvwg, and it is not clear if this should go through tsvwg or dccp. However, this is to let tsvwg know that this document will be discussed briefly in dccp tomorrow morning, at the end of the morning session. Regards, - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 9 17:07:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19232; Tue, 9 Nov 2004 17:07:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRe9l-0008A5-GT; Tue, 09 Nov 2004 17:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdyB-0003Y6-7T; Tue, 09 Nov 2004 16:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdvr-0002MW-Na for tsvwg@megatron.ietf.org; Tue, 09 Nov 2004 16:53:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17616 for ; Tue, 9 Nov 2004 16:53:41 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdwg-0007kh-I2 for tsvwg@ietf.org; Tue, 09 Nov 2004 16:54:35 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2004 23:14:45 +0100 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA9Lr4vP016043; Tue, 9 Nov 2004 22:53:08 +0100 (MET) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Nov 2004 22:53:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2004 22:43:15 +0100 Message-ID: Thread-Topic: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt Thread-Index: AcTGfXpIKwGRZ2xVRkm11TEb9Hra+AAJtg8Q From: "Francois Le Faucheur \(flefauch\)" To: "John Drake" X-OriginalArrivalTime: 09 Nov 2004 21:53:02.0116 (UTC) FILETIME=[7C0AA640:01C4C6A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: [Tsvwg] FW: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Content-Transfer-Encoding: quoted-printable Hi John, As discussed today, we will bring the next revision of draft-lefaucheur-rsvp-dste in closer alignment with "LSP Hierarchy" draft. In particular, the IF_ID RSVP_HOP object will be used as per "LSP Hierarchy". I think we could also even go for out of band signaling (also as per "LSP Hierarchy"), then we would probably want to do the "checks" to confirm proper out-of-band signaling. Thanks again for your comments. Francois >> -----Original Message----- >> From: John Drake [mailto:jdrake@calient.net]=20 >> Sent: mardi 9 novembre 2004 17:59 >> To: John Drake; Francois Le Faucheur (flefauch) >> Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch) >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt >>=20 >> Francois, >>=20 >> I just checked the hierarchy I-D and the two checks you=20 >> mentioned are for >> the out-of-band case. I.e., you want to check that the far=20 >> end of the FA >> LSP is associated with the node that sent you the Path message. >>=20 >> You could probably state in your I-D that for this check=20 >> isn't necessary for >> the in-band case. I don't know if you should mention that a=20 >> node should >> check the FA LSP specified in the IF_ID is the same as the=20 >> LSP in which the >> Path message was received. >>=20 >> Thanks, >>=20 >> John=20 >>=20 >> > > >> -----Original Message----- >> > > >> From: John Drake [mailto:jdrake@calient.net] >> > > >> Sent: lundi 18 octobre 2004 18:20 >> > > >> To: Francois Le Faucheur (flefauch) >> > > >> Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch); >> > > >> Carol Iturralde (cei) >> > > >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt >> > > >> >> > > >> Francois, >> > > >> >> > > >> The issue may be a simple as the fact that you don't make it >> > > >> clear that you >> > > >> are using LSP hierarchy as a base and that you don't >> > > >> explicitly detail what >> > > >> the differences are. This makes your I-D read as though it >> > > >> is proposing >> > > >> something different. >> > > >> >> > > >> I would suggest that you include a normative reference to >> > > >> the LSP hierarchy >> > > >> I-D and indicate that its signaling procedures are to be >> > > >> used; in particular >> > > >> that the FA LSP is identified using the IF_ID RSVP_HOP. (I >> > > >> think it would >> > > >> also help if you used its terminology.) >> > > >> >> > > >> Comments inline. >> > > >> >> > > >> Thanks, >> > > >> >> > > >> John >> > > >> >> > > >> > -----Original Message----- >> > > >> > From: Francois Le Faucheur (flefauch)=20 >> [mailto:flefauch@cisco.com] >> > > >> > Sent: Monday, October 18, 2004 8:27 AM >> > > >> > To: John Drake >> > > >> > Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch); >> > > >> Carol Iturralde >> > > >> > (cei) >> > > >> > Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt >> > > >> > >> > > >> > Hi John, >> > > >> > >> > > >> > Thanks for checking the document. >> > > >> [John Drake] >> > > >> >> > > >> You're welcome. >> > > >> >> > > >> > >> > > >> > >> -----Original Message----- >> > > >> > >> From: John Drake [mailto:jdrake@calient.net] >> > > >> > >> Sent: vendredi 15 octobre 2004 18:02 >> > > >> > >> To: Francois Le Faucheur (flefauch) >> > > >> > >> Cc: Francois Le Faucheur (flefauch); Bruce Davie (bdavie) >> > > >> > >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt >> > > >> > >> >> > > >> > >> Francois, >> > > >> > >> >> > > >> > >> Is there a reason why you couldn't re-use the signaling >> > > >> > >> procedures of the >> > > >> > >> LSP hierarchy I-D? >> > > >> > >> > > >> > This is what we have tried to do. >> > > >> > The LSP hierarchy draft does specify a number of ways to >> > > >> signal from >> > > >> > Aggregate Head to Aggregate Tail. In particular, it >> > > >> discusses one option >> > > >> > that is required for non-packet-capable optical boxes >> > > >> (RSVP out of band) >> > > >> > and one option which can be used for packet-capable boxes >> > > >> (encpasulate >> > > >> > inside tunnel). We use the latter option. >> > > >> [John Drake] >> > > >> >> > > >> That's fine, but it does stipulate that in all cases=20 >> the FA LSP is >> > > >> identified with the IF_ID RSVP_HOP. >> > > >> >> > > >> > >> > > >> > As I said, one necessary difference comes from the fact >> > > >> that RSVP uses >> > > >> > final destination while RSVP-TE uses ERO. But as you say >> > > >> below, that >> > > >> > doesn't affect things once it is encapsulated. >> > > >> > >> > > >> > >>If the Path message is tunneled from head-end to >> > > >> > >> tail-end, as described in LSP hierarchy I-D, it doesn't >> > > >> > >> matter what is in >> > > >> > >> the destination address field of tunneled IP packet. >> > > >> > >> Also, >> > > >> > >> in checking with >> > > >> > >> Lou Berger, it seems that all RSVP-TE=20 >> implementations place >> > > >> > >> the next hop >> > > >> > >> address in the destination address field. >> > > >> > >> > > >> > Agreed. >> > > >> > Which is why we see a small difference in how to handle >> > > >> aggregation of >> > > >> > end-to-end RSVP from that viewpoint. >> > > >> > >> > > >> > >> >> > > >> > >> It seems to me that having multiple ways of doing the >> > > >> same thing is >> > > >> > >> counter-productive. >> > > >> > >> Also, in section 5, you seem to be recommending that your >> > > >> > >> procedures, rather >> > > >> > >> than the procedures of the LSP hierarchy I-D, be used for >> > > >> > >> LSP hierarchy. >> > > >> > >> > > >> > We are not trying to introduce any change over LSP >> > > >> hierarchy. Again, we >> > > >> > think the behavior is in line with LSP hiererachy=20 >> draft wherever >> > > >> > possible and only differs for what is specific to RSVP >> > > >> end-to-end flows. >> > > >> > Please let us know if you see specific aspects which would >> > > >> be departing >> > > >> > from LSP hierarchy and which could be brought back in line. >> > > >> > >> > > >> > Thanks >> > > >> > >> > > >> > Francois >> > > >> > >> > > >> > >> > > >> > >> >> > > >> > >> Thanks, >> > > >> > >> >> > > >> > >> John >> > > >> > >> >> > > >> > >> > -----Original Message----- >> > > >> > >> > From: Francois Le Faucheur (flefauch) >> > > >> [mailto:flefauch@cisco.com] >> > > >> > >> > Sent: Friday, October 15, 2004 3:31 AM >> > > >> > >> > To: John Drake >> > > >> > >> > Cc: Francois Le Faucheur (flefauch); Bruce=20 >> Davie (bdavie) >> > > >> > >> > Subject: RE: I-D=20 >> ACTION:draft-lefaucheur-rsvp-dste-01.txt >> > > >> > >> > >> > > >> > >> > Hi John, >> > > >> > >> > >> > > >> > >> > Thanks for the note. Yes, we are aware of that draft >> > > >> and also see a >> > > >> > >> > number of commonalities. In fact, in section=20 >> 5, we point >> > > >> > >> out that one of >> > > >> > >> > the applicable scenario is the one where the end-to-end >> > > >> > >> reservations are >> > > >> > >> > RSVP-TE tunnel reservations as per lsp-hiererachy. >> > > >> > >> > However, the prime focus of the rsvp-dste draft is, >> > > >> of course, the >> > > >> > >> > aggregation of regular RSVP reservations and its >> > > >> > >> applicablity to CAC for >> > > >> > >> > voice. One of the related aspect is that RSVP-TE >> > > >> > >> reservations use ERO >> > > >> > >> > while regular RSVP Path uses final destination=20 >> addresses. >> > > >> > >> This makes it >> > > >> > >> > much more natural with regular RSVP to encapuslate the >> > > >> > >> Path inside the >> > > >> > >> > tunnel, than with lsp-hiererachy where Path message >> > > >> can be forwrded >> > > >> > >> > out-of-band to the Tunnel tail. >> > > >> > >> > >> > > >> > >> > Looking forward to hearing more comments >> > > >> > >> > >> > > >> > >> > Francois >> > > >> > >> > >> > > >> > >> > >> -----Original Message----- >> > > >> > >> > >> From: John Drake [mailto:jdrake@calient.net] >> > > >> > >> > >> Sent: jeudi 14 octobre 2004 23:05 >> > > >> > >> > >> To: Francois Le Faucheur (flefauch) >> > > >> > >> > >> Subject: FW: I-D=20 >> ACTION:draft-lefaucheur-rsvp-dste-01.txt >> > > >> > >> > >> >> > > >> > >> > >> Francois, >> > > >> > >> > >> >> > > >> > >> > >> Are you aware of the following I-D: >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hiera >> > > >> > >> > >> rchy-08.txt >> > > >> > >> > >> >> > > >> > >> > >> I think there's a fair amount of overlap between >> > > >> it and your >> > > >> > >> > >> draft, below, >> > > >> > >> > >> which I just skimmed. (And which I'll read=20 >> more thoroughly >> > > >> > >> > >> later this >> > > >> > >> > >> week.) >> > > >> > >> > >> >> > > >> > >> > >> Thanks, >> > > >> > >> > >> >> > > >> > >> > >> John >> > > >> > >> > >> >> > > >> > >> > >> -----Original Message----- >> > > >> > >> > >> From: Internet-Drafts@ietf.org >> > > >> [mailto:Internet-Drafts@ietf.org] >> > > >> > >> > >> Sent: Thursday, October 14, 2004 1:18 PM >> > > >> > >> > >> To: i-d-announce@ietf.org >> > > >> > >> > >> Subject: I-D=20 >> ACTION:draft-lefaucheur-rsvp-dste-01.txt >> > > >> > >> > >> >> > > >> > >> > >> A New Internet-Draft is available from the on-line >> > > >> > >> Internet-Drafts >> > > >> > >> > >> directories. >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> > >> > >> Title : Aggregation of RSVP >> > > >> > >> Reservations over MPLS >> > > >> > >> > >> TE/DS-TE >> > > >> > >> > >> Tunnels >> > > >> > >> > >> Author(s) : F. Le Faucheur, et al. >> > > >> > >> > >> Filename :=20 >> draft-lefaucheur-rsvp-dste-01.txt >> > > >> > >> > >> Pages : 18 >> > > >> > >> > >> Date : 2004-10-14 >> > > >> > >> > >> >> > > >> > >> > >> This document provides specification for=20 >> aggregation of >> > > >> > >> RSVP end-to- >> > > >> > >> > >> end reservations over MPLS Traffic=20 >> Engineering (TE) >> > > >> > >> > >> tunnels or MPLS >> > > >> > >> > >> Diffserv-aware MPLS Traffic Engineering (DS-TE) >> > > >> Tunnels. This >> > > >> > >> > >> approach is based on RFC 3175 and simply=20 >> modifies the >> > > >> > >> > >> corresponding >> > > >> > >> > >> procedures for operations over MPLS TE tunnels >> > > >> instead of >> > > >> > >> > >> aggregated >> > > >> > >> > >> RSVP reservations. This approach can be used to >> > > >> > >> achieve admission >> > > >> > >> > >> control of a very large number of flows=20 >> in a scalable >> > > >> > >> > >> manner since >> > > >> > >> > >> the devices in the core of the network are >> > > >> unaware of the >> > > >> > >> > >> end-to-end >> > > >> > >> > >> RSVP reservations and are only aware of the >> > > >> MPLS TE tunnels. >> > > >> > >> > >> >> > > >> > >> > >> A URL for this Internet-Draft is: >> > > >> > >> > >> >> > > >> > >> >> > > >>=20 >> http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt >> > > >> > >> > >> >> > > >> > >> > >> To remove yourself from the I-D=20 >> Announcement list, send >> > > >> > >> a message to >> > > >> > >> > >> i-d-announce-request@ietf.org with the word=20 >> unsubscribe in >> > > >> > >> > >> the body of the >> > > >> > >> > >> message. >> > > >> > >> > >> You can also visit >> > > >> > >> > >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> > > >> > >> > >> to change your subscription settings. >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> > >> > >> Internet-Drafts are also available by=20 >> anonymous FTP. Login >> > > >> > >> > >> with the username >> > > >> > >> > >> "anonymous" and a password of your e-mail address. >> > > >> > >> After logging in, >> > > >> > >> > >> type "cd internet-drafts" and then >> > > >> > >> > >> "get draft-lefaucheur-rsvp-dste-01.txt". >> > > >> > >> > >> >> > > >> > >> > >> A list of Internet-Drafts directories can=20 >> be found in >> > > >> > >> > >> http://www.ietf.org/shadow.html >> > > >> > >> > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> > >> > >> Internet-Drafts can also be obtained by e-mail. >> > > >> > >> > >> >> > > >> > >> > >> Send a message to: >> > > >> > >> > >> mailserv@ietf.org. >> > > >> > >> > >> In the body type: >> > > >> > >> > >> "FILE >> > > >> > >> /internet-drafts/draft-lefaucheur-rsvp-dste-01.txt". >> > > >> > >> > >> >> > > >> > >> > >> NOTE: The mail server at ietf.org can return >> > > >> the document in >> > > >> > >> > >> MIME-encoded form by using the "mpack" utility. >> > > >> > >> To use this >> > > >> > >> > >> feature, insert the command "ENCODING mime" >> > > >> > >> before the "FILE" >> > > >> > >> > >> command. To decode the response(s), you will >> > > >> > >> need "munpack" or >> > > >> > >> > >> a MIME-compliant mail reader. Different >> MIME-compliant >> > > >> > >> > >> mail readers >> > > >> > >> > >> exhibit different behavior, especially=20 >> when dealing >> with >> > > >> > >> > >> "multipart" MIME messages (i.e. documents which >> > > >> > >> have been split >> > > >> > >> > >> up into multiple messages), so check your local >> > > >> > >> documentation on >> > > >> > >> > >> how to manipulate these messages. >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> > >> > >> Below is the data which will enable a MIME >> > > >> compliant mail reader >> > > >> > >> > >> implementation to automatically retrieve the ASCII >> > > >> > >> version of the >> > > >> > >> > >> Internet-Draft. >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> ------------------------------------------------------------- >> > > >> > >> > >> ------------ >> > > >> > >> > >> In order to maintain computing=20 >> infrastructure integrity, >> > > >> > >> > >> Cisco Systems >> > > >> > >> > >> Enterprise Messaging Services and InfoSec=20 >> teams have set a >> > > >> > >> > >> mail policy >> > > >> > >> > >> disallowing executable attachments in email. >> > > >> > >> > >> >> > > >> > >> > >> This message contained an executable attachment >> > > >> type that is >> > > >> > >> > >> prohibited >> > > >> > >> > >> by this policy. The attachment has been=20 >> removed from this >> > > >> > >> > >> message and >> > > >> > >> > >> copied to quarantine by our systems. It=20 >> will be held in >> > > >> > >> > >> quarantine for >> > > >> > >> > >> seven days in the event that the content needs to >> > > >> be retrieved. >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> ------------------------------------------------------------- >> > > >> > >> > >> ------------ >> > > >> > >> > >> For further reference information about viruses and >> > > >> > >> email antivirus >> > > >> > >> > >> efforts within Cisco, please visit: >> > > >> > >> > >> >> > > >> > >> > >> http://wwwin.cisco.com/it/ems/services/antiviral >> > > >> > >> > >> >> > > >> > >> > >> >> > > >> > >> > >> If your concern isn't addressed by the=20 >> information in this >> > > >> > >> > >> notification >> > > >> > >> > >> or the above web page, you may open a=20 >> support request: >> > > >> > >> > >> >> > > >> > >> > >> http://wwwin.cisco.com/support/ >> > > >> > >> > >> >> > > >> > >> > >> Select "Messaging", "Email-Related", "Mail Routing" >> > > >> > >> > >> >> > > >> > >> > >> Please include in the text of your case the=20 >> following >> > > >> > >> information: >> > > >> > >> > >> >> > > >> > >> > >> * Full headers of the message. Documentation on >> > > >> > >> displaying the full >> > > >> > >> > >> headers is available at this URL: >> > > >> > >> > >> >> > > >> > >> > >> >> > > >>=20 >> http://wwwin.cisco.com/support/library/faqs/solution002471.html >> > > >> > >> > >> >> > > >> > >> > >> * This unique quarantine identifier: i9EL4Ew8014772 >> > > >> > >> > >> >> > > >> > >> > >> If the matter is urgent, you may follow up by >> > > >> calling one of >> > > >> > >> > >> the below >> > > >> > >> > >> referenced numbers. Please make every=20 >> effort to provide >> > > >> > >> the above >> > > >> > >> > >> requested information via the support web=20 >> tool prior to >> > > >> > >> > >> calling as it >> > > >> > >> > >> will greatly aid the resolution of your issue. >> > > >> > >> > >> >> > > >> > >> > >> Americas: >> > > >> > >> > >> 1 408 526 8888 >> > > >> > >> > >> >> > > >> > >> > >> Asiapac >> > > >> > >> > >> +61 2 8446 8888 >> > > >> > >> > >> >> > > >> > >> > >> EMEA >> > > >> > >> > >> +31 20 485 4888 >> > > >> > >> > >> >> > > >> > >> > >> Japan >> > > >> > >> > >> +81 3 5549 6888 >> > > >> > >> > >> >> > > >> > >> > >> US (Toll Free) >> > > >> > >> > >> 1| 800| 888| 8187| (ext.68888) >> > > >> > >> > >> >> > > >> > >> > >> Thank you for your cooperation, >> > > >> > >> > >> >> > > >> > >> > >> Enterprise Messaging Services >> > > >> > >> > >> Cisco Systems, Inc >> > > >> > >> > >> >> > > >> > >> >> > > >> >>=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 10 11:13:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25311; Wed, 10 Nov 2004 11:13:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRv6j-00069m-BJ; Wed, 10 Nov 2004 11:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuvp-0003Is-G8; Wed, 10 Nov 2004 11:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRumg-0000la-Ie for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 10:53:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23049 for ; Wed, 10 Nov 2004 10:53:19 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRund-0005ZY-1D for tsvwg@ietf.org; Wed, 10 Nov 2004 10:54:23 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAAFqka25706; Wed, 10 Nov 2004 10:52:46 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 10:52:46 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465020BA4A9@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: Brian E Carpenter , Fred Baker , "Kwok-Ho Chan" Date: Wed, 10 Nov 2004 10:52:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: tsvwg@ietf.org, David Black Subject: [Tsvwg] RE: draft-baker-diffserv-basic-classes-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986383015==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1986383015== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C73D.4B96842B" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C73D.4B96842B Content-Type: text/plain Thanks Brian for the additional comments, see answers below. ************************ Hi, I find more to comment in this draft each time I look at it. Maybe it's getting longer each time... > The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in [RFC2119]. It's very strange to find this in the Abstract, not the Introduction. [Joe] Moved to Introduction. > 1.2 Service Class Definition > > > A "service class" represents a set of traffic that requires specific > delay, loss and jitter characteristics from the network for which a > consistent and defined per-hop behavior (PHB) [RFC2475] applies. The Proposed Standard is RFC2474 and that should surely be the primary normative reference; 2475 is Informational. [Joe] Will change (PHB) reference to [RFC2474] Also, this section still lacks any reference to the PDB document and any explanation of the relationship between Service Class and PDB. I suspect it is something like this: A Service Class as defined here is essentially a statement of the required characteristics of a traffic aggregate; the actual specification of the expected treatment of a traffic aggregate within a domain is defined as a Per Domain Behavior [RFC3086]. You need this, since you later refer to a PDB [RFC3662]. [Joe] OK, will add a reference to PDB in section 1.2 as requested. > 1.3 Key Differentiated Services Concepts > > > The reader SHOULD be familiar with the principles of the > Differentiated Services Architecture [RFC2475]. However, we > recapitulate key concepts here to save searching. Again, the normative reference is [RFC2474]. [Joe] Will change to [RFC2474] and [RFC2475] > 1.4.1 Default Forwarding (DF) > > > The basic forwarding behavior applied to any class of traffic are > those described in [RFC2475] and [RFC2309]. And again. [Joe] Will replace RFC2475 with RFC2474. > 4.3 Multimedia Conferencing Service Class ... > > RECOMMENDED DSCP marking: > o Video conferencing packets are marked with AF4x > o VPN service may be marked with AF4x, depending on the service > characteristics > o Server to server data transfer with AF4x, depending on the service > characteristics It makes no sense to suddenly mention VPNs and server2server data transfer here. Either this is the multimedia conferencing service class, or it isn't. If you think this service class also contains VPN and server2server traffic, that needs stating up front. [Joe]Will remove the above text. The name for the service class "Multimedia Conferencing" was chosen because many currently deployed rate adaptive multimedia conferencing solutions are configured this way. Other applications may use this service class as well, if the characteristics and performance requirements of this service class are appropriate. > 5.3 Explanation of Ring Clipping If we allowed such things in RFCs, this would be a footnote. I think this should either be a subsection 4.2.1, or at least it should contain a reference back to 4.2. [Joe] Will move it to Appendix and provide reference back to 4.2. This is a problem that needs to be address in real networks as interworking with Public Switched Telephony Network (PSTN) is needed. It uses jargon and acronyms unknown in the IETF (Tandem Office??? ISUP??) and English errors. [Joe] Will explain the acronyms and fix any English errors. > 5.4 VPN Service Mapping You don't refer to RFC 2983 (Differentiated Services and Tunnels), and I'm not sure you are consistent with it. You should certainly indicate which of the conceptual models in 2983 you are suggesting. And of course if it's an IPSec VPN, IPSec specifies certain rules that you have to follow. [Joe] This section will be moved to the Appendix and will add reference to RFC 2983. In this draft we are not address all the different options for VPNs and what the QoS guidelines should to be. As stated in the draft further study is required. Brian Regards, Joe. Jozef Babiarz email: babiarz@nortelnetworks.com ------_=_NextPart_001_01C4C73D.4B96842B Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-baker-diffserv-basic-classes-04

Thanks Brian for the additional comments, see answers = below.
************************
Hi,
 
I find more to comment in this draft each time I = look at it. Maybe it's getting longer each time...

>    The key words = "SHOULD", "SHOULD NOT", "REQUIRED", = "SHALL", "SHALL
>    NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in
>    this document are to be = interpreted as described in [RFC2119].

It's very strange to find this in the Abstract, not = the Introduction.
[Joe] Moved to Introduction.

> 1.2  Service Class Definition
>
>
>    A "service class" = represents a set of traffic that requires specific
>    delay, loss and jitter = characteristics from the network for which a
>    consistent and defined = per-hop behavior (PHB) [RFC2475] applies.

The Proposed Standard is RFC2474 and that should = surely be the primary normative reference; 2475 is = Informational.
[Joe] Will change (PHB) reference to = [RFC2474]
 
Also, this section still lacks any reference to the = PDB document and any explanation of the relationship between Service = Class and PDB.

I suspect it is something like this:

   A Service Class as defined here is = essentially a statement of
   the required characteristics of a = traffic aggregate; the actual
   specification of the expected treatment = of a traffic aggregate
   within a domain is defined as a Per = Domain Behavior [RFC3086].
You need this, since you later refer to a PDB = [RFC3662].
[Joe] OK, will add a reference to PDB in section 1.2 = as requested.

> 1.3  Key Differentiated Services = Concepts
>
>
>    The reader SHOULD be familiar = with the principles of the
>    Differentiated Services = Architecture [RFC2475].  However, we
>    recapitulate key concepts = here to save searching.

Again, the normative reference is [RFC2474].
[Joe] Will change to [RFC2474] and [RFC2475]
 
> 1.4.1  Default Forwarding (DF)
>
>
>    The basic forwarding behavior = applied to any class of traffic are
>    those described in [RFC2475] = and [RFC2309].

And again.
[Joe] Will replace RFC2475 with RFC2474.

> 4.3  Multimedia Conferencing Service = Class
...
>
>    RECOMMENDED DSCP = marking:
>    o  Video conferencing = packets are marked with AF4x
>    o  VPN service may be = marked with AF4x, depending on the service
>       = characteristics
>    o  Server to server data = transfer with AF4x, depending on the service
>       = characteristics

It makes no sense to suddenly mention VPNs and = server2server data transfer here. Either this is the multimedia = conferencing service class, or it isn't. If you think this service = class also contains VPN and server2server traffic, that needs stating = up front.

[Joe]Will remove the above text.
The name for the service class "Multimedia = Conferencing" was chosen because many currently deployed rate adaptive = multimedia conferencing solutions are configured this way. Other = applications may use this service class as well, if the characteristics = and performance requirements of this service class are = appropriate.

> 5.3  Explanation of Ring Clipping

If we allowed such things in RFCs, this would be a = footnote. I think this should either be a subsection 4.2.1, or at least = it should contain a reference back to 4.2.

[Joe] Will move it to Appendix and provide reference = back to 4.2. This is a problem that needs to be address in real = networks as interworking with Public Switched Telephony Network (PSTN) = is needed.

It uses jargon and acronyms unknown in the IETF = (Tandem Office??? ISUP??) and English errors.
[Joe] Will explain the acronyms and fix any English = errors.

> 5.4  VPN Service Mapping

You don't refer to RFC 2983 (Differentiated Services = and Tunnels), and I'm not sure you are consistent with it. You should = certainly indicate which of the conceptual models in 2983 you are = suggesting. And of course if it's an IPSec VPN, IPSec specifies certain = rules that you have to follow.

[Joe] This section will be moved to the Appendix and = will add reference to RFC 2983. In this draft we are not address all = the different options for VPNs and what the QoS guidelines should to = be. As stated in the draft further study is required.

 
     Brian

Regards, Joe.
Jozef Babiarz
email: babiarz@nortelnetworks.com

------_=_NextPart_001_01C4C73D.4B96842B-- --===============1986383015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1986383015==-- From tsvwg-bounces@ietf.org Wed Nov 10 14:04:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13852; Wed, 10 Nov 2004 14:04:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxms-00024R-AR; Wed, 10 Nov 2004 14:05:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxcJ-0007SJ-WC; Wed, 10 Nov 2004 13:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxRf-00050s-HT for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 13:43:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11375 for ; Wed, 10 Nov 2004 13:43:50 -0500 (EST) Received: from lightwave.chromisys.com ([63.102.55.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxSf-0001T6-IN for tsvwg@ietf.org; Wed, 10 Nov 2004 13:44:54 -0500 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 10:43:14 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC01DDDEB5@nimbus.chromisys.com> From: John Drake To: "Francois Le Faucheur (flefauch)" Date: Wed, 10 Nov 2004 10:43:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Cc: tsvwg@ietf.org Subject: [Tsvwg] RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Francois, You're very welcome. John > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Tuesday, November 09, 2004 1:43 PM > To: John Drake > Cc: FLF; tsvwg@ietf.org > Subject: FW: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt > > Hi John, > > As discussed today, we will bring the next revision of > draft-lefaucheur-rsvp-dste in closer alignment with "LSP Hierarchy" > draft. In particular, the IF_ID RSVP_HOP object will be used as per "LSP > Hierarchy". I think we could also even go for out of band signaling > (also as per "LSP Hierarchy"), then we would probably want to do the > "checks" to confirm proper out-of-band signaling. > > Thanks again for your comments. > > Francois > > >> -----Original Message----- > >> From: John Drake [mailto:jdrake@calient.net] > >> Sent: mardi 9 novembre 2004 17:59 > >> To: John Drake; Francois Le Faucheur (flefauch) > >> Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch) > >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt > >> > >> Francois, > >> > >> I just checked the hierarchy I-D and the two checks you > >> mentioned are for > >> the out-of-band case. I.e., you want to check that the far > >> end of the FA > >> LSP is associated with the node that sent you the Path message. > >> > >> You could probably state in your I-D that for this check > >> isn't necessary for > >> the in-band case. I don't know if you should mention that a > >> node should > >> check the FA LSP specified in the IF_ID is the same as the > >> LSP in which the > >> Path message was received. > >> > >> Thanks, > >> > >> John > >> > > >> > > >> -----Original Message----- > >> > > >> From: John Drake [mailto:jdrake@calient.net] > >> > > >> Sent: lundi 18 octobre 2004 18:20 > >> > > >> To: Francois Le Faucheur (flefauch) > >> > > >> Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch); > >> > > >> Carol Iturralde (cei) > >> > > >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > >> > > >> Francois, > >> > > >> > >> > > >> The issue may be a simple as the fact that you don't make it > >> > > >> clear that you > >> > > >> are using LSP hierarchy as a base and that you don't > >> > > >> explicitly detail what > >> > > >> the differences are. This makes your I-D read as though it > >> > > >> is proposing > >> > > >> something different. > >> > > >> > >> > > >> I would suggest that you include a normative reference to > >> > > >> the LSP hierarchy > >> > > >> I-D and indicate that its signaling procedures are to be > >> > > >> used; in particular > >> > > >> that the FA LSP is identified using the IF_ID RSVP_HOP. (I > >> > > >> think it would > >> > > >> also help if you used its terminology.) > >> > > >> > >> > > >> Comments inline. > >> > > >> > >> > > >> Thanks, > >> > > >> > >> > > >> John > >> > > >> > >> > > >> > -----Original Message----- > >> > > >> > From: Francois Le Faucheur (flefauch) > >> [mailto:flefauch@cisco.com] > >> > > >> > Sent: Monday, October 18, 2004 8:27 AM > >> > > >> > To: John Drake > >> > > >> > Cc: Bruce Davie (bdavie); Francois Le Faucheur (flefauch); > >> > > >> Carol Iturralde > >> > > >> > (cei) > >> > > >> > Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > > >> > > >> > Hi John, > >> > > >> > > >> > > >> > Thanks for checking the document. > >> > > >> [John Drake] > >> > > >> > >> > > >> You're welcome. > >> > > >> > >> > > >> > > >> > > >> > >> -----Original Message----- > >> > > >> > >> From: John Drake [mailto:jdrake@calient.net] > >> > > >> > >> Sent: vendredi 15 octobre 2004 18:02 > >> > > >> > >> To: Francois Le Faucheur (flefauch) > >> > > >> > >> Cc: Francois Le Faucheur (flefauch); Bruce Davie (bdavie) > >> > > >> > >> Subject: RE: I-D ACTION:draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > >> > >> > > >> > >> Francois, > >> > > >> > >> > >> > > >> > >> Is there a reason why you couldn't re-use the signaling > >> > > >> > >> procedures of the > >> > > >> > >> LSP hierarchy I-D? > >> > > >> > > >> > > >> > This is what we have tried to do. > >> > > >> > The LSP hierarchy draft does specify a number of ways to > >> > > >> signal from > >> > > >> > Aggregate Head to Aggregate Tail. In particular, it > >> > > >> discusses one option > >> > > >> > that is required for non-packet-capable optical boxes > >> > > >> (RSVP out of band) > >> > > >> > and one option which can be used for packet-capable boxes > >> > > >> (encpasulate > >> > > >> > inside tunnel). We use the latter option. > >> > > >> [John Drake] > >> > > >> > >> > > >> That's fine, but it does stipulate that in all cases > >> the FA LSP is > >> > > >> identified with the IF_ID RSVP_HOP. > >> > > >> > >> > > >> > > >> > > >> > As I said, one necessary difference comes from the fact > >> > > >> that RSVP uses > >> > > >> > final destination while RSVP-TE uses ERO. But as you say > >> > > >> below, that > >> > > >> > doesn't affect things once it is encapsulated. > >> > > >> > > >> > > >> > >>If the Path message is tunneled from head-end to > >> > > >> > >> tail-end, as described in LSP hierarchy I-D, it doesn't > >> > > >> > >> matter what is in > >> > > >> > >> the destination address field of tunneled IP packet. > >> > > >> > >> Also, > >> > > >> > >> in checking with > >> > > >> > >> Lou Berger, it seems that all RSVP-TE > >> implementations place > >> > > >> > >> the next hop > >> > > >> > >> address in the destination address field. > >> > > >> > > >> > > >> > Agreed. > >> > > >> > Which is why we see a small difference in how to handle > >> > > >> aggregation of > >> > > >> > end-to-end RSVP from that viewpoint. > >> > > >> > > >> > > >> > >> > >> > > >> > >> It seems to me that having multiple ways of doing the > >> > > >> same thing is > >> > > >> > >> counter-productive. > >> > > >> > >> Also, in section 5, you seem to be recommending that your > >> > > >> > >> procedures, rather > >> > > >> > >> than the procedures of the LSP hierarchy I-D, be used for > >> > > >> > >> LSP hierarchy. > >> > > >> > > >> > > >> > We are not trying to introduce any change over LSP > >> > > >> hierarchy. Again, we > >> > > >> > think the behavior is in line with LSP hiererachy > >> draft wherever > >> > > >> > possible and only differs for what is specific to RSVP > >> > > >> end-to-end flows. > >> > > >> > Please let us know if you see specific aspects which would > >> > > >> be departing > >> > > >> > from LSP hierarchy and which could be brought back in line. > >> > > >> > > >> > > >> > Thanks > >> > > >> > > >> > > >> > Francois > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > > >> > >> Thanks, > >> > > >> > >> > >> > > >> > >> John > >> > > >> > >> > >> > > >> > >> > -----Original Message----- > >> > > >> > >> > From: Francois Le Faucheur (flefauch) > >> > > >> [mailto:flefauch@cisco.com] > >> > > >> > >> > Sent: Friday, October 15, 2004 3:31 AM > >> > > >> > >> > To: John Drake > >> > > >> > >> > Cc: Francois Le Faucheur (flefauch); Bruce > >> Davie (bdavie) > >> > > >> > >> > Subject: RE: I-D > >> ACTION:draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > >> > > >> > > >> > >> > Hi John, > >> > > >> > >> > > >> > > >> > >> > Thanks for the note. Yes, we are aware of that draft > >> > > >> and also see a > >> > > >> > >> > number of commonalities. In fact, in section > >> 5, we point > >> > > >> > >> out that one of > >> > > >> > >> > the applicable scenario is the one where the end-to-end > >> > > >> > >> reservations are > >> > > >> > >> > RSVP-TE tunnel reservations as per lsp-hiererachy. > >> > > >> > >> > However, the prime focus of the rsvp-dste draft is, > >> > > >> of course, the > >> > > >> > >> > aggregation of regular RSVP reservations and its > >> > > >> > >> applicablity to CAC for > >> > > >> > >> > voice. One of the related aspect is that RSVP-TE > >> > > >> > >> reservations use ERO > >> > > >> > >> > while regular RSVP Path uses final destination > >> addresses. > >> > > >> > >> This makes it > >> > > >> > >> > much more natural with regular RSVP to encapuslate the > >> > > >> > >> Path inside the > >> > > >> > >> > tunnel, than with lsp-hiererachy where Path message > >> > > >> can be forwrded > >> > > >> > >> > out-of-band to the Tunnel tail. > >> > > >> > >> > > >> > > >> > >> > Looking forward to hearing more comments > >> > > >> > >> > > >> > > >> > >> > Francois > >> > > >> > >> > > >> > > >> > >> > >> -----Original Message----- > >> > > >> > >> > >> From: John Drake [mailto:jdrake@calient.net] > >> > > >> > >> > >> Sent: jeudi 14 octobre 2004 23:05 > >> > > >> > >> > >> To: Francois Le Faucheur (flefauch) > >> > > >> > >> > >> Subject: FW: I-D > >> ACTION:draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > >> > >> > >> > > >> > >> > >> Francois, > >> > > >> > >> > >> > >> > > >> > >> > >> Are you aware of the following I-D: > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hiera > >> > > >> > >> > >> rchy-08.txt > >> > > >> > >> > >> > >> > > >> > >> > >> I think there's a fair amount of overlap between > >> > > >> it and your > >> > > >> > >> > >> draft, below, > >> > > >> > >> > >> which I just skimmed. (And which I'll read > >> more thoroughly > >> > > >> > >> > >> later this > >> > > >> > >> > >> week.) > >> > > >> > >> > >> > >> > > >> > >> > >> Thanks, > >> > > >> > >> > >> > >> > > >> > >> > >> John > >> > > >> > >> > >> > >> > > >> > >> > >> -----Original Message----- > >> > > >> > >> > >> From: Internet-Drafts@ietf.org > >> > > >> [mailto:Internet-Drafts@ietf.org] > >> > > >> > >> > >> Sent: Thursday, October 14, 2004 1:18 PM > >> > > >> > >> > >> To: i-d-announce@ietf.org > >> > > >> > >> > >> Subject: I-D > >> ACTION:draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > >> > >> > >> > > >> > >> > >> A New Internet-Draft is available from the on-line > >> > > >> > >> Internet-Drafts > >> > > >> > >> > >> directories. > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> Title : Aggregation of RSVP > >> > > >> > >> Reservations over MPLS > >> > > >> > >> > >> TE/DS-TE > >> > > >> > >> > >> Tunnels > >> > > >> > >> > >> Author(s) : F. Le Faucheur, et al. > >> > > >> > >> > >> Filename : > >> draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > >> > >> Pages : 18 > >> > > >> > >> > >> Date : 2004-10-14 > >> > > >> > >> > >> > >> > > >> > >> > >> This document provides specification for > >> aggregation of > >> > > >> > >> RSVP end-to- > >> > > >> > >> > >> end reservations over MPLS Traffic > >> Engineering (TE) > >> > > >> > >> > >> tunnels or MPLS > >> > > >> > >> > >> Diffserv-aware MPLS Traffic Engineering (DS-TE) > >> > > >> Tunnels. This > >> > > >> > >> > >> approach is based on RFC 3175 and simply > >> modifies the > >> > > >> > >> > >> corresponding > >> > > >> > >> > >> procedures for operations over MPLS TE tunnels > >> > > >> instead of > >> > > >> > >> > >> aggregated > >> > > >> > >> > >> RSVP reservations. This approach can be used to > >> > > >> > >> achieve admission > >> > > >> > >> > >> control of a very large number of flows > >> in a scalable > >> > > >> > >> > >> manner since > >> > > >> > >> > >> the devices in the core of the network are > >> > > >> unaware of the > >> > > >> > >> > >> end-to-end > >> > > >> > >> > >> RSVP reservations and are only aware of the > >> > > >> MPLS TE tunnels. > >> > > >> > >> > >> > >> > > >> > >> > >> A URL for this Internet-Draft is: > >> > > >> > >> > >> > >> > > >> > >> > >> > > >> > >> http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-dste-01.txt > >> > > >> > >> > >> > >> > > >> > >> > >> To remove yourself from the I-D > >> Announcement list, send > >> > > >> > >> a message to > >> > > >> > >> > >> i-d-announce-request@ietf.org with the word > >> unsubscribe in > >> > > >> > >> > >> the body of the > >> > > >> > >> > >> message. > >> > > >> > >> > >> You can also visit > >> > > >> > >> > >> https://www1.ietf.org/mailman/listinfo/I-D-announce > >> > > >> > >> > >> to change your subscription settings. > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> Internet-Drafts are also available by > >> anonymous FTP. Login > >> > > >> > >> > >> with the username > >> > > >> > >> > >> "anonymous" and a password of your e-mail address. > >> > > >> > >> After logging in, > >> > > >> > >> > >> type "cd internet-drafts" and then > >> > > >> > >> > >> "get draft-lefaucheur-rsvp-dste-01.txt". > >> > > >> > >> > >> > >> > > >> > >> > >> A list of Internet-Drafts directories can > >> be found in > >> > > >> > >> > >> http://www.ietf.org/shadow.html > >> > > >> > >> > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > > >> > >> > >> > >> > > >> > >> > >> Send a message to: > >> > > >> > >> > >> mailserv@ietf.org. > >> > > >> > >> > >> In the body type: > >> > > >> > >> > >> "FILE > >> > > >> > >> /internet-drafts/draft-lefaucheur-rsvp-dste-01.txt". > >> > > >> > >> > >> > >> > > >> > >> > >> NOTE: The mail server at ietf.org can return > >> > > >> the document in > >> > > >> > >> > >> MIME-encoded form by using the "mpack" utility. > >> > > >> > >> To use this > >> > > >> > >> > >> feature, insert the command "ENCODING mime" > >> > > >> > >> before the "FILE" > >> > > >> > >> > >> command. To decode the response(s), you will > >> > > >> > >> need "munpack" or > >> > > >> > >> > >> a MIME-compliant mail reader. Different > >> MIME-compliant > >> > > >> > >> > >> mail readers > >> > > >> > >> > >> exhibit different behavior, especially > >> when dealing > >> with > >> > > >> > >> > >> "multipart" MIME messages (i.e. documents which > >> > > >> > >> have been split > >> > > >> > >> > >> up into multiple messages), so check your local > >> > > >> > >> documentation on > >> > > >> > >> > >> how to manipulate these messages. > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> Below is the data which will enable a MIME > >> > > >> compliant mail reader > >> > > >> > >> > >> implementation to automatically retrieve the ASCII > >> > > >> > >> version of the > >> > > >> > >> > >> Internet-Draft. > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> ------------------------------------------------------------- > >> > > >> > >> > >> ------------ > >> > > >> > >> > >> In order to maintain computing > >> infrastructure integrity, > >> > > >> > >> > >> Cisco Systems > >> > > >> > >> > >> Enterprise Messaging Services and InfoSec > >> teams have set a > >> > > >> > >> > >> mail policy > >> > > >> > >> > >> disallowing executable attachments in email. > >> > > >> > >> > >> > >> > > >> > >> > >> This message contained an executable attachment > >> > > >> type that is > >> > > >> > >> > >> prohibited > >> > > >> > >> > >> by this policy. The attachment has been > >> removed from this > >> > > >> > >> > >> message and > >> > > >> > >> > >> copied to quarantine by our systems. It > >> will be held in > >> > > >> > >> > >> quarantine for > >> > > >> > >> > >> seven days in the event that the content needs to > >> > > >> be retrieved. > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> ------------------------------------------------------------- > >> > > >> > >> > >> ------------ > >> > > >> > >> > >> For further reference information about viruses and > >> > > >> > >> email antivirus > >> > > >> > >> > >> efforts within Cisco, please visit: > >> > > >> > >> > >> > >> > > >> > >> > >> http://wwwin.cisco.com/it/ems/services/antiviral > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> If your concern isn't addressed by the > >> information in this > >> > > >> > >> > >> notification > >> > > >> > >> > >> or the above web page, you may open a > >> support request: > >> > > >> > >> > >> > >> > > >> > >> > >> http://wwwin.cisco.com/support/ > >> > > >> > >> > >> > >> > > >> > >> > >> Select "Messaging", "Email-Related", "Mail Routing" > >> > > >> > >> > >> > >> > > >> > >> > >> Please include in the text of your case the > >> following > >> > > >> > >> information: > >> > > >> > >> > >> > >> > > >> > >> > >> * Full headers of the message. Documentation on > >> > > >> > >> displaying the full > >> > > >> > >> > >> headers is available at this URL: > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> http://wwwin.cisco.com/support/library/faqs/solution002471.html > >> > > >> > >> > >> > >> > > >> > >> > >> * This unique quarantine identifier: i9EL4Ew8014772 > >> > > >> > >> > >> > >> > > >> > >> > >> If the matter is urgent, you may follow up by > >> > > >> calling one of > >> > > >> > >> > >> the below > >> > > >> > >> > >> referenced numbers. Please make every > >> effort to provide > >> > > >> > >> the above > >> > > >> > >> > >> requested information via the support web > >> tool prior to > >> > > >> > >> > >> calling as it > >> > > >> > >> > >> will greatly aid the resolution of your issue. > >> > > >> > >> > >> > >> > > >> > >> > >> Americas: > >> > > >> > >> > >> 1 408 526 8888 > >> > > >> > >> > >> > >> > > >> > >> > >> Asiapac > >> > > >> > >> > >> +61 2 8446 8888 > >> > > >> > >> > >> > >> > > >> > >> > >> EMEA > >> > > >> > >> > >> +31 20 485 4888 > >> > > >> > >> > >> > >> > > >> > >> > >> Japan > >> > > >> > >> > >> +81 3 5549 6888 > >> > > >> > >> > >> > >> > > >> > >> > >> US (Toll Free) > >> > > >> > >> > >> 1| 800| 888| 8187| (ext.68888) > >> > > >> > >> > >> > >> > > >> > >> > >> Thank you for your cooperation, > >> > > >> > >> > >> > >> > > >> > >> > >> Enterprise Messaging Services > >> > > >> > >> > >> Cisco Systems, Inc > >> > > >> > >> > >> > >> > > >> > >> > >> > > >> > >> _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 10 15:58:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01461; Wed, 10 Nov 2004 15:58:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzYc-0006nW-OP; Wed, 10 Nov 2004 15:59:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzKL-0007i4-D9; Wed, 10 Nov 2004 15:44:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyuK-0000Cl-2n for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 15:17:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22698 for ; Wed, 10 Nov 2004 15:17:30 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyvG-00043h-Li for tsvwg@ietf.org; Wed, 10 Nov 2004 15:18:35 -0500 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAAKGB028124; Wed, 10 Nov 2004 15:16:12 -0500 (EST) Received: from KCHAN-2K3.nortelnetworks.com (artpt5r7.us.nortel.com [47.140.52.158]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKL31RCY; Wed, 10 Nov 2004 15:15:58 -0500 Message-Id: <6.0.3.0.0.20041110144924.02db9a18@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 10 Nov 2004 15:15:56 -0500 To: Philip Jacobs From: Kwok Ho Chan Subject: Re: [Tsvwg] Question regarding draft-baker-diffserv-basic-classes-04. txt In-Reply-To: <418EC6AA.6020702@cisco.com> References: <418EC6AA.6020702@cisco.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1870308490==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc --===============1870308490== Content-Type: multipart/alternative; boundary="=====================_2676528==.ALT" --=====================_2676528==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Philip: We actually have another draft submitted http://www.ietf.org/internet-drafts/draft-chan-tsvwg-diffserv-class-aggr-00.txt (But not planning to be addressed in this IETF meeting). We are improving it currently and would like to discuss this on the mailing list and in future IETF meetings This draft may help answer some of the issue you have below because in this draft we are aggregating more than one service class into a traffic treatment. Doing so may give some service class better treatment it may need. That draft will deal with the issues you raised below. Aggregation will only make sense only if each service within the aggregation will be upheld/satisfied. We are currently updating this draft and will more then happy to listen to any suggestion you have. -- Kwok -- At 08:06 PM 11/7/2004, Philip Jacobs wrote: >I have a question regarding draft-baker-diffserv-basic-classes-04.txt > >It seems that there are business and unavailability cases when >applications would be carried in "non-optimal" Service Classes. > >E.g.1. A business decision may be made such that urgent email could be >sent in the "Low-latency" rather than the "High Throughput Data" Service >Class used for regular email (with appropriately set higher expectations). > >E.g.2. During signaling, if there is no available capacity in the >"Telephony" services class, a VoIP call may be carried in "Low-latency" >Service Class (with appropriately set lower expectations). > >My question is "should this draft contain advise regarding into which >Service Classes various types of application may be non-optimally placed?" > >It might be useful to include advice regarding: >- types of application traffic which may damage Services Classes's ability >to deliver as expected. Eg An email may damage the "Telephony" service class. > >- types of application traffic which may be carried in "non-optimal" >Service Classes without negative impact. > >This would answer the question, which service classes a type of >application may be "promoted/demoted" into, and which ones it may not. > >Phil > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > --=====================_2676528==.ALT Content-Type: text/html; charset="us-ascii" Philip:
We actually have another draft submitted
  http://www.ietf.org/internet-drafts/draft-chan-tsvwg-diffserv-class-aggr-00.txt
(But not planning to be addressed in this IETF meeting).  We are improving it
currently and would like to discuss this on the mailing list and in future IETF meetings

This draft may help answer some of the issue you have below because
in this draft we are aggregating more than one service class into a
traffic treatment.  Doing so may give some service class better treatment
it may need.

That draft will deal with the issues you raised below.
Aggregation will only make sense only if each service within the aggregation
will be upheld/satisfied.
We are currently updating this draft and will more then happy to listen to
any suggestion you have.

-- Kwok --


At 08:06 PM 11/7/2004, Philip Jacobs wrote:

I have a question regarding draft-baker-diffserv-basic-classes-04.txt

It seems that there are business and unavailability cases when applications would be carried in "non-optimal" Service Classes.

E.g.1. A business decision may be made such that urgent email could be sent in the "Low-latency" rather than the "High Throughput Data" Service Class used for regular email (with appropriately set higher expectations).

E.g.2. During signaling, if there is no available capacity in the "Telephony" services class, a VoIP call may be carried in "Low-latency" Service Class (with appropriately set lower expectations).

My question is "should this draft contain advise regarding into which Service Classes various types of application may be non-optimally placed?"

It might be useful to include advice regarding:
- types of application traffic which may damage Services Classes's ability to deliver as expected. Eg An email may damage the "Telephony" service class.

- types of application traffic which may be carried in "non-optimal" Service Classes without negative impact.

This would answer the question, which service classes a type of application may be "promoted/demoted" into, and which ones it may not.

Phil



_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
--=====================_2676528==.ALT-- --===============1870308490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1870308490==-- From tsvwg-bounces@ietf.org Wed Nov 10 16:07:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02902; Wed, 10 Nov 2004 16:07:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRziA-0007IA-46; Wed, 10 Nov 2004 16:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzVP-0007s9-6b; Wed, 10 Nov 2004 15:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzCx-0002c0-PC for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 15:36:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25353; Wed, 10 Nov 2004 15:36:45 -0500 (EST) From: fred@cisco.com Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzDx-0004lb-Hl; Wed, 10 Nov 2004 15:37:50 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2004 12:48:06 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAAKaAnC019201; Wed, 10 Nov 2004 12:36:11 -0800 (PST) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA23991; Wed, 10 Nov 2004 12:36:12 -0800 (PST) Date: Wed, 10 Nov 2004 12:36:12 -0800 (PST) Message-Id: <200411102036.MAA23991@irp-view7.cisco.com> To: proceedings@ietf.org, tsvwg@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Tsvwg] My slides in TSVWG Today X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea ftp://ftpeng.cisco.com/fred/mlpp/Nested_VPNs.ppt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 10 17:27:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12020; Wed, 10 Nov 2004 17:27:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0xZ-0000rD-BG; Wed, 10 Nov 2004 17:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0qD-0001RA-Dj; Wed, 10 Nov 2004 17:21:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0gd-0007s1-TJ for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 17:11:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10733 for ; Wed, 10 Nov 2004 17:11:28 -0500 (EST) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0hd-0000XC-UY for tsvwg@ietf.org; Wed, 10 Nov 2004 17:12:36 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E98EB6BA47 for ; Wed, 10 Nov 2004 17:10:55 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAAMAt1t017291 for ; Wed, 10 Nov 2004 17:10:55 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id EDC1D4FBF2; Wed, 10 Nov 2004 17:08:14 -0500 (EST) Date: Wed, 10 Nov 2004 17:08:14 -0500 From: Wesley Eddy To: tsvwg@ietf.org Message-ID: <20041110220814.GB13465@grc.nasa.gov> Mime-Version: 1.0 X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Tsvwg] slides from transport mobility architecture talk today X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331728106==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 --===============0331728106== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The slides I used to talk about a common transport layer mobility architecture today are available at: http://roland.grc.nasa.gov/~weddy/shared/tlmarch-00.pdf Thanks to the group for the valuable feedback. -Wes --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBkpFOzBuYqbnj3IwRAp1FAJ42aWDslf2M2OjY4sfqAXPzciGkKQCggwvr cbCF6n8Yl9lJRcs+CgD6r38= =P24H -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- --===============0331728106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0331728106==-- From tsvwg-bounces@ietf.org Wed Nov 10 17:30:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12203; Wed, 10 Nov 2004 17:30:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS10D-0000uW-DJ; Wed, 10 Nov 2004 17:31:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0qI-0001Sc-9F; Wed, 10 Nov 2004 17:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0jj-0008B4-MJ for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 17:14:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10954 for ; Wed, 10 Nov 2004 17:14:41 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0kl-0000bD-3M for tsvwg@ietf.org; Wed, 10 Nov 2004 17:15:48 -0500 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAAME9F19796; Wed, 10 Nov 2004 17:14:09 -0500 (EST) Received: from KCHAN-2K3.nortelnetworks.com (artpt6sc.us.nortel.com [47.140.61.14]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKL31VF7; Wed, 10 Nov 2004 17:14:08 -0500 Message-Id: <6.0.3.0.0.20041110170606.043bcfb8@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 10 Nov 2004 17:14:02 -0500 To: tsvwg@ietf.org From: Kwok Ho Chan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Kwok Ho Chan Subject: [Tsvwg] draft-baker-diffserv-classes-04.txt slides for TSVWG @ 61st IETF in DC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Please find the slides I presented in TSVWG today @ 61st IETF Washington DC is at: ftp://standards.nortelnetworks.com/diffserv/DiffServ_BasicClasses_61thIETF.ppt Please use save to file (instead of open) to see all the slides (at least on the browser I am using). -- Kwok -- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 10 17:43:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13321; Wed, 10 Nov 2004 17:43:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS1D6-0001CX-Ac; Wed, 10 Nov 2004 17:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS17f-0004rS-3G; Wed, 10 Nov 2004 17:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS109-0003No-G3 for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 17:31:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12307 for ; Wed, 10 Nov 2004 17:31:38 -0500 (EST) Received: from [130.129.135.214] (helo=nak.isi.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS119-0000vH-2p for tsvwg@ietf.org; Wed, 10 Nov 2004 17:32:46 -0500 Received: by nak.isi.edu (Postfix, from userid 3494) id 310D9541037; Wed, 10 Nov 2004 17:31:06 -0500 (EST) Date: Wed, 10 Nov 2004 17:31:06 -0500 From: Aaron Falk To: tsvwg@ietf.org Message-ID: <20041110223104.GD3444@isi.edu> Mail-Followup-To: tsvwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Cynicism-Level: 3 Organization: USC ISI X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Tsvwg] XCP slides from tsvwg, project page X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Project website: http://www.isi.edu/isi-xcp Slides from TSVWG meeting: http://www.isi.edu/isi-xcp/ietf/falk-xcp-tsvwg-ietf61.pdf _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 10 20:04:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25514; Wed, 10 Nov 2004 20:04:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS3PI-00040n-3d; Wed, 10 Nov 2004 20:05:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS3BD-0000dr-7Q; Wed, 10 Nov 2004 19:51:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS39B-0008Rg-6N for tsvwg@megatron.ietf.org; Wed, 10 Nov 2004 19:49:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24317 for ; Wed, 10 Nov 2004 19:49:05 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS3AE-0003cA-3e for tsvwg@ietf.org; Wed, 10 Nov 2004 19:50:15 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 1392F32996; Wed, 10 Nov 2004 19:49:03 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 951763290A; Wed, 10 Nov 2004 19:49:01 -0500 (EST) Date: Wed, 10 Nov 2004 19:49:01 -0500 (EST) From: "Armando L. Caro, Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: Aaron Falk In-Reply-To: <20041110223104.GD3444@isi.edu> Message-ID: References: <20041110223104.GD3444@isi.edu> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tsvwg@ietf.org Subject: [Tsvwg] comments on draft-falk-xcp-spec-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a I haven't gone through the draft in detail yet (but I did read the Sigcomm paper previously), and I have a couple of comments: I have another addition to the Security Considerations section: Malicious Receivers. A receiver can lie about the delta_throughput received downstream, and put whatever it wants in the feedback field sent back to the sender. I suppose that this could be addressed by a policer at the receiving edge similar to the one proposed to combat malicious senders, but wouldn't that be too much state for it to scale well? Also, is there enough incentive for these policing functions to be used? Minor fix... The wording under Malicious Sources in Section 5 should be: The XCP algorithms rely on senders to advertise information ^ Thanks... ~armando 0-- --0 | Armando L. Caro, Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Nov 14 12:40:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28061; Sun, 14 Nov 2004 12:40:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTONx-0008Oc-56; Sun, 14 Nov 2004 12:41:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTOIL-0006I6-JC; Sun, 14 Nov 2004 12:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTOCu-0005nO-79 for tsvwg@megatron.ietf.org; Sun, 14 Nov 2004 12:30:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27234 for ; Sun, 14 Nov 2004 12:30:29 -0500 (EST) Received: from mail.cyut.edu.tw ([163.17.1.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTOEh-0007t6-Sa for tsvwg@ietf.org; Sun, 14 Nov 2004 12:32:25 -0500 Received: from mychat9aacf5dc (localhost [127.0.0.1]) by mail.cyut.edu.tw (8.12.11/8.12.11) with ESMTP id iAEHTZh2014449 for ; Mon, 15 Nov 2004 01:29:35 +0800 (CST) Message-Id: <200411141729.iAEHTZh2014449@mail.cyut.edu.tw> X-Authentication-Warning: mail.cyut.edu.tw: iscan owned process doing -bs From: "ribb" To: Date: Mon, 15 Nov 2004 01:29:21 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTKb3pXEGYmVeAIQzOL/1XQ+hI7Ug== X-Spam-Score: 1.2 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Tsvwg] could we translate TCP to SCTP with translation mechanism? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0985644929==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. --===============0985644929== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C4CAB2.88E36590" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C4CAB2.88E36590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all: My question is could we translate TCP to SCTP with translation mechanism such as NAT(NAPT) ? thanks a lot. ------=_NextPart_000_000C_01C4CAB2.88E36590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 all:
 
My question is could=20 we  translate TCP to SCTP with  translation mechanism such as=20 NAT(NAPT) ?
 
thanks a=20 lot.
 
------=_NextPart_000_000C_01C4CAB2.88E36590-- --===============0985644929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0985644929==-- From tsvwg-bounces@ietf.org Mon Nov 15 13:53:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19959; Mon, 15 Nov 2004 13:53:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTm0U-000593-7e; Mon, 15 Nov 2004 13:55:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTltU-0002ej-Ub; Mon, 15 Nov 2004 13:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlpl-0001zg-Km for tsvwg@megatron.ietf.org; Mon, 15 Nov 2004 13:44:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19026 for ; Mon, 15 Nov 2004 13:44:12 -0500 (EST) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTlro-0004uv-JG for tsvwg@ietf.org; Mon, 15 Nov 2004 13:46:20 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 792736B9C7 for ; Mon, 15 Nov 2004 13:43:35 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAFIhZ1t021620 for ; Mon, 15 Nov 2004 13:43:35 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id C89594FC36; Mon, 15 Nov 2004 13:40:47 -0500 (EST) Date: Mon, 15 Nov 2004 13:40:47 -0500 From: Wesley Eddy To: tsvwg@ietf.org Message-ID: <20041115184047.GA2667@grc.nasa.gov> Mime-Version: 1.0 X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Tsvwg] multiaddressing X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2041841625==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 --===============2041841625== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In draft-crocker-mast-analysis-01 (now expired), the concept of "multiaddressing" for solving multihoming and mobility problems is explained. The HIP groups and multi6 are focusing on multiaddressing solutions built for "simple" transports that can only bind to a single address with no means to update or extend that binding when it might be required by mobility or multihoming. Adding a wedge-layer to map dynamic locators to fixed identifiers fixes these problems and allows the transport to go untouched and remain simple. A drawback of such wedge-layers, Mobile IP, and other systems that hide mobility (or multihoming) from the transport is that current transport mechanisms are not nearly "agile" enough to deal with end-to-end path changes that can pop up instantly. The transport is where all the path estimates are stored (congestion control variables, RTTM, PMTUD, etc) and making non-trivial path changes without some explicit signalling to the transport can be dangerous. If we're going to see multiaddressing wedge layers deployed, then it seems like we should have a slightly richer interface between the wedge and the transport so that reinitialization and reestimation of path state can happen rapidly. Architectures that don't include such wedges are what we were considering in draft-eddy-tlmarch-00 (presented last week). The idea of rapidly fixing the transport's path estimation variables is roughly visible in draft-swami-tcp-lmdr-04. For architectures that *do* include wedges, some similar form of signaling and responding to path changes is still _required_. Signaling has to occur both between the wedge and transport locally and remotely, so that both half-connections can be fixed. Responses to these signals will have to be implemented per-transport protocol. It's not entirely clear to me how we can combine the strengths of a multiaddressing wedge layer with the rapid-response of path property estimates that we can have without the wedge in a transport layer mobility scheme. Thoughts? -Wes --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBmPgvzBuYqbnj3IwRAi5JAJ4xnatwBxpU9d8yZY2DsftSvWMWvwCeM0JQ tx+qFU0zJX1yTf6QbcKX53A= =lKOv -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- --===============2041841625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============2041841625==-- From tsvwg-bounces@ietf.org Tue Nov 16 14:33:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03127; Tue, 16 Nov 2004 14:33:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU97k-0005nV-VN; Tue, 16 Nov 2004 14:36:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU915-00044i-Cz; Tue, 16 Nov 2004 14:29:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTRAL-0001Dn-4t for tsvwg@megatron.ietf.org; Sun, 14 Nov 2004 15:40:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09994 for ; Sun, 14 Nov 2004 15:40:03 -0500 (EST) Received: from mailhub.hp.com ([192.151.27.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTRCA-0007Ul-9f for tsvwg@ietf.org; Sun, 14 Nov 2004 15:42:00 -0500 Received: from [192.168.1.100] (adsl-67-116-53-107.dsl.sntc01.pacbell.net [67.116.53.107]) by mailhub.hp.com (Postfix) with ESMTP id 8E53527110 for ; Sun, 14 Nov 2004 15:39:28 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200411141729.iAEHTZh2014449@mail.cyut.edu.tw> References: <200411141729.iAEHTZh2014449@mail.cyut.edu.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <475877FD-367D-11D9-ACAD-000393765F60@hp.com> Content-Transfer-Encoding: quoted-printable From: rick jones Subject: Re: [Tsvwg] could we translate TCP to SCTP with translation mechanism? Date: Sun, 14 Nov 2004 12:39:27 -0800 To: tsvwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 16 Nov 2004 14:29:25 -0500 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > My question is could we=A0 translate TCP to SCTP with=A0 translation=20= > mechanism such as NAT(NAPT) ? Given that NAT is something of an application-level gateway already,=20 sure, you could probably do an application-level gateway that had TCP=20 enter at one side and SCTP the other. I'm not sure I would call that a "translation" however. And while you=20= could probably cover most of not all the semantics of TCP with SCTP,=20 going the other way with the myriad of SCTP semantics might be=20 non-trivial. rick jones sometimes life is best with chickens, sheep, pigs and cows separate :) my thoughts only _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 16 15:03:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06137; Tue, 16 Nov 2004 15:03:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9ad-0006Z8-GW; Tue, 16 Nov 2004 15:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9Nz-0000VJ-EP; Tue, 16 Nov 2004 14:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9FD-0006xJ-P2 for tsvwg@megatron.ietf.org; Tue, 16 Nov 2004 14:44:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04372 for ; Tue, 16 Nov 2004 14:44:03 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9HS-00066K-Fy for tsvwg@ietf.org; Tue, 16 Nov 2004 14:46:24 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id iAGJhv29013794; Tue, 16 Nov 2004 11:43:57 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 8A2D877AA12; Tue, 16 Nov 2004 14:43:55 -0500 (EST) To: rick jones From: Mark Allman Subject: Re: [Tsvwg] could we translate TCP to SCTP with translation mechanism? In-Reply-To: <475877FD-367D-11D9-ACAD-000393765F60@hp.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Eight Days a Week MIME-Version: 1.0 Date: Tue, 16 Nov 2004 14:43:55 -0500 Message-Id: <20041116194355.8A2D877AA12@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0256995593==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa --===============0256995593== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain rick- > sometimes life is best with chickens, sheep, pigs and cows separate :) > my thoughts only in this case ... not so much allman --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBmlh7WyrrWs4yIs4RAtZiAJ4xtvgDiDGovvGg6BsMt5Dl/DFRZACdFuXH Sy9JrV57PGpaR4vdHgud1Lw= =Mjeg -----END PGP SIGNATURE----- --=-=-=-- --===============0256995593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0256995593==-- From tsvwg-bounces@ietf.org Wed Nov 17 19:29:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06651; Wed, 17 Nov 2004 19:29:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUaDn-0001yn-EW; Wed, 17 Nov 2004 19:32:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZcg-0001P9-8Y; Wed, 17 Nov 2004 18:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZOB-0006vm-62 for tsvwg@megatron.ietf.org; Wed, 17 Nov 2004 18:39:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02702 for ; Wed, 17 Nov 2004 18:39:00 -0500 (EST) Received: from nak.isi.edu ([128.9.168.79]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUZQf-0000nk-Em for tsvwg@ietf.org; Wed, 17 Nov 2004 18:41:38 -0500 Received: by nak.isi.edu (Postfix, from userid 3494) id 42B455602FC; Wed, 17 Nov 2004 15:38:30 -0800 (PST) Date: Wed, 17 Nov 2004 15:38:29 -0800 From: Aaron Falk To: "Armando L. Caro, Jr." Message-ID: <20041117233829.GB3574@isi.edu> Mail-Followup-To: "Armando L. Caro, Jr." , tsvwg@ietf.org, xcp@isi.edu References: <20041110223104.GD3444@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Cynicism-Level: 3 Organization: USC ISI X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tsvwg@ietf.org, xcp@isi.edu Subject: [Tsvwg] Re: comments on draft-falk-xcp-spec-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Armando L. Caro, Jr. wrote: > I haven't gone through the draft in detail yet (but I did read the > Sigcomm paper previously), and I have a couple of comments: > > I have another addition to the Security Considerations section: Malicious > Receivers. A receiver can lie about the delta_throughput received > downstream, and put whatever it wants in the feedback field sent back to > the sender. I suppose that this could be addressed by a policer at the > receiving edge similar to the one proposed to combat malicious senders, > but wouldn't that be too much state for it to scale well? Also, is there > enough incentive for these policing functions to be used? Armando- Thanks for your comments. Dina discusses liars and cheaters in her thesis. Specifically, section 7.4 discusses receivers' misconduct. To summarize, receivers can be policed at the edge of the network through boxes which are in the path and can see packets flowing both ways. If a policing box sees negative feedback in packets going to a receiver but that feedback is not being copied into packets destined for a sender, it may take punitive action. Since these boxes are at the edge of the network they are subject to fewer scaling concerns. Note, however, that there is no way for upstream senders or networks to know that policers exist downstream. So, a concerned upstream sender or network may test the 'honesty' of a receiver by occasionally setting some negative feedback and watching for it to be reflected by the receiver. If you have further thoughts on this subject, I invite you to join the XCP mailing list. Details at http://www.isi.edu/isi-xcp. > > Minor fix... > The wording under Malicious Sources in Section 5 should be: > > The XCP algorithms rely on senders to advertise information > ^ Got it. Thanks, --aaron --aaron _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 17 21:32:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18562; Wed, 17 Nov 2004 21:32:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUc8g-0004o0-1s; Wed, 17 Nov 2004 21:35:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUc1O-0002tu-US; Wed, 17 Nov 2004 21:27:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUbrJ-0001M1-6s for tsvwg@megatron.ietf.org; Wed, 17 Nov 2004 21:17:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17414 for ; Wed, 17 Nov 2004 21:17:15 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUbtp-0004VD-P8 for tsvwg@ietf.org; Wed, 17 Nov 2004 21:19:54 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA28648; Wed, 17 Nov 2004 18:16:38 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAI2Gct24804; Wed, 17 Nov 2004 18:16:38 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:16:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] multiaddressing Date: Wed, 17 Nov 2004 18:16:36 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0614067A@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] multiaddressing Thread-Index: AcTLRIMt4DwmUVVxTkGsa7d/UQP0IABs4QeQ From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 18 Nov 2004 02:16:38.0103 (UTC) FILETIME=[A268BE70:01C4CD14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Wesley Eddy [mailto:weddy@grc.nasa.gov]=20 > Sent: Monday, November 15, 2004 1:41 PM > To: tsvwg@ietf.org > Subject: [Tsvwg] multiaddressing >=20 >=20 > Architectures that don't include such wedges are what we were=20 > considering in draft-eddy-tlmarch-00 (presented last week). =20 > The idea of rapidly fixing the transport's path estimation=20 > variables is roughly visible in draft-swami-tcp-lmdr-04. For=20 > architectures that *do* include wedges, some similar form of=20 > signaling and responding to path changes is still _required_.=20 > Signaling has to occur both between the wedge and transport=20 > locally and remotely, so that both half-connections can be=20 > fixed. Responses to these signals will have to be=20 > implemented per-transport protocol. >=20 > It's not entirely clear to me how we can combine the=20 > strengths of a multiaddressing wedge layer with the=20 > rapid-response of path property estimates that we can have=20 > without the wedge in a transport layer mobility scheme. Thoughts? What is not clear? Whether to use the LMDR techniques, or how to invoke them? It doesn't seem that invoking them should be much of a problem-- wedge layers can keep track of when addresses change and do an internal trigger notification. In fact, the=20 proposed LMDR option might not be needed in such a case, and it can all be handled locally, independently by both sides of the connection. What is the status of LMDR? Has it been proposed for any WG activity? =20 Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 17 22:30:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21173; Wed, 17 Nov 2004 22:30:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUd2R-0005mH-Fy; Wed, 17 Nov 2004 22:32:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUcqd-0006n9-CS; Wed, 17 Nov 2004 22:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUcp4-0006al-QG for tsvwg@megatron.ietf.org; Wed, 17 Nov 2004 22:19:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20187 for ; Wed, 17 Nov 2004 22:19:00 -0500 (EST) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUcrb-0005Te-3Y for tsvwg@ietf.org; Wed, 17 Nov 2004 22:21:40 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 0D6DF6BAB9 for ; Wed, 17 Nov 2004 21:55:46 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAI2tjfr022368; Wed, 17 Nov 2004 21:55:45 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id D7E184FC3B; Wed, 17 Nov 2004 21:52:54 -0500 (EST) Date: Wed, 17 Nov 2004 21:52:54 -0500 From: Wesley Eddy To: "Henderson, Thomas R" Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041118025254.GA27014@grc.nasa.gov> References: <6938661A6EDA8A4EA8D1419BCE46F24C0614067A@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0614067A@xch-nw-27.nw.nos.boeing.com> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0946418522==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============0946418522== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2004 at 06:16:36PM -0800, Henderson, Thomas R wrote: > =20 > What is not clear? Whether to use the LMDR techniques, or how > to invoke them? Well, let's start by looking at the claim that a wedge layer is handy because you don't have to modify any transports. The argument is that at least all congestion-controlled transports should be modified, so this advantage of the wedge approaches falls down at least a bit. The wedge approach is still handy for dealing with the book-keeping as addresses come and go, but to me it's pretty clear that we can't leave the transport entirely untouched. If we use a wedge, we have to extend the interface to pass "mobility event" bits up to the transport so that congestion control and other path estimates can be properly dealt with. The exact interface will require some thought. I do not know of any current work on this. > It doesn't seem that invoking them should be > much of a problem-- wedge layers can keep track of when addresses > change and do an internal trigger notification. In fact, the=20 > proposed LMDR option might not be needed in such a case, and it > can all be handled locally, independently by both sides of the > connection. That sounds right to me. The LMDR option arose because Mobile IP masks mobility events totally. If a wedge was to be kindly enough to propagate that information up the stack, then a TCP option wouldn't be needed, we'd just need the TCP path state-reseting behavior in response to triggers from the wedge. =20 > What is the status of LMDR? Has it been proposed for any WG > activity? The current version of the draft has not been discussed in an IETF context yet. I believe that earlier versions have been in either TSVWG or TCPM, although have not generated much interest. Yogesh can probably provide a better answer to this. I think Nokia is exploring it in some internal use, and I know that we've been advocating a similar TCP response to mobility events in NASA's ACAST project (http://acast.grc.nasa.gov), and as a transport modification to aid in planetary exploration missions using mobile devices. -Wes --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBnA6GzBuYqbnj3IwRAmERAJ4x3UQ6eTlCcOwWMTBvYi2T4zUCjwCfYRv6 U6KzLc8tOyj3TnRy/3URPos= =a4/u -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- --===============0946418522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0946418522==-- From tsvwg-bounces@ietf.org Thu Nov 18 10:30:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03637; Thu, 18 Nov 2004 10:30:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUoHn-0003mY-MT; Thu, 18 Nov 2004 10:33:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnqx-0002ju-M7; Thu, 18 Nov 2004 10:05:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnnH-0008Qe-V6 for tsvwg@megatron.ietf.org; Thu, 18 Nov 2004 10:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00476 for ; Thu, 18 Nov 2004 10:01:53 -0500 (EST) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnpu-0003DE-Dj for tsvwg@ietf.org; Thu, 18 Nov 2004 10:04:40 -0500 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id iAIF14sE010968; Thu, 18 Nov 2004 10:01:17 -0500 (EST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <419CB8D4.9080502@stewart.chicago.il.us> Date: Thu, 18 Nov 2004 09:59:32 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ribb Subject: Re: [Tsvwg] could we translate TCP to SCTP with translation mechanism? References: <200411141729.iAEHTZh2014449@mail.cyut.edu.tw> In-Reply-To: <200411141729.iAEHTZh2014449@mail.cyut.edu.tw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit ribb wrote: > Dear all: > > My question is could we translate TCP to SCTP with translation mechanism > such as NAT(NAPT) ? > > thanks a lot. One can do anything.. as my friend Kacheong says.. its only code.. Now.. the bad thing such an approach would do is: a) Break the end2end model b) Hide a lot of SCTP features behind TCP c) possibly cause problems with SCTP's message orientation vs tcp's byte stream.. an app may not like the way a set of TCP packets are "chunk-i-fied". Now in my mind in itself is a big red flag... And overall .. what do you gain.. multi-homing maybe.. but you still would have head of line blocking... I don't see this approach is worth the effort it would require.. I would rather see NAT's and FW just plain learn about SCTP :-D R > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Nov 18 12:48:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15949; Thu, 18 Nov 2004 12:48:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqRd-0007Fw-VR; Thu, 18 Nov 2004 12:51:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUq8w-0005g5-Tj; Thu, 18 Nov 2004 12:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUq1M-0003dJ-L6 for tsvwg@megatron.ietf.org; Thu, 18 Nov 2004 12:24:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13935 for ; Thu, 18 Nov 2004 12:24:33 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUq41-0006df-Es for tsvwg@ietf.org; Thu, 18 Nov 2004 12:27:22 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIHOSb20282; Thu, 18 Nov 2004 19:24:29 +0200 (EET) X-Scanned: Thu, 18 Nov 2004 19:25:46 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAIHPk4n014163; Thu, 18 Nov 2004 19:25:46 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00dVzPhv; Thu, 18 Nov 2004 19:25:45 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIHNSa27159; Thu, 18 Nov 2004 19:23:28 +0200 (EET) Received: from [172.19.11.158] ([172.19.11.158]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 19:23:10 +0200 Message-ID: <419CDA65.5060201@nokia.com> Date: Thu, 18 Nov 2004 11:22:45 -0600 From: Yogesh Prem Swami Organization: Nokia Research Center, Dallas User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] multiaddressing References: <6938661A6EDA8A4EA8D1419BCE46F24C0614067A@xch-nw-27.nw.nos.boeing.com> <20041118025254.GA27014@grc.nasa.gov> In-Reply-To: <20041118025254.GA27014@grc.nasa.gov> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-OriginalArrivalTime: 18 Nov 2004 17:23:10.0885 (UTC) FILETIME=[47089D50:01C4CD93] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Henderson, Thomas R" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1119203231==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1119203231== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD9CBF65BADA98E40379E36F7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9CBF65BADA98E40379E36F7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Wes, Tom, Please see inline: ext Wesley Eddy wrote: > On Wed, Nov 17, 2004 at 06:16:36PM -0800, Henderson, Thomas R wrote: > >>What is the status of LMDR? Has it been proposed for any WG >>activity? > > > The current version of the draft has not been discussed in an IETF > context yet. I believe that earlier versions have been in either TSVWG > or TCPM, although have not generated much interest. Yogesh can probably The old LMDR draft (using just a bit) was presented in TSVWG long time back, but there wasn't enough discussion. (Note that the draft has two parts, detection and response, and the response part should be valid regardless of the detection scheme.) Yogesh --------------enigD9CBF65BADA98E40379E36F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQZzaeoKsoYbjxS8bAQIVSQf/bBiy2PHWw7i7hmMhV86PBIuRvi3fWrjD jJL20srM30NINYl6JlsZIGK7d0oYYq2hD47bNjzbbNWuacibt4AGBz4pIggBuxzA lBASdBdPB8oFs7QF7SXfc+g9PGoGYzgerR6CKNXUIHjecf0n17kQ5vzWDUGchdn2 WEZfWI5l7VnhzI5wCGfRll4l/RHOaYUi7GD2QdKigZ1w5xdrn2NPjiPSBYWlrPiE 22CIOSnzIIgVJ/ucxpgpGwzcAGwxqFRJ5YPJn2oQSB5m9/draGnXHMZqWKJn8xcJ mW+ooFleIgtSpDjnhet3VvQi4y3Qs7LvMAU3/QuuBWLQFLbPbtzD3A== =FzQw -----END PGP SIGNATURE----- --------------enigD9CBF65BADA98E40379E36F7-- --===============1119203231== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1119203231==-- From tsvwg-bounces@ietf.org Mon Nov 22 14:39:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06826; Mon, 22 Nov 2004 14:39:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWK5e-00009B-08; Mon, 22 Nov 2004 14:43:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJy4-000597-Uf; Mon, 22 Nov 2004 14:35:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJq2-0004Bz-03 for tsvwg@megatron.ietf.org; Mon, 22 Nov 2004 14:27:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05554 for ; Mon, 22 Nov 2004 14:27:00 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJtX-0007Ih-QB for tsvwg@ietf.org; Mon, 22 Nov 2004 14:30:40 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAMJQQxg023457 for ; Mon, 22 Nov 2004 19:26:26 GMT Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Nov 2004 14:26:26 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59708995A@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Mon, 22 Nov 2004 14:26:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Tsvwg] draft-silverman-tsvwg-mlefphb-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 TSVWGers, draft-silverman-tsvwg-mlefphb-01 was discussed at the IEPREP meeting at the 61st IETF in D.C. As many of you are no doubt aware, the IEPREP working group is investigating a requirements space connected to providing emergency services comparable to those employed in the PSTN by government or military officials (as opposed to consumers) in emergency circumstances. Many of the envisioned solutions for this space involve the use of various QoS mechanisms that, under the current structure of the Transport Area, tend to be worked on here in TSVWG. At the request of the IEPREP chairs and the document authors, we TSVWG chairs wanted to let you know that the IEPREP WG discussed the possibility of advancing of the mlefphb draft to Experimental. Since the IEPREP WG is not chartered to do mechanism work, presumably the mlefphb draft would have to advance here in TSVWG. Mlefphb is not uncontroversial. A few TSVWGs ago, we say a presentation from Fred Baker that spoke to the original -00 draft of the mlefphb (draft-baker-tsvwg-mlef-concerns). Partly, the -01 version of mlefphb was issued to clarify some of the concerns raised about call admissoin control in the mlef-concerns draft. However, even given this change, the IEPREP group remained divided on whether or not the mlefphb work should be advanced. Given all this, I'd like to ask if anyone here in TSVWG is interested in pursuing the mlefphb draft (for Experimental) here? Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 24 09:30:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27477; Wed, 24 Nov 2004 09:30:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyDy-0000B2-Ej; Wed, 24 Nov 2004 09:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWy39-0003Ce-ES; Wed, 24 Nov 2004 09:23:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWxwv-0001t1-6j for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 09:16:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26347 for ; Wed, 24 Nov 2004 09:16:47 -0500 (EST) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWy0n-0007AK-MD for tsvwg@ietf.org; Wed, 24 Nov 2004 09:20:50 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 6E29B6BA19 for ; Wed, 24 Nov 2004 09:16:15 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAOEGEhJ028816 for ; Wed, 24 Nov 2004 09:16:15 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 380B64FC21; Wed, 24 Nov 2004 09:13:15 -0500 (EST) Date: Wed, 24 Nov 2004 09:13:15 -0500 From: Wesley Eddy To: tsvwg@ietf.org Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041124141315.GB16629@grc.nasa.gov> References: <20041115184047.GA2667@grc.nasa.gov> Mime-Version: 1.0 In-Reply-To: <20041115184047.GA2667@grc.nasa.gov> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238869724==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 --===============0238869724== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2004 at 01:40:47PM -0500, Wesley Eddy wrote: > In draft-crocker-mast-analysis-01 (now expired), the concept of > "multiaddressing" for solving multihoming and mobility problems is > explained. >=20 > The HIP groups and multi6 are focusing on multiaddressing solutions > built for "simple" transports that can only bind to a single address > with no means to update or extend that binding when it might be required > by mobility or multihoming. Adding a wedge-layer to map dynamic locators > to fixed identifiers fixes these problems and allows the transport to go > untouched and remain simple. >=20 I previously brought up the idea that a multiaddressing wedge should at least pass a bit up to the transport to notify it of mobility events. Another consideration, in comparison to systems where the transport does all the book-keeping of addresses and handles mobility and multihoming on its own, is that the transport<->wedge interface will likely not be rich enough for the transport to do the sorts of things that SCTP is capable of, like retransmiting on alternate paths, load balancing between interfaces, etc. I'm not sure that the wedge interface could be made rich enough to support those types of transport decisions without completely negating the benefit of its simplicity, and certainly we don't want the wedge to be doing those types of things silently itself without the transport's consent. It looks like this issue is another point in favor of transport-based mobility/multihoming schemes. I'm still in favor of passing the book-keeping off to a common wedge somehow, but it looks like there's still quite a bit of utility in having the transport be able to query and richly interact with that wedge, rather than have it just transparently "make things work". -Wes --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBpJb7zBuYqbnj3IwRAgpDAJ9tzIZUaLLwpWVtlZn6apBpTOwEbQCeOeGa z14iUMZrnpvnJbOyYIsdmBc= =7hrA -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- --===============0238869724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0238869724==-- From tsvwg-bounces@ietf.org Wed Nov 24 09:32:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27615; Wed, 24 Nov 2004 09:32:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyGE-0000TG-5l; Wed, 24 Nov 2004 09:36:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWy3B-0003DV-7K; Wed, 24 Nov 2004 09:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWy00-0002QH-In for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 09:20:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26513 for ; Wed, 24 Nov 2004 09:19:57 -0500 (EST) Received: from 263.net.cn ([211.150.96.22] helo=smtp.263.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWy3q-0007iM-Pt for tsvwg@ietf.org; Wed, 24 Nov 2004 09:24:00 -0500 Received: from ced202-dgn3vx13 (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id D7363356C1 for ; Wed, 24 Nov 2004 22:19:48 +0800 (CST) (envelope-from cbeibei@263.net) Received: from ced202-dgn3vx13 (unknown [218.2.118.70]) by antispam-2 (Coremail:263(040326)) with SMTP id D9CLAISYpEHkEXZG.1 for ; Wed, 24 Nov 2004 22:19:49 +0800 (CST) X-TEBIE-Originating-IP: [218.2.118.70] Date: Wed, 24 Nov 2004 22:18:46 +0800 From: "=?gb2312?B?sszd7d3t?=" To: "classdraft4" X-mailer: Foxmail 5.0 beta2 [cn] Mime-Version: 1.0 Message-Id: <20041124141948.D7363356C1@smtp.263.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Tsvwg] some problems about draft-baker-diffserv-basic-classes-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0844253105==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 --===============0844253105== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGk6DQoNCiAgSSBoYXZlIHNvbWUgcHJvYmxlbXMgYWJvdXQgZHJhZnQtYmFrZXItZGlmZnNlcnYt YmFzaWMtY2xhc3Nlcy0wNC4NCg0KICAxLldoeSBpcyB0aGUgcHJpb3JpdHkgb2YgTXVsdGltZWRp YSBDb25mZXJlbmNpbmcoZWcuSC4zMjMvVjIgVmlkZW8gY29uZmVyZW5jaW5nKSBsb3dlciB0aGFu IHRlbGVwaG9uZT8gVGhlIGZvcm1lcih2aWRlbykgc29tZXRpbWVzIG5lZWQgdmVyeSBsb3cgZGVs YXksZWcuQ0JSIHZpZGVvLiANCg0KICAyIFVzdWFsbHksdGhlIHNpZ25hbGxpbmcgcHJlY2VkZSB0 aGUgY29ycmVzcG9uZGluZyBzZXJ2aWNlLiBXaHkgZG9lcyB0aGUgc2VydmljZSBjbGFzcyBzaWdu YWxsaW5nIGhhdmUgYSBsb3dlciBwcmlvcml0eSB0aGFuIHRlbGVwaG9uZT8gQW5kIGkgYWxzbyBk b24ndCBrbm93IHdoeSB0aGUgUUFNIGlzIGJlaGluZCBMb3cgTGF0ZW5jeSAgZGF0YSxhbmQgdGhl IGJyb2FkY2FzdCB2aWRlbyBpcyBiZWhpbmQgbXVsdGltZWRpYSBzdHJlYW1pbmc/SW4gbXkgY29u Y2VwdGUsYnJvYWRjYXN0IHZpZGVvIGlzIGluY2x1ZGUgaW4gbXVsdGltZWlkYSBzdHJlYW1pbmcg YW5kIG5lZWQgbGVzcyBkZWxheS4NCiAgDQogIA0KICBUaGFuayB5b3UgdmVyeSBtdWNoISENCgkN Cg0KoaGhoaGhoaGhoaGhoaGhoQ0KDQqhoaGhoaGhoaGhoaGhoaGhQ2FpIEJlaS1iZWkNCqGhoaGh oaGhoaGhoaGhoaFjYmVpYmVpQDI2My5uZXQNCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNC0xMS0y NA0K --===============0844253105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0844253105==-- From tsvwg-bounces@ietf.org Wed Nov 24 10:04:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00605; Wed, 24 Nov 2004 10:04:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWykx-0003tu-0I; Wed, 24 Nov 2004 10:08:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWydZ-0004la-5X; Wed, 24 Nov 2004 10:00:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyYO-0002r9-Be for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 09:55:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29747 for ; Wed, 24 Nov 2004 09:55:30 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWycH-0002jY-6t for tsvwg@ietf.org; Wed, 24 Nov 2004 09:59:33 -0500 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAOEstJ17165; Wed, 24 Nov 2004 09:54:55 -0500 (EST) Received: from KCHAN-2K3.nortelnetworks.com (artpt61r.us.nortel.com [47.140.53.251]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKL3JSV6; Wed, 24 Nov 2004 09:54:54 -0500 Message-Id: <6.0.3.0.0.20041124094227.0487c168@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 24 Nov 2004 09:54:53 -0500 To: =?gb2312?B?sszd7d3t?= From: Kwok Ho Chan Subject: Re: [Tsvwg] some problems about draft-baker-diffserv-basic-classes-0 4 In-Reply-To: <20041124141948.D7363356C1@smtp.263.net> References: <20041124141948.D7363356C1@smtp.263.net> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Kwok Ho Chan , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757407570==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============0757407570== Content-Type: multipart/alternative; boundary="=====================_7402544==.ALT" --=====================_7402544==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Bei-Bei: Thank you for your comments. I think you mis-understood the concepts. The basic-classes draft separates the traffic into different classes based on their traffic characteristics. It does not necessarily mean Multimedia Conferencing is lower than= Telephony, they just needs to be separated. We also recommend some treatment approaches for each Service Class based on each of their traffic characteristics. Please look at (read) the draft this way and let us know if think= differently. Thanks! -- Kwok Ho Chan -- p.s. Are you based in China? It looks like a Chinese name to me. How may you want to use this draft? At 09:18 AM 11/24/2004, =3D?gb2312?B?sszd7d3t?=3D wrote: >Hi: > > I have some problems about draft-baker-diffserv-basic-classes-04. > > 1.Why is the priority of Multimedia Conferencing(eg.H.323/V2 Video=20 > conferencing) lower than telephone? The former(video) sometimes need very= =20 > low delay,eg.CBR video. > > 2 Usually,the signalling precede the corresponding service. Why does=20 > the service class signalling have a lower priority than telephone? And i= =20 > also don't know why the QAM is behind Low Latency data,and the broadcast= =20 > video is behind multimedia streaming?In my concepte,broadcast video is=20 > include in multimeida streaming and need less delay. > > > > Thank you very much!! > > >=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 > >=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Cai Bei-bei >=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1cbeibei@263.net >=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-11-24 > > --=====================_7402544==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bei-Bei:
Thank you for your comments.
I think you mis-understood the concepts.
The basic-classes draft separates the traffic into different=20 classes
based on their traffic characteristics.
It does not necessarily mean Multimedia Conferencing is lower than Telephony,
they just needs to be separated.
We also recommend some treatment approaches for each Service Class based
on each of their traffic characteristics.
Please look at (read) the draft this way and let us know if think differently.
Thanks!
-- Kwok Ho Chan --
p.s. Are you based in China?  It looks like a Chinese name to me.
      How may you want to use this draft?


At 09:18 AM 11/24/2004, =3D?gb2312?B?sszd7d3t?=3D wrote:

Hi:

  I have some problems about draft-baker-diffserv-basic-classes-04.

  1.Why is the priority of Multimedia Conferencing(eg.H.323/V2 Video conferencing) lower than telephone? The former(video) sometimes need very low delay,eg.CBR video.

  2 Usually,the signalling precede the corresponding service. Why does the service class signalling have a lower priority than telephone? And i also don't know why the QAM is behind Low Latency  data,and the broadcast video is behind multimedia streaming?In my concepte,broadcast video is include in multimeida streaming and need less delay.

 
 
  Thank you very much!!
       

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Cai= Bei-bei
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1cbeibei@263.n= et
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12= 004-11-24

 
--=====================_7402544==.ALT-- --===============0757407570== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0757407570==-- From tsvwg-bounces@ietf.org Wed Nov 24 12:24:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12721; Wed, 24 Nov 2004 12:24:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX0wO-0000RI-PJ; Wed, 24 Nov 2004 12:28:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX0c1-0003Qv-Vd; Wed, 24 Nov 2004 12:07:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX0Jo-0007Yp-5o for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 11:48:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09494 for ; Wed, 24 Nov 2004 11:48:33 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX0Nh-0005in-6q for tsvwg@ietf.org; Wed, 24 Nov 2004 11:52:38 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id iAOGmReU049449; Wed, 24 Nov 2004 08:48:27 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 5E1A377AA12; Wed, 24 Nov 2004 11:48:26 -0500 (EST) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [Tsvwg] multiaddressing In-Reply-To: <20041124141315.GB16629@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Smoke On the Water MIME-Version: 1.0 Date: Wed, 24 Nov 2004 11:48:26 -0500 Message-Id: <20041124164826.5E1A377AA12@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0476417722==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============0476417722== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain (This is not really my ball of wax, but a thought ...) > certainly we don't want the wedge to be doing those types of things > silently itself without the transport's consent. Your assumption. Not mine. At the risk of forming an unholy marriage of buzzwords, HIP + XCP == clean separation of concerns (amongst IP, HIP, XCP, TCP/DCCP/SCTP/blah). (Where I use "HIP" to mean some form of node identifier that isn't the IP address and "XCP" to mean some congestion control that is not built into the transport and with fine-grained path information from the path itself.) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBpLtaWyrrWs4yIs4RAiXUAJ4qF06X4pnK4c399W4HS82Vns2d/ACgltqJ cFRjYY1rgkz9uS4j3OJdQ7w= =EG8x -----END PGP SIGNATURE----- --=-=-=-- --===============0476417722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0476417722==-- From tsvwg-bounces@ietf.org Wed Nov 24 12:28:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13263; Wed, 24 Nov 2004 12:28:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX10B-0000cd-7G; Wed, 24 Nov 2004 12:32:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX0qh-0000s4-KR; Wed, 24 Nov 2004 12:22:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX0Wu-00028s-7k for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 12:02:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10779 for ; Wed, 24 Nov 2004 12:02:05 -0500 (EST) Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX0an-0007G2-Ax for tsvwg@ietf.org; Wed, 24 Nov 2004 12:06:10 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B0DB968A09 for ; Wed, 24 Nov 2004 12:01:35 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAOH1ZhJ019621; Wed, 24 Nov 2004 12:01:35 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 4F1004FC21; Wed, 24 Nov 2004 11:58:35 -0500 (EST) Date: Wed, 24 Nov 2004 11:58:35 -0500 From: Wesley Eddy To: Mark Allman Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041124165835.GL16629@grc.nasa.gov> References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> Mime-Version: 1.0 In-Reply-To: <20041124164826.5E1A377AA12@guns.icir.org> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0805840790==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 --===============0805840790== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="64LDleNqNegJ4g97" Content-Disposition: inline --64LDleNqNegJ4g97 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2004 at 11:48:26AM -0500, Mark Allman wrote: >=20 > (This is not really my ball of wax, but a thought ...) >=20 > > certainly we don't want the wedge to be doing those types of things > > silently itself without the transport's consent. >=20 > Your assumption. Not mine. >=20 > At the risk of forming an unholy marriage of buzzwords, HIP + XCP =3D=3D > clean separation of concerns (amongst IP, HIP, XCP, TCP/DCCP/SCTP/blah). >=20 That's not going to work so well, without some heavy modifications. If you let the wedge do load balancing, for example, it's going to be shuffling things the transport sees as going on/off a single virtual path onto multiple paths. Then the wedge will be passing up XCP data from multiple paths to the transport, that looks like it's coming from a single path. How is the transport to interpret this? Would you propose to make the wedge figure that out too by somehow aggregating the XCP data and passing up smoothed versions reflecting the virtual path? -Wes --64LDleNqNegJ4g97 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBpL27zBuYqbnj3IwRAr/AAJ9AR1TJbV3UBxtvxeiyr6DNqq6CDACeJxVv roIK9dX3BBQJWHzKOAU+vhg= =tlAO -----END PGP SIGNATURE----- --64LDleNqNegJ4g97-- --===============0805840790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0805840790==-- From tsvwg-bounces@ietf.org Wed Nov 24 12:34:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14188; Wed, 24 Nov 2004 12:34:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX16K-0000rl-7x; Wed, 24 Nov 2004 12:38:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX0tw-000280-1o; Wed, 24 Nov 2004 12:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX0my-0007f4-6b for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 12:18:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12207 for ; Wed, 24 Nov 2004 12:18:41 -0500 (EST) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX0qq-0000Fv-N9 for tsvwg@ietf.org; Wed, 24 Nov 2004 12:22:46 -0500 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id iAOHGG9i005733; Wed, 24 Nov 2004 12:16:56 -0500 (EST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41A4C172.4070609@stewart.chicago.il.us> Date: Wed, 24 Nov 2004 12:14:26 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] multiaddressing References: <20041115184047.GA2667@grc.nasa.gov> <20041124141315.GB16629@grc.nasa.gov> In-Reply-To: <20041124141315.GB16629@grc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Ok, I will finally comment a bit on this :-0 Wesley Eddy wrote: > On Mon, Nov 15, 2004 at 01:40:47PM -0500, Wesley Eddy wrote: > >>In draft-crocker-mast-analysis-01 (now expired), the concept of >>"multiaddressing" for solving multihoming and mobility problems is >>explained. >> The crocker draft was just an attempt to take the SCTP add-ip draft and duplicate it into a lower level.. I never thought it would work since the reason we have been holding the add-ip draft is the fact that there are security issues with it. These should be solved as soon as we finish the work on the auth draft.. but you can't do that without state which means a shim layer can't do it.. unless you want to mirror all the transport state at a layer below transport.. ughly and far from simple... I know that first hand.. I am working on NAT and SCTP and let me tell you its tricky when restarts can show up .. and thats not even the multi-homing .. just single homed SCTP :-0 >>The HIP groups and multi6 are focusing on multiaddressing solutions >>built for "simple" transports that can only bind to a single address >>with no means to update or extend that binding when it might be required >>by mobility or multihoming. Adding a wedge-layer to map dynamic locators >>to fixed identifiers fixes these problems and allows the transport to go >>untouched and remain simple. >> > > > I previously brought up the idea that a multiaddressing wedge should at > least pass a bit up to the transport to notify it of mobility events. > > Another consideration, in comparison to systems where the transport does > all the book-keeping of addresses and handles mobility and multihoming > on its own, is that the transport<->wedge interface will likely not be > rich enough for the transport to do the sorts of things that SCTP is > capable of, like retransmiting on alternate paths, load balancing > between interfaces, etc. I'm not sure that the wedge interface could be > made rich enough to support those types of transport decisions without > completely negating the benefit of its simplicity, and certainly we > don't want the wedge to be doing those types of things silently itself > without the transport's consent. I just don't see how you can have anything simple below transport doing this.. It just gets more and more complicated.. IMO we should leave it where per-connection state can be maintained so one can do the necessary things... R > > It looks like this issue is another point in favor of transport-based > mobility/multihoming schemes. I'm still in favor of passing the > book-keeping off to a common wedge somehow, but it looks like there's > still quite a bit of utility in having the transport be able to query > and richly interact with that wedge, rather than have it just > transparently "make things work". > > -Wes > > > ------------------------------------------------------------------------ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 24 12:49:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15605; Wed, 24 Nov 2004 12:49:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1KR-0001Hv-5s; Wed, 24 Nov 2004 12:53:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX19r-0006iG-EJ; Wed, 24 Nov 2004 12:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX13h-0004bn-77 for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 12:36:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14481 for ; Wed, 24 Nov 2004 12:35:58 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX17b-0000u1-Ja for tsvwg@ietf.org; Wed, 24 Nov 2004 12:40:04 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAOHY6t17718; Wed, 24 Nov 2004 09:34:07 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAOHY60l072913; Wed, 24 Nov 2004 09:34:06 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAOHY6kq072912; Wed, 24 Nov 2004 09:34:06 -0800 (PST) (envelope-from faber) Date: Wed, 24 Nov 2004 09:34:06 -0800 From: Ted Faber To: Wesley Eddy Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041124173405.GJ71049@pun.isi.edu> References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> Mime-Version: 1.0 In-Reply-To: <20041124165835.GL16629@grc.nasa.gov> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1162706304==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --===============1162706304== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYjDATHXTWnytHRU" Content-Disposition: inline --zYjDATHXTWnytHRU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 24, 2004 at 11:58:35AM -0500, Wesley Eddy wrote: > On Wed, Nov 24, 2004 at 11:48:26AM -0500, Mark Allman wrote: > > > > (This is not really my ball of wax, but a thought ...) > > > > > certainly we don't want the wedge to be doing those types of things > > > silently itself without the transport's consent. > > > > Your assumption. Not mine. > > > > At the risk of forming an unholy marriage of buzzwords, HIP + XCP == > > clean separation of concerns (amongst IP, HIP, XCP, TCP/DCCP/SCTP/blah). > > > > That's not going to work so well, without some heavy modifications. If > you let the wedge do load balancing, for example, it's going to be > shuffling things the transport sees as going on/off a single virtual path > onto multiple paths. Then the wedge will be passing up XCP data from > multiple paths to the transport, that looks like it's coming from a > single path. How is the transport to interpret this? Would you propose > to make the wedge figure that out too by somehow aggregating the XCP > data and passing up smoothed versions reflecting the virtual path? Ummmm, without *some* path continuity/locality congestion control is pretty difficult. How often do you expect paths to change? If it's per-packet with high probability, this is a very tricky thing. If the paths change once a minute (for example), it's a minor issue - not much worse than starting a new connection every minute. You can define an unsolvable problem here. Do you have to? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --zYjDATHXTWnytHRU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBpMYNaUz3f+Zf+XsRAi+NAJ995mlwEBWUeAJSEyFeicUjMoH7vgCggaI4 ThAE2H4SA7SFrm2o7G8su6c= =bwdx -----END PGP SIGNATURE----- --zYjDATHXTWnytHRU-- --===============1162706304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1162706304==-- From tsvwg-bounces@ietf.org Wed Nov 24 12:54:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15931; Wed, 24 Nov 2004 12:54:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1Pl-0001XN-RP; Wed, 24 Nov 2004 12:58:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1KR-0001Cx-Ud; Wed, 24 Nov 2004 12:53:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1E7-0007X4-GA for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 12:46:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15396 for ; Wed, 24 Nov 2004 12:46:44 -0500 (EST) Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1Hi-0001DO-1I for tsvwg@ietf.org; Wed, 24 Nov 2004 12:50:50 -0500 Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id iAOHk2B4005791; Wed, 24 Nov 2004 12:46:08 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0I7P008012OQ3J@lmco.com>; Wed, 24 Nov 2004 12:46:02 -0500 (EST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0I7P00L562OQ8U@lmco.com>; Wed, 24 Nov 2004 12:46:02 -0500 (EST) Received: from EMSS09M02.us.lmco.com ([158.183.26.5]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Nov 2004 12:46:02 -0500 Date: Wed, 24 Nov 2004 12:46:02 -0500 From: "Eagan, Christopher" Subject: RE: [Tsvwg] draft-silverman-tsvwg-mlefphb-01 To: "Peterson, Jon" , tsvwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: RE: [Tsvwg] draft-silverman-tsvwg-mlefphb-01 Thread-Index: AcTSTXSqu6iG5SLmTiOJXUpQmLjGgA== content-class: urn:content-classes:message X-OriginalArrivalTime: 24 Nov 2004 17:46:02.0564 (UTC) FILETIME=[7718B840:01C4D24D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7BIT X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7BIT In response to the question, "Given all this, I'd like to ask if anyone here in TSVWG is interested in pursuing the mlefphb draft (for Experimental) here?"... Yes, MLEF is a needed and helpful mechanism to manage multiple levels of priority, real-time traffic. In the reservation based scheme to protect high priority real-time traffic, MLEF can still provide redundant protection, especially during route changes. Reservation schemes may take several seconds to re-reserve bandwidth on route changes. MLEF can levy the consequences of temporary congestion on the lower priority traffic. In addition, it may be beneficial to commercial mobile communications providers who want to sell different levels of service. For example, the premium service customers would be less likely to experience temporary cut-out's in their conversations when moving between cells. MLEF also provides a mechanism to increase call capacity by allowing the group of lower priority calls to proceed with a degraded level of service. For example, for a 1,500,000 bps rated link, if each call requires 80,000 bps, the link could carry 18 calls with zero packet loss (1,500,000 / 80,000 = 18.75). However, if 5 of the calls were high priority and required zero packet loss, while you allowed up to 10% packet loss on low priority calls, you could accommodate 15 low priority calls in addition to 5 high priority calls for a increase in call capacity of about 10%. This can be taken further with a dual-rate codec rule such as, "All calls will start with a high quality, high b/w codec. If it is recognized that there is network congestion (e.g. via RTCP, ECN, etc.) and the call is low priority, switch to a lower quality, lower bandwidth codec to relieve the network". This dual-rate scheme can further increase the call capacity of a network. MLEF fits in here to protect the high priority traffic while the dual-rate mechanisms adjust. Whether this is fair, good, bad, evil, etc. is a choice that can be made on a case by case basis by the network owners. MLEF is strongly being considered by at least US government working groups for protection of certain defense related traffic. (Being a relative IETF neophyte, I am not sure how this point will resonate.) >From a commercial perspective, this is a market. From a standards perspective, having an experimental RFC for MLEF keeps the IETF community informed of what is being considered for standards in other circles. I think the point has been made that MLEF is not necessarily a stand-alone all-powerful mechanism to handle different priorities of real-time traffic. MLEF is a good tool to fine tune voip networks that have special requirements and circumstances. Chris Eagan Lockheed Martin (301) 240 - 6328 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Nov 24 12:56:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16087; Wed, 24 Nov 2004 12:56:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1Rx-0001ef-N8; Wed, 24 Nov 2004 13:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1Kz-0001Iu-FW; Wed, 24 Nov 2004 12:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1Fk-00089d-Fi for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 12:48:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15500 for ; Wed, 24 Nov 2004 12:48:25 -0500 (EST) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1Je-0001FE-0B for tsvwg@ietf.org; Wed, 24 Nov 2004 12:52:31 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 121C56BA70 for ; Wed, 24 Nov 2004 12:47:56 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAOHlthJ002234; Wed, 24 Nov 2004 12:47:55 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 921514FC21; Wed, 24 Nov 2004 12:44:55 -0500 (EST) Date: Wed, 24 Nov 2004 12:44:55 -0500 From: Wesley Eddy To: Ted Faber Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041124174455.GO16629@grc.nasa.gov> References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: <20041124173405.GJ71049@pun.isi.edu> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0199859699==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============0199859699== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oCBD0SPT9UHZkBMO" Content-Disposition: inline --oCBD0SPT9UHZkBMO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2004 at 09:34:06AM -0800, Ted Faber wrote: > >=20 > > That's not going to work so well, without some heavy modifications. If > > you let the wedge do load balancing, for example, it's going to be > > shuffling things the transport sees as going on/off a single virtual pa= th > > onto multiple paths. Then the wedge will be passing up XCP data from > > multiple paths to the transport, that looks like it's coming from a > > single path. How is the transport to interpret this? Would you propose > > to make the wedge figure that out too by somehow aggregating the XCP > > data and passing up smoothed versions reflecting the virtual path? >=20 > Ummmm, without *some* path continuity/locality congestion control is > pretty difficult. How often do you expect paths to change? If it's > per-packet with high probability, this is a very tricky thing. If the > paths change once a minute (for example), it's a minor issue - not much > worse than starting a new connection every minute. I was talking about load balancing over multiple _static_ paths, and claiming that a wedge could/should not provide this service. Perhaps I wasn't very clear. =20 > You can define an unsolvable problem here. Do you have to? I don't see load balancing over multiple static paths (with congestion control) as unsolvable, It can be done in SCTP. I think we had a minor translation error between what I meant, what I said, and what you read :). -Wes --oCBD0SPT9UHZkBMO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBpMiXzBuYqbnj3IwRAuFAAJ9DZqXyUShYVDBFsQU2Qu+PU81b4wCeNcE2 SwqYPBanRD4Eosipx9NkgNU= =PWy6 -----END PGP SIGNATURE----- --oCBD0SPT9UHZkBMO-- --===============0199859699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0199859699==-- From tsvwg-bounces@ietf.org Wed Nov 24 13:01:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16374; Wed, 24 Nov 2004 13:01:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1WF-0001lU-HL; Wed, 24 Nov 2004 13:05:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1L2-0001KN-3T; Wed, 24 Nov 2004 12:53:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1I3-0000Iy-1d for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 12:50:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15720 for ; Wed, 24 Nov 2004 12:50:47 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1Lw-0001M5-IU for tsvwg@ietf.org; Wed, 24 Nov 2004 12:54:54 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id iAOHoleU050206; Wed, 24 Nov 2004 09:50:47 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 034E577AA12; Wed, 24 Nov 2004 12:50:46 -0500 (EST) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [Tsvwg] multiaddressing In-Reply-To: <20041124165835.GL16629@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Smoke On the Water MIME-Version: 1.0 Date: Wed, 24 Nov 2004 12:50:46 -0500 Message-Id: <20041124175046.034E577AA12@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Ted Faber , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0636416147==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============0636416147== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Wes- > > At the risk of forming an unholy marriage of buzzwords, HIP + XCP == > > clean separation of concerns (amongst IP, HIP, XCP, TCP/DCCP/SCTP/blah). > > That's not going to work so well, without some heavy modifications. I know I'm a little funny, but I don't mind modifying things that don't exist. :-) > If you let the wedge do load balancing, for example, it's going to be > shuffling things the transport sees as going on/off a single virtual > path onto multiple paths. Then the wedge will be passing up XCP data > from multiple paths to the transport, that looks like it's coming from > a single path. How is the transport to interpret this? Would you > propose to make the wedge figure that out too by somehow aggregating > the XCP data and passing up smoothed versions reflecting the virtual > path? I don't understand how XCP could possibly make this situation worse. In a non-XCP world the transport that is trying to assess such a path has the same issues and less information. In the load balancing example you give my head might explode without XCP. TCP will probably settle on the lowest common denominator. Probably. In that case, the information XCP provides sure sounds handy to me --- precisely because implicit information will look like such a tangled mess. HIP+XCP sure sounds like an interesting avenue to think about from here. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBpMn1WyrrWs4yIs4RAiXSAJ93Pw4W8SF1xZ0RvNKHHibBJkV6XgCdF/Ze kal9uAPUhu03BuoWSPYZaOI= =JROp -----END PGP SIGNATURE----- --=-=-=-- --===============0636416147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0636416147==-- From tsvwg-bounces@ietf.org Wed Nov 24 13:22:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18046; Wed, 24 Nov 2004 13:22:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1qw-0002Tv-Ky; Wed, 24 Nov 2004 13:26:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1hu-0007iN-CU; Wed, 24 Nov 2004 13:17:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1aP-0005J0-Ex for tsvwg@megatron.ietf.org; Wed, 24 Nov 2004 13:09:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16883 for ; Wed, 24 Nov 2004 13:09:46 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1eI-0001xy-Q7 for tsvwg@ietf.org; Wed, 24 Nov 2004 13:13:52 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAOI7tt29211; Wed, 24 Nov 2004 10:07:55 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAOI7t8h073416; Wed, 24 Nov 2004 10:07:55 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAOI7sP2073415; Wed, 24 Nov 2004 10:07:54 -0800 (PST) (envelope-from faber) Date: Wed, 24 Nov 2004 10:07:54 -0800 From: Ted Faber To: Wesley Eddy Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041124180754.GK71049@pun.isi.edu> References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> Mime-Version: 1.0 In-Reply-To: <20041124174455.GO16629@grc.nasa.gov> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0642078675==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da --===============0642078675== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/ZYM6PqDyfNytx60" Content-Disposition: inline --/ZYM6PqDyfNytx60 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 24, 2004 at 12:44:55PM -0500, Wesley Eddy wrote: > On Wed, Nov 24, 2004 at 09:34:06AM -0800, Ted Faber wrote: > > You can define an unsolvable problem here. Do you have to? > > I don't see load balancing over multiple static paths (with congestion > control) as unsolvable, It can be done in SCTP. I think we had a minor > translation error between what I meant, what I said, and what you read > :). Good diagnosis, doc. :-) Multiple static paths is trickier than single paths but solvable. I think Mark's point of separations of concerns is right on here. Each path would be congestion controlled individually and the balancer could pick. But since each path is basically a transport connection, why not put the load balancer above transport, say in the application where it has some app-based knowledge of how to prioritize traffic? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --/ZYM6PqDyfNytx60 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBpM36aUz3f+Zf+XsRAsCAAKCpzIaxSKx3DosOKQfa1SH9w4PUrACdHAEE lj9yCJh862G05B1jzvDzVjM= =xGF8 -----END PGP SIGNATURE----- --/ZYM6PqDyfNytx60-- --===============0642078675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0642078675==-- From tsvwg-bounces@ietf.org Thu Nov 25 06:45:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01566; Thu, 25 Nov 2004 06:45:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXI87-0000tV-Re; Thu, 25 Nov 2004 06:49:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXI19-0006ED-AM; Thu, 25 Nov 2004 06:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXHwR-0005Yc-RR for tsvwg@megatron.ietf.org; Thu, 25 Nov 2004 06:37:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01087 for ; Thu, 25 Nov 2004 06:37:37 -0500 (EST) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXI0U-0000ll-JI for tsvwg@ietf.org; Thu, 25 Nov 2004 06:41:52 -0500 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id iAPBb79i007905; Thu, 25 Nov 2004 06:37:09 -0500 (EST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41A5C370.5000100@stewart.chicago.il.us> Date: Thu, 25 Nov 2004 06:35:12 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] multiaddressing References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> In-Reply-To: <20041124174455.GO16629@grc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Ted Faber , tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Wesley Eddy wrote: > On Wed, Nov 24, 2004 at 09:34:06AM -0800, Ted Faber wrote: > >>>That's not going to work so well, without some heavy modifications. If >>>you let the wedge do load balancing, for example, it's going to be >>>shuffling things the transport sees as going on/off a single virtual path >>>onto multiple paths. Then the wedge will be passing up XCP data from >>>multiple paths to the transport, that looks like it's coming from a >>>single path. How is the transport to interpret this? Would you propose >>>to make the wedge figure that out too by somehow aggregating the XCP >>>data and passing up smoothed versions reflecting the virtual path? >> >>Ummmm, without *some* path continuity/locality congestion control is >>pretty difficult. How often do you expect paths to change? If it's >>per-packet with high probability, this is a very tricky thing. If the >>paths change once a minute (for example), it's a minor issue - not much >>worse than starting a new connection every minute. > > > > I was talking about load balancing over multiple _static_ paths, and > claiming that a wedge could/should not provide this service. Perhaps I > wasn't very clear. > > > >>You can define an unsolvable problem here. Do you have to? > > > I don't see load balancing over multiple static paths (with congestion > control) as unsolvable, It can be done in SCTP. I think we had a minor > translation error between what I meant, what I said, and what you read > :). Jana at the U-Del is doing his PHd thesis on this very thing. There are several papers on the subject at: http://pel.cis.udel.edu/ (look for Concurrent Multipath Transfer - CMT) R > > -Wes > > > ------------------------------------------------------------------------ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Nov 25 06:49:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01838; Thu, 25 Nov 2004 06:49:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXIBg-0000yO-8K; Thu, 25 Nov 2004 06:53:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXI3D-0006g2-0D; Thu, 25 Nov 2004 06:44:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXI0J-000673-DP for tsvwg@megatron.ietf.org; Thu, 25 Nov 2004 06:41:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01225 for ; Thu, 25 Nov 2004 06:41:36 -0500 (EST) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXI4M-0000pO-EB for tsvwg@ietf.org; Thu, 25 Nov 2004 06:45:51 -0500 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id iAPBfP9i007911; Thu, 25 Nov 2004 06:41:25 -0500 (EST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41A5C472.8030405@stewart.chicago.il.us> Date: Thu, 25 Nov 2004 06:39:30 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [Tsvwg] multiaddressing References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> In-Reply-To: <20041124180754.GK71049@pun.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Ted Faber wrote: > On Wed, Nov 24, 2004 at 12:44:55PM -0500, Wesley Eddy wrote: > >>On Wed, Nov 24, 2004 at 09:34:06AM -0800, Ted Faber wrote: >> >>>You can define an unsolvable problem here. Do you have to? >> >>I don't see load balancing over multiple static paths (with congestion >>control) as unsolvable, It can be done in SCTP. I think we had a minor >>translation error between what I meant, what I said, and what you read >>:). > > > > Good diagnosis, doc. :-) > > Multiple static paths is trickier than single paths but solvable. Yep > > I think Mark's point of separations of concerns is right on here. Each > path would be congestion controlled individually and the balancer could > pick. But since each path is basically a transport connection, why not > put the load balancer above transport, say in the application where it > has some app-based knowledge of how to prioritize traffic? > Well.. that works sort of.. except there are other problems.. when a path switch occurs fast during the balancing you will get a problem with the way the cwnd's grow (some of Jana's earlier work shows this.... the only solution we found .. if the transport is not invovled is to disable fast retransmit... which is ugly)... And as far as XCP goes.. I would not hold ones breath waiting for routers to provide all this wonderful information... it can be done but its expensive and not something your likely to see in production anytime soon. R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Nov 25 12:00:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29617; Thu, 25 Nov 2004 12:00:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXN3I-0000Dv-SI; Thu, 25 Nov 2004 12:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXMsF-0002TN-NX; Thu, 25 Nov 2004 11:53:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXMnc-0001RV-IZ for tsvwg@megatron.ietf.org; Thu, 25 Nov 2004 11:48:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28171 for ; Thu, 25 Nov 2004 11:48:50 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m19.mx.aol.com ([64.12.137.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXMrj-0008Mc-Fs for tsvwg@ietf.org; Thu, 25 Nov 2004 11:53:07 -0500 Received: from Mpierce1@aol.com by imo-m19.mx.aol.com (mail_out_v37_r3.8.) id g.1ee.2f8ed066 (16633); Thu, 25 Nov 2004 11:48:14 -0500 (EST) Message-ID: <1ee.2f8ed066.2ed766ce@aol.com> Date: Thu, 25 Nov 2004 11:48:14 EST Subject: Re: [Tsvwg] draft-silverman-tsvwg-mlefphb-01 To: jon.peterson@neustar.biz, tsvwg@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0470281702==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============0470281702== Content-Type: multipart/alternative; boundary="part1_1ee.2f8ed066.2ed766ce_boundary" --part1_1ee.2f8ed066.2ed766ce_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, I believe it is very important to discuss MLEF in order to move it forward in some way. While it would clearly be better to get WG consensus to forward it for approval (probably as an Experimental), the authors could also progress it as an individual submission to the RFC editor. In the latter case, the authors would want to first resolve whatever concerns are raised by participants in the group. Since Jon mentioned the previous draft-baker-tsvwg-mlef-concerns, I need to say that the authors feel they have properly addressed the specific MLEF-related issues raised, especially by making it clear that MLEF is not a stand-alone solution and must work in conjunction with other mechanisms such as Call (Session) Admission Control. It is important that disucssion be held on the specifics described in MLEF with a clear understanding that it is not intended to be a service description for the "Assured Service" defined in draft-pierce-tsvwg-assured-service-req. That is, it only addresses one of the "preferential treatment" mechanisms which, together with other mechanisms already defined or to be defined, is expected to yield the overall "assured service" capabilities which are required by certain organizations. I am primarily interested in its potential use within the US Defense Department Network. I believe Chris Eagan described very well the need we have for this capability. Mike Pierce Artel --part1_1ee.2f8ed066.2ed766ce_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable To all,

I believe it is very important to discuss MLEF in order to move it forwa= rd in some way. While it would clearly be better to get WG consensus to forw= ard it for approval (probably as an Experimental), the authors could also pr= ogress it as an individual submission to the RFC editor. In the latter case,= the authors would want to first resolve whatever concerns are raised by par= ticipants in the group.

Since Jon mentioned the previous draft-baker-tsvwg-mlef-concerns, I need= to say that the authors feel they have properly addressed the specific MLEF= -related issues raised, especially by making it clear that MLEF is not a sta= nd-alone solution and must work in conjunction with other mechanisms such as= Call (Session) Admission Control.

It is important that disucssion be held on the specifics described in ML= EF with a clear understanding that it is not intended to be a service descri= ption for the "Assured Service" defined in draft-pierce-tsvwg-assured-servic= e-req. That is, it only addresses one of the "preferential treatment" mechan= isms which, together with other mechanisms already defined or to be defined,= is expected to yield the overall "assured service" capabilities which are r= equired by certain organizations. I am primarily interested in its potential= use within the US Defense Department Network. I believe Chris Eagan describ= ed very well the need we have for this capability.

Mike Pierce
Artel
--part1_1ee.2f8ed066.2ed766ce_boundary-- --===============0470281702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0470281702==-- From tsvwg-bounces@ietf.org Fri Nov 26 16:58:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27207; Fri, 26 Nov 2004 16:58:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXoBN-0000V1-Ot; Fri, 26 Nov 2004 17:03:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXo4B-0005kG-7a; Fri, 26 Nov 2004 16:55:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXo1L-0005Sz-29 for tsvwg@megatron.ietf.org; Fri, 26 Nov 2004 16:52:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26825 for ; Fri, 26 Nov 2004 16:52:49 -0500 (EST) Received: from drake.interchange.ubc.ca ([142.103.145.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXo5e-0000HK-Cj for tsvwg@ietf.org; Fri, 26 Nov 2004 16:57:21 -0500 Received: from portal9.itservices.ubc.ca (portal9.itservices.ubc.ca [142.103.134.16]) by mta2.interchange.ubc.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I7T007ZW3FYHS@mta2.interchange.ubc.ca> for tsvwg@ietf.org; Fri, 26 Nov 2004 13:52:46 -0800 (PST) Date: Fri, 26 Nov 2004 13:52:46 -0800 (PST) Date-warning: Date header was inserted by mta2.interchange.ubc.ca From: humaira To: tsvwg@ietf.org Message-id: <8704695.1101505966322.JavaMail.myubc2@portal9.itservices.ubc.ca> MIME-version: 1.0 X-Mailer: uPortal WEB email client 3.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7BIT Subject: [Tsvwg] SCTP latency X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7BIT Hi, We have been looking at SCTP (one-to-one style) latency performance on a basic socket application (described below), and compared the results obtained with an equivalent TCP application. We are using lksctp-2.6.6 on Linux kernel 2.6.7. According to our results SCTP is an order of magnitude slower than TCP. Other people have mentioned that they have done similar latency tests and have obtained similar outputs. (Reference: http://sourceforge.net/mailarchive/forum.php?thread_id=5987343&forum_id=1856 ) We are very interested in finding out where, deep down, SCTP is spending so much time since this is just a vanilla sctp port. We would have expected to see SCTP performance comparable to TCP on a clean network. We have read other postings on the subject such as http://www1.ietf.org/mail-archive/web/tsvwg/current/msg04879.html which mention CRC32c as a possible performance overhead in sctp. However, looking at the order of difference in our results it seems unlikely that CRC32C is the only factor here. It would be very helpful if somebody could provide insight into other factors for this behavior. Thank you for your help. Humaira Our application does the following. There are two nodes (one Pentium II, 400.9MHz and the other Pentium III, 999.981MHz both with Linux 2.6.7) Node1 sends a message of size X to Node2 and then receives message of size X from Node2. Node2 does the opposite,i.e.receives message size X from Node1 and then sends message size X to Node1. We measure the time taken to carry out this operation using rdtsc which returns the number of Pentium clock cycles. The above operation was repeated 1000 times and the time obtained is the average of these 1000 iterations. We warm-up the cache before doing any time measurement. Our SCTP program uses the one-to-one style and we send and receive using sctp_sendmsg and sctp_recvmsg. The TCP counterpart simply uses send and recv. The NODELAY option is set to 1 in both SCTP and TCP (i.e.Nagles's algorithm is disabled). The default values for socket send and receive buffers was used in both cases. In our case the default tcp socket send and receive buffer sizes were 16384 and 87380 respectively and the default SCTP socket send and receive buffer sizes were both 110592. The results for different message sizes are copied below. Latency results for TCP Msg_size=1 tsecs=0.000176 Msg_size=2 tsecs=0.000176 Msg_size=4 tsecs=0.000168 Msg_size=8 tsecs=0.000169 Msg_size=16 tsecs=0.000175 Msg_size=32 tsecs=0.000175 Msg_size=64 tsecs=0.000186 Msg_size=128 tsecs=0.000219 Msg_size=256 tsecs=0.000261 Msg_size=512 tsecs=0.000371 Msg_size=1024 tsecs=0.000571 Msg_size=2048 tsecs=0.000856 Msg_size=4096 tsecs=0.001182 Msg_size=8192 tsecs=0.001905 Msg_size=16384 tsecs=0.003300 Msg_size=32768 tsecs=0.006069 Msg_size=65536 tsecs=0.011681 Msg_size=131072 tsecs=0.022805 Msg_size=262144 tsecs=0.045151 Msg_size=524288 tsecs=0.089808 Msg_size=1048576 tsecs=0.178923 Msg_size=2097152 tsecs=0.357190 Latency results for SCTP Msg_size=1 tsecs=0.005685 Msg_size=2 tsecs=0.005686 Msg_size=4 tsecs=0.005697 Msg_size=8 tsecs=0.005693 Msg_size=16 tsecs=0.005700 Msg_size=32 tsecs=0.005706 Msg_size=64 tsecs=0.005704 Msg_size=128 tsecs=0.005726 Msg_size=256 tsecs=0.005738 Msg_size=512 tsecs=0.005733 Msg_size=1024 tsecs=0.005772 Msg_size=2048 tsecs=0.007902 Msg_size=4096 tsecs=0.002706 Msg_size=8192 tsecs=0.004739 Msg_size=16384 tsecs=0.023130 Msg_size=32768 tsecs=0.048449 Msg_size=65536 tsecs=0.050129 Msg_size=131072 tsecs=0.078571 Msg_size=262144 tsecs=0.258564 Msg_size=524288 tsecs=0.716646 Msg_size=1048576 tsecs=0.981830 Msg_size=2097152 tsecs=2.056492 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 09:46:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25781; Mon, 29 Nov 2004 09:46:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYmsL-0002yq-Oz; Mon, 29 Nov 2004 09:51:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYmY5-0000Ti-7K; Mon, 29 Nov 2004 09:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYmKm-0005ng-8F for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 09:16:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23374 for ; Mon, 29 Nov 2004 09:16:54 -0500 (EST) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYmPf-0002Eu-25 for tsvwg@ietf.org; Mon, 29 Nov 2004 09:22:01 -0500 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id iATEGf84011635; Mon, 29 Nov 2004 09:16:44 -0500 (EST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41AB2EE7.5020502@stewart.chicago.il.us> Date: Mon, 29 Nov 2004 09:15:03 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: humaira Subject: Re: [Tsvwg] SCTP latency References: <8704695.1101505966322.JavaMail.myubc2@portal9.itservices.ubc.ca> In-Reply-To: <8704695.1101505966322.JavaMail.myubc2@portal9.itservices.ubc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Humaria: Comments below... humaira wrote: > Hi, > > We have been looking at SCTP (one-to-one style) latency performance > on a basic socket application (described below), and compared the > results obtained with an equivalent TCP application. We are using > lksctp-2.6.6 on Linux kernel 2.6.7. According to our results SCTP is > an order of magnitude slower than TCP. Other people have mentioned > that they have done similar latency tests and have obtained similar > outputs. (Reference: > http://sourceforge.net/mailarchive/forum.php?thread_id=5987343&forum_id=1856 > ) We are very interested in finding out where, deep down, SCTP is > spending so much time since this is just a vanilla sctp port. We > would have expected to see SCTP performance comparable to TCP on a > clean network. > > We have read other postings on the subject such as > http://www1.ietf.org/mail-archive/web/tsvwg/current/msg04879.html > which mention CRC32c as a possible performance overhead in sctp. > However, looking at the order of difference in our results it seems > unlikely that CRC32C is the only factor here. CRC32c is a large part of the performance difference... however I think in the case of lk-sctp it is more an issue with a new stack. I have just completed most of another performance pass on the KAME-Bsd stack and I get much better numbers then you did... I hope to re-run my tests and get both a gprof output and a transfer throughput to post on my web site.... As to what I was seeing roughly.. My network was: P-IV-2.8Gig dell server <------------------> IBM Laptop T-40 (1.5Gig M Pentium) 1000Mbit copper via 2950 cisco switches Sending from the Dell box to the IBM I saw: 0.0 53.925576 # rb:0 size:2000000000:sctp: (296.705222 Megabits per sec) 0.0 54.160244 # rb:0 size:2000000000:tcp: (295.419644 Megabits per sec) 0.0 53.914660 # rb:0 size:2000000000:sctp: (296.765295 Megabits per sec) 0.0 54.082463 # rb:0 size:2000000000:tcp: (295.844514 Megabits per sec) The above is what comes out of my test utility.. it runs the same code only with TCP or SCTP using the SOCK_STREAM (or 1 to 1 model). Now watching the CPU idle'ness the Dell (sending side) seemed to run about 55% idle while sending TCP and 50% idle while sending SCTP. The IBM laptop (receiving side) tendend to run about 58% idle on the TCP pass but only 30% idle on the SCTP passes.. Another important note here is that both machines have a TCP offload on the NIC I am using.. this means that the TCP connections do not suffer any extra time for the checksum.. Testing on my laptop locally... KAME-BSD by default will disable the CRC32c (controlable by a sysctl), I get over the loopback with the CRC disabled about 3Gigbit's per second .. however if I change the sysctl and run it with the CRC enabled I drop to 600Megabit... Now when I reverse things and have my P-IV be the receiver things get a bit more interesting.. I zip up to about 400Megabit with SCTP slightly faster... however in looking at TCP and SCTP I am seeing fast retransmissions.. this tells me I am loosing packets.. and since I use cat-5 wire I think this is my problem (I even took the switch out and did a back-2-back wire and had the same problem)... Note that I am quite a bit faster on the transfer the opposite way.. this tells me that I still need to work on the receive path of KAME-Bsd.. I really need to write my own steam-lined sctp_soreceive instead of using the stock one.. this, I think, could get the BSD stack close to the same idle time on receive.. I am hoping... I have noted too that message sizes play a big role in the transfer... TCP can always pack down a full MTU.. SCTP is limited in this, somewhat, in that it must fragment to its max size and can do bundling but not always will the pieces fit together. To pull this out of the factor (since I don't have an app that does message framing for a fair comparison) I use 1452 has the message write size... This is the largest chunk of data that SCTP can place in one packet... for FreeBSD (which is what I was using 4.10) the max TCP stuffs is about 1448 (I think timestamps is the reason)... > > It would be very helpful if somebody could provide insight into other > factors for this behavior. > > Thank you for your help. Humaira > > Our application does the following. There are two nodes (one Pentium > II, 400.9MHz and the other Pentium III, 999.981MHz both with Linux > 2.6.7) Node1 sends a message of size X to Node2 and then receives > message of size X from Node2. Node2 does the opposite,i.e.receives > message size X from Node1 and then sends message size X to Node1. > > We measure the time taken to carry out this operation using rdtsc > which returns the number of Pentium clock cycles. The above operation > was repeated 1000 times and the time obtained is the average of these > 1000 iterations. We warm-up the cache before doing any time > measurement. > > Our SCTP program uses the one-to-one style and we send and receive > using sctp_sendmsg and sctp_recvmsg. The TCP counterpart simply uses > send and recv. The NODELAY option is set to 1 in both SCTP and TCP > (i.e.Nagles's algorithm is disabled). The default values for socket > send and receive buffers was used in both cases. In our case the > default tcp socket send and receive buffer sizes were 16384 and 87380 > respectively and the default SCTP socket send and receive buffer > sizes were both 110592. > > The results for different message sizes are copied below. > > Latency results for TCP Msg_size=1 tsecs=0.000176 Msg_size=2 > tsecs=0.000176 Msg_size=4 tsecs=0.000168 Msg_size=8 tsecs=0.000169 > Msg_size=16 tsecs=0.000175 Msg_size=32 tsecs=0.000175 Msg_size=64 > tsecs=0.000186 Msg_size=128 tsecs=0.000219 Msg_size=256 > tsecs=0.000261 Msg_size=512 tsecs=0.000371 Msg_size=1024 > tsecs=0.000571 Msg_size=2048 tsecs=0.000856 Msg_size=4096 > tsecs=0.001182 Msg_size=8192 tsecs=0.001905 Msg_size=16384 > tsecs=0.003300 Msg_size=32768 tsecs=0.006069 Msg_size=65536 > tsecs=0.011681 Msg_size=131072 tsecs=0.022805 Msg_size=262144 > tsecs=0.045151 Msg_size=524288 tsecs=0.089808 Msg_size=1048576 > tsecs=0.178923 Msg_size=2097152 tsecs=0.357190 > Does your TCP app do actuall message framing? I.e. are you doing a read and then processing the buffer to frame it correctly? Also is this just one message transfered? I.e. are you incurring the a connection setup per message? Maybe we can share the test utilties we are using.. I can gladly post mine (or email it to you) and I could run yours on my setup as well.. R > Latency results for SCTP Msg_size=1 tsecs=0.005685 Msg_size=2 > tsecs=0.005686 Msg_size=4 tsecs=0.005697 Msg_size=8 tsecs=0.005693 > Msg_size=16 tsecs=0.005700 Msg_size=32 tsecs=0.005706 Msg_size=64 > tsecs=0.005704 Msg_size=128 tsecs=0.005726 Msg_size=256 > tsecs=0.005738 Msg_size=512 tsecs=0.005733 Msg_size=1024 > tsecs=0.005772 Msg_size=2048 tsecs=0.007902 Msg_size=4096 > tsecs=0.002706 Msg_size=8192 tsecs=0.004739 Msg_size=16384 > tsecs=0.023130 Msg_size=32768 tsecs=0.048449 Msg_size=65536 > tsecs=0.050129 Msg_size=131072 tsecs=0.078571 Msg_size=262144 > tsecs=0.258564 Msg_size=524288 tsecs=0.716646 Msg_size=1048576 > tsecs=0.981830 Msg_size=2097152 tsecs=2.056492 > > > _______________________________________________ tsvwg mailing list > tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 12:30:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12084; Mon, 29 Nov 2004 12:30:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpQx-0006vu-U7; Mon, 29 Nov 2004 12:35:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpDa-0000v1-Lq; Mon, 29 Nov 2004 12:21:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYp6I-0005zI-Pm for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 12:14:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09860 for ; Mon, 29 Nov 2004 12:14:08 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpBF-0006WN-10 for tsvwg@ietf.org; Mon, 29 Nov 2004 12:19:17 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 212A332896; Mon, 29 Nov 2004 12:14:09 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 176FE328AF; Mon, 29 Nov 2004 12:14:07 -0500 (EST) Date: Mon, 29 Nov 2004 12:14:06 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Mark Allman Subject: Re: [Tsvwg] multiaddressing In-Reply-To: <20041124175046.034E577AA12@guns.icir.org> Message-ID: References: <20041124175046.034E577AA12@guns.icir.org> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Ted Faber , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi Mark/all, > > If you let the wedge do load balancing, for example, it's going to be > > shuffling things the transport sees as going on/off a single virtual > > path onto multiple paths. Then the wedge will be passing up XCP data > > from multiple paths to the transport, that looks like it's coming from > > a single path. How is the transport to interpret this? Would you > > propose to make the wedge figure that out too by somehow aggregating > > the XCP data and passing up smoothed versions reflecting the virtual > > path? > > I don't understand how XCP could possibly make this situation worse. In > a non-XCP world the transport that is trying to assess such a path has > the same issues and less information. In the load balancing example you > give my head might explode without XCP. TCP will probably settle on the > lowest common denominator. Probably. In that case, the information XCP > provides sure sounds handy to me --- precisely because implicit > information will look like such a tangled mess. Implicit feedback is a mess if the transport is unaware of the existence of multiple paths. If the transport is aware of multiple paths, and has knowledge of data scheduling on multiple paths (as against a wedge/shim under the transport), load balancing can be done without anybody's head exploding. Such a transport *can* separate per-path information, of course with added effort. We have managed to get SCTP to do exactly this separation - see http://www.cis.udel.edu/~iyengar/publications/2004.spects.iyengar.pdf regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 12:49:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13942; Mon, 29 Nov 2004 12:49:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpjb-0007Mw-En; Mon, 29 Nov 2004 12:54:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpTh-0004k0-BW; Mon, 29 Nov 2004 12:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpQp-0003ua-Uk for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 12:35:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12712 for ; Mon, 29 Nov 2004 12:35:21 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpVm-00073L-Lh for tsvwg@ietf.org; Mon, 29 Nov 2004 12:40:30 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 262C3328C1; Mon, 29 Nov 2004 12:35:23 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 7A69732896; Mon, 29 Nov 2004 12:35:21 -0500 (EST) Date: Mon, 29 Nov 2004 12:35:21 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Ted Faber Subject: Re: [Tsvwg] multiaddressing In-Reply-To: <20041124180754.GK71049@pun.isi.edu> Message-ID: References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 > > I don't see load balancing over multiple static paths (with congestion > > control) as unsolvable, It can be done in SCTP. I think we had a minor I agree. See our work on Concurrent Multipath Transfer - http://www.cis.udel.edu/~iyengar/publications/ > I think Mark's point of separations of concerns is right on here. Each > path would be congestion controlled individually and the balancer could > pick. Each path can also be congestion controlled individually within the transport itself. > But since each path is basically a transport connection, why not put the > load balancer above transport, say in the application where it has some > app-based knowledge of how to prioritize traffic? I want to point out a subtle difference here. Though each path is close to a transport connection, there is significant information sharing that occurs across paths within a transport connection used over the multiple paths. Looking at throughput as a measure of performance, we found that using an application with multiple transport connections on individual paths performs significantly worse than using a single transport connection that spans multiple paths (See http://www.cis.udel.edu/~iyengar/publications/2004.icon.iyengar.pdf, Figure 1, Figure 6 and Section V-A in particular). This performance difference was an unexpected result for us, as we were hoping that CMT would match up to the performance of an ideal load balancer at the application layer (AppStripe). CMT outperformed AppStripe by a significant measure. I agree that app-based knowledge of traffic prioritization is not used, we assume throughput to be our measure of performance. regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 13:22:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16590; Mon, 29 Nov 2004 13:22:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqEw-00083y-Jx; Mon, 29 Nov 2004 13:27:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq7l-000370-86; Mon, 29 Nov 2004 13:19:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq5b-0002qq-7b for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 13:17:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16364 for ; Mon, 29 Nov 2004 13:17:28 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqAY-0007ye-3f for tsvwg@ietf.org; Mon, 29 Nov 2004 13:22:38 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iATIEjQ18123; Mon, 29 Nov 2004 10:14:45 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iATIEjEw006710; Mon, 29 Nov 2004 10:14:45 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iATIEiqY006709; Mon, 29 Nov 2004 10:14:44 -0800 (PST) (envelope-from faber) Date: Mon, 29 Nov 2004 10:14:44 -0800 From: Ted Faber To: Randall Stewart Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041129181444.GB5502@pun.isi.edu> References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> <41A5C472.8030405@stewart.chicago.il.us> Mime-Version: 1.0 In-Reply-To: <41A5C472.8030405@stewart.chicago.il.us> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1019779826==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============1019779826== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This may be responding more to Jana's mail, but I'm going to be a little lazy and leave it here where I typed it. I am bad. On Thu, Nov 25, 2004 at 06:39:30AM -0500, Randall Stewart wrote: > Ted Faber wrote: > >I think Mark's point of separations of concerns is right on here. Each > >path would be congestion controlled individually and the balancer could > >pick. But since each path is basically a transport connection, why not > >put the load balancer above transport, say in the application where it > >has some app-based knowledge of how to prioritize traffic? > > > Well.. that works sort of.. except there are other problems.. when > a path switch occurs fast during the balancing you will get a > problem with the way the cwnd's grow (some of Jana's earlier work > shows this.... the only solution we found .. if the transport is not > invovled is to disable fast retransmit... which is ugly)... I haven't tried to do this, but (I'm assuming that you'll just disregard the rest of this paragraph, as you should) it's clear that the load balancer needs to have some special magic in it. It seems to me that just putting a bunch of transport connections down and striping the data with no regard for the properties of the application and the transport will have problems. A good load balancer would need to take into account how aggressive each transport needs to be (for example, the folks in DCCP are finding out that TFRC behaves oddly if it's supporting a fixed rate connection and slow/fixed connections in XCP may confuse the fairness algorithm). Even a system like TCP needs to probe the network for spare capacity or reduced capacity. For applications that send data that's of different value (bits that make the background look spiffy vs. bits that draw an opponent in a vidoe game, perhaps) the balancer might want to take that into account, too. Those are all hard problems, and it's not clear there are good, efficient (economical?) solutions. Still, I don't see how tackling them in the transport makes things any easier and in the case of integrating application info, it makes it harder. IMHO, transport should provide a set of quasi-static (the paths change infrequently) congestion controlled pipes that the application can use to do its work. My design sense says that transport should provide a building block that can be used to implement this multiaddressing/multipath load balancing/mobility thingie. Are there simple changes to transport that would help this? Are there a few things that this multiaddressing/multipath load balancing/mobility thingie would require of transport connections that would facilitate building using transport connections? Answering that question seems more fruitful to me than trying to put a big new function in transport. And if it turns out to be easier than I think it is to build a multiaddressing/multipath load balancing/mobility thingie, migrate it down the stack when it's done. > > And as far as XCP goes.. I would not hold ones breath waiting > for routers to provide all this wonderful information... it can > be done but its expensive and not something your likely to see > in production anytime soon. Yeah, I understand some of the problems and I'd like to understand more. I do think that XCP has been pretty clever at minimizing new state needed in the routers, but there are lots of questions about doing the computations. I'm not expecting to see it tomorrow, but with all the additional computing power Moore keeps bringing, it's probably wise to think about how we can use it to help with congestion, if we can. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBq2cUaUz3f+Zf+XsRAr4AAKDJc+p224InQJCiereQfLuXCLiXJACfUXjQ 4eJm69+qcVUXCZOqGByULqM= =XFVA -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- --===============1019779826== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1019779826==-- From tsvwg-bounces@ietf.org Mon Nov 29 14:46:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23758; Mon, 29 Nov 2004 14:46:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrYk-0001T2-WA; Mon, 29 Nov 2004 14:51:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrPo-0007mn-KV; Mon, 29 Nov 2004 14:42:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrJu-00074z-2j for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 14:36:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22830 for ; Mon, 29 Nov 2004 14:36:21 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrOq-0001DT-Ve for tsvwg@ietf.org; Mon, 29 Nov 2004 14:41:30 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 675CD32902; Mon, 29 Nov 2004 14:35:47 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 7272E32896; Mon, 29 Nov 2004 14:35:45 -0500 (EST) Date: Mon, 29 Nov 2004 14:35:45 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Ted Faber Subject: Re: [Tsvwg] multiaddressing In-Reply-To: <20041129181444.GB5502@pun.isi.edu> Message-ID: References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> <41A5C472.8030405@stewart.chicago.il.us> <20041129181444.GB5502@pun.isi.edu> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Randall Stewart , tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi Ted/all, > I haven't tried to do this, but (I'm assuming that you'll just disregard > the rest of this paragraph, as you should) it's clear that the load > balancer needs to have some special magic in it. It seems to me that > just putting a bunch of transport connections down and striping the data > with no regard for the properties of the application and the transport > will have problems. A good load balancer would need to take into > account how aggressive each transport needs to be (for example, the > folks in DCCP are finding out that TFRC behaves oddly if it's supporting > a fixed rate connection and slow/fixed connections in XCP may confuse the > fairness algorithm). Even a system like TCP needs to probe the network > for spare capacity or reduced capacity. For applications that send data > that's of different value (bits that make the background look spiffy vs. > bits that draw an opponent in a vidoe game, perhaps) the balancer might > want to take that into account, too. > > Those are all hard problems, and it's not clear there are good, > efficient (economical?) solutions. Still, I don't see how tackling them > in the transport makes things any easier and in the case of integrating > application info, it makes it harder. I agree. As far as solving problems is concerned, load balancing in the transport is probably no simpler than in the application. The application has better knowledge and understanding of the application's needs and demands, and the transport has better understanding of path/network characteristics. Either ways, information may need to be consolidated and exchanged across layers. > IMHO, transport should provide a set of quasi-static (the paths change > infrequently) congestion controlled pipes that the application can use > to do its work. My design sense says that transport should provide a > building block that can be used to implement this > multiaddressing/multipath load balancing/mobility thingie. > > Are there simple changes to transport that would help this? Are there a > few things that this multiaddressing/multipath load balancing/mobility > thingie would require of transport connections that would facilitate > building using transport connections? Answering that question seems > more fruitful to me than trying to put a big new function in transport. > And if it turns out to be easier than I think it is to build a > multiaddressing/multipath load balancing/mobility thingie, migrate it > down the stack when it's done. An application layer solution migrated down the stack still remains a solution *on top of* the transport layer, not *in* the transport layer. I do not think that developing a solution inside of transport is the same as developing a solution on top of transport, and migrating it down. I have found that there are benefits in doing load balancing *in* the transport, as against *on top of* the transport. These performance benefits may not dictate design choices, but IMHO, are certainly of value in making these choices. regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 14:59:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24897; Mon, 29 Nov 2004 14:59:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrl0-0001kj-RZ; Mon, 29 Nov 2004 15:04:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYray-0001oY-2X; Mon, 29 Nov 2004 14:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrW8-0000aI-51 for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 14:49:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24027 for ; Mon, 29 Nov 2004 14:48:58 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrb2-0001WP-SF for tsvwg@ietf.org; Mon, 29 Nov 2004 14:54:08 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA10449; Mon, 29 Nov 2004 11:48:04 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iATJm2i20308; Mon, 29 Nov 2004 11:48:02 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 11:48:03 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Tsvwg] multiaddressing Date: Mon, 29 Nov 2004 11:48:02 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060929@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] multiaddressing Thread-Index: AcTSS/92cEakUxZNSzWLhdhMH1hr+wD/N95w From: "Henderson, Thomas R" To: "Randall Stewart" , X-OriginalArrivalTime: 29 Nov 2004 19:48:03.0021 (UTC) FILETIME=[567E8FD0:01C4D64C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us]=20 > Sent: Wednesday, November 24, 2004 9:14 AM > To: weddy@grc.nasa.gov > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] multiaddressing >=20 >=20 > Ok, I will finally comment a bit on this :-0 >=20 > Wesley Eddy wrote: > > On Mon, Nov 15, 2004 at 01:40:47PM -0500, Wesley Eddy wrote: > >=20 > >>In draft-crocker-mast-analysis-01 (now expired), the concept of > >>"multiaddressing" for solving multihoming and mobility problems is > >>explained. > >> >=20 > The crocker draft was just an attempt to take the > SCTP add-ip draft and duplicate it into a lower level.. I never > thought it would work since the reason we have been holding > the add-ip draft is the fact that there are security issues > with it. These should be solved as soon as we finish the > work on the auth draft.. but you can't do that without state which > means a shim layer can't do it.. unless you want to mirror all > the transport state at a layer below transport.. ughly and far > from simple... I know that first hand.. I am working on NAT > and SCTP and let me tell you its tricky when restarts can > show up .. and thats not even the multi-homing .. just single > homed SCTP :-0 > > > I just don't see how you can have anything simple below transport > doing this.. It just gets more and more complicated.. IMO we should > leave it where per-connection state can be maintained so one can > do the necessary things... >=20 When you say "all the transport state", what do you mean? I do not see it as being that daunting, perhaps because I don't assume that a wedge implementation completely virtualizes all of the possible network paths so that transport is unaware of path changes. The wedge layer proposals (multi6 and HIP) assume that the wedge works out the security issues in binding addresses to hosts. And probably the NAT issues in the future as well. That leaves the congestion=20 control, which should be tied somehow to distinct paths (distinct=20 address pairs?). =20 SCTP implementations will support multiple paths, so they probably=20 won't not need much change at all in such a scenario. TCP doesn't support mobility, failover, or load balancing. Depending on how=20 ambitious one decided to be at the wedge layer, one might try to=20 duplicate all of SCTP's capability there (probably not), but at least=20 a simple cwnd/ssthresh reset upon path change detection at the wedge=20 layer should not be that difficult, and would allow mobility and = failover multihoming to work correctly. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 17:32:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21312; Mon, 29 Nov 2004 17:32:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYu9U-0001B1-D5; Mon, 29 Nov 2004 17:37:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtze-0002gY-Nz; Mon, 29 Nov 2004 17:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtrj-0005hL-AP for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 17:19:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19353 for ; Mon, 29 Nov 2004 17:19:25 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtwh-0000cX-Fz for tsvwg@ietf.org; Mon, 29 Nov 2004 17:24:36 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id EB0043291A; Mon, 29 Nov 2004 17:15:32 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 84E06328E9; Mon, 29 Nov 2004 17:15:30 -0500 (EST) Date: Mon, 29 Nov 2004 17:15:02 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Ted Faber Subject: Re: [Tsvwg] multiaddressing (private) In-Reply-To: Message-ID: References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> <41A5C472.8030405@stewart.chicago.il.us> <20041129181444.GB5502@pun.isi.edu> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Randall Stewart , tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi Ted/all, I thought I should add one more point to my earlier response: > > IMHO, transport should provide a set of quasi-static (the paths change > > infrequently) congestion controlled pipes that the application can use > > to do its work. My design sense says that transport should provide a > > building block that can be used to implement this > > multiaddressing/multipath load balancing/mobility thingie. > > > > Are there simple changes to transport that would help this? Are there a > > few things that this multiaddressing/multipath load balancing/mobility > > thingie would require of transport connections that would facilitate > > building using transport connections? Answering that question seems > > more fruitful to me than trying to put a big new function in transport. > > And if it turns out to be easier than I think it is to build a > > multiaddressing/multipath load balancing/mobility thingie, migrate it > > down the stack when it's done. There is also the question of what services are common enough to be pushed into a common layer below the application layer, to avoid repeated implementations in applications. If load balancing is a service that most applications would use (if provided) for increased throughput, the service should, IMHO, be provided in transport. When there are demonstrable benefits in adding some services to transport, is there a reason for keeping such services outside transport? regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 18:35:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26786; Mon, 29 Nov 2004 18:35:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYv8h-0002Y7-HL; Mon, 29 Nov 2004 18:41:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYv1G-0003BM-8T; Mon, 29 Nov 2004 18:33:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuz8-0002Ht-Hg for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 18:31:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26463 for ; Mon, 29 Nov 2004 18:31:08 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYv48-0002SE-56 for tsvwg@ietf.org; Mon, 29 Nov 2004 18:36:20 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iATNSIQ15864; Mon, 29 Nov 2004 15:28:18 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iATNSIsa009978; Mon, 29 Nov 2004 15:28:18 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iATNSIYb009977; Mon, 29 Nov 2004 15:28:18 -0800 (PST) (envelope-from faber) Date: Mon, 29 Nov 2004 15:28:18 -0800 From: Ted Faber To: Janardhan Iyengar Subject: Re: [Tsvwg] multiaddressing (private) Message-ID: <20041129232818.GC9132@pun.isi.edu> References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> <41A5C472.8030405@stewart.chicago.il.us> <20041129181444.GB5502@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Randall Stewart , tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574879103==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============1574879103== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uh9ZiVrAOUUm9fzH" Content-Disposition: inline --uh9ZiVrAOUUm9fzH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 29, 2004 at 05:15:02PM -0500, Janardhan Iyengar wrote: > Hi Ted/all, > > I thought I should add one more point to my earlier response: > > > > IMHO, transport should provide a set of quasi-static (the paths change > > > infrequently) congestion controlled pipes that the application can use > > > to do its work. My design sense says that transport should provide a > > > building block that can be used to implement this > > > multiaddressing/multipath load balancing/mobility thingie. > > > > > > Are there simple changes to transport that would help this? Are there a > > > few things that this multiaddressing/multipath load balancing/mobility > > > thingie would require of transport connections that would facilitate > > > building using transport connections? Answering that question seems > > > more fruitful to me than trying to put a big new function in transport. > > > And if it turns out to be easier than I think it is to build a > > > multiaddressing/multipath load balancing/mobility thingie, migrate it > > > down the stack when it's done. > > There is also the question of what services are common enough to be pushed > into a common layer below the application layer, to avoid repeated > implementations in applications. If load balancing is a service that most > applications would use (if provided) for increased throughput, the service > should, IMHO, be provided in transport. When there are demonstrable > benefits in adding some services to transport, is there a reason for > keeping such services outside transport? I imagine you've herad the rumors that there might be layers between transport (4) and application (7). I haven't really seen them, either, but it seems this load-balancing whatsis might be a good thing to put there, at least conceptually. :-) I say this because I have a hard time imagining one load-balancing whatsis that is good for everyone, but with DCCP & TCP and maybe XCP out there, I can imagine a reasonably sized set of load-balancing whatsi that snap on top of the various transports (maybe more than one transport at once) and provide different types of load balancing behavior. You might want to implement your whatsi in libraries or call them protocol layers. I think there may be reasons to think of them either way. I think that approach lets me keep simple transports (well, simplish - TCP and SCTP are somewhat intricate) while trying out some of these load balancing ideas in a way that can be passed around between apps and developers as well. You do need the transports to play nice - maybe export current estimated throughput and RTT info - but I like the modularity of talking to transports rather than subsuming transports better. Now, it may be that the cost of that modularity is crushing, but I didn't hear you say that layering cost was the showstopper. Did I just miss that? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --uh9ZiVrAOUUm9fzH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBq7CSaUz3f+Zf+XsRAlY0AJ44NmWn8Q+Ia+48PnQKY+UKwXyM3QCglgt6 0HuMbsZi9f3ZBhV9l7ELJIA= =AYBN -----END PGP SIGNATURE----- --uh9ZiVrAOUUm9fzH-- --===============1574879103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1574879103==-- From tsvwg-bounces@ietf.org Mon Nov 29 18:37:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26941; Mon, 29 Nov 2004 18:37:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYvAi-0002bM-W3; Mon, 29 Nov 2004 18:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYv1J-0003C8-QW; Mon, 29 Nov 2004 18:33:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYv0S-0002m9-Kp for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 18:32:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26507 for ; Mon, 29 Nov 2004 18:32:30 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYv5S-0002TH-FX for tsvwg@ietf.org; Mon, 29 Nov 2004 18:37:42 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iATNUNQ16402; Mon, 29 Nov 2004 15:30:23 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iATNUNwg009994; Mon, 29 Nov 2004 15:30:23 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iATNUNEb009993; Mon, 29 Nov 2004 15:30:23 -0800 (PST) (envelope-from faber) Date: Mon, 29 Nov 2004 15:30:23 -0800 From: Ted Faber To: Janardhan Iyengar Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041129233023.GD9132@pun.isi.edu> References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> <41A5C472.8030405@stewart.chicago.il.us> <20041129181444.GB5502@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Randall Stewart , tsvwg@ietf.org, Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0495668795==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============0495668795== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tEFtbjk+mNEviIIX" Content-Disposition: inline --tEFtbjk+mNEviIIX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 29, 2004 at 02:35:45PM -0500, Janardhan Iyengar wrote: > An application layer solution migrated down the stack still remains a > solution *on top of* the transport layer, not *in* the transport layer. I > do not think that developing a solution inside of transport is the same as > developing a solution on top of transport, and migrating it down. I have > found that there are benefits in doing load balancing *in* the transport, > as against *on top of* the transport. These performance benefits may not > dictate design choices, but IMHO, are certainly of value in making these > choices. I'm a slow thinker. Can you give me an example of a benefit to doing load balancing in transport that's not an implementation workaround, but a problem with using the transport service to do what you want? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --tEFtbjk+mNEviIIX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBq7EPaUz3f+Zf+XsRAhVFAJ4rKwahKjP+toybO+K/uGHwZuK3MACfS3xF RTJOuULTHMCXVFxKr2XA+uY= =+35h -----END PGP SIGNATURE----- --tEFtbjk+mNEviIIX-- --===============0495668795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0495668795==-- From tsvwg-bounces@ietf.org Mon Nov 29 19:31:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01581; Mon, 29 Nov 2004 19:31:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYw0S-0003oU-Nl; Mon, 29 Nov 2004 19:36:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYvtL-0001Wg-6u; Mon, 29 Nov 2004 19:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYvr2-0000yh-HI for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 19:26:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00706 for ; Mon, 29 Nov 2004 19:26:49 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYvw2-0003ci-Kx for tsvwg@ietf.org; Mon, 29 Nov 2004 19:32:03 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA18366; Mon, 29 Nov 2004 16:25:50 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAU0Pjx29615; Mon, 29 Nov 2004 18:25:46 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 16:25:47 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Tsvwg] multiaddressing Date: Mon, 29 Nov 2004 16:25:47 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] multiaddressing Thread-Index: AcTWbM6c+Y4R5Ta4QKO8hR4OckJUkgAATKlQ From: "Henderson, Thomas R" To: "Ted Faber" X-OriginalArrivalTime: 30 Nov 2004 00:25:47.0098 (UTC) FILETIME=[230EEBA0:01C4D673] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ted Faber [mailto:faber@ISI.EDU]=20 > Sent: Monday, November 29, 2004 3:30 PM > To: Janardhan Iyengar > Cc: Randall Stewart; tsvwg@ietf.org; Mark Allman > Subject: Re: [Tsvwg] multiaddressing >=20 > I'm a slow thinker. Can you give me an example of a benefit to doing > load balancing in transport that's not an implementation=20 > workaround, but > a problem with using the transport service to do what you want? >=20 How do applications learn of and propagate multiple address sets across which they can open multiple transport streams and load balance across them? DNS? It's probably not a good idea to create additional DNS dependencies. Applications themselves? Then you burden applications with learning the addresses and communicating them across to the peer, and it gets messy when NATs are involved (IP addresses in application data streams are deprecated). This question probably boils down to what do we want the transport/application API to look like-- do applications connect to hosts, or to IP addresses? If hosts (which would seem to be consistent with the terminology of RFC 793-- TCP as a "host-to-host" protocol), then we should probably think about offering load balancing in the stack somewhere. Then the question becomes (as you put it in the previous message) whether we can do a good enough job in the transport to provide a *common* load balancing service that has enough utility to multiple applications. Of course, if these services do not work in the stack, applications will reinvent them (SIP Reinvite, for example), and we shouldn't prevent anyone from using atomic building blocks at the application layer if they so choose, but it is worth considering from a performance and architecture standpoint whether transport should do applications a favor by providing such a mode of operation, and then whether it is of enough common benefit and worth the trouble. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 21:05:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09075; Mon, 29 Nov 2004 21:05:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxT7-00062T-Mh; Mon, 29 Nov 2004 21:10:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxJM-0006e5-6p; Mon, 29 Nov 2004 21:00:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxBA-0004ZX-PM for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 20:51:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08019 for ; Mon, 29 Nov 2004 20:51:43 -0500 (EST) Received: from pacific.interchange.ubc.ca ([142.103.145.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxGB-0005hE-Fy for tsvwg@ietf.org; Mon, 29 Nov 2004 20:56:56 -0500 Received: from portal9.itservices.ubc.ca (portal9.itservices.ubc.ca [142.103.134.16]) by mta1.interchange.ubc.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I7Y00F4AYI4L9@mta1.interchange.ubc.ca> for tsvwg@ietf.org; Mon, 29 Nov 2004 17:51:40 -0800 (PST) Date: Mon, 29 Nov 2004 17:51:40 -0800 (PST) Date-warning: Date header was inserted by mta1.interchange.ubc.ca From: humaira Subject: Re: [Tsvwg] SCTP latency To: Randall Stewart Message-id: <29694870.1101779500490.JavaMail.myubc2@portal9.itservices.ubc.ca> MIME-version: 1.0 X-Mailer: uPortal WEB email client 3.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7BIT Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7BIT Hi, Thank you for your reply, it helps a lot. Can you point us to where we can find design documentation about KAME SCTP implementation? We had a few questions about your tests on KAME-Bsd stack. The first one is about the 2Gbyte message size in the output of your test utility. We have been experimenting with sending large messages in lksctp, however, it is limited by the default send buffer size and sctp_sendmsg fails for message sizes above SO_SNDBUF size. (Reference: http://sourceforge.net/mailarchive/message.php?msg_id=9664532). Therefore, we break-up messages that are larger than the send buffer size into multiple smaller messages that can be handled by lksctp and then reassemble them into one large message at the receiving side. Is KAME capable of sending and receiving messages to the order of 2Gbytes on its own without requiring the user to break it up? If so, does KAME use some sort of kernel buffering? Your results for CPU idleness on IBM laptop are very interesting. Is the 30% idle figure for SCTP receiver because of the CRC32c overhead on the slower machine or something else? We would be very glad to make use of your test utility. We are emailing our basic socket application to you (For others: if you want a copy, please let me know). Regarding your question about our application, we are not incurring connection setup per message. The connection is established once and then we send a few messages to warm-up the cache before doing any time measurements. Different sized messages are sent in a for-loop on the same socket. Each message X of some particular size is sent and received a 1000 times and the time taken is the average of these 1000 iterations. Our TCP application is not currently doing message framing, which is of course something that should be added to it in order to make the comparison fair, but we were a bit surprised to see the order of difference in our TCP and SCTP latencies in our initial results to attribute it only to the lack of message framing. Thank you for your help. Humaira -----Original Message----- > Date: Mon Nov 29 06:15:03 PST 2004 > From: "Randall Stewart" > Subject: Re: [Tsvwg] SCTP latency > To: > > Humaria: > > Comments below... > > humaira wrote: > > Hi, > > > > We have been looking at SCTP (one-to-one style) latency performance > > on a basic socket application (described below), and compared the > > results obtained with an equivalent TCP application. We are using > > lksctp-2.6.6 on Linux kernel 2.6.7. According to our results SCTP is > > an order of magnitude slower than TCP. Other people have mentioned > > that they have done similar latency tests and have obtained similar > > outputs. (Reference: > > http://sourceforge.net/mailarchive/forum.php?thread_id=5987343&forum_id=1856 > > ) We are very interested in finding out where, deep down, SCTP is > > spending so much time since this is just a vanilla sctp port. We > > would have expected to see SCTP performance comparable to TCP on a > > clean network. > > > > We have read other postings on the subject such as > > http://www1.ietf.org/mail-archive/web/tsvwg/current/msg04879.html > > which mention CRC32c as a possible performance overhead in sctp. > > However, looking at the order of difference in our results it seems > > unlikely that CRC32C is the only factor here. > > CRC32c is a large part of the performance difference... however I think > in the case of lk-sctp it is more an issue with a new stack. I have just > completed most of another performance pass on the KAME-Bsd stack and > I get much better numbers then you did... I hope to re-run my tests > and get both a gprof output and a transfer throughput to post on > my web site.... > > As to what I was seeing roughly.. > > My network was: > > P-IV-2.8Gig dell server <------------------> IBM Laptop T-40 (1.5Gig > M Pentium) > > 1000Mbit copper via > 2950 cisco switches > > > Sending from the Dell box to the IBM I saw: > 0.0 53.925576 # rb:0 size:2000000000:sctp: (296.705222 Megabits per sec) > 0.0 54.160244 # rb:0 size:2000000000:tcp: (295.419644 Megabits per sec) > 0.0 53.914660 # rb:0 size:2000000000:sctp: (296.765295 Megabits per sec) > 0.0 54.082463 # rb:0 size:2000000000:tcp: (295.844514 Megabits per sec) > > The above is what comes out of my test utility.. it runs the same code > only with TCP or SCTP using the SOCK_STREAM (or 1 to 1 model). > > Now watching the CPU idle'ness the Dell (sending side) seemed to run > about 55% idle while sending TCP and 50% idle while sending SCTP. > > The IBM laptop (receiving side) tendend to run about 58% idle on the > TCP pass but only 30% idle on the SCTP passes.. > > Another important note here is that both machines have a TCP offload > on the NIC I am using.. this means that the TCP connections do not > suffer any extra time for the checksum.. > > Testing on my laptop locally... KAME-BSD by default will disable the > CRC32c (controlable by a sysctl), I get over the loopback with the > CRC disabled about 3Gigbit's per second .. however if I change the > sysctl and run it with the CRC enabled I drop to 600Megabit... > > Now when I reverse things and have my P-IV be the receiver things > get a bit more interesting.. I zip up to about 400Megabit with > SCTP slightly faster... however in looking at TCP and SCTP I > am seeing fast retransmissions.. this tells me I am loosing > packets.. and since I use cat-5 wire I think this is my > problem (I even took the switch out and did a back-2-back > wire and had the same problem)... > > Note that I am quite a bit faster on the transfer the opposite > way.. this tells me that I still need to work on the > receive path of KAME-Bsd.. I really need to write my > own steam-lined sctp_soreceive instead of using the > stock one.. this, I think, could get the BSD stack > close to the same idle time on receive.. I am hoping... > > I have noted too that message sizes play a big role > in the transfer... TCP can always pack down a > full MTU.. SCTP is limited in this, somewhat, in that > it must fragment to its max size and can do bundling > but not always will the pieces fit together. > > To pull this out of the factor (since I don't have an > app that does message framing for a fair comparison) > I use 1452 has the message write size... This is the > largest chunk of data that SCTP can place in one > packet... for FreeBSD (which is what I was using 4.10) the > max TCP stuffs is about 1448 (I think timestamps is the > reason)... > > > > > > It would be very helpful if somebody could provide insight into other > > factors for this behavior. > > > > Thank you for your help. Humaira > > > > Our application does the following. There are two nodes (one Pentium > > II, 400.9MHz and the other Pentium III, 999.981MHz both with Linux > > 2.6.7) Node1 sends a message of size X to Node2 and then receives > > message of size X from Node2. Node2 does the opposite,i.e.receives > > message size X from Node1 and then sends message size X to Node1. > > > > We measure the time taken to carry out this operation using rdtsc > > which returns the number of Pentium clock cycles. The above operation > > was repeated 1000 times and the time obtained is the average of these > > 1000 iterations. We warm-up the cache before doing any time > > measurement. > > > > Our SCTP program uses the one-to-one style and we send and receive > > using sctp_sendmsg and sctp_recvmsg. The TCP counterpart simply uses > > send and recv. The NODELAY option is set to 1 in both SCTP and TCP > > (i.e.Nagles's algorithm is disabled). The default values for socket > > send and receive buffers was used in both cases. In our case the > > default tcp socket send and receive buffer sizes were 16384 and 87380 > > respectively and the default SCTP socket send and receive buffer > > sizes were both 110592. > > > > The results for different message sizes are copied below. > > > > Latency results for TCP Msg_size=1 tsecs=0.000176 Msg_size=2 > > tsecs=0.000176 Msg_size=4 tsecs=0.000168 Msg_size=8 tsecs=0.000169 > > Msg_size=16 tsecs=0.000175 Msg_size=32 tsecs=0.000175 Msg_size=64 > > tsecs=0.000186 Msg_size=128 tsecs=0.000219 Msg_size=256 > > tsecs=0.000261 Msg_size=512 tsecs=0.000371 Msg_size=1024 > > tsecs=0.000571 Msg_size=2048 tsecs=0.000856 Msg_size=4096 > > tsecs=0.001182 Msg_size=8192 tsecs=0.001905 Msg_size=16384 > > tsecs=0.003300 Msg_size=32768 tsecs=0.006069 Msg_size=65536 > > tsecs=0.011681 Msg_size=131072 tsecs=0.022805 Msg_size=262144 > > tsecs=0.045151 Msg_size=524288 tsecs=0.089808 Msg_size=1048576 > > tsecs=0.178923 Msg_size=2097152 tsecs=0.357190 > > > > Does your TCP app do actuall message framing? I.e. are you doing > a read and then processing the buffer to frame it correctly? > > Also is this just one message transfered? I.e. are you incurring > the a connection setup per message? > > Maybe we can share the test utilties we are using.. I can gladly > post mine (or email it to you) and I could run yours > on my setup as well.. > > R > > > Latency results for SCTP Msg_size=1 tsecs=0.005685 Msg_size=2 > > tsecs=0.005686 Msg_size=4 tsecs=0.005697 Msg_size=8 tsecs=0.005693 > > Msg_size=16 tsecs=0.005700 Msg_size=32 tsecs=0.005706 Msg_size=64 > > tsecs=0.005704 Msg_size=128 tsecs=0.005726 Msg_size=256 > > tsecs=0.005738 Msg_size=512 tsecs=0.005733 Msg_size=1024 > > tsecs=0.005772 Msg_size=2048 tsecs=0.007902 Msg_size=4096 > > tsecs=0.002706 Msg_size=8192 tsecs=0.004739 Msg_size=16384 > > tsecs=0.023130 Msg_size=32768 tsecs=0.048449 Msg_size=65536 > > tsecs=0.050129 Msg_size=131072 tsecs=0.078571 Msg_size=262144 > > tsecs=0.258564 Msg_size=524288 tsecs=0.716646 Msg_size=1048576 > > tsecs=0.981830 Msg_size=2097152 tsecs=2.056492 > > > > > > _______________________________________________ tsvwg mailing list > > tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 22:06:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13105; Mon, 29 Nov 2004 22:06:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYyR2-00076f-0w; Mon, 29 Nov 2004 22:12:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYyKS-0005Ko-HY; Mon, 29 Nov 2004 22:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYyIR-0004xN-Q9 for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 22:03:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13014 for ; Mon, 29 Nov 2004 22:03:17 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYyNT-00073K-Bj for tsvwg@ietf.org; Mon, 29 Nov 2004 22:08:31 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAU301Q07702; Mon, 29 Nov 2004 19:00:01 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAU301XN011274; Mon, 29 Nov 2004 19:00:01 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAU301nb011273; Mon, 29 Nov 2004 19:00:01 -0800 (PST) (envelope-from faber) Date: Mon, 29 Nov 2004 19:00:01 -0800 From: Ted Faber To: "Henderson, Thomas R" Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041130030000.GE9132@pun.isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0437635805==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 --===============0437635805== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8vCeF2GUdMpe9ZbK" Content-Disposition: inline --8vCeF2GUdMpe9ZbK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 29, 2004 at 04:25:47PM -0800, Henderson, Thomas R wrote: > > > > -----Original Message----- > > From: Ted Faber [mailto:faber@ISI.EDU] > > Sent: Monday, November 29, 2004 3:30 PM > > To: Janardhan Iyengar > > Cc: Randall Stewart; tsvwg@ietf.org; Mark Allman > > Subject: Re: [Tsvwg] multiaddressing > > > > I'm a slow thinker. Can you give me an example of a benefit to doing > > load balancing in transport that's not an implementation > > workaround, but > > a problem with using the transport service to do what you want? > > > > How do applications learn of and propagate multiple address sets > across which they can open multiple transport streams and load > balance across them? DNS? It's probably not a good idea to create > additional DNS dependencies. Why *not* DNS? It's a distributed replicated 1-to-many database. It already returns lists of network addresses associated with a string, and there's a well-known API to get at those. I don't understand the additional dependency created here unless the endpoints were not exchanging DNS names to begin with. > Applications themselves? Then you > burden applications with learning the addresses and communicating > them across to the peer, and it gets messy when NATs are involved > (IP addresses in application data streams are deprecated). NATs are sure a problem if you want to go passing IP addresses around. That's not a problem introduced by multi-{addressing,homing}. Any protocol that wants to redirect has it. Not using IP addresses won't save you - SMTP accross a NAT may fail because the DNS reverse mapping that the endpoint believes in isn't the same one that a (paranoia) server sees. I don't have an easy answer to the problem of how an endpoint identifies itself to another endpoint when the endpoint doesn't know its own name, but I'm pretty sure that getting a list of names doesn't make it any harder than getting one. I understand you want to add another layer of indirection here, but I don't see why that layer needs to be resolved in transport, nor really what you'd save by doing so. (I'm a little fuzzy on why you need one at all). > > This question probably boils down to what do we want the > transport/application API to look like-- do applications connect to > hosts, or to IP addresses? If hosts (which would seem to be consistent > with the terminology of RFC 793-- TCP as a "host-to-host" protocol), > then we should probably think about offering load balancing in the > stack somewhere. Then the question becomes (as you put it in the > previous message) whether we can do a good enough job in the > transport to provide a *common* load balancing service that has > enough utility to multiple applications. There's a lot of space between transport and application. It's perfectly reasonable to insert a {library, protocol layer} in there if you want to create an idea that the application writer looks up a name and communicates with the named entity without changing the meaning of an IP address to TCP or another existing protocol. You're going to have to multiplex from "multiname" to multiple IP addresses (or transport connections) either way. Even if you had a transport protocol that would accept packets from an array of names for the other end, sending a packet requires picking the destination address to send to. You don't save any work doing it in transport, and you lose any possibilty to cleanly build on the transport. > > Of course, if these services do not work in the stack, applications > will reinvent them (SIP Reinvite, for example), and we shouldn't > prevent anyone from using atomic building blocks at the application > layer if they so choose, but it is worth considering from a > performance and architecture standpoint whether transport should do > applications a favor by providing such a mode of operation, and > then whether it is of enough common benefit and worth the trouble. I understand the efficiency concerns. It's very unclear to me that these dominate at this point. Until it's clear that they do, or that there's a big layering violation I still think that the right place to attack this is above transport (and not necessarily in the app). -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --8vCeF2GUdMpe9ZbK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBq+IwaUz3f+Zf+XsRAqruAKCuEgF7gqLa5SjTt96PhXElHIbd4ACgh3L9 Jdd70UXzQo3rqNw9LSALgfw= =LWdH -----END PGP SIGNATURE----- --8vCeF2GUdMpe9ZbK-- --===============0437635805== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0437635805==-- From tsvwg-bounces@ietf.org Mon Nov 29 22:58:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16871; Mon, 29 Nov 2004 22:58:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYzFB-00088N-Aq; Mon, 29 Nov 2004 23:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYz7p-0007pV-U1; Mon, 29 Nov 2004 22:56:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYz6c-0007dW-3A for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 22:55:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16700 for ; Mon, 29 Nov 2004 22:55:08 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYzBd-00083l-DA for tsvwg@ietf.org; Mon, 29 Nov 2004 23:00:22 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2004 21:01:37 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAU3sU9N005062 for ; Mon, 29 Nov 2004 19:54:30 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA17228 for ; Mon, 29 Nov 2004 19:54:35 -0800 (PST) Message-Id: <4.3.2.7.2.20041129213955.0250ce98@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Nov 2004 21:54:42 -0600 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Tsvwg] Reviews of RSVP extensions (here, there, or ... ?) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hey WG In the DC meeting of TSVWG, a distinguished person questioned at the microphone whether or not TSVWG was the right place in which to do RSVP extension reviews within the IETF. There was some discussion on this topic during the meeting, with the first reaction from a few of us being "if not here, where?" Someone (and to be clear, it was not me) from the audience offered the chairs the idea of opening up an RSVP WG for such extensions that have been steadily streaming in over the years into the Transport Area. That idea was forcefully put down by the table at the front of the room... perhaps rightfully so. But one thing was clear (to me at least), there was no other proposal for where to take RSVP extension documents for review by enough RSVP heads that each proposal would receive proper scrutiny by experts (if they aren't already in the TSVWG). So, I ask the list: Where should documents that are intended to be standards track extensions of RSVP be reviewed? Discussion would be good now.... cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Nov 29 23:29:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18952; Mon, 29 Nov 2004 23:28:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYziP-0000FC-Ur; Mon, 29 Nov 2004 23:34:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYzbw-0007Vm-KR; Mon, 29 Nov 2004 23:27:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYzRA-0004zO-Aw for tsvwg@megatron.ietf.org; Mon, 29 Nov 2004 23:16:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18060 for ; Mon, 29 Nov 2004 23:16:22 -0500 (EST) Received: from vscan.fit.ac.jp ([150.43.1.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYzWC-0008S3-BO for tsvwg@ietf.org; Mon, 29 Nov 2004 23:21:37 -0500 Received: from dontaku.fit.ac.jp (localhost [127.0.0.1]) by vscan.fit.ac.jp (8.12.5/8.12.5) with ESMTP id iAU4FbxQ024555 for ; Tue, 30 Nov 2004 13:15:38 +0900 (JST) Received: from [150.43.233.162] (nausica.ce.fit.ac.jp [150.43.233.162]) by dontaku.fit.ac.jp (8.11.6/3.7W03112810) with ESMTP id iAU4FbI30440 for ; Tue, 30 Nov 2004 13:15:37 +0900 Message-ID: <41ABF423.8030305@unisa.it> Date: Tue, 30 Nov 2004 13:16:35 +0900 From: giuseppe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Add/Delete IP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit An elementary question: Let suppose that I have one Network Interface card and, for some reasons (DCHP, RA, ) I could get 2 IP add. to use. If we use Add/Delete Ip addresses for SCTP, this means that we have also to be able to "set" 2 IP add. on the same NIC. This is possible? Giuseppe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 01:26:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28053; Tue, 30 Nov 2004 01:26:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ1Xy-0002l2-BC; Tue, 30 Nov 2004 01:31:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ1MQ-0003Uk-Ec; Tue, 30 Nov 2004 01:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ1FZ-000269-1S for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 01:12:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27065 for ; Tue, 30 Nov 2004 01:12:31 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ1Kc-0002UL-2y for tsvwg@ietf.org; Tue, 30 Nov 2004 01:17:46 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id AAA09251; Tue, 30 Nov 2004 00:11:21 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAU6BHx19269; Tue, 30 Nov 2004 00:11:17 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 22:11:19 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Tsvwg] multiaddressing Date: Mon, 29 Nov 2004 22:11:18 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060930@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] multiaddressing Thread-Index: AcTWiSsEtwHQrf2PQbWPI25KZ+EA+wGI5DLQ From: "Henderson, Thomas R" To: "Ted Faber" X-OriginalArrivalTime: 30 Nov 2004 06:11:19.0727 (UTC) FILETIME=[68AB0BF0:01C4D6A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ted Faber [mailto:faber@ISI.EDU] > Sent: Monday, November 29, 2004 7:00 PM > To: Henderson, Thomas R > Cc: Randall Stewart; tsvwg@ietf.org; Mark Allman; Janardhan Iyengar > Subject: Re: [Tsvwg] multiaddressing >=20 >=20 > On Mon, Nov 29, 2004 at 04:25:47PM -0800, Henderson, Thomas R wrote: > >=20 > >=20 > > > -----Original Message----- > > > From: Ted Faber [mailto:faber@ISI.EDU]=20 > > > Sent: Monday, November 29, 2004 3:30 PM > > > To: Janardhan Iyengar > > > Cc: Randall Stewart; tsvwg@ietf.org; Mark Allman > > > Subject: Re: [Tsvwg] multiaddressing > > >=20 > > > I'm a slow thinker. Can you give me an example of a=20 > benefit to doing > > > load balancing in transport that's not an implementation=20 > > > workaround, but > > > a problem with using the transport service to do what you want? > > >=20 > >=20 > > How do applications learn of and propagate multiple address sets > > across which they can open multiple transport streams and load > > balance across them? DNS? It's probably not a good idea to create > > additional DNS dependencies. >=20 > Why *not* DNS? It's a distributed replicated 1-to-many database. It > already returns lists of network addresses associated with a=20 > string, and > there's a well-known API to get at those. I don't understand the > additional dependency created here unless the endpoints were not > exchanging DNS names to begin with.=20 Two main reasons come to mind-- cases where DNS is not used, and=20 dynamic scenarios where updates are expensive and addresses are somewhat transient. >=20 > > Applications themselves? Then you > > burden applications with learning the addresses and communicating > > them across to the peer, and it gets messy when NATs are involved > > (IP addresses in application data streams are deprecated). >=20 > NATs are sure a problem if you want to go passing IP addresses around. > That's not a problem introduced by multi-{addressing,homing}. Any > protocol that wants to redirect has it. Not using IP addresses won't > save you - SMTP accross a NAT may fail because the DNS reverse mapping > that the endpoint believes in isn't the same one that a (paranoia) > server sees. I don't have an easy answer to the problem of how an > endpoint identifies itself to another endpoint when the=20 > endpoint doesn't > know its own name, but I'm pretty sure that getting a list of names > doesn't make it any harder than getting one. >=20 > I understand you want to add another layer of indirection here, but I > don't see why that layer needs to be resolved in transport, nor really > what you'd save by doing so. (I'm a little fuzzy on why you=20 > need one at > all). I was more suggesting that it may need to be resolved in the stack = somewhere than not at all, since the debate in that thread seemed to be = application vs. transport. >=20 > >=20 > > This question probably boils down to what do we want the > > transport/application API to look like-- do applications connect to > > hosts, or to IP addresses? If hosts (which would seem to=20 > be consistent > > with the terminology of RFC 793-- TCP as a "host-to-host" protocol), > > then we should probably think about offering load balancing in the > > stack somewhere. Then the question becomes (as you put it in the > > previous message) whether we can do a good enough job in the > > transport to provide a *common* load balancing service that has > > enough utility to multiple applications. >=20 > There's a lot of space between transport and application. It's > perfectly reasonable to insert a {library, protocol layer} in there if > you want to create an idea that the application writer looks up a name > and communicates with the named entity without changing the meaning of > an IP address to TCP or another existing protocol. Putting it into a session layer that runs over unmodified TCP does seem doable (there was a clever paper about Rocks and Racks in Mobicom a few years back) but it seems like it could get complicated synchronizing across the connections. For instance, what happens to data that was sent into the TCP send buffer of a now defunct connection-- is it yanked back out of the send buffer? (SS7 has a protocol that actually works like this: MTP-3 over MTP-2). Or a copy kept until a session-layer ACK comes? >=20 > You're going to have to multiplex from "multiname" to multiple IP > addresses (or transport connections) either way. Even if you had a > transport protocol that would accept packets from an array of=20 > names for > the other end, sending a packet requires picking the=20 > destination address > to send to. You don't save any work doing it in transport,=20 > and you lose > any possibilty to cleanly build on the transport. The act of picking the destination address correctly might be one strong argument for putting it in transport layer or in some adjacent layer that has access to transport state, because transport has the recent loss and congestion control history to inform the decision. But your point is well taken that it doesn't necessarily need to be in transport. My sense has been that it might be cleaner in the long run to solve it below the application somehow, though. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 02:51:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17679; Tue, 30 Nov 2004 02:51:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ2s2-0004By-EP; Tue, 30 Nov 2004 02:56:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ2kk-00022Y-Jl; Tue, 30 Nov 2004 02:48:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ2VZ-00060Y-WF for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 02:33:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16388 for ; Tue, 30 Nov 2004 02:33:07 -0500 (EST) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ2ad-0003rf-E2 for tsvwg@ietf.org; Tue, 30 Nov 2004 02:38:23 -0500 Received: from wrl-40.cs.helsinki.fi (wrl-40.cs.helsinki.fi [128.214.166.160]) (IDENT: jmanner, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 30 Nov 2004 09:33:02 +0200 id 000740D7.41AC222E.00002D85 Date: Tue, 30 Nov 2004 09:33:02 +0200 (EET) From: Jukka MJ Manner To: "James M. Polk" Subject: Re: [Tsvwg] Reviews of RSVP extensions (here, there, or ... ?) In-Reply-To: <4.3.2.7.2.20041129213955.0250ce98@localhost> Message-ID: References: <4.3.2.7.2.20041129213955.0250ce98@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Hi, If you look at how the work in Mobile IP was divided into three WGs (mip4, mip6, and mipshop), the same could happen here: move the existing RSVP proposals from TSVWG to a short-lived WG that will take those individual drafts and get them to RFCs quickly and efficiently, and close immediately after. Cheers, Jukka On Mon, 29 Nov 2004, James M. Polk wrote: > Hey WG > > In the DC meeting of TSVWG, a distinguished person questioned at the > microphone whether or not TSVWG was the right place in which to do RSVP > extension reviews within the IETF. There was some discussion on this topic > during the meeting, with the first reaction from a few of us being "if not > here, where?" > > Someone (and to be clear, it was not me) from the audience offered the chairs > the idea of opening up an RSVP WG for such extensions that have been steadily > streaming in over the years into the Transport Area. That idea was forcefully > put down by the table at the front of the room... perhaps rightfully so. > > But one thing was clear (to me at least), there was no other proposal for > where to take RSVP extension documents for review by enough RSVP heads that > each proposal would receive proper scrutiny by experts (if they aren't already > in the TSVWG). > > So, I ask the list: > > Where should documents that are intended to be standards track extensions of > RSVP be reviewed? > > Discussion would be good now.... > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 03:26:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20181; Tue, 30 Nov 2004 03:26:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ3Qg-0004sb-8F; Tue, 30 Nov 2004 03:32:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ374-0007DQ-7G; Tue, 30 Nov 2004 03:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ34e-0006b4-NH for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 03:09:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19181 for ; Tue, 30 Nov 2004 03:09:23 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ39i-0004Zy-7e for tsvwg@ietf.org; Tue, 30 Nov 2004 03:14:39 -0500 Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAU867Q12174; Tue, 30 Nov 2004 00:06:08 -0800 (PST) Message-ID: <41AC29E4.9000404@isi.edu> Date: Tue, 30 Nov 2004 00:05:56 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [Tsvwg] multiaddressing (private) References: <20041124141315.GB16629@grc.nasa.gov> <20041124164826.5E1A377AA12@guns.icir.org> <20041124165835.GL16629@grc.nasa.gov> <20041124173405.GJ71049@pun.isi.edu> <20041124174455.GO16629@grc.nasa.gov> <20041124180754.GK71049@pun.isi.edu> <41A5C472.8030405@stewart.chicago.il.us> <20041129181444.GB5502@pun.isi.edu> <20041129232818.GC9132@pun.isi.edu> In-Reply-To: <20041129232818.GC9132@pun.isi.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0860305041==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0860305041== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2A5DFC2C6398DB17473C3B57" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2A5DFC2C6398DB17473C3B57 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ted Faber wrote: > On Mon, Nov 29, 2004 at 05:15:02PM -0500, Janardhan Iyengar wrote: > >>Hi Ted/all, >> >>I thought I should add one more point to my earlier response: ... >>There is also the question of what services are common enough to be pushed >>into a common layer below the application layer, to avoid repeated >>implementations in applications. If load balancing is a service that most >>applications would use (if provided) for increased throughput, the service >>should, IMHO, be provided in transport. When there are demonstrable >>benefits in adding some services to transport, is there a reason for >>keeping such services outside transport? A number of reasons; these are some of the reasons that IP is outside TCP, and why the multi-6 WG is focusing on multhoming as a shim that is outside the transport protocol as well. In particular, data unit multiplexing is IP's job. Making it TCP's job too means that different TCPs - or SCTP and TCP, etc. - can have different muxing systems that either interfere or invert priorities. The argument that "this is something apps need, so let's share it and put it in the transport layer" holds even moreso for pushing it into IP; there are many transport protocols that would benefit from load-balanced muxing, and putting it even lower makes it a generic pseudo-link service. The further benefit is that whatever muxing you do at the single node might be applicable further down the line as well, in routers, and so should be at the network layer optimally. There's also the idea, as Ted mentioned, of something outside TCP; this can be somewhat parallel, ala the Congestion Manager. That was an attempt to help multiple TCPs play nice using a single mechanism, rather than replicating it through many TCPs. Joe --------------enig2A5DFC2C6398DB17473C3B57 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrCnrE5f5cImnZrsRAlFfAJ9J3wJPG65fve6y/HTyWTzGMS/stwCgzA3+ Z9xEbooBDzRbFfGgY9DT0fw= =rqLQ -----END PGP SIGNATURE----- --------------enig2A5DFC2C6398DB17473C3B57-- --===============0860305041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0860305041==-- From tsvwg-bounces@ietf.org Tue Nov 30 03:35:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20869; Tue, 30 Nov 2004 03:35:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ3Yw-00055E-L2; Tue, 30 Nov 2004 03:40:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ3MD-00011m-Vq; Tue, 30 Nov 2004 03:27:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ38E-0007Fj-44 for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 03:13:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19458 for ; Tue, 30 Nov 2004 03:13:04 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ3DI-0004ec-Ka for tsvwg@ietf.org; Tue, 30 Nov 2004 03:18:21 -0500 Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAU8BMQ13427; Tue, 30 Nov 2004 00:11:22 -0800 (PST) Message-ID: <41AC2B26.2070905@isi.edu> Date: Tue, 30 Nov 2004 00:11:18 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Tsvwg] multiaddressing References: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Randall Stewart , Ted Faber , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2038215708==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2038215708== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4F4F067071E2A3D7C490E859" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F4F067071E2A3D7C490E859 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: > >>-----Original Message----- >>From: Ted Faber [mailto:faber@ISI.EDU] >>Sent: Monday, November 29, 2004 3:30 PM >>To: Janardhan Iyengar >>Cc: Randall Stewart; tsvwg@ietf.org; Mark Allman >>Subject: Re: [Tsvwg] multiaddressing >> >>I'm a slow thinker. Can you give me an example of a benefit to doing >>load balancing in transport that's not an implementation >>workaround, but >>a problem with using the transport service to do what you want? > > How do applications learn of and propagate multiple address sets > across which they can open multiple transport streams and load > balance across them? Why should they? If the addresses "mean" the same thing, that ought to be a single socket, and the network-layer delivery ought to figure out there's more than one way there (ala multi6 shim). As to how NATs complicate the system - this version or any other - color me shocked. Any time what you want doesn't map to emulating a single network address, a NAT is a mistake you have to undo. It should be no surprise that it causes problems in this scenario, which clearly breaks the basic characteristic of a NAT. I like the idea of supporting muxing in the stack, but in the network, esp. since it can be useful for tunnels as well as for end-to-end apps. Joe --------------enig4F4F067071E2A3D7C490E859 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrCsmE5f5cImnZrsRAoelAJ9gYVc82LzkXaTYgW4n9HPNslH49gCeK+eG lbRxOvHKMNkCXMEjnB6IHGE= =rMLE -----END PGP SIGNATURE----- --------------enig4F4F067071E2A3D7C490E859-- --===============2038215708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============2038215708==-- From tsvwg-bounces@ietf.org Tue Nov 30 03:37:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21190; Tue, 30 Nov 2004 03:37:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ3ar-00057m-Uj; Tue, 30 Nov 2004 03:42:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ3Mg-0001JV-Tq; Tue, 30 Nov 2004 03:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ3EO-0007u6-Pb for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 03:19:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19802 for ; Tue, 30 Nov 2004 03:19:27 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ3JT-0004ks-CL for tsvwg@ietf.org; Tue, 30 Nov 2004 03:24:43 -0500 Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAU8GJQ14589; Tue, 30 Nov 2004 00:16:19 -0800 (PST) Message-ID: <41AC2C4F.9050905@isi.edu> Date: Tue, 30 Nov 2004 00:16:15 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [Tsvwg] multiaddressing References: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> <20041130030000.GE9132@pun.isi.edu> In-Reply-To: <20041130030000.GE9132@pun.isi.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "Henderson, Thomas R" , Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1426427122==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1426427122== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF981DF97E5CB1BD49AA6DDD4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF981DF97E5CB1BD49AA6DDD4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ted Faber wrote: ... > Why *not* DNS? It's a distributed replicated 1-to-many database. It > already returns lists of network addresses associated with a string, and > there's a well-known API to get at those. I don't understand the > additional dependency created here unless the endpoints were not > exchanging DNS names to begin with. When DNS returning multiple RRs it doesn't mean they're on the same host; they are just 'equivalent' in some fuzzy sense, e.g., replica servers of a database, alternate gateways to a VPN, etc. There would need to be a different record to indicate records that go to the same 'box' (i.e., we could call them WH for 'weak host'). Joe --------------enigF981DF97E5CB1BD49AA6DDD4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrCxPE5f5cImnZrsRAjpYAKDf6Lzeb6K81rjpHzItQHvHFJKOVACZAR8k kpE038jYo7lJHXYh9Zsmj1o= =hyhi -----END PGP SIGNATURE----- --------------enigF981DF97E5CB1BD49AA6DDD4-- --===============1426427122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1426427122==-- From tsvwg-bounces@ietf.org Tue Nov 30 07:22:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11762; Tue, 30 Nov 2004 07:22:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ76X-000219-Az; Tue, 30 Nov 2004 07:27:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ6xB-0008Bd-Fl; Tue, 30 Nov 2004 07:17:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ6u8-00077m-It for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 07:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10867 for ; Tue, 30 Nov 2004 07:14:45 -0500 (EST) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ6z9-0001pt-4d for tsvwg@ietf.org; Tue, 30 Nov 2004 07:20:05 -0500 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id iAUCES84014094; Tue, 30 Nov 2004 07:14:31 -0500 (EST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41AC63BE.4010609@stewart.chicago.il.us> Date: Tue, 30 Nov 2004 07:12:46 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: humaira Subject: Re: [Tsvwg] SCTP latency References: <29694870.1101779500490.JavaMail.myubc2@portal9.itservices.ubc.ca> In-Reply-To: <29694870.1101779500490.JavaMail.myubc2@portal9.itservices.ubc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Content-Transfer-Encoding: 7bit humaira wrote: > Hi, > > Thank you for your reply, it helps a lot. Can you point us to where > we can find design documentation about KAME SCTP implementation?' I have never really documented it.. the closests would be in the SCTP book since its a rewrite of the original app layer library into the kernel... of course there were a lot of changes ... but it does follow the general overview layed out in the book... But I really should circle back and update it to reflect the code.... sigh.. never enough time ... > > We had a few questions about your tests on KAME-Bsd stack. The first > one is about the 2Gbyte message size in the output of your test > utility. We have been experimenting with sending large messages in > lksctp, however, it is limited by the default send buffer size and > sctp_sendmsg fails for message sizes above SO_SNDBUF size. The test is setup that you give it a size of transfer and a record size. It does NOT send a 2G message.. KAME would also fail in this since the socket send buffer limits the largest single size message one can send. How my test works is the client does the active open, sets any receive buffer on the socket, and then sends a request to the peer to send N bytes in X byte sizes. Also included is the send buffer size. If the send buffer size is specified then the server sets it on the new "accepted" fd and then it starts to write data in X size pieces until N bytes are transfered. The control file to the client looks like: N:X:snd_buf:rcv_buf For snd_buf and rcv_buf a 0 indicates use the default for the transport. The run you looked at has a control file that looks like: # Control file needs # sizetos:blksize:snd_buf:recv_buf\n 2000000000:1452:0:0 So each write was 1452 bytes until 2 Gig was transfered The program first connects SCTP and does the transfer then it connects TCP and does the transfer ... it repeats these until it hits the number of passes requested or forever :-D Of course a ctl-c will get the program to stop at the end of the next pass (sometimes forever is to long :-D) > (Reference: > http://sourceforge.net/mailarchive/message.php?msg_id=9664532). > Therefore, we break-up messages that are larger than the send buffer > size into multiple smaller messages that can be handled by lksctp and > then reassemble them into one large message at the receiving side. > I have not looked at message sized type tranfer... its one of the things I have on my to-do list... i.e. have a app that sends varied size messages between a range of values... that way the TCP side must parse the messages into complete pieces... vs SCTP that does not... Most apps I have ran across in my various roles have all had very few messages over a few hundred bytes... I was thinking of doing things between 1 - 1400 bytes.. but throwing in a 5k or 8k message might also be good.... :-D > Is KAME capable of sending and receiving messages to the order of > 2Gbytes on its own without requiring the user to break it up? If so, > does KAME use some sort of kernel buffering? Well its possible but it would mean the socket send buffer would need to be 2Gig... and in reality I would think not likely.. It does not have a "partial deliver send"... Now I have sent a 2 Meg message (by raising the socket buffer defaults up large enough that I could raise up SCTP's socket send buffer)... but never 2G > > Your results for CPU idleness on IBM laptop are very interesting. Is > the 30% idle figure for SCTP receiver because of the CRC32c overhead > on the slower machine or something else? I think its a combination of things... First of all the 30% number is un-scientific.. its me running top while the TCP and SCTP transfers happen and observing... no fine grained stuff. I do, of course, have gprof info on what the kernel is doing.. and I have done most of the tweaks that were easy... A lot of the remaining time is in the standard so_receive() call. This is really optimized for (surprise) TCP and is not very efficent for SCTP.. but Free and Net BSD allow a transport to change these out.. so I really need to re-write an optimized version.. this, I think, will get the "idle-ness" up quite a bit.. as well as speed the transfer up more towards where I start hitting FR's > > We would be very glad to make use of your test utility. We are > emailing our basic socket application to you (For others: if you want > a copy, please let me know). Regarding your question about our > application, we are not incurring connection setup per message. The > connection is established once and then we send a few messages to > warm-up the cache before doing any time measurements. Different sized > messages are sent in a for-loop on the same socket. Each message X of > some particular size is sent and received a 1000 times and the time > taken is the average of these 1000 iterations. Our TCP application is > not currently doing message framing, which is of course something > that should be added to it in order to make the comparison fair, but > we were a bit surprised to see the order of difference in our TCP and > SCTP latencies in our initial results to attribute it only to the > lack of message framing. I think a lot of your problem may be that lk-sctp has not finished any performance work as well... just a guess... I know KAME was not steller when I started.. I will send you my apps seperate. R > > > Thank you for your help. > > Humaira > > > > > -----Original Message----- > > >> Date: Mon Nov 29 06:15:03 PST 2004 From: "Randall Stewart" >> Subject: Re: [Tsvwg] SCTP latency >> To: >> >> Humaria: >> >> Comments below... >> >> humaira wrote: >> >>> Hi, >>> >>> We have been looking at SCTP (one-to-one style) latency >>> performance on a basic socket application (described below), and >>> compared the results obtained with an equivalent TCP application. >>> We are using lksctp-2.6.6 on Linux kernel 2.6.7. According to our >>> results SCTP is an order of magnitude slower than TCP. Other >>> people have mentioned that they have done similar latency tests >>> and have obtained similar outputs. (Reference: >>> http://sourceforge.net/mailarchive/forum.php?thread_id=5987343&forum_id=1856 >>> ) We are very interested in finding out where, deep down, SCTP >>> is spending so much time since this is just a vanilla sctp port. >>> We would have expected to see SCTP performance comparable to TCP >>> on a clean network. >>> >>> We have read other postings on the subject such as >>> http://www1.ietf.org/mail-archive/web/tsvwg/current/msg04879.html >>> which mention CRC32c as a possible performance overhead in sctp. >>> However, looking at the order of difference in our results it >>> seems unlikely that CRC32C is the only factor here. >> >> CRC32c is a large part of the performance difference... however I >> think in the case of lk-sctp it is more an issue with a new stack. >> I have just completed most of another performance pass on the >> KAME-Bsd stack and I get much better numbers then you did... I hope >> to re-run my tests and get both a gprof output and a transfer >> throughput to post on my web site.... >> >> As to what I was seeing roughly.. >> >> My network was: >> >> P-IV-2.8Gig dell server <------------------> IBM Laptop T-40 >> (1.5Gig M Pentium) >> >> 1000Mbit copper via 2950 cisco switches >> >> >> Sending from the Dell box to the IBM I saw: 0.0 53.925576 # rb:0 >> size:2000000000:sctp: (296.705222 Megabits per sec) 0.0 54.160244 # >> rb:0 size:2000000000:tcp: (295.419644 Megabits per sec) 0.0 >> 53.914660 # rb:0 size:2000000000:sctp: (296.765295 Megabits per >> sec) 0.0 54.082463 # rb:0 size:2000000000:tcp: (295.844514 Megabits >> per sec) >> >> The above is what comes out of my test utility.. it runs the same >> code only with TCP or SCTP using the SOCK_STREAM (or 1 to 1 model). >> >> >> Now watching the CPU idle'ness the Dell (sending side) seemed to >> run about 55% idle while sending TCP and 50% idle while sending >> SCTP. >> >> The IBM laptop (receiving side) tendend to run about 58% idle on >> the TCP pass but only 30% idle on the SCTP passes.. >> >> Another important note here is that both machines have a TCP >> offload on the NIC I am using.. this means that the TCP connections >> do not suffer any extra time for the checksum.. >> >> Testing on my laptop locally... KAME-BSD by default will disable >> the CRC32c (controlable by a sysctl), I get over the loopback with >> the CRC disabled about 3Gigbit's per second .. however if I change >> the sysctl and run it with the CRC enabled I drop to 600Megabit... >> >> Now when I reverse things and have my P-IV be the receiver things >> get a bit more interesting.. I zip up to about 400Megabit with SCTP >> slightly faster... however in looking at TCP and SCTP I am seeing >> fast retransmissions.. this tells me I am loosing packets.. and >> since I use cat-5 wire I think this is my problem (I even took the >> switch out and did a back-2-back wire and had the same problem)... >> >> Note that I am quite a bit faster on the transfer the opposite >> way.. this tells me that I still need to work on the receive path >> of KAME-Bsd.. I really need to write my own steam-lined >> sctp_soreceive instead of using the stock one.. this, I think, >> could get the BSD stack close to the same idle time on receive.. I >> am hoping... >> >> I have noted too that message sizes play a big role in the >> transfer... TCP can always pack down a full MTU.. SCTP is limited >> in this, somewhat, in that it must fragment to its max size and can >> do bundling but not always will the pieces fit together. >> >> To pull this out of the factor (since I don't have an app that does >> message framing for a fair comparison) I use 1452 has the message >> write size... This is the largest chunk of data that SCTP can place >> in one packet... for FreeBSD (which is what I was using 4.10) the >> max TCP stuffs is about 1448 (I think timestamps is the reason)... >> >> >> >>> It would be very helpful if somebody could provide insight into >>> other factors for this behavior. >>> >>> Thank you for your help. Humaira >>> >>> Our application does the following. There are two nodes (one >>> Pentium II, 400.9MHz and the other Pentium III, 999.981MHz both >>> with Linux 2.6.7) Node1 sends a message of size X to Node2 and >>> then receives message of size X from Node2. Node2 does the >>> opposite,i.e.receives message size X from Node1 and then sends >>> message size X to Node1. >>> >>> We measure the time taken to carry out this operation using rdtsc >>> which returns the number of Pentium clock cycles. The above >>> operation was repeated 1000 times and the time obtained is the >>> average of these 1000 iterations. We warm-up the cache before >>> doing any time measurement. >>> >>> Our SCTP program uses the one-to-one style and we send and >>> receive using sctp_sendmsg and sctp_recvmsg. The TCP counterpart >>> simply uses send and recv. The NODELAY option is set to 1 in both >>> SCTP and TCP (i.e.Nagles's algorithm is disabled). The default >>> values for socket send and receive buffers was used in both >>> cases. In our case the default tcp socket send and receive buffer >>> sizes were 16384 and 87380 respectively and the default SCTP >>> socket send and receive buffer sizes were both 110592. >>> >>> The results for different message sizes are copied below. >>> >>> Latency results for TCP Msg_size=1 tsecs=0.000176 Msg_size=2 >>> tsecs=0.000176 Msg_size=4 tsecs=0.000168 Msg_size=8 >>> tsecs=0.000169 Msg_size=16 tsecs=0.000175 Msg_size=32 >>> tsecs=0.000175 Msg_size=64 tsecs=0.000186 Msg_size=128 >>> tsecs=0.000219 Msg_size=256 tsecs=0.000261 Msg_size=512 >>> tsecs=0.000371 Msg_size=1024 tsecs=0.000571 Msg_size=2048 >>> tsecs=0.000856 Msg_size=4096 tsecs=0.001182 Msg_size=8192 >>> tsecs=0.001905 Msg_size=16384 tsecs=0.003300 Msg_size=32768 >>> tsecs=0.006069 Msg_size=65536 tsecs=0.011681 Msg_size=131072 >>> tsecs=0.022805 Msg_size=262144 tsecs=0.045151 Msg_size=524288 >>> tsecs=0.089808 Msg_size=1048576 tsecs=0.178923 Msg_size=2097152 >>> tsecs=0.357190 >>> >> >> Does your TCP app do actuall message framing? I.e. are you doing a >> read and then processing the buffer to frame it correctly? >> >> Also is this just one message transfered? I.e. are you incurring >> the a connection setup per message? >> >> Maybe we can share the test utilties we are using.. I can gladly >> post mine (or email it to you) and I could run yours on my setup as >> well.. >> >> R >> >> >>> Latency results for SCTP Msg_size=1 tsecs=0.005685 Msg_size=2 >>> tsecs=0.005686 Msg_size=4 tsecs=0.005697 Msg_size=8 >>> tsecs=0.005693 Msg_size=16 tsecs=0.005700 Msg_size=32 >>> tsecs=0.005706 Msg_size=64 tsecs=0.005704 Msg_size=128 >>> tsecs=0.005726 Msg_size=256 tsecs=0.005738 Msg_size=512 >>> tsecs=0.005733 Msg_size=1024 tsecs=0.005772 Msg_size=2048 >>> tsecs=0.007902 Msg_size=4096 tsecs=0.002706 Msg_size=8192 >>> tsecs=0.004739 Msg_size=16384 tsecs=0.023130 Msg_size=32768 >>> tsecs=0.048449 Msg_size=65536 tsecs=0.050129 Msg_size=131072 >>> tsecs=0.078571 Msg_size=262144 tsecs=0.258564 Msg_size=524288 >>> tsecs=0.716646 Msg_size=1048576 tsecs=0.981830 Msg_size=2097152 >>> tsecs=2.056492 >>> >>> >>> _______________________________________________ tsvwg mailing >>> list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >> >> >> -- Randall Stewart 803-345-0369 815-342-5222(cell) > > > > _______________________________________________ tsvwg mailing list > tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 07:27:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12332; Tue, 30 Nov 2004 07:27:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ7B9-00028e-6R; Tue, 30 Nov 2004 07:32:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ74T-0001Nc-96; Tue, 30 Nov 2004 07:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ70a-0000Jm-01 for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 07:21:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11601 for ; Tue, 30 Nov 2004 07:21:26 -0500 (EST) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ75e-0001zr-84 for tsvwg@ietf.org; Tue, 30 Nov 2004 07:26:45 -0500 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id iAUCLG84014116; Tue, 30 Nov 2004 07:21:19 -0500 (EST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41AC6556.6090609@stewart.chicago.il.us> Date: Tue, 30 Nov 2004 07:19:34 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: giuseppe Subject: Re: [Tsvwg] Add/Delete IP References: <41ABF423.8030305@unisa.it> In-Reply-To: <41ABF423.8030305@unisa.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit giuseppe wrote: > An elementary question: > Let suppose that I have one Network Interface card and, for some reasons > (DCHP, RA, ) I could get 2 IP add. to use. > If we use Add/Delete Ip addresses for SCTP, this means that we have also > to be able to "set" 2 IP add. on the same NIC. This is possible? > Giuseppe Yes, A add can add multiple addresses (and delete multiple addresses) in the same ASCONF chunk. R > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 13:43:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18623; Tue, 30 Nov 2004 13:43:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZD3m-0003QG-9o; Tue, 30 Nov 2004 13:49:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCoO-0001wG-N3; Tue, 30 Nov 2004 13:33:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCRn-0001Li-3Z for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 13:09:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15556 for ; Tue, 30 Nov 2004 13:09:51 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCWw-0002VW-QD for tsvwg@ietf.org; Tue, 30 Nov 2004 13:15:15 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUI72Q11350; Tue, 30 Nov 2004 10:07:02 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAUI72rs016065; Tue, 30 Nov 2004 10:07:02 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAUI72bY016064; Tue, 30 Nov 2004 10:07:02 -0800 (PST) (envelope-from faber) Date: Tue, 30 Nov 2004 10:07:02 -0800 From: Ted Faber To: Joe Touch Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041130180702.GA15528@pun.isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> <20041130030000.GE9132@pun.isi.edu> <41AC2C4F.9050905@isi.edu> Mime-Version: 1.0 In-Reply-To: <41AC2C4F.9050905@isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Henderson, Thomas R" , Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807753874==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 --===============1807753874== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 30, 2004 at 12:16:15AM -0800, Joe Touch wrote: > > > Ted Faber wrote: > ... > >Why *not* DNS? It's a distributed replicated 1-to-many database. It > >already returns lists of network addresses associated with a string, and > >there's a well-known API to get at those. I don't understand the > >additional dependency created here unless the endpoints were not > >exchanging DNS names to begin with. > > When DNS returning multiple RRs it doesn't mean they're on the same > host; they are just 'equivalent' in some fuzzy sense, e.g., replica > servers of a database, alternate gateways to a VPN, etc. Doesn't mean they're not on the same host, either. I think the meaning of the multiple DNS returns is as well defined as the meaning of the list of names for the multi-{addressing,homing}/mobility thing that's in the air. > There would need to be a different record to indicate records that go to > the same 'box' (i.e., we could call them WH for 'weak host'). This may be a reasonable course. You may also be able to set up SRV records or some such thing (no I didn't pull up the format), if you wanted to argue that service points are what you're naming. There are other choices, too. The point is that if you want a distributed replicated 1-to-many database that handles primarily infrequent updates, I know where you can get one. Cheap. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBrLbGaUz3f+Zf+XsRAoA5AJ9OzwTAIHhjw23cR3Cw90ZAu1TMkwCbBXsi 6TjR/bNgg+qO4MTePOVQRTc= =DeZs -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- --===============1807753874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1807753874==-- From tsvwg-bounces@ietf.org Tue Nov 30 13:47:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18917; Tue, 30 Nov 2004 13:47:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZD7A-0003UZ-D3; Tue, 30 Nov 2004 13:52:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCpA-0002BG-Mj; Tue, 30 Nov 2004 13:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCe0-0005Re-RD for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 13:22:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16519 for ; Tue, 30 Nov 2004 13:22:29 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCj9-0002na-0K for tsvwg@ietf.org; Tue, 30 Nov 2004 13:27:52 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA05041; Tue, 30 Nov 2004 10:21:30 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAUILSi03285; Tue, 30 Nov 2004 10:21:28 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 10:21:25 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Tsvwg] multiaddressing Date: Tue, 30 Nov 2004 10:21:24 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDA2C@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Tsvwg] multiaddressing Thread-Index: AcTWiitChtMGoOtKTN2FBY2XJv+YTwAefeoA From: "Fleischman, Eric" To: "Ted Faber" , "Henderson, Thomas R" X-OriginalArrivalTime: 30 Nov 2004 18:21:25.0435 (UTC) FILETIME=[66E7A0B0:01C4D709] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable From: Ted Faber [mailto:faber@ISI.EDU] wrote: >Why *not* DNS? It's a distributed replicated=20 >1-to-many database. It already returns lists of=20 >network addresses associated with a string, and=20 >there's a well-known API to get at those. I don't=20 >understand the additional dependency created here=20 >unless the endpoints were not exchanging DNS names=20 >to begin with.=20 DNS is good for a great many things. However, it isn't particularly good for supporting transitory, real-time, and short-lived information. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 13:47:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18961; Tue, 30 Nov 2004 13:47:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZD7k-0003VN-Nn; Tue, 30 Nov 2004 13:53:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCpB-0002BU-Je; Tue, 30 Nov 2004 13:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCeQ-0005g8-RK for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 13:22:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16568 for ; Tue, 30 Nov 2004 13:22:55 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCja-0002o7-HH for tsvwg@ietf.org; Tue, 30 Nov 2004 13:28:18 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUILaQ16207; Tue, 30 Nov 2004 10:21:36 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAUILajA016167; Tue, 30 Nov 2004 10:21:36 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAUILalw016166; Tue, 30 Nov 2004 10:21:36 -0800 (PST) (envelope-from faber) Date: Tue, 30 Nov 2004 10:21:36 -0800 From: Ted Faber To: "Henderson, Thomas R" Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041130182136.GB15528@pun.isi.edu> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060930@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060930@xch-nw-27.nw.nos.boeing.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1579420106==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 --===============1579420106== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 29, 2004 at 10:11:18PM -0800, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Ted Faber [mailto:faber@ISI.EDU] > > On Mon, Nov 29, 2004 at 04:25:47PM -0800, Henderson, Thomas R wrote: > > > How do applications learn of and propagate multiple address sets > > > across which they can open multiple transport streams and load > > > balance across them? DNS? It's probably not a good idea to create > > > additional DNS dependencies. > > > > Why *not* DNS? It's a distributed replicated 1-to-many database. It > > already returns lists of network addresses associated with a > > string, and > > there's a well-known API to get at those. I don't understand the > > additional dependency created here unless the endpoints were not > > exchanging DNS names to begin with. > > Two main reasons come to mind-- cases where DNS is not used, and > dynamic scenarios where updates are expensive and addresses are > somewhat transient. No argument. Neither of those are added dependencies, and the only solution for doing that without multiple addresses is to use IP directly, so I'm not sure multihoming changes the problem, though it may well make it more important. [snip] > > > This question probably boils down to what do we want the > > > transport/application API to look like-- do applications connect to > > > hosts, or to IP addresses? If hosts (which would seem to > > be consistent > > > with the terminology of RFC 793-- TCP as a "host-to-host" protocol), > > > then we should probably think about offering load balancing in the > > > stack somewhere. Then the question becomes (as you put it in the > > > previous message) whether we can do a good enough job in the > > > transport to provide a *common* load balancing service that has > > > enough utility to multiple applications. > > > > There's a lot of space between transport and application. It's > > perfectly reasonable to insert a {library, protocol layer} in there if > > you want to create an idea that the application writer looks up a name > > and communicates with the named entity without changing the meaning of > > an IP address to TCP or another existing protocol. > > Putting it into a session layer that runs over unmodified TCP does seem > doable (there was a clever paper about Rocks and Racks in Mobicom a > few years back) but it seems like it could get complicated synchronizing > across the connections. I agree and I agree. There are some fine papers about striping across TCP connections as well that touch on some of these issues, and I'm sure there are some more out there that the community has yet to confront. > For instance, what happens to data that was > sent into the TCP send buffer of a now defunct connection-- is it yanked > back out of the send buffer? (SS7 has a protocol that actually works > like this: MTP-3 over MTP-2). Or a copy kept until a session-layer > ACK comes? If you really want to make sure it gets to the application, your ACK needs to be end-to-end (in this case session-to-session or maybe app-to-app). Less strict semantics mean less strict memory requirements. That seems like a good argument for a couple types of multi-whatsis layers or libraries to me. [snip] > But your point is well taken that it doesn't necessarily need to > be in transport. My sense has been that it might be cleaner in > the long run to solve it below the application somehow, though. I think separation of concerns is good when one can achieve it as is reuse of a good idea, so I'd like to see the idea in a {layer, library}. I'm not blind to costs or impossibilities that might push function into existing transports, but I don't see any of the latter now. Costs will be a matter of building and measuring. I'm glad we see eye-to-eye. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBrLowaUz3f+Zf+XsRAkRmAJwM1K3ZOroUki9rWBKlAFpn7ioK0QCfYtTe ywJdnTWMtKTyl+rGkrDSeC0= =ROny -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- --===============1579420106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1579420106==-- From tsvwg-bounces@ietf.org Tue Nov 30 13:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19208; Tue, 30 Nov 2004 13:49:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZD9M-0003aq-Sn; Tue, 30 Nov 2004 13:54:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCqE-0002x5-VF; Tue, 30 Nov 2004 13:35:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCnE-0001M9-9Q for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 13:32:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17182 for ; Tue, 30 Nov 2004 13:32:00 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCsN-00030h-2x for tsvwg@ietf.org; Tue, 30 Nov 2004 13:37:24 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUISEQ18412; Tue, 30 Nov 2004 10:28:14 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAUISEKH016318; Tue, 30 Nov 2004 10:28:14 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAUISDqu016317; Tue, 30 Nov 2004 10:28:13 -0800 (PST) (envelope-from faber) Date: Tue, 30 Nov 2004 10:28:13 -0800 From: Ted Faber To: Jukka MJ Manner Subject: Re: [Tsvwg] Reviews of RSVP extensions (here, there, or ... ?) Message-ID: <20041130182813.GC15528@pun.isi.edu> References: <4.3.2.7.2.20041129213955.0250ce98@localhost> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "James M. Polk" , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1267799025==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============1267799025== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 30, 2004 at 09:33:02AM +0200, Jukka MJ Manner wrote: > > Hi, > > If you look at how the work in Mobile IP was divided into three WGs (mip4, > mip6, and mipshop), the same could happen here: move the existing RSVP > proposals from TSVWG to a short-lived WG that will take those individual > drafts and get them to RFCs quickly and efficiently, and close > immediately after. Hmmmm. From your comments it sounds like the Mobile IP is a test case for this idea. How quick and efficient was the relevant mobile IP working group? I see that they're all still extant. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --Sr1nOIr3CvdE5hEN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBrLu9aUz3f+Zf+XsRAsdkAKCHkA/ZVfKr+DhaCgYXzhemBw6iWACfe3lA bBCO48rQOpDxbe72OjCvqSk= =RZGp -----END PGP SIGNATURE----- --Sr1nOIr3CvdE5hEN-- --===============1267799025== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1267799025==-- From tsvwg-bounces@ietf.org Tue Nov 30 13:55:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19963; Tue, 30 Nov 2004 13:55:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDFC-0003ow-SQ; Tue, 30 Nov 2004 14:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZD4C-0006o2-0x; Tue, 30 Nov 2004 13:49:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCqA-0002sp-9o for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 13:35:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17704 for ; Tue, 30 Nov 2004 13:35:03 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCvJ-00038y-Dp for tsvwg@ietf.org; Tue, 30 Nov 2004 13:40:26 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUIWdQ20009; Tue, 30 Nov 2004 10:32:39 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAUIWd86016365; Tue, 30 Nov 2004 10:32:39 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAUIWdru016364; Tue, 30 Nov 2004 10:32:39 -0800 (PST) (envelope-from faber) Date: Tue, 30 Nov 2004 10:32:39 -0800 From: Ted Faber To: "Fleischman, Eric" Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041130183239.GD15528@pun.isi.edu> References: <5B58696DB20B9140AD20E0685C573A6404FDDA2C@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDA2C@xch-nw-09.nw.nos.boeing.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Henderson, Thomas R" , Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321766545==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c --===============0321766545== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 30, 2004 at 10:21:24AM -0800, Fleischman, Eric wrote: > From: Ted Faber [mailto:faber@ISI.EDU] wrote: > > >Why *not* DNS? It's a distributed replicated > >1-to-many database. It already returns lists of > >network addresses associated with a string, and > >there's a well-known API to get at those. I don't > >understand the additional dependency created here > >unless the endpoints were not exchanging DNS names > >to begin with. > > DNS is good for a great many things. However, it isn't particularly good > for supporting transitory, real-time, and short-lived information. None of which was in the problem statement. The objection to DNS (and there was one) was that using it "created another dependency," not that the data was so volitile that it violated the DNS's famously loose consistency requirements. I certainly agree with your assessment of DNS's suitabiltly for handling rapidly changing data. It's not good for passing out doughnuts, either. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBrLzHaUz3f+Zf+XsRAtw/AKDHXr+7OPqmr0H+7AWjixuiQ6kqRgCfcBCw uSa9gk1J/bDPakT0Mw3pkC0= =pP9k -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- --===============0321766545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0321766545==-- From tsvwg-bounces@ietf.org Tue Nov 30 13:56:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20033; Tue, 30 Nov 2004 13:56:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDFz-0003r0-9I; Tue, 30 Nov 2004 14:01:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZD56-00076V-OL; Tue, 30 Nov 2004 13:50:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCqt-00032A-D5 for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 13:35:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17757 for ; Tue, 30 Nov 2004 13:35:48 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCw1-00039r-IM for tsvwg@ietf.org; Tue, 30 Nov 2004 13:41:11 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA03618; Tue, 30 Nov 2004 12:34:52 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAUIYpi17364; Tue, 30 Nov 2004 10:34:51 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 10:34:47 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Tsvwg] multiaddressing Date: Tue, 30 Nov 2004 10:34:47 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Tsvwg] multiaddressing Thread-Index: AcTWt5YbqVODInOeT6CHNI6WxWVLtQAUnekw From: "Fleischman, Eric" To: "Joe Touch" , "Henderson, Thomas R" X-OriginalArrivalTime: 30 Nov 2004 18:34:47.0698 (UTC) FILETIME=[45173F20:01C4D70B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: Ted Faber , Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable >From: Joe Touch [mailto:touch@ISI.EDU]=20 >>Henderson, Thomas R wrote: >>How do applications learn of and propagate multiple address sets=20 >>across which they can open multiple transport streams and load balance >>across them? > >Why should they? If the addresses "mean" the same thing, that ought to=20 >be a single socket, and the network-layer delivery ought to figure out=20 >there's more than one way there (ala multi6 shim). I'm not tracking with you here, Joe. Perhaps you could clarify what you are thinking a bit more (e.g., what stack model are you assuming?). For example, thinking in terms of the Seamoby work, for example, how can the transport "know" that two addresses mean the same thing? I expect you to answer that "the shim tells them." Is this your answer or are you thinking something else? If this is your answer, then what functions are you assuming the shim is able to perform? How do these shim functions interface to the IP layer and to the transport layer? --Eric _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 14:19:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22251; Tue, 30 Nov 2004 14:19:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDca-0004Xy-Nv; Tue, 30 Nov 2004 14:25:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDQ1-0005Oq-6H; Tue, 30 Nov 2004 14:12:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDGR-0002LP-DD for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 14:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20631 for ; Tue, 30 Nov 2004 14:02:13 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDLa-00040W-L8 for tsvwg@ietf.org; Tue, 30 Nov 2004 14:07:36 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA11891; Tue, 30 Nov 2004 13:01:24 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iAUJ1Mi14193; Tue, 30 Nov 2004 11:01:22 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 11:01:20 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Tsvwg] multiaddressing Date: Tue, 30 Nov 2004 11:01:20 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDA2E@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Tsvwg] multiaddressing Thread-Index: AcTXCzepj3SgsSy9QdGGwScznVJjfgAAGAng From: "Fleischman, Eric" To: "Ted Faber" X-OriginalArrivalTime: 30 Nov 2004 19:01:20.0899 (UTC) FILETIME=[FAB66D30:01C4D70E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: "Henderson, Thomas R" , Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Ted Faber [mailto:faber@ISI.EDU] wrote: >>Fleischman, Eric wrote: >> From: Ted Faber [mailto:faber@ISI.EDU] wrote: >>=20 >>>Why *not* DNS? It's a distributed replicated >>>1-to-many database. It already returns lists of=20 >>>network addresses associated with a string, and=20 >>>there's a well-known API to get at those. I don't=20 >>>understand the additional dependency created here=20 >>>unless the endpoints were not exchanging DNS names=20 >>>to begin with.=20 >=20 >>DNS is good for a great many things. However, it isn't particularly=20 >>good for supporting transitory, real-time, and short-lived=20 >>information. >None of which was in the problem statement. The objection to DNS=20 >(and there was one) was that using it "created another dependency,"=20 >not that the data was so volitile that it violated the DNS's=20 >famously loose consistency requirements. >I certainly agree with your assessment of DNS's suitabiltly for=20 >handling rapidly changing data. It's not good for passing out=20 >doughnuts, either. Ted, Ignoring the doughnut comment, the view from my knot-hole is that this discussion is hampered by differing and not fully articulated concept of operations. I come from the MANET world where I think in terms of constantly changing network topologies. Mobile IP and NEMO people think in terms of end system or network mobility in the context of a stable network environment. Other people think in terms of stable wire-line networks with limited or no mobility.=20 Multiple addresses may result from many causes, including mobility, private address spaces (e.g., NATs), multi-homing, multiple protocol support (e.g., IPv4 and IPv6), and IPv6 address usages.=20 I assume that a preferable solution for this issue would scratch the itches of all three types of environments (stable, mobile, highly mobile). From where I sit, DNS is appropriate for stable wire-line networks. It may or may not be appropriate for mobile (MIB and NEMO) environments, depending on certain (thus far unstated) concept of operations assumptions. However, it probably isn't appropriate for highly mobile (MANET) environments for this particular usage. --Eric _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 14:27:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23129; Tue, 30 Nov 2004 14:27:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDjx-0004mv-Ai; Tue, 30 Nov 2004 14:32:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDTx-0006jL-IO; Tue, 30 Nov 2004 14:16:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDKV-0003d5-6W for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 14:06:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21203 for ; Tue, 30 Nov 2004 14:06:25 -0500 (EST) Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDPe-00049j-Gv for tsvwg@ietf.org; Tue, 30 Nov 2004 14:11:47 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 93ECE689E4 for ; Tue, 30 Nov 2004 14:05:54 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAUJ5rhJ016946; Tue, 30 Nov 2004 14:05:53 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 031EF4FC16; Tue, 30 Nov 2004 14:02:45 -0500 (EST) Date: Tue, 30 Nov 2004 14:02:44 -0500 From: Wesley Eddy To: "Fleischman, Eric" Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041130190244.GA16321@grc.nasa.gov> References: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Henderson, Thomas R" , tsvwg@ietf.org, Janardhan Iyengar , Joe Touch , Ted Faber , Randall Stewart , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1514356579==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c --===============1514356579== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 30, 2004 at 10:34:47AM -0800, Fleischman, Eric wrote: > How do these shim functions interface to the IP layer and to the > transport layer? That's a question I've been (poorly) trying to ask, with the point being that we need to think about this interface in TSVWG. The shims will be interfacing with the transport and as the transport group, we'll need to make sure that the interface they provide is adequate for the things transports do. -Wes --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBrMPUzBuYqbnj3IwRAmQRAJ9Tfpj8m9xS/KOC9AYmCGdScHwktwCbBMC/ DkoycWLzjZA6i4ob+hhrV2Y= =DUDv -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- --===============1514356579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1514356579==-- From tsvwg-bounces@ietf.org Tue Nov 30 15:10:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28673; Tue, 30 Nov 2004 15:10:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZEPE-00066H-3Q; Tue, 30 Nov 2004 15:15:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZE9K-0002Ec-OR; Tue, 30 Nov 2004 14:58:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDw8-0006JE-0w for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 14:45:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25788 for ; Tue, 30 Nov 2004 14:45:18 -0500 (EST) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZE1I-0005Io-E3 for tsvwg@ietf.org; Tue, 30 Nov 2004 14:50:41 -0500 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (IDENT: jmanner, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 30 Nov 2004 21:45:15 +0200 id 00070ED0.41ACCDCB.00007D21 Date: Tue, 30 Nov 2004 21:45:15 +0200 (EET) From: Jukka MJ Manner To: Ted Faber Subject: Re: [Tsvwg] Reviews of RSVP extensions (here, there, or ... ?) In-Reply-To: <20041130182813.GC15528@pun.isi.edu> Message-ID: References: <4.3.2.7.2.20041129213955.0250ce98@localhost> <20041130182813.GC15528@pun.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: "James M. Polk" , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi, Mobile IP had been going on for years and years, and there was way too many drafts to handle by one WG and its chairs. I don't know/remember all the details behing the split, but it has worked, as far as I can tell. The same thing could be done here: get the RSVP documents, and people interested in those, to a new WG that will quickly deal with them, and close - quick, clean, and simple. My 2 cents, Jukka On Tue, 30 Nov 2004, Ted Faber wrote: > On Tue, Nov 30, 2004 at 09:33:02AM +0200, Jukka MJ Manner wrote: > > > > Hi, > > > > If you look at how the work in Mobile IP was divided into three WGs (mip4, > > mip6, and mipshop), the same could happen here: move the existing RSVP > > proposals from TSVWG to a short-lived WG that will take those individual > > drafts and get them to RFCs quickly and efficiently, and close > > immediately after. > > Hmmmm. From your comments it sounds like the Mobile IP is a test case > for this idea. How quick and efficient was the relevant mobile IP > working group? I see that they're all still extant. > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Nov 30 17:19:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21918; Tue, 30 Nov 2004 17:19:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGQo-0004nl-6c; Tue, 30 Nov 2004 17:25:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFfB-0008HC-RQ; Tue, 30 Nov 2004 16:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZEeZ-0002Hc-SS for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 15:31:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01292 for ; Tue, 30 Nov 2004 15:31:13 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZEjh-0006Yg-QL for tsvwg@ietf.org; Tue, 30 Nov 2004 15:36:37 -0500 Received: from [69.82.26.209] (209.sub-69-82-26.myvzw.com [69.82.26.209]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUKTRQ23414; Tue, 30 Nov 2004 12:29:27 -0800 (PST) Message-ID: <41ACD81E.7000701@isi.edu> Date: Tue, 30 Nov 2004 12:29:18 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [Tsvwg] multiaddressing References: <6938661A6EDA8A4EA8D1419BCE46F24C0406092E@xch-nw-27.nw.nos.boeing.com> <20041130030000.GE9132@pun.isi.edu> <41AC2C4F.9050905@isi.edu> <20041130180702.GA15528@pun.isi.edu> In-Reply-To: <20041130180702.GA15528@pun.isi.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Henderson, Thomas R" , Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0421963246==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0421963246== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0FF80F075403A85276CFE4F6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0FF80F075403A85276CFE4F6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ted Faber wrote: > On Tue, Nov 30, 2004 at 12:16:15AM -0800, Joe Touch wrote: > >> >>Ted Faber wrote: >>... >> >>>Why *not* DNS? It's a distributed replicated 1-to-many database. It >>>already returns lists of network addresses associated with a string, and >>>there's a well-known API to get at those. I don't understand the >>>additional dependency created here unless the endpoints were not >>>exchanging DNS names to begin with. >> >>When DNS returning multiple RRs it doesn't mean they're on the same >>host; they are just 'equivalent' in some fuzzy sense, e.g., replica >>servers of a database, alternate gateways to a VPN, etc. > > Doesn't mean they're not on the same host, either. It tends to, for servers in particular. RRs are used for pseudo load balancing; that's where the name came from, AFAIR. > I think the meaning > of the multiple DNS returns is as well defined as the meaning of the list > of names for the multi-{addressing,homing}/mobility thing that's > in the air. Not for multi6; in that case, the set of addresses is defined as being on the same endpoint. >>There would need to be a different record to indicate records that go to >>the same 'box' (i.e., we could call them WH for 'weak host'). > > This may be a reasonable course. You may also be able to set up SRV > records or some such thing (no I didn't pull up the format), if you > wanted to argue that service points are what you're naming. There are > other choices, too. > > The point is that if you want a distributed replicated 1-to-many > database that handles primarily infrequent updates, I know where you can > get one. Cheap. Agreed. But not necessarily out-of-the-box, that's all. Joe --------------enig0FF80F075403A85276CFE4F6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrNgiE5f5cImnZrsRAhaJAJ4+Hla2GR3rFZs9dPE/bj8zmievNACgoKhM ddOZWEzilpPTRISKF4BJe3o= =1tdz -----END PGP SIGNATURE----- --------------enig0FF80F075403A85276CFE4F6-- --===============0421963246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0421963246==-- From tsvwg-bounces@ietf.org Tue Nov 30 17:23:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22563; Tue, 30 Nov 2004 17:23:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGUV-00050y-Js; Tue, 30 Nov 2004 17:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZG9t-0004xt-SO; Tue, 30 Nov 2004 17:07:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZEgg-0003cI-Sd for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 15:33:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01459 for ; Tue, 30 Nov 2004 15:33:24 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZElo-0006bC-VQ for tsvwg@ietf.org; Tue, 30 Nov 2004 15:38:48 -0500 Received: from [69.82.26.209] (209.sub-69-82-26.myvzw.com [69.82.26.209]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUKUZQ24045; Tue, 30 Nov 2004 12:30:36 -0800 (PST) Message-ID: <41ACD866.8090307@isi.edu> Date: Tue, 30 Nov 2004 12:30:30 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: [Tsvwg] multiaddressing References: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Henderson, Thomas R" , tsvwg@ietf.org, Janardhan Iyengar , Randall Stewart , Ted Faber , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1519680660==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1519680660== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig384AB5450F707F6E3C31A213" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig384AB5450F707F6E3C31A213 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fleischman, Eric wrote: >>From: Joe Touch [mailto:touch@ISI.EDU] >> >>>Henderson, Thomas R wrote: >>>How do applications learn of and propagate multiple address sets >>>across which they can open multiple transport streams and load balance > > >>>across them? >> >>Why should they? If the addresses "mean" the same thing, that ought to >>be a single socket, and the network-layer delivery ought to figure out >>there's more than one way there (ala multi6 shim). > > I'm not tracking with you here, Joe. Perhaps you could clarify what you > are thinking a bit more (e.g., what stack model are you assuming?). For > example, thinking in terms of the Seamoby work, for example, how can the > transport "know" that two addresses mean the same thing? I expect you to > answer that "the shim tells them." Is this your answer or are you > thinking something else? If this is your answer, then what functions are > you assuming the shim is able to perform? How do these shim functions > interface to the IP layer and to the transport layer? See multi6 WG. They not only have answers to these questions, but drafts of solutions they're working on. Joe --------------enig384AB5450F707F6E3C31A213 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrNhmE5f5cImnZrsRApA3AJ9k8jWs+xR4xQ+15MYy15SdjFGu/QCfT6Tu YJ6fO5+qlEmbBHY30/MeINc= =CmhZ -----END PGP SIGNATURE----- --------------enig384AB5450F707F6E3C31A213-- --===============1519680660== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1519680660==-- From tsvwg-bounces@ietf.org Tue Nov 30 17:24:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22614; Tue, 30 Nov 2004 17:24:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGUy-000527-KT; Tue, 30 Nov 2004 17:29:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGA1-00051A-FW; Tue, 30 Nov 2004 17:07:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZEi4-0004pK-TS for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 15:34:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01601 for ; Tue, 30 Nov 2004 15:34:50 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZEnD-0006dy-3j for tsvwg@ietf.org; Tue, 30 Nov 2004 15:40:14 -0500 Received: from [69.82.26.209] (209.sub-69-82-26.myvzw.com [69.82.26.209]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUKWeQ24595; Tue, 30 Nov 2004 12:32:41 -0800 (PST) Message-ID: <41ACD8E2.603@isi.edu> Date: Tue, 30 Nov 2004 12:32:34 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] multiaddressing References: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> <20041130190244.GA16321@grc.nasa.gov> In-Reply-To: <20041130190244.GA16321@grc.nasa.gov> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Henderson, Thomas R" , tsvwg@ietf.org, Janardhan Iyengar , "Fleischman, Eric" , Ted Faber , Randall Stewart , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1984253361==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1984253361== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8A5E5E943B9DE869AEB58DED" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8A5E5E943B9DE869AEB58DED Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wesley Eddy wrote: > On Tue, Nov 30, 2004 at 10:34:47AM -0800, Fleischman, Eric wrote: > >>How do these shim functions interface to the IP layer and to the >>transport layer? > > > That's a question I've been (poorly) trying to ask, with the point being > that we need to think about this interface in TSVWG. The shims will be > interfacing with the transport and as the transport group, we'll need to > make sure that the interface they provide is adequate for the things > transports do. > > -Wes It would be useful to review the docs of the shim subgroup of multi6. They're just now being submitted to be WG docs. Joe --------------enig8A5E5E943B9DE869AEB58DED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrNjiE5f5cImnZrsRAlR0AJ9EOycRkGj05UfeQqxT5QHm83FQIACgkGL8 uKgGf3CHw2iOj6ypzcoXwT8= =lChP -----END PGP SIGNATURE----- --------------enig8A5E5E943B9DE869AEB58DED-- --===============1984253361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1984253361==-- From tsvwg-bounces@ietf.org Tue Nov 30 17:37:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24132; Tue, 30 Nov 2004 17:37:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGhh-0005U1-Oj; Tue, 30 Nov 2004 17:42:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGEk-0007Pi-0R; Tue, 30 Nov 2004 17:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFHL-0001qS-IY for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 16:11:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07681 for ; Tue, 30 Nov 2004 16:11:16 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFMU-00008a-JL for tsvwg@ietf.org; Tue, 30 Nov 2004 16:16:41 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUL96Q06130; Tue, 30 Nov 2004 13:09:06 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAUL96kh018090; Tue, 30 Nov 2004 13:09:06 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAUL9680018089; Tue, 30 Nov 2004 13:09:06 -0800 (PST) (envelope-from faber) Date: Tue, 30 Nov 2004 13:09:05 -0800 From: Ted Faber To: "Fleischman, Eric" Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041130210905.GG15528@pun.isi.edu> References: <5B58696DB20B9140AD20E0685C573A6404FDDA2E@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDA2E@xch-nw-09.nw.nos.boeing.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "Henderson, Thomas R" , Randall Stewart , tsvwg@ietf.org, Janardhan Iyengar , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0186570348==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --===============0186570348== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kadn00tgSopKmJ1H" Content-Disposition: inline --kadn00tgSopKmJ1H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 30, 2004 at 11:01:20AM -0800, Fleischman, Eric wrote: > Ted Faber [mailto:faber@ISI.EDU] wrote: > >>Fleischman, Eric wrote: > > > >>DNS is good for a great many things. However, it isn't particularly > >>good for supporting transitory, real-time, and short-lived > >>information. > > >None of which was in the problem statement. The objection to DNS > >(and there was one) was that using it "created another dependency," > >not that the data was so volitile that it violated the DNS's > >famously loose consistency requirements. > > >I certainly agree with your assessment of DNS's suitabiltly for > >handling rapidly changing data. It's not good for passing out > >doughnuts, either. > > Ignoring the doughnut comment, the view from my knot-hole is that this > discussion is hampered by differing and not fully articulated concept of > operations. I come from the MANET world where I think in terms of > constantly changing network topologies. Mobile IP and NEMO people think > in terms of end system or network mobility in the context of a stable > network environment. Other people think in terms of stable wire-line > networks with limited or no mobility. > > Multiple addresses may result from many causes, including mobility, > private address spaces (e.g., NATs), multi-homing, multiple protocol > support (e.g., IPv4 and IPv6), and IPv6 address usages. > > I assume that a preferable solution for this issue would scratch the > itches of all three types of environments (stable, mobile, highly > mobile). From where I sit, DNS is appropriate for stable wire-line > networks. It may or may not be appropriate for mobile (MIB and NEMO) > environments, depending on certain (thus far unstated) concept of > operations assumptions. However, it probably isn't appropriate for > highly mobile (MANET) environments for this particular usage. Despite my testy reply, I think we agree a bunch more than we disagree. I understand what you're saying and I apologize for snapping. As I'm sure you know, there's quite a bit to worry about beyond naming when you consider endpoints that move often and need to maintain communications when they do so. You can constrain yourself into an unsolvable problem pretty quickly. IMHO, one should grab at tradeoffs when they appear. For example, the scale of most of the proposed MANETs I've seen (other than sensor networks) means you can trade scope for consistency in the naming system. A small (by Internet standards) network of endpoints that change their name-to-address mappings frequently is a lousy fit for DNS, and there's no good reason to use it there. (Though having a name system tuned for that environment repsond to DNS queries might be of practical use.) The more of these sorts of discussions I have, the less I think that the various uses of multi-homing (e.g., mobility, availability, load balancing) are all that closely related. I'm less optimisitic that there is a single "multi-homing" solution that will scratch all those itches. In any case I think that it's an area in which people should tread carefully and precisely. I'm also concerned about making transport level changes without a clear need or at least a clear indication of the tradeoffs. I've yet to see a case where a system is impossible without moving multihoming into the transport or where all the hard parts are solved and the extra kernel/layer crossings are the only think keeping the system from being efficient. I'm not saying that they don't exist, just that I haven't seen clear demonstrations. Finally endpoint to endpoint transport where both endpoints have static single identifiers is tricky. Building on that rather than complicating it seems like the way to go. I recognize that's an opinion, but it's one that I hold pretty strongly. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --kadn00tgSopKmJ1H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBrOFxaUz3f+Zf+XsRAh9jAKC277NMKgQHP4wkyBSal/+Eb0kQXwCggKKt RzpOjo5Pld5+J6gScIh6cNU= =iBP0 -----END PGP SIGNATURE----- --kadn00tgSopKmJ1H-- --===============0186570348== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0186570348==-- From tsvwg-bounces@ietf.org Tue Nov 30 17:39:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24460; Tue, 30 Nov 2004 17:39:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGkD-0005am-6r; Tue, 30 Nov 2004 17:45:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGGl-0000O0-1N; Tue, 30 Nov 2004 17:14:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFOp-0007KW-OO for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 16:19:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09819 for ; Tue, 30 Nov 2004 16:19:01 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFU0-0000p6-AO for tsvwg@ietf.org; Tue, 30 Nov 2004 16:24:25 -0500 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAULGxQ08111; Tue, 30 Nov 2004 13:16:59 -0800 (PST) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.1/8.13.1) with ESMTP id iAULGxBc018196; Tue, 30 Nov 2004 13:16:59 -0800 (PST) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.1/8.13.1/Submit) id iAULGxSx018195; Tue, 30 Nov 2004 13:16:59 -0800 (PST) (envelope-from faber) Date: Tue, 30 Nov 2004 13:16:59 -0800 From: Ted Faber To: Jukka MJ Manner Subject: Re: [Tsvwg] Reviews of RSVP extensions (here, there, or ... ?) Message-ID: <20041130211659.GH15528@pun.isi.edu> References: <4.3.2.7.2.20041129213955.0250ce98@localhost> <20041130182813.GC15528@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "James M. Polk" , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1004000010==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a --===============1004000010== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYYhpFXgKVw71fwr" Content-Disposition: inline --mYYhpFXgKVw71fwr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Nov 30, 2004 at 09:45:15PM +0200, Jukka MJ Manner wrote: > > Hi, > > Mobile IP had been going on for years and years, and there was way too > many drafts to handle by one WG and its chairs. I don't know/remember all > the details behing the split, but it has worked, as far as I can tell. The > same thing could be done here: get the RSVP documents, and people > interested in those, to a new WG that will quickly deal with them, and > close - quick, clean, and simple. My impression hasn't been that there's been a shortage of time to present or discuss these drafts in TSVWG, but a low interest level. I'm not sure that a new group would address that. That's an impression; I could be way off. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --mYYhpFXgKVw71fwr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBrONLaUz3f+Zf+XsRAokpAKD37F8ThwMDq07qIJwGQBkSdKSW1wCg9Vcr dUs9oABKykHV65wWQy6WY/4= =uIMV -----END PGP SIGNATURE----- --mYYhpFXgKVw71fwr-- --===============1004000010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1004000010==-- From tsvwg-bounces@ietf.org Tue Nov 30 17:41:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24629; Tue, 30 Nov 2004 17:41:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGlN-0005df-MF; Tue, 30 Nov 2004 17:46:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGHH-0000nT-KM; Tue, 30 Nov 2004 17:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFRJ-0000X1-RL for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 16:21:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10421 for ; Tue, 30 Nov 2004 16:21:35 -0500 (EST) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFWS-0000zv-8u for tsvwg@ietf.org; Tue, 30 Nov 2004 16:26:59 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 4204B6BA58 for ; Tue, 30 Nov 2004 16:21:01 -0500 (EST) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id iAULKxhJ028156; Tue, 30 Nov 2004 16:20:59 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 343324FC16; Tue, 30 Nov 2004 16:17:51 -0500 (EST) Date: Tue, 30 Nov 2004 16:17:51 -0500 From: Wesley Eddy To: Joe Touch Subject: Re: [Tsvwg] multiaddressing Message-ID: <20041130211751.GC16321@grc.nasa.gov> References: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> <20041130190244.GA16321@grc.nasa.gov> <41ACD8E2.603@isi.edu> Mime-Version: 1.0 In-Reply-To: <41ACD8E2.603@isi.edu> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Henderson, Thomas R" , tsvwg@ietf.org, Janardhan Iyengar , "Fleischman, Eric" , Ted Faber , Randall Stewart , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1723771689==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --===============1723771689== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk" Content-Disposition: inline --HG+GLK89HZ1zG0kk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 30, 2004 at 12:32:34PM -0800, Joe Touch wrote: >=20 > It would be useful to review the docs of the shim subgroup of multi6.=20 > They're just now being submitted to be WG docs. >=20 Specifically, draft-nordmark-multi6dt-shim-00.txt lists one of the shim's goals as: """ o Have no impact on upper layer protocols in general and on transport protocols in particular. """ -Wes --HG+GLK89HZ1zG0kk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBrON+zBuYqbnj3IwRAmglAJ40wTrwABlrm8jiFcXJRbuE3a2e7wCeIOLa vO6fLWqQXu2149gx+XbvfkI= =c4yp -----END PGP SIGNATURE----- --HG+GLK89HZ1zG0kk-- --===============1723771689== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1723771689==-- From tsvwg-bounces@ietf.org Tue Nov 30 19:36:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04844; Tue, 30 Nov 2004 19:36:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIYo-0008L3-HD; Tue, 30 Nov 2004 19:41:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIRw-0005nX-Ry; Tue, 30 Nov 2004 19:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIQy-0005Ur-Gd for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 19:33:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04620 for ; Tue, 30 Nov 2004 19:33:25 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIWB-0008FX-3R for tsvwg@ietf.org; Tue, 30 Nov 2004 19:38:52 -0500 Received: from [166.153.43.38] (38.sub-166-153-43.myvzw.com [166.153.43.38]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iB10TjQ29839; Tue, 30 Nov 2004 16:29:46 -0800 (PST) Message-ID: <41AD1074.5000801@isi.edu> Date: Tue, 30 Nov 2004 16:29:40 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] multiaddressing References: <5B58696DB20B9140AD20E0685C573A6404FDDA2D@xch-nw-09.nw.nos.boeing.com> <20041130190244.GA16321@grc.nasa.gov> <41ACD8E2.603@isi.edu> <20041130211751.GC16321@grc.nasa.gov> In-Reply-To: <20041130211751.GC16321@grc.nasa.gov> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Henderson, Thomas R" , tsvwg@ietf.org, Janardhan Iyengar , "Fleischman, Eric" , Ted Faber , Randall Stewart , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2136827704==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2136827704== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig753DDCCD7B1F9BA10E75A694" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig753DDCCD7B1F9BA10E75A694 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wesley Eddy wrote: > On Tue, Nov 30, 2004 at 12:32:34PM -0800, Joe Touch wrote: > >>It would be useful to review the docs of the shim subgroup of multi6. >>They're just now being submitted to be WG docs. >> > > > Specifically, draft-nordmark-multi6dt-shim-00.txt lists one of the shim's > goals as: > """ > o Have no impact on upper layer protocols in general and on > transport protocols in particular. > """ > > -Wes No impact means no detrimental impact. It'd be useless if there's no benefit. Granted, they're not working on using multiple connections at once, but they are doing all the rest of what was mentioned - including shifting addresses as needed and potentially informing a transport or application that wants to know (AFAIR). I.e., adding muxing there seems the obvious place, rather than at the transport or the application. Joe --------------enig753DDCCD7B1F9BA10E75A694 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrRB1E5f5cImnZrsRAj+oAJ9bN2eb+C/QuM91regKEWhqPdm+DQCgjjJW JQ7CZL331cqE9pQncGKgwwg= =jB+A -----END PGP SIGNATURE----- --------------enig753DDCCD7B1F9BA10E75A694-- --===============2136827704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============2136827704==-- From tsvwg-bounces@ietf.org Tue Nov 30 20:34:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10554; Tue, 30 Nov 2004 20:34:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZJT3-0001Mj-I1; Tue, 30 Nov 2004 20:39:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZJH2-00008V-9L; Tue, 30 Nov 2004 20:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZJFD-0007xg-KO for tsvwg@megatron.ietf.org; Tue, 30 Nov 2004 20:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09914 for ; Tue, 30 Nov 2004 20:25:21 -0500 (EST) Received: from vscan.fit.ac.jp ([150.43.1.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZJKQ-0001CW-Le for tsvwg@ietf.org; Tue, 30 Nov 2004 20:30:47 -0500 Received: from dontaku.fit.ac.jp (localhost [127.0.0.1]) by vscan.fit.ac.jp (8.12.5/8.12.5) with ESMTP id iB11On9f002037 for ; Wed, 1 Dec 2004 10:24:50 +0900 (JST) Received: from [150.43.233.162] (nausica.ce.fit.ac.jp [150.43.233.162]) by dontaku.fit.ac.jp (8.11.6/3.7W03112810) with ESMTP id iB11OnI05523 for ; Wed, 1 Dec 2004 10:24:49 +0900 Message-ID: <41AD1D99.1010307@unisa.it> Date: Wed, 01 Dec 2004 10:25:45 +0900 From: giuseppe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Add/Delete under ns X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Somebody knows whether are some extensions to ns for Add/Delete IP features available? G _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg