Interdomain UX troubleshooting

[emile22]

Fast troubleshooting of QoS is mandatory to maintain end users high Quality of Experience;
There are my cases of troubleshooting. A typical example starts by the signaling to the ISP that its end-users are experimenting a significant decrease of QoE when using an Internet application. Typical point of failures are line cards memory errors or overloaded routers located somewhere on the path, either in the ISP domain or outside.

The ISP NOC has to localize asap the point of failure. Currently it proceeds by dichotomy (is the point of failure inside ISP domain or outside ?) using passive monitoring of packet lost and congestion.

Following is the description of the parameters in use:

1. Packet lost downstream (vice versa for upstream):

• Measure of packet lost before the point of measure needs TCP sequence number
• Measure of lost after the point of measure needs TCP ACK + SACK

1. Congestion:

• Detects that the congestion is located either before or after the point of measure
• Analysis based on TCP ACK+SACK observation

QUIC packets numbering should be continuous to allow packet loss monitoring. Flows control fields (ACK, SACK) are available in QUIC but encrypted.

It should be nice to use the approach of the TCPinc WG (with an integrity check mechanism) to keep visible the fields allowing fast troubleshooting of the network layer.

[MikeBishop]

This would directly contradict the existing suggestion to intentionally skip packet numbers in order to detect spoofed ACKs.

[mirjak]

Yes, I would rather use packet numbers for diagnostics, as proposed here and in draft-kuehlewind-quic-appman-00, and use ping to check return routability (see my comment on that in issue #161 ). I find the skipping packet numbers approach anyway not a good solution :-(

[emile22]

How can someone spoof ACKs which are integrity protected ?

[ronieven]

Fast response to QoS and QoE is crucial to network operators, some of the intended usage for HTTP over QUIC is media delivery which may be a paid service. I find that the looking at RTT and packet loss information separably problematic. It would have been better to work on Manageability of QUIC in parallel to the other documents.

[MikeBishop]

This is better addressed in the management drafts, if it's required for v1. @mirjak, can you open an issue for this if you don't think it's already sufficiently addressed?