Re: [conex] draft-ietf-conex-tcp-modifications-00.txt

John Leslie <john@jlc.net> Fri, 03 February 2012 14:18 UTC

Return-Path: <john@jlc.net>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE20A21F8540 for <conex@ietfa.amsl.com>; Fri, 3 Feb 2012 06:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.339
X-Spam-Level:
X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 4oCU-KvCqM1V for <conex@ietfa.amsl.com>; Fri, 3 Feb 2012 06:18:50 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C057121F852B for <conex@ietf.org>; Fri, 3 Feb 2012 06:18:49 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 11C5433C23; Fri, 3 Feb 2012 09:18:49 -0500 (EST)
Date: Fri, 03 Feb 2012 09:18:49 -0500
From: John Leslie <john@jlc.net>
To: Toby Moncaster <toby.moncaster@cl.cam.ac.uk>
Message-ID: <20120203141848.GL46701@verdi>
References: <20120201225647.22307.76083.idtracker@ietfa.amsl.com> <20120203011433.GJ46701@verdi> <201202030958.02017.mirja.kuehlewind@ikr.uni-stuttgart.de> <C7A4FC88-D58E-4E06-9A25-9204775D22CB@cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C7A4FC88-D58E-4E06-9A25-9204775D22CB@cl.cam.ac.uk>
User-Agent: Mutt/1.4.1i
Cc: conex@ietf.org
Subject: Re: [conex] draft-ietf-conex-tcp-modifications-00.txt
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2012 14:18:50 -0000

Toby Moncaster <toby.moncaster@cl.cam.ac.uk> wrote:
> On 3 Feb 2012, at 08:58, Mirja Kuehlewind wrote:
> 
>> just a quick comment for now: I will rework this section and probably
>> relax some of the MUSTs to SHOULDs as, yes, it is guess-work.
>> 
>> But counting packets is guess-work as well. You only know the number
>> of loss payload bytes at the TCP layer. To estimate how much packets
>> that have been is as much guessing?.

   Thank you!

   This is a good basis for discussion. TCP indeed "thinks" strictly in
bytes in interfacing to upper layers, and acknowledgments from the
receiver are denominated in bytes. Thus viewing congestion in bytes is
reasonable.

> And in fact you only know the number of packets the TCP sender /thinks/
> are lost. 

   Emphasis on the "lost"...

   Let us not forget the assumption in TCP congestion-control that the
losses indicate congestion -- while in fact we know there are other
reasons packets get lost.

> In actual fact though, TCP IS a byte stream, not a packet stream so
> to say accounting should be done byte wise is arguably in the spirit
> of TCP.

   Of course, TCP "is" a byte stream to upper layers, and a packet
stream to lower layers...

   But yes, accounting in terms of bytes probably _is_ "in the spirit
of TCP".

   However, IMHO, we shouldn't be aiming for the spirit of TCP --
rather we should aim for the spirit of IP. After all, we want our work
to be useful for transports other than TCP eventually.

   To the ISP (which is where I'm coming from), congestion is a matter
of packets, not bytes: there's no significant difference between big
packets and small packets in the congestion they may encounter. I
would like to see something akin to back-pressure telling me that
traffic to a particular destination is congested (not merely showing
packet loss which may be due to excessive noise instead of congestion).

   Will I ever see that -- perhaps not, but I can still wish for it.
I'm definitely glad we're proposing to notate loss separately from
ECN marking in ConEx marking.

   Probably Mirja and others enjoy figuring out how to infer congestion
in the absence of ECN or other explicit congestion signals -- to me,
this is uninteresting and possibly mis-directed. (But I'm glad someone
is working on that!)

> I would be interested to hear the views of someone in TCPM (I used to
> be, but not for 3 years or so).

   We could work on how to ask them, but someone actually active there
should pose the question. Perhaps something to the effect of
" 
" The folks in ConEx are working on how to account for congestion along
" the path from sender to receiver, in a manner visible to all nodes.
" There is discussion about whether it's better to count bytes or
" packets. Do any of you want to chime in on that?

> PS I personally feel packets is correct from a purely pragmatic
> engineering perspective (in other words, in the IETF spirit rather
> than the IRTF spirit)

   Of course I agree -- and I'd argue that this is an IETF WG, not an
IRTF RG...

--
John Leslie <john@jlc.net>