Thanks, inline with [RP2]

From: Jose Saldana <[email protected]<mailto:[email protected]>>
Organization: Universidad de Zaragoza
Reply-To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Wednesday, September 18, 2013 6:58 AM
To: Cisco Employee <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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:[email protected]]
Enviado el: lunes, 16 de septiembre de 2013 22:58
Para: [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>>
Organization: Universidad de Zaragoza
Reply-To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Monday, September 16, 2013 6:53 AM
To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]> 
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.

[RP2] The console itself (not a game) does MTU probing. If there is a MTU 
problem you get a network error.



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

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


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

Reply via email to