Re: Transport services BoF

[Michael Welzl <[e-mail]>]

Hi,

Indeed this discussion should probably take place at the  [e-mail] mailing list - see
https://sites.google.com/site/transportprotocolservices/  for more info

… but I'll answer here anyway:

there was this workshop arranged around RFC5218:
http://www.iab.org/activities/workshops/itat/

where I presented, the slides are at:
https://sites.google.com/site/transportprotocolservices/activities
This is the short paper I had there, where I tried to make the point regarding beneficial incremental deployment:
http://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_8.pdf
=> it's about using the "best effort" model: you wish for more, but live with less, potentially. At least that's one out of a few possible ways ahead.

As for who the "party" is: I think one possibility is to focus on user space implementations for a while… e.g. see http://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis
=> one rather straightforward deployment path is to do an update of a middleware like ZeroMQ to use different things than just TCP whenever possible in some reasonable way.

Since the main goal of TAPS is just to define the services and specify examples, it's not limiting to only one way of implementing things - from the point of view of "updating ZeroMQ", the RFCs that would come out of a TAPS-WG would just serve as implementation guidance.

Cheers,
Michael



On Feb 14, 2014, at 10:09 AM, [e-mail] wrote:

> Jose, all – sorry, (as I think you guessed!) my comment was about the transport services bof, not TCM-TF
>  
> phil
>  
> De: tcmtf [mailto:[e-mail]] En nombre de [e-mail]
> Enviado el: miércoles, 12 de febrero de 2014 11:59
> Para: [e-mail]; [e-mail]
> CC: [e-mail]
> Asunto: Re: [tcmtf] BoF preparation: Improvements in TCM-TF according to the received comments
>  
> << Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism offer a large number of services to applications in addition to the long-standing two services provided by TCP and UDP. For an application programmer, using protocols other than TCP or UDP is hard>>
>  
> One thing I think would be useful is to analyse this as a migration problem. I know lots of people have thought about why migration is hard. My take is that the crucial issues are to make sure there is incremental benefit (the party migrating gets a benefit now and not when everyone else has migrated) and to try and ensure migration can be one party at a time (so others don’t have to care – ‘party’ is most obviously one end host, but in some circumstances can be eg ‘Apple iOS’). There’s some quite nice stuff in RFC5218.
>  
> Best wishes
> Phil
>  
> From: tsv-area [mailto:[e-mail]] On Behalf Of Jose Saldana
> Sent: 05 February 2014 12:05
> To: [e-mail]
> Cc: [e-mail]
> Subject: BoF preparation: Improvements in TCM-TF according to the received comments
>  
> Hi all,
>  
> In order to prepare the BoF in London, I have tried to summarize the questions that have been discussed, in order to include the improvements in the charter and in the two drafts.
>  
> On behalf of clarity, I will send different messages with the solutions for each problem.
>  
> If you think there are other problems, please start a new thread.
>  
>  
> Problems discussed in the BoF:
>  
> 1) TCP multiplexing and effect on TCP dynamics. (I think this was the main problem).
>  
> 2) Path MTU discovery issues
>  
> 3) Are we adding latency and complexity to save relatively little bandwidth?
>  
> 4) Do vendors want standards in this space?
>  
>  
> Problems discussed in the list:
>  
> 5) Why is ROHC not a solution?
>  
>  
> Jose
>