FW: Using UDP in web/HTML5

[Santosh Sampath]

Hi Chrome team,

 

I work for Citrix where we have HTML5 app which uses many Web APIs to deliver remote apps/desktops in a browser tab.

One of the important API is network where we are using WebSockets. These are TCP based. We would like to leverage UDP for networking where we have more control on configuration of sockets in poor/lossy networks where TCP doesn’t scale well.

 

From search through internet/drafts these are some of the docs:

 

https://www.w3.org/TR/tcp-udp-sockets/ This is ideal API which provides raw TCP and UDP sockets in web without any overhead.

·       We would like to know if this or anything similar is coming anytime to web as the draft seems to not progressing after 2015?

 

UDP transport for websockets: Did not find any IETF draft but there are lot of search queries on web so people are probably interested. Is there any way we can make such a request?

 

Others:

·       WebRTC based datachannels: These are based on SCTP protocol on top of UDP. This is the closest to our use case that is available but ideally we would like to have access to raw (or little protocol like websockets) as we need to configure the connection settings ourselves instead of platform.

·       QUIC: It is based on UDP but we would need more along the lines of websockets. This is again not widely adopted.

·       WebAssembly (http://webassembly.org/docs/future-features/ network not really mentioned but things like threads/multiprocess are there so may be in future?)

 

Thanks,

Santosh

 

From: Santosh Sampath
Sent: Monday, May 1, 2017 8:27 PM
To: Ketaki Deshpande <ket...@google.com>; David Karam <dsk...@google.com>
Cc: Georgy Momchilov <Georgy.M...@citrix.com>; Vipin Borkar <Vipin....@citrix.com>; Rajkumar V Rajamanickam <rajkumarv.r...@citrix.com>
Subject: Using UDP in web/HTML5

 

Hi Ketaki/David,

 

We have been talking about Receiver for Chrome features but we have a request for the web version. Our HTML5/web Receiver is also an important use case as it helps many customers to use without installing on endpoints including Chromebooks where everything is usually web based.

 

Request:

We would like to know from your Chrome browser/platform engineers is there anything that is being developed to support UDP sockets support in HTML5 web API.

 

Background:

UDP sockets are important for development of an important Citrix feature called Adaptive transport

Today we have websockets in HTML5, which is TCP based. We do not have equivalent API for UDP.

There is UDP socket api available in ChromeOS but this request is for Web API. In general we would like to use web API if it is available and I think Chrome team also would encourage that.

 

APIs/drafts known:

https://www.w3.org/TR/tcp-udp-sockets/ This is ideal API which provides raw TCP and UDP sockets in web without any overhead.

·       We would like to know if this or anything similar is coming anytime to web as the draft seems to not progressing after 2015?

 

·       UDP transport for websockets: Did not find any IETF draft but there are lot of search queries on web so people are probably interested. Is there any way we can make such a request?

 

·       WebRTC based datachannels: These are based on SCTP protocol on top of UDP. This is the closest to our use case that is available but ideally we would like to have access to raw (or little protocol like websockets) as we need to configure the connection settings ourselves instead of platform.

 

·       QUIC: It is based on UDP but we would need more along the lines of websockets. This is again not widely adopted.

 

Thanks,
Santosh

[Takeshi Yoshino]

Hi Santosh,

On Thu, May 11, 2017 at 5:55 PM, Santosh Sampath <santosh...@citrix.com> wrote:

Hi Chrome team,

 

I work for Citrix where we have HTML5 app which uses many Web APIs to deliver remote apps/desktops in a browser tab.

One of the important API is network where we are using WebSockets. These are TCP based. We would like to leverage UDP for networking where we have more control on configuration of sockets in poor/lossy networks where TCP doesn’t scale well.

 

Yeah, we're receiving similar comments e.g. from game industry. cbentzel@ has been having some early discussion and I'm still catching up with it.

Could you tell us what kind of characteristics are important for your use cases in detail? That would be helpful.

 

From search through internet/drafts these are some of the docs:

 

https://www.w3.org/TR/tcp-udp-sockets/ This is ideal API which provides raw TCP and UDP sockets in web without any overhead.

·       We would like to know if this or anything similar is coming anytime to web as the draft seems to not progressing after 2015?

My gut feeling is that we cannot provide raw access to TCP/UDP considering the security model of the web platform but it'll be something like WebSocket protocol. 

 

 

UDP transport for websockets: Did not find any IETF draft but there are lot of search queries on web so people are probably interested. Is there any way we can make such a request?

 

No. There has been some discussions about UDP version of WS, but nothing (spec, impl) happened actually.

 

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-dev+unsubscribe@chromium.org.
To post to this group, send email to blink-ne...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/2a9a78b80f734aedb2c27bb109beb8a8%40SINPEX02CL02.citrite.net.

[Santosh Sampath]

Thank you very much Takeshi for quick response. Including Georgy, who is our architect for core protocol and transport layer.

 

I will let him explain better about network characteristics, use cases better which we are trying to solve/have solved.

 

Thanks,
Santosh

Hi Santosh,

 

--

To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.

[Chris Bentzel]

Thanks for adding me. I'd also agree that raw socket access will be a tough bridge to cross - I'd be particularly worried about anything without a handshake being used as a DDoS vector. But I am very interested in hearing what characteristics are needed.

[Georgy Momchilov]

Hi Takeshi,

 

Thank you for looking into this.

 

Ideally, we need access to a raw/direct UDP socket but something close to it may also work.

 

We have developed a new reliable in-order transmission protocol over UDP with its own ACKs, NACKs, etc. similar to TCP but with better congestion and flow control. TCP has RTT bias over WAN conditions (high latency and/or some packet loss) and does not saturate the available bandwidth well. With our protocol we get equal throughput performance on LAN but considerably better bandwidth saturation than TCP on WAN. This increases the performance of our presentation-layer protocol traffic, e.g. Graphics, Multimedia, File transfer, Printing  by anywhere between 2x to 10x depending on the nature the presentation-layer protocol: chatty/interactive vs. stream oriented. Another consideration in the congestion control algorithm is fairness.

 

In addition, we are adding lossy transmission over the same protocol pipe/socket for things like video or transient graphics. This is aimed at improving interactivity and UX over challenging or fast changing network conditions.

 

We are sharing the protocol implementation (C/C++ code) between multiple Citrix Receiver and HDX host OS platforms. One exception is our HTML5 and Chrome Receiver.  As Santosh mentioned, we have looked into WebRTC and its Data Channel (SCTP protocol) in browsers today. But that implies different UDP framing protocol implementation for HTML5 Receiver, and different congestion and flow-control characteristics. So, ideally, we would like to use a direct UDP socket.

 

We also use DTLS encryption and are planning to add SOCKS5 for UDP support for access through our gateway.

 

This is a very important core feature for Receivers and HDX and any help is greatly appreciated.

 

Best regards,

Georgy

[Adam Rice]

Some thoughts about requirements:

* The most critical thing is that the browser gets a clear signal from the server that the server understands that this traffic comes from sandboxed code and that ambient authority from the IP or network configuration should not be applied to it. This is the function that the Sec-WebSocket-Key header provides for WebSockets. The browser must not send any untrusted data to the server before it has this signal, which implies some sort of session management.

* The origin of the traffic must be unforgeably communicated to the server so that it can apply access control.

* It must not be possible to forge any widely-used or security-critical UDP protocol (WebSocket lets you forge HTTP GET requests by design, but even that is less-than-ideal).

* It must not be possible for a malicious web page and server to co-operate to manipulate a middlebox into doing something dangerous. This is the function that frame masking performs in the WebSocket protocol. I think the threat model is a little different here: whereas with WebSocket the main concern was cache poisoning attacks, with UDP it is more likely to be NAT devices that forward ports when they think they recognise an online multiplayer game connection.

* Denial-of-service attacks need to be prevented somehow.

* Port scanning and local network enumeration need to be prevented somehow.

I think there are a few UDP-specific issues that need to be addressed also, in particular traffic amplification attacks and forged packet injection attacks. There are probably some non-obvious issues as well.

It appears that unreliable and out-of-order delivery are very much required features. Will this make encryption more difficult?

In order for this to happen, someone will have to draft an RFC and provide a client and server implementation for test purposes.

Hi Santosh,

 

--

To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-dev+unsubscribe@chromium.org.

To post to this group, send email to blink-ne...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/2a9a78b80f734aedb2c27bb109beb8a8%40SINPEX02CL02.citrite.net.

 

--

You received this message because you are subscribed to the Google Groups "blink-network-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-dev+unsubscribe@chromium.org.

To post to this group, send email to blink-ne...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/2443c42e90bc4ffdbb4e2ee5eefa355d%40FTLPEX02CL02.citrite.net.

[Santosh Sampath]

Thanks Adam for your thoughts on requirements and details.

 

>> Will this make encryption more difficult?

I think we would expect encryption at transport via DTLS (similar to TLS for Secure websockets).

 

>>In order for this to happen, someone will have to draft an RFC and provide a client and server implementation for test purposes.

We have not done this for Web before how is this handled typically? Do you need some samples for client and server from our side?

 

Thanks,
Santosh

Hi Santosh,

 

--

To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.

To post to this group, send email to blink-ne...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/2a9a78b80f734aedb2c27bb109beb8a8%40SINPEX02CL02.citrite.net.

--
You received this message because you are subscribed to the Google Groups "blink-network-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.

To post to this group, send email to blink-ne...@chromium.org.

[Adam Rice]

On 31 May 2017 at 14:03, Santosh Sampath <santosh...@citrix.com> wrote:

I think we would expect encryption at transport via DTLS (similar to TLS for Secure websockets).

I have been thinking along the same lines.

>>In order for this to happen, someone will have to draft an RFC and provide a client and server implementation for test purposes.

We have not done this for Web before how is this handled typically? Do you need some samples for client and server from our side?

The most important thing for browser vendors is to have a test server to test their implementation against. The test server should be strictly protocol-conformant by default, but extensible to achieve various bad behaviours so that browsers can verify their error-checking works correctly. Since most browsers seem to be converging on using the w3c web-platform-tests, it should be straightforward to integrate into the wptserve server those tests use. In practice this means it needs to be implemented as a python moduie.

Standard authorship is a deep subject, and I am far from an expert. I found this document which seems relevant: https://www.ietf.org/ietf-ftp/1id-guidelines.txt. Takeshi has authored at least one RFC and probably has more insights.

[Adam Rice]

I expanded on my earlier notes and made a public document exploring the requirements:

https://docs.google.com/document/d/12dmpPfE6gYDOa_ILDbENT5UddkoiZ441ounCxzNevu4/edit

This is not intended to be authoritative or official. It is just my thoughts on the matter.

One important addition is the requirement for congestion control. I didn't want to add this because it adds a lot of complexity, and I don't expect there to be benefit to most well-behaved applications. But I concluded that the risk of badly-behaved applications overloading Internet infrastructure is real. Simpler solutions like packet-rate limiting or fixed bandwidth throttling would be too restrictive.

[Santosh Sampath]

Hi Adam,

 

The document looks promising on high level.

 

Do keep us posted on how it goes through standards process and any info is required from our side for code samples etc.

 

One point mentioned in the doc was about SOCKS protocol. I assume it is V5?

Behavior could be similar to that of Websockets today (i.e. javascript layer is not aware of such proxy and is handled by browser)

 

Thanks,
Santosh

 

From: ri...@google.com [mailto:ri...@google.com] On Behalf Of Adam Rice
Sent: Wednesday, June 7, 2017 3:36 PM
To: Santosh Sampath <santosh...@citrix.com>
Cc: Georgy Momchilov <Georgy.M...@citrix.com>; Takeshi Yoshino <tyos...@chromium.org>; Chris Bentzel <cben...@chromium.org>; blink-ne...@chromium.org
Subject: Re: FW: Using UDP in web/HTML5

 

I expanded on my earlier notes and made a public document exploring the requirements:

[Adam Rice]

On 10 June 2017 at 02:55, Santosh Sampath <santosh...@citrix.com> wrote:

One point mentioned in the doc was about SOCKS protocol. I assume it is V5?

Behavior could be similar to that of Websockets today (i.e. javascript layer is not aware of such proxy and is handled by browser)

Yes. I have clarified in the document that I am talking about SOCKS5 and that it should be transparent to Javascript. If the proxy is SOCKS4 it will fail, but hopefully there aren't many SOCKS4 proxies left.

[Santosh Sampath]

Hi Adam,

 

I hope you are doing well.

 

Were you able to proceed further in this area? Do you think it has chance to make it to standards sometime next year?

 

Thanks,
Santosh

[Adam Rice]

Thanks Santosh,

We are still in evaluation stage. We are not pursuing this very aggressively at the moment because the use cases we have identified all seem to be relatively small niches, and we haven't come up with a compelling reason why it is urgent right now.

I still believe it is an important capability for the web and I am still working on it, just at low priority.

If someone finds a compelling use case or the idea gets a lot of buy-in, it is entirely possible it could be standardised next year. However, from the current level of interest I am seeing it doesn't look likely.

Thanks,

Adam

[Santosh Sampath]

Thanks Adam for providing realistic update.

 

We have been trying to experiment using WebRTC datachannels (which uses DTLS+SCTP) and preliminary results show that it is slightly slower than websocket in LAN environments with no packet loss

(one branch office to another, for e.g. Bangalore to UK/US/Singapore with around 250ms/160ms/60ms latency respectively. I can share exact stats when we have better data in controlled emulated environment).

 

We might see benefits more when there is 1% or 2% packet loss (I only guess based on results shown in http://pages.cs.wisc.edu/~raj/sctp/report.pdf)

 

We could set Data channel to be “unreliable” and make “re-transmit count = 0” to make it behave “similar” to UDP.

However to make a connection the other end need to understand, WebRTC stack, ICE, STUN/TURN, parse SCTP and finally we would have access to data on the other end.

This is probable as WebRTC is built to make browser-browser peer-peer connections easy. We still might not get all UDP characteristics because of overhead.

 

If there were UDP available in Web, someone could use that as foundation for using higher level protocols like UDT (https://en.wikipedia.org/wiki/UDP-based_Data_Transfer_Protocol) which handle reliability like forward error correction. The other end still would need to understand websockets but websocket headers are very light weight with little overhead.

 

I know use cases are not as much as for regular websockets but something like Chrome remote desktop could also benefit from this kind of capability.

[Chris Bentzel]

One thing I'm interested in - how much do you care about robustness?

There are some proposals to simply have raw UDP or something close to it. For example, from some conversations with people who do networking for competitive games, the focus is performance at all cost and for people to adjust their network (set up firewall pinholes for example) 

But some cases - possibly like the one you've mentioned - want performance where possible but some robustness for other network types. For example, falling back to TCP if UDP is blocked, being able to route through authenticating HTTP proxies, allow extensions to intercept, etc. This would recommend a very different solution than the other approach.

[bernar...@gmail.com]

There is now a client/server WebTransport API proposal that may be of interest to you:

https://discourse.wicg.io/t/webtransport-proposal/3508

Also, an Origin Trial for a P2P API:  https://developers.google.com/web/updates/2019/01/rtcquictransport-api

If this sounds interesting to you, it would be helpful if you would respond to the WICG Discourse announcement (which would help demonstrate the interest to move the proposal forward)

[Santosh Sampath]

Hi Bernard,

 

Thanks for notifying us about the spec. It is interesting and useful in supporting unreliable packets in web.

 

If I read it correctly, WebTransport API is a generic interface and QUIC transport is one of the options.

>>This specification uses pluggable protocols, with QUIC [QUIC-TRANSPORT] as one such protocol

 

Who can add other protocols – would it be browser vendors?

For e.g. how can we plug a protocol which is based on custom protocol over DTLS instead of QUIC which handles reliable as well as unreliable delivery.

 

Thanks,
Santosh

 

From: bernar...@gmail.com <bernar...@gmail.com>
Sent: 01 May 2019 23:44
To: blink-network-dev <blink-ne...@chromium.org>
Cc: Santosh Sampath <santosh...@citrix.com>; Georgy Momchilov <Georgy.M...@citrix.com>
Subject: Re: FW: Using UDP in web/HTML5

 

There is now a client/server WebTransport API proposal that may be of interest to you: