Subject: about draft-johansson-quic-ecn-00

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 26 Jan 2017 10:40:10 +0100

Hi,

I have read the draft and i think it is a good starting point for this 
issue. thanks for writing it.

My main comment is about the ECN negotiation. I am unconvinced that the 
quic version negotiation is the right approach for this.

I mean, afaiu, quic version negotiation imposes an extra RTT when the 
new version is not supported. I think this is ok for major version 
changes, but I dont think this is appropriate for feature negotiation 
such as ECN.

I mean, unless ECN is supported by default in the first quic version, I 
think using quic version negotiation for  ECN support would be an 
obstacle in ECN adoption in quic. I mean, if we end up in the situation 
that the first (widely deployed) quic protocol specification does not 
support ECN by default, then having ECN negotiation using quic version 
will imply that if a client wants to tries to see if the server supports 
ECN, it risks to have a extra RTT penalty. (i understand the client can 
cache which servers support ECN, but we are back into working around 
these difficulties that make ecn adoption harder).

The other problem is related to the blocking of ECN bits in the IP 
header. Ideally, I guess, the client should be able to learn if the ECN 
bits are blocked during the negotiation phase i.e. the negotiation can 
fail either because the server doesnt support it or because the network 
doesnt support it. Because of this, I would argue that the good approach 
is to have the ECN bits set in the IP header of the packet carrying the 
ECN negotiation.

So, with all this, I think it may be a better approach to make ECN 
negotiation to be done using a new frame type that is sent in the stream 
1. This would be a message that the sender issues, after the connection 
has been established, to request ECN support from the other endpoint. 
This message would be sent in an ECN marked packet, to verify that the 
network delivers the message. The other endpoint can reply with another 
message accepting of not the ECN support for the connection.

I think this approach has the benefit of not imposing extra latency for 
those who want to check if ECN is supported and at the same time 
verifies that the network is able to deliver ECN marked packets. If any 
of these conditions fail, the negotiation fail. Moreover, i think these 
messages can be used to disable ECN in the middle of the connection. One 
case where this can be useful is in a mobility scenario, where one of 
the endpoints move and in order to check if the new path still supports 
ECN, they can resend the option and see if the packets still make it. I 
guess more complicated verification methods could be built into this.

thoughts?

regards, marcelo

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 31 Jan 2017 19:56:15 +0100

I'd also like to thank you for this consideration of where ECN fits 
within QUIC. I have a few comments, see below:

I really do see merit in requiring implementation of the receiver 
functionality. This to me is independent of a decision whether to use 
the ECN functionality at the sender. I’d support it being mandatory to 
implement *at least* basic ECN receiver support (which I think is 
similar to what marcelo said).

draft-ietf-tsvwg-rfc5405bis (now in RFC-ED queue), provides a checklist 
for UDP support for ECN, the current list in the draft seems similar, 
but is not quite the same. I think since rfc5405bis is scheduled for 
BCP, it would be good to cite this and align where possible.

The decision whether a sender chooses to mark using ECT(0) or ECT(1) or 
neither needs to be based on understanding of whether the combined send 
and receive stacks and network devices currently provide support (or 
more likely measurement), monitoring as described in 2.6 (i.e., this is 
a per-path run-time decision). One thing a QUIC  receiver may already 
know is whether a receive stack has support for ECN.

I suggest this places requirements on the feedback method:

A sender may need to understand how the network forwards ECT(x) marks on 
the forward path - (Alt 3 shows some functionality for this).  this can 
confirm whether ECT(x) marks are received. I expect this will be needed 
to know that ECT and ECN-CE marks are actually being sent across the 
entire path, and are not cleared at some midpoint, erasing the 
congestion information.  I think it is also would be useful to know that 
ECT(1) is actually traversing a path when using new ECT(1) semantics as 
described in the tsvwg draft (aka like L4S).

I can see real advantages if  alt-1, alt-2 at least provides a count to 
indicate the number of packets (bytes?) received with not-ECT; ECT(0); 
and ECT(1).

Knowing receive code point information would also provide opportunities 
to detect and react appropriately to misbehaving receivers/paths 
(including sender control to set the mark value) - although at least 
while the path/receiver is being verified the sender will likely also be 
needed to know *which* packets carried a specific mark. (as noted alt-3 
may not provide this). How we should do this, I am not sure - various 
ways exist - but designing a transport that can allow this should be 
possible.

Gorry

On 26/01/2017 10:40, marcelo bagnulo braun wrote:
> My main comment is about the ECN negotiation. I am unconvinced that 
> the quic version negotiation is the right approach for this.
>
> I mean, unless ECN is supported by default in the first quic version, 
> I think using quic version negotiation for  ECN support would be an 
> obstacle in ECN adoption in quic. I mean, if we end up in the 
> situation that the first (widely deployed) quic protocol specification 
> does not support ECN by default, then having ECN negotiation using 
> quic version will imply that if a client wants to tries to see if the 
> server supports ECN, it risks to have a extra RTT penalty. (i 
> understand the client can cache which servers support ECN, but we are 
> back into working around these difficulties that make ecn adoption 
> harder).
>
> header. Ideally, I guess, the client should be able to learn if the 
> ECN bits are blocked during the negotiation phase i.e. the negotiation 
> can fail either because the server doesnt support it or because the 
> network doesnt support it. Because of this, I would argue that the 
> good approach is to have the ECN bits set in the IP header of the 
> packet carrying the ECN negotiation.
>
> negotiation to be done using a new frame type that is sent in the 
> stream 1. This would be a message that the sender issues, after the 
> connection has been established, to request ECN support from the other 
> endpoint. This message would be sent in an ECN marked packet, to 
> verify that the network delivers the message. The other endpoint can 
> reply with another message accepting of not the ECN support for the 
> connection.
>
> I think this approach has the benefit of not imposing extra latency 
> for those who want to check if ECN is supported and at the same time 
> verifies that the network is able to deliver ECN marked packets. If 
> any of these conditions fail, the negotiation fail. Moreover, i think 
> these messages can be used to disable ECN in the middle of the 
> connection. One case where this can be useful is in a mobility 
> scenario, where one of the endpoints move and in order to check if the 
> new path still supports ECN, they can resend the option and see if the 
> packets still make it. I guess more complicated verification methods 
> could be built into this.
>
> thoughts?
>
> regards, marcelo
>