From Mirko.Suznjevic@fer.hr Thu Dec 13 01:06:57 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ACF21F8A5A; Thu, 13 Dec 2012 01:06:57 -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=[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 EH0SZdnk+Y46; Thu, 13 Dec 2012 01:06:57 -0800 (PST) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8221F8A56; Thu, 13 Dec 2012 01:06:55 -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; Thu, 13 Dec 2012 10:06:38 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Dec 2012 10:06:38 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDD911.289A6CC1" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 13 Dec 2012 10:06:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-Index: Ac3ZESqLi+BkjcfHSsa59QiO7XqseQ== From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: , X-OriginalArrivalTime: 13 Dec 2012 09:06:38.0579 (UTC) FILETIME=[28CCBC30:01CDD911] Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 09:06:57 -0000 ------_=_NextPart_001_01CDD911.289A6CC1 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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 ------_=_NextPart_001_01CDD911.289A6CC1 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

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=A0 a = multiplexing period can be employed. Values of maximum tolerable delays = presented in the draft form the base of such policy.=A0=A0=A0 The = recommendations are presented for real-time network services in which = TCTMF bandwidth optimization is applicable (i.e., services=A0 which have = low payload to header size ratio which results in high protocol = overhead).

Your feedback will be welcome. Thank = you.

Sincerely,

Mirko = Suznjevic

------_=_NextPart_001_01CDD911.289A6CC1-- From dwing@cisco.com Thu Dec 13 08:06:45 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC97821F8BBD for ; Thu, 13 Dec 2012 08:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.322 X-Spam-Level: X-Spam-Status: No, score=-110.322 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 yX1amSHCjp8K for ; Thu, 13 Dec 2012 08:06:45 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4036821F8B6B for ; Thu, 13 Dec 2012 08:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2046; q=dns/txt; s=iport; t=1355414805; x=1356624405; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=RgoyZRVH1gl/ARzNmJy92/EbHQSWhp/lrY/RG7+Cv+M=; b=WB3R75djapYJta/5Q0H8RUGHN3jd6tbvu8zR8G+NrIFeKQlkA5yAiU3U ujnQ+pk9ZxaUfJZlbmA2e+MW8ADWcbkagCXP9Lju8SaiARatJxgWTtJgo aZA03TUDDnlteMd/YEY3DLtxmvz72I7didbCZmWzZsX89FM9YUfW2CMXj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwIALz7yVCrRDoJ/2dsb2JhbABFg0i7JhZzgh4BAQEDAQgCaQsHAQMCCREEAQEkBAcZLQkIAgQBEgsFh30FDb1DjFeEQwOIYIUchFqDM4EcjyyDFA X-IronPort-AV: E=Sophos;i="4.84,274,1355097600"; d="scan'208";a="66475875" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 13 Dec 2012 16:06:44 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBDG6iGh012421; Thu, 13 Dec 2012 16:06:44 GMT From: "Dan Wing" To: "=?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?=" , References: In-Reply-To: Date: Thu, 13 Dec 2012 08:06:44 -0800 Message-ID: <021101cdd94b$d914b540$8b3e1fc0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHNcf5R7vnE/ECBWG34B3Yw3PCUVZgXstCw Content-Language: en-us Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:06:45 -0000 > -----Original Message----- > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf > Of Mirko Su=BEnjevic > Sent: Thursday, December 13, 2012 1:07 AM > To: tcmtf@ietf.org; tsvwg@ietf.org > Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling > Compressed Multiplexed Traffic Flows >=20 > Hello, >=20 >=20 >=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/ The suggested 400ms for interactive voice is at least 2x too high. I expect that number does not include the playout jitter buffer (which is variable, but usually a few samples, so 40-80ms). 200ms=20 end-to-end is the higher end, and that includes jitter buffer, codec=20 processing, and so on. But, more importantly: it seems valuable for endpoints to signal their maximum delay somehow. Or would the TCMTF function determine the maximum delay, using some heuristic? How does the TCMTF function determine how much of that 'tolerable latency' budget it can consume? -d > 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 >=20 >=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 >=20 >=20 > Your feedback will be welcome. Thank you. >=20 >=20 > Sincerely, >=20 > Mirko Suznjevic From jsaldana@unizar.es Fri Dec 14 02:48:47 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E740221F8695 for ; Fri, 14 Dec 2012 02:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, 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 atcQrqozg4x6 for ; Fri, 14 Dec 2012 02:48:47 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0B21F85A6 for ; Fri, 14 Dec 2012 02:48:45 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id qBEAmbje007630; Fri, 14 Dec 2012 11:48:37 +0100 From: "Jose Saldana" To: "'Dan Wing'" , "=?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?=" Date: Fri, 14 Dec 2012 11:48:46 +0100 Organization: Universidad de Zaragoza Message-ID: <005701cdd9e8$97cd59f0$c7680dd0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3Z6FrGGL1Sv2NVQcusvgwQMFS9Wg== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 10:48:48 -0000 Dan, Thanks for your feedback. 1) Regarding the question of 400 ms OWD for VoIP: If ITU says that = delays between 150 and 400 ms are acceptable, perhaps we could distinguish = between high-quality and non-high-quality VoIP. Does this make sense? The users = of some free-of-charge VoIP services may tolerate higher delays. 2) Regarding the jitter buffer, currently the draft doesn't talk about = it. So I think we should include some reference to that buffer. For online games, we cannot talk about it, since the implementation is not = (usually) public, but in VoIP it exists. What happens with Remote Desktop applications? Mirko, do you know if something similar to jitter buffer exists for any = game genre? And with respect to the OWD estimation, I send another mail. Thanks, Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Dan Wing > Enviado el: jueves, 13 de diciembre de 2012 17:07 > Para: 'Mirko Su=BEnjevi=E6'; tcmtf@ietf.org > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling > Compressed Multiplexed Traffic Flows >=20 > > -----Original Message----- > > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On = Behalf > > Of Mirko Su=BEnjevic > > Sent: Thursday, December 13, 2012 1:07 AM > > To: tcmtf@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/ >=20 > The suggested 400ms for interactive voice is at least 2x too high. I expect > that number does not include the playout jitter buffer (which is = variable, but > usually a few samples, so 40-80ms). 200ms end-to-end is the higher = end, and > that includes jitter buffer, codec processing, and so on. >=20 > But, more importantly: it seems valuable for endpoints to signal = their > maximum delay somehow. Or would the TCMTF function determine the > maximum delay, using some heuristic? >=20 > How does the TCMTF function determine how much of that 'tolerable > latency' budget it can consume? >=20 > -d >=20 >=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. > > > > > > > > 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 >=20 >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From jsaldana@unizar.es Fri Dec 14 02:58:03 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B021F8460 for ; Fri, 14 Dec 2012 02:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, 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 PYbgz1nCGsa9 for ; Fri, 14 Dec 2012 02:58:02 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id E54C921F86AA for ; Fri, 14 Dec 2012 02:58:01 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id qBEAvqa0027920; Fri, 14 Dec 2012 11:57:52 +0100 From: "Jose Saldana" To: "'Dan Wing'" , "=?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?=" Date: Fri, 14 Dec 2012 11:58:03 +0100 Organization: Universidad de Zaragoza Message-ID: <005801cdd9e9$e3c49110$ab4db330$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3Z6Jq1RkIy9F5oRC6RKizhzgYygw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 10:58:03 -0000 Dan, Regarding the use of the maximum delay, some days ago we discussed about = it: the actual OWD of the network should be measured (or estimated) in order = to know the maximum multiplexing period we can set. We may have this formula, if thinking one-way: OWD + Mux period/2 < tolerable_OWD If we think RTT: OWD + Mux period/2 + OWD back < 2*tolerable_OWD I don't know if we should include a mechanism for estimating OWD in = tcmtf. I think this is more an implementation problem, which may be already = solved. Another option is using some typical values, e.g. from http://ipnetwork.bgtmo.ip.att.net/pws/global_network_avgs.html The draft includes some preliminary/recommended values for the = Multiplexing Period. Is this interesting? Should we put the formula instead? Mirko, another question: in online games, players usually talk about the "ping", and I think it means RTT. Don't you think it would be better to define a RTT limit instead of a OWD one in that case? What do you think?=20 Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Dan Wing > Enviado el: jueves, 13 de diciembre de 2012 17:07 > Para: 'Mirko Su=BEnjevi=E6'; tcmtf@ietf.org > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling > Compressed Multiplexed Traffic Flows >=20 > > -----Original Message----- > > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On = Behalf > > Of Mirko Su=BEnjevic > > Sent: Thursday, December 13, 2012 1:07 AM > > To: tcmtf@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/ >=20 > The suggested 400ms for interactive voice is at least 2x too high. I expect > that number does not include the playout jitter buffer (which is = variable, but > usually a few samples, so 40-80ms). 200ms end-to-end is the higher = end, and > that includes jitter buffer, codec processing, and so on. >=20 > But, more importantly: it seems valuable for endpoints to signal = their > maximum delay somehow. Or would the TCMTF function determine the > maximum delay, using some heuristic? >=20 > How does the TCMTF function determine how much of that 'tolerable > latency' budget it can consume? >=20 > -d >=20 >=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. > > > > > > > > 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 >=20 >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From Mirko.Suznjevic@fer.hr Fri Dec 14 04:44:09 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA6B21F85FC for ; Fri, 14 Dec 2012 04:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 8xlDAgMrvaCX for ; Fri, 14 Dec 2012 04:44:08 -0800 (PST) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by ietfa.amsl.com (Postfix) with ESMTP id E4A5C21F85FA for ; Fri, 14 Dec 2012 04:44:06 -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, 14 Dec 2012 13:44:04 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Dec 2012 13:43:49 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 14 Dec 2012 13:43:52 +0100 Message-ID: In-Reply-To: <005801cdd9e9$e3c49110$ab4db330$@unizar.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-Index: Ac3Z6Jq1RkIy9F5oRC6RKizhzgYygwADBjUg References: <005801cdd9e9$e3c49110$ab4db330$@unizar.es> From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: , Dan Wing X-OriginalArrivalTime: 14 Dec 2012 12:43:49.0626 (UTC) FILETIME=[AA5275A0:01CDD9F8] Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:44:09 -0000 Hello, Just a quick response. As a response on the first question: I am not = aware of any such mechanisms being employed in games, but as Jose said a = great majority of games has proprietary sources.=20 As for the other question, yes we might be better off reporting RTT in = terms of games, as most players just look at "ping" and that is RTT. = Maybe even from a overall standpoint it would be better to report RTT = for the sake of simplicity and clarity of the formulas? Mirko -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es]=20 Sent: Friday, December 14, 2012 11:58 AM To: 'Dan Wing'; Mirko Su=BEnjevi=E6 Cc: tcmtf@ietf.org Subject: RE: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling Compressed Multiplexed Traffic Flows Dan, Regarding the use of the maximum delay, some days ago we discussed about = it: the actual OWD of the network should be measured (or estimated) in order = to know the maximum multiplexing period we can set. We may have this formula, if thinking one-way: OWD + Mux period/2 < tolerable_OWD If we think RTT: OWD + Mux period/2 + OWD back < 2*tolerable_OWD I don't know if we should include a mechanism for estimating OWD in = tcmtf. I think this is more an implementation problem, which may be = already solved. Another option is using some typical values, e.g. from = http://ipnetwork.bgtmo.ip.att.net/pws/global_network_avgs.html The draft includes some preliminary/recommended values for the = Multiplexing Period. Is this interesting? Should we put the formula = instead? Mirko, another question: in online games, players usually talk about the = "ping", and I think it means RTT. Don't you think it would be better to = define a RTT limit instead of a OWD one in that case? What do you think?=20 Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre=20 > de Dan Wing Enviado el: jueves, 13 de diciembre de 2012 17:07 > Para: 'Mirko Su=BEnjevi=E6'; tcmtf@ietf.org > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using=20 > Tunneling Compressed Multiplexed Traffic Flows >=20 > > -----Original Message----- > > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On=20 > > Behalf Of Mirko Su=BEnjevic > > Sent: Thursday, December 13, 2012 1:07 AM > > To: tcmtf@ietf.org; tsvwg@ietf.org > > Subject: [tcmtf] Draft: Maximum Tolerable Delays when using=20 > > 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/ >=20 > The suggested 400ms for interactive voice is at least 2x too high. I expect > that number does not include the playout jitter buffer (which is=20 > variable, but > usually a few samples, so 40-80ms). 200ms end-to-end is the higher=20 > end, and > that includes jitter buffer, codec processing, and so on. >=20 > But, more importantly: it seems valuable for endpoints to signal=20 > their maximum delay somehow. Or would the TCMTF function determine=20 > the maximum delay, using some heuristic? >=20 > How does the TCMTF function determine how much of that 'tolerable=20 > latency' budget it can consume? >=20 > -d >=20 >=20 > > It is an extension of tcmtf http://datatracker.ietf.org/doc/draft- > > saldana-tsvwg-tcmtf/. Since a specific list for tcmtf exists=20 > > (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=20 > > 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 >=20 >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From navajas@unizar.es Fri Dec 14 04:57:56 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F40621F86C3 for ; Fri, 14 Dec 2012 04:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vs2atbImwmw9 for ; Fri, 14 Dec 2012 04:57:55 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6896921F86C1 for ; Fri, 14 Dec 2012 04:57:55 -0800 (PST) Received: from [155.210.156.37] (tele3.cps.unizar.es [155.210.156.37]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id qBECvoRS024677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Dec 2012 13:57:50 +0100 Message-ID: <50CB224C.40202@unizar.es> Date: Fri, 14 Dec 2012 13:57:48 +0100 From: =?UTF-8?B?SnVsacOhbiBGZXJuw6FuZGV6LU5hdmFqYXM=?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: tcmtf@ietf.org References: <005701cdd9e8$97cd59f0$c7680dd0$@unizar.es> In-Reply-To: <005701cdd9e8$97cd59f0$c7680dd0$@unizar.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:57:56 -0000 Hello, I agree with Jose in order to distinguish between high and non high quality VoIP. The ITU-T Rec. G.114 defines several levels of user acceptance: Users very satisfied (0-200 ms OWD total value of one-way delay from mouth-to-ear), users satisfied (200-300ms), some user dissatisfied (300-400ms), many users dissatisfied (400-500ms) and Nearly all users dissatisfied (>500ms). Perhaps it would be fine define three levels for the OWD in VoIP: high quality (<200ms), acceptable quality (200-300ms) and no acceptable quality (>300ms) Julián El 14/12/2012 11:48, Jose Saldana escribió: > Dan, > > Thanks for your feedback. > > 1) Regarding the question of 400 ms OWD for VoIP: If ITU says that delays > between 150 and 400 ms are acceptable, perhaps we could distinguish between > high-quality and non-high-quality VoIP. Does this make sense? The users of > some free-of-charge VoIP services may tolerate higher delays. > > 2) Regarding the jitter buffer, currently the draft doesn't talk about it. > So I think we should include some reference to that buffer. For online > games, we cannot talk about it, since the implementation is not (usually) > public, but in VoIP it exists. > > What happens with Remote Desktop applications? > > Mirko, do you know if something similar to jitter buffer exists for any game > genre? > > And with respect to the OWD estimation, I send another mail. > > Thanks, > > Jose > >> -----Mensaje original----- >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de >> Dan Wing >> Enviado el: jueves, 13 de diciembre de 2012 17:07 >> Para: 'Mirko Sužnjević'; tcmtf@ietf.org >> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling >> Compressed Multiplexed Traffic Flows >> >>> -----Original Message----- >>> From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf >>> Of Mirko Sužnjevic >>> Sent: Thursday, December 13, 2012 1:07 AM >>> To: tcmtf@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/ >> The suggested 400ms for interactive voice is at least 2x too high. I > expect >> that number does not include the playout jitter buffer (which is variable, > but >> usually a few samples, so 40-80ms). 200ms end-to-end is the higher end, > and >> that includes jitter buffer, codec processing, and so on. >> >> But, more importantly: it seems valuable for endpoints to signal their >> maximum delay somehow. Or would the TCMTF function determine the >> maximum delay, using some heuristic? >> >> How does the TCMTF function determine how much of that 'tolerable >> latency' budget it can consume? >> >> -d >> >> >>> 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 >> >> _______________________________________________ >> tcmtf mailing list >> tcmtf@ietf.org >> https://www.ietf.org/mailman/listinfo/tcmtf > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf > > From dwing@cisco.com Fri Dec 14 09:28:46 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829DC21F8A10 for ; Fri, 14 Dec 2012 09:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.337 X-Spam-Level: X-Spam-Status: No, score=-110.337 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 g5pzb8SeWRqk for ; Fri, 14 Dec 2012 09:28:45 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C7DF421F8B30 for ; Fri, 14 Dec 2012 09:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5546; q=dns/txt; s=iport; t=1355506125; x=1356715725; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=FCGkTzOpS6HCIr0/wreG538p5SClednzJ4uWAwrzoyc=; b=Kgf29seoK6WMwRtCFdeNxi8BM6Zjb2rbMluWq7ol8NfUWGgAAsTnWVFV Fz1aaJ0UY8mYm662Z/bZeTqJpqxpGVONNwboBl9vopv+ZUUaFljbr4Imr hhxN46oBE7PFdNv7spqzJRTAQ/o0wr7en/DDyFoA1HclSLFxt3vr7OPJe 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikHAIhhy1CrRDoJ/2dsb2JhbABFg0iCcLhNFnOCHgEBAQMBAQEBBQIZSwULBwEDAgkRBAEBAwIfBAMCAhkOHwkIAgQBEgsFh30FDal9kwiBIos1G4MVgRMDiGCFHIRagzOBHI8sgxSBTA X-IronPort-AV: E=Sophos;i="4.84,282,1355097600"; d="scan'208";a="63471780" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 14 Dec 2012 17:28:34 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBEHSYNQ020956; Fri, 14 Dec 2012 17:28:34 GMT From: "Dan Wing" To: "=?UTF-8?Q?'Juli=C3=A1n_Fern=C3=A1ndez-Navajas'?=" , References: <005701cdd9e8$97cd59f0$c7680dd0$@unizar.es> <50CB224C.40202@unizar.es> In-Reply-To: <50CB224C.40202@unizar.es> Date: Fri, 14 Dec 2012 09:28:34 -0800 Message-ID: <036601cdda20$71c2e8a0$5548b9e0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGnpSEzhEalTw2TO1ez5XdmnoiPgQE+VvC7mFsCoKA= Content-Language: en-us Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:28:46 -0000 > -----Original Message----- > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf > Of Juli=C3=A1n Fern=C3=A1ndez-Navajas > Sent: Friday, December 14, 2012 4:58 AM > To: tcmtf@ietf.org > Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using > Tunneling Compressed Multiplexed Traffic Flows >=20 > Hello, > I agree with Jose in order to distinguish between high and non high > quality VoIP. > The ITU-T Rec. G.114 defines several levels of user acceptance: Users > very satisfied (0-200 ms OWD total value of one-way delay from = mouth-to- > ear), users satisfied (200-300ms), some user dissatisfied (300-400ms), > many users dissatisfied (400-500ms) and Nearly all users dissatisfied > (>500ms). > Perhaps it would be fine define three levels for the OWD in VoIP: high > quality (<200ms), acceptable quality (200-300ms) and no acceptable > quality (>300ms) Juli=C3=A1n That sounds like a good place to start. Mouth-to-ear delay is the total delay, and we cannot consume the total delay in the network -- there are other delays that consume part of the delay budget. Those include the sender's codec delay (which varies=20 depending on compression and speed of its processor) and the = packetization=20 interval (the sender does not send a continuous stream of bits). On the receiver we have the jitter buffer (~20-60ms or more) and its codec=20 (which varies depending on compression and speed of its processor). -d > El 14/12/2012 11:48, Jose Saldana escribi=C3=B3: > > Dan, > > > > Thanks for your feedback. > > > > 1) Regarding the question of 400 ms OWD for VoIP: If ITU says that > > delays between 150 and 400 ms are acceptable, perhaps we could > > distinguish between high-quality and non-high-quality VoIP. Does = this > > make sense? The users of some free-of-charge VoIP services may > tolerate higher delays. > > > > 2) Regarding the jitter buffer, currently the draft doesn't talk = about > it. > > So I think we should include some reference to that buffer. For = online > > games, we cannot talk about it, since the implementation is not > > (usually) public, but in VoIP it exists. > > > > What happens with Remote Desktop applications? > > > > Mirko, do you know if something similar to jitter buffer exists for > > any game genre? > > > > And with respect to the OWD estimation, I send another mail. > > > > Thanks, > > > > Jose > > > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En = nombre > >> de Dan Wing Enviado el: jueves, 13 de diciembre de 2012 17:07 > >> Para: 'Mirko Su=C5=BEnjevi=C4=87'; tcmtf@ietf.org > >> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using > >> Tunneling Compressed Multiplexed Traffic Flows > >> > >>> -----Original Message----- > >>> From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On > >>> Behalf Of Mirko Su=C5=BEnjevic > >>> Sent: Thursday, December 13, 2012 1:07 AM > >>> To: tcmtf@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/ > >> The suggested 400ms for interactive voice is at least 2x too high. = I > > expect > >> that number does not include the playout jitter buffer (which is > >> variable, > > but > >> usually a few samples, so 40-80ms). 200ms end-to-end is the higher > >> end, > > and > >> that includes jitter buffer, codec processing, and so on. > >> > >> But, more importantly: it seems valuable for endpoints to signal > >> their maximum delay somehow. Or would the TCMTF function determine > >> the maximum delay, using some heuristic? > >> > >> How does the TCMTF function determine how much of that 'tolerable > >> latency' budget it can consume? > >> > >> -d > >> > >> > >>> 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 > >> > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf > > > > >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From dwing@cisco.com Fri Dec 14 09:32:42 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1B21F8A82 for ; Fri, 14 Dec 2012 09:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.335 X-Spam-Level: X-Spam-Status: No, score=-110.335 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 wL2EZwg0nUfS for ; Fri, 14 Dec 2012 09:32:41 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA0E21F8A6C for ; Fri, 14 Dec 2012 09:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4715; q=dns/txt; s=iport; t=1355506361; x=1356715961; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=X29YYDH1Im9UWx/hGfFhAJsySkJhpLjnJIXZMchwmnI=; b=TQnj+lMDm+fUtmNFkcezlLZ8lc8l3EnNOkMG1+0gwp5qJeyPY8+k9UvV ZIbsNqpJlgALkh9aAJBymg3+i47NvvMJqpkA1wnSnLsojHGX+TYY8uHs0 uyixvm6lFhmlHNkSlwtcBEX4gayyPuineJ9HO0HdCwgTDqnT9FdtwBcN9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicHAIhhy1CrRDoI/2dsb2JhbABFg0i7PRZzgh4BAQEDAQEBAQUCZAUGBQcBAwIJEQQBASQEBxkOHwkIAgQBEgsFh3EDCQUNsyMFiV2MVxaELQOIYIUchFqDM4EcjyyDFIFE X-IronPort-AV: E=Sophos;i="4.84,282,1355097600"; d="scan'208";a="63472033" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 14 Dec 2012 17:32:41 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBEHWfVH021604; Fri, 14 Dec 2012 17:32:41 GMT From: "Dan Wing" To: , "=?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?=" References: <005801cdd9e9$e3c49110$ab4db330$@unizar.es> In-Reply-To: <005801cdd9e9$e3c49110$ab4db330$@unizar.es> Date: Fri, 14 Dec 2012 09:32:41 -0800 Message-ID: <036801cdda21$04e70f80$0eb52e80$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKQCDtBz71cID9veU3M31u25r+hkJaUMKRQ Content-Language: en-us Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:32:42 -0000 > -----Original Message----- > From: Jose Saldana [mailto:jsaldana@unizar.es] > Sent: Friday, December 14, 2012 2:58 AM > To: 'Dan Wing'; 'Mirko Su=BEnjevi=E6' > Cc: tcmtf@ietf.org > Subject: RE: [tcmtf] Draft: Maximum Tolerable Delays when using > Tunneling Compressed Multiplexed Traffic Flows >=20 > Dan, >=20 > Regarding the use of the maximum delay, some days ago we discussed = about > it: > the actual OWD of the network should be measured (or estimated) in = order > to know the maximum multiplexing period we can set. >=20 > We may have this formula, if thinking one-way: >=20 > OWD + Mux period/2 < tolerable_OWD >=20 > If we think RTT: >=20 > OWD + Mux period/2 + OWD back < 2*tolerable_OWD >=20 > I don't know if we should include a mechanism for estimating OWD in > tcmtf. I think this is more an implementation problem, which may be > already solved. Yes, it's already solved end-to-end: RTP with RTCP feedback allows=20 determining one way delay. But if something in the middle is multiplexing several packets together, we don't want it to add too much delay. That thing in the middle=20 won't necessarily know the one way delay seen by the endpoints, unless it analyzes the RTP and RTCP. There are devices that do that on=20 the market, mostly to diagnose where networks are causing loss/delay with RTP flows. > Another option is using some typical values, e.g. from > http://ipnetwork.bgtmo.ip.att.net/pws/global_network_avgs.html >=20 > The draft includes some preliminary/recommended values for the > Multiplexing Period. Is this interesting? Should we put the formula > instead? It's probably sufficient as-is. -d > Mirko, another question: in online games, players usually talk about = the > "ping", and I think it means RTT. Don't you think it would be better = to > define a RTT limit instead of a OWD one in that case? >=20 > What do you think? >=20 > Jose >=20 > > -----Mensaje original----- > > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre > > de Dan Wing Enviado el: jueves, 13 de diciembre de 2012 17:07 > > Para: 'Mirko Su=BEnjevi=E6'; tcmtf@ietf.org > > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using > > Tunneling Compressed Multiplexed Traffic Flows > > > > > -----Original Message----- > > > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On > > > Behalf Of Mirko Su=BEnjevic > > > Sent: Thursday, December 13, 2012 1:07 AM > > > To: tcmtf@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/ > > > > The suggested 400ms for interactive voice is at least 2x too high. = I > expect > > that number does not include the playout jitter buffer (which is > > variable, > but > > usually a few samples, so 40-80ms). 200ms end-to-end is the higher > > end, > and > > that includes jitter buffer, codec processing, and so on. > > > > But, more importantly: it seems valuable for endpoints to signal > > their maximum delay somehow. Or would the TCMTF function determine > > the maximum delay, using some heuristic? > > > > How does the TCMTF function determine how much of that 'tolerable > > latency' budget it can consume? > > > > -d > > > > > > > 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 > > > > > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf From jsaldana@unizar.es Mon Dec 17 03:26:01 2012 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8438621F8A98 for ; Mon, 17 Dec 2012 03:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 ihyBukkfjj-r for ; Mon, 17 Dec 2012 03:26:00 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id F213421F880D for ; Mon, 17 Dec 2012 03:25:57 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id qBHBPaj6027265; Mon, 17 Dec 2012 12:25:36 +0100 From: "Jose Saldana" To: "'Dan Wing'" , "=?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?=" , =?iso-8859-2?Q?Juli=E1n_Fern=E1ndez_Navajas?= Date: Mon, 17 Dec 2012 12:25:38 +0100 Organization: Universidad de Zaragoza Message-ID: <004c01cddc49$3e7264a0$bb572de0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3cRwhh4m0v9700QW6ztHWMDN8Brg== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:26:01 -0000 Hi all, Julian and I have been discussing about this. Some ideas have arisen. = This is the summary. This would be the scheme of the system, including mux and demux: Real-time application ------- mux -------- internet --------- demux = ------- server I think perhaps the draft could say something like: When setting the multiplexing period, there are two possibilities: 1.- Static / permanent: At system setup time, network delays are = measured, and a multiplexing period is selected and set in the multiplexer. 2.- Dynamic: A mechanism is used so as to adapt to the evolution of = network delays. In this case, different mechanisms can be used in order to = obtain periodical end-to-end network delay estimations, which would be useful = in order to set the multiplexing period: - If the traffic is RTP, then RTCP packets containing the estimation = could be analyzed in order to extract these values, as Dan suggests. The = question is: would that packets travel through the multiplexer? - If the traffic is TCP, perhaps something similar to the RTT estimation = of TCP could be useful. - If the traffic is UDP, should the mux use something like OWAMP (http://tools.ietf.org/html/rfc4656) in order to calculate two delays (application to mux, and mux to server) and calculate the sum?=20 I think the draft is only supposed to report the maximum delays normally considered acceptable. Perhaps the additional mechanisms for calculating = the RTT could just be suggested. What do you think? Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Dan Wing > Enviado el: viernes, 14 de diciembre de 2012 18:33 > Para: jsaldana@unizar.es; 'Mirko Su=BEnjevi=E6' > CC: tcmtf@ietf.org > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using = Tunneling > Compressed Multiplexed Traffic Flows >=20 > > -----Original Message----- > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > Sent: Friday, December 14, 2012 2:58 AM > > To: 'Dan Wing'; 'Mirko Su=BEnjevi=E6' > > Cc: tcmtf@ietf.org > > Subject: RE: [tcmtf] Draft: Maximum Tolerable Delays when using > > Tunneling Compressed Multiplexed Traffic Flows > > > > Dan, > > > > Regarding the use of the maximum delay, some days ago we discussed > > about > > it: > > the actual OWD of the network should be measured (or estimated) in > > order to know the maximum multiplexing period we can set. > > > > We may have this formula, if thinking one-way: > > > > OWD + Mux period/2 < tolerable_OWD > > > > If we think RTT: > > > > OWD + Mux period/2 + OWD back < 2*tolerable_OWD > > > > I don't know if we should include a mechanism for estimating OWD in > > tcmtf. I think this is more an implementation problem, which may be > > already solved. >=20 > Yes, it's already solved end-to-end: RTP with RTCP feedback allows > determining one way delay. >=20 > But if something in the middle is multiplexing several packets = together, we > don't want it to add too much delay. That thing in the middle won't > necessarily know the one way delay seen by the endpoints, unless it > analyzes the RTP and RTCP. There are devices that do that on the = market, > mostly to diagnose where networks are causing loss/delay with RTP = flows. >=20 >=20 > > Another option is using some typical values, e.g. from > > http://ipnetwork.bgtmo.ip.att.net/pws/global_network_avgs.html > > > > The draft includes some preliminary/recommended values for the > > Multiplexing Period. Is this interesting? Should we put the formula > > instead? >=20 > It's probably sufficient as-is. >=20 > -d >=20 > > Mirko, another question: in online games, players usually talk about > > the "ping", and I think it means RTT. Don't you think it would be > > better to define a RTT limit instead of a OWD one in that case? > > > > What do you think? > > > > Jose > > > > > -----Mensaje original----- > > > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En = nombre > > > de Dan Wing Enviado el: jueves, 13 de diciembre de 2012 17:07 > > > Para: 'Mirko Su=BEnjevi=E6'; tcmtf@ietf.org > > > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using > > > Tunneling Compressed Multiplexed Traffic Flows > > > > > > > -----Original Message----- > > > > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On > > > > Behalf Of Mirko Su=BEnjevic > > > > Sent: Thursday, December 13, 2012 1:07 AM > > > > To: tcmtf@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/ > > > > > > The suggested 400ms for interactive voice is at least 2x too high. > > > I > > expect > > > that number does not include the playout jitter buffer (which is > > > variable, > > but > > > usually a few samples, so 40-80ms). 200ms end-to-end is the = higher > > > end, > > and > > > that includes jitter buffer, codec processing, and so on. > > > > > > But, more importantly: it seems valuable for endpoints to signal > > > their maximum delay somehow. Or would the TCMTF function > determine > > > the maximum delay, using some heuristic? > > > > > > How does the TCMTF function determine how much of that 'tolerable > > > latency' budget it can consume? > > > > > > -d > > > > > > > > > > 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 > > > > > > > > > _______________________________________________ > > > tcmtf mailing list > > > tcmtf@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcmtf >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf