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

"Jose Saldana" <jsaldana@unizar.es> Thu, 16 May 2013 08:07 UTC

Return-Path: <jsaldana@unizar.es>
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 317BE21F8EC6 for <tcmtf@ietfa.amsl.com>; Thu, 16 May 2013 01:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.236
X-Spam-Level:
X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, 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 hNCV7XzpH4lZ for <tcmtf@ietfa.amsl.com>; Thu, 16 May 2013 01:07:05 -0700 (PDT)
Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD2221F8F0A for <tcmtf@ietf.org>; Thu, 16 May 2013 01:06:56 -0700 (PDT)
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 r4G86gBA008319; Thu, 16 May 2013 10:06:43 +0200
From: "Jose Saldana" <jsaldana@unizar.es>
To: <Tomaso.deCola@dlr.de>
References: <008201ce4fc4$22b8e510$682aaf30$@unizar.es> <E004A7C54DE04F4BB87DB9F32308DA5C01CFFE@MAIL4.fer.hr> <005101ce514a$3e41ea20$bac5be60$@unizar.es> <1A39DCC13AF3C14B83CD74124D4DCFC316F73162@DLREXMBX01.intra.dlr.de>
In-Reply-To: <1A39DCC13AF3C14B83CD74124D4DCFC316F73162@DLREXMBX01.intra.dlr.de>
Date: Thu, 16 May 2013 10:06:48 +0200
Organization: Universidad de Zaragoza
Message-ID: <005d01ce520c$514821d0$f3d86570$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CE521D.14D314B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMEIpyho0KjN7tC+jPQgybcWLqFigHQInc0Adx0aVwCD43m+JZt78aQ
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: 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
Reply-To: jsaldana@unizar.es
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 08:07:09 -0000

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 |
<mailto:sandro.scalise@dlr.de> tomaso.decola@dlr.de 
 <http://www.dlr.de/kn/institut/abteilungen/san>
http://www.dlr.de/kn/institut/abteilungen/san 

 

From: 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
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-backgrou
nd-data-traffic-mobile-devices>
http://www.qualcomm.com/media/documents/qualcomm-research-managing-backgroun
d-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] En nombre de
Mirko Sužnjevic
Enviado el: martes, 14 de mayo de 2013 10:08
Para: 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
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