Subject: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02

From: Yuchung Cheng <[email-masked]>
Date: Thu, 8 Aug 2013 02:31:54 +0100

a few suggestions on the categorization.

s/2. Basic Functionality/2. Core Functionality

3.1 Fundamental Changes: I found it a little awkward to have
"Fundamental Changes" under "recommended enhancements".
     Further: RFC5482 is not used/deployed, even tho Linux implements
it. Why is it recommended and/or fundamental?

both 3.2 and 3.3 have CC and loss recovery, I suggest we put all CC in
3.1 and LR in 3.2,

3.1: Congestion Control:
RFC3465,RFC6633,RFC3168

3.2: Loss recovery
 RFC2018, RFC6675, RFC3042, RFC6582

3.3 Detection and Prevention of Spurious loss recovery
  Move DSACK and RFC3522 to this section. The reason is that Eifel
response function depends on RFC3522 so they should be together for
better context.

Thanks.

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 8 Aug 2013 07:21:56 +0000

> it. Why is it recommended and/or fundamental?

As an author of that RFC, I agree with Yuchung. It shouldn't be in that category.

Lars

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 8 Aug 2013 09:25:30 +0000

> a few suggestions on the categorization.

Thanks

> s/2. Basic Functionality/2. Core Functionality

Done

> "Fundamental Changes" under "recommended enhancements".

From RFC 4614 (original TCP Roadmap)

" 
3.  Recommended Enhancements

   This section describes recommended TCP modifications that improve
   performance and security.  RFCs 1323 and 3168 represent fundamental
   changes to the protocol. 
"

As we can see, the original authors of the roadmap (and hopefully also
TCPM :-)) saw RFC 1323 as a fundamental change. So, so the only thing I did
was to create a section with this title and put the RFC into.
Nevertheless, if we believe now that the original text and therefore also
the title is misleading we can change them.

> it. Why is it recommended

Because it is standard track :-) But I agree with you, we should move
RFC5482 to Sec 4. since it is not deployed (@Hagen submit your patch to
netdev... :-))

I Sec 4. we do not have right subsection at the moment. I propose
"4.5 TCP Timeouts" (or something similar). In this section we could also
include "draft-ietf-tcpm-rtorestart-00", but I guess the roadmap will
shipped earlier to IESG :-)

> and/or fundamental?

Fine by me. Maybe we should do the same thing with section 4.2?
Any suggestions

>  Move DSACK

yes...

> and RFC3522 to this section.

hmm... 

> The reason is that Eifel

The same applies for RFC 3708...

We have the subsection "Detection and Prevention of Spurious Retransmissions"
in both sections: Recommended Enhancements and Experimental Extensions.
I think the reader able to connect this together. Moreover I put some text
in both section to connect them together.  

> 
> 
> Thanks.
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 8 Aug 2013 23:13:51 +0200

>RFC5482 to Sec 4. since it is not deployed (@Hagen submit your patch to

patch is nearly complete: already rebased on net-next but some IPv6 issues are
still around. Next week I will post the patch to netdev - I swear! ;-)

Hagen

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 8 Aug 2013 23:23:15 +0200

>it. Why is it recommended and/or fundamental?

BTW: a FreeBSD implementation also exists! The FreeBSD guys did some interop
analysis with my Linux implementation.

Hagen