Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

["Lubashev, Igor" <[e-mail]>]

ConEx tries to address the right set of questions, albeit the only proposed solution was for IPv6.

I like ConEx’s including an ECN CE Echo bit, since that lets you determine upstream and downstream congestion (if it happens on an ECN-supporting device). It is valuable for protocols that encrypt transport’s CE Echo information (like QUIC).  The combination of Q-bits (as in RFC 8321) and L-bits (as in ConEx) would let you do the same for loss.  A Spin-bit would be a useful addition for measurement, albeit it would require cooperation of both endpoints.


  *   Igor

P.S.
  There is work in ippm (draft-cfb-ippm-spinbit-new-measurements) that also attempts to use bits to inform the network about loss. That alternative does not require observer inferring Q-bit period (some power-of-2), but it requires both endpoints cooperating (which affects deployability) and can only detect loss of a minority of packets (fewer than 1/4 of server-to-client packets will typically have markings whose loss can be detected).


From: Mirja Kuehlewind <[e-mail]>
Sent: Thursday, October 24, 2019 11:54 AM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]; Lubashev, Igor <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

In ConEx, we also get upstream congestion by subtracting the ECN CE marks form the ConEx ECN marks, or count TCP seq# holes and subtract that number from the ConEx Loss marks. Of course the latter is not possible with QUIC and you would need something like the Q bit instead which however is basically Alternate-marking as defined in RFC8321.


From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 24. October 2019 at 16:38
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Nico,

Please can you explain your comment about the L bit: “only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)” Surely both the Q & the L bit are set by the sender?

I’d prefer a generic solution rather than one for one transport protocol.

I think it’s worth looking at https://tools.ietf.org/html/rfc7837<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7837&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=e78wvO7sMQ1OPb7LbdJ_VnbfcyceRVPepLvIuj98Woo&s=XqGR97CccV-6CMMzb-eeKiHHqx7DZbA_0VA0Bs031y4&e=>    This defined an IPv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7837-2520This-2520defined-2520an-2520IPv6&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=e78wvO7sMQ1OPb7LbdJ_VnbfcyceRVPepLvIuj98Woo&s=Vo5lTS0Qy4xW-ioc1-o1zIfIXWlcw0gJpDabAPOuSOY&e=> destination option for carrying ConEx markings in IPv6 datagrams. I think its L bit is identical to your L bit. RFC7837 also has 4 reserved bits so a bis would have plenty of room for Q bit.

https://tools.ietf.org/html/rfc7837#section-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7837-23section-2D3&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=e78wvO7sMQ1OPb7LbdJ_VnbfcyceRVPepLvIuj98Woo&s=FTyahheiTLt2hB9tJ0CxCtWPdcYLYjB6qdaaInTFUSA&e=>  discusses why the WG chose a destination option.

There seems to me a lot of similarity between the Conex work and this work, both in objectives & method. The Q bit is new since conex, and seems to offer some advantage of a clearer signal about upstream loss, under some assumptions.

Best wishes,
phil

From: tsvwg [mailto:[e-mail]] On Behalf Of Kuhn Nicolas
Sent: 24 October 2019 11:20
To: 'Christian Huitema' <[e-mail]<mailto:[e-mail]>>; Tom Herbert <[e-mail]<mailto:[e-mail]>>; Lubashev, Igor <[e-mail]<mailto:[e-mail]>>
Cc: Joe Touch <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Hi,

As far as I can see, there are different ways of signaling losses that are being discussed.
Here is an attempt of discussing advantages and drawbacks of each approach.
I believe that going for : short-term QUIC-bits and long-term TSVWG-bits is a good way forward. Moreover, this does not prevent from also having layer IP solutions.

-              Using IP level bits
Advantage : long term solution that is compatible for any upper-layer protocol
Drawback : compatibility with L2 tunnel solutions, problems in making it for IPv4 and IPv6 and only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)
-              Using new QUIC bits
Advantage : quick deployment of the solution and simple solution
Drawback : specific to QUIC
-              Generic transport solution
Advantage : standard solution for any transport
Drawback : “time-to-market” and only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)
-              Using OAM information
Advantage : management plane focusing on management functions – clearer interfaces between control, data and management planes
Drawback : need for standard interfaces between the different equipment that may follow other standard (IEEE, 3GPP) and management of “old” network still in operation

The privacy issues that are said to be specific to QUIC solution are inherent to any solution IMHO.

My 2cts,

Nico


De : tsvwg <[e-mail]<mailto:[e-mail]>> De la part de Christian Huitema
Envoyé : lundi 21 octobre 2019 20:20
À : Tom Herbert <[e-mail]<mailto:[e-mail]>>; Lubashev, Igor <[e-mail]<mailto:[e-mail]>>
Cc : Joe Touch <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Objet : Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019



On 10/21/2019 7:31 AM, Tom Herbert wrote:
Igor,

That misses the point of the statement. There are many protocols that don't have ubiquitous support over the Internet-- EH, IP fragmentation, any transport protocol other than TCP and sometimes UDP, and even IPv6. If "ubiquitous support" is required for deployment then we can never deploy new protocols or any protocol that is atypical to intermediate devices. So, unless we're planning on never doing anything new on the Internet, we need to address this.


The goal of any "for the network" signal is improved QoS.  Hence, if there is a non-trivial chance that inclusion of such signal will actually degrade QoS (by causing packets with the signal to be dropped), no sender will include such signals (and "happy eyeballs" style code is too complex and risky for the benefit).

As architecturally "ugly" as it sounds, I can only see the QUIC header and the most significant TTL bits as viable alternatives to be deployable widely on the Internet for IPv4.  For IPv6, even HBH and Dest Options are still too "risky" for packets, but that is likely to be improving.

You forgot to mention efforts to encode information in IP addresses, overload bits in the flow label, or other DPI parsing of UDP payload (like tunnels over UDP), and other creative ways to "find" bits that can be repuposed. There're all hacks! IP is designed to be an extensible protocol without the need for these. Pursuing such hacks, instead of using the defined mechanisms of extensibility, ostensibly solves some short term problems, but in the long run perpetuates protocol ossification and stifles evolution of the Internet.



If we want to not rely on hacks, I believe that we have to somehow change the network protocol. I have followed the development of the spin bit in QUIC, and the attempts to use more bits and provide for example indications of packet losses. There are typically two issues: privacy and practicality. Let's not discuss privacy here, except by assuming that privacy-sensitive deployments will find a need to "bleach" the signals. The signals are still useful for connection management as long as a large enough fraction of the connections are not bleached.

I think that solving the "practicality" issue requires moving the signal to the IP layer. The experiments by Orange show that you only need a small number of bits to monitor latency and loss rate from within the network - 2 or maybe 3 bits would do. If these bits are in the transport header, the network monitor has first to find out what transport protocol is in use, and possibly what version. With encrypted transports, that could soon become a daunting task. On the other hand, if the bits are at some fixed position in the IP header, monitoring becomes much simpler.

My personal preference would be to associate these bits with an IPv6 "flow" label, or for IPv4 the five-tuple. Latency is associated with routing and with applications, and in theory all packets in a flow share the same routing and the same kind of end-to-end processing. Of course, there are deployment issues, bleaching issues, etc. But the logic remains: associating latency and loss measurement with a packet flow makes the most sense. Moving that to the IP header also makes sense -- after all, it is very similar to ECN signals. The broad line of the solution would thus be:

1) Steal a couple of end to end bits, or maybe just 4 to 8 Diffserv code points

2) Use these bits to encode the "spin" and "loss" indications, and distinguish them from the "bleached" signal

3) Compute the "spin" and "loss" indications per end-to-end flow, and make that part of the spec.

There are obvious deployment issue, bleaching paths and all that. But at the same time, the information is meant to benefit network management, so there will be a strong incentive for network managers to ensure that it flows freely. Thus, it is not hopeless.

-- Christian Huitema