Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88

[Joe Touch <[e-mail]>]

Martin (et al.)

I continue to have grave concerns about additional presentations to the 
IETF by parties who squat on TCP option codepoints - in this case, TCP 
Crypt.

Any presentation on TCP Crypt to TSV should start - and end - with how 
they intend to undo the damage they have already done by deploying code 
using an unassigned codepoint.

I have raised this issue before, and it has still not been corrected:
https://github.com/sorbo/tcpcrypt/blob/master/kernel/linux/tcpcrypt/tcp_crypt.h

This situation needs to change before they should be given continued 
presence at the IETF IMO.

Joe

On 10/31/2013 11:13 AM, Martin Stiemerling wrote:
> Hi all,
>
> As promised a few more words about this part of the TSVAREA session in
> Vancouver:
>
> The intention of this "Evolution of IETF Transport Protocols" part is to
> test the waters if the IETF transport protocols are 'on track' of what
> is needed by today's hosts and applications -- and what's happening in
> the network.
>
> There are a number of activities around, see below, that propose changes
> to, for instance, TCP, and also new transport protocol proposals. There
> is also an on-going collaboration between the Transport Area and the
> HTTPbis working group with respect to HTTP/2.0.
>
> We will tackle a few of the proposals in the session, but there is no
> restricition to those. Here they are in no particular order:
>
> - The Saratoga protocol & interesting things out of this for the
> evolution of transport protocols (Presenter: Wes Eddy)
> - Functional decomposition of the transport layer (Presenter: Jana Iyengar)
> - TCP Crypt (Presenter: Andre Bittau)
> - IETF-43 Requirements for Unicast Transport/Sessions (ruts) bof
> (Presenter: Spencer Dawkins)
>
>
> Not well that there is also a presentation about the QUIC protocol just
> before this discussion.
>
>
> Note even better:
> The session does not need to deliver answers to any question that comes
> up, but is solely intended as a starting point for further activites, if
> needed, or just to note that we have talked about it, but everything is
> just fine and we can carry on.
>
> Thank you,
>
>    Martin
>
> On 10/23/2013 09:12 AM, Martin Stiemerling wrote:
>> Dear all,
>>
>> We would like to give time to the Transport Area to discuss any
>> potential need to evolve the IETF transport protocols.
>>
>> There are a number of proposals discussed in the IETF and outside of the
>> IETF on changing parts of TCP (e.g. laminar TCP [1]), reusing parts of
>> TCP (e.g., TCP Minion [2]), completely new transport protocols (e.g.
>> QUIC [3]), and also discussions about the congestion control approach to
>> be used (e.g., delay-based [4], LEDBAT [5]).
>>
>> (We are fully aware that this list of proposals is incomplete)
>>
>> Spencer and I are planning a slot in the TSVAREA session at IETF 88 in
>> Vancouver to discuss this topic.
>>
>> More information to come soon.
>>
>> Let Spencer and me know at [e-mail] if you are interested
>> in contributing actively to the session.
>>
>> Thanks,
>>
>>    Spencer and Martin, your TSV ADs.
>>
>> References
>> [1] https://developers.google.com/speed/protocols/tcp-laminar
>> [2] http://tools.ietf.org/html/draft-iyengar-minion-concept
>> [3]
>> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit?pli=1
>>
>>
>> [4] https://datatracker.ietf.org/wg/rmcat/charter/
>> [5] https://datatracker.ietf.org/wg/ledbat/charter/