Re: [tcmtf] BoF proposal for Berlin. Multiplexing ACKs

["Jose Saldana" <[e-mail]>]

Michael,

 

Thanks a lot. It is clear that grouping packets in a single device (scenario 2) is less straightforward than doing it in a network with a lot of flows (scenario 1). Two thoughts:

 

- Scenario 1 (network with a lot of flows): If I am a network provider, and I am able to identify in my aggregation network 50 ACK flows of 100 pps (corresponding to 50 concurrent file downloads), I can take one ACK from each flow, adding an average delay of 5 ms (I receive a packet every 10ms, so packets will be delayed from 0 to 10ms). So this would still be possible. And the bandwidth savings would be really high: I can easily compress from 40 to e.g., 6 or 8 bytes.

 

- Scenario 2 (a single device): As you say, a small increase of the RTT can significantly reduce the throughput if TCP-Friendly Rate Control is being used. However, is it widely used? In addition, in Draft B we are considering the idea of taking into account the RTT, in order to set the best value to multiplexing period. This is exactly what you say:

 

“look at the nominal RTT (for something like a TCP flow) .. and then determine a reasonable worst-case delay for the TCP ACKs.”

 

 

Any idea from Telefonica? Do you think multiplexing ACKs is interesting?

 

Thanks!

 

Jose

 

De: Michael Ramalho (mramalho) [mailto:[e-mail]] 
Enviado el: jueves, 16 de mayo de 2013 16:18
Para: [e-mail]; [e-mail]
CC: [e-mail]; Mirko Sužnjević
Asunto: RE: [tcmtf] BoF proposal for Berlin. Possible scheme

 

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: [e-mail] [mailto:[e-mail]] On Behalf Of Jose Saldana
Sent: Thursday, May 16, 2013 4:07 AM
To: [e-mail]
Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]] 
Enviado el: miércoles, 15 de mayo de 2013 22:19
Para: [e-mail]
CC: [e-mail]; [e-mail]
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 [phone] | Telefax  [phone] |  <mailto:[e-mail]> [e-mail] 
 <http://www.dlr.de/kn/institut/abteilungen/san> http://www.dlr.de/kn/institut/abteilungen/san 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Jose Saldana
Sent: Wednesday, May 15, 2013 10:58 AM
To: 'Mirko Sužnjević'
Cc: [e-mail]
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> 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: [e-mail] [mailto:[e-mail]] En nombre de Mirko Sužnjevic
Enviado el: martes, 14 de mayo de 2013 10:08
Para: [e-mail]
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:[e-mail]] 
Sent: Monday, May 13, 2013 12:25 PM
To: [e-mail]
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