Subject: Re: [clue] FW: New Version Notification fordraft-hansen-clue-protocol-choices-evaluation-00.txt

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 17 Nov 2011 18:29:47 -0800

About this one sentence:
"For these reasons we would recommend using UDP over TCP for an independent protocol"
I interpreted it to mean "... we would recommend using UDP rather than TCP ..."

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, November 17, 2011 10:24 PM
To: [email-masked]
Subject: Re: [clue] FW: New Version Notification fordraft-hansen-clue-protocol-choices-evaluation-00.txt

On 11/17/11 7:03 PM, Allyn Romanow (allyn) wrote:
> Looking forward to hearing comments-

Ask and ye shall receive:

Section 3:

"For these reasons we would recommend using UDP over TCP for an independent protocol"

I think you must mean TCP over UDP.

But, for something serial over UDP, we would be well advised to look at what RTCWEB is doing for its data channel. (TCP over UDP is one possibility, more or less, and SCTP over UDP is another.)

Moreoever, based on comments in joint ad hoc today, we may need to constrain ourselves to using *precisely* what RTCWEB uses so that its possible to have an RTCWEB-based endpoint in a CLUE sesssion.

Section 5:

   "for an independent protocol standard libraries can be used for the
    transport protocol, and it would even be possible to create a CLUE
    protocol library that could then be distributed, making adoption very
    straightforward."

The options being explored by rtcweb don't all have this property, at least not yet, though it is desired. And unfortunately there is no guarantee of that improving. (IIUC, Each browser implementation will provide an API for web apps. But its possible there won't be a common library used for the implementation in the browser.)

Section 7:

The issue of intermediaries inadvertently breaking things should not be such a big problem if an appropriate manner of conveying the data in sip is chosen. E.g. if an INFO package is used it should not be a problem.

OTOH, intermediaries may well advertently break the usage. But if so its most likely at the specific direction of whoever configured the intermediary. In that case the solution is "if it hurts, don't do it". 
The intermediary can break any technique if it feels it should.

An important issue is not mentioned: sending potentially large messages through the sip signaling path can load down all the servers on the path.

	Thanks,
	Paul
_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Nov 2011 10:35:48 +0800

> I interpreted it to mean "... we would recommend using UDP rather than TCP ..."

If that is the intent, then it puts it into a different light!

	Thanks,
	Paul

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 17 Nov 2011 19:54:31 -0800

Yes, thanks Mark, that's the intent.. prefer UDP rather than TCP.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Paul Kyzivat
> Sent: Thursday, November 17, 2011 6:36 PM
> To: [email-masked]
> Subject: Re: [clue] FW: New Version Notificationfordraft-hansen-clue-
> protocol-choices-evaluation-00.txt
> 
> > But, for something serial over UDP, we would be well advised to look
> at what RTCWEB is doing for its data channel. (TCP over UDP is one
> possibility, more or less, and SCTP over UDP is another.)
> >
> > Moreoever, based on comments in joint ad hoc today, we may need to
> constrain ourselves to using *precisely* what RTCWEB uses so that its
> possible to have an RTCWEB-based endpoint in a CLUE sesssion.
> >
> > Section 5:
> >
> >      protocol library that could then be distributed, making
adoption
> very
> >      straightforward."
> >
> > The options being explored by rtcweb don't all have this property,
at
> least not yet, though it is desired. And unfortunately there is no
> guarantee of that improving. (IIUC, Each browser implementation will
> provide an API for web apps. But its possible there won't be a common
> library used for the implementation in the browser.)
> >
> > Section 7:
> >
> > The issue of intermediaries inadvertently breaking things should not
> be such a big problem if an appropriate manner of conveying the data
in
> sip is chosen. E.g. if an INFO package is used it should not be a
> problem.
> >
> > OTOH, intermediaries may well advertently break the usage. But if so
> its most likely at the specific direction of whoever configured the
> intermediary. In that case the solution is "if it hurts, don't do it".
> > An important issue is not mentioned: sending potentially large
> messages through the sip signaling path can load down all the servers
> on the path.
> >
> > 	Thanks,
> > 	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 19 Nov 2011 00:30:06 +0000

> Moreoever, based on comments in joint ad hoc today, we may need to constrain ourselves to using *precisely* what RTCWEB uses so that its possible to have an RTCWEB-based endpoint in a CLUE sesssion.

It would definitely be *better* to do the same thing RTCWEB does for the data channel, but I don't know if it would be *required* by the RAI Area/A-Ds to do so.

As an FYI, if I had to guess, I'd guess RTCWEB will end up doing SCTP over DTLS over UDP.  DTLS will probably be mandatory to use for every communication, not optional.

> The options being explored by rtcweb don't all have this property, at least not yet, though it is desired. And unfortunately there is no guarantee of that improving. (IIUC, Each browser implementat…

I'm not sure I understand the above statement.  Let's imagine CLUE goes with TCP over UDP.  TCP over UDP is not built into operating systems today, so you have to add it somehow.  No matter what you do in CLUE, different CLUE implementors will have the choice of using common open-source TCP/UDP stacks, or writing one of their own.  That's exactly what will also happen in RTCWEB, whether they choose SCTP/DTLS/UDP or not.  There will be an open-source stack available, but no one can force you to use it.

> An important issue is not mentioned: sending potentially large messages through the sip signaling path can load down all the servers on the path.

Or fail completely.  :(

-hadriel