Re: [conex] ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05)

"Scheffenegger, Richard" <rs@netapp.com> Tue, 12 August 2014 09:04 UTC

Return-Path: <rs@netapp.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF81A07AC for <conex@ietfa.amsl.com>; Tue, 12 Aug 2014 02:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 nPbRGas8UnSP for <conex@ietfa.amsl.com>; Tue, 12 Aug 2014 02:04:03 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149BC1A07A8 for <conex@ietf.org>; Tue, 12 Aug 2014 02:04:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.01,847,1400050800"; d="scan'208";a="181449481"
Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 12 Aug 2014 02:04:03 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht04-prd.hq.netapp.com (10.106.77.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 12 Aug 2014 02:03:32 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 12 Aug 2014 02:03:31 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::c1bc:1fd5:922:886d%21]) with mapi id 15.00.0913.011; Tue, 12 Aug 2014 02:03:20 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Bob Briscoe <bob.briscoe@bt.com>
Thread-Topic: ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05)
Thread-Index: AQHPtWHz2i+Ekg14OEq23ra1x9j48JvLXEywgACRsGiAAL4qQA==
Date: Tue, 12 Aug 2014 09:03:19 +0000
Message-ID: <0730db69e74f4dcd9da8924f96b65eb3@hioexcmbx05-prd.hq.netapp.com>
References: <201408111244.s7BCiA7m021070@bagheera.jungle.bt.co.uk> <61f7d201e0484835825c74e3fcca2f8f@hioexcmbx05-prd.hq.netapp.com> <201408112137.s7BLbDoc022547@bagheera.jungle.bt.co.uk>
In-Reply-To: <201408112137.s7BLbDoc022547@bagheera.jungle.bt.co.uk>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.120.60.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/yRZKTGN712_ZG4iaxYN4W6CjzsI
Cc: Mirja KUEHLEWIND <mirja.kuehlewind@ikr.uni-stuttgart.de>, "conex@ietf.org" <conex@ietf.org>
Subject: Re: [conex] ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05)
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 12 Aug 2014 09:04:07 -0000

Hi Bob,

in the context of TCP, segment A is likely to be a pure ACK too; which would not be marked ECT per 3168, or at least the receiver would not reflect any mark (or loss) of such a pure ACK back (B).


But you are correct in the example, when A is a data segment, B is a data segment, and C is a pure ACK, the sender should not withhold or delay Conex information. And I fully agree with your observation that this paragraph has it upside down.

With a modification in the TCP semantics (AccECN), that example would extend to cases where either A or B (or both) are pure ACKs as well, that get ECN marked, so C would have the appropriate E bit set; Only ACK losses would not cause a Conex L bit, as pure ACK losses are not detected.

Best regards,

Richard Scheffenegger



> -----Original Message-----
> From: Bob Briscoe [mailto:bob.briscoe@bt.com]
> Sent: Montag, 11. August 2014 23:37
> To: Scheffenegger, Richard
> Cc: Mirja KUEHLEWIND
> Subject: RE: ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05)
> 
> Richard,
> 
> At 14:02 11/08/2014, Scheffenegger, Richard wrote:
> >Hi Bob,
> >
> >I believe you are making the argument for really symetric signaling;
> >like what we had discussed for AccECN and pure ACKs for the ECN header.
> >
> >And I agree with you, for a symmetric signal it doesn't make any sense
> >to exclude some fraction of segments from that stream; the X bit by
> >itself only signifies that this stream could have some conex markings
> >also...
> 
> No, no, no. I agree with your conclusion, but your reason is misplaced.
> 
> 
> >I guess the better approach might be to state something like:
> >
> >
> >       Current TCP ECN mechanisms do not provide congestion feedback
> > information
> >       about control packets such as pure ACKs which are not carrying any
> >       payload.
> >
> >       However, even though no conex information may be available,
> > future mechanisms
> >       could provide appropriate feedback. Therefore, these packets
> > MUST carry a
> >       Conex Destination option with the X bit set, but both L and E
> > bits SHOULD be
> >       unset, unless the sender has means to determine that control
> > packets were
> >       lost or marked with CE.
> 
> No. No. No. Nothing to do with any of this TCP feedback stuff.
> Please reboot brain into ConEx mode.
> 
> ConEx info is about the packet 1 RTT earlier (A), that triggered an ACK in
> the opposite direction (B), which in turn triggered this pure ACK we're
> talking about (C).
> 
> ConEx info on C is not about the possible loss or possible congestion
> marking in the IP layer of C itself. ConEx info on C is not even anything
> to do with the congestion feedback in the TCP layer of C.
> 
>   |` .   data         |
>   |` . ` .            |
>   |    ` . ` x(loss)  |
>   |        ` .        |
>   |            ` .    |
>   |             A  ` >|
>   |                . '|
>   |            . '    |
>   |        . '        |
>   | B  . ' data + SACK|
>   |< '                |
>   |` .                |
>   |    ` .            |
>   |        ` .        |
>   |            ` . C  |
>   |                ` >|
> 
> 
> The question of what ConEx marking there is on packet C doesn't depend on
> whether C is a pure ACK (or not). From the ConEx point of view, C is just
> an IP packet. ConEx doesn't care what's in packet C at the TCP layer. It's
> just an IP packet to put a CoNEx marking on.
> 
> There is absolutely no reason to say a pure ACK should not be marked
> ConEx-capable.
> 
> Indeed, once a host transport stack is ConEx-capable, it can mark all
> packets that it sends as ConEx-capable, irrespective of whether the other
> end supports ConEx (there's no such thing as 'supporting ConEx'
> for a receiver).
> 
> Regards
> 
> 
> Bob
> 
> 
> 
> 
> >Richard Scheffenegger
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob Briscoe [mailto:bob.briscoe@bt.com]
> > > Sent: Montag, 11. August 2014 14:44
> > > To: Mirja KUEHLEWIND; Scheffenegger, Richard
> > > Subject: ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05)
> > >
> > > Mirja, Richard,
> > >
> > > I don't see why TCP pure ACKs need to have ConEx-capable turned off
> (X=0).
> > >
> > > draft-ietf-conex-tcp-modifications-05 says:
> > > "
> > >     No congestion feedback information are available
> > >     about control packets such as pure ACKs which are not carrying any
> > >     payload.  Thus these packets should not be taken into account when
> > >     determining ConEx information.  These packet MUST carry a ConEx
> > >     Destination Option with the X bit unset.
> > > "
> > >
> > > However, ConEx on one packet isn't about the feedback in /that/
> packet.
> > >
> > > A stream of pure ACKs could be useful to send ConEx markings,
> > > particularly if a host that is primarily a data receiver doesn't
> > > often send data packets, but needs to send some timely ConEx
> > > markings to make up a deficit in marking. Even tho a pure ACK
> > > doesn't carry many bytes (80B incl IPv6 header), it's better than
> nothing.
> > >
> > > A network operator is entitled to police non-ConEx-capable packets
> > > more stringently than ConEx capable, so a TCP sender doesn't want to
> > > risk losing pure ACKs more than other packets.
> > >
> > >
> > > Bob
> > >
> > >
> > > ________________________________________________________________
> > > Bob Briscoe,                                                  BT
> 
> ________________________________________________________________
> Bob Briscoe,                                                  BT