Re: [SAM] RG last call for draft-irtf-samrg-common-api-04

Hi Sebastian,

  thanks for your comments!

  Handling MTU is more challenging in a scenario of multiple 
technologies as envisioned by the common mcast API. Different 
technologies may have different MTUs (that may change over time), 
interfaces may change dynamically (e.g., mobile scenarios) etc. However, 
dealing with MTU issues should not add extra complexity to the 
programmer side. It's not very practical if the programmer needs to 
check continously the feasible message size, for example. From this 
perspective, we think that a programming model and a middleware layer 
(implementing the group communication stack) should guarantee some 
maximal message size to the application developer.

  Nevertheless, you are completely right that more detailed error codes 
are required. We will add extended error codes for the send/receive 
calls, which will inform the user about message size issues. We will 
also add a new subsection that briefly discusses MTU issues.

Thanks
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

On Wed, 22 Feb 2012, Sebastian Meiling wrote:

> Hi all,
> 
> here some feedback on the document. In our project HAMcast we are implementing
> the common multicast API as part of our prototype. Lately we had some
> discussion in our group over the current definitions of the send and receive
> calls, and their error handling.
> 
> At the moment error handling is quite limited and just indicates success or
> failure of send/recv operation. From a developers perspective this might be a
> little coarse, as there is no information on what to do about the error. A
> common problem would be the size of data (message), that an application would
> like to send within one send call.
> 
> Using IP multicast (with standard socket API) data is send via UDP, thus
> message size is at least limited by UDP length field of 16 bits = 65K. But
> could also be limited by the OS, i.e. Linux allows to send 65K sized multicast
> messages, but Apple (MacOS X 10.7) has a limit of just 9K. Trying to send
> larger messages results in a error, e.g. "message to big".
> 
> Another issues is the effective packet size on wire (MTU). Applications like
> video streaming often optimize their message size to fit in a single IP
> packet. Thereby, reducing overhead due to IP fragmentation and/or (path) MTU
> detection in IPv6. Though, PathMTU detection for multicast is possible,
> discussions in other IETF WGs (mboned) recommend to use minimal MTU of 1280
> for multicast for IPv6.
> 
> Note: RFC 3542 defines some additional options for the socket API, that would
> be useful in these cases. But our investigation shows, that these are
> experimental  and not yet supported by most standard OS, i.e. Linux and MacOS
> X.
> 
> However besides these IPv6 specific issues, we think that the API should be
> extended by calls to allow applications to detect message and MTU sizes.
> Further error handling should be refined for send and recv.
> 
> Regards,
>   Sebastian
> 
> Am 06.02.2012 17:51, schrieb John Buford:
> > 
> > This is to initiate a last call for the Common API document.
> > 
> > The document and related implementation work have been presented at multiple
> > RG meetings.
> > 
> > Comments from the RG are requested to progress this document along the RFC
> > path.
> > 
> > Please review the document and provide your comments by Feb. 24.
> > 
> > ID URL: http://datatracker.ietf.org/doc/draft-irtf-samrg-common-API
> > 
> > Thanks,
> > 
> > John
> > _______________________________________________
> > SAM mailing list
> > SAM@irtf.org
> > http://www.irtf.org/mailman/listinfo/sam
> 
> 