[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

a) you could have a look at RFC 4571 where the same problem is addressed for RTP

b) Yes, MMT packets have a defined start and end. These have to be conveyed across the transport. Datagram transports (like UDP) have that, stream transports (like TCP) don’t. The notion of needing MTU at this level is incorrect IMHO, this should be left and dealt with at the network layer. Receive buffer size has nothing to do with message boundary. 

c) As noted, you’ll need to communicate the start and end of the MMT, either implicitly (through the use of a datagram transport) or explicitly (through the use of a framing protocol, like RFC 4571for instance, between MMT and TCP)

Thanks,

Jaap

On 8 Feb 2017, at 02:16, samira afzal <afzal.samira@xxxxxxxxx> wrote:

Thanks for your guides and helps Jaap and Anders.

Jaap,

a) What could be " protocol on top of TCP"? could you please tel me some examples? could MPEG-Dash be an instance?  The application that i am using is MMT protocol. 

 b) In the sender side, MMT checks the  length of each sample and it has to be at most equal to MTU ( which sets with user) if it is more than that value, then it divides to several fragments each one at most equal to MTU size . Is it different of what you tell about message boundary at sender side? 

At receiver, MMT is receiving data with size of recv buffer (in socket programming) and i believe it is not  "message boundary information" that you are talking about.

c) What do you suggest to me? changing MMT and adding this boundary? or adding another protocol beside MMT and TCP?

Thanks a lot for your time and guides.