From touch@isi.edu Wed Jan 2 13:51:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0D621F8692 for ; Wed, 2 Jan 2013 13:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.943 X-Spam-Level: X-Spam-Status: No, score=-104.943 tagged_above=-999 required=5 tests=[AWL=1.656, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TnLQiObHM6A for ; Wed, 2 Jan 2013 13:51:11 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7029C21F8689 for ; Wed, 2 Jan 2013 13:51:11 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r02LoO1O018806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 13:50:24 -0800 (PST) Message-ID: <50E4ABA0.90007@isi.edu> Date: Wed, 02 Jan 2013 13:50:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eliot Lear References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> In-Reply-To: <50C23EC3.5060704@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 21:51:12 -0000 Hi, all, Any thoughts on this, given the context below? I'd like to have the input of others on this list before updating the draft on this point. Thanks, Joe On 12/7/2012 11:08 AM, Joe Touch wrote: > Hi, Bob, Eliot, et al., > > On 12/6/2012 9:40 PM, Eliot Lear wrote: >> >> On 12/7/12 12:56 AM, Bob Briscoe wrote: >>> I don't see why ceasing to allocate system ports will help. It's not >>> clear whether you are trying to remove the false sense of security >>> that system ports purport to offer, or whether you are trying to >>> remove the higher bar to IANA allocation, both, neither, or what. >>> There's too little written in the draft, on the list and around the >>> bullets in your presentation of the draft to guess fully what you're >>> driving at. >> >> I support the notion of combining system and user for the simple reason >> that there is no technical difference between the two, there is no >> meaningful additional security offered by system. The distinction dates >> back to the notion that non-privileged users couldn't open a port below >> 1024 and we knew all Internet hosts by name. > > This was discussed at several IETFs before this doc was accepted as a WG > item, so I thought there was context. The doc does need expanding on > this, and I will do so in the next revision. > > My view is that: > > - the distinction has evolved to become meaningless, and thus treating > any port as more trusted because of its assigned range is a bad idea (as > Eliot points out above). Yes, there are plenty of systems that do > continue to treat the two ranges as different, but enough others that > don't that it seems a bad idea to continue to support the difference as > meaningful. > > Which is why I propose the following as an overall goal: > > The range 0...49151 will be known as Assigned ports. > > Port assignments will no longer distinguish between 'user', > 'system', 'well-known', and 'registered' subranges of Assigned > ports. > > If we do deprecate the difference between the ranges, we need to decide > how to move forward. > > First, regardless of how we move forward, IMO: > > Assigned ports should use the procedures from RFC 2780 > that apply to User ports. > > There are two ways forward, given that goal (in the order of my > preference): > > a) this document can officially deprecate the distinction between User > and System ports by declaring that IANA should cease further assignments > from the System range > > b) this document can suggest that users should not bother requesting > system ports > > c) this document can officially deprecate the distinction between User > and System ports by merging the two and letting users pick any available > port from the Assigned range > > Of these options, I think (c) creates a "land rush" in the System space, > and we don't have enough understanding of the impact on legacy protocols. > > (a) is the safest, since it merely requires that new services be > designed in a way that assumes that they could be run by any user on any > system - which, these days, seems like a reasonable recommendation. > > (b) is a way to circumvent the issue without deprecating the User/System > distinction, and IMO just continues to ignore the current situation > > Thoughts? > > Joe > From lars@netapp.com Thu Jan 3 01:00:28 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F5321F84E0 for ; Thu, 3 Jan 2013 01:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSlZwVPyf83f for ; Thu, 3 Jan 2013 01:00:28 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 06C9E21F84D8 for ; Thu, 3 Jan 2013 01:00:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,402,1355126400"; d="scan'208";a="4385764" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 03 Jan 2013 01:00:26 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0390Qh6016006; Thu, 3 Jan 2013 01:00:26 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.92]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0328.009; Thu, 3 Jan 2013 01:00:24 -0800 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? Thread-Index: AQHN1A1fDyzEOFozSkOmrli1KOM4oJgNWKEAgADh9oCAKcTuAA== Date: Thu, 3 Jan 2013 09:00:21 +0000 Message-ID: References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> In-Reply-To: <50C23EC3.5060704@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 09:00:28 -0000 Hi, On Dec 7, 2012, at 20:08, Joe Touch wrote: > There are two ways forward, given that goal (in the order of my preferenc= e): >=20 > a) this document can officially deprecate the distinction between User an= d System ports by declaring that IANA should cease further assignments from= the System range RFC6335 already raises the bar for system port allocations: o Ports in the System Ports range (0-1023) are also available for assignment through IANA. Because the System Ports range is both the smallest and the most densely assigned, the requirements for new assignments are more strict than those for the User Ports range, and will only be granted under the "IETF Review" or "IESG Approval" procedures [RFC5226]. A request for a System Port number MUST document *both* why using a port number from the Dynamic Ports range is unsuitable *and* why using a port number from the User Ports range is unsuitable for that application. So essentially, the system port range has become reserved for the IETF. Do = we need to do anything more? > b) this document can suggest that users should not bother requesting syst= em ports Well, it should say that requests need to undergo the needed IETF review ph= ases. > c) this document can officially deprecate the distinction between User an= d System ports by merging the two and letting users pick any available port= from the Assigned range >=20 > Of these options, I think (c) creates a "land rush" in the System space, = and we don't have enough understanding of the impact on legacy protocols. I don't like (c) either. I don't think the land rush is going to happen (be= cause of RFC6335), but because it might affect implementations that do trea= t the ranges differently. Would like to not affect deployed code. > (a) is the safest, since it merely requires that new services be designed= in a way that assumes that they could be run by any user on any system - w= hich, these days, seems like a reasonable recommendation. I think RFC6335 has basically resulted in option (a) already, with the nota= ble exception that the IETF can still assign system ports. I think that's g= ood. > (b) is a way to circumvent the issue without deprecating the User/System = distinction, and IMO just continues to ignore the current situation (b) has also essentially been established by 6335 - requests for system por= ts must undergo IETF Review and therefore be sufficiently documented in an = ID so that this review can happen. IANA cannot assign them directly anymore= . Lars= From brian.e.carpenter@gmail.com Thu Jan 3 01:02:32 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B6721F84E0 for ; Thu, 3 Jan 2013 01:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbKbRdK2puJO for ; Thu, 3 Jan 2013 01:02:30 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 52DB021F84D8 for ; Thu, 3 Jan 2013 01:02:27 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id r1so7240578wey.29 for ; Thu, 03 Jan 2013 01:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n+F5JgB3KqemLGoA0L3fTQ/Cmu2bC9TZoiu2czIsC4o=; b=Pckr0/qd39xqaJJ1VRAdOXHiZ9xFcUUEgW/Yb/2YzDysLzZus+hWYAbjk2C9SpesKP HEthDcOaKYbUBcOHuFy90f/ZQq5t4x2KzegI5OeXjqIFAhtfwYVYqvMnlJJZqXX8wAeO 3D2kyTnGAYyV+2OJvzNsc9SeQ27K6vzhT/3InpdL7RlK1c/uGqu7GvlmVPuX3A9RUBQm /4QTR3Kyjc1F1LrJvQpgoLkpWsOxKbqmQepj32C07gMn4AWUzajxBeBH7LtuYwl6hNS9 PwXOxOUTAQywijd0ai2Hkk644yhg1V2enHOJnQU1mmg5iG0PYNdU5lAXUrcFTacLE/eI UaEA== X-Received: by 10.194.78.162 with SMTP id c2mr76548170wjx.46.1357203746308; Thu, 03 Jan 2013 01:02:26 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-135.as13285.net. [2.102.219.135]) by mx.google.com with ESMTPS id h19sm88608969wiv.7.2013.01.03.01.02.24 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 01:02:24 -0800 (PST) Message-ID: <50E54937.1080109@gmail.com> Date: Thu, 03 Jan 2013 09:02:47 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> <50E4ABA0.90007@isi.edu> In-Reply-To: <50E4ABA0.90007@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 09:02:32 -0000 On 02/01/2013 21:50, Joe Touch wrote: ... >> First, regardless of how we move forward, IMO: >> >> Assigned ports should use the procedures from RFC 2780 >> that apply to User ports. As far as I can tell, RFC 2780 is completely superseded by RFC 6335 for this purpose, and that's what the IANA registry says too. The draft would have to formally update 6335. If I read your statement as "Assigned ports should use the procedures from RFC 6335 that apply to User ports." it would mean "IETF Review", "IESG Approval", or "Expert Review". At the moment, Expert Review is not allowed for ports 0-1023. >> There are two ways forward, given that goal (in the order of my >> preference): >> >> a) this document can officially deprecate the distinction between User >> and System ports by declaring that IANA should cease further assignments >> from the System range >> >> b) this document can suggest that users should not bother requesting >> system ports >> >> c) this document can officially deprecate the distinction between User >> and System ports by merging the two and letting users pick any available >> port from the Assigned range s/pick/request/ >> >> Of these options, I think (c) creates a "land rush" in the System space, >> and we don't have enough understanding of the impact on legacy protocols. As far as I can see, the only real-world effect of your proposal would be to allow ports 0-1023 to be assigned by Expert Review, if and only if we pick option (c). If we pick (a) or (b) we simply waste something like 280 ports without knowing why. Without a proper understanding, I don't see any real basis for deciding whether there's any benefit to a change. In fact I'd go further: if we can't pick (c) the whole exercise seems a bit pointless, since we don't make any change in the real world that I can see. Brian >> >> (a) is the safest, since it merely requires that new services be >> designed in a way that assumes that they could be run by any user on any >> system - which, these days, seems like a reasonable recommendation. >> >> (b) is a way to circumvent the issue without deprecating the User/System >> distinction, and IMO just continues to ignore the current situation >> >> Thoughts? >> >> Joe >> > From gorry@erg.abdn.ac.uk Thu Jan 3 02:19:16 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44BF21F8AF4 for ; Thu, 3 Jan 2013 02:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ke+usKEva4q for ; Thu, 3 Jan 2013 02:19:16 -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 E6DBC21F8804 for ; Thu, 3 Jan 2013 02:19:15 -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 9B9242B4395; Thu, 3 Jan 2013 10:19:14 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 3 Jan 2013 10:19:14 -0000 Message-ID: <5e9eeadacabd6ee925077e1f18226100.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <50E4ABA0.90007@isi.edu> References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> <50E4ABA0.90007@isi.edu> Date: Thu, 3 Jan 2013 10:19:14 -0000 From: gorry@erg.abdn.ac.uk To: "Joe Touch" 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: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 10:19:17 -0000 It seems probable that some systems (legacy, specific platforms) may differentiate the two port ranges - perhaps because of legacy implementations or because they have a different user/process model, different to mainstream OS. (c) below would conflict with this existing use. I can see the merits in at least (b) advising users to not request (and hence IANA to generally not accept) requests to allocate to this range, and explaining why. If there are ANY "potential" examples of cases where new protocols may benefit from having ports in this range that are known at the moment, people do need to speak on this list, or tell the author/ tsvwg chairs. Gorry > Hi, all, > > Any thoughts on this, given the context below? > > I'd like to have the input of others on this list before updating the > draft on this point. > > Thanks, > > Joe > > On 12/7/2012 11:08 AM, Joe Touch wrote: >> Hi, Bob, Eliot, et al., >> >> On 12/6/2012 9:40 PM, Eliot Lear wrote: >>> >>> On 12/7/12 12:56 AM, Bob Briscoe wrote: >>>> I don't see why ceasing to allocate system ports will help. It's not >>>> clear whether you are trying to remove the false sense of security >>>> that system ports purport to offer, or whether you are trying to >>>> remove the higher bar to IANA allocation, both, neither, or what. >>>> There's too little written in the draft, on the list and around the >>>> bullets in your presentation of the draft to guess fully what you're >>>> driving at. >>> >>> I support the notion of combining system and user for the simple reason >>> that there is no technical difference between the two, there is no >>> meaningful additional security offered by system. The distinction >>> dates >>> back to the notion that non-privileged users couldn't open a port below >>> 1024 and we knew all Internet hosts by name. >> >> This was discussed at several IETFs before this doc was accepted as a WG >> item, so I thought there was context. The doc does need expanding on >> this, and I will do so in the next revision. >> >> My view is that: >> >> - the distinction has evolved to become meaningless, and thus treating >> any port as more trusted because of its assigned range is a bad idea (as >> Eliot points out above). Yes, there are plenty of systems that do >> continue to treat the two ranges as different, but enough others that >> don't that it seems a bad idea to continue to support the difference as >> meaningful. >> >> Which is why I propose the following as an overall goal: >> >> The range 0...49151 will be known as Assigned ports. >> >> Port assignments will no longer distinguish between 'user', >> 'system', 'well-known', and 'registered' subranges of Assigned >> ports. >> >> If we do deprecate the difference between the ranges, we need to decide >> how to move forward. >> >> First, regardless of how we move forward, IMO: >> >> Assigned ports should use the procedures from RFC 2780 >> that apply to User ports. >> >> There are two ways forward, given that goal (in the order of my >> preference): >> >> a) this document can officially deprecate the distinction between User >> and System ports by declaring that IANA should cease further assignments >> from the System range >> >> b) this document can suggest that users should not bother requesting >> system ports >> >> c) this document can officially deprecate the distinction between User >> and System ports by merging the two and letting users pick any available >> port from the Assigned range >> >> Of these options, I think (c) creates a "land rush" in the System space, >> and we don't have enough understanding of the impact on legacy >> protocols. >> >> (a) is the safest, since it merely requires that new services be >> designed in a way that assumes that they could be run by any user on any >> system - which, these days, seems like a reasonable recommendation. >> >> (b) is a way to circumvent the issue without deprecating the User/System >> distinction, and IMO just continues to ignore the current situation >> >> Thoughts? >> >> Joe >> > From prvs=071574eb71=anna.brunstrom@kau.se Thu Jan 3 06:29:55 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638D521F8C11 for ; Thu, 3 Jan 2013 06:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcZpQ4Z4nvLA for ; Thu, 3 Jan 2013 06:29:55 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7E21F8C0F for ; Thu, 3 Jan 2013 06:29:54 -0800 (PST) Message-ID: <50E595D6.9000902@kau.se> Date: Thu, 03 Jan 2013 15:29:42 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 14:29:55 -0000 Hi Gorry, I have read both drafts and support their adoption. Best Regards, Anna > This email starts a WG call for adoption for 2 potential TSVWG work items > proposing minor extensions to SCTP: This adoption call will conclude 3rd > January 2013. > > 1) SCTP/DTLS > > The authors of "draft-tuexen-tsvwg-sctp-dtls-encaps-01" request that this > is adopted as TSVWG item. > > The IETF-85 meeting indicated some WG support for this, so we are now > ready to make a formal decision and this email is to allow people to > confirm that there is sufficient energy to complete this work in TSVWG. > > 2) SCTP SACK Immediately > > The authors of "draft-tuexen-tsvwg-sctp-sack-immediately" request that > this is adopted as TSVWG item. > > This draft was discussed at a number of previous IETFs and the IETF-85 > meeting indicated some WG support for this, so we are now ready to make a > formal decision and this email is to allow people to confirm that there is > sufficient energy to complete this work in TSVWG. > > > PLEASE send an email to this list: > > * if you think adopting either/both of these documents in TSVWG is a good > or bad idea. > > * if you have implemented or plan to implement these extensions. > > * Please also indicate if you are willing to REVIEW either/both documents > during its development. > > Best wishes, > > Gorry, David and James. > (TSVWG Co-Chairs) > From touch@isi.edu Thu Jan 3 10:51:15 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E0E21F8AC3 for ; Thu, 3 Jan 2013 10:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZulBEtiocka for ; Thu, 3 Jan 2013 10:51:12 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id EF05421F87B2 for ; Thu, 3 Jan 2013 10:51:11 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r03IonDB016847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 10:50:49 -0800 (PST) Message-ID: <50E5D309.9040208@isi.edu> Date: Thu, 03 Jan 2013 10:50:49 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> <50E4ABA0.90007@isi.edu> <50E54937.1080109@gmail.com> In-Reply-To: <50E54937.1080109@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 18:51:15 -0000 On 1/3/2013 1:02 AM, Brian E Carpenter wrote: > On 02/01/2013 21:50, Joe Touch wrote: > ... >>> First, regardless of how we move forward, IMO: >>> >>> Assigned ports should use the procedures from RFC 2780 >>> that apply to User ports. > > As far as I can tell, RFC 2780 is completely superseded by > RFC 6335 for this purpose, and that's what the IANA registry > says too. The draft would have to formally update 6335. RFC6335 reiterates the process in RFC2780; it doesn't create new policy on this matter. Depending on the decision, this doc might have to update 6335. I.e., arguably neither (a) nor (b) need to update 6335 since they don't change the application process so much as tell IANA or users what to do. > If I read your statement as "Assigned ports should use > the procedures from RFC 6335 that apply to User ports." > it would mean "IETF Review", "IESG Approval", or "Expert Review". > At the moment, Expert Review is not allowed for ports 0-1023. Yup. >>> There are two ways forward, given that goal (in the order of my >>> preference): >>> >>> a) this document can officially deprecate the distinction between User >>> and System ports by declaring that IANA should cease further assignments >>> from the System range >>> >>> b) this document can suggest that users should not bother requesting >>> system ports >>> >>> c) this document can officially deprecate the distinction between User >>> and System ports by merging the two and letting users pick any available >>> port from the Assigned range > > s/pick/request/ Yes. >>> Of these options, I think (c) creates a "land rush" in the System space, >>> and we don't have enough understanding of the impact on legacy protocols. > > As far as I can see, the only real-world effect of your proposal > would be to allow ports 0-1023 to be assigned by Expert Review, > if and only if we pick option (c). Right. > If we pick (a) or (b) we simply > waste something like 280 ports without knowing why. Well, we can explain why. And yes, we would lock out those available ports from further use. > Without a proper understanding, I don't see any real basis for > deciding whether there's any benefit to a change. In fact I'd go > further: if we can't pick (c) the whole exercise seems a bit pointless, > since we don't make any change in the real world that I can see. All of them make a change. I'm not sure why you don't think that's the case. Joe > > Brian > >>> >>> (a) is the safest, since it merely requires that new services be >>> designed in a way that assumes that they could be run by any user on any >>> system - which, these days, seems like a reasonable recommendation. >>> >>> (b) is a way to circumvent the issue without deprecating the User/System >>> distinction, and IMO just continues to ignore the current situation >>> >>> Thoughts? >>> >>> Joe >>> >> From touch@isi.edu Thu Jan 3 11:05:53 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED23E21F8A9B for ; Thu, 3 Jan 2013 11:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5xVcLRIVVnn for ; Thu, 3 Jan 2013 11:05:52 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5563121F86C8 for ; Thu, 3 Jan 2013 11:05:52 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r03J54CG019760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 11:05:04 -0800 (PST) Message-ID: <50E5D660.1000107@isi.edu> Date: Thu, 03 Jan 2013 11:05:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> <50E4ABA0.90007@isi.edu> <5e9eeadacabd6ee925077e1f18226100.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <5e9eeadacabd6ee925077e1f18226100.squirrel@www.erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:05:53 -0000 Hi, Gorry, On 1/3/2013 2:19 AM, gorry@erg.abdn.ac.uk wrote: > It seems probable that some systems (legacy, specific platforms) may > differentiate the two port ranges - perhaps because of legacy > implementations or because they have a different user/process model, > different to mainstream OS. (c) below would conflict with this existing > use. Yes. However, the current distinction is meaningless in some OSes as well; the point of (c) is to recognize that the distinction is already not widely enforced. > I can see the merits in at least (b) advising users to not request (and > hence IANA to generally not accept) requests to allocate to this range, > and explaining why. > > If there are ANY "potential" examples of cases where new protocols may > benefit from having ports in this range that are known at the moment, > people do need to speak on this list, or tell the author/ tsvwg chairs. Here's how many have been assigned in the past few years: 2007 2 2008 3 2009 0 2010 6 2011 2 2012 8 I.e., we still do get requests. There are people who still want numbers in that range due to perceived security, but IMO that rationale is incorrect. If that's the only reason, then IMO there's no reason to distinguish those numbers as different. Joe > > Gorry > >> Hi, all, >> >> Any thoughts on this, given the context below? >> >> I'd like to have the input of others on this list before updating the >> draft on this point. >> >> Thanks, >> >> Joe >> >> On 12/7/2012 11:08 AM, Joe Touch wrote: >>> Hi, Bob, Eliot, et al., >>> >>> On 12/6/2012 9:40 PM, Eliot Lear wrote: >>>> >>>> On 12/7/12 12:56 AM, Bob Briscoe wrote: >>>>> I don't see why ceasing to allocate system ports will help. It's not >>>>> clear whether you are trying to remove the false sense of security >>>>> that system ports purport to offer, or whether you are trying to >>>>> remove the higher bar to IANA allocation, both, neither, or what. >>>>> There's too little written in the draft, on the list and around the >>>>> bullets in your presentation of the draft to guess fully what you're >>>>> driving at. >>>> >>>> I support the notion of combining system and user for the simple reason >>>> that there is no technical difference between the two, there is no >>>> meaningful additional security offered by system. The distinction >>>> dates >>>> back to the notion that non-privileged users couldn't open a port below >>>> 1024 and we knew all Internet hosts by name. >>> >>> This was discussed at several IETFs before this doc was accepted as a WG >>> item, so I thought there was context. The doc does need expanding on >>> this, and I will do so in the next revision. >>> >>> My view is that: >>> >>> - the distinction has evolved to become meaningless, and thus treating >>> any port as more trusted because of its assigned range is a bad idea (as >>> Eliot points out above). Yes, there are plenty of systems that do >>> continue to treat the two ranges as different, but enough others that >>> don't that it seems a bad idea to continue to support the difference as >>> meaningful. >>> >>> Which is why I propose the following as an overall goal: >>> >>> The range 0...49151 will be known as Assigned ports. >>> >>> Port assignments will no longer distinguish between 'user', >>> 'system', 'well-known', and 'registered' subranges of Assigned >>> ports. >>> >>> If we do deprecate the difference between the ranges, we need to decide >>> how to move forward. >>> >>> First, regardless of how we move forward, IMO: >>> >>> Assigned ports should use the procedures from RFC 2780 >>> that apply to User ports. >>> >>> There are two ways forward, given that goal (in the order of my >>> preference): >>> >>> a) this document can officially deprecate the distinction between User >>> and System ports by declaring that IANA should cease further assignments >>> from the System range >>> >>> b) this document can suggest that users should not bother requesting >>> system ports >>> >>> c) this document can officially deprecate the distinction between User >>> and System ports by merging the two and letting users pick any available >>> port from the Assigned range >>> >>> Of these options, I think (c) creates a "land rush" in the System space, >>> and we don't have enough understanding of the impact on legacy >>> protocols. >>> >>> (a) is the safest, since it merely requires that new services be >>> designed in a way that assumes that they could be run by any user on any >>> system - which, these days, seems like a reasonable recommendation. >>> >>> (b) is a way to circumvent the issue without deprecating the User/System >>> distinction, and IMO just continues to ignore the current situation >>> >>> Thoughts? >>> >>> Joe >>> >> From touch@isi.edu Thu Jan 3 11:16:05 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9292321F8CC8 for ; Thu, 3 Jan 2013 11:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI6X-oipvYyq for ; Thu, 3 Jan 2013 11:16:04 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DC3D321F8A67 for ; Thu, 3 Jan 2013 11:16:04 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r03JFkOX021817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 11:15:46 -0800 (PST) Message-ID: <50E5D8E2.3080701@isi.edu> Date: Thu, 03 Jan 2013 11:15:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Eggert, Lars" References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:16:05 -0000 Hi, Lars, On 1/3/2013 1:00 AM, Eggert, Lars wrote: > Hi, > > On Dec 7, 2012, at 20:08, Joe Touch wrote: >> There are two ways forward, given that goal (in the order of my preference): >> >> a) this document can officially deprecate the distinction between User and System ports by declaring that IANA should cease further assignments from the System range > > RFC6335 already raises the bar for system port allocations: > > o Ports in the System Ports range (0-1023) are also available for > assignment through IANA. Because the System Ports range is both > the smallest and the most densely assigned, the requirements for > new assignments are more strict than those for the User Ports > range, and will only be granted under the "IETF Review" or "IESG > Approval" procedures [RFC5226]. A request for a System Port > number MUST document *both* why using a port number from the > Dynamic Ports range is unsuitable *and* why using a port number > from the User Ports range is unsuitable for that application. > > So essentially, the system port range has become reserved for the IETF. Do we need to do anything more? I just posted a summary of how many ports have been assigned in the past few years to the system range. The procedures above are what was informally required by IANA during that period anyway, and so we continue to receive requests and approve assignments based on the idea that this range is desired. >> b) this document can suggest that users should not bother requesting system ports > > Well, it should say that requests need to undergo the needed IETF review phases. Yes, but in this case we'd be recommending that the IETF review phase isn't relevant; the point is that this range isn't treated differently in enough OSes that it's not useful to treat those ports as disgintuished. >> c) this document can officially deprecate the distinction between User and System ports by merging the two and letting users pick any available port from the Assigned range >> >> Of these options, I think (c) creates a "land rush" in the System space, and we don't have enough understanding of the impact on legacy protocols. > > I don't like (c) either. I don't think the land rush is going to happen (because of RFC6335), (c) implies updating 6335 to allow "expert review" only, as with the user ports now. > but because it might affect implementations that do treat the ranges > differently. Would like to not affect deployed code. Right, but the concern is that there are two sets of widely deployed code: - code that treats system ports as privileged, e.g., requiring "root" access to connect to those ports - code that does not treat those ports as privileged IMO, it's a security risk to continue to expect these ports as being privileged, and we should cease propagating that misconception. >> (a) is the safest, since it merely requires that new services be designed in a way that assumes that they could be run by any user on any system - which, these days, seems like a reasonable recommendation. > > I think RFC6335 has basically resulted in option (a) already, with > the notable exception that the IETF can still assign system ports. I > think that's good. As I noted in my other post, (a) was essentially in effect for the past 6 years (at least), and that resulted in continued assignments (averaging 3/year). Note - this isn't an issue about running out of those ports. Given 270 available (Brian's number), we'd have 90 years left, which is roughly when the other ports run out at the current rate of assignment too. >> (b) is a way to circumvent the issue without deprecating the User/System distinction, and IMO just continues to ignore the current situation > > (b) has also essentially been established by 6335 - requests for system ports must undergo IETF Review and therefore be sufficiently documented in an ID so that this review can happen. IANA cannot assign them directly anymore. I disagree; again, we've had 3/year. That's not based on a recommendation that users shouldn't bother with that range. Joe From touch@isi.edu Thu Jan 3 15:06:34 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6453621F8DEE for ; Thu, 3 Jan 2013 15:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.145 X-Spam-Level: X-Spam-Status: No, score=-104.145 tagged_above=-999 required=5 tests=[AWL=2.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIBMEsSOTPH1 for ; Thu, 3 Jan 2013 15:06:33 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 658B121F8CAB for ; Thu, 3 Jan 2013 15:06:33 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r03N5bxV011471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 15:05:37 -0800 (PST) Message-ID: <50E60EC1.7060404@isi.edu> Date: Thu, 03 Jan 2013 15:05:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: jsaldana@unizar.es References: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> <50C99DC8.7060505@ericsson.com> <00dc01cdda12$5cb82190$162864b0$@unizar.es> In-Reply-To: <00dc01cdda12$5cb82190$162864b0$@unizar.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: gorry@erg.abdn.ac.uk, 'Magnus Westerlund' , tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:06:34 -0000 Hi, all, I read both this and 6man-udpchecksums, and have comments below. Joe ----- First, I'm a bit bothered that this issue is spread across two documents. IMO, these two ought to be merged into a single statement. It's confusing that neither doc includes a complete description of the issue and solution. This doc (6man-udpzero) is confusing - it lists 4 separate reasons for the need for zero checksums (sec 1.3.1), yet the first three restate the first one (reduced forwarding costs), and the last one (load balancing) isn't sufficiently motivated to the need to avoid checksums. This section should be revised to differentiate the separate issues and justify those that remain as being tied to avoiding the checksum. I do not see sufficient reason to implement this solution vs. UDP-lite. In both cases there is a need to revise the endpoints that process UDP packets, and in both cases an unmodified endpoint would drop the packets unless updated. That argues against the need for a unique solution for UDP vs. using UDP-lite. I.e., any packet that parses UDP headers would drop v6 zero-checksum UDPs unless modified, and any modification could support UDP-lite instead. Further, UDP-lite allows protection of portions of the UDP header that might benefit from this, even when the underlying packet has its own checksums. --- 6man-udpchecksums further remains incomplete. The doc gives specific text to update RFC 2460, but that text refers obscurely to "zero-checksum mode" without defining it anywhere (including inside the replacement text). IMO, there ought to be a very direct discussion of what that mode means and how it is achieved both on the send and receive side. I also wonder whether an interface that enables zero checksum mode should handle non-zero checksums. If these are intended for a tunnel, then IMO that use ought to be sufficiently constrained as to suggest that nonzero checksums might be a clear indication of an error (including a DOS attack on computation resources at a receiver). ---- On 12/14/2012 7:47 AM, Jose Saldana wrote: > Hi all. I have read draft-ietf-6man-udpchecksums-06.txt. I support it. > > > Only these comments (I hope they are useful): > > - Although the difference between "tunneling packet" and "tunneled packet" > is clear, I think something similar could be done when talking about > "tunneling protocols". The document sometimes talks about "tunnel protocols" > and other times about "tunneling protocols". Perhaps the term could be > unified. > > > Sentences which could be improved: > > - " These different examples each help to significantly reduce the > likelihood that a corrupted inner tunneled packet is finally delivered to a > protocol listener that can be affected by the packet." Sounds very > complicated, IMHO. > > - "similar effects that reduce the likelihood that an mis-delivered packet > are delivered." Could say " similar effects that reduce the likelihood that > a mis-delivered packet is delivered." > > - " A corruption will commonly only effect the single packet, not > established protocol state." Could say "A corruption will commonly affect a > single packet, not the established protocol state." > > - " Tunnel protocols encapsulating IP this will generally be safe," could > say "In tunnel protocols encapsulating IP, this will generally be safe," > > > A small typo: > > - "Corruption of the address information in an encapsulating packets," could > say " Corruption of the address information in an encapsulating packet" > > > Best regards, > > Jose Saldana > >> -----Mensaje original----- >> De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de >> Magnus Westerlund >> Enviado el: jueves, 13 de diciembre de 2012 10:20 >> Para: gorry@erg.abdn.ac.uk >> CC: tsvwg@ietf.org >> Asunto: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man- >> udpzero >> >> Hi, >> >> I do hope we will get some reviews from TSVWG. But I would like to point >> out that the target is Standards Track. >> >> I also would recommend that you take a look at the document implementing >> the change in the IPv6 Specification also after having reviewed >> draft-ietf-6man-udpzero-08: >> >> >> The IESG has received a request from the IPv6 Maintenance WG (6man) to >> consider the following document: >> - 'IPv6 and UDP Checksums for Tunneled Packets' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits > final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the beginning > of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document provides an update of the Internet Protocol version 6 >> (IPv6) specification (RFC2460) to improve the performance in the use >> case when a tunnel protocol uses UDP with IPv6 to tunnel packets. >> The performance improvement is obtained by relaxing the IPv6 UDP >> checksum requirement for suitable tunneling protocol where header >> information is protected on the "inner" packet being carried. This >> relaxation removes the overhead associated with the computation of >> UDP checksums on IPv6 packets used to carry tunnel protocols. The >> specification describes how the IPv6 UDP checksum requirement can be >> relaxed for the situation where the encapsulated packet itself >> contains a checksum. The limitations and risks of this approach are >> described, and restrictions specified on the use of the method. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> On 2012-12-12 09:09, gorry@erg.abdn.ac.uk wrote: >>> This message starts a two week TSVWG Working Group on advancing: >>> >>> Title : Applicability Statement for the use of IPv6 > UDP >>> Datagrams with Zero Checksums >>> Author(s) : Godred Fairhurst >>> Magnus Westerlund >>> Filename : draft-ietf-6man-udpzero-08.txt >>> Pages : 37 >>> Date : 2012-12-11 >>> >>> https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ >>> >>> This document is intended to be published as BCP via the 6MAN WG. >>> >>> This last call is being done given the number of changes and the time >>> since the earlier last calls. The changes were discussed at the >>> Atlanta IETF 6man & TSVWG sessions. The authors believe these changes >>> will resolve the open IESG Discusses. Our AD will start a concurrent >>> IETF last call as well. >>> >>> Substantive comments and statements of support for advancing this >>> document should be directed to the tsvwg or 6man mailing list. >>> Editorial suggestions can be sent to the authors. This last call will >>> end on 26 December 2012. >>> >>> James, David & Gorry >>> TSVWG Co-Chairs. >>> >>> >>> >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> 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 lear@cisco.com Sat Jan 5 01:46:46 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9823F21F845E for ; Sat, 5 Jan 2013 01:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvjThPzGKztJ for ; Sat, 5 Jan 2013 01:46:45 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 58DC821F845A for ; Sat, 5 Jan 2013 01:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4160; q=dns/txt; s=iport; t=1357379205; x=1358588805; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mnlDfK2PpqMWWPmcpRcwpLEGSEJiqcE0FN0kx6gqYlg=; b=KUAatWSgJcD2kgc366cZasIihZPYRCycc35qC7J3wnwVAnVHj0mL9Kx4 KO24MuOoVi+M2SFdCJ55OU2JhABjb7fvKsTI81lQZHSWNXd1sEsB4eRKj nqcaVqYjL/XnHkXpDXcTLVnfVdV7pFEWttHn6s4fr/14Fjqa3V3PeN8rT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYHAAb251CQ/khR/2dsb2JhbABEDoM5gnKzUINPFnOCHgEBAQMBIw8BOA0BEAsYAgIFFgsCAgkDAgECAUUGDQEHAQGIDQalAY86gSKLMIMwgRMDkliDM5BJgjY/ X-IronPort-AV: E=Sophos;i="4.84,415,1355097600"; d="scan'208";a="79539121" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 05 Jan 2013 09:46:43 +0000 Received: from ams3-vpn-dhcp6552.cisco.com (ams3-vpn-dhcp6552.cisco.com [10.61.89.151]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r059khL6013015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2013 09:46:43 GMT Message-ID: <50E7F682.5030106@cisco.com> Date: Sat, 05 Jan 2013 10:46:42 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Joe Touch References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> <50E4ABA0.90007@isi.edu> In-Reply-To: <50E4ABA0.90007@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 09:46:46 -0000 Joe, I like your summary. I would be satisfied with (a) or (c) with the understanding that with regard to (c) the expert reviewer has the final choice as to what port to use – and not the applicant, and that the expert reviewer will use (a) as a guide unless there is very good reason to do otherwise. Yes, I'm hedging slightly, but I just don't want someone writing stupid code that says that new protocols in that space are somehow unauthorized in some way (avoid a 240/4 situation). You'd think that'd be difficult with a range that is half consumed, but I wouldn't underestimate some implementers... Eliot On 1/2/13 10:50 PM, Joe Touch wrote: > Hi, all, > > Any thoughts on this, given the context below? > > I'd like to have the input of others on this list before updating the > draft on this point. > > Thanks, > > Joe > > On 12/7/2012 11:08 AM, Joe Touch wrote: >> Hi, Bob, Eliot, et al., >> >> On 12/6/2012 9:40 PM, Eliot Lear wrote: >>> >>> On 12/7/12 12:56 AM, Bob Briscoe wrote: >>>> I don't see why ceasing to allocate system ports will help. It's not >>>> clear whether you are trying to remove the false sense of security >>>> that system ports purport to offer, or whether you are trying to >>>> remove the higher bar to IANA allocation, both, neither, or what. >>>> There's too little written in the draft, on the list and around the >>>> bullets in your presentation of the draft to guess fully what you're >>>> driving at. >>> >>> I support the notion of combining system and user for the simple reason >>> that there is no technical difference between the two, there is no >>> meaningful additional security offered by system. The distinction >>> dates >>> back to the notion that non-privileged users couldn't open a port below >>> 1024 and we knew all Internet hosts by name. >> >> This was discussed at several IETFs before this doc was accepted as a WG >> item, so I thought there was context. The doc does need expanding on >> this, and I will do so in the next revision. >> >> My view is that: >> >> - the distinction has evolved to become meaningless, and thus treating >> any port as more trusted because of its assigned range is a bad idea (as >> Eliot points out above). Yes, there are plenty of systems that do >> continue to treat the two ranges as different, but enough others that >> don't that it seems a bad idea to continue to support the difference as >> meaningful. >> >> Which is why I propose the following as an overall goal: >> >> The range 0...49151 will be known as Assigned ports. >> >> Port assignments will no longer distinguish between 'user', >> 'system', 'well-known', and 'registered' subranges of Assigned >> ports. >> >> If we do deprecate the difference between the ranges, we need to decide >> how to move forward. >> >> First, regardless of how we move forward, IMO: >> >> Assigned ports should use the procedures from RFC 2780 >> that apply to User ports. >> >> There are two ways forward, given that goal (in the order of my >> preference): >> >> a) this document can officially deprecate the distinction between User >> and System ports by declaring that IANA should cease further assignments >> from the System range >> >> b) this document can suggest that users should not bother requesting >> system ports >> >> c) this document can officially deprecate the distinction between User >> and System ports by merging the two and letting users pick any available >> port from the Assigned range >> >> Of these options, I think (c) creates a "land rush" in the System space, >> and we don't have enough understanding of the impact on legacy >> protocols. >> >> (a) is the safest, since it merely requires that new services be >> designed in a way that assumes that they could be run by any user on any >> system - which, these days, seems like a reasonable recommendation. >> >> (b) is a way to circumvent the issue without deprecating the User/System >> distinction, and IMO just continues to ignore the current situation >> >> Thoughts? >> >> Joe >> > > From bob.briscoe@bt.com Mon Jan 7 02:23:54 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB1E21F842F for ; Mon, 7 Jan 2013 02:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-MvTE9zuHI9 for ; Mon, 7 Jan 2013 02:23:54 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8B221F8841 for ; Mon, 7 Jan 2013 02:23:53 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 7 Jan 2013 10:23:48 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 7 Jan 2013 10:23:51 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.318.4; Mon, 7 Jan 2013 10:23:47 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r07ANkMD025310; Mon, 7 Jan 2013 10:23:46 GMT Message-ID: <201301071023.r07ANkMD025310@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 7 Jan 2013 10:23:49 +0000 To: Joe Touch , Eliot Lear From: Bob Briscoe In-Reply-To: <50E7F682.5030106@cisco.com> References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> <50E4ABA0.90007@isi.edu> <50E7F682.5030106@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 10:23:54 -0000 Joe, Tx for yr explanation. Previously the doc merely=20 stated option a), without saying why, and I read=20 all the discussion on the list going back to the=20 beginning and couldn't find any reason why. I guess avoiding a landrush might be a valid=20 concern - a bit like once most of the gold has=20 been found, removing all controls on prospecting=20 and trying to declare that gold is no longer a=20 precious metal. If gold really is no longer a=20 precious metal, it wouldn't matter. Similarly, given system ports aren't special,=20 opening up the allocation space shouldn't matter.=20 However, we all know people (and implementers ;) are irrational. Like Eliot, I have no strong pref betw a) and c). But b) is too weak. If we do choose a), we should consider a feasible=20 transition strategy at a later stage to allow the=20 unallocated ports 0-1023 to be allocated. Eg.=20 plan to open 0-1023 up for allocation after a=20 couple of years while ports are still plentiful,=20 rather than waiting until they become scarce,=20 which will just precipitate a bigger landrush at some later date. Bob At 09:46 05/01/2013, Eliot Lear wrote: >Joe, > >I like your summary. I would be satisfied with (a) or (c) with the >understanding that with regard to (c) the expert reviewer has the final >choice as to what port to use =AD and not the applicant, and that the >expert reviewer will use (a) as a guide unless there is very good reason >to do otherwise. Yes, I'm hedging slightly, but I just don't want >someone writing stupid code that says that new protocols in that space >are somehow unauthorized in some way (avoid a 240/4 situation). You'd >think that'd be difficult with a range that is half consumed, but I >wouldn't underestimate some implementers... > >Eliot > >On 1/2/13 10:50 PM, Joe Touch wrote: > > Hi, all, > > > > Any thoughts on this, given the context below? > > > > I'd like to have the input of others on this list before updating the > > draft on this point. > > > > Thanks, > > > > Joe > > > > On 12/7/2012 11:08 AM, Joe Touch wrote: > >> Hi, Bob, Eliot, et al., > >> > >> On 12/6/2012 9:40 PM, Eliot Lear wrote: > >>> > >>> On 12/7/12 12:56 AM, Bob Briscoe wrote: > >>>> I don't see why ceasing to allocate system ports will help. It's not > >>>> clear whether you are trying to remove the false sense of security > >>>> that system ports purport to offer, or whether you are trying to > >>>> remove the higher bar to IANA allocation, both, neither, or what. > >>>> There's too little written in the draft, on the list and around the > >>>> bullets in your presentation of the draft to guess fully what you're > >>>> driving at. > >>> > >>> I support the notion of combining system and user for the simple= reason > >>> that there is no technical difference between the two, there is no > >>> meaningful additional security offered by system. The distinction > >>> dates > >>> back to the notion that non-privileged users couldn't open a port= below > >>> 1024 and we knew all Internet hosts by name. > >> > >> This was discussed at several IETFs before this doc was accepted as a= WG > >> item, so I thought there was context. The doc does need expanding on > >> this, and I will do so in the next revision. > >> > >> My view is that: > >> > >> - the distinction has evolved to become meaningless, and thus treating > >> any port as more trusted because of its assigned range is a bad idea= (as > >> Eliot points out above). Yes, there are plenty of systems that do > >> continue to treat the two ranges as different, but enough others that > >> don't that it seems a bad idea to continue to support the difference as > >> meaningful. > >> > >> Which is why I propose the following as an overall goal: > >> > >> The range 0...49151 will be known as Assigned ports. > >> > >> Port assignments will no longer distinguish between 'user', > >> 'system', 'well-known', and 'registered' subranges of Assigned > >> ports. > >> > >> If we do deprecate the difference between the ranges, we need to decide > >> how to move forward. > >> > >> First, regardless of how we move forward, IMO: > >> > >> Assigned ports should use the procedures from RFC 2780 > >> that apply to User ports. > >> > >> There are two ways forward, given that goal (in the order of my > >> preference): > >> > >> a) this document can officially deprecate the distinction between User > >> and System ports by declaring that IANA should cease further= assignments > >> from the System range > >> > >> b) this document can suggest that users should not bother requesting > >> system ports > >> > >> c) this document can officially deprecate the distinction between User > >> and System ports by merging the two and letting users pick any= available > >> port from the Assigned range > >> > >> Of these options, I think (c) creates a "land rush" in the System= space, > >> and we don't have enough understanding of the impact on legacy > >> protocols. > >> > >> (a) is the safest, since it merely requires that new services be > >> designed in a way that assumes that they could be run by any user on= any > >> system - which, these days, seems like a reasonable recommendation. > >> > >> (b) is a way to circumvent the issue without deprecating the= User/System > >> distinction, and IMO just continues to ignore the current situation > >> > >> Thoughts? > >> > >> Joe > >> > > > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From iesg-secretary@ietf.org Tue Jan 8 07:00:14 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B7521F8B2E; Tue, 8 Jan 2013 07:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-IpHcYLd7IF; Tue, 8 Jan 2013 07:00:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747E821F8AC8; Tue, 8 Jan 2013 07:00:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130108150013.2429.48676.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 07:00:13 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] Last Call: (UDP Encapsulation of SCTP Packets) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:00:14 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'UDP Encapsulation of SCTP Packets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/ballot/ No IPR declarations have been submitted directly on this I-D. From fpb@tid.es Tue Jan 15 06:42:02 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1E921F86E3; Tue, 15 Jan 2013 06:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axytVbLmpdZa; Tue, 15 Jan 2013 06:42:01 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF8321F86D8; Tue, 15 Jan 2013 06:41:59 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MGO006K18TYNY@tid.hi.inet>; Tue, 15 Jan 2013 15:41:58 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id F1.C5.02896.6BA65F05; Tue, 15 Jan 2013 15:41:58 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MGO006JV8TXNY@tid.hi.inet>; Tue, 15 Jan 2013 15:41:58 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.151]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0328.009; Tue, 15 Jan 2013 15:38:54 +0100 Date: Tue, 15 Jan 2013 14:41:56 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: X-Originating-IP: [10.95.64.115] To: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= , "tcmtf@ietf.org" , "tsvwg@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zg+EiJe6cIWzHJQOTkKQag)" Content-language: en-US Accept-Language: en-US Thread-topic: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-index: AQHN8y4KB8ofXnBXW0Oy0IIeip1rIA== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7f636d000000b50-31-50f56ab64727 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsXCFe9nqLst62uAwZs/aha7Pm9gtDj25i6b A5PHkiU/mQIYo7hsUlJzMstSi/TtErgypvSZF3xOqZixsJe1gfF9eBcjJ4eEgInEnp1vWSBs MYkL99azdTFycQgJbGOUuNq3jx3CecooMatjBSuEM5NRYtX696wgLSwCqhK3Wt8wgthsAloS p++uAhslLFAg0fnhC1gNp4CLROvuT8wQKxQk/px7zAIySESgk1GiYdJZsGZeAW+JKb/6oGxB iR+T74ENYhbIlbh3ZS8zhC0u0dx6EyzOCHTr91NrmEBsEYFCifstc4Hu5gCy9SSenI8BCYsC mW3HzrBD7BWQWLLnPNQNohIvH/9jncAoOgvJtllIts1Csg3C1pN4dmoWlK0tsWzha6gaXYlL D9exQthmEm9+TGNHVrOAkWMVo1hxUlFmekZJbmJmTrqBkV5Gpl5mXmrJJkZIBGbuYFy+U+UQ owAHoxIP74GznwOEWBPLiitzDzFKcjApifIWpn8NEOJLyk+pzEgszogvKs1JLT7EKMHBrCTC q2EElONNSaysSi3Kh0nJcHAoSfAKAJOFkGBRanpqRVpmDjDNwKSZODhB2nmA2kVAaniLCxJz izPTIfKnGFU59j9pf84oxJKXn5cqJc67OhOoSACkKKM0D27OK0ZxoIOFea1BRvAAEyXchFdA w5mAhm/a+xlkeEkiQkqqgXF7+9aPn6fXlTjIR76QW6WfEPdSoDHrauCvFFPm7jAZtl/f215d 8eDMeDyvqdwxKfzjYcbFz4+vF5vCln82KSA2jGE2V8MCv5BJksUvswV49Xry5u2oeNn4SH3R dW2vJ42X+SY/3SZgvkz0+6vk56qNga+MmbxVgpq9z+4r0d2ReKe42vzaFCWW4oxEQy3mouJE AEnK+cpRAwAA Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:42:02 -0000 --Boundary_(ID_zg+EiJe6cIWzHJQOTkKQag) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: quoted-printable Hi Mirko, Some comments to the draft: * In the introduction it says "TCTMF", it is "TCMTF". * I do not understand the sentence "Therefore, we neither take into acc= ount services using an approach in which all the calculations are deployed = in the server, which sends a real-time video stream to the client." in sect= ion 3. * In section 3 (Considered Services), I think it could be also interest= ing to consider non-real time services candidates to be TCMTF optimized. Fo= r example services like instant messaging, where the bandwidth saving is th= e main benefit of the TCMTF optimization, should be somehow mentioned, esta= blishing a kind of delay upper threshold. Related to that, in section 3, wh= en talking about web browsing, the sentence "there is no need for policy li= mitations in TCMTF" could be disappointed, because actually there are limit= ations (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 sec= onds are considered for streaming audio). * In section 4, I would change the sentence "A number of flows are mult= iplexed together before being sent through the Internet." for "A number of = flows are multiplexed together before being sent through the network.", bec= ause the network could not be necessary the Internet, I would also adapt Fi= gure 2. * Maybe the creation of a section 4.4 talking about non real time servi= ces could be considered including last comments (acceptable with the recomm= endation appearing in the last sentence of the section 4.3 "It should be no= ted that multiplexing periods of about 1 second can be considered as enough= for non real time services (e.g., web browsing and streaming audio).") * Table 1 could be included in a separate section (i.e. Section 4.5) as= a summary Hope to help! Regards, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es From: Mirko Su=BEnjevi=E6 > Date: jueves, 13 de diciembre de 2012 10:06 To: "tcmtf@ietf.org" >, "tsvwg@ietf.org" > Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compr= essed Multiplexed Traffic Flows Hello, We have just submitted the draft named Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows: http://datatracker.ietf.org= /doc/draft-suznjevic-tsvwg-mtd-tcmtf/ It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-t= svwg-tcmtf/. Since a specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss it there. The draft contains recommendations for TCMTF multiplexing period for differ= ent real-time services. In order to prevent QoE degradation of real-time se= rvices using TCMTF, a policy defining a multiplexing period can be employe= d. Values of maximum tolerable delays presented in the draft form the base = of such policy. The recommendations are presented for real-time network = services in which TCTMF bandwidth optimization is applicable (i.e., service= s which have low payload to header size ratio which results in high protoc= ol overhead). Your feedback will be welcome. Thank you. Sincerely, Mirko Suznjevic ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_zg+EiJe6cIWzHJQOTkKQag) Content-id: <9DD849C7D95A9040B5FC477442A7E6E2@hi.inet> Content-type: text/html; charset=iso-8859-2 Content-transfer-encoding: quoted-printable
Hi Mirko,

Some c= omments to the draft:
  • In the introduction it says "TCTMF", it is "TCMTF".=
  • I do not understand the sentence= "Therefore, we <= font face=3D"Calibri,sans-serif">neither take into account services using an approach in which all the calculations are deployed in the server, which sends a real= -time video stre= am to the client." in section 3.
  • In section 3 (Consider= ed Services), I think it could be also interesting to consider non-real tim= e services candidates to be TCMTF optimized. For example services like inst= ant messaging, where the bandwidth saving is the main benefit of the TCMTF optimization, = should be somehow mentioned, establishing a kind of delay upper threshold. = Related to that, in section 3, when talki= ng about web browsing, the sentence "there is no need for policy <= /font>limitations in TCMTF" c= ould be disappointed, because actually there are limitations (ITU-T_G.= 1010, 10 seconds for web browsing, as in section 4.1 10 seconds are considered for streaming audio).
  • In section 4, I would change the sentence "= A number of flows are multiplexed together before being sent through the Internet." for "A number of flows are multiplexed together before being sent throug= h the network.", because the network could not be necessary the Internet, I would also adapt Figure 2.
  • Maybe the creation of a = section 4.4 talking about non real time services could be considered includ= ing last comments (acceptable with the recommendation appearing in the last sentence of the = section 4.3 "It should be not= ed that multiplexing periods = of about 1 second can be considered as enough for non real time services (e.g., web browsing and streaming <= span style=3D"font-family:Calibri,sans-serif">audio).")
    • Table 1 could be included in a separate = section (i.e. Section 4.5) as a summary
Hope to help!

Regards,

Fernando Pascual Blanco
Telef=F3nica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168

From: Mirko Su=BEnjevi=E6 <Mirko.Suznjevic@fer.hr>
Date: jueves, 13 de diciembre de 20= 12 10:06
To: "tcmtf@ietf.org" <tcm= tf@ietf.org>, "tsvwg@ietf.org= " <tsvwg@ietf.org>
Subject: [tcmtf] Draft: Maximum Tol= erable Delays when using Tunneling Compressed Multiplexed Traffic Flows

Hello,

 

We have just submitted the draf= t named Maximum Tolerable Delays when using Tunneling Compressed Multiplexe= d Traffic Flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a spe= cific list for tcmtf exists (tcmtf@ietf.o= rg), the idea is to discuss it there.

 

The draft contains recommendati= ons for TCMTF multiplexing period for different real-time services. In orde= r to prevent QoE degradation of real-time services using TCMTF, a policy de= fining  a multiplexing period can be employed. Values of maximum tolerable delays presented in the draft form t= he base of such policy.    The recommendations are presented= for real-time network services in which TCTMF bandwidth optimization is ap= plicable (i.e., services  which have low payload to header size ratio which results in high protocol overhead).

 

Your feedback will be welcome. = Thank you.


Sincerely,

Mirko Suznjevic



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_zg+EiJe6cIWzHJQOTkKQag)-- From Mirko.Suznjevic@fer.hr Tue Jan 15 07:49:23 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6D121F871C; Tue, 15 Jan 2013 07:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJvU1JyYj4cl; Tue, 15 Jan 2013 07:49:19 -0800 (PST) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A421F8510; Tue, 15 Jan 2013 07:49:17 -0800 (PST) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.318.4; Tue, 15 Jan 2013 16:49:15 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jan 2013 16:49:00 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDF337.D5BC6F98" Date: Tue, 15 Jan 2013 16:48:59 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-Index: AQHN8y4KB8ofXnBXW0Oy0IIeip1rIJhKgzjA References: From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: FERNANDO PASCUAL BLANCO , , X-OriginalArrivalTime: 15 Jan 2013 15:49:00.0134 (UTC) FILETIME=[D5EB7060:01CDF337] Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:49:23 -0000 ------_=_NextPart_001_01CDF337.D5BC6F98 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, Thanks for all the comments, I will briefly respond to them, and include = your (as well as previous) corrections in a new version of the draft: * I do not understand the sentence "Therefore, we neither take into = account services using an approach in which all the calculations are = deployed in the server, which sends a real-time video stream to the = client." in section 3. The meaning of this sentence is that we will not be looking at the cloud = based gaming services such as OnLive or Gaiki as they are focused on = performing all needed calculations of the gamestate on the server, and = sending a very "fat" video stream to the client which only renders the = video. Therefore they are not suitable for tcmtf. I will change that in = order to be more clear. * In section 3 (Considered Services), I think it could be also = interesting to consider non-real time services candidates to be TCMTF = optimized. For example services like instant messaging, where the = bandwidth saving is the main benefit of the TCMTF optimization, should = be somehow mentioned, establishing a kind of delay upper threshold. = Related to that, in section 3, when talking about web browsing, the = sentence "there is no need for policy limitations in TCMTF" could be = disappointed, because actually there are limitations (ITU-T_G.1010, 10 = seconds for web browsing, as in section 4.1 10 seconds are considered = for streaming audio). At first when we were discussing we decided that it will be focused on = real-time services, but this can be broadened to others non-real-time. I = think giving such upper limits has a point, although would we even = employ tcmtf in cases in which we will not have enough data to send a = packet in 5 or more seconds? Is that feasible? Maybe in some sensor = networks? Maybe I am just looking it the wrong way, maybe we would have = a lot of traffic that needs to be packed ASAP! * In section 4, I would change the sentence "A number of flows are = multiplexed together before being sent through the Internet." for "A = number of flows are multiplexed together before being sent through the = network.", because the network could not be necessary the Internet, I = would also adapt Figure 2. Ok will be done. * Maybe the creation of a section 4.4 talking about non real time = services could be considered including last comments (acceptable with = the recommendation appearing in the last sentence of the section 4.3 "It = should be noted that multiplexing periods of about 1 second can be = considered as enough for non real time services (e.g., web browsing and = streaming audio).") Ok, seems sound enough. I will write it and see which format looks = better. * Table 1 could be included in a separate section (i.e. Section 4.5) as = a summary Ok. =20 Thanks again for the feedback! Cheers! Mirko =20 From: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]=20 Sent: Tuesday, January 15, 2013 3:42 PM To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; tsvwg@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows =20 Hi Mirko, =20 Some comments to the draft: * In the introduction it says "TCTMF", it is "TCMTF". * I do not understand the sentence "Therefore, we neither take into = account services using an approach in which all the calculations are = deployed in the server, which sends a real-time video stream to the = client." in section 3. * In section 3 (Considered Services), I think it could be also = interesting to consider non-real time services candidates to be TCMTF = optimized. For example services like instant messaging, where the = bandwidth saving is the main benefit of the TCMTF optimization, should = be somehow mentioned, establishing a kind of delay upper threshold. = Related to that, in section 3, when talking about web browsing, the = sentence "there is no need for policy limitations in TCMTF" could be = disappointed, because actually there are limitations (ITU-T_G.1010, 10 = seconds for web browsing, as in section 4.1 10 seconds are considered = for streaming audio). * In section 4, I would change the sentence "A number of flows are = multiplexed together before being sent through the Internet." for "A = number of flows are multiplexed together before being sent through the = network.", because the network could not be necessary the Internet, I = would also adapt Figure 2. * Maybe the creation of a section 4.4 talking about non real time = services could be considered including last comments (acceptable with = the recommendation appearing in the last sentence of the section 4.3 "It = should be noted that multiplexing periods of about 1 second can be = considered as enough for non real time services (e.g., web browsing and = streaming audio).") * Table 1 could be included in a separate section (i.e. Section 4.5) as = a summary Hope to help! =20 Regards, =20 Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es =20 From: Mirko Su=BEnjevi=E6 Date: jueves, 13 de diciembre de 2012 10:06 To: "tcmtf@ietf.org" , "tsvwg@ietf.org" Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling = Compressed Multiplexed Traffic Flows =20 Hello, =20 We have just submitted the draft named Maximum Tolerable Delays when = using Tunneling Compressed Multiplexed Traffic Flows: = http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ =20 It is an extension of tcmtf = http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a = specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss = it there. =20 The draft contains recommendations for TCMTF multiplexing period for = different real-time services. In order to prevent QoE degradation of = real-time services using TCMTF, a policy defining a multiplexing period = can be employed. Values of maximum tolerable delays presented in the = draft form the base of such policy. The recommendations are presented = for real-time network services in which TCTMF bandwidth optimization is = applicable (i.e., services which have low payload to header size ratio = which results in high protocol overhead). =20 Your feedback will be welcome. Thank you. Sincerely, Mirko Suznjevic =20 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ------_=_NextPart_001_01CDF337.D5BC6F98 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

Thanks for = all the comments, I will briefly respond to them, and include your (as = well as previous) corrections in a new version of the = draft:

  • I = do not understand the sentence "Therefore, we neither take = into account services using an approach in which all = the calculations are deployed in the server, which sends a = real-time video stream to the client." in section = 3.

The meaning of this sentence is = that we will not be looking at the cloud based gaming services such as = OnLive or Gaiki as they are focused on performing all needed = calculations of the gamestate on the server, and sending a very = “fat” video stream to the client which only renders the = video. Therefore they are not suitable for tcmtf. I will change that in = order to be more clear.

  • In = section 3 (Considered Services), I think it could be also interesting to = consider non-real time services candidates to be TCMTF optimized. For = example services like instant messaging, where the bandwidth saving is = the main benefit of the TCMTF optimization, should be somehow mentioned, = establishing a kind of delay upper threshold. Related to that, in = section 3, when talking about web browsing, the sentence "there is = no need for policy limitations in TCMTF" could = be disappointed, because actually there are limitations = (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 = seconds are considered for streaming = audio).

At first when we were discussing we = decided that it will be focused on real-time services, but this can be = broadened to others non-real-time. I think giving such upper limits has = a point, although would we even employ tcmtf in cases =A0in which we = will not have enough data to send a packet in 5 or more seconds? Is that = feasible? Maybe in some sensor networks? Maybe I am just looking it the = wrong way, maybe we would have a lot of traffic that needs to be packed = ASAP!

  • In = section 4, I would change the sentence "A number of flows are = multiplexed together before being sent through the Internet." = for "A number of flows are multiplexed together before being = sent through the network.", because the network could not be = necessary the Internet, I would also adapt Figure = 2.

Ok will be done.

  • Maybe the creation of a section = 4.4 talking about non real time services could be considered including = last comments (acceptable with the recommendation appearing in the last = sentence of the section 4.3 "It should be = noted that multiplexing periods of about 1 second can be considered = as enough for non real time services (e.g., web browsing and = streaming audio).")

Ok, seems sound enough. I will = write it and see which format looks better.

  • Table 1 could be included in a separate = section (i.e. Section 4.5) as a = summary

Ok.

 

Thanks = again for the feedback!

Cheers!
Mirko

 

From:= FERNANDO = PASCUAL BLANCO [mailto:fpb@tid.es]
Sent: Tuesday, January 15, = 2013 3:42 PM
To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; = tsvwg@ietf.org
Subject: Re: [tcmtf] Draft: Maximum Tolerable = Delays when using Tunneling Compressed Multiplexed Traffic = Flows

 

Hi = Mirko,

 

=

Some comments to the = draft:

  • In = the introduction it says "TCTMF", it is = "TCMTF".
  • I = do not understand the sentence "Therefore, we neither take = into account services using an approach in which all = the calculations are deployed in the server, which sends a = real-time video stream to the client." in section = 3.
  • In = section 3 (Considered Services), I think it could be also interesting to = consider non-real time services candidates to be TCMTF optimized. For = example services like instant messaging, where the bandwidth saving is = the main benefit of the TCMTF optimization, should be somehow mentioned, = establishing a kind of delay upper threshold. Related to that, in = section 3, when talking about web browsing, the sentence "there is = no need for policy limitations in TCMTF" could = be disappointed, because actually there are limitations = (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 = seconds are considered for streaming audio).
  • In = section 4, I would change the sentence "A number of flows are = multiplexed together before being sent through the Internet." = for "A number of flows are multiplexed together before being = sent through the network.", because the network could not be = necessary the Internet, I would also adapt Figure = 2.
  • Maybe the creation of a section = 4.4 talking about non real time services could be considered including = last comments (acceptable with the recommendation appearing in the last = sentence of the section 4.3 "It should be = noted that multiplexing periods of about 1 second can be considered = as enough for non real time services (e.g., web browsing and = streaming audio).")
  • Table 1 could be included in a separate = section (i.e. Section 4.5) as a = summary

Hope to help!

 

=

Regards,

 

=

Fernando Pascual = Blanco

Telef=F3nica Global = Resources

Network Automation = and Dynamization

TECHNOLOGY PEOPLE = GROUP

F = +34913128779

M = +34682005168

 

=

From: Mirko Su=BEnjevi=E6 <Mirko.Suznjevic@fer.hr>
= Date: jueves, 13 de diciembre de 2012 10:06
To: = "tcmtf@ietf.org" = <tcmtf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: = [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling = Compressed Multiplexed Traffic Flows

 

=

Hello,

 

We have just = submitted the draft named Maximum Tolerable Delays when using Tunneling = Compressed Multiplexed Traffic Flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

It is an = extension of tcmtf http:= //datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a = specific list for tcmtf exists (tcmtf@ietf.org), the idea is to = discuss it there.

 

The draft = contains recommendations for TCMTF multiplexing period for different = real-time services. In order to prevent QoE degradation of real-time = services using TCMTF, a policy defining  a multiplexing period can = be employed. Values of maximum tolerable delays presented in the draft = form the base of such policy.    The recommendations are = presented for real-time network services in which TCTMF bandwidth = optimization is applicable (i.e., services  which have low payload = to header size ratio which results in high protocol = overhead).

 

Your feedback = will be welcome. Thank you.


Sincerely,

Mirko = Suznjevic

 

Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo.
This message is = intended exclusively for its addressee. We only send and receive email = on the basis of the terms set out at:
http://www.tid.es/E= S/PAGINAS/disclaimer.aspx

------_=_NextPart_001_01CDF337.D5BC6F98-- From fpb@tid.es Thu Jan 17 01:07:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B01C21F88A5; Thu, 17 Jan 2013 01:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X36FUFS-BsF; Thu, 17 Jan 2013 01:07:37 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id B556221F8839; Thu, 17 Jan 2013 01:07:33 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MGR008PIIODEV@tid.hi.inet>; Thu, 17 Jan 2013 10:07:32 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id AA.DA.02896.35FB7F05; Thu, 17 Jan 2013 10:07:31 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MGR008Q0IOJEV@tid.hi.inet>; Thu, 17 Jan 2013 10:07:31 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([fe80::e1e3:e2fc:beda:deb9%15]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 10:04:22 +0100 Date: Thu, 17 Jan 2013 09:07:30 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: X-Originating-IP: [10.95.64.115] To: =?windows-1250?Q?Mirko_Su=9Enjevi=E6?= , "tcmtf@ietf.org" , "tsvwg@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lPGdM2ySRFqk6KCoeI6IZw)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-index: AQHN9JGjt/1wmNKQnUulDvKsi7PhJg== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7f636d000000b50-de-50f7bf5387ae X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGKsWRmVeSWpSXmKPExsXCFe9nqBu8/3uAwbKpCha7Pm9gtDj25i6b A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyrt+cwVSw9xFjRcuDRSwNjJcPMXYxcnJICJhI3G+7 zgxhi0lcuLeerYuRi0NIYBujxPwNE6Ccp4wSb9tBqkCcTYwSs859ZQFpYRFQldhwYi1YO5uA lsTpu6vA4sICBRKdH76wgticAi4Sd199h1qnIPHn3GMWkEEiAt2MEk3vFoAV8Qp4S7zuegll C0r8mHwPbBCzQK7E2jmHmCFscYnm1ptgcUYBWYl38+eD1YsIFErcb5nLBmHrSfzZux3MFgWy 246dYYdYLCCxZM95qD9FJV4+/sc6gVF0FpJ1s5Csm4Vk3SxGDiDbQOLRPm+IsLbEsoWvmSHC +hK3r2VChM0kelrusyArWcDIsYpRrDipKDM9oyQ3MTMn3cBILyNTLzMvtWQTIyQKM3cwLt+p cohRgINRiYf3wNnPAUKsiWXFlbmHGCU5mJREeT/v+R4gxJeUn1KZkVicEV9UmpNafIhRgoNZ SYRXZR9QjjclsbIqtSgfJiXDwaEkwcsCkhIsSk1PrUjLzAGmGpg0EwcnSDsPUHvKXpD24oLE 3OLMdIj8KUZtjv1P2p8zcsyY2POcUYglLz8vVUqc9xJIqQBIaUZpHty0V4ziQGcL8x4AyfIA EyfcnFdAK5iAVmza+xlkRUkiQkqqgXHXjh7Hr33Vfy6YmPqHLI/JrHVQvt0vsE215+CiHyJ/ I1erFO/1+f5/TuHEQv2Mmu6/GpXiE/pPlJxKPqQaeuWw35KTptJm/YFv7B6HKbfmmq3arVDd 6+qmeMruhteFXN8Nva0pksYXYjZdN43bc6lNWsrmslZ3yPVrO8NVDP6zlS/48XHSaSWW4oxE Qy3mouJEAABrbtJZAwAA Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 09:07:39 -0000 --Boundary_(ID_lPGdM2ySRFqk6KCoeI6IZw) Content-type: text/plain; charset=windows-1250 Content-transfer-encoding: quoted-printable Hi Mirko, Thank you for considering that. In addition, one more thing: in section 4, = the sentence "If a policy defining a multiplexing period is used, then the = average latency added to each packet will be half the multiplexing period."= only applies when there is not enough packet rate to fulfill a big packet = by multiplexing small ones. When there is a lot of packets to multiplex, i= n general, multiplexing period will not be reached, so half the multiplexin= g period will be the maximum/worse average added delay. In general, and whe= n TCMTF is working fine, average added delay will be lower. So, I would rewrite that phrase as: "If a policy defining a multiplexing pe= riod is used, then the average latency added to each packet will be half th= e time to fulfill a multiplexed one. In the worse case and if the multiplex= ing period is reached, the average latency added to each packet will be hal= f the multiplexing period". What do you think? Regards, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es From: Mirko Su=9Enjevi=E6 > Date: martes, 15 de enero de 2013 16:48 To: Fernando Pascual Blanco >, "tcmtf@ietf.or= g" >, "tsvwg@i= etf.org" > Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling C= ompressed Multiplexed Traffic Flows Hello, Thanks for all the comments, I will briefly respond to them, and include yo= ur (as well as previous) corrections in a new version of the draft: * I do not understand the sentence "Therefore, we neither take into acc= ount services using an approach in which all the calculations are deployed = in the server, which sends a real-time video stream to the client." in sect= ion 3. The meaning of this sentence is that we will not be looking at the cloud ba= sed gaming services such as OnLive or Gaiki as they are focused on performi= ng all needed calculations of the gamestate on the server, and sending a ve= ry =93fat=94 video stream to the client which only renders the video. There= fore they are not suitable for tcmtf. I will change that in order to be mor= e clear. * In section 3 (Considered Services), I think it could be also interest= ing to consider non-real time services candidates to be TCMTF optimized. Fo= r example services like instant messaging, where the bandwidth saving is th= e main benefit of the TCMTF optimization, should be somehow mentioned, esta= blishing a kind of delay upper threshold. Related to that, in section 3, wh= en talking about web browsing, the sentence "there is no need for policy li= mitations in TCMTF" could be disappointed, because actually there are limit= ations (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 sec= onds are considered for streaming audio). At first when we were discussing we decided that it will be focused on real= -time services, but this can be broadened to others non-real-time. I think = giving such upper limits has a point, although would we even employ tcmtf i= n cases in which we will not have enough data to send a packet in 5 or mor= e seconds? Is that feasible? Maybe in some sensor networks? Maybe I am just= looking it the wrong way, maybe we would have a lot of traffic that needs = to be packed ASAP! * In section 4, I would change the sentence "A number of flows are mult= iplexed together before being sent through the Internet." for "A number of = flows are multiplexed together before being sent through the network.", bec= ause the network could not be necessary the Internet, I would also adapt Fi= gure 2. Ok will be done. * Maybe the creation of a section 4.4 talking about non real time servi= ces could be considered including last comments (acceptable with the recomm= endation appearing in the last sentence of the section 4.3 "It should be no= ted that multiplexing periods of about 1 second can be considered as enough= for non real time services (e.g., web browsing and streaming audio).") Ok, seems sound enough. I will write it and see which format looks better. * Table 1 could be included in a separate section (i.e. Section 4.5) as= a summary Ok. Thanks again for the feedback! Cheers! Mirko From: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es] Sent: Tuesday, January 15, 2013 3:42 PM To: Mirko Su=9Enjevi=E6; tcmtf@ietf.org; tsvwg@ietf.= org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling C= ompressed Multiplexed Traffic Flows Hi Mirko, Some comments to the draft: * In the introduction it says "TCTMF", it is "TCMTF". * I do not understand the sentence "Therefore, we neither take into acc= ount services using an approach in which all the calculations are deployed = in the server, which sends a real-time video stream to the client." in sect= ion 3. * In section 3 (Considered Services), I think it could be also interest= ing to consider non-real time services candidates to be TCMTF optimized. Fo= r example services like instant messaging, where the bandwidth saving is th= e main benefit of the TCMTF optimization, should be somehow mentioned, esta= blishing a kind of delay upper threshold. Related to that, in section 3, wh= en talking about web browsing, the sentence "there is no need for policy li= mitations in TCMTF" could be disappointed, because actually there are limit= ations (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 sec= onds are considered for streaming audio). * In section 4, I would change the sentence "A number of flows are mult= iplexed together before being sent through the Internet." for "A number of = flows are multiplexed together before being sent through the network.", bec= ause the network could not be necessary the Internet, I would also adapt Fi= gure 2. * Maybe the creation of a section 4.4 talking about non real time servi= ces could be considered including last comments (acceptable with the recomm= endation appearing in the last sentence of the section 4.3 "It should be no= ted that multiplexing periods of about 1 second can be considered as enough= for non real time services (e.g., web browsing and streaming audio).") * Table 1 could be included in a separate section (i.e. Section 4.5) as= a summary Hope to help! Regards, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es From: Mirko Su=9Enjevi=E6 > Date: jueves, 13 de diciembre de 2012 10:06 To: "tcmtf@ietf.org" >, "tsvwg@ietf.org" > Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compr= essed Multiplexed Traffic Flows Hello, We have just submitted the draft named Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows: http://datatracker.ietf.org= /doc/draft-suznjevic-tsvwg-mtd-tcmtf/ It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-t= svwg-tcmtf/. Since a specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss it there. The draft contains recommendations for TCMTF multiplexing period for differ= ent real-time services. In order to prevent QoE degradation of real-time se= rvices using TCMTF, a policy defining a multiplexing period can be employe= d. Values of maximum tolerable delays presented in the draft form the base = of such policy. The recommendations are presented for real-time network = services in which TCTMF bandwidth optimization is applicable (i.e., service= s which have low payload to header size ratio which results in high protoc= ol overhead). Your feedback will be welcome. Thank you. Sincerely, Mirko Suznjevic ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_lPGdM2ySRFqk6KCoeI6IZw) Content-id: <625E98CBDF52724AB52B80C1DFA280AC@hi.inet> Content-type: text/html; charset=windows-1250 Content-transfer-encoding: quoted-printable
Hi Mirko,

Thank = you for considering that. In addition, one more thing: in section 4, the se= ntence "If a policy defining a multiplexing period is used, then the a= verage latency added to each packet will be half the multiplexing period." only applies when there is not enou= gh packet rate to fulfill a big packet by multiplexing small ones. When &nb= sp;there is a lot of packets to multiplex, in general, multiplexing period = will not be reached, so half the multiplexing period will be the maximum/worse average added delay. In general, and when= TCMTF is working fine, average added delay will be lower.
So, I = would rewrite that phrase as: "If a policy defining a multiplexing per= iod is used, then the average latency added to each packet will be hal= f the time to fulfill a multiplexed one. In the worse case and if the multiplexing period is reached, the average latency = added to each packet will be half the multiplexing period".

What d= o you think?

Regards,

Fernando Pascual Blanco
Telef=F3nica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
fpb@tid.es

From: Mirko Su=9Enjevi=E6 <Mirko.Suznjevic@fer.hr>
Date: martes, 15 de enero de 2013 1= 6:48
To: Fernando Pascual Blanco <fpb@tid.es>, "tcmtf@ietf.org" <= tcmtf@ietf.org>, "tsvwg@ietf.= org" <tsvwg@ietf.org>
Subject: Re: [tcmtf] Draft: Maximum= Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows=

Hello,<= /span>

Thanks = for all the comments, I will briefly respond to them, and include your (as = well as previous) corrections in a new version of the draft:

  • I do not understand the sentence "Therefore, we&nbs= p;neither take into account services using an approach in which all the&nbs= p;calculations are deployed in the server, which sends a real-time video stream to the client." in section 3.

The meaning of this sentence is that we will not be looking at the clou= d based gaming services such as OnLive or Gaiki as they are focused on perf= orming all needed calculations of the gamestate on the server, and sending a very =93fat=94 video stream to the client whi= ch only renders the video. Therefore they are not suitable for tcmtf. I wil= l change that in order to be more clear.

  • In section 3 (Considered Services), I think it could be = also interesting to consider non-real time services candidates to be TCMTF = optimized. For example services like instant messaging, where the bandwidth saving is the main benefit of the TCMTF opt= imization, should be somehow mentioned, establishing a kind of delay upper = threshold. Related to that, in section 3, when talking about web browsing, = the sentence "there is no need for policy limitations in TCMTF" could be disappointed, because= actually there are limitations (ITU-T_G.1010, 10 seconds for web brow= sing, as in section 4.1 10 seconds are considered for streaming audio).

At first when we were discussing we decided that it will be focused on = real-time services, but this can be broadened to others non-real-time. I th= ink giving such upper limits has a point, although would we even employ tcmtf in cases  in which we will not ha= ve enough data to send a packet in 5 or more seconds? Is that feasible? May= be in some sensor networks? Maybe I am just looking it the wrong way, maybe= we would have a lot of traffic that needs to be packed ASAP!

  • In section 4, I would change the sentence "A number= of flows are multiplexed together before being sent through the Inter= net." for "A number of flows are multiplexed together before being sent through the network.", because the network could no= t be necessary the Internet, I would also adapt Figure 2.

Ok will be done.

  • Maybe the creation of a section 4.4 talking about non = real time services could be considered including last comments (acceptable = with the recommendation appearing in the last sentence of the section 4.3 "It shou= ld be noted that multiplexing periods of about 1 second can be conside= red as enough for non real time services (e.g., web browsing and strea= ming audio).")

Ok, seems sound enough. I will write it and see which format looks bett= er.

  • Table 1 could be in= cluded in a separate section (i.e. Section 4.5) as a summary

Ok.

 <= /span>

Thanks = again for the feedback!

Cheers!=
Mirko

 <= /span>

From: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]
Sent: Tuesday, January 15, 2013 3:42 PM
To: Mirko Su=9Enjevi=E6; tcmtf@iet= f.org; tsvwg@ietf.org
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunn= eling Compressed Multiplexed Traffic Flows

 

Hi Mirko,

 

Some comments to the draft:

  • In the introduction it says "TCTMF", it is &qu= ot;TCMTF".
  • I do not understand the sente= nce "Therefore, we neither take into account services using an ap= proach in which all the calculations are deployed in the server, which= sends a real-time video stream to the client." in section 3.
  • In section 3 (Considered Services), I think it could = be also interesting to consider non-real time services candidates to be TCM= TF optimized. For example services like instant messaging, where the bandwidth saving is the main benefit of the TCMTF opt= imization, should be somehow mentioned, establishing a kind of delay upper = threshold. Related to that, in section 3, when talking about web browsing, = the sentence "there is no need for policy limitations in TCMTF" could be disappointed, because= actually there are limitations (ITU-T_G.1010, 10 seconds for web brow= sing, as in section 4.1 10 seconds are considered for streaming audio).
  • In section 4, I would change the sentence "= A number of flows are multiplexed together before being sent through t= he Internet." for "A number of flows are multiplexed togethe= r before being sent through the network.", because the network could no= t be necessary the Internet, I would also adapt Figure 2.
  • Maybe the creation of a section 4.4 talking about non real t= ime services could be considered including last comments (acceptable with t= he recommendation appearing in the last sentence of the section 4.3 "It shou= ld be noted that multiplexing periods of about 1 second can be conside= red as enough for non real time services (e.g., web browsing and strea= ming audio).")
  • Table 1 could be included in a separate sec= tion (i.e. Section 4.5) as a summary

Hope to help!

 

Regards,

 

Fernando Pascual Blanco

Telef=F3nica Global Resources

Network Automation and Dynamization

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

 

From: = Mirko Su=9Enjevi=E6 &= lt;Mirko.Suznjevic@fer.hr>=
Date: jueves, 13 de diciembre de 2012 10:06
To: "tcmtf@ietf.org"= <tcmtf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunnelin= g Compressed Multiplexed Traffic Flows

 

Hello,

 

We have j= ust submitted the draft named Maximum Tolerable Delays when using Tunneling= Compressed Multiplexed Traffic Flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

It is an = extension of tcmtf 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 recommendations for TCMTF multiplexing period for different real-= time services. In order to prevent QoE degradation of real-time services us= ing TCMTF, a policy defining  a multiplexing period can be employed. Values of maximum tolerable delays presented in th= e draft form the base of such policy.    The recommendations= are presented for real-time network services in which TCTMF bandwidth opti= mization is applicable (i.e., services  which have low payload to header size ratio which results in high protocol overhead).=

 

Your feed= back will be welcome. Thank you.


Sincerely,

Mirko Suz= njevic

 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/= ES/PAGINAS/disclaimer.aspx



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_lPGdM2ySRFqk6KCoeI6IZw)-- From magnus.westerlund@ericsson.com Thu Jan 17 03:00:18 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDED921F8B36 for ; Thu, 17 Jan 2013 03:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.044 X-Spam-Level: X-Spam-Status: No, score=-106.044 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW7D9DzW9zv4 for ; Thu, 17 Jan 2013 03:00:17 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAB721F86B3 for ; Thu, 17 Jan 2013 03:00:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-6d-50f7d9b9c7f7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.D6.10459.9B9D7F05; Thu, 17 Jan 2013 12:00:09 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 17 Jan 2013 12:00:09 +0100 Message-ID: <50F7D9B8.7030604@ericsson.com> Date: Thu, 17 Jan 2013 12:00:08 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: jsaldana@unizar.es References: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> <50C99DC8.7060505@ericsson.com> <00dc01cdda12$5cb82190$162864b0$@unizar.es> In-Reply-To: <00dc01cdda12$5cb82190$162864b0$@unizar.es> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje7Om98DDJa1Glm8bpvNaLHlmJ7F sTd32RyYPXo+v2DyWLLkJ5PHsqtHmAOYo7hsUlJzMstSi/TtErgyZr89z1xwwaji0r/UBsZu jS5GTg4JAROJ03u+skPYYhIX7q1n62Lk4hASOMko8X/lQlYIZzmjROeMO4wgVbwC2hLzf05n A7FZBFQlfh1eDmazCVhI3PzRCGaLCgRLbDi4igmiXlDi5MwnLCC2CNCGfx+mgNnMAhoS52e0 MoPYwgLeEp1z7rNALJvGKLHkdzNYESfQ0JZL+4AWcwCdJy6x5g0HRK+exJSrLYwQtrxE89bZ YHOEgG5raOpgncAoNAvJ6llIWmYhaVnAyLyKkT03MTMnvdxwEyMweA9u+a27g/HUOZFDjNIc LErivGGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MJaFyLxYdL7t7pUKyQU5vsY//u+d YVthqfFa6H3F+59+ZcbNO0QqYwNfLo5edbZ6UyI/y+m1wbmM/m//f5ssWbuAU+1PwplT65ok teQXx5yaWND4glNV/KiXZErxkVmXFOYqiS5K2H3y9u9TF3oWLZxeEpkXIfz67acTpzz21uZ4 a/Z0ScnphimxFGckGmoxFxUnAgDFfVp1LAIAAA== Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 11:00:20 -0000 Hi Jose, Many thanks for your review. An updated version has just been submitted. This should address your feedback. Thanks Magnus On 2012-12-14 16:47, Jose Saldana wrote: > Hi all. I have read draft-ietf-6man-udpchecksums-06.txt. I support it. > > > Only these comments (I hope they are useful): > > - Although the difference between "tunneling packet" and "tunneled packet" > is clear, I think something similar could be done when talking about > "tunneling protocols". The document sometimes talks about "tunnel protocols" > and other times about "tunneling protocols". Perhaps the term could be > unified. > > > Sentences which could be improved: > > - " These different examples each help to significantly reduce the > likelihood that a corrupted inner tunneled packet is finally delivered to a > protocol listener that can be affected by the packet." Sounds very > complicated, IMHO. > > - "similar effects that reduce the likelihood that an mis-delivered packet > are delivered." Could say " similar effects that reduce the likelihood that > a mis-delivered packet is delivered." > > - " A corruption will commonly only effect the single packet, not > established protocol state." Could say "A corruption will commonly affect a > single packet, not the established protocol state." > > - " Tunnel protocols encapsulating IP this will generally be safe," could > say "In tunnel protocols encapsulating IP, this will generally be safe," > > > A small typo: > > - "Corruption of the address information in an encapsulating packets," could > say " Corruption of the address information in an encapsulating packet" > > > Best regards, > > Jose Saldana > >> -----Mensaje original----- >> De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de >> Magnus Westerlund >> Enviado el: jueves, 13 de diciembre de 2012 10:20 >> Para: gorry@erg.abdn.ac.uk >> CC: tsvwg@ietf.org >> Asunto: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man- >> udpzero >> >> Hi, >> >> I do hope we will get some reviews from TSVWG. But I would like to point >> out that the target is Standards Track. >> >> I also would recommend that you take a look at the document implementing >> the change in the IPv6 Specification also after having reviewed >> draft-ietf-6man-udpzero-08: >> >> >> The IESG has received a request from the IPv6 Maintenance WG (6man) to >> consider the following document: >> - 'IPv6 and UDP Checksums for Tunneled Packets' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits > final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the beginning > of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document provides an update of the Internet Protocol version 6 >> (IPv6) specification (RFC2460) to improve the performance in the use >> case when a tunnel protocol uses UDP with IPv6 to tunnel packets. >> The performance improvement is obtained by relaxing the IPv6 UDP >> checksum requirement for suitable tunneling protocol where header >> information is protected on the "inner" packet being carried. This >> relaxation removes the overhead associated with the computation of >> UDP checksums on IPv6 packets used to carry tunnel protocols. The >> specification describes how the IPv6 UDP checksum requirement can be >> relaxed for the situation where the encapsulated packet itself >> contains a checksum. The limitations and risks of this approach are >> described, and restrictions specified on the use of the method. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> On 2012-12-12 09:09, gorry@erg.abdn.ac.uk wrote: >>> This message starts a two week TSVWG Working Group on advancing: >>> >>> Title : Applicability Statement for the use of IPv6 > UDP >>> Datagrams with Zero Checksums >>> Author(s) : Godred Fairhurst >>> Magnus Westerlund >>> Filename : draft-ietf-6man-udpzero-08.txt >>> Pages : 37 >>> Date : 2012-12-11 >>> >>> https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ >>> >>> This document is intended to be published as BCP via the 6MAN WG. >>> >>> This last call is being done given the number of changes and the time >>> since the earlier last calls. The changes were discussed at the >>> Atlanta IETF 6man & TSVWG sessions. The authors believe these changes >>> will resolve the open IESG Discusses. Our AD will start a concurrent >>> IETF last call as well. >>> >>> Substantive comments and statements of support for advancing this >>> document should be directed to the tsvwg or 6man mailing list. >>> Editorial suggestions can be sent to the authors. This last call will >>> end on 26 December 2012. >>> >>> James, David & Gorry >>> TSVWG Co-Chairs. >>> >>> >>> >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> 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 >> ---------------------------------------------------------------------- > > > -- Magnus Westerlund ---------------------------------------------------------------------- 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 magnus.westerlund@ericsson.com Thu Jan 17 04:27:46 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6921F85D9 for ; Thu, 17 Jan 2013 04:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.038 X-Spam-Level: X-Spam-Status: No, score=-106.038 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSRNqvfqJens for ; Thu, 17 Jan 2013 04:27:45 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E979D21F85D4 for ; Thu, 17 Jan 2013 04:27:44 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-fa-50f7ee3f415c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 29.AC.19728.F3EE7F05; Thu, 17 Jan 2013 13:27:44 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 17 Jan 2013 13:27:44 +0100 Message-ID: <50F7EE3E.2020505@ericsson.com> Date: Thu, 17 Jan 2013 13:27:42 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joe Touch References: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> <50C99DC8.7060505@ericsson.com> <00dc01cdda12$5cb82190$162864b0$@unizar.es> <50E60EC1.7060404@isi.edu> In-Reply-To: <50E60EC1.7060404@isi.edu> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvja7Du+8BBnN/MVq8bpvNaLHlmJ7F uj9zWSyOvbnL5sDi0fP5BZPHkiU/mTx2v9/K4rHs6hHmAJYoLpuU1JzMstQifbsEroxth3cz FtzRqNi0wr+BsV2hi5GTQ0LAROJqzy4mCFtM4sK99WxdjFwcQgInGSWunWhghnCWM0q0/VnG BlLFK6AtcWvvTnYQm0VAVeLGrknMIDabgIXEzR+NYDWiAsESGw6uYoKoF5Q4OfMJC4gtIiAr 8eDPG7BeZgEbiRVdd8FsYQFvic4591kglm1klNh9ayrYUE4BdYnZ1w4AFXEAnScuseYNB0Sv nsSUqy2MELa8RPPW2WDlQkC3NTR1sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15utIkRGNAH t/xW3cF455zIIUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhj105aVqYo6 fWMImXxOZ8bjvZtT3vyVDTNQ8tl62bJzVdHnZ9+9f9j9PnXHs+7DlfOFXSaJH4z2t1/brvpA 5Ol1v0cn77VFtCvMPyr7rsvnwjSzGKMSjSsX06RSTvFN5hD/uS5CX1B7zjTRbTP1tj/Tcj6R YFa3UdqyTMP73YVlhyYI3F905pygEktxRqKhFnNRcSIAg7XR3zYCAAA= Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:27:46 -0000 Hi Joe, Thanks for your review. See response to your comments below. On 2013-01-04 00:05, Joe Touch wrote: > Hi, all, > > I read both this and 6man-udpchecksums, and have comments below. > > Joe > > ----- > > First, I'm a bit bothered that this issue is spread across two > documents. IMO, these two ought to be merged into a single statement. > It's confusing that neither doc includes a complete description of the > issue and solution. There is historic reasons why this ended up like it did. It is far from optimal. But enough is enough. The documents I think are coherent in regards to each other. I will claim good enough. > > This doc (6man-udpzero) is confusing - it lists 4 separate reasons for > the need for zero checksums (sec 1.3.1), yet the first three restate the > first one (reduced forwarding costs), and the last one (load balancing) > isn't sufficiently motivated to the need to avoid checksums. This > section should be revised to differentiate the separate issues and > justify those that remain as being tied to avoiding the checksum. Is the differences really unclear after you have read 1.3.2-1.3.5 which goes into detail of what these bullets means? > > I do not see sufficient reason to implement this solution vs. UDP-lite. > In both cases there is a need to revise the endpoints that process UDP > packets, and in both cases an unmodified endpoint would drop the packets > unless updated. That argues against the need for a unique solution for > UDP vs. using UDP-lite. I.e., any packet that parses UDP headers would > drop v6 zero-checksum UDPs unless modified, and any modification could > support UDP-lite instead. Joe, you where yourself present in some of the 6man meeting where this was discussed. I would also preferred that UDP-lite was deployed for this use cases. However, UDP zero checksum actually has less places which requires modification to get this working, for example the load balancers are not needed to be updated to support zero-checksum UDP, but need to do that for UDP-Lite. > > Further, UDP-lite allows protection of portions of the UDP header that > might benefit from this, even when the underlying packet has its own > checksums. Agreed, it from this perspective a better solution. > > --- > > 6man-udpchecksums further remains incomplete. The doc gives specific > text to update RFC 2460, but that text refers obscurely to > "zero-checksum mode" without defining it anywhere (including inside the > replacement text). IMO, there ought to be a very direct discussion of > what that mode means and how it is achieved both on the send and receive > side. This has been addressed with the new 07 version: An IPv6 node associates a mode with each active UDP port. Whenever originating a UDP packet for a port in the default mode, an IPv6 node MUST compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it MUST be changed to hex FFFF for placement in the UDP header. IPv6 receivers MUST by default discard UDP packets containing a zero checksum, and SHOULD log the error. As an alternative, certain protocols that use UDP as a tunnel encapsulation, MAY enable the zero-checksum mode for a specific port (or set of ports). Any node implementing the zero-checksum mode MUST follow the node requirements specified in Section 4 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero]. Any protocol that enables the zero-checksum mode for a specific port or ports MUST follow the usage requirements specified in Section 5 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero]. Middleboxes supporting IPv6 MUST follow requirements 9, 10 and 11 of the usage requirements specified in Section 5 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero]. Is this clearer what i meant with the zero-checksum mode? > > I also wonder whether an interface that enables zero checksum mode > should handle non-zero checksums. If these are intended for a tunnel, > then IMO that use ought to be sufficiently constrained as to suggest > that nonzero checksums might be a clear indication of an error > (including a DOS attack on computation resources at a receiver). My view is that they absolutely need to handle both if zero-checksum is enabled. The primary reasons in to be able to checksum control traffic for the tunnel. Cheers Magnus Westerlund ---------------------------------------------------------------------- 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 touch@isi.edu Thu Jan 17 11:00:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5CB21F862A for ; Thu, 17 Jan 2013 11:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4aGF68TDy7I for ; Thu, 17 Jan 2013 11:00:12 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4EF21F88B5 for ; Thu, 17 Jan 2013 10:59:38 -0800 (PST) Received: from [128.9.184.199] ([128.9.184.199]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r0HIpUUA027779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2013 10:51:30 -0800 (PST) Message-ID: <50F84832.5060908@isi.edu> Date: Thu, 17 Jan 2013 10:51:30 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> <50C99DC8.7060505@ericsson.com> <00dc01cdda12$5cb82190$162864b0$@unizar.es> <50E60EC1.7060404@isi.edu> <50F7EE3E.2020505@ericsson.com> In-Reply-To: <50F7EE3E.2020505@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:00:13 -0000 Hi, Magnus (et al.), On 1/17/2013 4:27 AM, Magnus Westerlund wrote: > Hi Joe, > > Thanks for your review. See response to your comments below. > > On 2013-01-04 00:05, Joe Touch wrote: >> Hi, all, >> >> I read both this and 6man-udpchecksums, and have comments below. >> >> Joe >> >> ----- >> >> First, I'm a bit bothered that this issue is spread across two >> documents. IMO, these two ought to be merged into a single statement. >> It's confusing that neither doc includes a complete description of the >> issue and solution. > > There is historic reasons why this ended up like it did. It is far from > optimal. But enough is enough. The documents I think are coherent in > regards to each other. I will claim good enough. > >> >> This doc (6man-udpzero) is confusing - it lists 4 separate reasons for >> the need for zero checksums (sec 1.3.1), yet the first three restate the >> first one (reduced forwarding costs), and the last one (load balancing) >> isn't sufficiently motivated to the need to avoid checksums. This >> section should be revised to differentiate the separate issues and >> justify those that remain as being tied to avoiding the checksum. > > Is the differences really unclear after you have read 1.3.2-1.3.5 which > goes into detail of what these bullets means? Yes; I considered that context. >> I do not see sufficient reason to implement this solution vs. UDP-lite. >> In both cases there is a need to revise the endpoints that process UDP >> packets, and in both cases an unmodified endpoint would drop the packets >> unless updated. That argues against the need for a unique solution for >> UDP vs. using UDP-lite. I.e., any packet that parses UDP headers would >> drop v6 zero-checksum UDPs unless modified, and any modification could >> support UDP-lite instead. > > Joe, you where yourself present in some of the 6man meeting where this > was discussed. I would also preferred that UDP-lite was deployed for > this use cases. However, UDP zero checksum actually has less places > which requires modification to get this working, for example the load > balancers are not needed to be updated to support zero-checksum UDP, but > need to do that for UDP-Lite. That might be pointed out more directly. Is that the only reason? (maybe NAT traversal?) >> Further, UDP-lite allows protection of portions of the UDP header that >> might benefit from this, even when the underlying packet has its own >> checksums. > > Agreed, it from this perspective a better solution. > >> >> --- >> >> 6man-udpchecksums further remains incomplete. The doc gives specific >> text to update RFC 2460, but that text refers obscurely to >> "zero-checksum mode" without defining it anywhere (including inside the >> replacement text). IMO, there ought to be a very direct discussion of >> what that mode means and how it is achieved both on the send and receive >> side. > > This has been addressed with the new 07 version: > > An IPv6 node associates a mode with each active UDP port. I'm not sure what an "active UDP port" is; it might be useful to clarify this. Apps can send to ports they aren't listening on, e.g. > Whenever originating a UDP packet for a port in the default mode, > an IPv6 node MUST compute a UDP checksum over the packet and the > pseudo-header, and, if that computation yields a result of zero, > it MUST be changed to hex FFFF for placement in the UDP header. It might be useful to add "as per existing requirements." (to underscore that this isn't a change). This clearly explains how checksums are computed in the default. > IPv6 receivers MUST by default discard UDP packets containing a > zero checksum, and SHOULD log the error. > > As an alternative, certain protocols that use UDP as a tunnel > encapsulation, MAY enable the zero-checksum mode for a specific > port (or set of ports). Destination port? Source port? or port pairs? > Any node implementing the zero-checksum > mode MUST follow the node requirements specified in Section 4 of > "Applicability Statement for the use of IPv6 UDP Datagrams with > Zero Checksums" [I-D.ietf-6man-udpzero]. > > Any protocol that enables the zero-checksum mode for a specific > port or ports MUST follow the usage requirements specified in > Section 5 of "Applicability Statement for the use of IPv6 UDP > Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero]. > > Middleboxes supporting IPv6 MUST follow requirements 9, 10 and 11 > of the usage requirements specified in Section 5 of "Applicability > Statement for the use of IPv6 UDP Datagrams with Zero Checksums" > [I-D.ietf-6man-udpzero]. > > Is this clearer what i meant with the zero-checksum mode? It omits the corresponding re-statement of zero-checksum mode - notably the direct statement that a value of zero is inserted in the checksum field. (I realize that seems obvious, but it could also have meant that the checksum is omitted and the data starts earlier). >> I also wonder whether an interface that enables zero checksum mode >> should handle non-zero checksums. If these are intended for a tunnel, >> then IMO that use ought to be sufficiently constrained as to suggest >> that nonzero checksums might be a clear indication of an error >> (including a DOS attack on computation resources at a receiver). > > My view is that they absolutely need to handle both if zero-checksum is > enabled. The primary reasons in to be able to checksum control traffic > for the tunnel. But wouldn't that traffic have some other defining property - different port, different encapsulation, etc.? Joe > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > 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 touch@isi.edu Thu Jan 17 16:58:48 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4FB21F8AC8 for ; Thu, 17 Jan 2013 16:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.643 X-Spam-Level: X-Spam-Status: No, score=-104.643 tagged_above=-999 required=5 tests=[AWL=1.956, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkZdgjHFmz9m for ; Thu, 17 Jan 2013 16:58:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BD8C921F8953 for ; Thu, 17 Jan 2013 16:58:47 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r0I0vpWV016855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Jan 2013 16:57:51 -0800 (PST) Message-ID: <50F89E0F.5010506@isi.edu> Date: Thu, 17 Jan 2013 16:57:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Bob Briscoe References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> <50C23EC3.5060704@isi.edu> <50E4ABA0.90007@isi.edu> <50E7F682.5030106@cisco.com> <201301071023.r07ANkMD025310@bagheera.jungle.bt.co.uk> In-Reply-To: <201301071023.r07ANkMD025310@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 00:58:48 -0000 Hi, Bob, Eliot, et al., On 1/7/2013 2:23 AM, Bob Briscoe wrote: > Joe, > > Tx for yr explanation. Previously the doc merely stated option a), > without saying why, and I read all the discussion on the list going back > to the beginning and couldn't find any reason why. > > I guess avoiding a landrush might be a valid concern - a bit like once > most of the gold has been found, removing all controls on prospecting > and trying to declare that gold is no longer a precious metal. If gold > really is no longer a precious metal, it wouldn't matter. > > Similarly, given system ports aren't special, opening up the allocation > space shouldn't matter. However, we all know people (and implementers ;) > are irrational. > > Like Eliot, I have no strong pref betw a) and c). But b) is too weak. > > If we do choose a), we should consider a feasible transition strategy at > a later stage to allow the unallocated ports 0-1023 to be allocated. Eg. > plan to open 0-1023 up for allocation after a couple of years while > ports are still plentiful, rather than waiting until they become scarce, > which will just precipitate a bigger landrush at some later date. Sure - I'll update the doc accordingly. Thanks for the discussion. Joe > > > Bob > > At 09:46 05/01/2013, Eliot Lear wrote: >> Joe, >> >> I like your summary. I would be satisfied with (a) or (c) with the >> understanding that with regard to (c) the expert reviewer has the final >> choice as to what port to use ­ and not the applicant, and that the >> expert reviewer will use (a) as a guide unless there is very good reason >> to do otherwise. Yes, I'm hedging slightly, but I just don't want >> someone writing stupid code that says that new protocols in that space >> are somehow unauthorized in some way (avoid a 240/4 situation). You'd >> think that'd be difficult with a range that is half consumed, but I >> wouldn't underestimate some implementers... >> >> Eliot >> >> On 1/2/13 10:50 PM, Joe Touch wrote: >> > Hi, all, >> > >> > Any thoughts on this, given the context below? >> > >> > I'd like to have the input of others on this list before updating the >> > draft on this point. >> > >> > Thanks, >> > >> > Joe >> > >> > On 12/7/2012 11:08 AM, Joe Touch wrote: >> >> Hi, Bob, Eliot, et al., >> >> >> >> On 12/6/2012 9:40 PM, Eliot Lear wrote: >> >>> >> >>> On 12/7/12 12:56 AM, Bob Briscoe wrote: >> >>>> I don't see why ceasing to allocate system ports will help. It's not >> >>>> clear whether you are trying to remove the false sense of security >> >>>> that system ports purport to offer, or whether you are trying to >> >>>> remove the higher bar to IANA allocation, both, neither, or what. >> >>>> There's too little written in the draft, on the list and around the >> >>>> bullets in your presentation of the draft to guess fully what you're >> >>>> driving at. >> >>> >> >>> I support the notion of combining system and user for the simple >> reason >> >>> that there is no technical difference between the two, there is no >> >>> meaningful additional security offered by system. The distinction >> >>> dates >> >>> back to the notion that non-privileged users couldn't open a port >> below >> >>> 1024 and we knew all Internet hosts by name. >> >> >> >> This was discussed at several IETFs before this doc was accepted as >> a WG >> >> item, so I thought there was context. The doc does need expanding on >> >> this, and I will do so in the next revision. >> >> >> >> My view is that: >> >> >> >> - the distinction has evolved to become meaningless, and thus treating >> >> any port as more trusted because of its assigned range is a bad >> idea (as >> >> Eliot points out above). Yes, there are plenty of systems that do >> >> continue to treat the two ranges as different, but enough others that >> >> don't that it seems a bad idea to continue to support the >> difference as >> >> meaningful. >> >> >> >> Which is why I propose the following as an overall goal: >> >> >> >> The range 0...49151 will be known as Assigned ports. >> >> >> >> Port assignments will no longer distinguish between 'user', >> >> 'system', 'well-known', and 'registered' subranges of Assigned >> >> ports. >> >> >> >> If we do deprecate the difference between the ranges, we need to >> decide >> >> how to move forward. >> >> >> >> First, regardless of how we move forward, IMO: >> >> >> >> Assigned ports should use the procedures from RFC 2780 >> >> that apply to User ports. >> >> >> >> There are two ways forward, given that goal (in the order of my >> >> preference): >> >> >> >> a) this document can officially deprecate the distinction between User >> >> and System ports by declaring that IANA should cease further >> assignments >> >> from the System range >> >> >> >> b) this document can suggest that users should not bother requesting >> >> system ports >> >> >> >> c) this document can officially deprecate the distinction between User >> >> and System ports by merging the two and letting users pick any >> available >> >> port from the Assigned range >> >> >> >> Of these options, I think (c) creates a "land rush" in the System >> space, >> >> and we don't have enough understanding of the impact on legacy >> >> protocols. >> >> >> >> (a) is the safest, since it merely requires that new services be >> >> designed in a way that assumes that they could be run by any user >> on any >> >> system - which, these days, seems like a reasonable recommendation. >> >> >> >> (b) is a way to circumvent the issue without deprecating the >> User/System >> >> distinction, and IMO just continues to ignore the current situation >> >> >> >> Thoughts? >> >> >> >> Joe >> >> >> > >> > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From Mirko.Suznjevic@fer.hr Fri Jan 18 02:15:29 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9577921F88E3; Fri, 18 Jan 2013 02:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFfXx19-UDM3; Fri, 18 Jan 2013 02:15:19 -0800 (PST) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by ietfa.amsl.com (Postfix) with ESMTP id E137921F8867; Fri, 18 Jan 2013 02:15:16 -0800 (PST) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.318.4; Fri, 18 Jan 2013 11:15:14 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jan 2013 11:15:03 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDF564.AE14F110" Date: Fri, 18 Jan 2013 11:15:02 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-Index: AQHN9JGjt/1wmNKQnUulDvKsi7PhJphO37Iw References: From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: FERNANDO PASCUAL BLANCO , , X-OriginalArrivalTime: 18 Jan 2013 10:15:03.0356 (UTC) FILETIME=[AE4EFFC0:01CDF564] Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 10:15:29 -0000 ------_=_NextPart_001_01CDF564.AE14F110 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Yes I concur, it is a good notice. I am adding your comment to the = review list for the next version. Mirko Suznjevic =20 From: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]=20 Sent: Thursday, January 17, 2013 10:08 AM To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; tsvwg@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows =20 Hi Mirko, =20 Thank you for considering that. In addition, one more thing: in section = 4, the sentence "If a policy defining a multiplexing period is used, = then the average latency added to each packet will be half the = multiplexing period." only applies when there is not enough packet rate = to fulfill a big packet by multiplexing small ones. When there is a lot = of packets to multiplex, in general, multiplexing period will not be = reached, so half the multiplexing period will be the maximum/worse = average added delay. In general, and when TCMTF is working fine, average = added delay will be lower. So, I would rewrite that phrase as: "If a policy defining a multiplexing = period is used, then the average latency added to each packet will be = half the time to fulfill a multiplexed one. In the worse case and if the = multiplexing period is reached, the average latency added to each packet = will be half the multiplexing period". =20 What do you think? =20 Regards, =20 Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es =20 From: Mirko Su=BEnjevi=E6 Date: martes, 15 de enero de 2013 16:48 To: Fernando Pascual Blanco , "tcmtf@ietf.org" = , "tsvwg@ietf.org" Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows =20 Hello, Thanks for all the comments, I will briefly respond to them, and include = your (as well as previous) corrections in a new version of the draft: * I do not understand the sentence "Therefore, we neither take into = account services using an approach in which all the calculations are = deployed in the server, which sends a real-time video stream to the = client." in section 3. The meaning of this sentence is that we will not be looking at the cloud = based gaming services such as OnLive or Gaiki as they are focused on = performing all needed calculations of the gamestate on the server, and = sending a very "fat" video stream to the client which only renders the = video. Therefore they are not suitable for tcmtf. I will change that in = order to be more clear. * In section 3 (Considered Services), I think it could be also = interesting to consider non-real time services candidates to be TCMTF = optimized. For example services like instant messaging, where the = bandwidth saving is the main benefit of the TCMTF optimization, should = be somehow mentioned, establishing a kind of delay upper threshold. = Related to that, in section 3, when talking about web browsing, the = sentence "there is no need for policy limitations in TCMTF" could be = disappointed, because actually there are limitations (ITU-T_G.1010, 10 = seconds for web browsing, as in section 4.1 10 seconds are considered = for streaming audio). At first when we were discussing we decided that it will be focused on = real-time services, but this can be broadened to others non-real-time. I = think giving such upper limits has a point, although would we even = employ tcmtf in cases in which we will not have enough data to send a = packet in 5 or more seconds? Is that feasible? Maybe in some sensor = networks? Maybe I am just looking it the wrong way, maybe we would have = a lot of traffic that needs to be packed ASAP! * In section 4, I would change the sentence "A number of flows are = multiplexed together before being sent through the Internet." for "A = number of flows are multiplexed together before being sent through the = network.", because the network could not be necessary the Internet, I = would also adapt Figure 2. Ok will be done. * Maybe the creation of a section 4.4 talking about non real time = services could be considered including last comments (acceptable with = the recommendation appearing in the last sentence of the section 4.3 "It = should be noted that multiplexing periods of about 1 second can be = considered as enough for non real time services (e.g., web browsing and = streaming audio).") Ok, seems sound enough. I will write it and see which format looks = better. * Table 1 could be included in a separate section (i.e. Section 4.5) as = a summary Ok. =20 Thanks again for the feedback! Cheers! Mirko =20 From: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]=20 Sent: Tuesday, January 15, 2013 3:42 PM To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; tsvwg@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows =20 Hi Mirko, =20 Some comments to the draft: * In the introduction it says "TCTMF", it is "TCMTF". * I do not understand the sentence "Therefore, we neither take into = account services using an approach in which all the calculations are = deployed in the server, which sends a real-time video stream to the = client." in section 3. * In section 3 (Considered Services), I think it could be also = interesting to consider non-real time services candidates to be TCMTF = optimized. For example services like instant messaging, where the = bandwidth saving is the main benefit of the TCMTF optimization, should = be somehow mentioned, establishing a kind of delay upper threshold. = Related to that, in section 3, when talking about web browsing, the = sentence "there is no need for policy limitations in TCMTF" could be = disappointed, because actually there are limitations (ITU-T_G.1010, 10 = seconds for web browsing, as in section 4.1 10 seconds are considered = for streaming audio). * In section 4, I would change the sentence "A number of flows are = multiplexed together before being sent through the Internet." for "A = number of flows are multiplexed together before being sent through the = network.", because the network could not be necessary the Internet, I = would also adapt Figure 2. * Maybe the creation of a section 4.4 talking about non real time = services could be considered including last comments (acceptable with = the recommendation appearing in the last sentence of the section 4.3 "It = should be noted that multiplexing periods of about 1 second can be = considered as enough for non real time services (e.g., web browsing and = streaming audio).") * Table 1 could be included in a separate section (i.e. Section 4.5) as = a summary Hope to help! =20 Regards, =20 Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es =20 From: Mirko Su=BEnjevi=E6 Date: jueves, 13 de diciembre de 2012 10:06 To: "tcmtf@ietf.org" , "tsvwg@ietf.org" Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling = Compressed Multiplexed Traffic Flows =20 Hello, =20 We have just submitted the draft named Maximum Tolerable Delays when = using Tunneling Compressed Multiplexed Traffic Flows: = http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ =20 It is an extension of tcmtf = http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a = specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss = it there. =20 The draft contains recommendations for TCMTF multiplexing period for = different real-time services. In order to prevent QoE degradation of = real-time services using TCMTF, a policy defining a multiplexing period = can be employed. Values of maximum tolerable delays presented in the = draft form the base of such policy. The recommendations are presented = for real-time network services in which TCTMF bandwidth optimization is = applicable (i.e., services which have low payload to header size ratio = which results in high protocol overhead). =20 Your feedback will be welcome. Thank you. Sincerely, Mirko Suznjevic =20 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx =20 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ------_=_NextPart_001_01CDF564.AE14F110 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Yes I concur, it is a good notice. = I am adding your comment to the review list for the next = version.


Mirko Suznjevic

 

From:= FERNANDO = PASCUAL BLANCO [mailto:fpb@tid.es]
Sent: Thursday, January = 17, 2013 10:08 AM
To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; = tsvwg@ietf.org
Subject: Re: [tcmtf] Draft: Maximum Tolerable = Delays when using Tunneling Compressed Multiplexed Traffic = Flows

 

Hi = Mirko,

 

=

Thank you for considering that. = In addition, one more thing: in section 4, the sentence "If a = policy defining a multiplexing period is used, then the = average latency added to each packet will be half the multiplexing = period." only applies when there is not enough packet rate to = fulfill a big packet by multiplexing small ones. When  there is a = lot of packets to multiplex, in general, multiplexing period will not be = reached, so half the multiplexing period will be the maximum/worse = average added delay. In general, and when TCMTF is working fine, average = added delay will be lower.

So, I would rewrite that phrase = as: "If a policy defining a multiplexing period is used, then the = average latency added to each packet will be half the time to = fulfill a multiplexed one. In the worse case and if the multiplexing = period is reached, the average latency added to each packet will be half = the multiplexing period".

 

=

What do you = think?

 

=

Regards,

 

=

Fernando Pascual = Blanco

Telef=F3nica Global = Resources

Network Automation = and Dynamization

TECHNOLOGY PEOPLE = GROUP

F = +34913128779

M = +34682005168

 

=

From: Mirko Su=BEnjevi=E6 <Mirko.Suznjevic@fer.hr>
= Date: martes, 15 de enero de 2013 16:48
To: Fernando = Pascual Blanco <fpb@tid.es>, = "tcmtf@ietf.org" <tcmtf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: = Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling = Compressed Multiplexed Traffic Flows

 

=

Hello,

Thanks for all the comments, I will = briefly respond to them, and include your (as well as previous) = corrections in a new version of the draft:

  • I do not = understand the sentence "Therefore, we neither take into = account services using an approach in which all the calculations = are deployed in the server, which sends a real-time video stream to = the client." in section 3.

The meaning of this sentence is = that we will not be looking at the cloud based gaming services such as = OnLive or Gaiki as they are focused on performing all needed = calculations of the gamestate on the server, and sending a very = “fat” video stream to the client which only renders the = video. Therefore they are not suitable for tcmtf. I will change that in = order to be more clear.

  • In section 3 = (Considered Services), I think it could be also interesting to consider = non-real time services candidates to be TCMTF optimized. For example = services like instant messaging, where the bandwidth saving is the main = benefit of the TCMTF optimization, should be somehow mentioned, = establishing a kind of delay upper threshold. Related to that, in = section 3, when talking about web browsing, the sentence "there is = no need for policy limitations in TCMTF" could = be disappointed, because actually there are limitations = (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 = seconds are considered for streaming audio).

At first when we were discussing we = decided that it will be focused on real-time services, but this can be = broadened to others non-real-time. I think giving such upper limits has = a point, although would we even employ tcmtf in cases  in which we = will not have enough data to send a packet in 5 or more seconds? Is that = feasible? Maybe in some sensor networks? Maybe I am just looking it the = wrong way, maybe we would have a lot of traffic that needs to be packed = ASAP!

  • In section 4, = I would change the sentence "A number of flows are = multiplexed together before being sent through the Internet." = for "A number of flows are multiplexed together before being = sent through the network.", because the network could not be = necessary the Internet, I would also adapt Figure 2.

Ok will be done.

  • Maybe the creation of a section 4.4 talking = about non real time services could be considered including last comments = (acceptable with the recommendation appearing in the last sentence of = the section 4.3 "It should be = noted that multiplexing periods of about 1 second can be considered = as enough for non real time services (e.g., web browsing and = streaming audio).")

Ok, seems = sound enough. I will write it and see which format looks = better.

  • Table 1 could be included in a separate = section (i.e. Section 4.5) as a = summary

Ok.

 

Thanks again for the = feedback!

Cheers!
Mirko

 

= From:= FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]
Sent: = Tuesday, January 15, 2013 3:42 PM
To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; tsvwg@ietf.org
Subject: Re: = [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed = Multiplexed Traffic Flows

 

Hi Mirko,

 

Some comments to the = draft:

  • In the introduction it says = "TCTMF", it is "TCMTF".
  • I do not understand the sentence = "Therefore, we neither take into account services using an = approach in which all the calculations are deployed in the server, = which sends a real-time video stream to the client." in = section 3.
  • In section 3 (Considered = Services), I think it could be also interesting to consider non-real = time services candidates to be TCMTF optimized. For example services = like instant messaging, where the bandwidth saving is the main benefit = of the TCMTF optimization, should be somehow mentioned, establishing a = kind of delay upper threshold. Related to that, in section 3, when = talking about web browsing, the sentence "there is no need for = policy limitations in TCMTF" could be disappointed, = because actually there are limitations (ITU-T_G.1010, 10 seconds = for web browsing, as in section 4.1 10 seconds are considered for = streaming audio).
  • In section 4, I would change the = sentence "A number of flows are multiplexed together before = being sent through the Internet." for "A number of flows are = multiplexed together before being sent through the network.", = because the network could not be necessary the Internet, I would also = adapt Figure 2.
  • Maybe the creation of a section = 4.4 talking about non real time services could be considered including = last comments (acceptable with the recommendation appearing in the last = sentence of the section 4.3 "It should be = noted that multiplexing periods of about 1 second can be considered = as enough for non real time services (e.g., web browsing and = streaming audio).")
  • Table 1 could be included in a separate section = (i.e. Section 4.5) as a summary

Hope to = help!

 

Regards,

 

Fernando Pascual = Blanco

Telef=F3nica Global = Resources

Network Automation and = Dynamization

TECHNOLOGY PEOPLE = GROUP

F +34913128779

M +34682005168

 

From: Mirko Su=BEnjevi=E6 <Mirko.Suznjevic@fer.hr>
= Date: jueves, 13 de diciembre de 2012 10:06
To: = "tcmtf@ietf.org" = <tcmtf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: = [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling = Compressed Multiplexed Traffic Flows

 

Hello,

 

We have just = submitted the draft named Maximum Tolerable Delays when using Tunneling = Compressed Multiplexed Traffic Flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

It is an = extension of tcmtf http:= //datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a = specific list for tcmtf exists (tcmtf@ietf.org), the idea is to = discuss it there.

 

The draft = contains recommendations for TCMTF multiplexing period for different = real-time services. In order to prevent QoE degradation of real-time = services using TCMTF, a policy defining  a multiplexing period can = be employed. Values of maximum tolerable delays presented in the draft = form the base of such policy.    The recommendations are = presented for real-time network services in which TCTMF bandwidth = optimization is applicable (i.e., services  which have low payload = to header size ratio which results in high protocol = overhead).

 

Your feedback = will be welcome. Thank you.


Sincerely,

Mirko = Suznjevic

 

Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo.
This message is = intended exclusively for its addressee. We only send and receive email = on the basis of the terms set out at:
http://www.tid.es/E= S/PAGINAS/disclaimer.aspx

 

Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo.
This message is = intended exclusively for its addressee. We only send and receive email = on the basis of the terms set out at:
http://www.tid.es/E= S/PAGINAS/disclaimer.aspx

------_=_NextPart_001_01CDF564.AE14F110-- From mramalho@cisco.com Fri Jan 18 06:05:27 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAFD21F889A; Fri, 18 Jan 2013 06:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLTGS-m1ZrZb; Fri, 18 Jan 2013 06:05:21 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BD1B621F883F; Fri, 18 Jan 2013 06:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46971; q=dns/txt; s=iport; t=1358517920; x=1359727520; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TMYsqVxcK26SvOHBHceBs5sdXQtj8yA/tyCiD1jReio=; b=RWWns5nclJf3vBlwYQDD2E4nmkAEDNlZELn3XD56epQ6NhtdvQ9sURm5 2jfw/Y5k8187AxOKVx2xEXI00xrQxJXrXPNJbqonnUy6N0pjzm9BBN3QL wfvJmBS/il8gUX9LyxMUOj7SjTQGK8JPnpps0JLu7MdWCmDAUz7YsXGhi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADBV+VCtJXHA/2dsb2JhbABFgkipOYkMAYkqFnOCHgEBAQQaE0YWAgEIEQMBAQELCwsBAgQHMhQJCAIEARIIiBEMvB2MdgsLeIJUYQOSWYRPjy2CdYFmAQYCFx4 X-IronPort-AV: E=Sophos;i="4.84,492,1355097600"; d="scan'208,217";a="164422137" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jan 2013 14:05:19 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0IE5JZ9000549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jan 2013 14:05:19 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.163]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 08:05:18 -0600 From: "Michael Ramalho (mramalho)" To: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= , "FERNANDO PASCUAL BLANCO" , "tcmtf@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-Index: AQHN9WTCfb61mh1Pz0K8TME3OxMO+ZhPGtzw Date: Fri, 18 Jan 2013 14:05:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.168.119] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B9103154C4245xmbrcdx12ciscoc_" MIME-Version: 1.0 Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 14:05:27 -0000 --_000_D21571530BF9644D9A443D6BD95B9103154C4245xmbrcdx12ciscoc_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable All, Strictly speaking, the sentence ""If a policy defining a multiplexing perio= d is used, then the average latency added to each packet will be half the m= ultiplexing period."" makes an explicit assumption that the packet arrivals= (for TCMTF packets) are random/uniform (or even that the arrival pdf is on= e sided, with the most of the pdf area/contribution below the mean delay). Why even go there? If someone has such a "policy" ... the policy is to define the maximum wors= t-case TCMTF (encoding) delay. If the TCMTF encoder has not yet built a "ne= ar-MTU" packet and the worst-case delay timer fires ... push the packet out= ! The worst-case TCMTF delay we should introduce is determined by the packets= we want to multiplex within a TCMTF packet. If we knew their traffic class= ... we would have an idea of what the worst case should be. If we didn't, = but rather made a reasonable assumption (for example, based on signature an= alysis), then we push when our idea of what the worst case has been met. Given that the sentence referenced above is not correct (it has an implicit= random arrival process assumption) - we need to clarify it if it is decide= d to keep it. As Gorry notes in the next email on this thread, some delay-based congestio= n controls may respond to TCMTF-induced delay as an indication of increasin= g congestion in their congestion control. Anything we can do to limit the m= aximum delay (i.e., have a "nice" TCMTF-induced delay distribution) would b= e appreciated. Michael Ramalho From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of M= irko Su=BEnjevic Sent: Friday, January 18, 2013 5:15 AM To: FERNANDO PASCUAL BLANCO; tcmtf@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tun= neling Compressed Multiplexed Traffic Flows Yes I concur, it is a good notice. I am adding your comment to the review l= ist for the next version. Mirko Suznjevic From: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es] Sent: Thursday, January 17, 2013 10:08 AM To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; tsvwg@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling C= ompressed Multiplexed Traffic Flows Hi Mirko, Thank you for considering that. In addition, one more thing: in section 4, = the sentence "If a policy defining a multiplexing period is used, then the = average latency added to each packet will be half the multiplexing period."= only applies when there is not enough packet rate to fulfill a big packet = by multiplexing small ones. When there is a lot of packets to multiplex, i= n general, multiplexing period will not be reached, so half the multiplexin= g period will be the maximum/worse average added delay. In general, and whe= n TCMTF is working fine, average added delay will be lower. So, I would rewrite that phrase as: "If a policy defining a multiplexing pe= riod is used, then the average latency added to each packet will be half th= e time to fulfill a multiplexed one. In the worse case and if the multiplex= ing period is reached, the average latency added to each packet will be hal= f the multiplexing period". What do you think? Regards, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es From: Mirko Su=BEnjevi=E6 > Date: martes, 15 de enero de 2013 16:48 To: Fernando Pascual Blanco >, "tcmtf@ietf.or= g" >, "tsvwg@i= etf.org" > Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling C= ompressed Multiplexed Traffic Flows Hello, Thanks for all the comments, I will briefly respond to them, and include yo= ur (as well as previous) corrections in a new version of the draft: * I do not understand the sentence "Therefore, we neither take into acc= ount services using an approach in which all the calculations are deployed = in the server, which sends a real-time video stream to the client." in sect= ion 3. The meaning of this sentence is that we will not be looking at the cloud ba= sed gaming services such as OnLive or Gaiki as they are focused on performi= ng all needed calculations of the gamestate on the server, and sending a ve= ry "fat" video stream to the client which only renders the video. Therefore= they are not suitable for tcmtf. I will change that in order to be more cl= ear. * In section 3 (Considered Services), I think it could be also interest= ing to consider non-real time services candidates to be TCMTF optimized. Fo= r example services like instant messaging, where the bandwidth saving is th= e main benefit of the TCMTF optimization, should be somehow mentioned, esta= blishing a kind of delay upper threshold. Related to that, in section 3, wh= en talking about web browsing, the sentence "there is no need for policy li= mitations in TCMTF" could be disappointed, because actually there are limit= ations (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 sec= onds are considered for streaming audio). At first when we were discussing we decided that it will be focused on real= -time services, but this can be broadened to others non-real-time. I think = giving such upper limits has a point, although would we even employ tcmtf i= n cases in which we will not have enough data to send a packet in 5 or mor= e seconds? Is that feasible? Maybe in some sensor networks? Maybe I am just= looking it the wrong way, maybe we would have a lot of traffic that needs = to be packed ASAP! * In section 4, I would change the sentence "A number of flows are mult= iplexed together before being sent through the Internet." for "A number of = flows are multiplexed together before being sent through the network.", bec= ause the network could not be necessary the Internet, I would also adapt Fi= gure 2. Ok will be done. * Maybe the creation of a section 4.4 talking about non real time servi= ces could be considered including last comments (acceptable with the recomm= endation appearing in the last sentence of the section 4.3 "It should be no= ted that multiplexing periods of about 1 second can be considered as enough= for non real time services (e.g., web browsing and streaming audio).") Ok, seems sound enough. I will write it and see which format looks better. * Table 1 could be included in a separate section (i.e. Section 4.5) as= a summary Ok. Thanks again for the feedback! Cheers! Mirko From: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es] Sent: Tuesday, January 15, 2013 3:42 PM To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; tsvwg@ietf.= org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling C= ompressed Multiplexed Traffic Flows Hi Mirko, Some comments to the draft: * In the introduction it says "TCTMF", it is "TCMTF". * I do not understand the sentence "Therefore, we neither take into acc= ount services using an approach in which all the calculations are deployed = in the server, which sends a real-time video stream to the client." in sect= ion 3. * In section 3 (Considered Services), I think it could be also interest= ing to consider non-real time services candidates to be TCMTF optimized. Fo= r example services like instant messaging, where the bandwidth saving is th= e main benefit of the TCMTF optimization, should be somehow mentioned, esta= blishing a kind of delay upper threshold. Related to that, in section 3, wh= en talking about web browsing, the sentence "there is no need for policy li= mitations in TCMTF" could be disappointed, because actually there are limit= ations (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 sec= onds are considered for streaming audio). * In section 4, I would change the sentence "A number of flows are mult= iplexed together before being sent through the Internet." for "A number of = flows are multiplexed together before being sent through the network.", bec= ause the network could not be necessary the Internet, I would also adapt Fi= gure 2. * Maybe the creation of a section 4.4 talking about non real time servi= ces could be considered including last comments (acceptable with the recomm= endation appearing in the last sentence of the section 4.3 "It should be no= ted that multiplexing periods of about 1 second can be considered as enough= for non real time services (e.g., web browsing and streaming audio).") * Table 1 could be included in a separate section (i.e. Section 4.5) as= a summary Hope to help! Regards, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es From: Mirko Su=BEnjevi=E6 > Date: jueves, 13 de diciembre de 2012 10:06 To: "tcmtf@ietf.org" >, "tsvwg@ietf.org" > Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compr= essed Multiplexed Traffic Flows Hello, We have just submitted the draft named Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows: http://datatracker.ietf.org= /doc/draft-suznjevic-tsvwg-mtd-tcmtf/ It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-t= svwg-tcmtf/. Since a specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss it there. The draft contains recommendations for TCMTF multiplexing period for differ= ent real-time services. In order to prevent QoE degradation of real-time se= rvices using TCMTF, a policy defining a multiplexing period can be employe= d. Values of maximum tolerable delays presented in the draft form the base = of such policy. The recommendations are presented for real-time network = services in which TCTMF bandwidth optimization is applicable (i.e., service= s which have low payload to header size ratio which results in high protoc= ol overhead). Your feedback will be welcome. Thank you. Sincerely, Mirko Suznjevic ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --_000_D21571530BF9644D9A443D6BD95B9103154C4245xmbrcdx12ciscoc_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

All,=

 

Strictly speaking, the= sentence “"= If a policy defining a multiplexing period is used, then the average l= atency added to each packet will be half the multiplexing period."” makes an explici= t assumption that the packet arrivals (for TCMTF packets) are random/unifor= m (or even that the arrival pdf is one sided, with the most of the pdf area= /contribution below the mean delay).

 

Why even go there?

 

If someone has such a = “policy” … the policy is to define the maximum worst-case= TCMTF (encoding) delay. If the TCMTF encoder has not yet built a “ne= ar-MTU” packet and the worst-case delay timer fires … push the packet out!

 

The worst-case TCMTF d= elay we should introduce is determined by the packets we want to multiplex = within a TCMTF packet. If we knew their traffic class … we would have= an idea of what the worst case should be. If we didn’t, but rather made a reasonable assumption (for example, = based on signature analysis), then we push when our idea of what the worst = case has been met.

 

Given that the sentenc= e referenced above is not correct (it has an implicit random arrival proces= s assumption) – we need to clarify it if it is decided to keep it.

 

As Gorry notes in the = next email on this thread, some delay-based congestion controls may respond= to TCMTF-induced delay as an indication of increasing congestion in their = congestion control. Anything we can do to limit the maximum delay (i.e., have a “nice” TCMTF-induc= ed delay distribution) would be appreciated.

 

Michael Ramalho

 

From: tsvwg-bo= unces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Mirko Su=BEnjevic
Sent: Friday, January 18, 2013 5:15 AM
To: FERNANDO PASCUAL BLANCO; tcmtf@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when us= ing Tunneling Compressed Multiplexed Traffic Flows

 

Yes I concur, it is a = good notice. I am adding your comment to the review list for the next versi= on.


Mirko Suznjevic

 

From: FERNANDO= PASCUAL BLANCO [mailto:fpb@tid.es]
Sent: Thursday, January 17, 2013 10:08 AM
To: Mirko Su=BEnjevi=E6; tcmtf@ietf.org; tsvwg@ietf.org
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunn= eling Compressed Multiplexed Traffic Flows

 

Hi Mirk= o,

&n= bsp;

Thank y= ou for considering that. In addition, one more thing: in section 4, the sen= tence "If a policy defining a multiplexing period is used, then the av= erage latency added to each packet will be half the multiplexing period." only applies when there is not enough = packet rate to fulfill a big packet by multiplexing small ones. When  = there is a lot of packets to multiplex, in general, multiplexing period wil= l not be reached, so half the multiplexing period will be the maximum/worse average added delay. In general, and when= TCMTF is working fine, average added delay will be lower.

So, I w= ould rewrite that phrase as: "If a policy defining a multiplexing peri= od is used, then the average latency added to each packet will be half= the time to fulfill a multiplexed one. In the worse case and if the multiplexing period is reached, the average latency = added to each packet will be half the multiplexing period".=

&n= bsp;

What do= you think?

&n= bsp;

Regards= ,

&n= bsp;

Fernand= o Pascual Blanco

Telef= =F3nica Global Resources

Network= Automation and Dynamization

TECHNOL= OGY PEOPLE GROUP

F += 34913128779

M += 34682005168

&n= bsp;

From: Mirko Su=BEnjevi=E6 <Mirko.Suznjevic@fer.hr>
Date: martes, 15 de enero de 2013 16:48
To: Fernando Pascual Blanco <fpb@ti= d.es>, "tcmtf@ietf.org&qu= ot; <tcmtf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunn= eling Compressed Multiplexed Traffic Flows

&n= bsp;

Hello,

Thanks for all the com= ments, I will briefly respond to them, and include your (as well as previou= s) corrections in a new version of the draft:

  • I do not understand the sentence "Therefor= e, we neither take into account services using an approach in which al= l the calculations are deployed in the server, which sends a real-time video stream to the client." in section 3.

The meaning of this se= ntence is that we will not be looking at the cloud based gaming services su= ch as OnLive or Gaiki as they are focused on performing all needed calculat= ions of the gamestate on the server, and sending a very “fat” video stream to the client which only= renders the video. Therefore they are not suitable for tcmtf. I will chang= e that in order to be more clear.

  • In section 3 (Considered Services), I think it = could be also interesting to consider non-real time services candidates to = be TCMTF optimized. For example services like instant messaging, where the bandwidth saving is the main benefit of = the TCMTF optimization, should be somehow mentioned, establishing a kind of= delay upper threshold. Related to that, in section 3, when talking about w= eb browsing, the sentence "there is no need for policy limitations in TCMTF" could be disapp= ointed, because actually there are limitations (ITU-T_G.1010, 10 secon= ds for web browsing, as in section 4.1 10 seconds are considered for stream= ing audio).

At first when we were = discussing we decided that it will be focused on real-time services, but th= is can be broadened to others non-real-time. I think giving such upper limi= ts has a point, although would we even employ tcmtf in cases  in which we will not have enough data to send = a packet in 5 or more seconds? Is that feasible? Maybe in some sensor netwo= rks? Maybe I am just looking it the wrong way, maybe we would have a lot of= traffic that needs to be packed ASAP!

  • In section 4, I would change the sentence "= ;A number of flows are multiplexed together before being sent through = the Internet." for "A number of flows are multiplexed togeth= er before being sent through the network.", because the network could no= t be necessary the Internet, I would also adapt Figure 2.=

Ok will be done.

  • Maybe the creation of a section 4.4 talking abo= ut non real time services could be considered including last comments (acce= ptable with the recommendation appearing in the last sentence of the section 4.3 "It should be noted&nb= sp;that multiplexing periods of about 1 second can be considered as en= ough for non real time services (e.g., web browsing and streaming audi= o).")

Ok, seems sound enough= . I will write it and see which format looks better.

  • Table= 1 could be included in a separate section (i.e. Section 4.5) as a sum= mary

Ok.

 

Thanks again for the f= eedback!

Cheers!
Mirko

 

From: FERNANDO PASCUAL BLANCO [mail= to:fpb@tid.es]
Sent: Tuesday, January 15, 2013 3:42 PM
To: Mirko Su=BEnjevi=E6; tcmtf@iet= f.org; tsvwg@ietf.org
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunn= eling Compressed Multiplexed Traffic Flows

 =

Hi Mirk= o,

 <= /span>

Some co= mments to the draft:

  • In the introduction it says "TCTMF", = it is "TCMTF".
  • = I do not understand the sentence "Therefore, we neither take into= account services using an approach in which all the calculations are = deployed in the server, which sends a real-time video stream to the client." in section 3.
  • In section 3 (Considered Ser= vices), I think it could be also interesting to consider non-real time serv= ices candidates to be TCMTF optimized. For example services like instant messaging, where the bandwidth saving is the main benefit of = the TCMTF optimization, should be somehow mentioned, establishing a kind of= delay upper threshold. Related to that, in section 3, when talking about w= eb browsing, the sentence "there is no need for policy limitations in TCMTF" could be disapp= ointed, because actually there are limitations (ITU-T_G.1010, 10 secon= ds for web browsing, as in section 4.1 10 seconds are considered for stream= ing audio).
  • In section 4,= I would change the sentence "A number of flows are multiplexed t= ogether before being sent through the Internet." for "A number of= flows are multiplexed together before being sent through the network.", because the network could no= t be necessary the Internet, I would also adapt Figure 2.=
  • = Maybe the creation of a section 4.4 talkin= g about non real time services could be considered including last comments = (acceptable with the recommendation appearing in the last sentence of the section 4.3 "It should be noted&nb= sp;that multiplexing periods of about 1 second can be considered as en= ough for non real time services (e.g., web browsing and streaming audi= o).")
  • Table 1 could be included in a separate section (i.e.&= nbsp;Section 4.5) as a summary

Hope to help!=

 <= /span>

Regards= ,

 <= /span>

Fernand= o Pascual Blanco

Telef= =F3nica Global Resources

Network= Automation and Dynamization<= /span>

TECHNOL= OGY PEOPLE GROUP

F += 34913128779

M += 34682005168

 <= /span>

From: Mirko Su=BEnjevi=E6 <Mirko.Suznjevic@fer.hr>
Date: jueves, 13 de diciembre de 2012 10:06
To: "tcmtf@ietf.org"= <tcmtf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunnelin= g Compressed Multiplexed Traffic Flows

 <= /span>

Hello,=

 =

We have just submitted t= he draft named Maximum Tolerable Delays when using Tunneling Compressed Mul= tiplexed Traffic Flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/=

 =

It is an extension of tc= mtf http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a spe= cific list for tcmtf exists (tcmtf@ietf.o= rg), the idea is to discuss it there.

 =

The draft contains recom= mendations for TCMTF multiplexing period for different real-time services. = In order to prevent QoE degradation of real-time services using TCMTF, a po= licy defining  a multiplexing period can be employed. Values of maximum tolerable delays presented in the draft= form the base of such policy.    The recommendations are pr= esented for real-time network services in which TCTMF bandwidth optimizatio= n is applicable (i.e., services  which have low payload to header size ratio which results in high protocol overhead).

 =

Your feedback will be we= lcome. Thank you.


Sincerely,

Mirko Suznjevic

 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/= ES/PAGINAS/disclaimer.aspx

&n= bsp;


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/= ES/PAGINAS/disclaimer.aspx

--_000_D21571530BF9644D9A443D6BD95B9103154C4245xmbrcdx12ciscoc_-- From internet-drafts@ietf.org Tue Jan 22 02:58:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5488F21F8928; Tue, 22 Jan 2013 02:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2Frg18Zq4fp; Tue, 22 Jan 2013 02:58:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4097421F892C; Tue, 22 Jan 2013 02:58:38 -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.37 Message-ID: <20130122105838.22765.24490.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 02:58:38 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-08.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 10:58:39 -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 : UDP Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-08.txt Pages : 10 Date : 2012-12-23 Abstract: This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jan 22 03:12:29 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7107B21F87C5; Tue, 22 Jan 2013 03:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxZh-iv1G+5O; Tue, 22 Jan 2013 03:12:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D316B21F87CE; Tue, 22 Jan 2013 03:12:28 -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.37 Message-ID: <20130122111228.19385.71619.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 03:12:28 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 11:12:29 -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 : UDP Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-09.txt Pages : 10 Date : 2013-01-22 Abstract: This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Tuexen@lurchi.franken.de Tue Jan 22 03:15:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6A921F87CE for ; Tue, 22 Jan 2013 03:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wroSAzLee7K0 for ; Tue, 22 Jan 2013 03:15:36 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1690F21F87C8 for ; Tue, 22 Jan 2013 03:15:35 -0800 (PST) Received: from [10.0.1.109] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1B89A1C0C069F for ; Tue, 22 Jan 2013 12:15:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Michael Tuexen In-Reply-To: <20130122111228.19385.71619.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 12:15:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <11CF4856-C114-49EE-BB39-76F0C1C25120@lurchi.franken.de> References: <20130122111228.19385.71619.idtracker@ietfa.amsl.com> To: "tsvwg@ietf.org list" X-Mailer: Apple Mail (2.1283) Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 11:15:37 -0000 This version addresses some LC comments. Please ignore the -08 version which only contained the bumped version. I'm sorry for the = inconvenience. Best regards Michael On Jan 22, 2013, at 12:12 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Area Working Group Working = Group of the IETF. >=20 > Title : UDP Encapsulation of SCTP Packets > Author(s) : Michael Tuexen > Randall R. Stewart > Filename : draft-ietf-tsvwg-sctp-udp-encaps-09.txt > Pages : 10 > Date : 2013-01-22 >=20 > Abstract: > This document describes a simple method of encapsulating SCTP = Packets > into UDP packets and its limitations. This allows the usage of SCTP > in networks with legacy NAT not supporting SCTP. It can also be = used > to implement SCTP on hosts without directly accessing the IP-layer, > for example implementing it as part of the application without > requiring special privileges. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-09 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 From mthornbu@adobe.com Mon Jan 28 15:58:59 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27DE21F8467 for ; Mon, 28 Jan 2013 15:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqXFJUzbM5Yn for ; Mon, 28 Jan 2013 15:58:58 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 65D2721F843A for ; Mon, 28 Jan 2013 15:58:58 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUQcQwusIvJV2Lb7CR/ueI6aj7v1yXN8j@postini.com; Mon, 28 Jan 2013 15:58:58 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r0SNts1v009566 for ; Mon, 28 Jan 2013 15:55:55 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r0SNwsXM010683 for ; Mon, 28 Jan 2013 15:58:55 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 28 Jan 2013 15:58:54 -0800 From: Michael Thornburgh To: "tsvwg@ietf.org" Date: Mon, 28 Jan 2013 15:58:51 -0800 Thread-Topic: feedback request: draft-thornburgh-adobe-rtmfp Thread-Index: Ac39s2vnDiiS8429RMSUZn9wy7XbEw== Message-ID: <02485FF93524F8408ECA9608E47D9F20092BDF53C7@nambx05.corp.adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] feedback request: draft-thornburgh-adobe-rtmfp X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 23:58:59 -0000 hello TSV Working Group. i have recently uploaded an Internet-Draft describing a vendor network tran= sport protocol, "Secure Real-Time Media Flow Protocol (RTMFP)" from Adobe S= ystems Incorporated. this protocol is the foundation for the real-time and= peer-to-peer communication capabilities in Flash Player and related Adobe = products, which are widely deployed on the Internet today. we believe this= transport protocol has applicability beyond Flash and will be of interest = to the Internet community. this is the protocol presented by Matthew Kaufm= an to the TSV Area at IETF-77. we are looking toward this specification being published as an Informationa= l RFC. to that end i am soliciting feedback, comments, and reviews of the = I-D to gauge community interest and to help us improve its quality. there is IPR associated with this specification, which i have disclosed alo= ng with a royalty-free license declaration. that disclosure/declaration is= linked from the HTML-ized I-D page. --- Filename: draft-thornburgh-adobe-rtmfp Revision: 02 Title: Adobe's Secure Real-Time Media Flow Protocol Creation date: 2013-01-28 WG ID: Individual Submission Number of pages: 93 URL: http://www.ietf.org/internet-drafts/draft-thornburgh-adobe= -rtmfp-02.txt Status: http://datatracker.ietf.org/doc/draft-thornburgh-adobe-rtm= fp Htmlized: http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-thornburgh-adobe-= rtmfp-02 Abstract: This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features making it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used. --- thank you. -michael thornburgh