> -----Mensaje original----- > De: Reinaldo Penno (repenno) [mailto:[email protected]] > Enviado el: viernes, 27 de septiembre de 2013 16:12 > Para: [email protected]; [email protected]; [email protected] > Asunto: Re: TCM-TF: Path MTU > > > > On 9/27/13 6:56 AM, "Jose Saldana" <[email protected]> wrote: > > >Just my opinion about the MTU problem when TCM-optimizing: > > > > > >(Š) > >>>>>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. > > > > (Š) > > > >[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? >
[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. > > [RP] Agree. > > > > >What do you think? > > > >Jose > >
