IETF Logo Mail Archive

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

"Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com> Thu, 08 August 2013 09:25 UTC

Return-Path: <Alexander.Zimmermann@netapp.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301F321F9C9A for <tcpm@ietfa.amsl.com>; Thu, 8 Aug 2013 02:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-3.700, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxyQByDuscog for <tcpm@ietfa.amsl.com>; Thu, 8 Aug 2013 02:25:35 -0700 (PDT)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id F353921F9D02 for <tcpm@ietf.org>; Thu, 8 Aug 2013 02:25:34 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.89,838,1367996400"; d="asc'?scan'208"; a="40076433"
Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 08 Aug 2013 02:25:31 -0700
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.252]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 8 Aug 2013 02:25:31 -0700
From: "Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com>
To: Yuchung Cheng <ycheng@google.com>
Thread-Topic: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02
Thread-Index: AQHOk9cjavmpBvyUw0+uexU77ND+8ZmLgByA
Date: Thu, 08 Aug 2013 09:25:30 +0000
Message-ID: <0FCE61E5-337C-4506-9FDD-2287B98677EC@netapp.com>
References: <CAK6E8=eGSZbyHFg8R+y4Om4hbEdwK61TNN0_6H=wjPH8t1rgvA@mail.gmail.com>
In-Reply-To: <CAK6E8=eGSZbyHFg8R+y4Om4hbEdwK61TNN0_6H=wjPH8t1rgvA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_FB121E76-A872-47D8-8E07-FA6802D899BA"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Subject: Re: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2013 09:25:39 -0000

Am 08.08.2013 um 03:31 schrieb Yuchung Cheng <ycheng@google.com>:

> a few suggestions on the categorization.

Thanks

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

Done

> 
> 3.1 Fundamental Changes: I found it a little awkward to have
> "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.


>     Further: RFC5482 is not used/deployed, even tho Linux implements
> 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?
> 
> 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,

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

> 
> 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

yes...

> and RFC3522 to this section.

hmm... 

> The reason is that Eifel
> response function depends on RFC3522 so they should be together for
> better context.

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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

v2.46.0 | Report a Bug | By Email | System Status