Subject: [apps-discuss] Comments on draft-tschofenig-hourglass-00

From: SM <[email-masked]>
Date: Mon, 09 Jul 2012 17:09:01 -0700

Hi Hannes,

[Cc to apps-discuss as it seems like an Area subject]

I read draft-tschofenig-hourglass-00.  I found it interesting.  In Section 7:

   "The author is, however, struggling with the question whether there is
    enough evidence to conclude that every protocol design today shall
    build on HTTP/HTTPS (rather than voluntarily using to use HTTP/HTTPS
    because of its properties)."

I wondered how many IETF specifications are voluntarily being built 
over HTTP/HTTPS.  During the HYBI discussions there was the usual 
debate about whether to leapfrog over HTTP.  MILE used HTTPS on a 
different port (needs a fact check).  WEIRDS seems to be following 
the HTTP path, do does REPUTE.  XMPP has a HTTP angle (Peter, please 
correct me).  RTCWEB followed the HTTP angle.

HTTP seems like the "de facto" standard.  That would be similar to 
IP.  You used the word "voluntarily".  Isn't it like low-hanging 
fruit?  The port is open.  There is a wide choice of freely available 
code.  There is experience in getting around middleboxes 
constraints.  The user already has the basic software.

Regards,
-sm

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Jul 2012 10:10:32 +0300

Hi SM, 

thanks for looking at the document. 

By voluntary I mean that protocol designers have a choice and I understand that they want to use HTTP because it offers features they want and of course they are familiar with. If you pick HTTP then nobody will ask questions. If you develop your own protocol then it will raise eyebrows. You see the same happening with the shift from ASN.1 to XML and now to JSON as well. 

It is good that people re-use protocols. I use HTTP/HTTPS in protocol designs as well. 

If people just use HTTP because of its features that's one story but if they use it to get through firewalls then that's a different aspect. This story is a bit more complicated. 

There are obviously different networks that vary in their packet filtering behavior. For enterprise networks where your end device is under the control of the administrator neither HTTP nor HTTPS will get you through firewalls, if the administrator does not like it. For the public Internet we are lacking data as to the degree of filtering. There are some papers available, and I cite them in the draft, but that isn't really a lot to conclude that you need HTTP or even HTTPS to avoid filtering of your data by intermediaries.

Ciao
Hannes

PS: In your list below you mention RTCWEB and it is quite different than the rest of the protocols since it not only relies on HTTP but it heavily focuses on JavaScript to provide the necessary functionality. 

On Jul 10, 2012, at 3:09 AM, SM wrote:

> I wondered how many IETF specifications are voluntarily being built over HTTP/HTTPS.  During the HYBI discussions there was the usual debate about whether to leapfrog over HTTP.  MILE used HTTPS on a different port (needs a fact check).  WEIRDS seems to be following the HTTP path, do does REPUTE.  XMPP has a HTTP angle (Peter, please correct me).  RTCWEB followed the HTTP angle.
> 
> HTTP seems like the "de facto" standard.  That would be similar to IP.  You used the word "voluntarily".  Isn't it like low-hanging fruit?  The port is open.  There is a wide choice of freely available code.  There is experience in getting around middleboxes constraints.  The user already has the basic software.
> 
> Regards,
> -sm
>

---

From: SM <[email-masked]>
Date: Tue, 10 Jul 2012 02:13:58 -0700

Hi Hannes,
At 00:10 10-07-2012, Hannes Tschofenig wrote:
>PS: In your list below you mention RTCWEB and it is quite different 
>than the rest of the protocols since it not only relies on HTTP but 
>it heavily focuses on JavaScript to provide the necessary functionality.

I'll comment quickly on this.  I glossed over the details as I wrote 
that list.  It's not a good comparison of protocols.  The Rich Web 
client [1] could be used as an argument for RTCWEB.  I am not 
referring to the working group.

ICSI Netalyzr has been used by the IETF community to test for the 
usual caveats [2].  One US dollar per user [3] is a significant 
incentive to influence what the public Internet [4] should be like.

Regards,
-sm

1. http://www.w3.org/2006/rwc/Activity.html
2. http://netalyzr.icsi.berkeley.edu/restore/id=example-session
3. http://www.icir.org/christian/publications/2011-foci-dns.pdf
4. It's a complex story.  Ecosystem might be a better fit.

---

From: Michiel de Jong <[email-masked]>
Date: Tue, 10 Jul 2012 15:50:05 +0300

Hi,

very interesting article; i don't have much experience as a protocol
designer yet, but i do study this topic a lot. I feel it's more a case
of applications moving into the browser (or the 'web runtime' as it's
sometimes called when used for running client-side app) than
necessarily specifically moving onto http:

- Since two years with CORS it's possible to do cross-origin http
calls from inside the web runtime.
- Since one year we have websockets.
- This year we'll have webrtc.

That makes the "waist" for the web as an app platform wider than just
http(s) itself. What this means for designing protocols for in-browser
apps is, i think:

- http(s) by itself is fine for delayed delivery of content that
rarely changes (web pages). Having a server in between the sending
client and the receiving client actually adds value here, both for
decoupling the clients in time, and to make one-to-many delivery
cheaper on the sending client (with the server basically taking the
hit of repeated retrieval of a document).

- http(s)+cors is useful for generic remote storage of in-app user
data (we based the remoteStorage protocol on this). Unlike http(s) by
itself, which only allows the client-side application 1 specific
server to connect to, with cors, the application can connect to
whichever server the user chooses at runtime (not just a server chosen
by the application provider).

- when latency is important, sending data from a sending client, up to
a server, and then down to a receiving client, http(s)+cors is good
for the upload, but not for the download. Http was not designed for
server-initiated transfer. Long-polling has been used to work around
this, but websockets are the proper way to do this. since it has only
been a year since websockets are available in browsers, i think a lot
of application-level protocol will start using websockets instead of
http now.

- when bandwidth is high (e.g. video streaming), it's advantageous to
use PeerConnection, as included by the WebRTC stack, and establish
(after handshake, ice, stun and turn if i understood it correctly) a
route directly between the two clients, this saving server costs.

That is why i think the 'hourglass waist' we are moving towards may prove to be:

http(s)+cors, websockets, PeerConnection

Of course, this is only talking about client-to-client communication.
In server-to-server communication, http(s) is popular for the other
reasons that were mentioned.

I think the main problem we need to solve now in this space, is so to
speak the "Where is Bob?" problem. If Alice wants to contact Bob, then
where should she connect to? She needs to either consult a central
directory server, or Bob needs to run his own server at his own DNS
domain name which he dials into. I am not sure whether it will be
enough to wait for mobile IPv6 (co-located care-of addresses) to be
widely supported, or whether this is a problem that still needs extra
attention.

I definitely agree that the security model of the browser will also
need more research, specifically how users experience the gestures of
'visiting', 'bookmarking' and 'installing' a web app.

Having said all that, i think the move of applications into browser
apps is definitely happening, especially in the last 18 months, and i
think it's a big win. IMHO, javascript and the web runtime as an
'hourglass waist' constitute the 'cross-platform application platform'
that we hoped java would be.

My 2ct,
Michiel