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

Thank you Patrick.

Thus I suggest that we keep "Join/LeaveMulticastGroup methods" in the spec - the easiest way and it is worth doing.

Thank you again
Bin

From: patrick.ducksong@gmail.com [mailto:patrick.ducksong@gmail.com] On Behalf Of Patrick McManus
Sent: Wednesday, May 08, 2013 8:59 AM
To: Jonas Sicking
Cc: HU, BIN; 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.

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<mailto: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<mailto: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<mailto:jonas@sicking.cc>]
Sent: Tuesday, May 07, 2013 4:43 PM

To: HU, BIN
Cc: Nilsson, Claes1; public-sysapps@w3.org<mailto: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<mailto: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<mailto:jonas@sicking.cc>]
Sent: Tuesday, May 07, 2013 3:08 PM

To: HU, BIN
Cc: Nilsson, Claes1; public-sysapps@w3.org<mailto: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<mailto: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<mailto:jonas@sicking.cc>]
Sent: Tuesday, May 07, 2013 11:59 AM
To: HU, BIN
Cc: Nilsson, Claes1; public-sysapps@w3.org<mailto: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<mailto: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<mailto:Claes1.Nilsson@sonymobile.com>]
Sent: Tuesday, May 07, 2013 8:08 AM
To: public-sysapps@w3.org<mailto: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<tel:%2B46%20705%2056%2068%2078>
sonymobile.com<http://sonymobile.com/>

[SONY make.believe]