Subject: [nwcrg] draft-montpetit-transport-use-cases-00

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 29 Nov 2013 11:57:27 -0500

As promised, the 1st draft of the use cases - copying the NC people since I mention them.

In pdf - I edited it in the Joe Touch Word format - will get into plain text later.

/mjm
Marie-Jose Montpetit
[email-masked]
[email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Fri, 29 Nov 2013 22:27:04 +0100

Hi,

I have only joined NWCRG just now; apologies!

While I appreciate that you cc'ed them in your message to keep them in the loop, I think it's inappropriate for us to now go through details in the document in their list too. So I'll use this chance to remind everyone that the discussion of this document should take place at  [email-masked] , mailing list info page https://sympa.uio.no/ifi.uio.no/info/transport-services , which was established to work towards a BOF on Transport Services. The general information page on this planned BOF is at:
https://sites.google.com/site/transportprotocolservices/

I will also say that I agree with the use case on network coding in this document; indeed we seem to have some common ground here, because of this part of the NWCRG charter:

"Application layer. Interactions between Network Coding and application-specific coding (such as video layers encoding); Joint source and network coding; combining network coding with content/information-centric networking."

Our intention is to stop applications from specifying "TCP" or "UDP" but give them a service instead, and let a system underneath make the best possible choice from what it has available with a possible fall-back to TCP and UDP in case nothing else works (but automatized, hidden from the application). This should give more immediate benefits to applications and ease the deployment of new transports - so it could be useful for what NWCRG will come up with.

Cheers,
Michael

On 29. nov. 2013, at 17:57, Marie-Jose Montpetit <[email-masked]> wrote:

> <trans-serv-use-cases-00.pdf>
> 
> 
> /mjm
> Marie-Jose Montpetit
> [email-masked]
> [email-masked]
> 
>

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 30 Nov 2013 12:59:44 +0000

useful doc - one typo (HPPT:)

can I commend everyone's attention to a forthcoming conext paper from the
folks at at&t research which shows empirically that SPDY is by no means a
panacea, and indeed, in many mobile (common) scenarious, could be
detrimental to peformance -see
http://conferencs.sigcomm.org/co-next/2013/program/p303.pdf

fixing the http/tcp mess for all situations was never going to be
straightforward, alas

cheers
j.

On Fri, Nov 29, 2013 at 4:57 PM, Marie-Jose Montpetit <[email-masked]
> wrote:

> ---
> Transport Services BOF plan - website: href="

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 30 Nov 2013 13:33:33 +0000

>>corrected URL:
 >>> http://conferences.sigcomm.org/co-next/2013/program/p303.pdf

[weird - i cut and paste the url from my browser - packet loss of 1 byte maybe?  :)

 >>and I see it as more evidence that it's useful to abstract the
 >>apps-oriented functions away from the path-oriented transport functions.

absolutely agree...

 >>The paper is interesting, but I have some doubts about the analysis after
 >>working with SPDY over tunnels and satellite links, I've come to doubt
 >>that present  "SPDY opens only one TCP connection" ... The use of extra
 >>connections may now happen, likely to be adaptive to avoid HOL blocking.

they have full packet traces (I talked to KK about the work in a lot of detail:)
 >>It also reports that a spurious RTO causes ssthresh to become reduced, so

yup
 >>I guess this means they don't consider F-RTO or Eifel.
 
 >>The problem of preserving low RTT caches is hard for the IETF to work on,
 >>since the IETF specs never allowed an RTO below 1 sec, to avoid this. It
 >>is probably something TCPM should address as likely the same issues will
 >>become more sever with TFO!!!
 
yep
 >>best wishes,
 >>Gorry
 >>>> As promised, the 1st draft of the use cases - copying the NC people
 >>>> since
 >>>> I mention them.
 >>>>

 cheers

   jon

---

From: Michael Welzl <[email-masked]>
Date: Sat, 30 Nov 2013 14:38:58 +0100

> apps-oriented functions away from the path-oriented transport functions.

Agreed; and thanks for the pointer, this looks very interesting!
I've been involved in such a SPDY study too, currently under submission, but available as a tech rep:

Yehia Elkhatib, Gareth Tyson, Michael Welzl: "The Effect of Network and Infrastructural Variables on SPDY's Performance", Lancaster University technical report SCC-2013-01, July 2013.
http://www.comp.lancs.ac.uk/~elkhatib/Docs/2013.07_spdy-tr.pdf

We also didn't find that it generally performs particularly well (ironically enough, it did improve things when IW10 from too many connections became a problem  :-)   ). I guess that's why they started their work on QUIC.

Marie-Jose's use case doc contains a use case that I wrote about faster web surfing, even with HTTP, using multi-streaming at the transport layer (where it belongs). It's rather obvious that these improvements could have been made a long time ago... I never understood what the real reasons were that prevented web-over-SCTP from taking off? I remember seeing good things from the University of Delaware about that, but still it didn't get used...

Maybe it was the interface  :-)    well that's what we're setting out to solve. A VERY old problem, really, and high time to fix it now.

Cheers,
Michael

---

From: [email-masked]
Date: Sat, 30 Nov 2013 13:46:39 -0000

Just to be clear - I don't doubt their experiments, but apps-orieneted
protocols can evolve very quickly and be hard to characterise as they
evolve strategies to combat perceived transport issues.

At least that brings me back to the main topic - it would be really good
if we evolve away from the socket interface to have a more
service-oriented interface to the transport, sockets are too low in the
stack. HTTP needs to tell transport what it wants to do.

Gorry

>  >>>> In pdf - I edited it in the Joe Touch Word format - will get into
> plain
>  >>>> text later.
>  >>>>
>  >>>>
>  >>>>
>  >>>> /mjm
>  >>>> Marie-Jose Montpetit
>  >>>> [email-masked]
>  >>>> [email-masked]
>  >>>>
>  >>>>
>  >>>>
>  >>>> ---

---

From: Michael Welzl <[email-masked]>
Date: Sat, 30 Nov 2013 14:49:30 +0100

> stack. HTTP needs to tell transport what it wants to do.

Agreed; looking at existing APIs (Per's draft) is a starting point for that.

Cheers,
Michael

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 30 Nov 2013 08:49:50 -0500

I agree and I think this is how I see it. I would even say that HTTP is borderline as far as the level where the requirements emerge from - I would add that applications that run over HTTP should also be able tell what they want to have. 

/mjm
Marie-Jose Montpetit
[email-masked]
[email-masked]

---

From: <[email-masked]>
Date: Sat, 30 Nov 2013 13:49:50 +0000

> HTTP needs to tell transport what it wants to do.

fully agree, and that's why I wrote
http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]]
Sent: 30 November 2013 13:46
To: Jon Crowcroft
Cc: [email-masked]; Marie-Jose Montpetit; [email-masked]; Michael Welzl; Igor Zhovnirovsky; [email-masked]; [email-masked]
Subject: Re: [transport-services] draft-montpetit-transport-use-cases-00

Gorry