I will try to jump start the discussion. I'm not a gaming console= vendor but sometimes deal with issues in this space due to ISP worries.

Inline with [RP]

From: Jose Saldana <jsaldana@unizar.es>
Organization: Universidad de Zarago= za
Reply-To: "jsaldana@unizar.es" <jsaldana@unizar.es>
Date: Monday, September 16, 2013 6:= 53 AM
To: "tsv-area@ietf.org" <tsv-area@ietf.org>, "tc= mtf@ietf.org" <tcmtf@ietf.org= >
Subject: TCM-TF: topics to be discu= ssed in the list

Hi all. I have been reading thr= ough the minutes of the BoF in Berlin, and I think we have to discuss about= some things, and then improve the documents and the charter proposal accor= dingly.

These things are to be discusse= d in the tcmtf@ietf.org mailing list. We would like to ask people interested to = subscribe to that list, in order to get their opinions and to get a fruitfu= l discussion (https://www.ietf.org/mailman/listinfo/tcmtf).

Reading the BoF minutes (http://www.ietf.org/proceedings/87/minutes/minutes-87-tc= mtf), if we remove TCP optimization from the proposal, these would be the remaining qu= estions (IMO):

1) It is clear that some TCP fu= nctions can be impacted by TCM-TF, so let us assume that we remove from the= charter the possibility of multiplexing TCP flows. Do we still need some o= f that TCP functions? If the answer is =93yes=94, then we have a problem.

2) =93This is not being done by a host; it is in network, if a=
 separator does not include timing, it could lose delay signals for congest=
ion control based on delay=94.

3) Path MTU discovery issues

[RP] Very important issue. There are some gaming consoles that &= nbsp;just by putting their packets in a lightweight UDP tunnel you get a me= ssage saying you have MTU issues and everything stops. Debugging is up to t= he user.

4) Are we =93adding latency and= complexity to save relatively little bandwidth=94? Additional delays: =93b= ufferbloat - could be increasing buffers to group packets up.=94 Are we add= ing undesired delays?

[RP] I can not really answer the complexity trade-off question but my = feedback is that adding any latency to multiplayer games like CoD seems lik= e a bad idea. ISPs constantly get complains from multiplayer CoD users abou= t delay (and by delay I mean very low numbers like 20ms increases). Not only affects their score but whether= others will play with them. Maybe if you combine this bigger packet = with a a low latency queue in their CPE/Hotspot it might be an acceptable s= olution, not sure, need more digging.

5) =93Do vendors want standards= in this space? There are a lot of proprietary products; I would like to he= ar from other vendors who also would like to see this.=94

[RP] It would be good to also get opinions from the folks that w= ould be affected by this proposal such as XBOX, WoW developers.

6) =93application can sometimes= send multiple packets with the same message so that they have unique proba= bility of loss (not correlated), this is an application choice that needs t= o be known by a tunnel.=94

Any other questions?=

Thanks a lot,=

Jose Saldana

--_000_45A697A8FFD7CF48BCF2BE7E106F06040B6D884Dxmbrcdx04ciscoc_-- From jsaldana@unizar.es Wed Sep 18 06:59:15 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E96111E82D7; Wed, 18 Sep 2013 06:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.346 X-Spam-Level: X-Spam-Status: No, score=-4.346 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb5Q-fF5RkzO; Wed, 18 Sep 2013 06:59:10 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1356D11E82AF; Wed, 18 Sep 2013 06:59:06 -0700 (PDT) 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 r8IDwrQo027357; Wed, 18 Sep 2013 15:58:53 +0200 From: "Jose Saldana" To: "'Reinaldo Penno $repenno$'" , , References: <016501ceb2e4$1435f090$3ca1d1b0$@unizar.es> <45A697A8FFD7CF48BCF2BE7E106F06040B6D884D@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B6D884D@xmb-rcd-x04.cisco.com> Subject: RE: TCM-TF: topics to be discussed in the list Date: Wed, 18 Sep 2013 15:58:57 +0200 Organization: Universidad de Zaragoza Message-ID: <00cd01ceb477$3b77d4e0$b2677ea0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01CEB487.FF020470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLjwbASlDUCai4022zPiZ/JpfWAqpehZiPw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 13:59:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CE_01CEB487.FF020470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reinaldo, Thanks a lot and welcome to the list! Some other comments inline. Jose De: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Enviado el: lunes, 16 de septiembre de 2013 22:58 Para: jsaldana@unizar.es; tsv-area@ietf.org; tcmtf@ietf.org Asunto: Re: TCM-TF: topics to be discussed in the list Hello Jose, I will try to jump start the discussion. I'm not a gaming console vendor but sometimes deal with issues in this space due to ISP worries. Inline with [RP] From: Jose Saldana Organization: Universidad de Zaragoza Reply-To: "jsaldana@unizar.es" Date: Monday, September 16, 2013 6:53 AM To: "tsv-area@ietf.org" , "tcmtf@ietf.org" Subject: TCM-TF: topics to be discussed in the list Hi all. I have been reading through the minutes of the BoF in Berlin, and I think we have to discuss about some things, and then improve the documents and the charter proposal accordingly. These things are to be discussed in the tcmtf@ietf.org mailing list. We would like to ask people interested to subscribe to that list, in order to get their opinions and to get a fruitful discussion ( https://www.ietf.org/mailman/listinfo/tcmtf). Reading the BoF minutes ( http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf), if we remove TCP optimization from the proposal, these would be the remaining questions (IMO): 1) It is clear that some TCP functions can be impacted by TCM-TF, so let us assume that we remove from the charter the possibility of multiplexing TCP flows. Do we still need some of that TCP functions? If the answer is "yes", then we have a problem. 2) "This is not being done by a host; it is in network, if a separator does not include timing, it could lose delay signals for congestion control based on delay". 3) Path MTU discovery issues [RP] Very important issue. There are some gaming consoles that just by putting their packets in a lightweight UDP tunnel you get a message saying you have MTU issues and everything stops. Debugging is up to the user. [Jose] Which game genre are you talking about? Perhaps this only happens when the console is sending MTU packets. Real-time games usually send very small ones, but this is a very interesting topic we have to study. 4) Are we "adding latency and complexity to save relatively little bandwidth"? Additional delays: "bufferbloat - could be increasing buffers to group packets up." Are we adding undesired delays? [RP] I can not really answer the complexity trade-off question but my feedback is that adding any latency to multiplayer games like CoD seems like a bad idea. ISPs constantly get complains from multiplayer CoD users about delay (and by delay I mean very low numbers like 20ms increases). Not only affects their score but whether others will play with them. Maybe if you combine this bigger packet with a a low latency queue in their CPE/Hotspot it might be an acceptable solution, not sure, need more digging. [Jose] The idea of this is that we would only consider it for the "rush hour", when the alternative is "additional delay" or "no service". But this is not only for games. It can also be useful for VoIP (in fact, RFC4170 already exists and it does exactly this), and for Machine to Machine communications. Regarding games, this may happen in certain moments/points in the network due to different causes: release of a new game (or new content in an existing game). In addition, we are considering a second draft with the delay limits for each service. If the limit is 10 ms for a game, the bandwidth savings can still be high if the number of players is big enough (Counter Strike: 20 players, 10 ms, 25% savings, see 8 games in http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf) 5) "Do vendors want standards in this space? There are a lot of proprietary products; I would like to hear from other vendors who also would like to see this." [RP] It would be good to also get opinions from the folks that would be affected by this proposal such as XBOX, WoW developers. [Jose] The problem is that gaming companies do not participate in the IETF activities. I have only participated in a research proposal with a gaming company. They can be interested, but they do not worry too much about standards, they just want their games to work 24/7. 6) "application can sometimes send multiple packets with the same message so that they have unique probability of loss (not correlated), this is an application choice that needs to be known by a tunnel." Any other questions? Thanks a lot, Jose Saldana ------=_NextPart_000_00CE_01CEB487.FF020470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reinaldo,

Thanks a = lot and welcome to the list!

Some other = comments inline.

Jose

De: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] =
Enviado el: lunes, 16 de septiembre de 2013 = 22:58
Para: jsaldana@unizar.es; tsv-area@ietf.org; = tcmtf@ietf.org
Asunto: Re: TCM-TF: topics to be discussed in = the list

Hello = Jose,

I = will try to jump start the discussion. I'm not a gaming console = vendor but sometimes deal with issues in this space due to ISP = worries.

Inline with = [RP]

From: = Jose Saldana <jsaldana@unizar.es>
Organ= ization: Universidad de Zaragoza
Reply-To: "jsaldana@unizar.es" <jsaldana@unizar.es>
Date:= Monday, September 16, 2013 6:53 AM
To: "tsv-area@ietf.org" <tsv-area@ietf.org>, "tcmtf@ietf.org" <tcmtf@ietf.org>
Subject: = TCM-TF: topics to be discussed in the = list

Hi all. I have been reading through the minutes of = the BoF in Berlin, and I think we have to discuss about some things, and = then improve the documents and the charter proposal = accordingly.

These things are to be discussed in = the tcmtf@ietf.org mailing list. = We would like to ask people interested to subscribe to that list, in = order to get their opinions and to get a fruitful discussion = (https://www.ietf.org/mailman/listinfo/tcmtf).

Reading the BoF minutes (http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf<= /span>), if we = remove TCP optimization from the proposal, these would be the remaining = questions (IMO):

1) It is clear that some TCP = functions can be impacted by TCM-TF, so let us assume that we remove = from the charter the possibility of multiplexing TCP flows. Do we still = need some of that TCP functions? If the answer is “yes”, = then we have a problem.

2) “This is not being done by a host; it is in network, if a =
separator does not include timing, it could lose delay signals for =
congestion control based on delay”.

3) Path MTU discovery issues

= ;

[RP] Very = important issue. There are some gaming consoles that just by = putting their packets in a lightweight UDP tunnel you get a message = saying you have MTU issues and everything stops. Debugging is up to the = user.

<= /p>

[Jose] Which game genre = are you talking about? Perhaps this only happens when the console is = sending MTU packets. Real-time games usually send very small ones, but = this is a very interesting topic we have to = study.

<= /p>

4) Are we = “adding latency and complexity to save relatively little = bandwidth”? Additional delays: “bufferbloat - could be = increasing buffers to group packets up.” Are we adding undesired = delays?

= ;

[RP] I = can not really answer the complexity trade-off question but my feedback = is that adding any latency to multiplayer games like CoD seems like a = bad idea. ISPs constantly get complains from multiplayer CoD users about = delay (and by delay I mean very low numbers like 20ms increases). Not = only affects their score but whether others will play with them. = Maybe if you combine this bigger packet with a a low latency queue = in their CPE/Hotspot it might be an acceptable solution, not sure, need = more digging.

&nb= sp;

[Jose] The idea of this = is that we would only consider it for the “rush hour”, when = the alternative is “additional delay” or “no = service”.

<= /p>

But this is not only for = games. It can also be useful for VoIP (in fact, RFC4170 already exists = and it does exactly this), and for Machine to Machine = communications.

<= /p>

Regarding games, this = may happen in certain moments/points in the network due to different = causes: release of a new game (or new content in an existing = game).

<= /p>

In addition, we are = considering a second draft with the delay limits for each service. If = the limit is 10 ms for a game, the bandwidth savings can still be high = if the number of players is big enough (Counter Strike: 20 players, 10 = ms, 25% savings, see 8 games in http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsa= ldana.pdf)

5) “Do = vendors want standards in this space? There are a lot of proprietary = products; I would like to hear from other vendors who also would like to = see this.”

= ;

[RP] = It would be good to also get opinions from the folks that would be = affected by this proposal such as XBOX, WoW = developers.

<= /p>

[Jose] The problem is = that gaming companies do not participate in the IETF activities. I have = only participated in a research proposal with a gaming company. They can = be interested, but they do not worry too much about standards, they just = want their games to work 24/7.

<= /p>

6) = “application can sometimes send multiple packets with the same = message so that they have unique probability of loss (not correlated), = this is an application choice that needs to be known by a = tunnel.”

Any other questions?

Thanks a lot,

Jose Saldana =

------=_NextPart_000_00CE_01CEB487.FF020470-- From repenno@cisco.com Wed Sep 18 09:22:05 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF5811E829D; Wed, 18 Sep 2013 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz7WHEZ34ZXY; Wed, 18 Sep 2013 09:21:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C374411E826E; Wed, 18 Sep 2013 09:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29372; q=dns/txt; s=iport; t=1379521313; x=1380730913; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=xJHFFZVd7m3PwBC8h32pm3KbdiYeYNzfmaoMTAP2rB8=; b=N/6j2E9Bi6tP9XFzlKoq0LBhWRYurYAyMRGh1LrMZe8/iSzXChlzdcgo GUmJT089Z7HNXefO2EbwrTFnzzqzNoDfLH0TmOeZ9Avkuofw7h/qMO5H4 hCH9OYWcmUQ9jItbolTvRDxEug/fSznhCgX4KXfyub44idSxdkS6tlAVl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8GAIHSOVKtJV2Y/2dsb2JhbABaFoItRDhSuGKIRoEbFnSCJQEBAQICAQEBKkEdAQgRAwECCwIUAQYuCxQJCAEBBAESCAESh2gMujeOKYENIA0KAQaDGIEAA4xQh0+FC4V/ikaDJIFpQQ X-IronPort-AV: E=Sophos;i="4.90,929,1371081600"; d="scan'208,217";a="261456278" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 18 Sep 2013 16:21:53 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8IGLrCW018458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 16:21:53 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 11:21:52 -0500 From: "Reinaldo Penno (repenno)" To: "jsaldana@unizar.es" , "tsv-area@ietf.org" , "tcmtf@ietf.org" Subject: Re: TCM-TF: topics to be discussed in the list Thread-Topic: TCM-TF: topics to be discussed in the list Thread-Index: Ac6y35DJ7iXFf9wOQMeil2E9ofeebAALwjqAAGShuoD//7KUgA== Date: Wed, 18 Sep 2013 16:21:52 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B6DB8A0@xmb-rcd-x04.cisco.com> In-Reply-To: <00cd01ceb477$3b77d4e0$b2677ea0$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.65.59] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DB8A0xmbrcdx04ciscoc_" MIME-Version: 1.0 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:22:06 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DB8A0xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, inline with [RP2] From: Jose Saldana > Organization: Universidad de Zaragoza Reply-To: "jsaldana@unizar.es" > Date: Wednesday, September 18, 2013 6:58 AM To: Cisco Employee >, "tsv-area= @ietf.org" >, "tcmtf@ietf.org" > Subject: RE: TCM-TF: topics to be discussed in the list Reinaldo, Thanks a lot and welcome to the list! Some other comments inline. Jose De: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Enviado el: lunes, 16 de septiembre de 2013 22:58 Para: jsaldana@unizar.es; tsv-area@ietf.org; tcmtf@ietf.org Asunto: Re: TCM-TF: topics to be discussed in the list Hello Jose, I will try to jump start the discussion. I'm not a gaming console vendor bu= t sometimes deal with issues in this space due to ISP worries. Inline with [RP] From: Jose Saldana > Organization: Universidad de Zaragoza Reply-To: "jsaldana@unizar.es" > Date: Monday, September 16, 2013 6:53 AM To: "tsv-area@ietf.org" >, "tcmtf@ietf.org" > Subject: TCM-TF: topics to be discussed in the list Hi all. I have been reading through the minutes of the BoF in Berlin, and I= think we have to discuss about some things, and then improve the documents= and the charter proposal accordingly. These things are to be discussed in the tcmtf@ietf.org mailing list. We would like to ask people interested to subscribe to tha= t list, in order to get their opinions and to get a fruitful discussion (ht= tps://www.ietf.org/mailman/listinfo/tcmtf). Reading the BoF minutes (http://www.ietf.org/proceedings/87/minutes/minutes= -87-tcmtf), if we remove TCP optimization from the proposal, these would be= the remaining questions (IMO): 1) It is clear that some TCP functions can be impacted by TCM-TF, so let us= assume that we remove from the charter the possibility of multiplexing TCP= flows. Do we still need some of that TCP functions? If the answer is =93ye= s=94, then we have a problem. 2) =93This is not being done by a host; it is in network, if a separator do= es not include timing, it could lose delay signals for congestion control b= ased on delay=94. 3) Path MTU discovery issues [RP] Very important issue. There are some gaming consoles that just by pu= tting their packets in a lightweight UDP tunnel you get a message saying yo= u have MTU issues and everything stops. Debugging is up to the user. [Jose] Which game genre are you talking about? Perhaps this only happens wh= en the console is sending MTU packets. Real-time games usually send very sm= all ones, but this is a very interesting topic we have to study. [RP2] The console itself (not a game) does MTU probing. If there is a MTU p= roblem you get a network error. 4) Are we =93adding latency and complexity to save relatively little bandwi= dth=94? Additional delays: =93bufferbloat - could be increasing buffers to = group packets up.=94 Are we adding undesired delays? [RP] I can not really answer the complexity trade-off question but my feedb= ack is that adding any latency to multiplayer games like CoD seems like a b= ad idea. ISPs constantly get complains from multiplayer CoD users about del= ay (and by delay I mean very low numbers like 20ms increases). Not only aff= ects their score but whether others will play with them. Maybe if you comb= ine this bigger packet with a a low latency queue in their CPE/Hotspot it m= ight be an acceptable solution, not sure, need more digging. [Jose] The idea of this is that we would only consider it for the =93rush h= our=94, when the alternative is =93additional delay=94 or =93no service=94. [RP2] Got it, but where is the contention? If the CPE then maybe a LLQ woul= d help. But this is not only for games. It can also be useful for VoIP (in fact, RF= C4170 already exists and it does exactly this), and for Machine to Machine = communications. [RP2] Good point. Regarding games, this may happen in certain moments/points in the network d= ue to different causes: release of a new game (or new content in an existin= g game). In addition, we are considering a second draft with the delay limits for ea= ch service. If the limit is 10 ms for a game, the bandwidth savings can sti= ll be high if the number of players is big enough (Counter Strike: 20 playe= rs, 10 ms, 25% savings, see 8 games in http://diec.unizar.es/~jsaldana/pers= onal/commag_nov_2011_jsaldana.pdf) [RP2] thanks, I skimmed through it. Do you have traces and measurements for= CoD on the XBOX360 platform? That would be probably the biggest bang for t= he buck. I will certainly read you paper. 5) =93Do vendors want standards in this space? There are a lot of proprieta= ry products; I would like to hear from other vendors who also would like to= see this.=94 [RP] It would be good to also get opinions from the folks that would be af= fected by this proposal such as XBOX, WoW developers. [Jose] The problem is that gaming companies do not participate in the IETF = activities. I have only participated in a research proposal with a gaming c= ompany. They can be interested, but they do not worry too much about standa= rds, they just want their games to work 24/7. 6) =93application can sometimes send multiple packets with the same message= so that they have unique probability of loss (not correlated), this is an = application choice that needs to be known by a tunnel.=94 Any other questions? Thanks a lot, Jose Saldana --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DB8A0xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B26C6ACE74338409D49484E907C8B8B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Thanks, inline with [RP2]

From: Jose Saldana <jsaldana@unizar.es>
Organization: Universidad de Zarago= za
Reply-To: "jsaldana@unizar.es" <jsaldana@unizar.es>
Date: Wednesday, September 18, 2013= 6:58 AM
To: Cisco Employee <repenno@cisco.com>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "tcmtf@ietf.org" <tcmtf@ietf.org>
Subject: RE: TCM-TF: topics to be d= iscussed in the list

Reinald= o,

&n= bsp;

Thanks = a lot and welcome to the list!

&n= bsp;

Some ot= her comments inline.

&n= bsp;

Jose

&n= bsp;

De: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
Enviado el: lunes, 16 de septiembre de 2013 22:58
Para: jsaldana@unizar.es; = tsv-area@ietf.org; tcmtf@ietf.org=
Asunto: Re: TCM-TF: topics to be discussed in the list

Hello J= ose,

&n= bsp;

I will = try to jump start the discussion. I'm not a gaming console vendor but = sometimes deal with issues in this space due to ISP worries.

&n= bsp;

Inline = with [RP]

&n= bsp;

From: Jose Saldana <jsaldana@unizar.es>
Organization: Universidad de Zaragoza
Reply-To: "jsaldana@uniza= r.es" <jsaldana@unizar.es= >
Date: Monday, September 16, 2013 6:53 AM
To: "tsv-area@ietf.org= " <tsv-area@ietf.org>, = "tcmtf@ietf.org" <tcmtf@ietf.org>
Subject: TCM-TF: topics to be discussed in the list

&n= bsp;

Hi all. I= have been reading through the minutes of the BoF in Berlin, and I think we= have to discuss about some things, and then improve the documents and the = charter proposal accordingly.=

These thi= ngs are to be discussed in the tcmtf@ietf.org mailing list. We would= like to ask people interested to subscribe to that list, in order to get t= heir opinions and to get a fruitful discussion (https://www.ietf.org/mailman/listinfo/tcmtf).

Reading t= he BoF minutes (http:/= /www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf), if we remove TCP optimization from the proposal, these would be the remain= ing questions (IMO):

1) It is = clear that some TCP functions can be impacted by TCM-TF, so let us assume t= hat we remove from the charter the possibility of multiplexing TCP flows. D= o we still need some of that TCP functions? If the answer is =93yes=94, then we have a problem.

2) =93This is not being done by a host; it is in=
 network, if a separator does not include timing, it could lose delay signa=
ls for congestion control based on delay=94.

3) Path MTU discovery issues

[RP] Very important issue. There are some gaming consoles = that just by putting their packets in a lightweight UDP tunnel = you get a message saying you have MTU issues and everything stops. Debugging is up to the user.

[Jose] Which game genre are you talking about? Perhaps thi= s only happens when the console is sending MTU packets. Real-time games usu= ally send very small ones, but this is a very interesting topic we have to study.

[RP2] The console itself (not a game) = does MTU probing. If there is a MTU problem you get a network error. <= /div>

4) Are we= =93adding latency and complexity to save relatively little bandwidth=94? A= dditional delays: =93bufferbloat - could be increasing buffers to group pac= kets up.=94 Are we adding undesired delays?

[RP] I can not really answer the complexity trade-off ques= tion but my feedback is that adding any latency to multiplayer games like C= oD seems like a bad idea. ISPs constantly get complains from multiplayer CoD users about delay (and by delay I mean = very low numbers like 20ms increases). Not only affects their score but whe= ther others will play with them. Maybe if you combine this bigger pac= ket with a a low latency queue in their CPE/Hotspot it might be an acceptable solution, not sure, need more diggin= g.

[Jose] The idea of this is that we would only consider it = for the =93rush hour=94, when the alternative is =93additional delay=94 or = =93no service=94.

[RP2] Got it, but where is the content= ion? If the CPE then maybe a LLQ would help.

But this is not only for games. It can also be useful for = VoIP (in fact, RFC4170 already exists and it does exactly this), and for Ma= chine to Machine communications.

[RP2] Good point.

Regarding games, this may happen in certain moments/points= in the network due to different causes: release of a new game (or new cont= ent in an existing game).

In addition, we are considering a second draft with the de= lay limits for each service. If the limit is 10 ms for a game, the bandwidt= h savings can still be high if the number of players is big enough (Counter Strike: 20 players, 10 ms, 25% savings, = see 8 games in http://diec.unizar.es/~jsaldana/personal= /commag_nov_2011_jsaldana.pdf)<= /span>

&n= bsp;

[RP2] thanks, I skimmed thr= ough it. Do you have traces and measurements for CoD on the XBOX360 platfor= m? That would be probably the biggest bang for the buck. I will certainly read you paper.

5) =93Do = vendors want standards in this space? There are a lot of proprietary produc= ts; I would like to hear from other vendors who also would like to see this= .=94

[RP] It would be good to also get opinions from the = folks that would be affected by this proposal such as XBOX, WoW developers.=

[Jose] The problem is that gaming companies do not partici= pate in the IETF activities. I have only participated in a research proposa= l with a gaming company. They can be interested, but they do not worry too much about standards, they just want their games= to work 24/7.

6) =93app= lication can sometimes send multiple packets with the same message so that = they have unique probability of loss (not correlated), this is an applicati= on choice that needs to be known by a tunnel.=94

Any other= questions?

Thanks a = lot,

Jose Saldana

--_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DB8A0xmbrcdx04ciscoc_-- From jsaldana@unizar.es Fri Sep 27 06:56:59 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC1611E814F; Fri, 27 Sep 2013 06:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.277 X-Spam-Level: X-Spam-Status: No, score=-4.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XBPq8BrsKJi; Fri, 27 Sep 2013 06:56:53 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 38CFE21F9D66; Fri, 27 Sep 2013 06:56:48 -0700 (PDT) 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 r8RDuaH8007030; Fri, 27 Sep 2013 15:56:36 +0200 From: "Jose Saldana" To: "'Reinaldo Penno $repenno$'" , , Subject: TCM-TF: Path MTU Date: Fri, 27 Sep 2013 15:56:44 +0200 Organization: Universidad de Zaragoza Message-ID: <00d801cebb89$6948b790$3bda26b0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac67iGausLwrFaprRJeUtk1utH2csw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:56:59 -0000 Just my opinion about the MTU problem when TCM-optimizing: (=85)=A0 >>>>3) Path MTU discovery issues =A0 >>>[RP] Very important issue. There are some gaming consoles =A0that = =A0just by putting their packets in a lightweight UDP tunnel you get a message=20 >>>saying you have MTU issues and everything stops. Debugging is up to = the user. =A0 =A0 >>[Jose] Which game genre are you talking about? Perhaps this only = happens when the console is sending MTU packets. Real-time games usually send >> very small ones, but this is a very interesting topic we have to = study. >[RP2] The console itself (not a game) does MTU probing. If there is a = MTU problem you get a network error.=A0 =A0(=85) [Jose] TCM is deployed inside the network (within a network segment), = and the end machines do not know that it is being deployed. TCM only makes sense for small-packet flows. Obviously, a TCM optimizer = will not multiplex packets if they are big. Those packets will travel in = their native form, and the tunnel is not required. So if a console does that = test, a good TCM implementation should not do anything. There is another question: we are talking about multiplexing based on a = time period. However, the MTU is another limitation. I mean, if the period = has not expired yet, but you are near the MTU, you'd better send the packet = and begin a new period. What do you think? Jose From repenno@cisco.com Fri Sep 27 07:11:47 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66A111E8159; Fri, 27 Sep 2013 07:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6sRxsbrEkdH; Fri, 27 Sep 2013 07:11:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3957711E814E; Fri, 27 Sep 2013 07:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1797; q=dns/txt; s=iport; t=1380291102; x=1381500702; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=yaF+df9MxCyWYMQB74iyOeuMs1xQ8rhxL3wIPTn80Rg=; b=De9mvWBTNrJuVpchBkrA3dS4mHiAOj9ApSM/JlpcElv3liWz3vv4lT6e KYU+ryDFng+5LZ9Y7sgHltCS9QDyD0N0c3+0XaNrTv+V9UVneTyMi3ppd fy4berlJ6DF79VY5u020h7S6TNLGsuNq4JvQuaMRZwHaliI11u3vrd7AD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMiRRVKtJV2Y/2dsb2JhbABZgweBCsBLgRwWdIInAQSBCwEIIlYlAQEEARIIh366Q48gOIMdgQEDqXWDJIIq X-IronPort-AV: E=Sophos;i="4.90,993,1371081600"; d="scan'208";a="265286295" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 27 Sep 2013 14:11:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8REBfxb009289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 14:11:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 09:11:41 -0500 From: "Reinaldo Penno (repenno)" To: "jsaldana@unizar.es" , "tsv-area@ietf.org" , "tcmtf@ietf.org" Subject: Re: TCM-TF: Path MTU Thread-Topic: TCM-TF: Path MTU Thread-Index: Ac67iGausLwrFaprRJeUtk1utH2cs///5KKA Date: Fri, 27 Sep 2013 14:11:41 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B6E9D71@xmb-rcd-x04.cisco.com> In-Reply-To: <00d801cebb89$6948b790$3bda26b0$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.126.13] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 14:11:48 -0000 On 9/27/13 6:56 AM, "Jose Saldana" wrote: >Just my opinion about the MTU problem when TCM-optimizing: > > >(=8A)=20 >>>>>3) Path MTU discovery issues >=20 >>>>[RP] Very important issue. There are some gaming consoles that just >>>>by >putting their packets in a lightweight UDP tunnel you get a message >>>>saying you have MTU issues and everything stops. Debugging is up to the >user. =20 >=20 >>>[Jose] Which game genre are you talking about? Perhaps this only happens >when the console is sending MTU packets. Real-time games usually send >>> very small ones, but this is a very interesting topic we have to study. > >>[RP2] The console itself (not a game) does MTU probing. If there is a MTU >problem you get a network error. > > (=8A) > >[Jose] TCM is deployed inside the network (within a network segment), and >the end machines do not know that it is being deployed. > >TCM only makes sense for small-packet flows. [RP] Yes, but how TCM would know that before hand about the flow ? Is that a run time decision based on packet size inspection? >Obviously, a TCM optimizer will >not multiplex packets if they are big. Those packets will travel in their >native form, and the tunnel is not required. So if a console does that >test, >a good TCM implementation should not do anything. [RP] If you have a mix of large packets (close to MTU, no tunneling) and small packets, that would cause reordering, no? > >There is another question: we are talking about multiplexing based on a >time >period. However, the MTU is another limitation. I mean, if the period has >not expired yet, but you are near the MTU, you'd better send the packet >and >begin a new period. [RP] Agree. > >What do you think? > >Jose > From jsaldana@unizar.es Fri Sep 27 07:51:05 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3921F9703; Fri, 27 Sep 2013 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.531 X-Spam-Level: X-Spam-Status: No, score=-5.531 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKvG683NJ6WU; Fri, 27 Sep 2013 07:50:59 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id E9ABF21F9D7C; Fri, 27 Sep 2013 07:50:55 -0700 (PDT) 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 r8REohQu008990; Fri, 27 Sep 2013 16:50:43 +0200 From: "Jose Saldana" To: "'Reinaldo Penno $repenno$'" , , References: <00d801cebb89$6948b790$3bda26b0$@unizar.es> <45A697A8FFD7CF48BCF2BE7E106F06040B6E9D71@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B6E9D71@xmb-rcd-x04.cisco.com> Subject: RE: TCM-TF: Path MTU Date: Fri, 27 Sep 2013 16:50:51 +0200 Organization: Universidad de Zaragoza Message-ID: <00e201cebb90$f66d3540$e3479fc0$@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: AQFjK2R8LreIbggnmzfUdkoGE13ykpqwyljw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 14:51:05 -0000 > -----Mensaje original----- > De: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > Enviado el: viernes, 27 de septiembre de 2013 16:12 > Para: jsaldana@unizar.es; tsv-area@ietf.org; tcmtf@ietf.org > Asunto: Re: TCM-TF: Path MTU >=20 >=20 >=20 > On 9/27/13 6:56 AM, "Jose Saldana" wrote: >=20 > >Just my opinion about the MTU problem when TCM-optimizing: > > > > > >(=A9) > >>>>>3) Path MTU discovery issues > > > >>>>[RP] Very important issue. There are some gaming consoles that > >>>>just by > >putting their packets in a lightweight UDP tunnel you get a message > >>>>saying you have MTU issues and everything stops. Debugging is up = to > >>>>the > >user. > > > >>>[Jose] Which game genre are you talking about? Perhaps this only > >>>happens > >when the console is sending MTU packets. Real-time games usually send > >>> very small ones, but this is a very interesting topic we have to study. > > > >>[RP2] The console itself (not a game) does MTU probing. If there is = a > >>MTU > >problem you get a network error. > > > > (=A9) > > > >[Jose] TCM is deployed inside the network (within a network segment), > >and the end machines do not know that it is being deployed. > > > >TCM only makes sense for small-packet flows. >=20 > [RP] Yes, but how TCM would know that before hand about the flow ? Is = that > a run time decision based on packet size inspection? >=20 > >Obviously, a TCM optimizer will > >not multiplex packets if they are big. Those packets will travel in > >their native form, and the tunnel is not required. So if a console = does > >that test, a good TCM implementation should not do anything. >=20 > [RP] If you have a mix of large packets (close to MTU, no tunneling) = and small > packets, that would cause reordering, no? >=20 [Jose] Yep. If an application generates big and small packets, they = could arrive reordered at the end machine. Perhaps we should also take this = into account in the "recommendations draft": only optimizing flows that = generate small (and no big) packets. Currently we are considering those kinds of flows in fact. > > > >There is another question: we are talking about multiplexing based on = a > >time period. However, the MTU is another limitation. I mean, if the > >period has not expired yet, but you are near the MTU, you'd better = send > >the packet and begin a new period. >=20 > [RP] Agree. >=20 > > > >What do you think? > > > >Jose > >