Re: [tcmtf] BoF proposal for Berlin. Possible scheme

"Michael Ramalho (mramalho)" <mramalho@cisco.com> Thu, 16 May 2013 14:18 UTC

Return-Path: <mramalho@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 6DB1421F8EC1 for <tcmtf@ietfa.amsl.com>; Thu, 16 May 2013 07:18:11 -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 MOMxp+XjMT0U for <tcmtf@ietfa.amsl.com>; Thu, 16 May 2013 07:18:06 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDFD21F9227 for <tcmtf@ietf.org>; Thu, 16 May 2013 07:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=87399; q=dns/txt; s=iport; t=1368713885; x=1369923485; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MqPEZrK5lRHgsP0VXuSX2hmybkB1mQcNKuV7FA5pMFE=; b=Vnw2RddvUTgX9YNkrJ2kh4RpSMd9wTmTsQU+o1VEF1DphYr0GiOXjkTq GsIuHqzEZoVapvmY220BC0PR8UI3fpMpamhBWsmXJQ7cWBSL7v0XTGQS1 m9eewst4lyWcPET/qLR8nYF+6v7AfPouLuER0G5p37k3YNIxejINKT0Lc o=;
X-Files: TFRC_Rate_as_function_of_RTT.pdf : 38508
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAMjplFGtJXG+/2dsb2JhbABbgkNEN8FBfBZ0gh8BAQEELRg0EAIBCBEEAQELFgEGBwIYDwkUCQgCBAEJBAUIAQUNh3EMvSqNVheBABYbBgGCdGEDj3qFbJMMgxCCJg
X-IronPort-AV: E=Sophos; i="4.87,684,1363132800"; d="pdf'?scan'208,217"; a="211103763"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 16 May 2013 14:18:04 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4GEI4Gs028994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 14:18:04 GMT
Received: from xmb-rcd-x12.cisco.com ([169.254.2.133]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 16 May 2013 09:18:03 -0500
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: "jsaldana@unizar.es" <jsaldana@unizar.es>, "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de>
Thread-Topic: [tcmtf] BoF proposal for Berlin. Possible scheme
Thread-Index: AQHOUHoleHYQWM//90SLNaIRvcsgl5kGR1gAgAC+dwCAAMWuAIAAD+Sg
Date: Thu, 16 May 2013 14:18:03 +0000
Message-ID: <D21571530BF9644D9A443D6BD95B910315559B57@xmb-rcd-x12.cisco.com>
References: <008201ce4fc4$22b8e510$682aaf30$@unizar.es> <E004A7C54DE04F4BB87DB9F32308DA5C01CFFE@MAIL4.fer.hr> <005101ce514a$3e41ea20$bac5be60$@unizar.es> <1A39DCC13AF3C14B83CD74124D4DCFC316F73162@DLREXMBX01.intra.dlr.de> <005d01ce520c$514821d0$f3d86570$@unizar.es>
In-Reply-To: <005d01ce520c$514821d0$f3d86570$@unizar.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.125.231]
Content-Type: multipart/mixed; boundary="_004_D21571530BF9644D9A443D6BD95B910315559B57xmbrcdx12ciscoc_"
MIME-Version: 1.0
Cc: "tcmtf@ietf.org" <tcmtf@ietf.org>, =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= <Mirko.Suznjevic@fer.hr>
Subject: Re: [tcmtf] BoF proposal for Berlin. Possible scheme
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: Thu, 16 May 2013 14:18:11 -0000

Hi Jose,

Re: 125 ACKs per second is an ACK every 8 ms or so for your laptop.

Got to be careful when you want to compress/aggregate them ... for example ...

1) If the flow has a long RTT (excluding any RTT increase due to aggregation/delay of some ACKs) ... something like 200 ms RTT ... you can aggregate up to 50 ms worth of them with little decrease in maximum transfer BW.

2) Conversely, if the flow has a short RTT (sub ~70 ms) ... you can lose up to HALF the maximum transfer BW by delaying ACKs by 25ms (on average).

Pick a background packet loss rate and look at the TFRC rate as a function of i.i.d. loss rate  and RTT time attached (generated from the TFRC equation ... the table is just easier to visualize).

Perhaps this could suggest a heuristic for a flow ... look at the nominal RTT (for something like a TCP flow) .. and then determine a reasonable worst-case delay for the TCP ACKs. You heard it first here.

Michael

PS - Qualcomm (I believe, and others) have technology that "aggregates packets" on the mobile when the mobile is in the "not-presently-active/in-use" mode (I forget the exact term they use for that state). Thus they primarily conserve battery by limiting the time the radio functionality needs to be on by aggregating time-insensitive data requests.

From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf Of Jose Saldana
Sent: Thursday, May 16, 2013 4:07 AM
To: Tomaso.deCola@dlr.de
Cc: tcmtf@ietf.org; Mirko Sužnjević
Subject: Re: [tcmtf] BoF proposal for Berlin. Possible scheme

Hi, Tomaso. Your idea is interesting. My opinion:

- TCMTF can reduce pps (and consequently energy) in routers and other intermediate nodes, since in that place we can find a lot of flows to be multiplexed together.

- Regarding the battery of a mobile phone, I don't see the savings so straightforward, since the number of flows is smaller. And you cannot put together a number of packets belonging to the same real-time flow without annoying the user. One case I found some days ago: I was downloading a big file with a  laptop connected via Wi-Fi to a DSL, and I captured the traffic with Wireshark. I found that my laptop was sending 125 ACKs per second!. If we put a number of ACKs together (they can be compressed: same origin and destination, same ports, etc), we can reduce the number of pps, and also bandwidth. However, we should be careful with TCP timeouts and so on.

Perhaps we could think about other savings in terminals: e.g., sensor networks?

Best regards,

Jose

De: Tomaso.deCola@dlr.de [mailto:Tomaso.deCola@dlr.de]
Enviado el: miércoles, 15 de mayo de 2013 22:19
Para: jsaldana@unizar.es
CC: tcmtf@ietf.org; Mirko.Suznjevic@fer.hr
Asunto: RE: [tcmtf] BoF proposal for Berlin. Possible scheme

Hi Jose,

If I'm not wrong IETF is also interested in energy saving issues (e.g., eman, roll WGs). I think that in our case it is also important to figure out whether we are talking about battery consumption on mobile devices, sensor nodes, etc. or on the power usage in routers and other intermediate nodes, which is a topic largely addressed in the field of green networking. This differentiation can be clarified according to the specific scenarios we are addressing, so that we can highlight whether tcmtf concepts are more beneficial for the end-nodes or for the network infrastructure. If the latter is the case, probably network operators like Telefonica and device manifacturers like Cisco (who both already contributed to the discussion in this list) can further motivate the need for a standard (or more than one).

Regards,

Tomaso

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola@dlr.de<mailto:sandro.scalise@dlr.de>
http://www.dlr.de/kn/institut/abteilungen/san

From: tcmtf-bounces@ietf.org<mailto:tcmtf-bounces@ietf.org> [mailto:tcmtf-bounces@ietf.org] On Behalf Of Jose Saldana
Sent: Wednesday, May 15, 2013 10:58 AM
To: 'Mirko Sužnjević'
Cc: tcmtf@ietf.org<mailto:tcmtf@ietf.org>
Subject: Re: [tcmtf] BoF proposal for Berlin. Possible scheme

Hi, Mirko.

The idea of energy savings is also interesting. People are getting more and more concerned with the energy consumption. Not only European Commission, but also smartphone and tablet manufacturers: the duration of the battery is critical there.

For example, "Qualcomm has developed a solution called Network Socket Request Manager (NSRM) for efficient application management. NSRM reduces smart phone signaling traffic by bundling application requests and intelligently delaying them. NSRM provides significant signaling reduction and also improves stand-by time."
http://www.qualcomm.com/media/documents/qualcomm-research-managing-background-data-traffic-mobile-devices

Perhaps we could also include this idea in the presentations. The benefits of packet grouping are 3 instead of 2:

1- Bandwidth saving
2- PPS reduction
3- Energy savings

What do you think? Will people at the IETF like energy savings?

Best regards,

Jose

De: tcmtf-bounces@ietf.org<mailto:tcmtf-bounces@ietf.org> [mailto:tcmtf-bounces@ietf.org] En nombre de Mirko Sužnjevic
Enviado el: martes, 14 de mayo de 2013 10:08
Para: tcmtf@ietf.org<mailto:tcmtf@ietf.org>
Asunto: Re: [tcmtf] BoF proposal for Berlin. Possible scheme

Hello everybody,
Well I concur with the structure. I believe that the main thing is to do is to well formulate and explain the problem. We must prove in a coherent way that the problem we are addressing here is a problem worth putting effort to and worth solving. In short we must present all the benefits the  solving of our problem might bring. We more or less covered the network aspects of the TCMTF. Maybe one of the previously not emphasized things is the notion of energy savings which TCMTF implementation might bring.  I am not certain would such topics be interesting in the IETF, but it was interesting for the European Commission.
Ofcourse I will create the presentation regarding my part.
Cheers!
Mirko Suznjevic


From: Jose Saldana [mailto:jsaldana@unizar.es]
Sent: Monday, May 13, 2013 12:25 PM
To: tcmtf@ietf.org<mailto:tcmtf@ietf.org>
Cc: Martin Stiemerling; Dan Wing; Mirko Sužnjević
Subject: BoF proposal for Berlin. Possible scheme

Hi all.

According to http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87, 2013-06-17 (Monday) is the cutoff date for BOF proposal requests to Area Directors. So we still have a month.

we could discuss a bit the possible scheme for the BoF proposal.

According to Martin's suggestion, we could begin the session with a teaser presentation describing what the exact issues are and what is the need for standardization.

So we could follow this structure:

1- Teaser presentation: describing the problem and the need for standardization

2- Charter: Documents to be generated within this potential WG

3- Draft A: Explaining the current TCMTF proposal

4- Draft B: Explaining the content of the draft about delay requirements, classification methods, etc.


Dan Wing could be in charge of (1). This would be good, since he is one of the authors of RFC4170 (the RFC we should "update" with TCMTF), so he knows the whole story. In addition, he has been in the TCMTF draft from the very beginning.

I could be in charge of (2), mainly explaining the charter.

Perhaps someone from Telefonica could be in charge of (3).

Mirko Suznjevic could present (4), since he is the first author.






What do you think? Any ideas?

Thanks a lot and best regards!,

Jose