Subject: [dispatch] A Datagram Transport for the RTC-Web profile

From: Henry Sinnreich <[email-masked]>
Date: Thu, 16 Dec 2010 14:47:07 -0600

Hi Harald,
 
I would like to add my thanks to Alan Johnston¹s note, this time to your
other I-D, [I-D: draft-alvestrand-dispatch-rtcweb-datagram-00] since is a
timely and welcome contribution to what may well turn out to become the most
exciting development in VoIP: Opening such as SIP VoIP up from its separate
applications environment, Internet or telecom, into the mainstream world of
applications, into the browser.
 
Given the transformative potential we believe this has, maybe a contrarian
view to the solutions presented here is timely right now. The Internet
industry will produce solutions one way or another and the challenge in our
IETF work here is to develop a standard that is most attractive to
implementers. This is the focus in the message.
 
There is an obvious need to present, discuss and research various options
before developing any standard document. So here are some comments when
adopting a contrarian view. This is certainly not a complete list nor does
everything tie yet neatly together  the reason why we propose this work to
be an IRTF (http://www.irtf.org/) work item.
 
Last but not least, as per your model, we discuss here only media transport
between browsers or between a browser and a possible RTC server, such as a
conference server. All issues of control, such as rendezvous, session setup,
etc. are out of scope. These topics are addressed elsewhere.
 
Missing items
=============
 
In sections 1.Introduction and 2.Terminology, the key distinction must be
added between streaming audio/video (a/v) media and interactive real-time
(RT) media for communications and other, such as games, to which the title
RTC is pointing.
 
³When transporting audio / video data between participants on the current
Internet, there are a number of obstacles to be faced.²
Well, there is also really good news to be added: Content Distribution
Networks (CDN) support highest quality HDTV streaming to many millions of
users. CDN share something with the Internet: CDN are a general purpose
global platform that while keeping to basic HTTP protocol support enables an
endless stream of innovations that require no network upgrades for new Web
applications. CDN are also scalable Internet style. See below how CDN could
also serve as relays for RT media.
 
Another missing item seems to be any emphasis on the handling of media for
P2P RTC in the browser, arguably the ultimate communication solution for
many reasons, such as lowest cost of ownership, instant scalability for peak
traffic events. Would not P2P media run inside a VPN-like network over HIP,
as discussed below make a most attractive option?
 
Last but not least, actually the most important for tens of millions of Web
app developers is the complete integration with all and any web applications
and integration into web development tools, such as graphic Integrated
Development Environments (IDE).
How can the required protocol expertise on media, as required here be best
hidden from app developers, so they are not discouraged from using it?
 
Unnecessary Complexity: Are there better options? Which?
 
The Datagram Model that is presented in section 3.Service model. Being an
assembly of very complex constructs to be found in recent IETF documents,
arguably weighs down the Service model. This contradicts the golden design
rule that engineering is finished only when it can be made no simpler and no
more. 
We also miss here a discussion of design options and the criteria for
picking any particular choice. Discussing such options in detail are key to
choosing and defending an approach for RT Web communications.

Alternate options for RT Web media
==============================
 
Missing the option of using just UDP and application level scheduling
without any other protocols. My understanding is that Skype for example has
proven such an approach for interactive a/v. Skype does not use RTP. Neither
do Apple TV, Flash video and others for streaming media.
 
Another approach, also well proven for CDN is streaming HTTP. Bidirectional
HTTP and Streaming HTTP is the object of present IETF work and it would make
sense to benefit from it.
 
Sample scenarios for using HTTP for media transport in RTC:
 
·      Users are inside a single ISP, within a small geographical area and
the nearest CDN HTTP proxy serves as the media relay. A suitable a/v codec
packetization and sequencing from the end point browser based apps can
easily meet the required delay, such as less than 150 ms end-to-end. The CDN
HTTP proxy has to be instructed not to cache this stream and is used Œas
is¹.
 
·      Some users are geographically remote and in different ISPs. In this
case, the CDN owned fiber backbones might prove to be an alternative to the
congestion experienced from peering and backhaul. Here too the huge CDN
infrastructure is used Œas is¹.
 
Alternate Options for NAT traversal
===================================
 
Instead of using ICE as in RFC 5245 that is described specifically for SIP,
why not using ICE as specified 5750 for HIP since it has the following
benefits:
 
·      ICE for HIP works for all application layer protocols and has all the
benefit of a generic solution
·      HIP supports also IPv6 transition, mobility and multi-homing
·      HIP provides VPN-like security for both media and control, thus
meeting the criteria for simplicity in our contrarian approach.
 
Things to disagree with
=======================
 
The URI schema for datagram channels contradicts both the Internet and Web
architectural principles:
 
1.  Registration of URIs contradict the loose coupling and scalability of
the Web architecture (reference)
2.  The URI registration template uses IP addresses. This contradicts the
IAB UNSAF RFC 3424 and is also one of the main weaknesses of SDP in SIP,
since the IP addresses are not information, but rather disinformation; many
intermediaries along the path will change them unfortunately. By contrast,
HIP works end-to-end like the User Space VPN and is better positioned to
handle this. The are no intermediaries inside the VPN-like network
established over HIP.
3.  Why not enjoy also the flexibility not to use only DNS names for the
media description, but rather P2P names, such as in Skype? Caution, we may
open here a can of worms, but this is important as well. It must be IMO also
part of discussing the design options.
 
Missing sections: Discussion and Conclusions
============================================
 
The key item to discuss is if the approach in this draft meets the basic
engineering criteria: The design is the simplest possible and nothing
remains to be taken away to make it simpler and no more.
 
My conclusion is the I-D is a welcome start of work on RT interactive
communications on the web, but the approach presented, though formally
compliant with the most recent IETF application area standards work may not
be the most simple. Therefore it may not be the most successful in the
market.
 
Recommendations
===============
 
The discussions of other options, such as the examples recommended here
require detailed discussions, prototyping and testing before adopting
anything resembling a standard proposal. For this reason we suggest the RTC
Web work should continue within the Internet Research Task Force (IRTF) and
I have taken the liberty to copy the IRTF Chair Lars Eggert for this
purpose. Possible work items include:
 
·      What is the complexity, for example measured in the number of
messages and protocol support required in the present RTC Web I-D as is?
·      List and comparison of alternatives? (Such as using CDN, HIP and P2P)
·      Would a SIP API standard and RTC Web constitute a complete solution?
If not, what is missing?
·      Scenarios and business models. Who pays the CDN for RTC? Business
innovation is impossible to predict, but must be enabled by providing the
tools and flexibility inherent in the Darwinian Web to the genius of
application developers.
·      Prototypes and test reports.
 
It can be argued that sending this work to the IRTF will introduce a delay,
but as mentioned, the Internet industry will produce solutions one way or
another and the challenge in the IETF work here is to develop a standard
that is most attractive to app developers and to implementers.
See also ³What Makes for a Successful Protocol², RFC 5218.
 
Thanks, Henry

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Dec 2010 11:00:18 +0100

Henry,

thanks for your note!

Shortform reply:

- I think this is IETF ready at the present time.
- I would enjoy seeing a CDN-based alternative written up, but don't 
believe in it.
- I don't see a business case for adding HIP.
- I'll reform the URI section. It was done in a rush, and not well.

Details below.

On 12/16/10 21:47, Henry Sinnreich wrote:
> Hi Harald,
>
> I would like to add my thanks to Alan Johnston's note, this time to 
> your other I-D, [I-D: draft-alvestrand-dispatch-rtcweb-datagram-00] 
> since is a timely and welcome contribution to what may well turn out 
> to become the most exciting development in VoIP: Opening such as SIP 
> VoIP up from its separate applications environment, Internet or 
> telecom, into the mainstream world of applications, into the browser.
>
> Given the transformative potential we believe this has, maybe a 
> contrarian view to the solutions presented here is timely right now. 
> The Internet industry will produce solutions one way or another and 
> the challenge in our IETF work here is to develop a standard that is 
> most attractive to implementers. This is the focus in the message.
Contrarian is good... it allows us to make our basic thinking clear.
>
> There is an obvious need to present, discuss and research various 
> options before developing any standard document. So here are some 
> comments when adopting a contrarian view. This is certainly not a 
> complete list nor does everything tie yet neatly together -- the 
> reason why we propose this work to be an IRTF (http://www.irtf.org/) 
> work item.
Allow me to disagree.... my perception is that there is such a huge 
amount of existing practice (Skype, Google Talk Video, MSN Video, Adobe 
Connect, even ChatRoulette) that the field's experimentation phase is 
already well established, and may indeed be mostly behind us - the time 
is ripe (I think) to get some agreement on how to use the standard 
building blocks we have in an interoperable manner. This is not what the 
IRTF has been traditionally best at; it is rather a typical standards 
activity.
>
> Last but not least, as per your model, we discuss here only media 
> transport between browsers or between a browser and a possible RTC 
> server, such as a conference server. All issues of control, such as 
> rendezvous, session setup, etc. are out of scope. These topics are 
> addressed elsewhere.
>
> Missing items
> =============
>
> In sections 1.Introduction and 2.Terminology, the key distinction must 
> be added between streaming audio/video (a/v) media and interactive 
> real-time (RT) media for communications and other, such as games, to 
> which the title RTC is pointing.
Why?

At the datagram level, I don't see a distinction. Both A/V and non-A/V 
data have specific requirements for delivery probability, ordering and 
timeliness; the requirements are different, but both types of data have 
a need to have data packets delivered.

I've had some comments about the "RTC" moniker before, but am not really 
sure what current/previous usage of the term refers to - could you help?
>
> "When transporting audio / video data between participants on the 
> current Internet, there are a number of obstacles to be faced."
> Networks (CDN) support highest quality HDTV streaming to many millions 
> of users. CDN share something with the Internet: CDN are a general 
> purpose global platform that while keeping to basic HTTP protocol 
> support enables an endless stream of innovations that require no 
> network upgrades for new Web applications. CDN are also scalable 
> Internet style. See below how CDN could also serve as relays for RT media.
I wasn't aware that CDNs had any relationship to real-time 
communication; will look forward to studying the details on this. Google 
actively uses relays to get around firewalls, and of course there is a 
long (and sad) history of using multicast, either at the network layer 
or the application layer, to get distribution trees for media, but I 
hadn't been aware that the CDN name was being used for this type of 
functionality.
>
> Another missing item seems to be any emphasis on the handling of media 
> for P2P RTC in the browser, arguably the ultimate communication 
> solution for many reasons, such as lowest cost of ownership, instant 
> scalability for peak traffic events. Would not P2P media run inside a 
> VPN-like network over HIP, as discussed below make a most attractive 
> option?
Please elucidate - I may be getting some terminology wrong, but I simply 
don't get this. What do you mean by "handling of media for P2P RTC", 
what is "ultimate" about the communcation solution, and what is the 
scalability property you wish to explore?
>
> Last but not least, actually the most important for tens of millions 
> of Web app developers is the complete integration with all and any web 
> applications and integration into web development tools, such as 
> graphic Integrated Development Environments (IDE).
> How can the required protocol expertise on media, as required here be 
> best hidden from app developers, so they are not discouraged from 
> using it?
Consider me a dinosaur, but I still develop Java code in Emacs, and have 
friends who do Javascript in vi; I consider the hiding of properties of 
underlying systems a failure of our education system, which has led to 
fundamental architectural mistakes in the past (such as Tim Berners 
Lee's belief that setting up a connection across the Internet was a 
simple thing, and therefore reasonable to do at each request of his 
newly-concieved HTTP protocol).

I believe that if we get a clean and comprehensible model out at the 
protocol specs level, and a clean and comprehensible API out at the 
Javascript / DOM level, the IDEs will follow when they need to.
> The Datagram Model that is presented in section 3.Service model. Being 
> an assembly of very complex constructs to be found in recent IETF 
> documents, arguably weighs down the Service model. This contradicts 
> the golden design rule that engineering is finished only when it can 
> be made no simpler and no more.
> picking any particular choice. Discussing such options in detail are 
> key to choosing and defending an approach for RT Web communications.
Well... the model is dependent on IP, UDP and ICE. That's it.
Its definition references some rather hefty specs, including PseudoTCP 
(unspecified) and RTP, but does not depend on them.

Of those three, IP and UDP are necessary, and simple. ICE is complex, 
but is itself a result of multiple iterations of the "try to make things 
simpler, find that simpler solutions don't work for significant use 
cases, back off".
> without any other protocols. My understanding is that Skype for 
> example has proven such an approach for interactive a/v. Skype does 
> not use RTP. Neither do Apple TV, Flash video and others for streaming 
> media.
And neither do they interoperate with each other, or with anything else. 
(Flash video does interoperate with some other stuff, as proven by the 
flash-based version of Google Talk Video).

Application-over-UDP would require that we have one single spec that 
specifies all of the layers from the application down to UDP, including 
firewall / NAT traversal, codecs and so on. This seems like an approach 
that is anathema to the "building blocks" approach of IETF standardization.
>
> Another approach, also well proven for CDN is streaming HTTP. 
> Bidirectional HTTP and Streaming HTTP is the object of present IETF 
> work and it would make sense to benefit from it.
Streaming HTTP is TCP-based, and TCP has long been thought to be 
inappropriate for real-time interactive media; it is a commonly used 
fallback for the cases where UDP doesn't get through, but is problematic 
because of the high jitter that can result from packet loss due to 
sequential retransmission.

One of the design criteria for this work was direct browser-to-browser 
communication without intermediaries; the only technique I know of that 
works through firewalls and NATs is simultaneous-open TCP, which has a 
not-stellar success rate.
> ·      Users are inside a single ISP, within a small geographical area 
> and the nearest CDN HTTP proxy serves as the media relay. A suitable 
> a/v codec packetization and sequencing from the end point browser 
> based apps can easily meet the required delay, such as less than 150 
> ms end-to-end. The CDN HTTP proxy has to be instructed not to cache 
> this stream and is used 'as is'.
As noted above, this means that we drop the requirement for direct 
browser-to-browser communication even for the one-on-one case. I don't 
believe this would be acceptable to a majority of participants.
>
> ·      Some users are geographically remote and in different ISPs. In 
> this case, the CDN owned fiber backbones might prove to be an 
> alternative to the congestion experienced from peering and backhaul. 
> Here too the huge CDN infrastructure is used 'as is'.
Again, this means we're dropping direct traffic - or alternatively, that 
we're demanding two modes for the implementation, one direct and one 
using a CDN (or other relay).

Do we then require that all communicating users are connected to the 
same CDN, or are we requiring that for service to be universal, there 
has to be an universal open CDN peering policy? Both of those seem like 
reasonably challenging propositions.
> Alternate Options for NAT traversal
Actually this is not an option for NAT traversal, it's an option for a 
different network layer.
I've been fascinated by HIP ever since it was first proposed by Bob 
Moskwitz, especially since it seemed at the time to offer a cleaner 
ID/Locator split than either IPv4 or IPv6 - but it's never been a 
solution that was great for incremental deployment in scenarios where 
some degre of interworking with older equipment was required.

Currently, HIP seems to deploy on top of UDP, so it's actually an 
additional layer of protocol compared to the proposal in the draft.
>
> Instead of using ICE as in RFC 5245 that is described specifically for 
> SIP, why not using ICE as specified 5750 for HIP since it has the 
> following benefits:
The RFC number is wrong... it's 5770. It refers to RFC 5245 for its 
actual ICE specifics, and OpenHIP at least now runs by default over UDP, 
so the complexity of an ICE-over-HIP solution is not lower than an 
ICE-over-UDP solution.
>
> ·      ICE for HIP works for all application layer protocols and has 
> all the benefit of a generic solution
Only for those application layer protocols that have a defined mapping 
to HIP, of course - and it will fail to interwork with the same 
application layer protocols over non-HIP.
> meeting the criteria for simplicity in our contrarian approach.
At the cost of any sort of interoperability with non-HIP, of course.
>
> Things to disagree with
> =======================
>
> The URI schema for datagram channels contradicts both the Internet and 
> Web architectural principles:
>
> 1.  Registration of URIs contradict the loose coupling and scalability 
> of the Web architecture (reference)
Sorry, I don't understand this. Could you elucidate?
> 2.  The URI registration template uses IP addresses. This contradicts 
> the IAB UNSAF RFC 3424 and is also one of the main weaknesses of SDP 
> in SIP, since the IP addresses are not information, but rather 
> disinformation; many intermediaries along the path will change them 
> unfortunately. By contrast, HIP works end-to-end like the User Space 
> VPN and is better positioned to handle this. The are no intermediaries 
> inside the VPN-like network established over HIP.
Actually I was trying to represent exactly the same information as a set 
of ICE "a=candidate" SDP attribute (RFC 5245 section 15.1), without 
having read the spec for that attribute before writing what I wrote; 
I'll make sure to reference that spec properly and be compatible with it.

My opinion about the usage of IP addresses in SIP is too voluminous to 
fit within the confines of this note; the whole section may be a 
candidate for being dropped if it turns out that the API work to be 
performed in the W3C can use "a=candidate" sets rather than wanting to 
use URIs.
> 3.  Why not enjoy also the flexibility not to use only DNS names for 
> the media description, but rather P2P names, such as in Skype? 
> Caution, we may open here a can of worms, but this is important as 
> well. It must be IMO also part of discussing the design options.
Yes, it's a can of worms, since there is no referenceable document for 
"P2P names", nor a documented way to dereference "P2P names". I am very 
much disinclined to make this specification depend on undefined terms.
> The key item to discuss is if the approach in this draft meets the 
> basic engineering criteria: The design is the simplest possible and 
> nothing remains to be taken away to make it simpler and no more.
(slightly tongue-in-cheek) Other efforts have made the experience that 
there's more disagreement about the justification than about the 
specification; thus, by the same engineering criteria, leaving out the 
discussion may make the spec simpler....
> compliant with the most recent IETF application area standards work 
> may not be the most simple. Therefore it may not be the most 
> successful in the market.
>
> Recommendations
> ===============
>
> The discussions of other options, such as the examples recommended 
> here require detailed discussions, prototyping and testing before 
> adopting anything resembling a standard proposal. For this reason we 
> suggest the RTC Web work should continue within the Internet Research 
> Task Force (IRTF) and I have taken the liberty to copy the IRTF Chair 
> Lars Eggert for this purpose. Possible work items include:
>
Another approach is of course to ask the proponents of alternate 
approaches to describe them in such a way that the relative merits can 
be compared. In particular, I would enjoy seeing a specification of the 
CDN approach that was specified to a level that allows independent, 
interoperable implementation, since I'm not knowledgeable enough about 
the standardized interfaces to the CDNs to be able to produce such a 
document at this time.
> ·      Would a SIP API standard and RTC Web constitute a complete 
> solution? If not, what is missing?
It is interesting to ask "a complete solution to what". I've asked some 
other people to consider taking on the task of writing scenarios 
documents that can be used to drive requirements, but at the moment, no 
documents are on the table.

My personal short-form is "if I can implement Google Talk Video and 
ChatRoulette on top of these interfaces without a plugin in the browser, 
it's a solution to something; if I can't, it isn't".
> ·      Scenarios and business models. Who pays the CDN for RTC? 
> Business innovation is impossible to predict, but must be enabled by 
> providing the tools and flexibility inherent in the Darwinian Web to 
> the genius of application developers.

Indeed, that is a good question, and one reason why I don't want to 
build a protocol suite that can only be used in the presence of CDNs.

> It can be argued that sending this work to the IRTF will introduce a 
> delay, but as mentioned, the Internet industry will produce solutions 
> one way or another and the challenge in the IETF work here is to 
> develop a standard that is most attractive to app developers and to 
> implementers.
> See also "What Makes for a Successful Protocol", RFC 5218.
An important document to read, indeed.