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

[<[e-mail]>]

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
http://sat-net.com/L.Wood/


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

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

On 2. des. 2013, at 02:56, [e-mail] wrote:

> Why do you assume an http transfer involves a browser?
>
> Lloyd Wood
> http://sat-net.com/L.Wood/
>
>
> ________________________________________
> From: Michael Welzl [[e-mail]]
> Sent: 01 December 2013 23:27
> To: Arjuna Sathiaseelan
> Cc: Gorry Fairhurst; Jon Crowcroft; Marie-Jose Montpetit; <[e-mail]>; Igor Zhovnirovsky; [e-mail]
> Subject: Re: [transport-services] draft-montpetit-transport-use-cases-00
>
> 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
>
>
>
> On 1. des. 2013, at 08:19, Arjuna Sathiaseelan <[e-mail]> wrote:
>
>> 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 <[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
>>>>
>>>
>>>
>>>
>>>
>>> ---
>>> Transport Services BOF plan - website: href="https://sites.google.com/site/transportprotocolservices/
>>
>>
>>
>> --
>> Arjuna Sathiaseelan | http://www.cl.cam.ac.uk/~as2330/
>
>