Subject: Re: [quicwg/base-drafts] Address change and consent to send (#161)

From: ekr <[email-masked]>
Date: Fri, 05 May 2017 06:37:55 -0700

Note on "doesn't have to be random". I think the term you want here is "unpredictable" or "unguessable"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-299466679

---

From: janaiyengar <[email-masked]>
Date: Fri, 05 May 2017 18:35:23 -0700

You need two things here:
1. Server adds an unpredictable jump to packet number on noticing IP change. This can still leave the client open to a large cwnd's worth of data getting dumped on a victim. So,
2. Server cuts its cwnd to min cwnd (say, 4 packets) until a packet > first_packet_sent_on_peer_address_change is acked. At that point, the IP change is verified, and the server restores the cwnd.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-299607534

---

From: Martin Thomson <[email-masked]>
Date: Sun, 07 May 2017 16:56:39 -0700

@janaiyengar, you are assuming that a jump in packet number is what will carry the unguessable property.  I don't think that's sound.  In order for the jump to be valuable, it has to be large, which leads to the packet number encoding not being big enough.  The suggestion here, which I think is reasonable, is that you have an unguessable value that is sent to the endpoint that moved.  Overloading packet number for this is nice in theory, and it might be the right answer in the end, but I wouldn't presume that it is the best answer.

Also, you can't just "restore" the cwnd on a new path.  That path might look nothing like the previous path.  Unless you are also suggesting that your initial cwnd can safely be *anything* as long as you react properly, you have to allow for the possibility that the new path could be orders of magnitudes less capable than the previous path.  Starting congestion control all over is probably the only sensible thing you can do.  That is, you have a different congestion state for every path used.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-299745062

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 11 May 2017 19:28:37 -0700

Is not the following enough to defend against this?
- clamping down CWND (which you have to do anyway for a brand new path),
- a packet number jump (does not need to be huge; a jump several times bigger than MIN_CWND is sufficient), and
- an impending "QUIC Public Reset" or "ICMP Port Unreach"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300967380

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 20:30:43 -0700

As stated earlier ([here](https://github.com/quicwg/base-drafts/issues/161#issuecomment-299745062) and [here](https://github.com/quicwg/base-drafts/issues/305) for instance), I don't think that a single packet number gap contains enough entropy and it could in fact be a mistake to rely on it for other reasons.  ACK efficiency or resistance to delays and reordering being some concrete reasons against leaving intentional gaps.  I would rather we build something more concrete than rely on these implicit mechanisms.

As stated on the mailing list, Public Reset and ICMP Unreachable can't or won't necessarily be sent by the entity under attack.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300974860

---

From: janaiyengar <[email-masked]>
Date: Thu, 11 May 2017 21:56:06 -0700

On cwnd: When I said "restore the cwnd", I meant to the *initial cwnd* on the new path. Whatever cwnd you use on a new IP, the server cuts it down cwnd to *min_cwnd* (which is 2 x MSS), and then restores the cwnd back to the earlier cwnd on validation.

On packet number jumps: Are you saying that a 4-byte packet number is inadequate entropy? If so then we'll need to revisit Version Negotiation, since a VN packet includes a new server-selected connection ID and the only correlator is the packet number. An attacker could just as easily inject a VN packet with the correct packet number causing the connection establishment to break. (Actually, the problem in VN is worse than here, since the attacker cannot get a single packet wrong when trying to guess a jump. We haven't nailed down rules for when an endpoint receives a VN with a packet number that does not match any sent packets.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300983751

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 22:19:41 -0700

Are you assuming that you would create a 31-bit jump?  The draft currently suggests 8-bits, which is not sufficient for this attack.

FWIW, I don't assume that Version Negotiation gives any indication of consent to receive, though the echo of a 31-bit value might suffice (TCP is 32).  It doesn't need to really, because the client is only going to send the same packet that it would have sent without seeing any packets from the server.

The actual entropy from a 31-bit jump is actually less than you think.  The attacker can always pretend that packets were lost and guess high.  That has an effect on cwnd which might reduce the effectiveness of the attack if the guess is wrong, so the wiggle room is probably not that big, but the actual entropy is in fact smaller.

> We haven't nailed down rules for when an endpoint receives a VN with a packet number that does not match any sent packets.

Issue #523 opened.  Should be easy to rectify.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300986257

---

From: Marten Seemann <[email-masked]>
Date: Thu, 11 May 2017 22:30:31 -0700

There's another downside to skipping packet numbers. If the ACK that confirms the packet number jump is lost, the verification of the new path will take longer, since ACKs are not sent with every packet.
The PING-PONG solution (where the client needs to echo a random value provided by the server) has the advantage that a client could aggressively send out PONGs (e.g. include a PONG in every packet until one of them is acknowledged), to make sure that the server considers the new path valid as quickly as possible, even if some packets are lost.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300987552

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 22:33:44 -0700

An endpoint could aggressively send ACK frames in the same way, right?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300987882

---

From: Marten Seemann <[email-masked]>
Date: Thu, 11 May 2017 22:44:38 -0700

You'd have to make some assumptions about the size of the gap then. There are use cases for gaps larger than the normal reordering of the path that should not trigger the aggressive ACKing. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300989092

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 23:03:39 -0700

Do you have those use cases listed anywhere?  Other than for testing purposes, I was only aware of this specific issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300991410

---

From: Marten Seemann <[email-masked]>
Date: Thu, 11 May 2017 23:14:25 -0700

I heard of the idea to serve a single connection from multiple servers, and assigning a range of packet numbers to each server. I haven't thought all the details through, but if this is possible, there will be larger gaps (although you wouldn't need 31-bit packet number space for this).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300992846

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 23:19:36 -0700

Oh yeah.  Though `n` servers could be given `n*m+i`.  The idea is frightening and intriguing at the same time.

As for triggering an aggressive ACK, I agree that an explicit signal removes the uncertainty, but if the gap needs to be in the order of 2^31, then you can simply step up the ACK schedule if you see a large gap.  We could even recommend a minimum gap.

But that all assumes that packet number gaps are the right way to validate consent to receive.  I don't think that they are.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-300993571

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 12 May 2017 09:54:17 -0700

> stated on the mailing list, Public Reset and ICMP Unreachable can't or won't necessarily be sent by the entity under attack.

If an entity does not send Public Reset or ICMP Unreachable, and our CWND after a "migration" event was low, the CWND would not open up w/o ACKs, so the server (reflector) would not send anything more to the victim.  This is the same effect as not getting a PONG back.

> amount of entropy

You need a lot of entropy only when it is cheap for an attacker to keep guessing.  In this case, if your MIN_CWND is, say, 2, and you jump the packet number by rand(min=0, max=1023) (uniformly distributed), then with 99.8% probability the attacker's ACK will ack a packet you never sent, and he will kill this connection.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-301129576

---

From: hardie <[email-masked]>
Date: Fri, 12 May 2017 11:18:14 -0700

So, to confirm my understanding of this method, we expect a client to change connection-id when it knows it is changing IP address, for the linkability reasons we have rehearsed elsewhere.  This method would then get used whenever that new connection-id is seen for the first time and when a new IP is presented on the old connection ID, because we presume that this is an indication of NAT rebinding. 

Would a change in source port, re-using the same connection ID and IP also trigger this?  It seems like that presents a pretty small risk of being an attack.   

Which causes me to wonder whether we also ought to exempt other changes that are most likely to be due to either NAT rebinding or IPv6 address selection mechanics.  The same v4 /28 or v6 /64 seem very likely to be the same host.  Is it worth PINGing there?  Or is it not worth the special logic to test the change?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-301149244

---

From: janaiyengar <[email-masked]>
Date: Fri, 12 May 2017 14:23:54 -0700

>
> Are you assuming that you would create a 31-bit jump? The draft currently
> suggests 8-bits, which is not sufficient for this attack.
>

Yes, I was. That's an easy enough thing to change in the draft.

> The actual entropy from a 31-bit jump is actually less than you think. The
> attacker can always pretend that packets were lost and guess high. That has
> an effect on cwnd which might reduce the effectiveness of the attack if the
> guess is wrong, so the wiggle room is probably not that big, but the actual
> entropy is in fact smaller.
>
Not following. If an attacker guesses high or not, when the sender receives
an ACK for a packet it never sent, it MUST terminate the connection. I
don't think the cwnd or pretending that packet loss happened matters here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-301189475

---

From: janaiyengar <[email-masked]>
Date: Fri, 12 May 2017 14:33:55 -0700

That said, I'm definitely leaning towards the PING-PONG thing myself.  It's simpler to describe, implement, and not get wrong.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-301191336

---

From: janaiyengar <[email-masked]>
Date: Fri, 12 May 2017 14:41:41 -0700

Ted -- your summary is correct. I think we probably should require (MUST) it on an IP address change, but port number changes are probably ok. If we decide to go with a PING-PONG frame (which is where I'm leaning), then the cost of sending this frame isn't that high, so it's fine to be liberal in deciding when to send it.

Reducing the cwnd however has costs, and I would be more cautious there. Doing so on IP address changes seems like the safest thing to do. If we wanted to be slightly more performance-sensitive, we could do something like allow /24s without cwnd reduction, but still send a PING-PONG or something like it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-301192712

---

From: Martin Thomson <[email-masked]>
Date: Sat, 20 May 2017 04:08:02 -0700

IP might not be OK.  I think that a CGN will randomize in an unpredictable fashion, but if they don't it would be possible to do a reflection attack on hosts that share a CGN.  I agree that's narrow, and probably not very compelling, but nonetheless it suggests that in general we can't consider a change in port alone to be perfectly safe.  Probably safe with caveats might be OK, and we might allow a higher initial value for that, but I don't see any real harm in starting the congestion control over again.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-302866502

---

From: hardie <[email-masked]>
Date: Mon, 22 May 2017 09:46:29 -0700

On Sat, May 20, 2017 at 4:08 AM, Martin Thomson <[email-masked]>
wrote:

> IP might not be OK. I think that a CGN will randomize in an unpredictable
> fashion, but if they don't it would be possible to do a reflection attack
> on hosts that share a CGN. I agree that's narrow, and probably not very
> compelling, but nonetheless it suggests that in general we can't consider a
> change in port alone to be perfectly safe.
>
I'm not really following the difference between CGN behavior and NAT
behavior here that is causing you to draw a different conclusion for NAT
rebindings and CGN rebindings.  Are you seeing a case where the NAT has
re-bound and the CGN then rebinds as increasing the risk that the return
traffic is not seen?

> Probably safe with caveats might be OK, and we might allow a higher
> initial value for that, but I don't see any real harm in starting the
> congestion control over again.
>
I think the data we have so far indicates that a port-only change doesn't
require this, and I think it would substantially increase the number of
times you had to restart the controller.

Ted

> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/161#issuecomment-302866502>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5GFZ2yHbc35OJRr-pppYJEGXzz2hks5r7smRgaJpZM4LlHwL>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303155882

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 May 2017 17:11:31 -0700

Yes, this is generically applicable to NAT.

I'd be interested in that data.  You might be seeing less enterprise traffic, so I'd keep that as a caveat.  Because when you have a whitelist for port-only changes you get some potential issues there.  Unless you think that there is no reason why one enterprise user might be motivated to attack another host on the same network.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303253792

---

From: hardie <[email-masked]>
Date: Mon, 22 May 2017 17:21:15 -0700

On Mon, May 22, 2017 at 5:11 PM, Martin Thomson <[email-masked]>
wrote:

>  Unless you think that there is no reason why one enterprise user might be
> motivated to attack another host on the same network.
>
> So, the threat model is user X sets up a connection to server Z, receiving
port N of IP xxx.xxx.xxx.xxx.
user X detects that if User Y were to set up a connection, Port K would be
used with the same xxx.xxx.xxx.xxx. Alternatively, port K has been
allocated for some other connection of user Y's.
User X then begins to emit packets with xxx.xxx.xxx.xxx:K as source.
(The firewall and NAT pass these for reasons we cannot ken)
User Y receives the traffic.  In case one, it clogs the (physical) port.
In case two, it messes with the established connection.

I'd hazard a guess that firewall and NAT prevention of this is high enough
that keeping the connection window open while doing a PING/PONG still makes
sense, but I agree that I did not think of this particular threat model.

Ted

> <https://github.com/quicwg/base-drafts/issues/161#issuecomment-303253792>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5DE1Xs3VMNmdwXN3zcemME2gbi4Gks5r8iQzgaJpZM4LlHwL>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303255091

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 May 2017 17:29:23 -0700

Yes, if we assume that the attacker's resources are limited to those that exist behind the same NAT/firewall, it's pretty tricky to mount that attack.

In the end, I would prefer to have some simple blanket rules, followed by an explanation of some cases in which certain rules might be lifted.  Same-port migrations might be one of those cases.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303256271

---

From: hardie <[email-masked]>
Date: Tue, 23 May 2017 09:15:47 -0700

On Mon, May 22, 2017 at 5:29 PM, Martin Thomson <[email-masked]>
wrote:

> Yes, if we assume that the attacker's resources are limited to those that
> exist behind the same NAT/firewall, it's pretty tricky to mount that attack.
>
> In the end, I would prefer to have some simple blanket rules, followed by
> an explanation of some cases in which certain rules might be lifted.
> Same-port migrations might be one of those cases.
>
> I think the simplest blanket rules are:

1) If there has been an IP migration, reset the congestion window until a
PING returns a PONG.
2) If there has been a port migration, send a PING and reset the congestion
window if the PONG  does not return within 2x previous RTT.

While I use PING/Pong here, any of the methods discussed (packet skipping,
new return routability frame) have the same semantics; I'm more concerned
that we get simple blanket rules that don't have us reset the state when we
don't need to.
regards,

Ted

> <https://github.com/quicwg/base-drafts/issues/161#issuecomment-303256271>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5D-fr-uHRGGmDGoI_3goZU7johvhks5r8ihigaJpZM4LlHwL>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303452355

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 May 2017 18:05:36 -0700

If the PONG doesn't come back, I would say that the path is unusable.  

I can see the case for restoration in the case of a port-only change, on the assumption that the path between the remote endpoint and the NAT is unlikely to change significantly in terms of characteristics.   But an IP change could be onto a path with substantially different characteristics.

Here's my proposal:

If the IP address or port of a peer changes, reset the congestion window and initiate \<insert path validation method here>.  Once the validation completes, if the IP address of the peer did not change, the congestion window MAY be increased to the value it had prior to migration.  If the path validation method fails completely after \<some time>, mark the path as unusable, which might cause the connection to fail.

Question: do we have to consider the possibility that the prior congestion window might decay due to inactivity and account for that here, or is it better to continue to run the old controller, feed all the new signals into it and switch it in?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303585687

---

From: hardie <[email-masked]>
Date: Wed, 24 May 2017 11:16:41 -0700

On Tue, May 23, 2017 at 6:05 PM, Martin Thomson <[email-masked]>
wrote:

> Agreed.

> I can see the case for restoration in the case of a port-only change, on
> the assumption that the path between the remote endpoint and the NAT is
> unlikely to change significantly in terms of characteristics. But an IP
> change could be onto a path with substantially different characteristics.
>
> Here's my proposal:
>
> If the IP address or port of a peer changes, reset the congestion window
> and initiate <insert path validation method here>. Once the validation
> completes, if the IP address of the peer did not change, the congestion
> window MAY be increased to the value it had prior to migration. If the path
> validation method fails completely after <some time>, mark the path as
> unusable, which might cause the connection to fail.
>

So, there are two types of path changes which could happen here.  One is a
change in origin of the path, and an IP change would typically signal that
by being in a different address range.  So you'd have rough heuristics that
said if the new IP is in the same /N that it should be treated as likely
using the same path but that if it is in a substantially different CIDR
block it is likely using a different path.   The other change is one in
which some path elements are using functions like ECMP to share load across
links.  In those cases, a shift in port may also result in a shift in path
because the source port is used in the load sharing function.  While those
functions are generally aimed at keeping the load (and thus congestion) on
the relevant links in balance, there is no way to guarantee that they are.

As a result, what we do here depends a lot on what we're trying to
optimize.  If we want to minimize the lost of congestion control state, I
think we end up with something like:

If the source IP address or port of a peer changes, reset the congestion
window and initiate path validation.  If the path validation method fails
after <some time>, mark the path as unusable.  If the path validation
completes, the congestion window MAY be increased to the value it had prior
to migration; this increase should occur only when it is likely that the
change in IP address or port did result in a path change.  A change in both
port and IP should always be taken as evidence of a path change.

If we are trying to minimize the chance that a congestion window gets
re-opened inappropriately, I think we get something like this:

If the source IP address or port of a peer changes, reset the congestion
window and initiate path validation.  If the path validation method fails
after <some time>, mark the path as unusable.  If the path validation
completes, the congestion window MAY be increased to the value it had prior
to migration if only the port has changed and there is no other evidence in
a change in path.

> Question: do we have to consider the possibility that the prior congestion
> window might decay due to inactivity and account for that here, or is it
> better to continue to run the old controller, feed all the new signals into
> it and switch it in?
>
In the latter case, you mean that you'd feed the signals into both the new
controller created on IP/port change and the controller that existed before
the change, swapping the latter in when the path validation succeeded?

Ted

> <https://github.com/quicwg/base-drafts/issues/161#issuecomment-303585687>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5PFhqfaLL3ombwr3D2POfQMiiqyNks5r84JfgaJpZM4LlHwL>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303808138

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 May 2017 14:22:51 -0700

I guess that I'm in the "minimize the change that a congestion window gets re-opened inappropriately", absent more evidence that doing so wouldn't be too bad.

> [...] you mean that you'd feed the signals into both the new controller created on IP/port change and the controller that existed before the change, swapping the latter in when the path validation succeeded? 

Yes.  There might need to be some tweaks to that if we consider the possibility that the previous path could be reused, but that's essentially it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303855677

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 May 2017 22:13:44 -0700

Would there be a concern related to address change forced by overcrowded mibile networks at conferences, festivals, and disasters?

________________________________
From: Martin Thomson <[email-masked]>
Sent: Wednesday, May 24, 2017 11:22:50 PM
To: quicwg/base-drafts
Cc: Subscribed
Subject: Re: [quicwg/base-drafts] Address change and consent to send (#161)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/161#issuecomment-303855677>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AALzN7RK1WQGH0646ebrto8WUHlmkW-Eks5r9J-qgaJpZM4LlHwL>.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-303924401

---

From: mirjak <[email-masked]>
Date: Thu, 25 May 2017 06:27:09 -0700

I think "the congestion window MAY be increased to the value it had prior
to migration; this increase should occur only when it is likely that the
change in IP address or port did not result in a path change" is about right. MAY indicates that it is rather not recommended by default but as you have already a guess about the available bandwidth on the path, you can do some smarter probing like chirping where you send packets with different inter packet gaps. Or we don't say anything about this and leave it to the congestion controller because every congestion controller will anyway implement a different way to increase the window.

Another question: do we need to decrease to the minimal congestion window or the initial congestion window?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-304009727