From gorry@erg.abdn.ac.uk Fri Dec 6 04:04:09 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCA91AE37D; Fri, 6 Dec 2013 04:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5xZjzCOEhR9; Fri, 6 Dec 2013 04:04:07 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 13F901AE37A; Fri, 6 Dec 2013 04:04:04 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 2607D2B44CE; Fri, 6 Dec 2013 12:04:00 +0000 (GMT) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id EC1562B44A6; Fri, 6 Dec 2013 12:03:58 +0000 (GMT) Message-ID: <52A1BD2E.8080308@erg.abdn.ac.uk> Date: Fri, 06 Dec 2013 12:03:58 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: iesg-secretary@ietf.org, tsvwg-ads@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: tsvwg@ietf.org Subject: [tsvwg] Addition of TSVWG Charter Milestones X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 12:04:09 -0000 Spencer (as responsible AD), the following drafts were discussed in the TSVWG meetings in Vancouver and received support at that meeting, offers to review, and no noted opposition. Since then, a WG call for adoption has completed. This has confirmed this position. The Chairs therefore request the addition of the following milestones to the TSVWG charter. Please could the ADs approve this request? Gorry (co-Chair TSVWG) ---- PLEASE ADD THE FOLLOWING NEW MILESTONES TO THE TSVWG CHARTER: NEW: Jan 2014 Submit ‘SCTP PR Polices’ as a PS RFC NEW: Jul 2014 Submit ‘SCTP New Data Chunk’ as a PS RFC From gorry@erg.abdn.ac.uk Fri Dec 6 04:13:02 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022931ADF5E; Fri, 6 Dec 2013 04:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv1oQD8BCTjT; Fri, 6 Dec 2013 04:13:00 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 48E231ACAD7; Fri, 6 Dec 2013 04:13:00 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 5B6852B44CC; Fri, 6 Dec 2013 12:12:56 +0000 (GMT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 647142B44A6; Fri, 6 Dec 2013 12:12:54 +0000 (GMT) Message-ID: <52A1BF46.8050302@erg.abdn.ac.uk> Date: Fri, 06 Dec 2013 12:12:54 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [tsvwg] Updated TSVWG milestones and new work items. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 12:13:02 -0000 TSVWG, This note documents a set of updates to the Charter, approved following discussion at the TSVWG meetings at IETF-88. These changes will be recorded shortly in the TSVWG Charter page. Gorry (co-Chair TSVWG) --- NEW: Apr 2015 Submit 'RSVP Multiple Instance' to IESG as a PS RFC” NOTE: Above change includes a name change, the WG has decided to change the direction of the work to make the result simpler and more general. After updating the milestone we'll formally confirm the WG is OK with the new proposed solution and then adopt the new draft NEW: Nov 2014 Submit 'SCTP NAT Support' to IESG for consideration as a PS RFC NOTE: Revised date. NEW: May 2014 Submit 'Quick Failover Algorithm in SCTP' to the IESG for consideration as an Experimental RFC NOTE: Revised date. Note that we may LATER discuss if this should be considered as a PS. NEW: Jan 2014 Submit 'RSVP Application-ID Profiles for Voice and Video Streams' to IESG for consideration as a Proposed Standard RFC NOTE: Revised date. NEW: Jan 2014 Submit 'Encoding and Transport of (Pre-) Congestion Information from the Domain Egress to the Ingress' to the IESG for consideration as an Experimental RFC NOTE: Revised date. NEW: Nov 2014 Submit 'SCTP NAT SpecificationÂ’ as a BCP RFC NOTE: Formerly a Behave WG work item. NEW: Nov 2014 Submit 'Behavioral Requirements UpdatesÂ’ as a BCP RFC NOTE: Formerly a Behave WG work item. NEW: Jul 2014 Submit ‘Multicast UDP GuidelinesÂ’ as a BCP RFC NOTE: Notified in TSVWG and MBONED. --- From ietf-secretariat-reply@ietf.org Fri Dec 6 08:52:40 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD101AE05C for ; Fri, 6 Dec 2013 08:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjlPGoXlDMtZ for ; Fri, 6 Dec 2013 08:52:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CD11AE33D for ; Fri, 6 Dec 2013 08:52:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206165237.6746.60039.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 08:52:37 -0800 From: IETF Secretariat Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:52:40 -0000 Changed milestone "Submit 'Encoding and Transport of (Pre-) Congestion Information from the Domain Egress to the Ingress' to the IESG for consideration as an Experimental RFC", set due date to January 2014 from May 2013. Changed milestone "Submit 'RSVP Application-ID Profiles for Voice and Video Streams' to IESG for consideration as a Proposed Standard RFC", set due date to January 2014 from July 2013. Changed milestone "Submit 'Quick Failover Algorithm in SCTP' to the IESG for consideration as an Experimental RFC", set due date to May 2014 from July 2013. Added milestone "Submit =C2=91Multicast UDP Guidelines=C2=92 as a BCP RFC",= due July 2014. Added milestone "Submit 'Behavioral Requirements Updates=C2=92 as a BCP RFC", due November 2014. Changed milestone "Submit 'SCTP NAT Support' to IESG for consideration as a Proposed Standard", set description to "Submit 'SCTP NAT Support' to IESG for consideration as a PS RFC", set due date to November 2014 from May 2013. Added milestone "Submit 'SCTP NAT Specification=C2=92 as a BCP RFC", due November 2014. Changed milestone "Submit 'Intserv Multiple TSpec' to IESG for consideration as a Proposed Standard RFC", set description to "Submit 'RSVP Multiple Instance' to IESG as a PS RFC", set due date to April 2015 from May 2012. URL: http://datatracker.ietf.org/wg/tsvwg/charter/ From spencerdawkins.ietf@gmail.com Sat Dec 7 21:56:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408991AD945; Sat, 7 Dec 2013 21:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGl-Qw-_E4Y3; Sat, 7 Dec 2013 21:56:01 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 452E91AD944; Sat, 7 Dec 2013 21:56:01 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq4so2530013wib.1 for ; Sat, 07 Dec 2013 21:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ILGl75its4+ltr/qOYzP6jdY5xQFQgeeta+QnMNUMYo=; b=AcdfnRyip5QOwBh1wruWPbU2Lqv4WZvARFCEn4xB7tGxOu4f90AhE4FCox8d2pfA/5 +TxfgQwmptOO1ncMMilAUcNgU+BBNLsiM5KBZguzzQilzzJrHC2813gZLuMWz+D8srj9 Q/ZQleWipGe56G4n1melF3lbW4DHebOGK/QKAZsow7k/syFehG14akVnl+PUn6LV0YTk PVzhYxfuHrLXQOLijDTbjTBvpHTZ2E245ZHtEoJ6mYLt6/AS4LYf9uGAODiY3drMDFCF d1OG4l5cDcPCh1IUbuqj9f+ERIhaBnXUgF6H9ocFl5XUNFjWaXzDIJ8lK0YaB4NCZO+k J+nQ== X-Received: by 10.180.206.138 with SMTP id lo10mr8946354wic.25.1386482156427; Sat, 07 Dec 2013 21:55:56 -0800 (PST) Received: from [192.168.0.23] (173-135-98-63.pools.spcsdns.net. [173.135.98.63]) by mx.google.com with ESMTPSA id cx3sm10723001wib.0.2013.12.07.21.55.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 21:55:55 -0800 (PST) Message-ID: <52A409E7.2050900@gmail.com> Date: Sat, 07 Dec 2013 23:55:51 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: iesg-secretary@ietf.org References: <52A1BD2E.8080308@erg.abdn.ac.uk> In-Reply-To: <52A1BD2E.8080308@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, tsvwg-ads@ietf.org Subject: Re: [tsvwg] Addition of TSVWG Charter Milestones X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 05:56:03 -0000 Dear IESG Secretary, These milestones are approved ... Thank you, Spencer On 12/06/2013 06:03 AM, Gorry Fairhurst wrote: > > Spencer (as responsible AD), > > the following drafts were discussed in the TSVWG meetings in Vancouver > and received support at that meeting, offers to review, and no noted > opposition. > > Since then, a WG call for adoption has completed. This has confirmed > this position. The Chairs therefore request the addition of the > following milestones to the TSVWG charter. > > Please could the ADs approve this request? > > Gorry > (co-Chair TSVWG) > > ---- > > PLEASE ADD THE FOLLOWING NEW MILESTONES TO THE TSVWG CHARTER: > > NEW: > Jan 2014 Submit ‘SCTP PR Polices’ as a PS RFC > > NEW: > Jul 2014 Submit ‘SCTP New Data Chunk’ as a PS RFC > From ietf-secretariat-reply@ietf.org Mon Dec 9 09:01:47 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829E01ADFE0 for ; Mon, 9 Dec 2013 09:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mbbO8wW5E0x for ; Mon, 9 Dec 2013 09:01:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ABB1ADFF6 for ; Mon, 9 Dec 2013 09:01:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209170145.5159.95476.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 09:01:45 -0800 From: IETF Secretariat Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:01:47 -0000 Added milestone "Submit 'SCTP PR Polices' as a PS RFC", due January 2014. Added milestone "Submit 'SCTP New Data Chunk' as a PS RFC", due July 2014. URL: http://datatracker.ietf.org/wg/tsvwg/charter/ From ietf-secretariat-reply@ietf.org Thu Dec 12 05:44:32 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3221AE2DA for ; Thu, 12 Dec 2013 05:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urpsup63z8X0 for ; Thu, 12 Dec 2013 05:44:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6041AE2DB for ; Thu, 12 Dec 2013 05:44:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212134430.7131.70607.idtracker@ietfa.amsl.com> Date: Thu, 12 Dec 2013 05:44:30 -0800 From: IETF Secretariat Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:44:32 -0000 Changed milestone "Submit 'Behavioral Requirements Updates=C2=92 as a BCP RFC", set description to "Submit 'Behavioral Requirements Updates'=C2=92 as a BCP RFC". URL: http://datatracker.ietf.org/wg/tsvwg/charter/ From ietf-secretariat-reply@ietf.org Thu Dec 12 06:11:35 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807001AE1F3 for ; Thu, 12 Dec 2013 06:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0NV1-Tz-acr for ; Thu, 12 Dec 2013 06:11:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F190F1AE2BA for ; Thu, 12 Dec 2013 06:11:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212141132.13488.36913.idtracker@ietfa.amsl.com> Date: Thu, 12 Dec 2013 06:11:32 -0800 From: IETF Secretariat Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 14:11:35 -0000 Changed milestone "Submit =C2=91Multicast UDP Guidelines=C2=92 as a BCP RFC= ", set description to "Submit '=C2=91Multicast UDP Guidelines' as a BCP RFC". Changed milestone "Submit 'SCTP NAT Specification=C2=92 as a BCP RFC", set description to "Submit 'SCTP NAT Specification=C2=92' as a BCP RFC". URL: http://datatracker.ietf.org/wg/tsvwg/charter/ From internet-drafts@ietf.org Sat Dec 14 05:48:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1986E1AE033; Sat, 14 Dec 2013 05:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wUmXB1VVJ1O; Sat, 14 Dec 2013 05:47:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 180DD1AE04A; Sat, 14 Dec 2013 05:43:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131214134347.18883.88528.idtracker@ietfa.amsl.com> Date: Sat, 14 Dec 2013 05:43:47 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-prpolicies-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 13:48:04 -0000 X-List-Received-Date: Sat, 14 Dec 2013 13:48:04 -0000 X-List-Received-Date: Sat, 14 Dec 2013 13:48:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Additional Policies for the Partial Reliability Extensio= n of the Stream Control Transmission Protocol Author(s) : Michael Tuexen Robin Seggelmann Randall R. Stewart Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-prpolicies-00.txt Pages : 6 Date : 2013-12-14 Abstract: This document defines policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michawe@ifi.uio.no Sun Dec 15 08:59:55 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26AB1AE0A3; Sun, 15 Dec 2013 08:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVAx9_oGDPJc; Sun, 15 Dec 2013 08:59:52 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id BFC891AE090; Sun, 15 Dec 2013 08:59:51 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VsF2j-0005IX-AD; Sun, 15 Dec 2013 17:59:49 +0100 Received: from 089144206194.atnat0015.highway.bob.at ([89.144.206.194] helo=[192.168.1.2]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VsF2f-00062i-8b; Sun, 15 Dec 2013 17:59:49 +0100 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_C2EB6189-E4F2-4307-BD58-1773C3B05227" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Sun, 15 Dec 2013 17:59:40 +0100 References: <44BAC6A4-D208-4043-B777-57F2F4910559@kau.se> To: "iccrg@irtf.org" , tsvwg IETF list , "tsv-area@ietf.org" X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 12 sum msgs/h 6 total rcpts 10980 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C93574002F16E4A3FDB5B171EB5F87CF4E5FB42C X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 89.144.206.194 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 8 max/h 4 blacklist 0 greylist 1 ratelimit 0 Cc: "transport-services@ifi.uio.no" Subject: [tsvwg] About the Transport Services BOF: new drafts available X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 16:59:56 -0000 --Apple-Mail=_C2EB6189-E4F2-4307-BD58-1773C3B05227 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, I'd like to give you an update about recent activities regarding a = proposed BOF on Transport Services for the London IETF. The website for = this activity is here = https://sites.google.com/site/transportprotocolservices/ and the BOF = request is visible in the IETF Wiki: = http://wiki.tools.ietf.org/bof/trac/ There was a side meeting in Vancouver, in which the major feedback was = that we should not be too focused on the Berkeley sockets API and what = existing transports can provide, but really look at what applications = currently use and what services they want. We have incorporated this = feedback and begun with some homework in this direction - two related = drafts have recently been submitted: http://tools.ietf.org/html/draft-montpetit-transport-use-cases-00 which = discusses some application use cases and derived requirements, and the = draft described below, = http://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis-00 which = discusses transport APIs. Essentially the first draft shows some = futuristic things (what applications could do in the future), while the = focus of the second draft is on how we could improve existing = applications by only updating the middleware that they use. If you want to get a better idea of what this whole thing is about, you = could look at the problem statement draft: draft-moncaster-tsvwg-transport-services-01 We're glad to get contributions or feedback (which should be directed to = the transport-services list, i.e. transport-services@ifi.uio.no / = https://sympa.uio.no/ifi.uio.no/info/transport-services ). Thanks, cheers, Michael Begin forwarded message: > From: Per Hurtig > Subject: Fwd: New Version Notification for = draft-hurtig-tsvwg-transport-apis-00.txt > Date: 15. desember 2013 16:56:55 CET > To: "" > Cc: Michael Welzl , Stein Gjessing = , Martin Sustrik >=20 > Dear all, >=20 > we have now submitted a first draft describing transport APIs and how = they could > be improved using transport services.=20 > The URL to the draft: = http://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis-00 >=20 > Abstract > --- > Commonly used networking APIs are currently limited by the transport = layer's > inability to expose services instead of protocols. An = API/application/user is > therefore forced to use exactly the services that are implemented by = the > selected transport. This document surveys networking APIs and = discusses how they > can be improved by a more expressive transport layer that hides and = automatizes > the choice of the transport protocol. > --- >=20 > We=92d like people to comment the contents and also help out in = surveying the > different APIs listed in the draft. We would also like feedback on = APIs that > should be included but are not. The complete list of included APIs is = given > below together with status (completed/claimed/unclaimed). The = completed ones > need review, the claimed are currently being written, and the = unclaimed is up > for grabs by you! >=20 > * ZeroMQ (completed) > * nanomsg (claimed) > * enet (completed) > * Java Message Service (unclaimed) > * Chrome Network Stack (unclaimed) > * CFNetwork (unclaimed) > * Apache Portable Runtime (claimed) > * VirtIO (unclaimed) > * BSD Sockets (unclaimed) > * Java Libraries (completed) > * Netscape Portable Runtime (unclaimed) > * Infiniband Verbs (unclaimed) > * Input/Output Completion Port (unclaimed) >=20 >=20 >=20 > Best Regards, > Per Hurtig >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-hurtig-tsvwg-transport-apis-00.txt >> Date: 15 Dec 2013 16:51:34 GMT+1 >> To: Per Hurtig , Stein Gjessing = , Michael Welzl , Martin = Sustrik >>=20 >>=20 >> A new version of I-D, draft-hurtig-tsvwg-transport-apis-00.txt >> has been successfully submitted by Per Hurtig and posted to the >> IETF repository. >>=20 >> Filename: draft-hurtig-tsvwg-transport-apis >> Revision: 00 >> Title: Transport APIs >> Creation date: 2013-12-15 >> Group: Individual Submission >> Number of pages: 13 >> URL: = http://www.ietf.org/internet-drafts/draft-hurtig-tsvwg-transport-apis-00.t= xt >> Status: = http://datatracker.ietf.org/doc/draft-hurtig-tsvwg-transport-apis >> Htmlized: = http://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis-00 >>=20 >>=20 >> Abstract: >> Commonly used networking APIs are currently limited by the transport >> layer's inability to expose services instead of protocols. An API/ >> application/user is therefore forced to use exactly the services = that >> are implemented by the selected transport. This document surveys >> networking APIs and discusses how they can be improved by a more >> expressive transport layer that hides and automatizes the choice of >> the transport protocol. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 >=20 --Apple-Mail=_C2EB6189-E4F2-4307-BD58-1773C3B05227 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = all,

I'd like to give you an update about recent = activities regarding a proposed BOF on Transport Services for the London = IETF. The website for this activity is here https://= sites.google.com/site/transportprotocolservices/  and the BOF = request is visible in the IETF Wiki: http://wiki.tools.ietf.org/b= of/trac/

There was a side meeting in = Vancouver, in which the major feedback was that we should not be too = focused on the Berkeley sockets API and what existing transports can = provide, but really look at what applications currently use and what = services they want. We have incorporated this feedback and begun with = some homework in this direction - two related drafts have recently been = submitted:
http://tools.ietf.org/html/draft-montpetit-transport-use-cases-00 = which discusses some application use cases and derived requirements, and = the draft described below, h= ttp://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis-00 which = discusses transport APIs. Essentially the first draft shows some = futuristic things (what applications could do in the future), while the = focus of the second draft is on how we could improve existing = applications by only updating the middleware that they = use.

If you want to get a better idea of what = this whole thing is about, you could look at the problem statement = draft:

We're glad to get contributions or feedback (which should be directed = to the transport-services list, i.e. transport-services@ifi.uio.n= o  /  https://s= ympa.uio.no/ifi.uio.no/info/transport-services  = ).

Thanks, = cheers,
Michael


Begin = forwarded message:

From: Per Hurtig <per.hurtig@kau.se>
Subject: = Fwd: New Version Notification for = draft-hurtig-tsvwg-transport-apis-00.txt
Date: 15. desember 2013 = 16:56:55 CET
Cc: Michael Welzl <michawe@ifi.uio.no>, Stein = Gjessing <steing@ifi.uio.no>, Martin = Sustrik <sustrik@250bpm.com>

Dear all,

we have now submitted a first draft = describing transport APIs and how they could
be improved using = transport services.
The URL to the draft: h= ttp://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis-00

= Abstract
---
Commonly used networking APIs are currently limited = by the transport layer's
inability to expose services instead of = protocols. An API/application/user is
therefore forced to use exactly = the services that are implemented by the
selected transport. This = document surveys networking APIs and discusses how they
can be = improved by a more expressive transport layer that hides and = automatizes
the choice of the transport protocol.
---

We=92d = like people to comment the contents and also help out in surveying = the
different APIs listed in the draft. We would also like feedback = on APIs that
should be included but are not. The complete list of = included APIs is given
below together with status = (completed/claimed/unclaimed). The completed ones
need review, the = claimed are currently being written, and the unclaimed is up
for = grabs by you!

* ZeroMQ (completed)
* nanomsg (claimed)
* = enet (completed)
* Java Message Service (unclaimed)
* Chrome = Network Stack (unclaimed)
* CFNetwork (unclaimed)
* Apache = Portable Runtime (claimed)
* VirtIO (unclaimed)
* BSD Sockets = (unclaimed)
* Java Libraries (completed)
* Netscape Portable = Runtime (unclaimed)
* Infiniband Verbs (unclaimed)
* Input/Output = Completion Port (unclaimed)



Best Regards,
Per = Hurtig

Begin forwarded message:

From: internet-drafts@ietf.org
S= ubject: New Version Notification for = draft-hurtig-tsvwg-transport-apis-00.txt
Date: 15 Dec 2013 16:51:34 = GMT+1
To: Per Hurtig <per.hurtig@kau.se>, Stein = Gjessing <stein.gjessing@ifi.uio.no>= ;, Michael Welzl <michawe@ifi.uio.no>, Martin = Sustrik <sustrik@250bpm.com>


A= new version of I-D, draft-hurtig-tsvwg-transport-apis-00.txt
has = been successfully submitted by Per Hurtig and posted to the
IETF = repository.

Filename: = draft-hurtig-tsvwg-transport-apis
Revision: = 00
Title: = = Transport APIs
Creation date: 2013-12-15
Group: = Individual Submission
Number of pages: 13
URL: =             http://www.ietf.org/internet-drafts/draft-hurtig-tsvwg-transpo= rt-apis-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-hurtig-tsvwg-transport-apis
= Htmlized:        h= ttp://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis-00

=
Abstract:
 Commonly used networking APIs are currently = limited by the transport
 layer's inability to expose services = instead of protocols.  An API/
 application/user is = therefore forced to use exactly the services that
 are = implemented by the selected transport.  This document surveys
=  networking APIs and discusses how they can be improved by a = more
 expressive transport layer that hides and automatizes the = choice of
 the transport protocol.




Please = note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF = Secretariat




= --Apple-Mail=_C2EB6189-E4F2-4307-BD58-1773C3B05227-- From Mirko.Suznjevic@fer.hr Mon Dec 16 02:27:01 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501BB1AE11D; Mon, 16 Dec 2013 02:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j8sKtC3wpHW; Mon, 16 Dec 2013 02:26:55 -0800 (PST) Received: from mail.fer.hr (mail5.fer.hr [161.53.72.235]) by ietfa.amsl.com (Postfix) with ESMTP id 563E81ADDAC; Mon, 16 Dec 2013 02:26:54 -0800 (PST) Received: from MAIL4.fer.hr ([fe80::40a6:8369:434e:dfdc]) by MAIL5.fer.hr ([fe80::adf5:20ce:8838:5e78%11]) with mapi id 14.02.0342.003; Mon, 16 Dec 2013 11:26:52 +0100 From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: "tcmtf@ietf.org" Thread-Topic: New version of draft-suznjevic-tsvwg-mtd-tcmtf Thread-Index: Ac76SVVJxMXdvv2LRdyFDOLTPsPZTQ== Date: Mon, 16 Dec 2013 10:26:51 +0000 Message-ID: Accept-Language: en-US, hr-HR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:8204:d606:cafe:ddb4:a4f3:52e5:e029] Content-Type: multipart/alternative; boundary="_000_E004A7C54DE04F4BB87DB9F32308DA5C0EFDDDMAIL4ferhr_" MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: [tsvwg] New version of draft-suznjevic-tsvwg-mtd-tcmtf X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 10:27:01 -0000 --_000_E004A7C54DE04F4BB87DB9F32308DA5C0EFDDDMAIL4ferhr_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, We have submitted the new version of draft-suznjevic-tsvwg-mtd-tcmtf-02 nam= ed Delay Limits and Multiplexing Policies to be employed with Tunneling Com= pressed Multiplexed Traffic Flows http://tools.ietf.org/html/draft-suznjevi= c-tsvwg-mtd-tcmtf-02 It intended as a supportive document for TCM-TF http://datatracker.ietf.org= /doc/draft-saldana-tsvwg-tcmtf/. Since a specific list for tcmtf exists (tc= mtf@ietf.org), the idea is to discuss it there. The draft contains recommendations for TCM-TF multiplexing period for diffe= rent network services as well as description of several policies required i= n the process of packet multiplexing. This version comprises adjustments of= certain multiplexing periods, correction regarding the types of services e= mployed and several changes in nomenclature, as suggested on the list and m= eeting in Berlin. Any comments and suggestions are very appreciated. Sincerely, Mirko Suznjevic --_000_E004A7C54DE04F4BB87DB9F32308DA5C0EFDDDMAIL4ferhr_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

We have submitted the new versi= on of draft-suznjevic-tsvwg-mtd-tcmtf-02 named Delay Limits and Multiplexin= g Policies to be employed with Tunneling Compressed Multiplexed Traffic Flo= ws http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf-02

It intended as a supportive doc= ument for TCM-TF http= ://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a specifi= c list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss it there.

The draft contains recommendati= ons for TCM-TF multiplexing period for different network services as well a= s description of several policies required in the process of packet multipl= exing. This version comprises adjustments of certain multiplexing periods, correction regarding the types of service= s employed and several changes in nomenclature, as suggested on the list an= d meeting in Berlin.

Any comments and suggestions ar= e very appreciated.

Sincerely,

Mirko Suznjevic

 

--_000_E004A7C54DE04F4BB87DB9F32308DA5C0EFDDDMAIL4ferhr_-- From gorry@erg.abdn.ac.uk Mon Dec 16 06:30:26 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACCA1ADFFE for ; Mon, 16 Dec 2013 06:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrrOHkVEzMh8 for ; Mon, 16 Dec 2013 06:30:23 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF991ADFD4 for ; Mon, 16 Dec 2013 06:30:23 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id DEED02B4510; Mon, 16 Dec 2013 14:30:21 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id D0C382B42D4 for ; Mon, 16 Dec 2013 14:30:19 +0000 (GMT) Message-ID: <52AF0E7B.6030400@erg.abdn.ac.uk> Date: Mon, 16 Dec 2013 14:30:19 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: tsvwg WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [tsvwg] TSVWG Status Update December 2013 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:30:26 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Best wishes, Gorry, David & James (TSVWG Chairs) Sept 2013 --- Recently published: draft-ietf-tsvwg-sctp-udp-encap was published as RFC 6951. draft-ietf-tsvwg-sctp-sack-immediately was published as RFC 7053. ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html draft-ietf-tsvwg-byte-pkt-congest - Document Shepherd: Gorry ------------------------------------------------------------------- IDs in IESG processing: None. ------------------------------------------------------------------- WG Drafts with Chairs: ‘Multicast UDP Guidelines’ as a BCP RFC - Document Shepherd: Gorry - WG needs to consider drafts and identify reviewers. ------------------------------------------------------------------- WG Drafts: --- draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: James Replaces: draft-karagiannis-pcn-tsvwg-rsvp-pcn AD decision allowed this to be added to the milestones Document adopted, status will be EXP (IETF-84 due to dependencies on PCN R RSVP-DIR review received (BB, KC). DUE: WGLC concluded Friday, August 23rd, 2013. Nov 2013, DUE: new ID required to address RSVP model and then repeat WGLC --- draft-ietf-tsvwg-port-use - Document Shepherd: Gorry Replaces: draft-touch-tsvwg-port-use-00 - Intended to be advice to protocol designers needing a port. 5 people looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. IETF-82, discussed. Adopted by WG Presented IETF-86, March 2013 Milestone updated to June 2014 DUE: Next step WGLC DUE: Please read sections and provide feedback! --- draft-ietf-tsvwg-rsvp-app-id-vv-profiles Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IETF-80. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Gorry liaised with MMUSIC WG Chairs on companion draft (norm ref from this tsvwg draft). Adopted as a TSVWG work item, December 2013, [Milestone Jul 2013]. This will update a RFC 2872 (PS). Presented at IETF-86, Mar 2013 (no comments) DUE: Expected ready for WGLC; DUE: Reviewers are needed to prepare for a WGLC. --- draft-ietf-tsvwg-natsupp-tsvwg - Document Shepherd: James Replaces: draft-stewart-natsupp-tsvwg Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg Authors restructured draft (-03) Added support for single and multi-homed support. IETF-86: 3 people in meeting had read -04 or -05. DUE: Authors please update following comments and align to related draft on SCTP NAT. DUE: Please comment on list ++ Dan Wing has committed to review this. --- draft-ietf-tsvwg-sctpnat Replaces: draft-ietf-behave-sctpnat-03.txt Adopted Nov 2013. Former BEHAVE WG work item that defines SCTP NAT support DUE: Authors please update to align to related draft on SCTP NAT. DUE: Please comment on list --- draft-ietf-tsvwg-requirements-update-00 Replaces: draft-ietf-behave-requirements-update-00 Nov 2013, Former BEHAVE WG work item intended for publication as a BCP DUE: Please comment on list ++ Dan Wing has committed to review this. --- draft-ietf-tsvwg-sctp-failover - Document Shepherd: James Replaces: draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - Understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD Adopted by WG 26/6/2012. [Milestone: Jul 2013, EXP] DUE: Please comment on list. --- draft-ietf-tsvwg-sctp-dtls-encaps - Document Shepherd: Gorry Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01 WG adopted 13/12/2013. Support {AB, IR, SL, MB, TD} [Milestone: Jan 2014, PS] Implemented in Firefox (FF21). Required by RTCweb. DUE: Please comment on list. --- draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David WG interest in this topic recorded at IETF-78. Charter update needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 - New name: 'RSVP Multiple Instance'. DUE: Discussion needed on list. --- draft-ietf-tsvwg-sctp-prpolicies replaces: draft-tuexen-tsvwg-sctp-prpolicies Nov 2013, Adopted SCTP PR Polices intended for publication as a PS RFC --- draft-ietf-tsvwg-sctp-ndata replaces: draft-stewart-tsvwg-sctp-ndata-03 Nov 2013, Adopted , intended for publication as a PS RFC ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. --------------------------------------------------------------- Authors request to be considered for adoption: draft-shepherd-multicast-udp-guidelines - Multicast UDP Usage Guidelines for Application Designers Announced at Orlando, IETF-86, Mar 2013 (no presentation) - Thought to fall within TSVWG charter, milestone created. - Authors requested TSVWG adoption. DUE: Please comment on list. --- draft-briscoe-tsvwg-ecn-encap-guidelines - Document Contact: Gorry -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) Authors need to update this draft. New ID presented in Atlanta, IETF-85. ID presented in IETF-88. - Authors requested TSVWG adoption. DUE: Please comment on list. --- draft-geib-tsvwg-diffserv-intercon-02.txt - Document Contact: David DiffServ interconnection classes New ID presented in Atlanta, IETF-85. ID presented in Orlando, IETF-86, Mar 2013. DUE: Please comment on list. --- draft-dhesikan-tsvwg-rtcweb-qos - RTCweb and QoS Markings - Authors requested TSVWG adoption. Chairs: Who has read the draft? (lots 10's of people) Chairs: Who thinks it is important to do work in the IETF? (Many) I-D updated after initial TSVWG feedback DUE: comment on list. --------------------------------------------------------------- Individual drafts recently discussed in TSVWG: draft-tuexen-tsvwg-sctp-multipath (CMT) -00 Presented in Prague, IETF-80. - understood not to conflict with draft-nishida-tsvwg-sctp-failover - Implemented in FreeBSD (ns2, inet) - subsumes NR-SACK -01, 2010-12-27 DUE: Please comment to list. DUE: Need to decide if this can be adopted as a WG Item --- draft-polk-tsvwg-rfc4594-update - Document Contact: David Discussed at IETF-83, Paris Noted at IETF-84, but not discussed (no time). ID-discussed at IETF-85. DUE: Please comment on list. --- draft-polk-tsvwg-new-dscp-assignments - Document Contact: David - noted at IETF-84, but not discussed (no time). Linked to above DUE: Please comment on list. --- From Ruediger.Geib@telekom.de Tue Dec 17 23:55:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602021AE0E3 for ; Tue, 17 Dec 2013 23:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGMOjL8hjwTG for ; Tue, 17 Dec 2013 23:55:28 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 842071ADFBF for ; Tue, 17 Dec 2013 23:55:27 -0800 (PST) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 18 Dec 2013 08:55:25 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 18 Dec 2013 08:55:24 +0100 From: To: Date: Wed, 18 Dec 2013 08:55:23 +0100 Thread-Topic: comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: Ac76a2kWIsSUsIJDTGS7lPj99Sf0pABVa2jg Message-ID: References: <52AF0E7B.6030400@erg.abdn.ac.uk> In-Reply-To: <52AF0E7B.6030400@erg.abdn.ac.uk> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 07:55:30 -0000 Hi Gorry, my small contribution to discuss the TSVWG input: draft dhesikan -03 is a rather short document. It is now focused on IP DSCP= markings suggested for RTCweb traffic. I appreciate that the 3GPP QCI rela= ted discussion has been removed. The authors of draft dhesikan prefer to support a wide set of DSCPs and sug= gest to support different levels of priority. The introduction seems to say= , it is largely considered to be applied within LANs, for home gateway inte= rnal classification and for Wifi. That's fine with me. In the case of traffic sent to a network provider broadband access router /= network gateway, I doubt that too many markings make sense. I'd expect the= network provider routers or gateways not to trust DiffServ markings sent b= y a consumer device. The draft doesn't mention that. Adding such a note may= be useful.=20 As I'm known for simplistic approaches, my take is to mark traffic sent by = a home gateway to a provider policy point by two DSCPs only, Best Effort an= d an AF PHB. I agree however with the authors, that a Home Gateway could an= d should internally apply a much more fine grained QoS differentiation for = upstream traffic. If all home network devices apply proper markings as sugg= ested by the authors, this may help. If there's interest to approach the 3GPP community for a discussion on a us= eful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. This sho= uld be documented in a separate draft, as I'd expect this inter SDO work to= consume a fair amount of time. Regards and seasonal greetings, Ruediger From gorry@erg.abdn.ac.uk Wed Dec 18 00:55:15 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842E81AE320; Wed, 18 Dec 2013 00:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oUZlpm_hcER; Wed, 18 Dec 2013 00:55:14 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20B1AE31F; Wed, 18 Dec 2013 00:55:14 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2D21D2B44B3; Wed, 18 Dec 2013 08:55:12 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 18 Dec 2013 08:55:12 -0000 Message-ID: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> Date: Wed, 18 Dec 2013 08:55:12 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 08:55:15 -0000 The IETF tsvwg has started to consider the adoption of draft-yong-tsvwg-gre-in-udp-encap to be developed into a Proposed Standard within the tsvwg on 5th November. There was initial supporting feedback from people attending the IETF-88 TSVWG meeting. We are now asking for any additional comments/feedback prior to confirming this call. The call will close on 31st December 2013. Gorry, James and David. (TSVWG Chairs) From gorry@erg.abdn.ac.uk Wed Dec 18 03:28:13 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6130B1AE392 for ; Wed, 18 Dec 2013 03:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKRK4t6nTy4l for ; Wed, 18 Dec 2013 03:28:11 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8D1AE363 for ; Wed, 18 Dec 2013 03:28:10 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C1B432B44B3; Wed, 18 Dec 2013 11:28:08 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 18 Dec 2013 11:28:08 -0000 Message-ID: In-Reply-To: References: <52AF0E7B.6030400@erg.abdn.ac.uk> Date: Wed, 18 Dec 2013 11:28:08 -0000 From: gorry@erg.abdn.ac.uk To: Ruediger.Geib@telekom.de User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 11:28:13 -0000 See a few thoughts in-line (with no chair-hat): > Hi Gorry, > > my small contribution to discuss the TSVWG input: > > draft dhesikan -03 is a rather short document. It is now focused on IP > DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP QCI > related discussion has been removed. > > The authors of draft dhesikan prefer to support a wide set of DSCPs and > suggest to support different levels of priority. The introduction seems to > say, it is largely considered to be applied within LANs, for home gateway > internal classification and for Wifi. That's fine with me. > > In the case of traffic sent to a network provider broadband access router > / network gateway, I doubt that too many markings make sense. I'd expect > the network provider routers or gateways not to trust DiffServ markings > sent by a consumer device. The draft doesn't mention that. Adding such a > note may be useful. > Personally I'd agree - it would be useful to describe this context > As I'm known for simplistic approaches, my take is to mark traffic sent by > a home gateway to a provider policy point by two DSCPs only, Best Effort > and an AF PHB. I agree however with the authors, that a Home Gateway could > and should internally apply a much more fine grained QoS differentiation > for upstream traffic. If all home network devices apply proper markings as > suggested by the authors, this may help. > I think it would be useful to say that each DSCP by a single app require a way for the app or transport to know which work appropriately along that path. Especially when traffic is dynamically moved between different PHB groups. The fact that many deployed networks support a small set of DSCPs is worth I think a mention. To me this has some implications, e.g. when the App sets EF or CS1 and networks supports just AF and BE - intended precedence would then rely upon correct treatment or re-marking. If this were not appropriate, then the loss will depend upon whether it was before or after the DSCPs were interpreted as intended. > If there's interest to approach the 3GPP community for a discussion on a > useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. This > should be documented in a separate draft, as I'd expect this inter SDO > work to consume a fair amount of time. > > Regards and seasonal greetings, > > Ruediger > > > Gorry From lucy.yong@huawei.com Wed Dec 18 06:56:55 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8321C1AE400 for ; Wed, 18 Dec 2013 06:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94Lk0nhozNAG for ; Wed, 18 Dec 2013 06:56:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 381FB1AE3FD for ; Wed, 18 Dec 2013 06:56:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBO40203; Wed, 18 Dec 2013 14:56:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 14:56:08 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 14:56:39 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 06:56:33 -0800 From: Lucy yong To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO+87od2qsr446REG4lrsIkVc8OJpaC7mA Date: Wed, 18 Dec 2013 14:56:33 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453060A3@dfweml509-mbx.china.huawei.com> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 14:56:55 -0000 Support as one of editors. Lucy -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of gorry@erg.abdn.ac.= uk Sent: Wednesday, December 18, 2013 2:55 AM To: tsvwg@ietf.org Subject: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-u= dp-encap The IETF tsvwg has started to consider the adoption of draft-yong-tsvwg-gre= -in-udp-encap to be developed into a Proposed Standard within the tsvwg on = 5th November. There was initial supporting feedback from people attending = the IETF-88 TSVWG meeting. We are now asking for any additional comments/feedback prior to confirming = this call. The call will close on 31st December 2013. Gorry, James and David. (TSVWG Chairs) From lars@netapp.com Wed Dec 18 10:32:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186E41ADF83 for ; Wed, 18 Dec 2013 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.44 X-Spam-Level: X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYChVwm1KvIn for ; Wed, 18 Dec 2013 10:32:39 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C2F431ADF99 for ; Wed, 18 Dec 2013 10:32:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,508,1384329600"; d="asc'?scan'208";a="130374400" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 18 Dec 2013 10:32:38 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 10:32:38 -0800 From: "Eggert, Lars" To: Gorry Fairhust Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO+87k8APwrmdcTEeL/7KZiwWVIJpazYuA Date: Wed, 18 Dec 2013 18:32:37 +0000 Message-ID: References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: multipart/signed; boundary="Apple-Mail=_D8DF0F06-2E6C-41B2-B6EA-0735D7C2FFCE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 18:32:42 -0000 --Apple-Mail=_D8DF0F06-2E6C-41B2-B6EA-0735D7C2FFCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I would like to see the draft discuss how it addresses the issues raised = in RFC5405, before I'd be comfortable in stating a position. Lars --Apple-Mail=_D8DF0F06-2E6C-41B2-B6EA-0735D7C2FFCE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUrHqRdZcnpRveo1xAQLAEAQAiFI58Ce96BkAJlqGcFee8UEtwwXc7Uv1 5J9JAWzV5dW+9VY/54H8RarGjyDuFfGzVUKo4FHhHz9ZtlR6kw1zxM+zxDnxEgEG IAOWxSttZw14zYtPg2T0asASVlwmed8X+fKRTDbf1od/WiyVhzwL2qna0YXbslyK ZTh/RDQz4o4= =85uA -----END PGP SIGNATURE----- --Apple-Mail=_D8DF0F06-2E6C-41B2-B6EA-0735D7C2FFCE-- From lucy.yong@huawei.com Wed Dec 18 11:22:55 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70511AE026 for ; Wed, 18 Dec 2013 11:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRrvvqk-X80f for ; Wed, 18 Dec 2013 11:22:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2B271AE000 for ; Wed, 18 Dec 2013 11:22:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBO56738; Wed, 18 Dec 2013 19:22:50 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 19:22:21 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 19:22:49 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 11:22:48 -0800 From: Lucy yong To: "Eggert, Lars" , Gorry Fairhust Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO+87kx417Y5g9ekGGal3JiCPEappazYuA//+GTJA= Date: Wed, 18 Dec 2013 19:22:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 19:22:55 -0000 Hi Lars, I assume that you mean the MTU issue motioned in RFC5405. Section 4 in the = draft describes the tunnel ingress must perform fragmentation on the packet= before encapsulation. GTP-in-UDP encapsulation introduces additional 8 byt= es beyond GRE header. Thus MTU size parameter set by operator MUST fact thi= s in.=20 If this is not your point, please clarify it. Regards, Lucy -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: Wednesday, December 18, 2013 12:33 PM To: Gorry Fairhust Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-= in-udp-encap I would like to see the draft discuss how it addresses the issues raised in= RFC5405, before I'd be comfortable in stating a position. Lars From david.black@emc.com Wed Dec 18 16:17:18 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0641AC404 for ; Wed, 18 Dec 2013 16:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXHzlcINFFac for ; Wed, 18 Dec 2013 16:17:13 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A8CC71A82E2 for ; Wed, 18 Dec 2013 16:17:12 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBJ0H9oR016823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Dec 2013 19:17:10 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com rBJ0H9oR016823 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1387412230; bh=ga2ECP2+gAMnJz/8mlWqMqmgG2I=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oUHZGEIrV4z8ki7Tjo376tRQhXUIPP0IXQjBkD6qUtGtwrNZzZtoAmGRGEC3p7ns7 vZeRTIfjf1HAiJO+kdoBAG46va+Bdt0zgq3h6qyiokgBx8LskbwXCYJeBnVYfWgZHZ kjB2170bfawCZ9gxCqI4NvDh/t3hAwMNkzxUQEU4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com rBJ0H9oR016823 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor); Wed, 18 Dec 2013 16:16:48 -0800 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBJ0GluN012827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 19:16:47 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Wed, 18 Dec 2013 19:16:47 -0500 From: "Black, David" To: "Eggert, Lars" Date: Wed, 18 Dec 2013 19:16:46 -0500 Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO+87kx417Y5g9ekGGal3JiCPEappazYuA//+GTJCAAFA+kA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 00:17:18 -0000 Lars, This probably needs a longer discussion, as RFC 5405 is not straightforward= to address in this draft because GRE is not the "Application" as that term is used in = the title of RFC 5405. The "Application" is running above GRE, and if GRE were as widel= y deployed and/or used/usable as UDP, RFC 5405 could (in that hypothetical universe) h= ave been addressed to both UDP and GRE. In particular, there is probably not much that can be said about congestion= control, as that functionality and/or concerns (e.g., about its absence) are above G= RE in the stack. I'll echo Lucy's question - what specific aspects of RFC 5405 concern you? FWIW, as an individual, I support adoption of this draft, as I think it hel= ps deal with protocols whose preferred encapsulation is GRE when running them over infrastructure that is more UDP- friendly than GRE-friendly (e.g., in its E= CMP and/or LAG support). Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Lucy yong > Sent: Wednesday, December 18, 2013 2:23 PM > To: Eggert, Lars; Gorry Fairhust > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gr= e-in- > udp-encap >=20 > Hi Lars, >=20 > I assume that you mean the MTU issue motioned in RFC5405. Section 4 in th= e > draft describes the tunnel ingress must perform fragmentation on the pack= et > before encapsulation. GTP-in-UDP encapsulation introduces additional 8 by= tes > beyond GRE header. Thus MTU size parameter set by operator MUST fact this= in. >=20 > If this is not your point, please clarify it. >=20 > Regards, > Lucy >=20 >=20 >=20 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Eggert, Lars > Sent: Wednesday, December 18, 2013 12:33 PM > To: Gorry Fairhust > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gr= e-in- > udp-encap >=20 > I would like to see the draft discuss how it addresses the issues raised = in > RFC5405, before I'd be comfortable in stating a position. >=20 > Lars From an.p.nguyen@HQ.DHS.GOV Wed Dec 18 10:10:03 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D3A1AE037 for ; Wed, 18 Dec 2013 10:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3AO8B6Hi6c7 for ; Wed, 18 Dec 2013 10:10:01 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 248B51AE006 for ; Wed, 18 Dec 2013 10:10:00 -0800 (PST) Received: from mail163-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Dec 2013 18:09:59 +0000 Received: from mail163-ch1 (localhost [127.0.0.1]) by mail163-ch1-R.bigfish.com (Postfix) with ESMTP id 2BF57C050E; Wed, 18 Dec 2013 18:09:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:216.81.82.139; KIP:(null); UIP:(null); IPV:NLI; H:D2IBLPRHQ102.dhs.gov; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I542I1432I1521Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h1155h) Received: from mail163-ch1 (localhost.localdomain [127.0.0.1]) by mail163-ch1 (MessageSwitch) id 1387390197839032_23720; Wed, 18 Dec 2013 18:09:57 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail163-ch1.bigfish.com (Postfix) with ESMTP id C7EC160047; Wed, 18 Dec 2013 18:09:57 +0000 (UTC) Received: from D2IBLPRHQ102.dhs.gov (216.81.82.139) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Dec 2013 18:09:57 +0000 Received: from D2IBLPRHQ104.dhs.gov (192.168.49.134) by D2IBLPRHQ102.dhs.gov (10.82.0.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 18 Dec 2013 13:09:59 -0500 Received: from D2ABLPRHQ103.DSA.DHS (10.237.115.14) by D2IBLPRHQ104.dhs.gov (10.82.4.51) with Microsoft SMTP Server (TLS) id 14.2.347.0; Wed, 18 Dec 2013 13:09:44 -0500 Received: from D2ASEPREA008.DSA.DHS ([169.254.12.98]) by D2ABLPRHQ103.DSA.DHS ([fe80::15d4:e9b9:8b5:7449%10]) with mapi id 14.02.0347.000; Wed, 18 Dec 2013 13:09:56 -0500 From: "Nguyen, An P" To: "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aNTdoIGQdO+0qxJmFzPP6P75paJLgAgAAYlqA= Date: Wed, 18 Dec 2013 18:09:55 +0000 Message-ID: References: <52AF0E7B.6030400@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.235.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hq.dhs.gov X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Thu, 19 Dec 2013 02:00:58 -0800 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 18:11:48 -0000 James, After I quickly scanned through Section 5 - DSCP Mappings of the draft-dhes= ikan-tsvwg-rtcweb-qos03, I have a question for you: I wonder if this section could be expanded to include RFC 5856 - A Differe= ntiated Services Code Point (DSCP) for Capacity-Admitted Traffic? Respectfully yours, An Nguyen DHS/OEC ( Formerly known as NCS) =20 -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of gorry@erg.abdn.ac.= uk Sent: Wednesday, December 18, 2013 6:28 AM To: Ruediger.Geib@telekom.de Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos See a few thoughts in-line (with no chair-hat): > Hi Gorry, > > my small contribution to discuss the TSVWG input: > > draft dhesikan -03 is a rather short document. It is now focused on IP=20 > DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP=20 > QCI related discussion has been removed. > > The authors of draft dhesikan prefer to support a wide set of DSCPs=20 > and suggest to support different levels of priority. The introduction=20 > seems to say, it is largely considered to be applied within LANs, for=20 > home gateway internal classification and for Wifi. That's fine with me. > > In the case of traffic sent to a network provider broadband access=20 > router / network gateway, I doubt that too many markings make sense.=20 > I'd expect the network provider routers or gateways not to trust=20 > DiffServ markings sent by a consumer device. The draft doesn't mention=20 > that. Adding such a note may be useful. > Personally I'd agree - it would be useful to describe this context > As I'm known for simplistic approaches, my take is to mark traffic=20 > sent by a home gateway to a provider policy point by two DSCPs only,=20 > Best Effort and an AF PHB. I agree however with the authors, that a=20 > Home Gateway could and should internally apply a much more fine=20 > grained QoS differentiation for upstream traffic. If all home network=20 > devices apply proper markings as suggested by the authors, this may help. > I think it would be useful to say that each DSCP by a single app require a = way for the app or transport to know which work appropriately along that pa= th. Especially when traffic is dynamically moved between different PHB grou= ps. The fact that many deployed networks support a small set of DSCPs is worth = I think a mention. To me this has some implications, e.g. when the App sets= EF or CS1 and networks supports just AF and BE - intended precedence would= then rely upon correct treatment or re-marking. If this were not appropria= te, then the loss will depend upon whether it was before or after the DSCPs= were interpreted as intended. > If there's interest to approach the 3GPP community for a discussion on=20 > a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help.=20 > This should be documented in a separate draft, as I'd expect this=20 > inter SDO work to consume a fair amount of time. > > Regards and seasonal greetings, > > Ruediger > > > Gorry From lars@netapp.com Thu Dec 19 04:42:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615631A1F62 for ; Thu, 19 Dec 2013 04:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.44 X-Spam-Level: X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKWxzWkr6nBU for ; Thu, 19 Dec 2013 04:42:40 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 07FDB1A1F33 for ; Thu, 19 Dec 2013 04:42:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,512,1384329600"; d="asc'?scan'208";a="130697534" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 19 Dec 2013 04:42:38 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 04:42:37 -0800 From: "Eggert, Lars" To: "Black, David" Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO/E+udeAZzQlalEKGbUyzKUd0wZpb/REA Date: Thu, 19 Dec 2013 12:42:37 +0000 Message-ID: References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_85F16D22-45AC-43D6-8424-3AE613285431"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 12:42:41 -0000 --Apple-Mail=_85F16D22-45AC-43D6-8424-3AE613285431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2013-12-19, at 1:16, Black, David wrote: > This probably needs a longer discussion, as RFC 5405 is not = straightforward to address > in this draft because GRE is not the "Application" as that term is = used in the title of > RFC 5405. The "Application" is running above GRE, and if GRE were as = widely deployed > and/or used/usable as UDP, RFC 5405 could (in that hypothetical = universe) have > been addressed to both UDP and GRE. >=20 > In particular, there is probably not much that can be said about = congestion control, > as that functionality and/or concerns (e.g., about its absence) are = above GRE in the > stack. let me expand a bit. GRE can carry pretty much any traffic that has an EtherType, including = congestion-controlled and non-congestion-controlled traffic. At the moment, because GRE is carried directly in IP, it's pretty much = limited to paths without middleboxes. That excludes most consumer = Internet connections. When encapsulated inside UDP, it can traverse those paths.=20 The issue I see - and I'm not saying it's a showstopper or anything, but = it requires discussion - is that UDP-encapsulated-GRE can make = non-congestion-controlled traffic appear in regions in the network where = it currently doesn't go as easily. This is what Section 3.1.3 in RFC5405 is about. > I'll echo Lucy's question - what specific aspects of RFC 5405 concern = you? See above. And thanks, Lucy, for pointing me a the MTU discussion. By the way, you probably also need to say a bit more about why a zero = UDP checksum is OK here, simply pointing at the RFCs is not enough. = There needs to be some machinery present in the encapsulation to make = that use OK, IIRC. Lars --Apple-Mail=_85F16D22-45AC-43D6-8424-3AE613285431 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUrLputZcnpRveo1xAQLrCQP+KvmRPyg8NLiVoIrjQ5nXIMrU+o1pqXFu luyEn6i2MQogle6+TBMQpJY5xZbH27vF1Hyxv5VdcL0aBFDcv50Mraz0O7RrgCxv wlh8xL3G1g7btQL9Alt6tDUBnRrEMdnVxsm/ZHNmsILSB0m5vYjH4e1MIIXteVS8 wzw8he/8Wms= =Q/qm -----END PGP SIGNATURE----- --Apple-Mail=_85F16D22-45AC-43D6-8424-3AE613285431-- From sdhesika@cisco.com Thu Dec 19 09:27:56 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F0E1AE1FF for ; Thu, 19 Dec 2013 09:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR2y8bCnl5dx for ; Thu, 19 Dec 2013 09:27:54 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9B1AE1EC for ; Thu, 19 Dec 2013 09:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3396; q=dns/txt; s=iport; t=1387474072; x=1388683672; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2q1no97+Kxe2CsmBEgX1lra4UYUHQm6XrEEXFfSIJQE=; b=LKB/kXCYTQ8QyG0MmUgQq+XtXCHQ7vn4Baa94NHuhvzc/ty+U0il6kKK qRNhm1pFDIHhgoUWME7+uyhjeBNiUj+2SlwvVeEpWT7Y2dS24rdrKo+Km OTRq6pmoUMgtdm7O+uSL9r9lf9dTh4LpaNx6/cwUtSCserz4Y+LbOUeXV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJ8rs1KtJXHB/2dsb2JhbABZDoJ9gQ25LIEXFnSCJQEBAQMBOjgHBQcEAgEIEQQBAQsUCQcyFAkIAgQBDQUIDIdoBwHLBReOYTEHBoMdgRMEqiqCbD+CKg X-IronPort-AV: E=Sophos;i="4.95,513,1384300800"; d="scan'208";a="7958526" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 19 Dec 2013 17:27:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBJHRqXD015520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 17:27:52 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.125]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 11:27:51 -0600 From: "Subha Dhesikan (sdhesika)" To: "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aJErlBSAcWG0ODmxKj8FJpKppaNXsAgAGQV8A= Date: Thu, 19 Dec 2013 17:27:51 +0000 Message-ID: References: <52AF0E7B.6030400@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:27:56 -0000 Thank you for your comments, Ruediger and Gorry. Inline as SD: -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of gorry@erg.abdn.ac.= uk Sent: Wednesday, December 18, 2013 3:28 AM To: Ruediger.Geib@telekom.de Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos See a few thoughts in-line (with no chair-hat): > Hi Gorry, > > my small contribution to discuss the TSVWG input: > > draft dhesikan -03 is a rather short document. It is now focused on IP=20 > DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP=20 > QCI related discussion has been removed. > > The authors of draft dhesikan prefer to support a wide set of DSCPs=20 > and suggest to support different levels of priority. The introduction=20 > seems to say, it is largely considered to be applied within LANs, for=20 > home gateway internal classification and for Wifi. That's fine with me. > > In the case of traffic sent to a network provider broadband access=20 > router / network gateway, I doubt that too many markings make sense.=20 > I'd expect the network provider routers or gateways not to trust=20 > DiffServ markings sent by a consumer device. The draft doesn't mention=20 > that. Adding such a note may be useful. > Personally I'd agree - it would be useful to describe this context SD: Sounds good. I will add a statement or two on lack of trust of client = devices and the effect on DSCP marking.=20 In addition, I am expecting there will be some work done on the authorizati= on mechanisms for webrtc traffic that will allow some off-path authorizatio= n of DSCP for particular flows. > As I'm known for simplistic approaches, my take is to mark traffic=20 > sent by a home gateway to a provider policy point by two DSCPs only,=20 > Best Effort and an AF PHB. I agree however with the authors, that a=20 > Home Gateway could and should internally apply a much more fine=20 > grained QoS differentiation for upstream traffic. If all home network=20 > devices apply proper markings as suggested by the authors, this may help. > I think it would be useful to say that each DSCP by a single app require a = way for the app or transport to know which work appropriately along that pa= th. Especially when traffic is dynamically moved between different PHB grou= ps. The fact that many deployed networks support a small set of DSCPs is worth = I think a mention. To me this has some implications, e.g. when the App sets= EF or CS1 and networks supports just AF and BE - intended precedence would= then rely upon correct treatment or re-marking. If this were not appropria= te, then the loss will depend upon whether it was before or after the DSCPs= were interpreted as intended. SD: ack. Yes, it is possible to add an example or two on how the DSCPs defi= ned in this document can be treated in a network that has only 2-4 PHBs. > If there's interest to approach the 3GPP community for a discussion on=20 > a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help.=20 > This should be documented in a separate draft, as I'd expect this=20 > inter SDO work to consume a fair amount of time. SD: I will also participate as needed.=20 Regards, Subha > > Regards and seasonal greetings, > > Ruediger > > > Gorry From sdhesika@cisco.com Thu Dec 19 09:34:28 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3838A1AC4A7 for ; Thu, 19 Dec 2013 09:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKyZ7qR1PklO for ; Thu, 19 Dec 2013 09:34:25 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B78C21ADE71 for ; Thu, 19 Dec 2013 09:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4132; q=dns/txt; s=iport; t=1387474464; x=1388684064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wP6TUpNu7P+TOiLFoqxYWnmLUuJ9fq6C5sHcG3YurtQ=; b=fU2yEtZOAuOnwByZSFsXzD5FI1huTrbSnwno0dqpZHbGBGp5g+v55ZwY VPDyzvlcK7EbM5cPGCIqpRPTBHe8Dvk01Gftt0D/8Xt8vUMBRoq1VB9HZ St6FjwHHjnbg8kz4UjIZZhj/ZjK85s40objm5XJCNtZn9kqvkx9nG28j7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACMts1KtJV2d/2dsb2JhbABZDoJ9gQ25LIEXFnSCJQEBAQMBOjgHBQcEAgEIEQQBAQsUCQcyFAkIAgQBDQUIDIdoBwHLAReOYTEHBoMdgRMEqiqCbD+CKg X-IronPort-AV: E=Sophos;i="4.95,513,1384300800"; d="scan'208";a="292678689" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 19 Dec 2013 17:34:23 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBJHYNSs004843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 17:34:23 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.125]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 11:34:23 -0600 From: "Subha Dhesikan (sdhesika)" To: "Nguyen, An P" , "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" Thread-Topic: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos Thread-Index: AQHO+8aJErlBSAcWG0ODmxKj8FJpKppaNXsAgABwQoCAASIF8A== Date: Thu, 19 Dec 2013 17:34:22 +0000 Message-ID: References: <52AF0E7B.6030400@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:34:28 -0000 Thanks An Nguyen. I am sure James will share his thoughts but here is what = my thoughts were when I prepared the document: I did deliberate on whether the high priority category of the voice traffic= should be left aside for admitted EF. I decided against it eventually bec= ause admitted-EF brings with it the requirements of admission control. Si= nce there is no admission control mechanisms or discussions in this draft, = it led to my decision to leave it out. I believe we can discuss further on the use cases for admitted traffic in w= ebRTC and if needed, introduce the conditions and marking of traffic with a= dmitted EF to a separate document. Regards, Subha -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Nguyen, An P Sent: Wednesday, December 18, 2013 10:10 AM To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de Cc: tsvwg@ietf.org Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos James, After I quickly scanned through Section 5 - DSCP Mappings of the draft-dhes= ikan-tsvwg-rtcweb-qos03, I have a question for you: I wonder if this section could be expanded to include RFC 5856 - A Differe= ntiated Services Code Point (DSCP) for Capacity-Admitted Traffic? Respectfully yours, An Nguyen DHS/OEC ( Formerly known as NCS) =20 -----Original Message----- From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of gorry@erg.abdn.ac.= uk Sent: Wednesday, December 18, 2013 6:28 AM To: Ruediger.Geib@telekom.de Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos See a few thoughts in-line (with no chair-hat): > Hi Gorry, > > my small contribution to discuss the TSVWG input: > > draft dhesikan -03 is a rather short document. It is now focused on IP=20 > DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP=20 > QCI related discussion has been removed. > > The authors of draft dhesikan prefer to support a wide set of DSCPs=20 > and suggest to support different levels of priority. The introduction=20 > seems to say, it is largely considered to be applied within LANs, for=20 > home gateway internal classification and for Wifi. That's fine with me. > > In the case of traffic sent to a network provider broadband access=20 > router / network gateway, I doubt that too many markings make sense. > I'd expect the network provider routers or gateways not to trust=20 > DiffServ markings sent by a consumer device. The draft doesn't mention=20 > that. Adding such a note may be useful. > Personally I'd agree - it would be useful to describe this context > As I'm known for simplistic approaches, my take is to mark traffic=20 > sent by a home gateway to a provider policy point by two DSCPs only,=20 > Best Effort and an AF PHB. I agree however with the authors, that a=20 > Home Gateway could and should internally apply a much more fine=20 > grained QoS differentiation for upstream traffic. If all home network=20 > devices apply proper markings as suggested by the authors, this may help. > I think it would be useful to say that each DSCP by a single app require a = way for the app or transport to know which work appropriately along that pa= th. Especially when traffic is dynamically moved between different PHB grou= ps. The fact that many deployed networks support a small set of DSCPs is worth = I think a mention. To me this has some implications, e.g. when the App sets= EF or CS1 and networks supports just AF and BE - intended precedence would= then rely upon correct treatment or re-marking. If this were not appropria= te, then the loss will depend upon whether it was before or after the DSCPs= were interpreted as intended. > If there's interest to approach the 3GPP community for a discussion on=20 > a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help. > This should be documented in a separate draft, as I'd expect this=20 > inter SDO work to consume a fair amount of time. > > Regards and seasonal greetings, > > Ruediger > > > Gorry From lucy.yong@huawei.com Thu Dec 19 17:06:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672CD1AEE6D for ; Thu, 19 Dec 2013 17:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a68k2ACFSFG for ; Thu, 19 Dec 2013 17:06:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF7131AEE69 for ; Thu, 19 Dec 2013 17:06:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZE69078; Fri, 20 Dec 2013 01:06:42 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 01:06:07 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 01:06:39 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Thu, 19 Dec 2013 17:06:36 -0800 From: Lucy yong To: "Eggert, Lars" , "Black, David" Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO/E+zW6XmX/PkrE2mFRjd/VtMYppb/RSA//+bbEA= Date: Fri, 20 Dec 2013 01:06:35 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 01:06:48 -0000 Hi Lars, Thank you for the suggestion. I agree that the draft should add some clarif= ications on these issues described in RFC5405. Will the following be accept= able statements for each issue? If not, like to hear your concern or sugges= tion. Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechanism= does not use or rely on UDP transport layer functions except demultiplexin= g. The UDP header just provides the fields for GRE payload indication and f= low entropy. Thus it is not a regular UDP application built on the top of U= DP transport layer and relying on the UDP layer to provide some transport f= unctions. However it is useful to document the issues raised in RFC5405 aga= inst GRE-in-UDP.=20 Congestion Control Guidelines: GRE-in-UDP encapsulation does not provid= e any congestion control mechanism. Whether an application encapsulated by = GRE-in-UDP should employ a congestion control mechanism or not, please refe= r to the congestion control guideline described in RFC5405. Message Size Guidelines: (This is already addressed in section 4 of the= draft). Reliability Guidelines: Not apply. GRE-in-UDP provides the same reliabi= lity and integrity as of GRE encapsulation. In order words, no need additio= nal mechanism when using GRE-in-UDP instead of GRE.=20 Checksum Guidelines: Since GRE already has the checksum function, GRE-i= n-UDP does not need to use the UDP checksum. For simplifying the process, U= DP checksum should be set to zero. Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a standar= d UDP port number [TBD] to indicate GRE payload. This port number MUST not = be used by any middlebox or an application for other purpose. This will ens= ure the consistent behavior along the path when the application is encapsul= ated by GRE or GRE-in-UDP. Programming Guidelines: Not apply. The applicability of GRE-in-UDP is t= o the GRE encapsulated network protocols that generate a high traffic volum= e. =20 ICMP Guidelines: add text in section 7.1.: If tunnel end point uses ICM= P to inform no GRE-in-UDP support, peer end point needs additional validati= on checking. The validation process should follow the guideline described i= n RFC5405. (does this address Gorry's comment?) Security Considerations: like to hear if we should use DTLS in the envi= ronment that the security is a concern. Regards, Lucy From lars@netapp.com Fri Dec 20 00:37:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96B21AC441 for ; Fri, 20 Dec 2013 00:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.44 X-Spam-Level: X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSZptP56C-6J for ; Fri, 20 Dec 2013 00:37:40 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id F24021A16F0 for ; Fri, 20 Dec 2013 00:37:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,519,1384329600"; d="asc'?scan'208";a="62867738" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx2-out.netapp.com with ESMTP; 20 Dec 2013 00:37:38 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Fri, 20 Dec 2013 00:37:38 -0800 From: "Eggert, Lars" To: Lucy yong Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO/R/HNG3zYzsZBEWAk8RBp3UfTJpdSUoA Date: Fri, 20 Dec 2013 08:37:36 +0000 Message-ID: <0348D31A-5B3B-415D-88D3-E0574525CD44@netapp.com> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_A67A64F2-317C-4DFC-BE65-C418C3B06E88"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 08:37:41 -0000 --Apple-Mail=_A67A64F2-317C-4DFC-BE65-C418C3B06E88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2013-12-20, at 2:06, Lucy yong wrote: > Although GRE-in-UDP encapsulation uses the UDP header, the tunnel = mechanism does not use or rely on UDP transport layer functions except = demultiplexing. The UDP header just provides the fields for GRE payload = indication and flow entropy. Thus it is not a regular UDP application = built on the top of UDP transport layer and relying on the UDP layer to = provide some transport functions. However it is useful to document the = issues raised in RFC5405 against GRE-in-UDP.=20 I disagree with this view. UDP as protocol doesn't provide anything = other than demultiplexing to begin with. That's why we did a BCP on what = mechanisms an application or tunnel that uses UDP on the Internet needs = to possibly implement. Your GRE-in-UDP tunnel is a user of UDP just as = any other application or protocol that uses UDP. It's not special. > Congestion Control Guidelines: GRE-in-UDP encapsulation does not = provide any congestion control mechanism. Whether an application = encapsulated by GRE-in-UDP should employ a congestion control mechanism = or not, please refer to the congestion control guideline described in = RFC5405. It's not enough to refer to RFC5405. RFC5405 actually recommends some = mechanisms that the tunnel should employ. In your case, where you don't = know whether the payload is congestion-controlled, the recommendation = is: 2. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled. This can be the case, for example, when some link-layer protocols are encapsulated within UDP (but not all link-layer protocols; some are congestion-controlled). Because it is not known that congestion losses of tunneled non-IP traffic will trigger an appropriate congestion response at the senders, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Because tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines in Section 3.1.1 apply. > Message Size Guidelines: (This is already addressed in section 4 of = the draft). >=20 > Reliability Guidelines: Not apply. GRE-in-UDP provides the same = reliability and integrity as of GRE encapsulation. In order words, no = need additional mechanism when using GRE-in-UDP instead of GRE.=20 >=20 > Checksum Guidelines: Since GRE already has the checksum function, = GRE-in-UDP does not need to use the UDP checksum. For simplifying the = process, UDP checksum should be set to zero. >=20 > Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a = standard UDP port number [TBD] to indicate GRE payload. This port number = MUST not be used by any middlebox or an application for other purpose. = This will ensure the consistent behavior along the path when the = application is encapsulated by GRE or GRE-in-UDP. >=20 > Programming Guidelines: Not apply. The applicability of GRE-in-UDP = is to the GRE encapsulated network protocols that generate a high = traffic volume. >=20 > ICMP Guidelines: add text in section 7.1.: If tunnel end point uses = ICMP to inform no GRE-in-UDP support, peer end point needs additional = validation checking. The validation process should follow the guideline = described in RFC5405. (does this address Gorry's comment?) >=20 > Security Considerations: like to hear if we should use DTLS in the = environment that the security is a concern. It would be good to see the discussion on the points above in the ID. Lars --Apple-Mail=_A67A64F2-317C-4DFC-BE65-C418C3B06E88 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUrQByNZcnpRveo1xAQLVyAQAjoSM8llcV+XplX9aSKtyKLDszjZwth8W yTFRQDdGzxtD7bKkGK6SzpRTs3YPO1Z7UIV+GRIIU2hNclILJSU5FC66D2esSfyV gOZZLKtBzlLyGbqa3dCazVfA+8DDrtoawHLWIINsUuMYlkA2j7IwlBiuzBNoeA8K nTihnB/F280= =FFZh -----END PGP SIGNATURE----- --Apple-Mail=_A67A64F2-317C-4DFC-BE65-C418C3B06E88-- From magnus.westerlund@ericsson.com Fri Dec 20 00:47:07 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568691ADF93; Fri, 20 Dec 2013 00:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPqWYNUB_ZJd; Fri, 20 Dec 2013 00:47:06 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6881AD8E2; Fri, 20 Dec 2013 00:47:05 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-6d-52b40406f755 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1F.4B.23787.60404B25; Fri, 20 Dec 2013 09:47:02 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.347.0; Fri, 20 Dec 2013 09:46:44 +0100 Message-ID: <52B40406.6040903@ericsson.com> Date: Fri, 20 Dec 2013 09:47:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tsvwg X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIJMWRmVeSWpSXmKPExsUyM+JvrS4by5Yggx+nLSzW/mtntzj25i6b A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyrqzqZiy4xV5x78dS9gbGDWxdjJwcEgImEovPPWeB sMUkLtxbDxTn4hASOMQosbH7J1iRkMByRolJCyW6GDk4eAW0Jd632YCEWQRUJf5OPAvWyyZg IXHzRyNYuahAsMStaQ/YQWxeAUGJkzOfgNWICEhJXHuwlxHEZhZQl7iz+BxYjbCAr8TRPRcY QcZLCIhL9DQGQZToSUy52gJVLi/RvHU2M8Q12hINTR2sExgFZiHZMAtJyywkLQsYmVcxsucm ZuaklxtuYgQG28Etv3V3MJ46J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjHKPG+NKomazf7jmvEKNMfSWzHbOQx8U7KX8+C+ftWzc+YqtZnNL7r6ES/eyVI9nOK4y 0DUqzfzcckpuxu+LNvfyflkc5ApZnbtItyJ63bWjt40WNKurlyqndp2LU9GyVYg4tI7je8Ee u8Zti8wljid9D3OYu186s+Jsm5P2Ws/yhbV+RfonlFiKMxINtZiLihMBvkgbegQCAAA= Cc: "rtcweb@ietf.org" Subject: [tsvwg] Request that TSVWG adopts draft-dhesikan-tsvwg-rtcweb-qos as WG item X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 08:47:07 -0000 TSVWG, This is a request that TSVWG adopts draft-dhesikan-tsvwg-rtcweb-qos as a WG item. There are significant interest in RTCWEB to have a document that documents what the possibilities are for Diffserv markings of traffic flows like RTCWEB data and media traffic. I strongly encourage the RTCWEB WG participants to engage in this work and jointly work with TSVWG participants and the document authors to resolve issues, raise and answer questions around this work. Merry Christmas Magnus Westerlund (As RTCWEB WG chair) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lucy.yong@huawei.com Fri Dec 20 07:33:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90E1ADF82 for ; Fri, 20 Dec 2013 07:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoW6autSclyv for ; Fri, 20 Dec 2013 07:33:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79A1ADF43 for ; Fri, 20 Dec 2013 07:33:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZF33187; Fri, 20 Dec 2013 15:33:06 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 15:32:24 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 15:33:01 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Fri, 20 Dec 2013 07:32:56 -0800 From: Lucy yong To: "Eggert, Lars" Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO/V7EWDmPZvgBrEO5onIubyqAGppdM9xA Date: Fri, 20 Dec 2013 15:32:56 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45306700@dfweml509-mbx.china.huawei.com> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> <0348D31A-5B3B-415D-88D3-E0574525CD44@netapp.com> In-Reply-To: <0348D31A-5B3B-415D-88D3-E0574525CD44@netapp.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 15:33:12 -0000 > Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechani= sm does not use or rely on UDP transport layer functions except demultiplex= ing. The UDP header just provides the fields for GRE payload indication and= flow entropy. Thus it is not a regular UDP application built on the top of= UDP transport layer and relying on the UDP layer to provide some transport= functions. However it is useful to document the issues raised in RFC5405 a= gainst GRE-in-UDP.=20 I disagree with this view. UDP as protocol doesn't provide anything other t= han demultiplexing to begin with. That's why we did a BCP on what mechanism= s an application or tunnel that uses UDP on the Internet needs to possibly = implement. Your GRE-in-UDP tunnel is a user of UDP just as any other applic= ation or protocol that uses UDP. It's not special. [Lucy] How about this: GRE-in-UDP encapsulation uses the UDP header so, fro= m UDP perspective, it is a UDP application. From tunnel encapsulation persp= ective, GRE-in-UDP does not use or rely on UDP transport layer functions ex= cept demultiplexing, i.e. the UDP header just provides the fields for GRE p= ayload indication and flow entropy. However it is useful to document the is= sued raised in RFC5405 against GRE-in-UDP. > Congestion Control Guidelines: GRE-in-UDP encapsulation does not provi= de any congestion control mechanism. Whether an application encapsulated by= GRE-in-UDP should employ a congestion control mechanism or not, please ref= er to the congestion control guideline described in RFC5405. It's not enough to refer to RFC5405. RFC5405 actually recommends some mecha= nisms that the tunnel should employ. In your case, where you don't know whe= ther the payload is congestion-controlled, the recommendation is: 2. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled. This can be the case, for example, when some link-layer protocols are encapsulated within UDP (but not all link-layer protocols; some are congestion-controlled). Because it is not known that congestion losses of tunneled non-IP traffic will trigger an appropriate congestion response at the senders, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Because tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines in Section 3.1.1 apply. [Lucy] Thanks! We will make it sufficient and refer to this specific sectio= n in RFC5405. Regards, Lucy > Message Size Guidelines: (This is already addressed in section 4 of th= e draft). >=20 > Reliability Guidelines: Not apply. GRE-in-UDP provides the same reliab= ility and integrity as of GRE encapsulation. In order words, no need additi= onal mechanism when using GRE-in-UDP instead of GRE.=20 >=20 > Checksum Guidelines: Since GRE already has the checksum function, GRE-= in-UDP does not need to use the UDP checksum. For simplifying the process, = UDP checksum should be set to zero. >=20 > Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a standa= rd UDP port number [TBD] to indicate GRE payload. This port number MUST not= be used by any middlebox or an application for other purpose. This will en= sure the consistent behavior along the path when the application is encapsu= lated by GRE or GRE-in-UDP. >=20 > Programming Guidelines: Not apply. The applicability of GRE-in-UDP is = to the GRE encapsulated network protocols that generate a high traffic volu= me. >=20 > ICMP Guidelines: add text in section 7.1.: If tunnel end point uses IC= MP to inform no GRE-in-UDP support, peer end point needs additional validat= ion checking. The validation process should follow the guideline described = in RFC5405. (does this address Gorry's comment?) >=20 > Security Considerations: like to hear if we should use DTLS in the env= ironment that the security is a concern. It would be good to see the discussion on the points above in the ID. Lars From l.wood@surrey.ac.uk Sat Dec 21 16:50:28 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDEC1AE110 for ; Sat, 21 Dec 2013 16:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60p5RR5O9b65 for ; Sat, 21 Dec 2013 16:50:24 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) by ietfa.amsl.com (Postfix) with ESMTP id EE02D1AE10B for ; Sat, 21 Dec 2013 16:50:23 -0800 (PST) Received: from [85.158.137.99:23404] by server-8.bemta-3.messagelabs.com id 76/D1-31081-C4736B25; Sun, 22 Dec 2013 00:50:20 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-217.messagelabs.com!1387673419!16399977!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6111 invoked from network); 22 Dec 2013 00:50:20 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-9.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2013 00:50:20 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.22]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sun, 22 Dec 2013 00:50:19 +0000 From: To: , Date: Sun, 22 Dec 2013 00:50:08 +0000 Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO/V7EWDmPZvgBrEO5onIubyqAGppdM9xAgAIprBU= Message-ID: <290E20B455C66743BE178C5C84F1240847E51037B8@EXMB01CMS.surrey.ac.uk> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> <0348D31A-5B3B-415D-88D3-E0574525CD44@netapp.com>, <2691CE0099834E4A9C5044EEC662BB9D45306700@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45306700@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 00:50:28 -0000 It's important to note that protocols sanity-checking their own headers is = important, so that stuff arrives where it should and is rejected before arr= iving where it shouldn't and messing up something else's communications. Basic GRE doesn't check its own headers,and its optional checksum, if used,= does the entire payload. The UDP protocol header serves double-duty as payload and as pseudo-header = check _for both IP and UDP_. It's an important check that demultiplexing ha= ppens in the right place, and more so in IPv6. In IPv6, there's no IP heade= r checksum and more reliance on L2 checking that the packet made it across = a link intact (a design mistake imo - a header checksum could easily have c= overed the unchanging field, and excluded TTL, and given future NAT devices= more of a headache.) One way to get a sensible endpoint arrival checksum for both GRE and UDP he= aders - and the IP pseudoheader, which is much more important in IPv6 due t= o the above design choice - is to use UDP-Lite (itself an academic design m= istake on the assumption it would be a simple upgrade for UDP exploiting re= dundant checksum fields, but stymied by existing deployed code relying on t= he wrong checksum field!) with its checksum set to cover the IP pseudoheade= r, UDP header, and GRE header (especially if the GRE header is checksumless= , and the L2 payload being carried has its own checksum). Saying 'we can just set checksums to zero' is really sloppy engineering - e= specially for IPv6, which is itself sloppily engineered in this regard (and= GRE direct over IPv6 would have the same problem.) I know, I'm just rehash= ing the arguments in RFC6935 and 6936: The operation of IPv6 with UDP with a zero checksum is not the same as IPv4 with UDP with a zero checksum. Protocol designers should not be fooled into thinking that the two are the same. though I draw different conclusions than those RFCs do, erring on the side = of reliability. But the arguments (operational deployment/convenience/decen= t engineering and reliability) are a whole lot more nuanced than just sayin= g 'set checksums to zero, all will be fine'. I oppose adoption of this draft. It's trying to fix a non-problem in a way = no better than using GRE over IPv6 with a key field for entropy. (I have no idea who said the quoted and unquoted text below.) Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of Lucy yong [lucy.yong@huaw= ei.com] Sent: 20 December 2013 15:32 To: Eggert, Lars Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Working Group Adoption call for: dra= ft-yong-tsvwg-gre-in-udp-encap > Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechani= sm does not use or rely on UDP transport layer functions except demultiplex= ing. The UDP header just provides the fields for GRE payload indication and= flow entropy. Thus it is not a regular UDP application built on the top of= UDP transport layer and relying on the UDP layer to provide some transport= functions. However it is useful to document the issues raised in RFC5405 a= gainst GRE-in-UDP. I disagree with this view. UDP as protocol doesn't provide anything other t= han demultiplexing to begin with. That's why we did a BCP on what mechanism= s an application or tunnel that uses UDP on the Internet needs to possibly = implement. Your GRE-in-UDP tunnel is a user of UDP just as any other applic= ation or protocol that uses UDP. It's not special. [Lucy] How about this: GRE-in-UDP encapsulation uses the UDP header so, fro= m UDP perspective, it is a UDP application. From tunnel encapsulation persp= ective, GRE-in-UDP does not use or rely on UDP transport layer functions ex= cept demultiplexing, i.e. the UDP header just provides the fields for GRE p= ayload indication and flow entropy. However it is useful to document the is= sued raised in RFC5405 against GRE-in-UDP. > Congestion Control Guidelines: GRE-in-UDP encapsulation does not provi= de any congestion control mechanism. Whether an application encapsulated by= GRE-in-UDP should employ a congestion control mechanism or not, please ref= er to the congestion control guideline described in RFC5405. It's not enough to refer to RFC5405. RFC5405 actually recommends some mecha= nisms that the tunnel should employ. In your case, where you don't know whe= ther the payload is congestion-controlled, the recommendation is: 2. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled. This can be the case, for example, when some link-layer protocols are encapsulated within UDP (but not all link-layer protocols; some are congestion-controlled). Because it is not known that congestion losses of tunneled non-IP traffic will trigger an appropriate congestion response at the senders, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Because tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines in Section 3.1.1 apply. [Lucy] Thanks! We will make it sufficient and refer to this specific sectio= n in RFC5405. Regards, Lucy > Message Size Guidelines: (This is already addressed in section 4 of th= e draft). > > Reliability Guidelines: Not apply. GRE-in-UDP provides the same reliab= ility and integrity as of GRE encapsulation. In order words, no need additi= onal mechanism when using GRE-in-UDP instead of GRE. > > Checksum Guidelines: Since GRE already has the checksum function, GRE-= in-UDP does not need to use the UDP checksum. For simplifying the process, = UDP checksum should be set to zero. > > Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a standa= rd UDP port number [TBD] to indicate GRE payload. This port number MUST not= be used by any middlebox or an application for other purpose. This will en= sure the consistent behavior along the path when the application is encapsu= lated by GRE or GRE-in-UDP. > > Programming Guidelines: Not apply. The applicability of GRE-in-UDP is = to the GRE encapsulated network protocols that generate a high traffic volu= me. > > ICMP Guidelines: add text in section 7.1.: If tunnel end point uses IC= MP to inform no GRE-in-UDP support, peer end point needs additional validat= ion checking. The validation process should follow the guideline described = in RFC5405. (does this address Gorry's comment?) > > Security Considerations: like to hear if we should use DTLS in the env= ironment that the security is a concern. It would be good to see the discussion on the points above in the ID. Lars From edc@google.com Sat Dec 21 20:07:33 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3D1AE169 for ; Sat, 21 Dec 2013 20:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJv7-88AowRU for ; Sat, 21 Dec 2013 20:07:31 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0304F1AE164 for ; Sat, 21 Dec 2013 20:07:30 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id z2so9860259wiv.7 for ; Sat, 21 Dec 2013 20:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ekRup7942XhEXchxY8213lvk6vyVL0YgmLoyNtSrouQ=; b=FvEDnQ06ou/AW/nNFsfgIanmCVwdsuzi5JQfsh0GNox+T2bxRUdG5e1OpwKFAGqYMG VjppF+oUsuQ6oWfBSmBDmltlxoTLs+lurPvNhMt70ElmP0at/pIv9eQx04+ZTFTs/VM/ TJvRYI8egTzZAx0PgynjR5hUbzSMcfM4LmY7xhr9FV0VWZ6DKvHrp8rZmDiM8+gDwxc5 e6e/LYZ9GEop0+rUO6+gNX2jtuOoPzXwQpxt53HSz1T3wbdQ6R6XNy+ws6rfV3/S048l hZWAXMgitXD2Peznnu3f9y9nJDub06cEdZ6Czi8RmVsKVlGqyqcr0Xynk1SygHPhFPuw PdNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ekRup7942XhEXchxY8213lvk6vyVL0YgmLoyNtSrouQ=; b=i3yNt1dvOKMSFLrPQtv4WZxDtwiuUcoGBpFBphDIGQYTrZU+Hgd52NIbzrYMupKmrc Ee9Wbt/FkBto6y5J557Jql8E5EauPe0Y2omQnPdW2zUlXjlrQipUIS05EMJDb2EZoHb5 EXmS0Alaqc95iSk2wLGVIk277kxpUhEF0JkawreNHSmo3fFFFIeMKjhg8ZJVozHo67Dw h41HBKJwKpjw/HaVgOPGCaosqSdDmWfDMLojt+w2GQ7S0trqNlwK926oldPi1lX8pIx4 VXsqvrVF7/ANssmeopyCSawxlO39VGfuP/DDWwJ7vhVodkAgxXdsHN2+pJvyjBP2AmqY h1Mw== X-Gm-Message-State: ALoCoQnVqcIw51ozSxWCXijaokgrwnCaUpBb6GWQV+Z/Hjs0RtZfaQC4JASe4cAiFoe37XmqnMwBxYvnMgdvCUYfYAWWd0GYd8vJc5fZDBH5cpl0b/FA60FmfacdqrE1XJg6KwcRngnr5w6V/qtzyVdaqqfppmeHGlre++2bN8pXI/R1YaAWbULKq/Qa1kyfOS6tB+XU7uN5 X-Received: by 10.194.120.41 with SMTP id kz9mr19492wjb.92.1387685247659; Sat, 21 Dec 2013 20:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Sat, 21 Dec 2013 20:06:47 -0800 (PST) In-Reply-To: <290E20B455C66743BE178C5C84F1240847E51037B8@EXMB01CMS.surrey.ac.uk> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> <0348D31A-5B3B-415D-88D3-E0574525CD44@netapp.com> <2691CE0099834E4A9C5044EEC662BB9D45306700@dfweml509-mbx.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E51037B8@EXMB01CMS.surrey.ac.uk> From: Edward Crabbe Date: Sat, 21 Dec 2013 20:06:47 -0800 Message-ID: To: l.wood@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 04:07:34 -0000 Disagree. The non-problem part is simply not true, at least for those of who maintain backbones with older equipment that cannot make use of the GRE key, or for those networks that already make use of the key for other purposes. W/r/t the 'sloppy engineering': again, disagree. You've conveniently ignored the arguments offered up in *favor* of checksum 0 in RFC6935. I obviously agree that the issue is more nuanced than 'set checksums to zero, all will be fine'; it was never our intent to imply this. On Sat, Dec 21, 2013 at 4:50 PM, wrote: > It's important to note that protocols sanity-checking their own headers i= s important, so that stuff arrives where it should and is rejected before a= rriving where it shouldn't and messing up something else's communications. > > Basic GRE doesn't check its own headers,and its optional checksum, if use= d, does the entire payload. > > The UDP protocol header serves double-duty as payload and as pseudo-heade= r check _for both IP and UDP_. It's an important check that demultiplexing = happens in the right place, and more so in IPv6. In IPv6, there's no IP hea= der checksum and more reliance on L2 checking that the packet made it acros= s a link intact (a design mistake imo - a header checksum could easily have= covered the unchanging field, and excluded TTL, and given future NAT devic= es more of a headache.) > > One way to get a sensible endpoint arrival checksum for both GRE and UDP = headers - and the IP pseudoheader, which is much more important in IPv6 due= to the above design choice - is to use UDP-Lite (itself an academic design= mistake on the assumption it would be a simple upgrade for UDP exploiting = redundant checksum fields, but stymied by existing deployed code relying on= the wrong checksum field!) with its checksum set to cover the IP pseudohea= der, UDP header, and GRE header (especially if the GRE header is checksumle= ss, and the L2 payload being carried has its own checksum). > > Saying 'we can just set checksums to zero' is really sloppy engineering -= especially for IPv6, which is itself sloppily engineered in this regard (a= nd GRE direct over IPv6 would have the same problem.) I know, I'm just reha= shing the arguments in RFC6935 and 6936: > > The operation of IPv6 with UDP with a zero checksum is not the same > as IPv4 with UDP with a zero checksum. Protocol designers should not > be fooled into thinking that the two are the same. > > though I draw different conclusions than those RFCs do, erring on the sid= e of reliability. But the arguments (operational deployment/convenience/dec= ent engineering and reliability) are a whole lot more nuanced than just say= ing 'set checksums to zero, all will be fine'. > > I oppose adoption of this draft. It's trying to fix a non-problem in a wa= y no better than using GRE over IPv6 with a key field for entropy. > > (I have no idea who said the quoted and unquoted text below.) > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ________________________________________ > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of Lucy yong [lucy.yong@hu= awei.com] > Sent: 20 December 2013 15:32 > To: Eggert, Lars > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Working Group Adoption call for: d= raft-yong-tsvwg-gre-in-udp-encap > >> Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechan= ism does not use or rely on UDP transport layer functions except demultiple= xing. The UDP header just provides the fields for GRE payload indication an= d flow entropy. Thus it is not a regular UDP application built on the top o= f UDP transport layer and relying on the UDP layer to provide some transpor= t functions. However it is useful to document the issues raised in RFC5405 = against GRE-in-UDP. > > I disagree with this view. UDP as protocol doesn't provide anything other= than demultiplexing to begin with. That's why we did a BCP on what mechani= sms an application or tunnel that uses UDP on the Internet needs to possibl= y implement. Your GRE-in-UDP tunnel is a user of UDP just as any other appl= ication or protocol that uses UDP. It's not special. > > [Lucy] How about this: GRE-in-UDP encapsulation uses the UDP header so, f= rom UDP perspective, it is a UDP application. From tunnel encapsulation per= spective, GRE-in-UDP does not use or rely on UDP transport layer functions = except demultiplexing, i.e. the UDP header just provides the fields for GRE= payload indication and flow entropy. However it is useful to document the = issued raised in RFC5405 against GRE-in-UDP. > >> Congestion Control Guidelines: GRE-in-UDP encapsulation does not prov= ide any congestion control mechanism. Whether an application encapsulated b= y GRE-in-UDP should employ a congestion control mechanism or not, please re= fer to the congestion control guideline described in RFC5405. > > It's not enough to refer to RFC5405. RFC5405 actually recommends some mec= hanisms that the tunnel should employ. In your case, where you don't know w= hether the payload is congestion-controlled, the recommendation is: > > 2. A tunnel generates UDP traffic at a volume that corresponds to > the volume of payload traffic, and the payload traffic is not > known to be IP-based, or is known to be IP-based but not > congestion-controlled. > > This can be the case, for example, when some link-layer protocols > are encapsulated within UDP (but not all link-layer protocols; > some are congestion-controlled). Because it is not known that > congestion losses of tunneled non-IP traffic will trigger an > appropriate congestion response at the senders, the UDP tunnel > SHOULD employ an appropriate congestion control mechanism. > Because tunnels are usually bulk-transfer applications as far as > the intermediate routers are concerned, the guidelines in > Section 3.1.1 apply. > > [Lucy] Thanks! We will make it sufficient and refer to this specific sect= ion in RFC5405. > > Regards, > Lucy > >> Message Size Guidelines: (This is already addressed in section 4 of t= he draft). >> >> Reliability Guidelines: Not apply. GRE-in-UDP provides the same relia= bility and integrity as of GRE encapsulation. In order words, no need addit= ional mechanism when using GRE-in-UDP instead of GRE. >> >> Checksum Guidelines: Since GRE already has the checksum function, GRE= -in-UDP does not need to use the UDP checksum. For simplifying the process,= UDP checksum should be set to zero. >> >> Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a stand= ard UDP port number [TBD] to indicate GRE payload. This port number MUST no= t be used by any middlebox or an application for other purpose. This will e= nsure the consistent behavior along the path when the application is encaps= ulated by GRE or GRE-in-UDP. >> >> Programming Guidelines: Not apply. The applicability of GRE-in-UDP is= to the GRE encapsulated network protocols that generate a high traffic vol= ume. >> >> ICMP Guidelines: add text in section 7.1.: If tunnel end point uses I= CMP to inform no GRE-in-UDP support, peer end point needs additional valida= tion checking. The validation process should follow the guideline described= in RFC5405. (does this address Gorry's comment?) >> >> Security Considerations: like to hear if we should use DTLS in the en= vironment that the security is a concern. > > It would be good to see the discussion on the points above in the ID. > > Lars > From l.wood@surrey.ac.uk Sat Dec 21 22:10:08 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14C51AE072 for ; Sat, 21 Dec 2013 22:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO1ZNXpbz1_j for ; Sat, 21 Dec 2013 22:10:04 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA421ADFEF for ; Sat, 21 Dec 2013 22:10:03 -0800 (PST) Received: from [85.158.137.99:22272] by server-14.bemta-3.messagelabs.com id 8E/48-06105-83286B25; Sun, 22 Dec 2013 06:10:00 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-217.messagelabs.com!1387692599!2630000!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9201 invoked from network); 22 Dec 2013 06:09:59 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-13.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2013 06:09:59 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.22]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Sun, 22 Dec 2013 06:09:58 +0000 From: To: Date: Sun, 22 Dec 2013 06:09:47 +0000 Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: Ac7+y06HUPsHyq8ERUmkdgr75NdriwAEBu+I Message-ID: <290E20B455C66743BE178C5C84F1240847E51037B9@EXMB01CMS.surrey.ac.uk> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> <0348D31A-5B3B-415D-88D3-E0574525CD44@netapp.com> <2691CE0099834E4A9C5044EEC662BB9D45306700@dfweml509-mbx.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E51037B8@EXMB01CMS.surrey.ac.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 06:10:08 -0000 The arguments offered up in RFC6935 are explicitly _for_ tunnels. I quote: Some non-tunnel protocols operate with general servers that do not know the source from which they will receive a packet. In such applications, a zero UDP checksum is unsuitable, because it is necessary to provide the first level of verification that the packet was intended for the receiving server. A verification prevents the server from processing the datagram payload; without this, the server may spend significant resources processing the packet, including sending replies or error messages. [..] One unfortunate side effect of increased use of a zero checksum is that it also increases the likelihood of acceptance when a datagram with a zero UDP checksum is misdelivered. This requires all tunnel protocols using this method to be designed to be robust in the face of misdelivery. There's no discussion of the impact of that 'unfortunate side effect' of mi= sdelivered packets with zero checksum and corrupted port address arriving a= t some other application, and screwing that up via pollution. In other word= s, it's fine and dandy for tunnels to protect themselves, but the rest of t= he Internet be damned, it's not the tunnels' problem if zero-checksum packe= ts wind up elesewhere. At least GRE over IP direct didn't have that problem as much; other UDP app= lications were untouched, and a lot more selective corruption would be requ= ired to turn a non-UDP packet into a valid UDP packet that hits a port. We agree on nuance. draft-yong-tsvwg-gre-in-udp-encap is not about nuance, = but about expedience, like so much of IETF work. Lloyd Wood http://sat-net.com/L.Wood/ this just supports my thesis that all transport work im the IETF is dooomed= . ________________________________________ From: Edward Crabbe [edc@google.com] Sent: 22 December 2013 04:06 To: Wood L Dr (Electronic Eng) Cc: Lucy yong; Eggert, Lars; tsvwg@ietf.org Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-= in-udp-encap Disagree. The non-problem part is simply not true, at least for those of who maintain backbones with older equipment that cannot make use of the GRE key, or for those networks that already make use of the key for other purposes. W/r/t the 'sloppy engineering': again, disagree. You've conveniently ignored the arguments offered up in *favor* of checksum 0 in RFC6935. I obviously agree that the issue is more nuanced than 'set checksums to zero, all will be fine'; it was never our intent to imply this. On Sat, Dec 21, 2013 at 4:50 PM, wrote: > It's important to note that protocols sanity-checking their own headers i= s important, so that stuff arrives where it should and is rejected before a= rriving where it shouldn't and messing up something else's communications. > > Basic GRE doesn't check its own headers,and its optional checksum, if use= d, does the entire payload. > > The UDP protocol header serves double-duty as payload and as pseudo-heade= r check _for both IP and UDP_. It's an important check that demultiplexing = happens in the right place, and more so in IPv6. In IPv6, there's no IP hea= der checksum and more reliance on L2 checking that the packet made it acros= s a link intact (a design mistake imo - a header checksum could easily have= covered the unchanging field, and excluded TTL, and given future NAT devic= es more of a headache.) > > One way to get a sensible endpoint arrival checksum for both GRE and UDP = headers - and the IP pseudoheader, which is much more important in IPv6 due= to the above design choice - is to use UDP-Lite (itself an academic design= mistake on the assumption it would be a simple upgrade for UDP exploiting = redundant checksum fields, but stymied by existing deployed code relying on= the wrong checksum field!) with its checksum set to cover the IP pseudohea= der, UDP header, and GRE header (especially if the GRE header is checksumle= ss, and the L2 payload being carried has its own checksum). > > Saying 'we can just set checksums to zero' is really sloppy engineering -= especially for IPv6, which is itself sloppily engineered in this regard (a= nd GRE direct over IPv6 would have the same problem.) I know, I'm just reha= shing the arguments in RFC6935 and 6936: > > The operation of IPv6 with UDP with a zero checksum is not the same > as IPv4 with UDP with a zero checksum. Protocol designers should not > be fooled into thinking that the two are the same. > > though I draw different conclusions than those RFCs do, erring on the sid= e of reliability. But the arguments (operational deployment/convenience/dec= ent engineering and reliability) are a whole lot more nuanced than just say= ing 'set checksums to zero, all will be fine'. > > I oppose adoption of this draft. It's trying to fix a non-problem in a wa= y no better than using GRE over IPv6 with a key field for entropy. > > (I have no idea who said the quoted and unquoted text below.) > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ________________________________________ > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of Lucy yong [lucy.yong@hu= awei.com] > Sent: 20 December 2013 15:32 > To: Eggert, Lars > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Working Group Adoption call for: d= raft-yong-tsvwg-gre-in-udp-encap > >> Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechan= ism does not use or rely on UDP transport layer functions except demultiple= xing. The UDP header just provides the fields for GRE payload indication an= d flow entropy. Thus it is not a regular UDP application built on the top o= f UDP transport layer and relying on the UDP layer to provide some transpor= t functions. However it is useful to document the issues raised in RFC5405 = against GRE-in-UDP. > > I disagree with this view. UDP as protocol doesn't provide anything other= than demultiplexing to begin with. That's why we did a BCP on what mechani= sms an application or tunnel that uses UDP on the Internet needs to possibl= y implement. Your GRE-in-UDP tunnel is a user of UDP just as any other appl= ication or protocol that uses UDP. It's not special. > > [Lucy] How about this: GRE-in-UDP encapsulation uses the UDP header so, f= rom UDP perspective, it is a UDP application. From tunnel encapsulation per= spective, GRE-in-UDP does not use or rely on UDP transport layer functions = except demultiplexing, i.e. the UDP header just provides the fields for GRE= payload indication and flow entropy. However it is useful to document the = issued raised in RFC5405 against GRE-in-UDP. > >> Congestion Control Guidelines: GRE-in-UDP encapsulation does not prov= ide any congestion control mechanism. Whether an application encapsulated b= y GRE-in-UDP should employ a congestion control mechanism or not, please re= fer to the congestion control guideline described in RFC5405. > > It's not enough to refer to RFC5405. RFC5405 actually recommends some mec= hanisms that the tunnel should employ. In your case, where you don't know w= hether the payload is congestion-controlled, the recommendation is: > > 2. A tunnel generates UDP traffic at a volume that corresponds to > the volume of payload traffic, and the payload traffic is not > known to be IP-based, or is known to be IP-based but not > congestion-controlled. > > This can be the case, for example, when some link-layer protocols > are encapsulated within UDP (but not all link-layer protocols; > some are congestion-controlled). Because it is not known that > congestion losses of tunneled non-IP traffic will trigger an > appropriate congestion response at the senders, the UDP tunnel > SHOULD employ an appropriate congestion control mechanism. > Because tunnels are usually bulk-transfer applications as far as > the intermediate routers are concerned, the guidelines in > Section 3.1.1 apply. > > [Lucy] Thanks! We will make it sufficient and refer to this specific sect= ion in RFC5405. > > Regards, > Lucy > >> Message Size Guidelines: (This is already addressed in section 4 of t= he draft). >> >> Reliability Guidelines: Not apply. GRE-in-UDP provides the same relia= bility and integrity as of GRE encapsulation. In order words, no need addit= ional mechanism when using GRE-in-UDP instead of GRE. >> >> Checksum Guidelines: Since GRE already has the checksum function, GRE= -in-UDP does not need to use the UDP checksum. For simplifying the process,= UDP checksum should be set to zero. >> >> Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a stand= ard UDP port number [TBD] to indicate GRE payload. This port number MUST no= t be used by any middlebox or an application for other purpose. This will e= nsure the consistent behavior along the path when the application is encaps= ulated by GRE or GRE-in-UDP. >> >> Programming Guidelines: Not apply. The applicability of GRE-in-UDP is= to the GRE encapsulated network protocols that generate a high traffic vol= ume. >> >> ICMP Guidelines: add text in section 7.1.: If tunnel end point uses I= CMP to inform no GRE-in-UDP support, peer end point needs additional valida= tion checking. The validation process should follow the guideline described= in RFC5405. (does this address Gorry's comment?) >> >> Security Considerations: like to hear if we should use DTLS in the en= vironment that the security is a concern. > > It would be good to see the discussion on the points above in the ID. > > Lars > From lucy.yong@huawei.com Sun Dec 22 08:58:53 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213641AE729 for ; Sun, 22 Dec 2013 08:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYWakIaQJtJe for ; Sun, 22 Dec 2013 08:58:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 293E31AE725 for ; Sun, 22 Dec 2013 08:58:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZG65251; Sun, 22 Dec 2013 16:58:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 22 Dec 2013 16:57:59 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 22 Dec 2013 16:58:42 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Sun, 22 Dec 2013 08:58:37 -0800 From: Lucy yong To: "l.wood@surrey.ac.uk" , "edc@google.com" Thread-Topic: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap Thread-Index: AQHO/stbtjw9dRWkUU+4/IHLKXolgppgQVqAgAAm9zA= Date: Sun, 22 Dec 2013 16:58:37 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45306A66@dfweml509-mbx.china.huawei.com> References: <22ab814105cd16d61ad4796954d15dd6.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D4530623D@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ECD3C34@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D4530664C@dfweml509-mbx.china.huawei.com> <0348D31A-5B3B-415D-88D3-E0574525CD44@netapp.com> <2691CE0099834E4A9C5044EEC662BB9D45306700@dfweml509-mbx.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E51037B8@EXMB01CMS.surrey.ac.uk>, <290E20B455C66743BE178C5C84F1240847E51037B9@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E51037B9@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-in-udp-encap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 16:58:53 -0000 It is a fair argument on the checksum. It gives the ability for other UDP a= pplications to detect if a UDP packet mis-delivery occurs. =20 Suggested text: since GRE already has the checksum function, GRE-in-UDP doe= s not need to use the UDP checksum. To simplify the process, RECOMMEND to s= et UDP checksum zero. However, GRE-in-UDP may use UDP checksum at the envir= onment where a UDP packet may be mis-delivered to a wrong port.=20 As stated in the draft, GRE-in-UDP primary market place is for IPv4 network= s, where the issue has to be addressed sooner than IPv6 upgrade happens. Thanks, Lucy =20 -----Original Message----- From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk]=20 Sent: Sunday, December 22, 2013 12:10 AM To: edc@google.com Cc: Lucy yong; lars@netapp.com; tsvwg@ietf.org Subject: RE: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-= in-udp-encap The arguments offered up in RFC6935 are explicitly _for_ tunnels. I quote: Some non-tunnel protocols operate with general servers that do not know the source from which they will receive a packet. In such applications, a zero UDP checksum is unsuitable, because it is necessary to provide the first level of verification that the packet was intended for the receiving server. A verification prevents the server from processing the datagram payload; without this, the server may spend significant resources processing the packet, including sending replies or error messages. [..] One unfortunate side effect of increased use of a zero checksum is that it also increases the likelihood of acceptance when a datagram with a zero UDP checksum is misdelivered. This requires all tunnel protocols using this method to be designed to be robust in the face of misdelivery. There's no discussion of the impact of that 'unfortunate side effect' of mi= sdelivered packets with zero checksum and corrupted port address arriving a= t some other application, and screwing that up via pollution. In other word= s, it's fine and dandy for tunnels to protect themselves, but the rest of t= he Internet be damned, it's not the tunnels' problem if zero-checksum packe= ts wind up elesewhere. At least GRE over IP direct didn't have that problem as much; other UDP app= lications were untouched, and a lot more selective corruption would be requ= ired to turn a non-UDP packet into a valid UDP packet that hits a port. We agree on nuance. draft-yong-tsvwg-gre-in-udp-encap is not about nuance, = but about expedience, like so much of IETF work. Lloyd Wood http://sat-net.com/L.Wood/ this just supports my thesis that all transport work im the IETF is dooomed= . ________________________________________ From: Edward Crabbe [edc@google.com] Sent: 22 December 2013 04:06 To: Wood L Dr (Electronic Eng) Cc: Lucy yong; Eggert, Lars; tsvwg@ietf.org Subject: Re: [tsvwg] Working Group Adoption call for: draft-yong-tsvwg-gre-= in-udp-encap Disagree. The non-problem part is simply not true, at least for those of who maintain= backbones with older equipment that cannot make use of the GRE key, or for= those networks that already make use of the key for other purposes. W/r/t the 'sloppy engineering': again, disagree. You've conveniently igno= red the arguments offered up in *favor* of checksum 0 in RFC6935. I obviously agree that the issue is more nuanced than 'set checksums to zer= o, all will be fine'; it was never our intent to imply this. On Sat, Dec 21, 2013 at 4:50 PM, wrote: > It's important to note that protocols sanity-checking their own headers i= s important, so that stuff arrives where it should and is rejected before a= rriving where it shouldn't and messing up something else's communications. > > Basic GRE doesn't check its own headers,and its optional checksum, if use= d, does the entire payload. > > The UDP protocol header serves double-duty as payload and as=20 > pseudo-header check _for both IP and UDP_. It's an important check=20 > that demultiplexing happens in the right place, and more so in IPv6.=20 > In IPv6, there's no IP header checksum and more reliance on L2=20 > checking that the packet made it across a link intact (a design=20 > mistake imo - a header checksum could easily have covered the=20 > unchanging field, and excluded TTL, and given future NAT devices more=20 > of a headache.) > > One way to get a sensible endpoint arrival checksum for both GRE and UDP = headers - and the IP pseudoheader, which is much more important in IPv6 due= to the above design choice - is to use UDP-Lite (itself an academic design= mistake on the assumption it would be a simple upgrade for UDP exploiting = redundant checksum fields, but stymied by existing deployed code relying on= the wrong checksum field!) with its checksum set to cover the IP pseudohea= der, UDP header, and GRE header (especially if the GRE header is checksumle= ss, and the L2 payload being carried has its own checksum). > > Saying 'we can just set checksums to zero' is really sloppy engineering -= especially for IPv6, which is itself sloppily engineered in this regard (a= nd GRE direct over IPv6 would have the same problem.) I know, I'm just reha= shing the arguments in RFC6935 and 6936: > > The operation of IPv6 with UDP with a zero checksum is not the same > as IPv4 with UDP with a zero checksum. Protocol designers should not > be fooled into thinking that the two are the same. > > though I draw different conclusions than those RFCs do, erring on the sid= e of reliability. But the arguments (operational deployment/convenience/dec= ent engineering and reliability) are a whole lot more nuanced than just say= ing 'set checksums to zero, all will be fine'. > > I oppose adoption of this draft. It's trying to fix a non-problem in a wa= y no better than using GRE over IPv6 with a key field for entropy. > > (I have no idea who said the quoted and unquoted text below.) > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ________________________________________ > From: tsvwg [tsvwg-bounces@ietf.org] On Behalf Of Lucy yong=20 > [lucy.yong@huawei.com] > Sent: 20 December 2013 15:32 > To: Eggert, Lars > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Working Group Adoption call for: d= raft-yong-tsvwg-gre-in-udp-encap > >> Although GRE-in-UDP encapsulation uses the UDP header, the tunnel mechan= ism does not use or rely on UDP transport layer functions except demultiple= xing. The UDP header just provides the fields for GRE payload indication an= d flow entropy. Thus it is not a regular UDP application built on the top o= f UDP transport layer and relying on the UDP layer to provide some transpor= t functions. However it is useful to document the issues raised in RFC5405 = against GRE-in-UDP. > > I disagree with this view. UDP as protocol doesn't provide anything other= than demultiplexing to begin with. That's why we did a BCP on what mechani= sms an application or tunnel that uses UDP on the Internet needs to possibl= y implement. Your GRE-in-UDP tunnel is a user of UDP just as any other appl= ication or protocol that uses UDP. It's not special. > > [Lucy] How about this: GRE-in-UDP encapsulation uses the UDP header so, f= rom UDP perspective, it is a UDP application. From tunnel encapsulation per= spective, GRE-in-UDP does not use or rely on UDP transport layer functions = except demultiplexing, i.e. the UDP header just provides the fields for GRE= payload indication and flow entropy. However it is useful to document the = issued raised in RFC5405 against GRE-in-UDP. > >> Congestion Control Guidelines: GRE-in-UDP encapsulation does not prov= ide any congestion control mechanism. Whether an application encapsulated b= y GRE-in-UDP should employ a congestion control mechanism or not, please re= fer to the congestion control guideline described in RFC5405. > > It's not enough to refer to RFC5405. RFC5405 actually recommends some mec= hanisms that the tunnel should employ. In your case, where you don't know w= hether the payload is congestion-controlled, the recommendation is: > > 2. A tunnel generates UDP traffic at a volume that corresponds to > the volume of payload traffic, and the payload traffic is not > known to be IP-based, or is known to be IP-based but not > congestion-controlled. > > This can be the case, for example, when some link-layer protocols > are encapsulated within UDP (but not all link-layer protocols; > some are congestion-controlled). Because it is not known that > congestion losses of tunneled non-IP traffic will trigger an > appropriate congestion response at the senders, the UDP tunnel > SHOULD employ an appropriate congestion control mechanism. > Because tunnels are usually bulk-transfer applications as far as > the intermediate routers are concerned, the guidelines in > Section 3.1.1 apply. > > [Lucy] Thanks! We will make it sufficient and refer to this specific sect= ion in RFC5405. > > Regards, > Lucy > >> Message Size Guidelines: (This is already addressed in section 4 of t= he draft). >> >> Reliability Guidelines: Not apply. GRE-in-UDP provides the same relia= bility and integrity as of GRE encapsulation. In order words, no need addit= ional mechanism when using GRE-in-UDP instead of GRE. >> >> Checksum Guidelines: Since GRE already has the checksum function, GRE= -in-UDP does not need to use the UDP checksum. For simplifying the process,= UDP checksum should be set to zero. >> >> Middlebox Traversal Guidelines: GRE-in-UDP encapsulation uses a stand= ard UDP port number [TBD] to indicate GRE payload. This port number MUST no= t be used by any middlebox or an application for other purpose. This will e= nsure the consistent behavior along the path when the application is encaps= ulated by GRE or GRE-in-UDP. >> >> Programming Guidelines: Not apply. The applicability of GRE-in-UDP is= to the GRE encapsulated network protocols that generate a high traffic vol= ume. >> >> ICMP Guidelines: add text in section 7.1.: If tunnel end point=20 >> uses ICMP to inform no GRE-in-UDP support, peer end point needs=20 >> additional validation checking. The validation process should follow=20 >> the guideline described in RFC5405. (does this address Gorry's=20 >> comment?) >> >> Security Considerations: like to hear if we should use DTLS in the en= vironment that the security is a concern. > > It would be good to see the discussion on the points above in the ID. > > Lars >