Subject: TCM-TF: topics to be discussed in the list

From: "Jose Saldana" <[email-masked]>
Date: Mon, 16 Sep 2013 15:53:09 +0200

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 [email-masked] 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>
https://www.ietf.org/mailman/listinfo/tcmtf).

Reading the BoF minutes (
<http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf>
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

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 16 Sep 2013 20:57:34 +0000

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 <[email-masked]<mailto:[email-masked]>>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 16, 2013 6:53 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 [email-masked]<mailto:[email-masked]> 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”.

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

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.

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.

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

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 18 Sep 2013 15:58:57 +0200

Reinaldo,

Thanks a lot and welcome to the list!

Some other comments inline.

Jose

De: Reinaldo Penno (repenno) [mailto:[email-masked]] 
Enviado el: lunes, 16 de septiembre de 2013 22:58
Para: [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, September 16, 2013 6:53 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: TCM-TF: topics to be discussed in the list

 

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

[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>
http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf)

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

 

Any other questions?

Thanks a lot,

Jose Saldana

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 18 Sep 2013 16:21:52 +0000

Thanks, inline with [RP2]

From: Jose Saldana <[email-masked]<mailto:[email-masked]>>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 18, 2013 6:58 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: TCM-TF: topics to be discussed in the list

Reinaldo,

Jose

De: Reinaldo Penno (repenno) [mailto:[email-masked]]
Enviado el: lunes, 16 de septiembre de 2013 22:58
Para: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: Re: TCM-TF: topics to be discussed in the list

Hello Jose,

Inline with [RP]

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

[Jose] The idea of this is that we would only consider it for the “rush hour”, when the alternative is “additional delay” or “no service”.

[RP2] Got it, but where is the contention? If the CPE then maybe a LLQ would help.

But this is not only for games. It can also be useful for VoIP (in fact, RFC4170 already exists and it does exactly this), and for Machine to Machine communications.

[RP2] Good point.

Regarding games, this may happen in certain moments/points in the network due to different causes: release of a new game (or new content in an existing game).

In addition, we are considering a second draft with the delay limits for each service. If the limit is 10 ms for a game, the bandwidth savings can still be high if the number of players is big enough (Counter Strike: 20 players, 10 ms, 25% savings, see 8 games in http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf)

[RP2] thanks, I skimmed through it. Do you have traces and measurements for CoD on the XBOX360 platform? That would be probably the biggest bang for the buck. I will certainly read you paper.

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

Any other questions?

Thanks a lot,

Jose Saldana