Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt

[Joseph Touch <[e-mail]>]

Some thoughts...

> On Mar 24, 2020, at 7:09 AM, Wesley Eddy <[e-mail]> wrote:
> 
> In this update, I think everything is addressed except for 4 topics:
> 
> 1) Reserved bits description - I made no changes yet.  Discussion spanned a few threads, but didn't look to me like it converged.  Michael's summary thread covers a number of options and relevant questions: https://mailarchive.ietf.org/arch/msg/tcpm/UOHo4tXQPpBV90U-pRmdt_LfjRA <https://mailarchive.ietf.org/arch/msg/tcpm/UOHo4tXQPpBV90U-pRmdt_LfjRA>IMO, need to be clear that:
- MUST be ignored by endpoints that don’t support their assigned use
- MUST be set to zero by endpoints that don’t support their assigned use
- requires standards-track doc to assign (IMO)

If we want to assign any for experiments, we would do that in a standards-track update to this doc, so this decision doesn’t box us in for all time — but we’re not there yet IMO
> 2) R1 and R2 values - Gorry questioned whether (A) applications should still be notified with R1 is reached, and (B) whether R1 = 3 RTOs and R2 >= 100s are still recommended values.  I don't think any other RFC or errata has revised these, so am inclined to leave it alone for now in this doc, but maybe bookmark it as a topic for future consideration in the working group.
> 
No particular comment...
> 3) Dead gateway detection - I made no changes yet; this may be another topic for potential future consideration.  The question is posed here:https://mailarchive.ietf.org/arch/msg/tcpm/IGhHYUOCwES7I-DjsgHnFsa-zVY/ <https://mailarchive.ietf.org/arch/msg/tcpm/IGhHYUOCwES7I-DjsgHnFsa-zVY/>I see the original question but nothing further. I don’t see anything needed beyond what’s in RFC1122 here. This is an optimization of a given TCP implementation to help IP, not the responsibility of TCP in any way to support. I.e., at best, this doc could say that “some TCP statistics may be used by other protocols, e.g., by IP for dead gateway detection”. But not require it.
> 4) OPEN+LISTEN while same local port is in SYN-SENT/RECEIVED - I made no changes yet, but Gorry suggested that the text below may need updating with regard to modern systems (I'll be grateful for specific suggested changes on this):
> 
> A TCP that supports multiple concurrent users MUST provide an
> OPEN call that will functionally allow an application to LISTEN
> on a port while a connection block with the same local port is
> in SYN-SENT or SYN-RECEIVED state (MUST-42).
> 
I would change it to talk about connections rather than users, but otherwise retain it largely as-is:

A TCP that supports multiple concurrent connections MUST provide an
OPEN call that will functionally allow an application to LISTEN
on a port while a connection block with the same local port is
in SYN-SENT or SYN-RECEIVED state (MUST-42).

This does beg the question about whether we want to address how a LISTEN on wildcard affects concurrent LISTENs on more specific values or even OPENs. I’d really like to see this addressed explicitly - it’s a property of our API that seems to be underspecified (AFAICT).

IMO:
	More specific socket-pairs SHOULD be allowed in both LISTENs and OPENs in the presence of wildcard LISTENs.

I’d even favor that being a MUST, recognizing that existing systems may not support this.

Joe