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

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 12 Aug 2014 09:03:19 +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:[email-masked]]
> 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:[email-masked]]
> > > 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