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