Re: [nwcrg] [transport-services] draft-montpetit-transport-use-cases-00

[<[e-mail]>]

 > 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: [e-mail] [[e-mail]]
Sent: 30 November 2013 13:46
To: Jon Crowcroft
Cc: [e-mail]; Marie-Jose Montpetit; [e-mail]; Michael Welzl; Igor Zhovnirovsky; [e-mail]; [e-mail]
Subject: Re: [transport-services] draft-montpetit-transport-use-cases-00

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 missive <[e-mail]>,
> [e-mail]
> .ac.uk typed:
>
>  >>> http://conferencs.sigcomm.org/co-next/2013/program/p303.pdf
>
>  >>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...
>
>  >>> fixing the http/tcp mess for all situations was never going to be
>  >>> straightforward, alas
>
>  >>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
>  >>
>  >>> cheers
>  >>> j.
>  >>>
>  >>>
>  >>> On Fri, Nov 29, 2013 at 4:57 PM, Marie-Jose Montpetit
>  >>> <[e-mail]
>  >>>> wrote:
>  >>>
>  >>>> 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
>  >>>> [e-mail]
>  >>>> [e-mail]
>  >>>>
>  >>>>
>  >>>>
>  >>>> ---
>  >>>> Transport Services BOF plan - website: href="
>  >>>> https://sites.google.com/site/transportprotocolservices/
>  >>>>
>  >>>
>  >>
>  >>
>
>  cheers
>
>    jon
>