Subject: Re: [rtcweb] Sending of zero-length messages over data channels

From: Harald Alvestrand <[email-masked]>
Date: Sun, 03 Aug 2014 11:20:01 +0200

On 07/24/2014 10:25 PM, Makaraju, Maridi Raju (Raju) wrote:
>
> */In conclusion, I think websocket API supports zero length because 
> websocket protocol supports zero-length data frames. So, it does not 
> have the issue of 'bufferedAmount' discrepancy. /*
>
> *//*
>
> Yes, that is what I meant.
>
> */<Raju>/*
>
> */Ok, good. Websocket is not sending any dummy bytes, so 
> /**/bufferedAmount is always accurate./*
>
> */I am still not convinced that to keep data channel API consistent 
> with websocket API we need to introduce of dummy byte!?/*
>
> */How about keeping consistency of what goes on wire vs. what user 
> sent? websocket preserves that, where as data channel won't. /*
>

The WebSocket protocol is not on-the-wire compatible with the 
DataChannel protocol.
This has not been a design goal, and I don't see any reason to make it one.

> *//*
>
> */IMHO opinion, sending such a dummy byte may have other consequences:/*
>
> */1./**/App is not aware of what's going on? send() probably meant to 
> be called with non-empty data, but some error leg could have caused it 
> become empty, but still a byte will be sent out!!/*
>
> */2./**/Debugging becomes bit more complex and not intuitive. WebRTC 
> is already complex, why add more complexity?/*
>
> */3./**/Interop issues. The more the exceptions the more the interop 
> issues you see as some implementations may overlook these or implement 
> them later./*
>
> *//*
>
> */It's usually a bad idea to send a dummy byte on wire, without the 
> application direct involvement./*
>

I recommend spending some time with Wireshark looking at actual traces 
before making any such statement. Many protocols have dummy bytes, for 
many different reasons.

> *//*
>
> */IMHO, if doing PPID_OOB is more effort and can't fit in webrtc 1.0 
> then it would be better to delay and do it in more proper way than 
> taking a shortcut with PPID_EMPTY. With PPID_OOB approach underlying 
> signaling protocol can negotiate OOB before using it; though such 
> negotiation is not mandatory, but this approach allows such possibility./*
>

/*PPID_OOB would make the compatibility problem worse, not better.*/
>
> *//*
>
> *//*
>
> */I then, rest my case! /**/J/**//*
>
> *//*
>
> */</Raju>/*
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 4 Aug 2014 18:08:55 +0000

>IMHO opinion, sending such a dummy byte may have other consequences:

1.      >App is not aware of what's going on? send() probably meant to be called >with non-empty data, but some error leg could have caused it become >empty, but still a byte will be sent out!!

2.      >Debugging becomes bit more complex and not intuitive. WebRTC is >already complex, why add more complexity?

3.      >Interop issues. The more the exceptions the more the interop issues you >see as some implementations may overlook these or implement them >later.

>It's usually a bad idea to send a dummy byte on wire, without the application >direct involvement.

>I recommend spending some time with Wireshark looking at actual traces >before making any such statement. Many protocols have dummy bytes, for >many different reasons.

<Raju2>
I am afraid there is some confusion about my comment and as a result we may be talking about dummy bytes at 2 different levels: app level and underlying protocol level.
I am aware of many protocols using reserved bits, bytes, padded bits/bytes, protocol-level heartbeats/PING-PONGs (SCTP heartbeats use of opaque data). In all these cases the mechanism is built into the protocol below app-level protocol itself with no direct involvement of application-level protocol. My comment was in the context of application-level protocol.
If app calls send() 3 times with data "abc", "" (empty/null data with size 0) and then "xyz" then on the wire in the application-level payload you see "abc" <dummy byte> "xyz".
So, can you please point to me a protocol where this kind of dummy byte(s) are inserted in between application payload?

Btw, If you leave the app choice to send the byte (using OOB_PPID) then there is a possibility for the app to send 256 distinct values instead of browser hard-coding the byte to zero always, which just conveys a single value.

</Raju2>

>PPID_OOB would make the compatibility problem worse, not better.
<Raju2>
I would appreciate if you can provide reasons on why PPID_OOB making compatibility worse?
With PPID_OOB, apps have a choice to negotiate (this negotiation is like any other negotiation for webrtc.) and use this option. PPID_EMPTY option seems to be enabled always and no way to turn-off.
Without an option to turn off PPID_EMPTY, you will get into more compatibility issues as some webrtc implementations may not implement it on day one; a native client could be using an interim version of a popular webrtc lib; or it might be using its own webrtc lib, in which case we can't expect it to implement all these later-adders in a timely manner.

</Raju2>

BR
Raju

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Aug 2014 22:44:56 +0200

Not responding to rest of message.

On 08/04/2014 08:08 PM, Makaraju, Maridi Raju (Raju) wrote:
>
> */>PPID_OOB would make the compatibility problem worse, not better./*
> */<Raju2>/*
>
> */I would appreciate if you can provide reasons on why PPID_OOB making 
> compatibility worse?/*
>

Because WebSockets doesn't have any functionality corresponding to PPID_OOB.

Adding more functions that WebSockets doesn't have makes compatibility 
with WebSockets worse.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Aug 2014 13:49:16 -0700

On 4 August 2014 13:44, Harald Alvestrand <[email-masked]> wrote:
> Adding more functions that WebSockets doesn't have makes compatibility with
> WebSockets worse.

Not that this is a good example, but I really wish this wasn't the
yardstick we keep on trotting out.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 4 Aug 2014 21:08:06 +0000

>Because WebSockets doesn't have any functionality corresponding to >PPID_OOB.

>Adding more functions that WebSockets doesn't have makes compatibility >with WebSockets worse.
<Raju>
Per the discussions I thought only backward compatibility with Websocket API is what's desired with data channel API. Does it also mean data channel API can't add new APIs while maintaining compatibility to existing ones? I don't see a reason why new APIs can't be added and be restricted by websocket API though! Such restriction will limit the data channel API and won't allow leveraging on the flexibility provided by data channel's SCTP transport only.

</Raju>

BR
Raju

---

From: Justin Uberti <[email-masked]>
Date: Mon, 4 Aug 2014 17:18:51 -0700

On Mon, Aug 4, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>
>
>
>
> *>IMHO opinion, sending such a dummy byte may have other consequences:*
>
> 1.      *>App is not aware of what’s going on? send() probably meant to
> be called >with non-empty data, but some error leg could have caused it
> become >empty, but still a byte will be sent out!!*
>
> 2.      *>Debugging becomes bit more complex and not intuitive. WebRTC is
> >already complex, why add more complexity?*
>
> 3.      *>Interop issues. The more the exceptions the more the interop
> issues you >see as some implementations may overlook these or implement
> them >later.*
>
>
>
> *>It’s usually a bad idea to send a dummy byte on wire, without the
> application >direct involvement.*
>
>
>  *<Raju2> *
> *I am afraid there is some confusion about my comment and as a result we
> may be talking about dummy bytes at 2 different levels: app level and
> underlying protocol level.*
>
> *I am aware of many protocols using reserved bits, bytes, padded
> bits/bytes, protocol-level heartbeats/PING-PONGs (SCTP heartbeats use of
> opaque data). In all these cases the mechanism is built into the protocol
> below app-level protocol itself with no direct involvement of
> application-level protocol. My comment was in the context of
> application-level protocol. *
>
> *If app calls send() 3 times with data “abc”, “” (empty/null data with
> size 0) and then “xyz” then on the wire in the application-level payload
> you see “abc” <dummy byte> “xyz”.*
>
> *So, can you please point to me a protocol where this kind of dummy
> byte(s) are inserted in between application payload?*
>
>
>
> *Btw, If you leave the app choice to send the byte (using OOB_PPID) then
> there is a possibility for the app to send 256 distinct values instead of
> browser hard-coding the byte to zero always, which just conveys a single
> value.*
>
>
>
> *</Raju2>*
>
>
>

What value would this provide to justify the increased complexity?

>
> *>PPID_OOB would make the compatibility problem worse, not better.*
> *<Raju2>*
>
> *I would appreciate if you can provide reasons on why PPID_OOB making
> compatibility worse?*
>
> *With PPID_OOB, apps have a choice to negotiate (this negotiation is like
> any other negotiation for webrtc.) and use this option. PPID_EMPTY option
> seems to be enabled always and no way to turn-off. *
>
> *Without an option to turn off PPID_EMPTY, you will get into more
> compatibility issues as some webrtc implementations may not implement it on
> day one; a native client could be using an interim version of a popular
> webrtc lib; or it might be using its own webrtc lib, in which case we can’t
> expect it to implement all these later-adders in a timely manner.*
>
>
> I doubt this will be a real-world problem, given that the protocol is
still evolving and all implementations need to keep up, but if this turns
out to be an issue we can negotiate it in SDP.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 5 Aug 2014 13:57:51 +0000

Comments inserted between <Raju3> and </Raju3>

What value would this provide to justify the increased complexity?
<Raju3>
It provides a generic mechanism for an app to send OOB data within the same data channel. The new API can be used for the heartbeat purpose or for some other more innovative use cases like sending control data (e.g. sending a user’s emption so that other end can display it appropriately). It achieves all of this in a more transparent way than browser inserting a dummy byte.
Like anything else, I look forward to members’ feedback on this to see if such a need exists and the added API and procedures is worth considering.

</Raju3>

<Raju2>
I would appreciate if you can provide reasons on why PPID_OOB making compatibility worse?
With PPID_OOB, apps have a choice to negotiate (this negotiation is like any other negotiation for webrtc.) and use this option. PPID_EMPTY option seems to be enabled always and no way to turn-off.
Without an option to turn off PPID_EMPTY, you will get into more compatibility issues as some webrtc implementations may not implement it on day one; a native client could be using an interim version of a popular webrtc lib; or it might be using its own webrtc lib, in which case we can’t expect it to implement all these later-adders in a timely manner.
</Raju2>
I doubt this will be a real-world problem, given that the protocol is still evolving and all implementations need to keep up, but if this turns out to be an issue we can negotiate it in SDP.
<Raju3>
I agree that the implementations need to keep up, but in reality that may not be true. I remember the discussion of changing DTLS-SRTP transport “RTP/SAVPF” to “UDP/TLS/RTP/SAVPF”. It took some time to co-ordinate the changes even between Firefox and Chrome. Now if we think about other webrtc implementations (Internet Explorer?) in the mix then the interop gets complex very quickly.
IMHO, dealing with it when it happens is obviously a reactive way and having a capability to negotiate this (either PPID_EMPTY or PPID_OOB) is proactive way.
Again, I look forward to members’ feedback on this.

</Raju3>

BR
Raju