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

From: John Buford <[email-masked]>
Date: Mon, 6 Feb 2012 11:51:43 -0500

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

---

From: Sebastian Meiling <[email-masked]>
Date: Wed, 22 Feb 2012 14:48:12 +0100

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:
> _______________________________________________
> SAM mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/sam

-- 
Sebastian Meiling
+---------------------------------------+
  Internet Technologies Research Group
  Department of Computer Science
  Hamburg University of Applied Sciences
  Berliner Tor 7, 20099 Hamburg, Germany
+---------------------------------------+
  Mail: [email-masked]
   Fon: +49 40 42875 - 8067
   Fax: +49 40 42875 - 8409
   Web: http://www.haw-hamburg.de/inet
+---------------------------------------+

---

From: Matthias Waehlisch <[email-masked]>
Date: Sun, 26 Feb 2012 15:52:03 +0100

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:[email-masked] .. 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.
> 
> 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
>

---

From: "John Buford" <[email-masked]>
Date: Mon, 27 Feb 2012 14:02:58 -0500

Following comments with my RG chair hat off.

Document is well written, design is good.  Great to see implementation work
accompanying the ID.
AFAIK, available multicast APIs are technology specific.  Perhaps this point
should be made in the document.

p. 11 "Names can uniquely determine a group in a global communication
context".
- regarding "can", should this be "must" or "should"?
- please add language that specifies whether group names are intended to be
unique 
  (by namespace domain, by all domains, across all active sessions, across
all past present or future sessions, other)?
- is the application responsible for selecting group names and determining
uniqueness?

p. 11 "Details of service discovery are out of scope of this document"
  - is it intended that this be 1) implementation specific detail, 2)
addressed in another specification,
    3) use an existing service discovery mechanism (if so, such as)?

p. 12, 15

   is "sips" a possible scheme?

p. 10 "It group communication services ..."  ?

p. 19 (4.4.2) 
- is Receive meant to be non-blocking or blocking?
- Can the application receive an event when data is available to receive?

- How do you see an application implementing multi-resolution multicast with
this?

- how is mobility across multicast domains supported, that is, if a roaming
client moves from an IPv4 multicast
  network to an overlay multicast network, is 1) the transition handled by
the middleware,
  2) the transition detectable by the application through the API, 
  3) requires the application to detect the transition and make the
appropriate calls to the API
     to reconfigure the membership and socket?

- how is XCAST (or, generally multi-destination multicast routing)
supported?
   For example, the discussion 3.5 Name to Address Mapping would seem to be
effected
   if we want to be able to associate a group name with a list of unicast
addresses.

- msg assembly/disassembly handled by the middleware for messages too large
to send in one multicast packet?

-----Original Message-----
From: John Buford [mailto:[email-masked]] 
Sent: Monday, February 06, 2012 11:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: RG last call for draft-irtf-samrg-common-api-04

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.

Thanks,

John