Subject: Re: Treatment of ICMP for PMTU

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Jul 2018 10:45:47 +0200

Hi,

Den 2018-06-29 kl. 02:30, skrev Lubashev, Igor:
>>>   • What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)?
>> Isn't this sufficiently covered in 4821?
> Not really.  Or, at least I could not find anything more useful there then: "If an ICMP PTB message is received matching the probe packet, then search_high and eff_pmtu MAY be set from the MTU value indicated in the message."  So 4821 seems silent on what to do if ICMP is received for a non-probe packet, and it seems silent on how one could decide whether to set search_high and eff_pmtu from the MTU in ICMP or not (saying "MAY" does not really help here).  These questions are what I am trying to address for QUIC.
>
> 4821 uses MAY in the sentence above, since it does not really give any better indication.  This PR draws a distinction between ICMP w/ and w/o on-path proof and in some specific cases, it recommends a SHOULD.
>
>
If you look at the updated PLPMTUD:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/

3.3. Reducing the PLPMTU: Confirming Path Characteristics

    If the DPLPMTUD method detects that a packet with the PLPMTU size is
    no supported by the network path, then the DLPMTUD method needs to
    validate the PLPMTU. This can happen when a validated PTB message is
    received, or another event that indicates the network path no longer
    sustains this packet size, such as a loss report from the PL

    All implementations of DPLPMTUD are REQUIRED to provide support that
    reduces the PLPMTU when the actual PMTU supported by a network path
    is less than the PLPMTU.

Section 4.9 says:

    PROBE_DONE: The PROBE_DONE state indicates a successful end to a
       probing phase.  DPLPMTUD remains in this state until either the
       PMTU_RAISE_TIMER expires or a received PTB message is verified.

However, I have to say that the draft is a bit unclear on what to do at 
this point.

I guess the options are two.

Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my 
perspective, the important is that one uses this a signal for checking 
the PMTU.

I will start a thread on TSVWG WG mailing list regarding the lack of 
specific text in their draft for this case.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 2 Jul 2018 23:19:51 +0000

*   Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my perspective, the important is that one uses this a signal for checking the PMTU.

From my perspective, there are two things that are important here:

  1.  Use PTB signal to start probing (as you said).  This is section 3.3.
  2.  Identify cases, when you can set PMTU to PTB_SIZE immediately upon receipt of PTB, while the probing is happening.

Plus one more thing that is not in that draft at all – I think it is prudent to respect PTB, even if that PTB is not validated (i.e. w/o on-path proof, using my lingo), if PTB_SIZE is large enough (to be defined how large).  It probably deserves its own thread in tsvwg.

  *   Igor

From: Magnus Westerlund [mailto:[email-masked]]
Sent: Monday, July 02, 2018 4:46 AM
To: Lubashev, Igor <[email-masked]>; Eggert, Lars <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Martin Duke <[email-masked]>
Subject: Re: Treatment of ICMP for PMTU

Hi,

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Ddatagram-2Dplpmtud_&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=uDGI9jiS7Geg3dbv7-6X13iWfUICKy3fOiekJYaO_HA&s=MQRhWnsLTgO3sRXM-EnMvYTRoX9HubTysSfT_FPicJk&e=>

   is less than the PLPMTU.

Section 4.9 says:

However, I have to say that the draft is a bit unclear on what to do at this point.

Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my perspective, the important is that one uses this a signal for checking the PMTU.

I will start a thread on TSVWG WG mailing list regarding the lack of specific text in their draft for this case.

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 3 Jul 2018 11:08:44 +0200

Den 2018-07-03 kl. 01:19, skrev Lubashev, Igor:
>
>   * Probe starting at PTB_SIZE or verify Base_MTU and then probe up.
>     From my perspective, the important is that one uses this a signal
>     for checking the PMTU.
>
>  2. Identify cases, when you can set PMTU to PTB_SIZE immediately upon
>     receipt of PTB, while the probing is happening.
>
Yes, that should definitely be detailed. For a validated message, I 
think there are good reasons to adjust PLPMTU to PTB_SIZE when it is 
less than PLPMTU and >= BASE_MTU. As this can prevent driving at least 
one additional RTT of data likely into a MTU blackhole. However, there 
are clearly corner cases, for example with inconsistent MTUs. But the 
goal there is to find the lower of the multiple thresholds.

> Plus one more thing that is not in that draft at all – I think it is 
> prudent to respect PTB, even if that PTB is not validated (i.e. w/o 
> on-path proof, using my lingo), if PTB_SIZE is large enough (to be 
> defined how large).  It probably deserves its own thread in tsvwg.
>

Definitely a TSVWG thread I think, please start a thread. I see 
significant issue with using unvalidated PTBs. First of all one need to 
be able to be certain that it is actually related to ones flow at all. 
Secondly, if it doesn't contain any information that one can identify it 
as an actually sent packet then one are open to off-path attackers. That 
is a real issue. I think at most one can initiate a probe based on flow 
related but not fully validated PTB messages.

Cheers

Magnus Westerlund

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 6 Jul 2018 15:00:40 +0000

Mikkel, Igor,

In case you don't follow HTTPbis: I have published an I-D [1] [2] that surveys options for tunneling of UDP and IP. It presents some options for framing but it is not exhaustive. There's a slot on the agenda to discuss things there.

I added a HoL section in response to your earlier comments. I'm looking for input on whether such tunneling should depend on partial reliability in QUIC (bearing in mind that there may be some desire to support TCP-based HTTP).

Kind regards
Lucas

[1] https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnelling-00
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0025.html

________________________________
From: QUIC [[email-masked]] on behalf of Mikkel Fahnøe Jørgensen [[email-masked]]
Sent: 28 June 2018 11:07
To: Lucas Pardue; IETF QUIC WG; Martin Duke; Lubashev, Igor
Subject: RE: Treatment of ICMP for PMTU

I think QUIC needs a tunnel extension frame.

On 28 June 2018 at 11.25.20, Lucas Pardue ([email-masked]<mailto:[email-masked]>) wrote:

Igor Lubashev wrote:

>I think I see what you are talking about.
>
>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forward
>data streams, not packets. Hence, MTU concept on a tunnel-stream is
>meaningless. The text says it explicitly: "Note that the size and number of TCP
>segments is not guaranteed to map predictably to the size and number of
>HTTP DATA or QUIC STREAM frames." From the client's perspective there is
>only one PMTU that is relevant -- the one to the proxy. The proxy will keep
>tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP
>segments accordingly.

Right, that's how I was seeing it.

>Trying to design a CONNECT-like method to proxy an entire QUIC connection
>over a single QUIC stream would create HOLB for QUIC packets to and from
>the proxy. Some sort of a partially reliable QUIC stream could help here.

Both you and Mikkel have identified HOL as something that needs more thought. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL is enough to make QUIC not QUIC". I've taken the view that it may be desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL avoidance as an optimisation rather than a requirement. Partial reliability (of streams, or of some new frame type) could help solve that puzzle. Now I think about it, a complimentary mitigation could be to reserve a set of tunnel-streams to provide some basic multiplexing. However, the complexity of that might not be worth it.

>This proxying scheme would require an extension to CONNECT to open a
>UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also mandate
>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it
>would be a very good idea for such a proxy to add a new frame for providing
>ICMP-like explicit PMTU feedback to the sender (why leave the sender
>guessing and probing, if the PMTU is already known to the proxy?).

This is good feedback. Thanks!

Kind regards
Lucas

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 6 Jul 2018 15:43:50 -0400

Hi Lukas, thanks for working on this.

It’s a bit much for me swallow in detail so I can only provide some general
thoughts.

QUIC recently added extension frames that require IANA registry, but there
is an endless supply.
This could be used to define semantics suitable for lossless packets in a
very straightforward manner that may be simpler than Partial Reliability
once that lands because you just add a tunnel header and ship the frame as
if it were a UDP packet without ACK’ing it. There needs to focus on flow
control all the same. That could be tricky.

Now, adding extension random frames for something that aims to be standard
outside of QUIC is probably not optimal, especially considering that
QUIC/v2 is sort of expected to deliver something similar. In fact, this
could be great input for a v2 use case. I imagine there won’t be a one size
suits all partial reliability feature. In part because tunneling doesn’t
even want partial reliability, just unreliability - i.e. not attempt at
ordering what is received, if it is received.

Additionally, the constraint that tunneling should happen not just over
QUIC but QUIC/HTTP adds additional constraints because QUIC/HTTP would not
automatically add an extension frame. It might even not really support
partial reliability in v2 in a way that is well suited for the problem. On
the other hand, QUIC/HTTP seems to be infinitely hackable, so you could
abuse unistreams to create packets - but likely that would sink
unsuspecting end-points not optimized for that.

Now, I don’t know that much about HTTP tunnelling - but - it might be
possible to use QUIC/HTTP as a signalling path and create a separate QUIC
connection for payload with either an extension frame, or a future v2
unreliability feature, or even an official tunnelling frame.

Given that QUIC is encrypted, it becomes harder for middleware to block
non-HTTP, so the question is: why does it need to be over HTTP? If the
answer is that middelware still knows too much - perhaps QUIC should fix
that.

So, I think the best option would probably be to wait for v2 and do some
studies with extension frames meanwhile and possibly play with signalling
via QUIC/HTTP if it must be HTTP.

But all of this just based on intuition and no deep knowledge of tunneling
protocols.

Mikkel

On 6 July 2018 at 17.00.44, Lucas Pardue ([email-masked]) wrote:

Mikkel, Igor,

In case you don't follow HTTPbis: I have published an I-D [1] [2] that
surveys options for tunneling of UDP and IP. It presents some options for
framing but it is not exhaustive. There's a slot on the agenda to discuss
things there.

I added a HoL section in response to your earlier comments. I'm looking for
input on whether such tunneling should depend on partial reliability in
QUIC (bearing in mind that there may be some desire to support TCP-based
HTTP).

Kind regards
Lucas

[1]
https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnelling-00
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0025.html

------------------------------
*From:* QUIC [[email-masked]] on behalf of Mikkel Fahnøe Jørgensen [
[email-masked]]
*Sent:* 28 June 2018 11:07
*To:* Lucas Pardue; IETF QUIC WG; Martin Duke; Lubashev, Igor
*Subject:* RE: Treatment of ICMP for PMTU

On 28 June 2018 at 11.25.20, Lucas Pardue ([email-masked]) wrote:

>the proxy. Some sort of a partially reliable QUIC stream could help here.

Both you and Mikkel have identified HOL as something that needs more
thought. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL
is enough to make QUIC not QUIC". I've taken the view that it may be
desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so
I view HOL avoidance as an optimisation rather than a requirement. Partial
reliability (of streams, or of some new frame type) could help solve that
puzzle. Now I think about it, a complimentary mitigation could be to
reserve a set of tunnel-streams to provide some basic multiplexing.
However, the complexity of that might not be worth it.

Kind regards
Lucas

---

From: "Gorry (erg)" <[email-masked]>
Date: Tue, 3 Jul 2018 07:57:13 -0400

See below : 

> On 2 Jul 2018, at 19:19, Lubashev, Igor <ilubashe=[email-masked]> wrote:
> 

Fine (for me) to say to use as PROBED_SIZE, to trigger an immediate check that this size works. 

> Use PTB signal to start probing (as you said).  This is section 3.3.
> Identify cases, when you can set PMTU to PTB_SIZE immediately upon receipt of PTB, while the probing is happening.
>  

That last part, I  less clear about - and I think we see there are cases where that may not do what would be best. Please  do feel discuss in tsvwg...

Gorry 
> Igor