Re: [tcmtf] 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 but
sometimes deal with issues in this space due to ISP worries.

Inline with [RP]

From: Jose Saldana <jsaldana@unizar.es>
Organization: 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>
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

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