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

Sebastian Meiling <> Wed, 22 February 2012 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 579A021F87D4 for <>; Wed, 22 Feb 2012 05:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ShkuAr5kLnGF for <>; Wed, 22 Feb 2012 05:48:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B59A121F87C7 for <>; Wed, 22 Feb 2012 05:48:15 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/RC4-MD5; 22 Feb 2012 14:48:13 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 22 Feb 2012 14:48:13 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 22 Feb 2012 14:48:12 +0100
Message-ID: <>
Date: Wed, 22 Feb 2012 14:48:12 +0100
From: Sebastian Meiling <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [SAM] RG last call for draft-irtf-samrg-common-api-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Feb 2012 13:48:20 -0000

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.


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.
> Thanks,
> John
> _______________________________________________
> SAM mailing list

Sebastian Meiling
  Internet Technologies Research Group
  Department of Computer Science
  Hamburg University of Applied Sciences
  Berliner Tor 7, 20099 Hamburg, Germany
   Fon: +49 40 42875 - 8067
   Fax: +49 40 42875 - 8409