On 09.09.2013, at 18:25, Jose = Saldana <jsaldana@unizar.es> = wrote:

Dear = all,

As you may know, we had a TCM-TF BoF in IETF87 Berlin = (http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf= ).

As a result of the BoF, it = was clear (IMHO) that there is some interest on the topic. There were a = number of people who thought that a WG should be created, and several = people also volunteered for reviewing = documents.

However, in the BoF it was also clear that there are some = concerns that have to be issued before chartering. The main one is the = interaction between TCM optimization and TCP mechanisms. Since TCP = controls its rate depending on the RTT, the addition of a multiplexing = delay may modify and even harm TCP behavior.

As a consequence, we are = going to redefine the Charter, removing the optimization of TCP. So = RTP/UDP and UDP will be the considered options for = optimization.

We would like to get more people involved in the = discussion, so we would like to invite those who actively participate on = Transport Area discussion to join the mailing list https://www.ietf.org/mailman/listinfo/tcmtf, in order to get their = feedback.

Thanks in advance,

Jose = Saldana
_____________________________________= __________
tcmtf mailing list
To: "'Manuel Gorius'" References: <017d01cead79$25240a10$6f6c1e30$@unizar.es> In-Reply-To: Date: Tue, 10 Sep 2013 16:14:25 +0200 Organization: Universidad de Zaragoza Message-ID: <002d01ceae30$0e3460e0$2a9d22a0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CEAE40.D1BE1B40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHuvPs5z3YNAt6hhH28PKho2tIgMgDdQFaPmXf7wUA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Next steps with TCM-TF 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 14:14:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01CEAE40.D1BE1B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Manuel, It sounds good. Could you please provide the link to some documentation (e.g. a paper, a report) about the "predictably reliable" error control scheme? Thanks! Jose De: Manuel Gorius [mailto:gorius@nt.uni-saarland.de] Enviado el: martes, 10 de septiembre de 2013 14:30 Para: jsaldana@unizar.es CC: tcmtf@ietf.org Asunto: Re: [tcmtf] Next steps with TCM-TF Dear Jose, It was nice to follow the ideas brought up during the TCM-TF BoF. I think that a related standard might become important in near future since besides online gaming there is also a plenty of upcoming interactive and sensor applications that would be sending small parameter updates (think of smart factory applications for instance or even e-health services). I highly appreciate the decision to move the focus away from TCP. Given TCP's limited efficiency for interactive applications, the concerns of potential impact on its performance should not put an innovation bottleneck in front of new ideas improving transport efficiency. During the BoF session the question of transport reliability for such multiplexed packet flows was raised. This would be a point where our lab could contribute. We developed a "predictably reliable" error control scheme that operates under strict delay constraints. The scheme would particularly benefit from the larger packets and the higher aggregate data rate of the multiplexed packet flows. If such error control would be considered beneficial in TCM-TF, I'd be happy to become active. Best regards, Manuel Gorius On 09.09.2013, at 18:25, Jose Saldana wrote: Dear all, As you may know, we had a TCM-TF BoF in IETF87 Berlin ( http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf). As a result of the BoF, it was clear (IMHO) that there is some interest on the topic. There were a number of people who thought that a WG should be created, and several people also volunteered for reviewing documents. However, in the BoF it was also clear that there are some concerns that have to be issued before chartering. The main one is the interaction between TCM optimization and TCP mechanisms. Since TCP controls its rate depending on the RTT, the addition of a multiplexing delay may modify and even harm TCP behavior. As a consequence, we are going to redefine the Charter, removing the optimization of TCP. So RTP/UDP and UDP will be the considered options for optimization. We would like to get more people involved in the discussion, so we would like to invite those who actively participate on Transport Area discussion to join the mailing list https://www.ietf.org/mailman/listinfo/tcmtf, in order to get their feedback. Thanks in advance, Jose Saldana _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf ------=_NextPart_000_002E_01CEAE40.D1BE1B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Manuel,

It sounds good. Could you please provide the link to some = documentation (e.g. a paper, a report) about the “predictably = reliable” error control scheme?

Thanks!

Jose

De: Manuel = Gorius [mailto:gorius@nt.uni-saarland.de] =
Enviado el: martes, 10 de septiembre de 2013 = 14:30
Para: jsaldana@unizar.es
CC: = tcmtf@ietf.org
Asunto: Re: [tcmtf] Next steps with = TCM-TF

Dear = Jose,

It was nice to follow the ideas brought up during the = TCM-TF BoF. I think that a related standard might become important in = near future since besides online gaming there is also a plenty of = upcoming interactive and sensor applications that would be sending small = parameter updates (think of smart factory applications for instance or = even e-health services). I highly appreciate the decision to move the = focus away from TCP. Given TCP's limited efficiency for interactive = applications, the concerns of potential impact on its performance should = not put an innovation bottleneck in front of new ideas improving = transport efficiency.

During the BoF session the question of transport = reliability for such multiplexed packet flows was raised. This would be = a point where our lab could contribute. We developed a "predictably = reliable" error control scheme that operates under strict = delay constraints. The scheme would particularly benefit from the larger = packets and the higher aggregate data rate of the multiplexed packet = flows. If such error control would be considered beneficial in TCM-TF, = I'd be happy to become active.

Best regards,
        &n= bsp; Manuel Gorius

On 09.09.2013, at 18:25, Jose Saldana <jsaldana@unizar.es> = wrote:

Dear = all,=
=
As you may = know, we had a TCM-TF BoF in IETF87 Berlin (http://www.ietf.org/proceedings/87/minutes/minutes= -87-tcmtf).=
=
As a = result of the BoF, it was clear (IMHO) that there is some interest on = the topic. There were a number of people who thought that a WG should be = created, and several people also volunteered for reviewing = documents.=
=
However, = in the BoF it was also clear that there are some concerns that have to = be issued before chartering. The main one is the interaction between TCM = optimization and TCP mechanisms. Since TCP controls its rate depending = on the RTT, the addition of a multiplexing delay may modify and even = harm TCP behavior.=
=
As a = consequence, we are going to redefine the Charter, removing the = optimization of TCP. So RTP/UDP and UDP will be the considered options = for optimization.=
=
We would = like to get more people involved in the discussion, so we would like to = invite those who actively participate on Transport Area discussion to = join the mailing list https://www.ietf.org/mailman/listinfo/tcmtf= , in order = to get their feedback.=
=
Thanks in = advance,=
=
Jose = Saldana=
_________= ______________________________________
tcmtf mailing list
tcmtf@ietf.org
https://www.ietf.org/mailman/listinfo/tcmtf=

------=_NextPart_000_002E_01CEAE40.D1BE1B40-- From gorius@nt.uni-saarland.de Tue Sep 10 08:08:42 2013 Return-Path: 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 CB4B121E8054 for ; Tue, 10 Sep 2013 08:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 rKLvaz05Mz5I for ; Tue, 10 Sep 2013 08:08:38 -0700 (PDT) Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) by ietfa.amsl.com (Postfix) with ESMTP id 807CD21F9CC7 for ; Tue, 10 Sep 2013 08:08:36 -0700 (PDT) Received: from [192.168.44.164] ([89.204.137.183]) (authenticated bits=0) by triton.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id r8AF86pe001054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Sep 2013 17:08:22 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_29F34A69-703D-457A-B360-8A065BE84BF5" Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Manuel Gorius In-Reply-To: <002d01ceae30$0e3460e0$2a9d22a0$@unizar.es> Date: Tue, 10 Sep 2013 17:08:06 +0200 Message-Id: References: <017d01cead79$25240a10$6f6c1e30$@unizar.es> <002d01ceae30$0e3460e0$2a9d22a0$@unizar.es> To: jsaldana@unizar.es X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (triton.rz.uni-saarland.de [134.96.7.25]); Tue, 10 Sep 2013 17:08:25 +0200 (CEST) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-14; AVE: 7.9.10.68; VDF: 7.11.99.164; host: AntiVir3) Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Next steps with TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:08:43 -0000 --Apple-Mail=_29F34A69-703D-457A-B360-8A065BE84BF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jose, Thank you for your interest. We had set up a project website = providing literature and a Linux kernel module implementing our = "Predictably Reliable Real-time Protocol":=20 http://www.nt.uni-saarland.de/en/projects/running-projects/prrt.html For a quick technical overview I'd like to point you on a poster = presentation available under:=20 = http://www.nt.uni-saarland.de/fileadmin/file_uploads/projects/prrt/PRRT_Po= ster.pdf Please let me know if any of the implemented ideas are suitable for the = TCM-TF. Best regards, Manuel On 10.09.2013, at 16:14, "Jose Saldana" wrote: > Manuel, > =20 > It sounds good. Could you please provide the link to some = documentation (e.g. a paper, a report) about the =93predictably = reliable=94 error control scheme? > =20 > Thanks! > =20 > Jose > =20 > De: Manuel Gorius [mailto:gorius@nt.uni-saarland.de]=20 > Enviado el: martes, 10 de septiembre de 2013 14:30 > Para: jsaldana@unizar.es > CC: tcmtf@ietf.org > Asunto: Re: [tcmtf] Next steps with TCM-TF > =20 > Dear Jose, > =20 > It was nice to follow the ideas brought up during the TCM-TF BoF. I = think that a related standard might become important in near future = since besides online gaming there is also a plenty of upcoming = interactive and sensor applications that would be sending small = parameter updates (think of smart factory applications for instance or = even e-health services). I highly appreciate the decision to move the = focus away from TCP. Given TCP's limited efficiency for interactive = applications, the concerns of potential impact on its performance should = not put an innovation bottleneck in front of new ideas improving = transport efficiency. > =20 > During the BoF session the question of transport reliability for such = multiplexed packet flows was raised. This would be a point where our lab = could contribute. We developed a "predictably reliable" error control = scheme that operates under strict delay constraints. The scheme would = particularly benefit from the larger packets and the higher aggregate = data rate of the multiplexed packet flows. If such error control would = be considered beneficial in TCM-TF, I'd be happy to become active. > =20 > Best regards, > Manuel Gorius > =20 > On 09.09.2013, at 18:25, Jose Saldana wrote: >=20 >=20 > Dear all, > =20 > As you may know, we had a TCM-TF BoF in IETF87 Berlin = (http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf). > =20 > As a result of the BoF, it was clear (IMHO) that there is some = interest on the topic. There were a number of people who thought that a = WG should be created, and several people also volunteered for reviewing = documents. > =20 > However, in the BoF it was also clear that there are some concerns = that have to be issued before chartering. The main one is the = interaction between TCM optimization and TCP mechanisms. Since TCP = controls its rate depending on the RTT, the addition of a multiplexing = delay may modify and even harm TCP behavior. > =20 > As a consequence, we are going to redefine the Charter, removing the = optimization of TCP. So RTP/UDP and UDP will be the considered options = for optimization. > =20 > We would like to get more people involved in the discussion, so we = would like to invite those who actively participate on Transport Area = discussion to join the mailing list = https://www.ietf.org/mailman/listinfo/tcmtf, in order to get their = feedback. > =20 > Thanks in advance, > =20 > Jose Saldana > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf > =20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf --Apple-Mail=_29F34A69-703D-457A-B360-8A065BE84BF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Jose, Thank you for = your interest. We had set up a project website providing literature = and a Linux kernel module implementing our "Predictably Reliable = Real-time Protocol":
http://www.nt.uni-saarland.de/en/projects/running-projects/prrt.html

For a quick technical overview I'd like to = point you on a poster presentation available under:
http://www.nt.uni-saarland.de/fileadmin/file_uploads/pro= jects/prrt/PRRT_Poster.pdf

Please let me = know if any of the implemented ideas are suitable for the = TCM-TF.

Best regards,
= Manuel

On 10.09.2013, at 16:14, "Jose = Saldana" <jsaldana@unizar.es> = wrote:

It sounds good. Could you please = provide the link to some documentation (e.g. a paper, a report) about = the =93predictably reliable=94 error control = scheme?

De: Manuel Gorius = [mailto:gorius@nt.uni-saarland.de]
Enviado el: martes, 10 de septiembre de = 2013 14:30
Para: jsaldana@unizar.es
CC: tcmtf@ietf.org
Asunto: Re: [tcmtf] Next steps with = TCM-TF
Dear = Jose,
It = was nice to follow the ideas brought up during the TCM-TF BoF. I think = that a related standard might become important in near future since = besides online gaming there is also a plenty of upcoming interactive and = sensor applications that would be sending small parameter updates (think = of smart factory applications for instance or even e-health services). I = highly appreciate the decision to move the focus away from TCP. Given = TCP's limited efficiency for interactive applications, the concerns of = potential impact on its performance should not put an innovation = bottleneck in front of new ideas improving transport = efficiency.
Best = regards,
        &= nbsp; Manuel = Gorius
On = 09.09.2013, at 18:25, Jose Saldana <jsaldana@unizar.es> = wrote:
Dear all,
As you may know, we had a TCM-TF BoF = in IETF87 Berlin ().
As a result of the BoF, it was clear = (IMHO) that there is some interest on the topic. There were a number of = people who thought that a WG should be created, and several people also = volunteered for reviewing documents.
However, in the BoF it was also = clear that there are some concerns that have to be issued before = chartering. The main one is the interaction between TCM optimization and = TCP mechanisms. Since TCP controls its rate depending on the RTT, the = addition of a multiplexing delay may modify and even harm TCP = behavior.
As a consequence, we are going to redefine the Charter, = removing the optimization of TCP. So RTP/UDP and UDP will be the = considered options for optimization.
We would like to get more people = involved in the discussion, so we would like to invite those who = actively participate on Transport Area discussion to join the mailing = list , in order to get their feedback.
Thanks in advance,
Jose Saldanatcmtf@ietf.org
To: "'Manuel Gorius'" References: <017d01cead79$25240a10$6f6c1e30$@unizar.es> <002d01ceae30$0e3460e0$2a9d22a0$@unizar.es> In-Reply-To: Date: Thu, 12 Sep 2013 15:31:38 +0200 Organization: Universidad de Zaragoza Message-ID: <00ec01ceafbc$692c5ab0$3b851010$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00ED_01CEAFCD.2CB6D860" X-Mailer: Microsoft Outlook 14.0 Content-language: es Thread-index: AQHuvPs5z3YNAt6hhH28PKho2tIgMgDdQFaPAxTcTRUBRZLleJlYOgnw X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Next steps with TCM-TF 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 13:31:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00ED_01CEAFCD.2CB6D860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Manuel. I have been reading some of your papers. This is the idea I have got: - You have proposed and implemented a new transport protocol (Predictably Reliable Realtime Transport protocol, PRRT), which would be useful for providing the reliability required by multimedia services under their specific delay constraint. - It is "designed for high-rate and low-latency media services over lossy network infrastructures". - So the first use is video transmission, I think. Can some of the ideas be useful for TCM-TF? As a first question, TCM-TF can only optimize small-packet flows (VoIP, online games, sensor networks, M2M), which usually have low bandwidth requirements, and at the same time require low latency. So the considered services are not the same. You talk about "the question of transport reliability for such multiplexed packet flows". So, are you proposing the possibility of using some of these ideas for improving the reliability of multiplexed flows? Thanks! Jose De: Manuel Gorius [mailto:gorius@nt.uni-saarland.de] Enviado el: martes, 10 de septiembre de 2013 17:08 Para: jsaldana@unizar.es CC: tcmtf@ietf.org Asunto: Re: [tcmtf] Next steps with TCM-TF Jose, Thank you for your interest. We had set up a project website providing literature and a Linux kernel module implementing our "Predictably Reliable Real-time Protocol": http://www.nt.uni-saarland.de/en/projects/running-projects/prrt.html For a quick technical overview I'd like to point you on a poster presentation available under: http://www.nt.uni-saarland.de/fileadmin/file_uploads/projects/prrt/PRRT_Post er.pdf Please let me know if any of the implemented ideas are suitable for the TCM-TF. Best regards, Manuel On 10.09.2013, at 16:14, "Jose Saldana" wrote: Manuel, It sounds good. Could you please provide the link to some documentation (e.g. a paper, a report) about the "predictably reliable" error control scheme? Thanks! Jose De: Manuel Gorius [mailto:gorius@ nt.uni-sa arland.de] Enviado el: martes, 10 de septiembre de 2013 14:30 Para: jsaldana@unizar.es CC: tcmtf@ietf.org Asunto: Re: [tcmtf] Next steps with TCM-TF Dear Jose, It was nice to follow the ideas brought up during the TCM-TF BoF. I think that a related standard might become important in near future since besides online gaming there is also a plenty of upcoming interactive and sensor applications that would be sending small parameter updates (think of smart factory applications for instance or even e-health services). I highly appreciate the decision to move the focus away from TCP. Given TCP's limited efficiency for interactive applications, the concerns of potential impact on its performance should not put an innovation bottleneck in front of new ideas improving transport efficiency. During the BoF session the question of transport reliability for such multiplexed packet flows was raised. This would be a point where our lab could contribute. We developed a "predictably reliable" error control scheme that operates under strict delay constraints. The scheme would particularly benefit from the larger packets and the higher aggregate data rate of the multiplexed packet flows. If such error control would be considered beneficial in TCM-TF, I'd be happy to become active. Best regards, Manuel Gorius On 09.09.2013, at 18:25, Jose Saldana < jsaldana@unizar.es> wrote: Dear all, As you may know, we had a TCM-TF BoF in IETF87 Berlin ( http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf). As a result of the BoF, it was clear (IMHO) that there is some interest on the topic. There were a number of people who thought that a WG should be created, and several people also volunteered for reviewing documents. However, in the BoF it was also clear that there are some concerns that have to be issued before chartering. The main one is the interaction between TCM optimization and TCP mechanisms. Since TCP controls its rate depending on the RTT, the addition of a multiplexing delay may modify and even harm TCP behavior. As a consequence, we are going to redefine the Charter, removing the optimization of TCP. So RTP/UDP and UDP will be the considered options for optimization. We would like to get more people involved in the discussion, so we would like to invite those who actively participate on Transport Area discussion to join the mailing list https://www.ietf.org/mailman/listinfo/tcmtf, in order to get their feedback. Thanks in advance, Jose Saldana _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf ------=_NextPart_000_00ED_01CEAFCD.2CB6D860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi, Manuel.

I have been reading some of your papers. This is the idea I have = got:

- You have proposed and implemented a new transport protocol = (Predictably Reliable Realtime Transport protocol, PRRT), which would be = useful for providing the reliability required by multimedia services = under their specific delay constraint.

- It is “designed for high-rate and low-latency media services = over lossy network infrastructures”.

- So the first use is video transmission, I = think.

Can some of the ideas be useful for TCM-TF?

As a first question, TCM-TF can only optimize small-packet flows = (VoIP, online games, sensor networks, M2M), which usually have low = bandwidth requirements, and at the same time require low = latency.

So the considered services are not the same.

You talk about “the question of transport reliability for such = multiplexed packet flows”. So, are you proposing the possibility = of using some of these ideas for improving the reliability of = multiplexed flows?

Thanks!

Jose

De: = Manuel Gorius [mailto:gorius@nt.uni-saarland.de]
Enviado el: = martes, 10 de septiembre de 2013 17:08
Para: = jsaldana@unizar.es
CC: tcmtf@ietf.org
Asunto: Re: = [tcmtf] Next steps with TCM-TF

Jose, Thank you for your interest. We had set up = a project website providing literature and a Linux kernel module = implementing our "Predictably Reliable Real-time = Protocol":
http://www.nt.uni-saarland.de/en/projects/running-projects/prrt.html=

For a quick technical overview I'd like to point you = on a poster presentation available = under:
http://www.nt.uni-saarland.de/fileadmin/file_uploads/p= rojects/prrt/PRRT_Poster.pdf

Please let me know if any of the implemented ideas are = suitable for the TCM-TF.

Best regards,
        &n= bsp; Manuel

On = 10.09.2013, at 16:14, "Jose Saldana" <jsaldana@unizar.es> = wrote:

Manuel,

It sounds good. Could you please provide the link to some = documentation (e.g. a paper, a report) about the “predictably = reliable” error control scheme?

Thanks!

Jose

De: Manuel = Gorius [mailto:gorius@nt.uni-saarland.de]
Enviado el: martes, 10 de septiembre de = 2013 14:30
Para: jsaldana@unizar.es
CC: tcmtf@ietf.org
Asunto: Re: [tcmtf] Next steps with = TCM-TF

Dear Jose,

It was nice to follow the ideas brought up during the = TCM-TF BoF. I think that a related standard might become important in = near future since besides online gaming there is also a plenty of = upcoming interactive and sensor applications that would be sending small = parameter updates (think of smart factory applications for instance or = even e-health services). I highly appreciate the decision to move the = focus away from TCP. Given TCP's limited efficiency for interactive = applications, the concerns of potential impact on its performance should = not put an innovation bottleneck in front of new ideas improving = transport efficiency.

During the BoF session the question of transport = reliability for such multiplexed packet flows was raised. This would be = a point where our lab could contribute. We developed a "predictably = reliable" error control scheme that operates under strict = delay constraints. The scheme would particularly benefit from the larger = packets and the higher aggregate data rate of the multiplexed packet = flows. If such error control would be considered beneficial in TCM-TF, = I'd be happy to become active.

Best regards,
        &n= bsp; Manuel = Gorius

On 09.09.2013, at 18:25, Jose Saldana <jsaldana@unizar.es> = wrote:

Dear = all,

As you may = know, we had a TCM-TF BoF in IETF87 Berlin (http://www.ietf.org/proceedings/87/minutes/minutes= -87-tcmtf).

As a = result of the BoF, it was clear (IMHO) that there is some interest on = the topic. There were a number of people who thought that a WG should be = created, and several people also volunteered for reviewing = documents.

However, = in the BoF it was also clear that there are some concerns that have to = be issued before chartering. The main one is the interaction between TCM = optimization and TCP mechanisms. Since TCP controls its rate depending = on the RTT, the addition of a multiplexing delay may modify and even = harm TCP behavior.

As a = consequence, we are going to redefine the Charter, removing the = optimization of TCP. So RTP/UDP and UDP will be the considered options = for optimization.

We would = like to get more people involved in the discussion, so we would like to = invite those who actively participate on Transport Area discussion to = join the mailing list https://www.ietf.org/mailman/listinfo/tcmtf= , in order = to get their feedback.

Thanks in = advance,

Jose = Saldana
_________= ______________________________________
tcmtf mailing list
tcmtf@ietf.org
https://www.ietf.org/mailman/listinfo/tcmtf=

_________= ______________________________________
tcmtf mailing list
tcmtf@ietf.org
https://www.ietf.org/mailman/listinfo/tcmtf=

------=_NextPart_000_00ED_01CEAFCD.2CB6D860-- From jsaldana@unizar.es Mon Sep 16 06:53:17 2013 Return-Path: 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 0A07A11E8284; Mon, 16 Sep 2013 06:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.462 X-Spam-Level: X-Spam-Status: No, score=-4.462 tagged_above=-999 required=5 tests=[AWL=-0.464, 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 O7OIuybB0942; Mon, 16 Sep 2013 06:53:12 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 901FD11E8250; Mon, 16 Sep 2013 06:53:11 -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 r8GDr7E3013880; Mon, 16 Sep 2013 15:53:08 +0200 From: "Jose Saldana" To: , Date: Mon, 16 Sep 2013 15:53:09 +0200 Organization: Universidad de Zaragoza Message-ID: <016501ceb2e4$1435f090$3ca1d1b0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01CEB2F4.D7BF5CD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6y35DJ7iXFf9wOQMeil2E9ofeebA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [tcmtf] TCM-TF: topics to be discussed in the list 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 13:53:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0166_01CEB2F4.D7BF5CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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? 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." 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_0166_01CEB2F4.D7BF5CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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

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?

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

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_0166_01CEB2F4.D7BF5CD0-- From repenno@cisco.com Mon Sep 16 13:57:55 2013 Return-Path: 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 DD8A811E8145; Mon, 16 Sep 2013 13:57:55 -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 MQZmbCdVuLwG; Mon, 16 Sep 2013 13:57:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67F11E828A; Mon, 16 Sep 2013 13:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14270; q=dns/txt; s=iport; t=1379365055; x=1380574655; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=7vYEg7mLjUY9T2W4qSD5TH3YOY9Y5DZlcEtfrluftzY=; b=IET8zRUsLmALHHeJzmdwwz/5L4xgxMbRdJ7bhR7rrw1/PrICd5MiGzkS 9Oio9sfTl929pGlZDKKB7CY266ImorotIG6HoGE5Cq5wD4jc6W108Yobt IGmCG0PhtJ2NQF/28LCdCrVMcLnj5qEm6k5LL/Pv0wggdVGfcDoUBH8wB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAG1wN1KtJXHA/2dsb2JhbABagkNEOFLBA4EiFnSCJQEBAQQBAQEqQR0BCBEDAQILAhsuCxQJCAEBBAESCAESh2gMukaPQiANCwaDGIEAA4xQh0+LCopGgySCKg X-IronPort-AV: E=Sophos;i="4.90,918,1371081600"; d="scan'208,217";a="257506258" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 16 Sep 2013 20:57:35 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8GKvYU3010070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Sep 2013 20:57:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 15:57:34 -0500 From: "Reinaldo Penno (repenno)" To: "jsaldana@unizar.es" , "tsv-area@ietf.org" , "tcmtf@ietf.org" Thread-Topic: TCM-TF: topics to be discussed in the list Thread-Index: Ac6y35DJ7iXFf9wOQMeil2E9ofeebAALwjqA Date: Mon, 16 Sep 2013 20:57:34 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B6D884D@xmb-rcd-x04.cisco.com> In-Reply-To: <016501ceb2e4$1435f090$3ca1d1b0$@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.155.67.51] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040B6D884Dxmbrcdx04ciscoc_" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 20:57:56 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6D884Dxmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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. 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. 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. 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_45A697A8FFD7CF48BCF2BE7E106F06040B6D884Dxmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9D7D340BAF02C14FB4D2F14B00D49EE8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
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>
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 gorius@nt.uni-saarland.de Mon Sep 16 17:21:38 2013 Return-Path: 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 8FC0511E8168 for ; Mon, 16 Sep 2013 17:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 Qa7et-bMLT9h for ; Mon, 16 Sep 2013 17:21:24 -0700 (PDT) Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8B11E8160 for ; Mon, 16 Sep 2013 17:21:19 -0700 (PDT) Received: from com.intel-vci.uni-saarland.de (com.intel-vci.uni-saarland.de [134.96.18.58]) by triton.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id r8H0LD49032103; Tue, 17 Sep 2013 02:21:13 +0200 Received: from localhost (localhost [127.0.0.1]) by com.intel-vci.uni-saarland.de (Postfix) with ESMTP id BD41D972001; Tue, 17 Sep 2013 02:21:13 +0200 (CEST) Received: from com.intel-vci.uni-saarland.de ([127.0.0.1]) by localhost (com.intel-vci.uni-saarland.de [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id V0Q8asonb4WG; Tue, 17 Sep 2013 02:21:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by com.intel-vci.uni-saarland.de (Postfix) with ESMTP id 8705B972002; Tue, 17 Sep 2013 02:21:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at intel-vci.uni-saarland.de Received: from com.intel-vci.uni-saarland.de ([127.0.0.1]) by localhost (com.intel-vci.uni-saarland.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id okyageT-bKPj; Tue, 17 Sep 2013 02:21:10 +0200 (CEST) Received: from com.intel-vci.uni-saarland.de (localhost [127.0.0.1]) by com.intel-vci.uni-saarland.de (Postfix) with ESMTP id 5096E972001; Tue, 17 Sep 2013 02:21:10 +0200 (CEST) Date: Tue, 17 Sep 2013 02:21:10 +0200 (CEST) From: Manuel Gorius To: jsaldana@unizar.es Message-ID: <917683638.212231.1379377270245.JavaMail.zimbra@nt.uni-saarland.de> In-Reply-To: <00ec01ceafbc$692c5ab0$3b851010$@unizar.es> References: <017d01cead79$25240a10$6f6c1e30$@unizar.es> <002d01ceae30$0e3460e0$2a9d22a0$@unizar.es> <00ec01ceafbc$692c5ab0$3b851010$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.55.60.72] X-Mailer: Zimbra 8.0.4_GA_5739 (zclient/8.0.4_GA_5739) Thread-Topic: Next steps with TCM-TF Thread-Index: AQHuvPs5z3YNAt6hhH28PKho2tIgMgDdQFaPAxTcTRUBRZLleJlYOgnwsFl5IMk= X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (triton.rz.uni-saarland.de [134.96.7.25]); Tue, 17 Sep 2013 02:21:14 +0200 (CEST) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-14; AVE: 7.9.10.68; VDF: 7.11.99.164; host: AntiVir3) Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Next steps with TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 00:21:38 -0000 Hi Jose, Indeed the efficiency of the proposed error control scheme increases for hi= gher data rates. I was assuming that the multiplexing of several flows woul= d result in a reasonably high rate. The mechanisms deployed in our protocol= , however, also scale down to lower rates.=20 My idea after reading the notes taken during the BoF session was that this = scheme could provide transparent error control on the multiplexed link segm= ent so as to mitigate the impact of lost aggregated frames on ent-to-end er= ror control of higher layers. I think delay-constrained error control is es= sential for those multiplexed flows. Simple, reactive packet repetitions mi= ght induce too much of unpredictable latency. Best regards, Manuel ----- Urspr=C3=BCngliche Mail ----- Von: Jose Saldana An: 'Manuel Gorius' CC: tcmtf@ietf.org Gesendet: Thu, 12 Sep 2013 15:31:38 +0200 (CEST) Betreff: Re: [tcmtf] Next steps with TCM-TF Hi, Manuel. =20 I have been reading some of your papers. This is the idea I have got: =20 - You have proposed and implemented a new transport protocol (Predictably Reliable Realtime Transport protocol, PRRT), which would be useful for providing the reliability required by multimedia services under their specific delay constraint. =20 - It is "designed for high-rate and low-latency media services over lossy network infrastructures". =20 - So the first use is video transmission, I think. =20 =20 Can some of the ideas be useful for TCM-TF? =20 As a first question, TCM-TF can only optimize small-packet flows (VoIP, online games, sensor networks, M2M), which usually have low bandwidth requirements, and at the same time require low latency. =20 So the considered services are not the same. =20 You talk about "the question of transport reliability for such multiplexed packet flows". So, are you proposing the possibility of using some of these ideas for improving the reliability of multiplexed flows? =20 Thanks! =20 Jose =20 De: Manuel Gorius [mailto:gorius@nt.uni-saarland.de]=20 Enviado el: martes, 10 de septiembre de 2013 17:08 Para: jsaldana@unizar.es CC: tcmtf@ietf.org Asunto: Re: [tcmtf] Next steps with TCM-TF =20 Jose, Thank you for your interest. We had set up a project website providin= g literature and a Linux kernel module implementing our "Predictably Reliable Real-time Protocol":=20 http://www.nt.uni-saarland.de/en/projects/running-projects/prrt.html =20 For a quick technical overview I'd like to point you on a poster presentation available under:=20 http://www.nt.uni-saarland.de/fileadmin/file_uploads/projects/prrt/PRRT_Pos= t er.pdf =20 Please let me know if any of the implemented ideas are suitable for the TCM-TF. =20 Best regards, Manuel =20 On 10.09.2013, at 16:14, "Jose Saldana" wrote: Manuel, =20 It sounds good. Could you please provide the link to some documentation (e.g. a paper, a report) about the "predictably reliable" error control scheme? =20 Thanks! =20 Jose =20 De: Manuel Gorius [mailto:gorius@ nt.uni-sa arland.de]=20 Enviado el: martes, 10 de septiembre de 2013 14:30 Para: jsaldana@unizar.es CC: tcmtf@ietf.org Asunto: Re: [tcmtf] Next steps with TCM-TF =20 Dear Jose, =20 It was nice to follow the ideas brought up during the TCM-TF BoF. I think that a related standard might become important in near future since besides online gaming there is also a plenty of upcoming interactive and sensor applications that would be sending small parameter updates (think of smart factory applications for instance or even e-health services). I highly appreciate the decision to move the focus away from TCP. Given TCP's limite= d efficiency for interactive applications, the concerns of potential impact o= n its performance should not put an innovation bottleneck in front of new ideas improving transport efficiency. =20 During the BoF session the question of transport reliability for such multiplexed packet flows was raised. This would be a point where our lab could contribute. We developed a "predictably reliable" error control schem= e that operates under strict delay constraints. The scheme would particularly benefit from the larger packets and the higher aggregate data rate of the multiplexed packet flows. If such error control would be considered beneficial in TCM-TF, I'd be happy to become active. =20 Best regards, Manuel Gorius =20 On 09.09.2013, at 18:25, Jose Saldana < jsaldana@unizar.es> wrote: Dear all, =20 As you may know, we had a TCM-TF BoF in IETF87 Berlin ( http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf). =20 As a result of the BoF, it was clear (IMHO) that there is some interest on the topic. There were a number of people who thought that a WG should be created, and several people also volunteered for reviewing documents. =20 However, in the BoF it was also clear that there are some concerns that hav= e to be issued before chartering. The main one is the interaction between TCM optimization and TCP mechanisms. Since TCP controls its rate depending on the RTT, the addition of a multiplexing delay may modify and even harm TCP behavior. =20 As a consequence, we are going to redefine the Charter, removing the optimization of TCP. So RTP/UDP and UDP will be the considered options for optimization. =20 We would like to get more people involved in the discussion, so we would like to invite those who actively participate on Transport Area discussion to join the mailing list https://www.ietf.org/mailman/listinfo/tcmtf, in order to get their feedback= . =20 Thanks in advance, =20 Jose Saldana _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf =20 _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf =20 From jsaldana@unizar.es Wed Sep 18 06:59:15 2013 Return-Path: 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 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> 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 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 Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion 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: 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)" To: "jsaldana@unizar.es" , "tsv-area@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" 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;

&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;

&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: 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 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$'" , , 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 Subject: [tcmtf] TCM-TF: Path MTU 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" 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: 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 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" 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 Subject: Re: [tcmtf] TCM-TF: Path MTU X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion 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: 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 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> 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 Subject: Re: [tcmtf] TCM-TF: Path MTU 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" 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 > >