Re: [sysapps/raw socket api]:Proposal for resolution of remaining issues.

Generally the impact of lots of UDP sockets is fairly small - I wouldn't be
afraid of it, but at the same time if it is easy to tweak around the edges
then it can be worth doing.

1] each one costs you some buffers, so consolidating reduces that. OTOH it
means you might see overruns more easily of the more limited buffering you
have and that's not necessarily a win. Which way you go depends on which is
more important to you (footprint or reliability).

2] each port allocation definitely has a cost in state at the network level
for NATs and cell towers etc. Sometimes these things comes with strict
quotas for UDP (much more strict than TCP). and the quota is effectively
not discoverable. Exceeding quota can have awful failure modes such as
silent timeouts. That's the best argument for UDP port consolidation imo.


On Tue, May 7, 2013 at 8:23 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> I we might be talking past each other, or I'm simply misunderstanding
> something.
>
> The question was whether it would be a problem to prevent a single
> UDPSocket instance from joining N multicast groups. My proposed solution
> was to request that apps that want to join N multicast groups create N
> UDPSocket instances, each joining a single multicast group.
>
> That shouldn't affect battery usage as far as I know, but I don't know if
> it the amount of memory or buffers that is used. And I don't know if that
> forces a different patterns of outgoing ports. Nor do I know if that's less
> convenient for authors.
>
> cc'ing Patrick McManus from our networking team who knows more about this
> stuff than me.
>
> / Jonas
>
>
> On Tue, May 7, 2013 at 4:47 PM, HU, BIN <bh526r@att.com> wrote:
>
>>  The issue is not “2 v.s. 1”, but potentially “many v.s. 1”, where
>> “many” is unknown – depending on deployment and popularity in commercial
>> market.****
>>
>> ** **
>>
>> Thanks****
>>
>> Bin****
>>
>> ** **
>>
>> *From:* Jonas Sicking [mailto:jonas@sicking.cc]
>> *Sent:* Tuesday, May 07, 2013 4:43 PM
>>
>> *To:* HU, BIN
>> *Cc:* Nilsson, Claes1; public-sysapps@w3.org; Isberg, Anders;
>> Edenbrandt, Anders; Isaksson, Björn
>> *Subject:* Re: [sysapps/raw socket api]:Proposal for resolution of
>> remaining issues.****
>>
>> ** **
>>
>> On Tue, May 7, 2013 at 3:24 PM, HU, BIN <bh526r@att.com> wrote:****
>>
>>  Even if UDP is connectionless, which means less resource requirement
>> than connection-oriented TCP, it still consumes system resources such as
>> memory / buffer, port and CPU to maintain its “open” status and ready to
>> handle possible incoming datagrams at any time. And more importantly, it
>> means more battery drain in handheld devices.****
>>
>>  ** **
>>
>> Is there really a difference in memory/buffer/battery/port usage to keep
>> two UDPSockets open compared to keeping just one which listens to two
>> multicast ports?****
>>
>> / Jonas****
>>
>>  ****
>>
>>   ****
>>
>> Thanks****
>>
>> Bin****
>>
>>  ****
>>
>> *From:* Jonas Sicking [mailto:jonas@sicking.cc]
>> *Sent:* Tuesday, May 07, 2013 3:08 PM****
>>
>>
>> *To:* HU, BIN
>> *Cc:* Nilsson, Claes1; public-sysapps@w3.org; Isberg, Anders;
>> Edenbrandt, Anders; Isaksson, Björn
>> *Subject:* Re: [sysapps/raw socket api]:Proposal for resolution of
>> remaining issues.****
>>
>>  ****
>>
>> Does keeping UDP sockets "open" really use any system resources?****
>>
>> / Jonas****
>>
>>  ****
>>
>> On Tue, May 7, 2013 at 12:12 PM, HU, BIN <bh526r@att.com> wrote:****
>>
>> The socket resources on embedded devices (TV, tablets, smartphones) are
>> limited. If there are hundreds of channels, and if hundreds of sockets are
>> open, the concern is that the performance of device, and thus the user
>> experience will be unpleasant.****
>>
>>  ****
>>
>> There are many implementation choices, and we may want to keep the
>> choices open. For example, implementation can open a certain number of
>> sockets (depending on the device’s limit), and each socket serves a certain
>> number of channels, etc. Ultimately, the goal is to keep the desired user
>> experience consistently across a variety of devices.****
>>
>>  ****
>>
>> Thanks****
>>
>> Bin****
>>
>>  ****
>>
>> *From:* Jonas Sicking [mailto:jonas@sicking.cc]
>> *Sent:* Tuesday, May 07, 2013 11:59 AM
>> *To:* HU, BIN
>> *Cc:* Nilsson, Claes1; public-sysapps@w3.org; Isberg, Anders;
>> Edenbrandt, Anders; Isaksson, Björn
>> *Subject:* Re: [sysapps/raw socket api]:Proposal for resolution of
>> remaining issues.****
>>
>>  ****
>>
>> Does this mean that they have to use a single UDPSocket instance to
>> listen to all those groups? Are there advantages to?****
>>
>> / Jonas****
>>
>>  ****
>>
>> On Tue, May 7, 2013 at 10:36 AM, HU, BIN <bh526r@att.com> wrote:****
>>
>> With regard to Issue 12 “Join/LeaveMulticastGroup”, I think there are
>> various commercial use cases we should consider. For example, commercial
>> radio and TV services adopt multicast-addressable services, e.g. BBC Radio,
>> Virgin Radio, and Telekom Austria, in receiving radio and TV broadcast. A
>> user may want to listen to radio and watch TV from multiple providers, thus
>> need the ability to join several multicast groups simultaneously, e.g.
>> preview some other channels while watching one channel.****
>>
>>  ****
>>
>> Just 2 my cents****
>>
>> Thanks****
>>
>>  ****
>>
>> Bin****
>>
>>  ****
>>
>> *From:* Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com]
>> *Sent:* Tuesday, May 07, 2013 8:08 AM
>> *To:* public-sysapps@w3.org
>> *Cc:* Isberg, Anders; Edenbrandt, Anders; "Isaksson, Björn"
>> *Subject:* [sysapps/raw socket api]:Proposal for resolution of remaining
>> issues.****
>>
>>  ****
>>
>> Hi,****
>>
>>  ****
>>
>> There are 7 open issues for the Raw Socket API.****
>>
>>  ****
>>
>> I propose the following for each issue :****
>>
>>  ****
>>
>> https://github.com/sysapps/raw-sockets/issues/11: Devices have more than
>> one network interface. However, the issue is whether web applications
>> should be able to select a specific local network interface to use for a
>> socket or if always the “default interface”/the configured interface should
>> be used. My view is that we should provide this possibility by an optional
>> field in the constructor’s options attribute. I must admit that I have
>> difficulties in motivating this by tangible use cases but I haven’t seen
>> any existing TCP or UDP socket API that  does not provide the possibility
>> to bind a socket to a local address. So there must be use cases and I
>> propose that we keep this possibility in the specification. Objections?**
>> **
>>
>>  ****
>>
>> https://github.com/sysapps/raw-sockets/issues/12: I propose a
>> simplification here by removing the Join/LeaveMulticastGroup methods and
>> instead adding the optional field “DOMString multicastGroupAddress” to
>> dictionary UDPOptions. This means that if this field is present when the
>> constructor is executed the UA will join the requested multicast group for
>> the socket using for example IGMP. The UA leaves the multicast group when
>> the UDP socket is closed through the close()  method. However, this assumes
>> that there are no use cases for a socket to belong to several multicast
>> groups simultaneously and/or for continuing to use a socket that previously
>> was belonging to a multicast group. Do we have such use cases? If not I
>> suggest that we use a field in dictionary UDPOptions to state multicast
>> group instead of explicit methods. Objections?****
>>
>>  ****
>>
>> https://github.com/sysapps/raw-sockets/issues/13: Any objection to
>> adding “boolean addressReuse;” to TCPServerOptions dictionary?****
>>
>>  ****
>>
>> https://github.com/sysapps/raw-sockets/issues/14: I have listed some
>> basic use cases at
>> http://www.w3.org/wiki/System_Applications_WG:_Raw_Sockets_API but each
>> use case may need some elaboration. Any input, also including additional
>> use cases, from the WG is appreciated.****
>>
>>  ****
>>
>> https://github.com/sysapps/raw-sockets/issues/16: “Note that even if the
>> socket is only sending to a multicast address, it is a good practice to
>> explicitly join the multicast group (otherwise some routers may not relay
>> packets).” This statement is based on input from 4D but I can’t find any
>> documentation that supports the statement. Could 4D or any other party
>> provide any documentation supporting this statement? ****
>>
>>  ****
>>
>> https://github.com/sysapps/raw-sockets/issues/15: Just fix.****
>>
>>  ****
>>
>> https://github.com/sysapps/raw-sockets/issues/10: Currently the options
>> argument for TCP and TCPServer sockets just have a Boolean field
>> “useSecureTransport;”. This might be enough for a TCP client socket for
>> server authentication using the default certificate and keys. If we need to
>> support client authentication I guess that a client certificate has to be
>> selected but I am not sure if this is something that should be exposed to
>> the web application? For the secure TCP server sockets (if we should
>> support that?) certificates and keys have to be provisioned but once again
>> I am not sure what has to be exposed to web applications.****
>>
>> Ke-Fong has promised to provide input on secure sockets.****
>>
>>  ****
>>
>> Comments?****
>>
>>  ****
>>
>> Claes****
>>
>>  ****
>>
>>  ****
>>
>> *Claes Nilsson M.Sc.E.E** *****
>>
>> Master Engineer - Web Research ****
>>
>> Advanced Application Labs****
>>
>>  ****
>>
>> Sony Mobile Communications****
>>
>> Tel: +46 705 56 68 78****
>>
>> sonymobile.com****
>>
>>  ****
>>
>> [image: SONY make.believe]****
>>
>>  ****
>>
>>  ****
>>
>>  ****
>>
>>  ** **
>>
>
>