Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

Costin Raiciu <c.raiciu@cs.ucl.ac.uk> Mon, 05 May 2014 16:04 UTC

Return-Path: <c.raiciu@cs.ucl.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E15A1A03B9 for <tcpm@ietfa.amsl.com>; Mon, 5 May 2014 09:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQLUiDJW1v8Y for <tcpm@ietfa.amsl.com>; Mon, 5 May 2014 09:04:19 -0700 (PDT)
Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 786FC1A038D for <tcpm@ietf.org>; Mon, 5 May 2014 09:04:19 -0700 (PDT)
Received: from 5-12-111-140.residential.rdsnet.ro ([5.12.111.140] helo=192-168-0-103.rdsnet.ro) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1WhLN3-0005P3-Jq; Mon, 05 May 2014 17:04:01 +0100
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>
In-Reply-To: <5367B0F1.1000403@isi.edu>
Date: Mon, 05 May 2014 19:04:01 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <45E71AD0-D376-4E59-A094-19DAEFCE22D3@cs.ucl.ac.uk>
References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <CF8D8E25-E435-4199-8FD6-3F7066447292@iki.fi> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <CAO249yeyr5q21-=e6p5azwULOh1_jUsniZ6YPcDYd69av8MMYw@mail.gmail.com> <DCC98F94-EA74-4AAA-94AE-E399A405AF13@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <536548D7.5030802@uclouvain.be> <5367B0F1.1000403@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7QxhrdcN-oMD0Dro77FUGZn0x5E
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 05 May 2014 16:04:22 -0000

> A middlebox that examines the contents of TCP traffic - or worse, modifies it - needs to follow all of RFC1122 host requirements. It's interpreting content - if it sees a SYN with an unknown option, it ought to have removed it or dropped the SYN.
> 
> If it doesn't, you have a device that is broken and needs to be replaced.
> 
> We should design TCP to be liberal in what it accepts, but no Internet protocol should be designed to overcome deliberate implementation errors.

As much as I agree with this purist view of the Internet, I also believe it is unworkable if we want stuff deployed. 

Say we actually stuck to the plan and designed EDO for a world with reasonable middleboxes. Then we implement it in Linux, then we turn it on by default. Then, all of a sudden the Internet stops working, and you have disgruntled users cursing Linux right and left....

Trouble is, for middleboxes to change you need to have a working protocol (that is maybe suboptimal) and a strong need for the change, and push from OS/app vendors etc. 

Cheers.
Costin




> 
>> This results in  :
>> 
>> segment 1 : TCP header indicates 4 bytes of option, followed by EDO
>> option indicating an option of 100 bytes, 100 bytes of option (e.g. a
>> very long SACK), 500 bytes of data
>> 
>> segment 2 : TCP header indicates 4 bytes of option, followed by EDO
>> option indicating an option of 100 bytes, 500 bytes of data
>> 
>> The receiver will try to parse 100 bytes of option in the second segment...
> 
> Agreed.
> 
> However, now you're back to the NIC issue (which ought not be related):
> 
>> In their IMC paper entitled "Is it Still Possible to Extend TCP?",
>> Michio Honda et al. provide the following recommendation
>> http://conferences.sigcomm.org/imc/2011/docs/p181.pdf
>> 
>> "All the NICs we tested correctly copied the options to all the split
>> segments. TSO is now sufficiently commonplace so that designers of
>> extensions to TCP should assume it. The implication is that TCP options
>> must be designed so that when they are duplicated on consecutive
>> segments, this does not adversely affect correctness or performance."
> 
> This tells me your TCP interface was implemented incorrectly.
> 
> The correct interface passes options (including the extended option *and its associated contents*) ***SEPARATELY*** from the user data.
> 
> If that is done all the way down to the TSO, the TSO will correctly copy the option into individual segments correctly.
> 
> If, however, you implement this badly - and pass TCP segments as a whole to the offload engine, then the offload engine *has no business* splitting or coalescing segments.
> 
>> EDO should be modified to take this recommendation into account to be
>> deployable in today's Internet.
>> 
>> One possibility could be to include a checksum inside the EDO option.
>> 
>> 
>>   +--------+--------+--------+--------+----------+----------+
>>   |  Kind  | Length |  Header_length  |       Checksum      |
>>   +--------+--------+--------+--------+----------+----------+
> 
> That logic would apply too EVERY option, and now we have a TCP that wastes space primarily to locate and debug implementation errors.
> 
> I don't agree that TCP should be designed to overcome deliberate implementation errors.
> 
> Joe
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm