Re: [tcmtf] TCM-TF: topics to be discussed in the list

"Reinaldo Penno (repenno)" <repenno@cisco.com> Wed, 18 September 2013 16:22 UTC

Return-Path: <repenno@cisco.com>
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 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)" <repenno@cisco.com>
To: "jsaldana@unizar.es" <jsaldana@unizar.es>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "tcmtf@ietf.org" <tcmtf@ietf.org>
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
Subject: Re: [tcmtf] TCM-TF: topics to be discussed in the list
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2013 16:22:06 -0000

Thanks, inline with [RP2]

From: Jose Saldana <jsaldana@unizar.es<mailto:jsaldana@unizar.es>>
Organization: Universidad de Zaragoza
Reply-To: "jsaldana@unizar.es<mailto:jsaldana@unizar.es>" <jsaldana@unizar.es<mailto:jsaldana@unizar.es>>
Date: Wednesday, September 18, 2013 6:58 AM
To: Cisco Employee <repenno@cisco.com<mailto:repenno@cisco.com>>, "tsv-area@ietf.org<mailto:tsv-area@ietf.org>" <tsv-area@ietf.org<mailto:tsv-area@ietf.org>>, "tcmtf@ietf.org<mailto:tcmtf@ietf.org>" <tcmtf@ietf.org<mailto: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<mailto:jsaldana@unizar.es>; tsv-area@ietf.org<mailto:tsv-area@ietf.org>; tcmtf@ietf.org<mailto: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<mailto:jsaldana@unizar.es>>
Organization: Universidad de Zaragoza
Reply-To: "jsaldana@unizar.es<mailto:jsaldana@unizar.es>" <jsaldana@unizar.es<mailto:jsaldana@unizar.es>>
Date: Monday, September 16, 2013 6:53 AM
To: "tsv-area@ietf.org<mailto:tsv-area@ietf.org>" <tsv-area@ietf.org<mailto:tsv-area@ietf.org>>, "tcmtf@ietf.org<mailto:tcmtf@ietf.org>" <tcmtf@ietf.org<mailto: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<mailto: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.

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



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”.

[RP2] Got it, but where is the contention? 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 Machine 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 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)



[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 the buck. I will certainly read you paper.


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