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 [email protected] 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/
