RE: ECN in QUIC

[Ingemar Johansson S <[e-mail]>]

Hi

I believe that I start to understand the issue. Still I don't believe that it is any problem with using packet counters. As Koen pointed out it can simplify processing and this was also stated when this question was raised on the tracker (see https://github.com/quicwg/base-drafts/issues/805 ).

Assuming that we tag which packet goes where it will be possible to track how many packets that gone in which direction. Also the ECT/CE counters indicate the count of ECT/CE marked packets when the packet with the highest known sequence number is received. So if we keep separate "congestion control and transmission list" context for the different path then it should work and the correct congestion control will be achieved regardless it is ECT(0) or ECT(1) based congestion control.
It will also be possible to detect ECN bleach along new paths with this. 
  
/Ingemar

> -----Original Message-----
> From: Christian Huitema [mailto:[e-mail]]
> Sent: den 25 januari 2018 23:11
> To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-
> bell-labs.com>; Lubashev, Igor <[e-mail]>; Brian Trammell
> (IETF) <[e-mail]>
> Cc: Ingemar Johansson S <[e-mail]>; QUIC WG
> <[e-mail]>; Bob Briscoe ([e-mail])
> <[e-mail]>
> Subject: Re: ECN in QUIC
> 
> On 1/25/2018 12:10 AM, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
> 
> > Some questions related to the remark of Christian: "We are heading
> towards a single packet sequence number space shared by multiple paths"
> > What is the rationale behind this?
> > Is the reason for this that there are currently no per path
> states/communications required? (because congestion control is currently
> out of scope, and it is currently the only per path processing required). In
> that case I understand why the current design of QUIC is optimizing itself
> towards application to application state, but we must make sure we don't
> make our live difficult if we have per connection state (when it is needed,
> like congestion control).
> 
> This is related to encryption options for multipath. I explained the design
> choices in https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/.
> AEAD encryption requires that sequence numbers do not repeat for a given
> encryption context. For multipath, this requirement can be met by either
> having separate encryption contexts per path, or having a single encryption
> context for all paths and using the same sequence number space for every
> paths. This is also a requirement when multiple paths are used for
> connection migration.
> 
> We had that discussion in Melbourne, and the sense of the room was clearly
> that having separate encryption contexts per paths was too complicated.
> Having a single sequence number space and a single encryption context is
> significantly simpler. There is a privacy issue, linkability via the sequence
> numbers, but that privacy issue can be addressed by encrypting the
> sequence numbers, and we pretty much agreed to do that. Hence my
> statement that "We are heading towards a single packet sequence number
> space shared by multiple paths".
> 
> Of course we still need to maintain per path variables for RTT, PMTU and
> congestion control. As long as we only support migration, that could be
> finessed somewhat by resetting these variables to their initial state at the
> end of the migration. But when we do true multipath, there will be a need to
> associate congestion control signals with paths. If we have a single sequence
> number, the way to do that is to maintain associations between packets and
> path, e.g. having a path tag in the packet copy kept for retransmission
> purposes. That's sufficient for signals like ACK or losses, but it requires that
> ECN signals be tied to specific packets.
> 
> -- Christian Huitema
> 
>