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

From: Arjuna Sathiaseelan <[email-masked]>
Date: Sun, 1 Dec 2013 07:19:04 +0000

I am presuming this would enable HTTP to use LEDBAT/ish? POST over low
capacity uploads for e.g

Arjuna

> stack. HTTP needs to tell transport what it wants to do.
>
> Gorry
>
>> In missive <[email-masked]>,
>> [email-masked]
>> .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
>>  >>> <[email-masked]
>>  >>>> 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
>>  >>>> [email-masked]
>>  >>>> [email-masked]
>>  >>>>
>>  >>>>
>>  >>>>
>>  >>>> ---
>>  >>>> Transport Services BOF plan - website: href="
>>  >>>> https://sites.google.com/site/transportprotocolservices/
>>  >>>>
>>  >>>
>>  >>
>>  >>
>>
>>  cheers
>>
>>    jon
>>
>
>
>
>
> ---
> Transport Services BOF plan - website: href="https://sites.google.com/site/transportprotocolservices/

-- 
Arjuna Sathiaseelan | http://www.cl.cam.ac.uk/~as2330/

---

From: Michael Welzl <[email-masked]>
Date: Mon, 2 Dec 2013 00:27:23 +0100

For uploads, why would you need LLoyd's scheme? If you're the sender, it's local - you do whatever you wish, just as with pluggable congestion control (I guess the browser would have to make this decision, then, based on a configuration from... somewhere).

Cheers,
Michael

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 01:56:24 +0000

Why do you assume an http transfer involves a browser?

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

________________________________________
From: Michael Welzl [[email-masked]]
Sent: 01 December 2013 23:27
To: Arjuna Sathiaseelan
Cc: Gorry Fairhurst; Jon Crowcroft; Marie-Jose Montpetit; <[email-masked]>; Igor Zhovnirovsky; [email-masked]
Subject: Re: [transport-services] draft-montpetit-transport-use-cases-00

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Mon, 2 Dec 2013 08:20:08 +0100

Okay, often does, sometimes won't - but what's your point?

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 09:44:02 +0000

My point in
http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports

is that, although we can already specify port and application protocol (http/ftp/h323 etc) behaviour, we cannot specify transport protocol or interface to use the same way - yet it would be useful to do so, and to have the high-level preferences passed down the stack.

The 'Happy eyeballs'approach  is 'let's try everything until something works - whatever, we don't know what' while this is 'specify the exact behaviour wanted'. Happy eyeballs is intended as a naive-user-centric approach, rather than an explicit configuration useful for debugging or for setting up machine-to-machine interactions.  Among other things, the draft above  can, if implemented, deliberately override non-deterministic happy eyeballs-type behaviour and defend against unpredictable outcomes by specifying exact behaviour needed.

If you have to select your transport by choosing your socket code down in the middle of your stack, or let something down there go 'yeah, whatever answers first using whatever' outside your control, you're at the mercy of choices made for an environment you may not live in.

Lloyd Wood

________________________________________
From: Michael Welzl [[email-masked]]
Sent: 02 December 2013 07:20
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [transport-services] draft-montpetit-transport-use-cases-00

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 3 Dec 2013 14:50:29 -0500

I agree in some way (yes it is very application centric) and disagree in another one (because this is what is the goal of if).

This document wants to come up with the use cases independently of the transports services and eventually use these to generate the requirements that in turn will help chose the services.

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

On Dec 3, 2013, at 2:46 PM, Joe Touch <[email-masked]> wrote:

> Hi, all,
> 
> While this outline is interesting, IMO it focuses quite a bit on the applications and not enough on the different transport services that can (a) actually be provided, and (b) are actually needed.
> 
> Joe
> 
> On 11/29/2013 8:57 AM, Marie-Jose Montpetit wrote:
>> 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] <mailto:[email-masked]>
>> [email-masked]
>> 
>> 
>> =
> 
> ---