Subject: [Tsv-art] do we need a checklist or guidelines?

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 11:16:53 -0700

Hi, all,

I'm seeing increasingly bizzare attempts to modify TCP.

We currently have two requirements for TCP mods, AFAICT:

    a) passes TSV-chair, TSV-ART, and possibly TCPM, TSVWG, etc. review

    b) includes "TCP-friendliness" (mostly for congestion control)

I propose it's time for some new criteria, as follows. Can others let me
know if this would be useful to document somehow, whether formally as an
ID or at least as a TSV-ART checklist?

    c) compliant with existing TCP requirements, notably:

        1) compatible with already-defined TCP options

        2) fail-safe fallback to legacy endpoints (notably not requiring
a new connection attempt with different parameters)

Criteria "c)" is currently under "attack" (imo) by some in the LWIP and
MPTCP groups, the former which hasn't addressed this issue at all and
the latter appears to be actively rejecting it.

Thoughts?

I'd be glad to write this up further, with justification.

Joe

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 19 Jul 2017 18:34:21 +0000

l deal with the LWIG document (to ensure TCPM review) and as of now I don't think I need any formal checklist for that specific document. 

Also, we decided to publish documents such as DCTCP for somewhat controlled environments. I am not sure if DCTCP would really meet requirement b). So this sort of list may be non-trivial.

Michael

> -----Original Message-----
> From: Tsv-art [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Wednesday, July 19, 2017 8:17 PM
> To: [email-masked]
> Subject: [Tsv-art] do we need a checklist or guidelines?
> 
> Hi, all,
> 
> I propose it's time for some new criteria, as follows. Can others let me know
> if this would be useful to document somehow, whether formally as an ID or
> at least as a TSV-ART checklist?
> 
>         2) fail-safe fallback to legacy endpoints (notably not requiring a new
> connection attempt with different parameters)
> 
> Criteria "c)" is currently under "attack" (imo) by some in the LWIP and MPTCP
> groups, the former which hasn't addressed this issue at all and the latter
> appears to be actively rejecting it.
> 
> Thoughts?
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 12:50:37 -0700

> l deal with the LWIG document (to ensure TCPM review) and as of now I don't think I need any formal checklist for that specific document. 
I just posted a related request for clarification to LWIG. Can you
contact me directly with your thoughts on that?

> Also, we decided to publish documents such as DCTCP for somewhat controlled environments. 
Sure - OK, so the list below needs some tweaking, of course. It needs to
be "relatively friendly to TCPs in the same environment", at least.

Joe

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 20 Jul 2017 08:25:11 +0000

The main author has already replied to your review; I suggest to discuss on the LWIG list.

The document will have to evolve and improve, but I think we have enough means to ensure TCPM review.

Michael

> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2017 9:51 PM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; tsv-
> [email-masked]
> Subject: Re: [Tsv-art] do we need a checklist or guidelines?
> 
> 
> 
> > l deal with the LWIG document (to ensure TCPM review) and as of now I
> don't think I need any formal checklist for that specific document.
> I just posted a related request for clarification to LWIG. Can you contact me
> directly with your thoughts on that?
> 
> Sure - OK, so the list below needs some tweaking, of course. It needs to be
> "relatively friendly to TCPs in the same environment", at least.
> 
> Joe

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 20 Jul 2017 14:22:16 +0200

Hi Joe,

I would say that the points under c) are usually already discussed and considered in the IETF (in tcpm where we sooner or later have all these proposals presented at least once). However, I don’t see a need to further formalize anything here because I don’t see how this could help.

I also think that „attack“ is really not the right word here. People are free and should be encouraged to bring their idea to the IETF/tcpm and then have a discussion with the experts there figuring out if their proposed solution is the right approach or if there are other better alternatives. Just trying to send these people away doesn’t help.

Mirja

> Am 19.07.2017 um 20:16 schrieb Joe Touch <[email-masked]>:
> 
> Hi, all,
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Jul 2017 07:27:31 -0700

> I also think that „attack“ is really not the right word here. People are free and should be encouraged to bring their idea to the IETF/tcpm and then have a discussion with the experts there figurin…
The issue is similar to security considerations, congestion issues with
UDP, etc - the community *is* extending and adapting TCP and certainly
we're providing feedback, but that feedback would be a lot more
efficient if the community knew what our expectations were, IMO.

Especially when some of these requests for transport analysis happen in
days/hours before IESG review, as is too often the case.

Joe