Subject: soliciting feedback on draft-abilash-quic-network

From: "Ritesh Mukherjee" <[email-masked]>
Date: Thu, 5 Jan 2017 10:34:40 -0500

Hi Team,

We recently published draft-abilash-quic-network-00 which proposes a change
to the QUIC protocol header that will allow network elements to prioritize
streams in QUIC packets, divert high priority streams to low loss paths, and
adjust packet pacing on a per stream basis. We have already received some
very positive comments from some members but wanted to solicit feedback from
the larger community. Please provide your comments/feedback/recommendations
as necessary: 

URL:
https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

Thank you in advance!

Ritesh

---

From: Patrick McManus <[email-masked]>
Date: Thu, 5 Jan 2017 11:02:48 -0500

Ritesh - thanks for taking the time to write your thoughts down and sharing
them.

The draft calls for removing encryption of the stream ID and also adding a
priority system at the transport level that's less expressive than the h2
one quic has to carry - (also unencrypted).

The quic charter calls for " a UDP-based, stream-multiplexing, encrypted
transport protocol". and "provide confidentiality [..] of both application
data and QUIC header.".

Further, draft-abilash's security considerations are effectively empty,
which makes me doubt things like traffic analysis, etc have been considered.

This doesn't sound like the mentioned draft should be used for changes in
the protocol, though it may provide useful input to the applicability and
manageability statement.

-Patrick

On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee <
[email-masked]> wrote:

> Hi Team,
>
>
>
> We recently published draft-abilash-quic-network-00 which proposes a
> change to the QUIC protocol header that will allow network elements to
> prioritize streams in QUIC packets, divert high priority streams to low
> loss paths, and adjust packet pacing on a per stream basis. We have already
> received some very positive comments from some members but wanted to
> solicit feedback from the larger community. Please provide your
> comments/feedback/recommendations as necessary:
>
>
>
> URL:            https://www.ietf.org/internet-drafts/draft-abilash-quic-
> network-00.txt
>

---

From: "Ritesh Mukherjee" <[email-masked]>
Date: Thu, 5 Jan 2017 11:50:13 -0500

Hi Patrick,

Please see inline…..

Ritesh

From: Patrick McManus [mailto:[email-masked]] 
Sent: Thursday, January 5, 2017 11:03 AM
To: Ritesh Mukherjee <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: soliciting feedback on draft-abilash-quic-network

Ritesh - thanks for taking the time to write your thoughts down and sharing them.

The draft calls for removing encryption of the stream ID and also adding a priority system at the transport level that's less expressive than the h2 one quic has to carry - (also unencrypted).

[Ritesh] The stream ID and priority are authenticated. Yes – they need to be unencrypted for the network elements to optimize performance.

The quic charter calls for " a UDP-based, stream-multiplexing, encrypted transport protocol". and "provide confidentiality [..] of both application data and QUIC header.".

[Ritesh] The entire statement says “describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers.”. The charter does not mandate not exposing any element of the QUIC header even if it would improve performance.

Further, draft-abilash's security considerations are effectively empty, which makes me doubt things like traffic analysis, etc have been considered.

[Ritesh] Agreed. It is work in progress. We have done testing and analysis. We will update it in the next iteration and suggestions are always welcome.  

This doesn't sound like the mentioned draft should be used for changes in the protocol, though it may provide useful input to the applicability and manageability statement.

[Ritesh] We are open to all suggestions. Our current thinking is that this should be an option in future implementations.  

-Patrick

On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee <[email-masked] <mailto:[email-masked]> > wrote:

Hi Team,

We recently published draft-abilash-quic-network-00 which proposes a change to the QUIC protocol header that will allow network elements to prioritize streams in QUIC packets, divert high priority streams to low loss paths, and adjust packet pacing on a per stream basis. We have already received some very positive comments from some members but wanted to solicit feedback from the larger community. Please provide your comments/feedback/recommendations as necessary: 

URL:            https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Thank you in advance!

Ritesh

---

From: Abilash Menon <[email-masked]>
Date: Thu, 5 Jan 2017 13:20:08 -0500

Patrick,

More replies inline <amenon>

> On Jan 5, 2017, at 11:50 AM, Ritesh Mukherjee <[email-masked]> wrote:
> 
> Hi Patrick,
>  
> Please see inline…..
>  
> Ritesh
>  
>   <>
> From: Patrick McManus [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Ritesh Mukherjee <[email-masked] <mailto:[email-masked]>>
> Cc: IETF QUIC WG <[email-masked] <mailto:[email-masked]>>

<amenon> We would like to understand your concerns as to why this would be a problem.. The draft calls for exposing some fields in the header so that QUIC can benefit from the network. These could be made optional for clients which do not want to avail any network performance enhancements.

> Further, draft-abilash's security considerations are effectively empty, which makes me doubt things like traffic analysis, etc have been considered
> 
> 
> 

<amenon> Yes. We will update the draft with more details. Please let us know if there are some specific cases you would like us to address.

> This doesn't sound like the mentioned draft should be used for changes in the protocol, though it may provide useful input to the applicability and manageability statement.
<amenon> Please let us know your concerns and we can work through them. We strongly feel this will be useful to prioritize QUIC traffic more effectively in the network elements. This would be a way to bring application layer information into the network layer for more intelligent traffic engineering and prioritization.

Thanks,
Abilash

> On Thu, Jan 5, 2017 at 10:34 AM, Ritesh Mukherjee <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Team,
>>  
>> URL:            https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt <https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt>
>> Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00 <https://tools.ietf.org/html/draft-abilash-quic-network-00>
>>  
>> Thank you in advance!
>>  
>> Ritesh
>>  
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 5 Jan 2017 11:40:55 -0800

> We recently published draft-abilash-quic-network-00 which proposes a
change 
> to the QUIC protocol header that will allow network elements to prioritize
streams
> in QUIC packets, divert high priority streams to low loss paths, and
adjust packet 
> pacing on a per stream basis. We have already received some very positive
comments
> from some members but wanted to solicit feedback from the larger
community. Please
> provide your comments/feedback/recommendations as necessary: 
>
> URL:           
> Htmlized:       https://tools.ietf.org/html/draft-abilash-quic-network-00

I have read your draft, and do not believe it should be adopted by the
working group at this point. First, we should be extremely cautious about
adding any information in the public header, because of well documented
issues such as middlebox interference or ossification. In particular, there
is a long history of middle boxes doing strange things with anything that
pretends to be a priority field. Also, the connection control pretty much
assumes a single flow of packets forwarded with equal priorities. You just
cannot assume the interaction between priorities and error connection would
be beneficial. 

The quoted motivation for your draft is a research paper published last May,
"How quick is QUIC"
(https://www.researchgate.net/publication/302585207_How_quick_is_QUIC). The
simulations reported in this paper show QUIC being generally more efficient
than HTTP or SPDY, except in one set of conditions: high bandwidth, large
proportion of large objects, and very low packet loss rate. It is unclear
whether that conclusion depends on the QUIC protocol, or on implementation
parameters used in the simulation. The authors attribute it to "the packet
pacing mechanism in QUIC", which would be too conservative and would unduly
slow down the transmissions. 

Your draft quotes that same study as [MEG2016], but comes with its own
explanation of the issue, "This is because QUIC is an end to end protocol
and provides no means for the intermediate network elements to contribute to
QUIC improvements." There is no mention of such explanation in [MEG2016],
which leads me to believe that your statement is just a personal opinion,
not based on any published study. 

In short, I believe that the technical solution that you propose is not
justified by any study. It would add complexity in the protocol without any
proven benefit. It would risk serious interoperability issues, and would
greatly increase the risk of middle box interference. I don't see why the WG
would work on that.

-- Christian Huitema

---

From: Ted Hardie <[email-masked]>
Date: Thu, 5 Jan 2017 11:57:08 -0800

Howdy,

Forgive the top posting, but this seems to be a bit of meta-question.  If I
read your draft correctly, you are suggesting that QUIC expose stream
identifiers and associate them with a priority, so that on-path devices may
move certain streams onto higher priority paths or otherwise give variable
quality of service.

For this to work correctly, though, the basic aim of multiplexing seems to
be changed as you could not multiplex streams into the same packet, even if
they have the same desired network treatment.  At that level of isolation,
independent QUIC connections may suit your use cases just as well (if,
indeed, you would choose QUIC at all).  If that is the required level of
independence, why does opening different connections not work as well?

It's also not clear why you need that level of independence. At the very
least, your description makes it seem that you could multiplex streams
whose desired network treatment is the same.  And, if you did multiplex
streams with the same desired network treatment, there seems to be no need
at all to expose the stream identifiers (after all, you might have more
than one stream in a packet).  Instead, you would only need to expose the
desired network treatment for a specific packet.  Why is that not enough to
meet the need and why, if that is the case, would differentiated DSCP
markings not meet your needs?

On the latter case, there was good bit of discussion on how well multiple
DSCP markings on a single 5-tuple would work in the context of WEBRTC; if
you have not read RFC 7657, I would suggest doing so, along with
draft-ietf-tsvwg-rtcweb-qos.  Though pointing primarily at RTP flows
multiplexed using BUNDLE, I suspect many of the lessons learned would apply
to your efforts, whether you used DSCP or a different marking.

regards,

Ted

---

From: Patrick McManus <[email-masked]>
Date: Thu, 5 Jan 2017 15:31:22 -0500

Hey All,

My high level comment is that (from the abstract of the transport ID) "QUIC
encrypts most of its headers, thereby limiting protocol evolution to QUIC
endpoints only. Therefore, middleboxes, in large part, are not required to
be updated as new protocol versions are deployed".

unencrypting data in order to have middleboxes be updated for new protocol
versions (and their options!) is really an anti-goal of this work. This is
for both protocol evolution and application confidentiality.

This is a strong end to end design decision - if you think the value of a
transport protocol instead comes from network signaling you're going to
disagree with a number of design decisions. The open questions are often
about how _more_ confidentiality and integrity can be created (i.e. is it
feasible to make the connection identifier less trackable, and how a public
reset can be made less public (or if its even needed at all)) - the public
stream id proposal blows against that headwind.

Others have made interesting comments about the relationship between frames
and packets and there are at least 2 github issues open on priority and
retransmission - Christian also makes a good comment in this thread about
congestion control and its embedded assumptions. Making these elements
opaque to the network lets the transport protocol come to a consistent
internal resolution to these questions without depending on path behavior
which is aligned with the goal in my first paragraph.

hth explain my thoughts. Again, thanks for taking the time to write it
down. I know that can feel thankless, but it really helps everyone
understand crisply what is being discussed and I sincerely appreciate it.

-Patrick

On Thu, Jan 5, 2017 at 1:20 PM, Abilash Menon <[email-masked]>
wrote:

> *From:* Patrick McManus [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, January 5, 2017 11:03 AM
> *To:* Ritesh Mukherjee <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>
> *Subject:* Re: soliciting feedback on draft-abilash-quic-network
>
> [Ritesh] The stream ID and priority are authenticated. Yes – they need to
> be unencrypted for the network elements to optimize performance.
>
> [Ritesh] The entire statement says “describe how those keys are used to
> provide confidentiality and integrity protection of both application data
> and QUIC headers.”. The charter does not mandate not exposing any element
> of the QUIC header even if it would improve performance.
>
>
> <amenon> We would like to understand your concerns as to why this would be
> a problem.. The draft calls for exposing some fields in the header so that
> QUIC can benefit from the network. These could be made optional for clients
> which do not want to avail any network performance enhancements.
>
> which makes me doubt things like traffic analysis, etc have been considered
>
>
> [Ritesh] Agreed. It is work in progress. We have done testing and
> analysis. We will update it in the next iteration and suggestions are
> always welcome.
>
>
> <amenon> Yes. We will update the draft with more details. Please let us
> know if there are some specific cases you would like us to address.
>
>
> <amenon> Please let us know your concerns and we can work through them. We
> strongly feel this will be useful to prioritize QUIC traffic more
> effectively in the network elements. This would be a way to bring
> application layer information into the network layer for more intelligent
> traffic engineering and prioritization.
>
> Thanks,
> Abilash
>
> [Ritesh] We are open to all suggestions. Our current thinking is that this
> should be an option in future implementations.
>
> -Patrick
>
>

---

From: Abilash Menon <[email-masked]>
Date: Thu, 5 Jan 2017 17:37:26 -0500

Christian,

Thanks for reviewing the draft. Please see replies below :

> On Jan 5, 2017, at 2:40 PM, Christian Huitema <[email-masked]> wrote:
> 

We were approaching QUIC from a  different perspective, where if the network could assist QUIC protocol and also provide feedback, it would enable the client to make more intelligent decisions.  The QUIC connection currently assumes a single connection, but our proposal would provide an option to prioritize the streams within QUIC. For eg: lets say the web page needs to display real content and advertisement on the side. The content could be given a higher priority and the advertisement  could be given a lower priority. In the network, especially in SD-WAN(Software-Defined Wide Area Network) multiple paths would be available  - a path with higher quality and one with lower quality. The priority helps to multiplex the streams between these 2 paths.

The stream ids would let the edge boxes break one QUIC session into multiple sub sessions. A per stream state machine can be added on the edge boxes which can provide security and enables  the client to run a per stream congestion algorithm instead of one for the whole connection. 

> not based on any published study. 

If you take the packet pacing for instance, if packets are dropped for the connection with N streams, the packet pacing could increase the latency. But for a case where the network could multiplex a QUIC packet into multiple streams, the packet pacing can be done a per stream basis that way not affecting packets on other streams.

> justified by any study.

Our proposal is based on the data we have gleaned from different network conditions and deployment of existing protocols, but not from running QUIC protocol with this proposed change itself.  Please let us know if there are some specific results you would like to see and we could run some experiments and provide them. 

> It would add complexity in the protocol without any

Thanks again for your feedback. We understand that this calls for a change in the protocol header. But this would allow the network and the application to make smarter decisions. We can run some experiments and get you some results.

Thanks,
Abilash

---

From: Abilash Menon <[email-masked]>
Date: Thu, 5 Jan 2017 18:38:03 -0500

Hey Ted,

Thanks for your feedback. Please see replies inline :

> On Jan 5, 2017, at 2:57 PM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> Forgive the top posting, but this seems to be a bit of meta-question.  If I read your draft correctly, you are suggesting that QUIC expose stream identifiers and associate them with a priority, so that on-path devices may move certain streams onto higher priority paths or otherwise give variable quality of service.

That is one use case yes. The on-path devices can provide quality of services on a per stream basis. 

> 
> For this to work correctly, though, the basic aim of multiplexing seems to be changed as you could not multiplex streams into the same packet, even if they have the same desired network treatment.  At that level of isolation, independent QUIC connections may suit your use cases just as well (if, indeed, you would choose QUIC at all).  If that is the required level of independence, why does opening different connections not work as well?

Using stream1, the connection gets established and the headers get exchanged using stream 3. Opening multiple connections would incur more latency for the connection setup. So with one QUIC connection, multiple streams can leverage the same connection without taking the hit of the connection establishment latency for each stream.

> 
> It's also not clear why you need that level of independence. At the very least, your description makes it seem that you could multiplex streams whose desired network treatment is the same.  And, if you did multiplex streams with the same desired network treatment, there seems to be no need at all to expose the stream identifiers (after all, you might have more than one stream in a packet).

Stream id being exposed would help build QUIC state machine in the network elements for each stream as mentioned in the draft. The packet pacing mechanism will also benefit from this as it can be done a per stream basis and not for the whole connection. 

>   Instead, you would only need to expose the desired network treatment for a specific packet.  Why is that not enough to meet the need and why, if that is the case, would differentiated DSCP markings not meet your needs?

Yes. Network treatment of a packet (priority) is definitely needed. Stream id being exposed would help build QUIC state machine in the network elements for each stream as mentioned in the draft. The packet pacing mechanism will also benefit from this as it can be done a per stream basis and not for the whole connection. Also, the stream priority would be used to send among multiple paths in multi path case. 

> 
> On the latter case, there was good bit of discussion on how well multiple DSCP markings on a single 5-tuple would work in the context of WEBRTC; if you have not read RFC 7657, I would suggest doing so, along with draft-ietf-tsvwg-rtcweb-qos. 

DSCP may not always guarantee the quality of service as it could be remarked by the routers in between. It also depends on other factors within the router eg: burst,  packet rate etc . So the application priority can get lost.  Based on the QUIC stream priority, network elements could remark the DSCP value to take a better path. We are not proposing any remarking of the QUIC stream priority, but that it will remain the same. We can add authentication to make sure the fields are in tact. Also in DSCP case a single flow will usually be given the same priority. In this case, the single flow/session can be given different priorities on a per stream basis.

Thanks,
Abilash

> Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect many of the lessons learned would apply to your efforts, whether you used DSCP or a different marking.
> 
> regards,
> 
> Ted
> 
> 
> 
> On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Team,
> 
>  
>

---

From: Abilash Menon <[email-masked]>
Date: Thu, 5 Jan 2017 19:08:00 -0500

Patrick,

> On Jan 5, 2017, at 3:31 PM, Patrick McManus <[email-masked]> wrote:
> 
> Hey All,
> 
> My high level comment is that (from the abstract of the transport ID) "QUIC encrypts most of its headers, thereby limiting protocol evolution to QUIC endpoints only. Therefore, middleboxes, in large part, are not required to be updated as new protocol versions are deployed". 
> 
> unencrypting data in order to have middleboxes be updated for new protocol versions (and their options!) is really an anti-goal of this work. This is for both protocol evolution and application confidentiality.

Sure.  We understand the sentiment. Our goal was to see how QUIC could be provided more assistance from the network. Priority plays a big role in classifying the streams and the stream id for providing better feedback and state machine establishment. As for protocol evolution, as long as its a tlv format and has backward compatibility, it should not be an issue. This could be a separate header section just for network elements and optional. We can add capability flags for the same. Would this be something you would be open to  - an optional header.

We are viewing QUIC as something that will eventually replace TCP for a lot of applications. We currently can parse the TCP packet and have state machines implemented for it in our network elements. Unfortunately there is no priority set by each packet.  Also stream id, would provide better analytics on the network on a per connection basis. 

> 
> This is a strong end to end design decision - if you think the value of a transport protocol instead comes from network signaling you're going to disagree with a number of design decisions. The open questions are often about how _more_ confidentiality and integrity can be created (i.e. is it feasible to make the connection identifier less trackable, and how a public reset can be made less public (or if its even needed at all)) - the public stream id proposal blows against that headwind.

Interesting.  The session could still be identified using the 5 tuple for sure.  But looks like the approach is to hide everything possible for security reasons. Are there no thoughts on getting network assistance where possible ? What about priority per packet. Is that a cause for concern as well. The protocol can get feedback as well as assistance from the network.

> 
> Others have made interesting comments about the relationship between frames and packets and there are at least 2 github issues open on priority and retransmission - Christian also makes a good comment in this thread about congestion control and its embedded assumptions. Making these elements opaque to the network lets the transport protocol come to a consistent internal resolution to these questions without depending on path behavior which is aligned with the goal in my first paragraph.
> 
> hth explain my thoughts. Again, thanks for taking the time to write it down. I know that can feel thankless, but it really helps everyone understand crisply what is being discussed and I sincerely appreciate it.

Thank you again for taking the time to go through your different concerns.  We would like to follow up on this and see if the group is open to an optional network header element and priority. This way only clients can choose to avail this assistance if needed. This would be a good use-case in SD-WAN scenarios.

Thanks,
Abilash

> 
> -Patrick
> 
> 
> On Thu, Jan 5, 2017 at 1:20 PM, Abilash Menon <[email-masked] <mailto:[email-masked]>> wrote:
> Patrick,
> 
>> On Jan 5, 2017, at 11:50 AM, Ritesh Mukherjee <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Patrick,
>>  
>> Please see inline…..
>>  
>> Ritesh
>>  
>>   <>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 5 Jan 2017 16:08:43 -0800

Reply in-line.

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <[email-masked]>
wrote:

> Forgive the top posting, but this seems to be a bit of meta-question.  If
> I read your draft correctly, you are suggesting that QUIC expose stream
> Using stream1, the connection gets established and the headers get
> exchanged using stream 3. Opening multiple connections would incur more
> latency for the connection setup. So with one QUIC connection, multiple
> streams can leverage the same connection without taking the hit of the
> connection establishment latency for each stream.
>

With 0RTT, this is probably not an issue for a long-lived flows, and it has
to be compared to the cost for application mechanics to make sure that each
packet contains elements from only a single stream.  For a multiplexing
protocol, the latter seems fundamentally sub-optimal.

> than one stream in a packet).
>
>
> Stream id being exposed would help build QUIC state machine in the network
> elements for each stream as mentioned in the draft. The packet pacing
> mechanism will also benefit from this as it can be done a per stream basis
> and not for the whole connection.
>
>
So, "building the QUIC state machine in the network elements" doesn't mean
much absent a knowledge of what those network elements are going to do with
the state.  The use case that you mentioned originally, path selection for
network treatment, doesn't actually require that the on-path elements
distinguish among streams that require like treatment.  It simply requires
that the requested network treatment be visible.  Given that multiplexing
streams that require like network treatment works with the multiplexed
design of QUIC, I'm still unclear why you want to insist on such a strict
independence.

  Instead, you would only need to expose the desired network treatment for
> a specific packet.  Why is that not enough to meet the need and why, if
> that is the case, would differentiated DSCP markings not meet your needs?
>
>
> Yes. Network treatment of a packet (priority) is definitely needed. Stream
> id being exposed would help build QUIC state machine in the network
> elements for each stream as mentioned in the draft. The packet pacing
> mechanism will also benefit from this as it can be done a per stream basis
> and not for the whole connection.
>

Your draft says this:

   However, session aware routers will have a flow per
   stream.  Hence the packet rate can be adjusted on a per stream basis
   and not for the whole connection.

Once again, this seems to run counter to the design of a multiplexed
protocol, and the description in the document is a bit circular.  A session
aware router certainly would not have a flow per stream as QUIC is designed
now; it would have no way to create such a flow.  You are motivating the
change in QUIC in order to achieve that for session aware routers, but
without addressing the loss of other basic QUIC design features.

> Also, the stream priority would be used to send among multiple paths in
> multi path case.
>
>

> draft-ietf-tsvwg-rtcweb-qos.
>
>
> DSCP may not always guarantee the quality of service as it could be
> remarked by the routers in between. It also depends on other factors within
> the router eg: burst,  packet rate etc . So the application priority can
> get lost.  Based on the QUIC stream priority, network elements could remark
> the DSCP value to take a better path.
>

So, I recommended you look at the document because it treats the problem of
having a single five(or six)-tuple flow have different markings.
Evidently, your basic answer is to replace the current flow-state
management with a different view of the flow ("session"), using the stream
id as a demultiplexing signal.  You then wish to have a marking for the
session.

One of the design goals of QUIC is that it be deployable on the Internet as
it exists, rather than relying on features which must be introduced into
the network to support it.  This effort seems to run counter to that design
goal as well.

> We are not proposing any remarking of the QUIC stream priority, but that
> it will remain the same. We can add authentication to make sure the fields
> are in tact. Also in DSCP case a single flow will usually be given the same
> priority. In this case, the single flow/session can be given different
> priorities on a per stream basis.
>
>
Of course, there is a potential silly state here if the session-state aware
network elements do something on one signal and their non-session-state
peers act on a different signal; at best, you'd have to scrub and re-mark
to avoid that.  Given that, I fail to see why the multiple-markings within
a flow approach of RFC 7657 doesn't work at least as well, at least for the
Internet as currently deployed.

regards,

Ted

> Thanks,
> Abilash
>
>
> Though pointing primarily at RTP flows multiplexed using BUNDLE, I suspect
> many of the lessons learned would apply to your efforts, whether you used
> DSCP or a different marking.
>
>
> regards,
>
> Ted
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 5 Jan 2017 19:52:39 -0800

Hi,

Thanks for writing up the draft -- as Patrick notes, it's helpful to have
something concrete to discuss.

I have a number of thoughts as I catch up on this thread, but I have a
high-order one: have you considered proposing this draft for HTTP/2? Given
that the use of streams is basically the same for HTTP/2 and HTTP over
QUIC, I would expect that signaling stream IDs and priorities for HTTP/2
should be similar. Why not propose it for HTTP/2?

There are a significant number of engineering issues with doing priorities
per stream, the most significant one being the one that Christian points
out: that congestion control and loss detection will need to be per-stream,
defeating a major rationale for stream multiplexing. That is a
show-stopper, in my opinion. You'd have the same troubles with TCP and
HTTP/2.

I don't think prioritizing streams by network elements makes good
engineering sense.

- jana

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <[email-masked]> wrote:

>> For this to work correctly, though, the basic aim of multiplexing seems
>> to be changed as you could not multiplex streams into the same packet, even
>> if they have the same desired network treatment.  At that level of
>> isolation, independent QUIC connections may suit your use cases just as
>> well (if, indeed, you would choose QUIC at all).  If that is the required
>> level of independence, why does opening different connections not work as
>> well?
>>
>>
> With 0RTT, this is probably not an issue for a long-lived flows, and it
> has to be compared to the cost for application mechanics to make sure that
> each packet contains elements from only a single stream.  For a
> multiplexing protocol, the latter seems fundamentally sub-optimal.
>
>
>>
>>
>> Stream id being exposed would help build QUIC state machine in the
>> network elements for each stream as mentioned in the draft. The packet
>> pacing mechanism will also benefit from this as it can be done a per stream
>> basis and not for the whole connection.
>>
>>
>> Yes. Network treatment of a packet (priority) is definitely needed.
> So, I recommended you look at the document because it treats the problem
> of having a single five(or six)-tuple flow have different markings.
> One of the design goals of QUIC is that it be deployable on the Internet
> as it exists, rather than relying on features which must be introduced into
> Of course, there is a potential silly state here if the session-state
> aware network elements do something on one signal and their
> non-session-state peers act on a different signal; at best, you'd have to
> scrub and re-mark to avoid that.  Given that, I fail to see why the
> multiple-markings within a flow approach of RFC 7657 doesn't work at least
> as well, at least for the Internet as currently deployed.
>
> regards,
>
> Ted
>
>
>> Thanks,
>> Abilash
>>
>>
>> Though pointing primarily at RTP flows multiplexed using BUNDLE, I
>> suspect many of the lessons learned would apply to your efforts, whether
>> you used DSCP or a different marking.
>>
>>
>> regards,
>>
>> Ted
>>
>>
>>

---

From: <[email-masked]>
Date: Fri, 6 Jan 2017 08:37:44 +0000

Dear Ritesh,

Thank you for sharing this draft.

I appreciate the idea of exposing more information in the public QUIC header for network-assistance purposes. I see this effort as a contribution to this charter text:

==
Current practices for network management of transport protocols
include the ability to apply access control lists (ACLs), hashing of
flows for equal-cost multipath routing (ECMP), directional signaling
of flows, signaling of flow setup and teardown, and the ability to
export information about flows for accounting purposes. The QUIC
protocol need not be defined to enable each of these abilities, or
enable them in the same way as they are enabled by TCP when used
with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, reflecting the tensions
described in RFC 7258.
==

I understand this is a -00. More discussion is required to justify to what extent the proposed priority field and moving the stream ID to the public header will be of help.

Thank you for initiating this work.

Cheers,
Med

De : QUIC [mailto:[email-masked]] De la part de Ritesh Mukherjee
Envoyé : jeudi 5 janvier 2017 16:35
À : [email-masked]
Objet : soliciting feedback on draft-abilash-quic-network

Hi Team,

Thank you in advance!

Ritesh

---

From: Abilash Menon <[email-masked]>
Date: Fri, 6 Jan 2017 08:00:03 -0500

Ted,

> On Jan 5, 2017, at 7:08 PM, Ted Hardie <[email-masked]> wrote:
> 
> Reply in-line.
> 
> On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <[email-masked] <mailto:[email-masked]>> wrote:
> Hey Ted,
> 
>> On Jan 5, 2017, at 2:57 PM, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Howdy,
>> 
> With 0RTT, this is probably not an issue for a long-lived flows, and it has to be compared to the cost for application mechanics to make sure that each packet contains elements from only a single stream.  For a multiplexing protocol, the latter seems fundamentally sub-optimal.

Sure. I agree for long lived flows. I am not sure if the use case for QUIC is going to be limited to the current applications or will be extended going forward. Our idea was to get application view of the network on a per stream basis - provides better debugging , analytics and any protocol specific assistance that could be provided. Yes the details of the latter are important I understand.

> So, "building the QUIC state machine in the network elements" doesn't mean much absent a knowledge of what those network elements are going to do with the state.  The use case that you mentioned originally, path selection for network treatment, doesn't actually require that the on-path elements distinguish among streams that require like treatment.  It simply requires that the requested network treatment be visible.  Given that multiplexing streams that require like network treatment works with the multiplexed design of QUIC, I'm still unclear why you want to insist on such a strict independence.

Sure. The state machine can help implement some security features, ensure the client and server are following the protocol specifics and can also implement rate limit per stream. The idea here was to get this started and going forward work with the charter to continue to improve on this. Yes - the network treatment being visible would solve the prioritization. 

> Yes. Network treatment of a packet (priority) is definitely needed. Stream id being exposed would help build QUIC state machine in the network elements for each stream as mentioned in the draft. The packet pacing mechanism will also benefit from this as it can be done a per stream basis and not for the whole connection.
> 
> Your draft says this:
> 
> Once again, this seems to run counter to the design of a multiplexed protocol, and the description in the document is a bit circular.  A session aware router certainly would not have a flow per stream as QUIC is designed now; it would have no way to create such a flow.  You are motivating the change in QUIC in order to achieve that for session aware routers, but without addressing the loss of other basic QUIC design features.

Sorry that may have been confusing.. Yes the current routers have no way to do that. The statement assumes that the fields have been exposed. Yes - our motivation is to have submissions for every QUIC sessions that can be seen in network elements.

>  
> Also, the stream priority would be used to send among multiple paths in multi path case. 
> 
> 
>  
>> 
> DSCP may not always guarantee the quality of service as it could be remarked by the routers in between. It also depends on other factors within the router eg: burst,  packet rate etc . So the application priority can get lost.  Based on the QUIC stream priority, network elements could remark the DSCP value to take a better path.
> 
> So, I recommended you look at the document because it treats the problem of having a single five(or six)-tuple flow have different markings.  Evidently, your basic answer is to replace the current flow-state management with a different view of the flow ("session"), using the stream id as a demultiplexing signal.  You then wish to have a marking for the session.  

Sure. Will take a look at the document.

> 
> One of the design goals of QUIC is that it be deployable on the Internet as it exists, rather than relying on features which must be introduced into the network to support it.  This effort seems to run counter to that design goal as well.

Ofcourse. The design goal makes sense - else the protocol cannot evolve at all ! Our proposal is an optional feature which could be used if the network elements can support it.

>  
> We are not proposing any remarking of the QUIC stream priority, but that it will remain the same. We can add authentication to make sure the fields are in tact. Also in DSCP case a single flow will usually be given the same priority. In this case, the single flow/session can be given different priorities on a per stream basis.
> 
> 
> Of course, there is a potential silly state here if the session-state aware network elements do something on one signal and their non-session-state peers act on a different signal; at best, you'd have to scrub and re-mark to avoid that.  Given that, I fail to see why the multiple-markings within a flow approach of RFC 7657 doesn't work at least as well, at least for the Internet as currently deployed.

Things could be made to work - I need to read the RFC. But our view is that any application traffic could be assisted by the network elements.  Aforementioned,  this would help with analytics, debugging etc. Applications could be written with network in mind giving more granular control.(not just the priority). Ff there are network elements that support it, the applications can make use of it. I understand your concerns as we don’t have results to back this for QUIC.

Thanks
Abilash

---

From: Abilash Menon <[email-masked]>
Date: Fri, 6 Jan 2017 08:16:49 -0500

Jana,

Thank you for reviewing. Please see inline :

> On Jan 5, 2017, at 10:52 PM, Jana Iyengar <[email-masked]> wrote:
> 
> Hi,
> 
> Thanks for writing up the draft -- as Patrick notes, it's helpful to have something concrete to discuss.
> 
> I have a number of thoughts as I catch up on this thread, but I have a high-order one: have you considered proposing this draft for HTTP/2? Given that the use of streams is basically the same for HTTP/2 and HTTP over QUIC, I would expect that signaling stream IDs and priorities for HTTP/2 should be similar. Why not propose it for HTTP/2?

We did not consider that, but we certainly could. Thank you for the suggestion.

> 
> There are a significant number of engineering issues with doing priorities per stream, the most significant one being the one that Christian points out: that congestion control and loss detection will need to be per-stream, defeating a major rationale for stream multiplexing. That is a show-stopper, in my opinion. You'd have the same troubles with TCP and HTTP/2.

So if you consider packet pacing with multiple streams, the latency of one stream need not be affected by another if one specific stream gets affected. Yes this would need per stream congestion control - it looks like you done want to have that granular control here. So is there any network assistance you would like the protocol to get if the network elements can support it. If so , please let us know - we would like to understand. 

> 
> I don't think prioritizing streams by network elements makes good engineering sense.

Prioritization could certainly help streams. That could use the RFC7657 which Ted had mentioned, but our approach was to leverage the QUIC protocol itself to use priority and get more granular view of the network using stream ids. We will see if we can get some useful results.

Thanks,
Abilash

> 
> - jana
> 
> 
> On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
> Reply in-line.
>

---

From: Lin Han <[email-masked]>
Date: Mon, 9 Jan 2017 20:15:18 +0000

Hi, Abilash

I have a question which might be related to this topic.

>From the point of view of network device, we want to know and also wish that the QUIC could support the signaling for the network device along the path.
This is for the QoS enhancement consideration in the future. Marking priority is not enough for provisioning a device.
The lesson from TCP is its rigidity for the extension. It would be nice that QUIC has such elastic from the beginning of the design.

Thanks

Lin

From: QUIC [mailto:[email-masked]] On Behalf Of Abilash Menon
Sent: Friday, January 06, 2017 5:17 AM
To: Jana Iyengar
Cc: Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on draft-abilash-quic-network

Jana,

On Jan 5, 2017, at 10:52 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks,
Abilash

- jana

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:
Reply in-line.

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon <[email-masked]<mailto:[email-masked]>> wrote:
Hey Ted,

On Jan 5, 2017, at 2:57 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

Howdy,

Your draft says this:

Thanks,
Abilash

regards,
Ted

On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee <[email-masked]<mailto:[email-masked]>> wrote:
Hi Team,

Thank you in advance!

Ritesh

---

From: Abilash Menon <[email-masked]>
Date: Mon, 9 Jan 2017 17:05:08 -0500

Lin,

We had suggested priority and streamed as a starting point to get more network aware details from the application. When you say signaling - are you indicating signaling to setup the network elements to start looking for QUIC packets or for something else. Please clarify.

Thanks,
Abilash

> On Jan 9, 2017, at 3:15 PM, Lin Han <[email-masked]> wrote:
> 
> Hi, Abilash
>  
> On Jan 5, 2017, at 10:52 PM, Jana Iyengar <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
>

---

From: Ian Swett <[email-masked]>
Date: Tue, 10 Jan 2017 07:33:19 -0800

I have many of the same concerns expressed above, but one specific element
of this proposal would appear to be a clear violation of the charter, which
is exposing stream ids and priorities.

The charter says: "This work will ensure that QUIC has security and
privacy properties
that are at least as good as a stack composed of TLS 1.3  using TCP"

HTTP/2 over TLS 1.3 does not expose these, and so as Jana mentioned, you'd
have to convince the HTTP/2 working group to expose these first.

On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon <[email-masked]>
wrote:

> Lin,
>
> We had suggested priority and streamed as a starting point to get more
> network aware details from the application. When you say signaling - are
> you indicating signaling to setup the network elements to start looking for
> QUIC packets or for something else. Please clarify.
>
> Thanks,
> Abilash
>
> From the point of view of network device, we want to know and also wish
> that the QUIC could support the signaling for the network device along the
> path.
> This is for the QoS enhancement consideration in the future. Marking
> priority is not enough for provisioning a device.
> The lesson from TCP is its rigidity for the extension. It would be nice
> that QUIC has such elastic from the beginning of the design.
>
> Thanks
>
> Lin
>
> *From:* QUIC [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Abilash Menon
> *Sent:* Friday, January 06, 2017 5:17 AM
> *To:* Jana Iyengar
> *Cc:* Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
> So if you consider packet pacing with multiple streams, the latency of one
> stream need not be affected by another if one specific stream gets
> affected. Yes this would need per stream congestion control - it looks like
> you done want to have that granular control here. So is there any network
> assistance you would like the protocol to get if the network elements can
> support it. If so , please let us know - we would like to understand.
>
>
>
> Prioritization could certainly help streams. That could use the RFC7657
> which Ted had mentioned, but our approach was to leverage the QUIC protocol
> itself to use priority and get more granular view of the network using
> stream ids. We will see if we can get some useful results.
>
> Thanks,
> Abilash
>
>
>
>
> - jana
>
>

---

From: "Ritesh Mukherjee" <[email-masked]>
Date: Tue, 10 Jan 2017 08:26:53 -0800

Please see inline…

From: Ian Swett [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2017 7:33 AM
To: Abilash Menon <[email-masked]>
Cc: Lin Han <[email-masked]>; Ritesh Mukherjee <[email-masked]>; Jana Iyengar <[email-masked]>; Ted Hardie <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: soliciting feedback on draft-abilash-quic-network

I have many of the same concerns expressed above, but one specific element of this proposal would appear to be a clear violation of the charter, which is exposing stream ids and priorities.

[Ritesh] The Stream IDs and priorities would still be authenticated. Are there any specific attacks you are concerned about?

The charter says: "This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3  using TCP"

HTTP/2 over TLS 1.3 does not expose these, and so as Jana mentioned, you'd have to convince the HTTP/2 working group to expose these first.

[Ritesh] There is no specific sequencing of proposing enhancements mentioned in the charter or anywhere else. In any case we understand it would be good to have a precedent – we are considering making a proposal in the HTTP/2 WG. 

On Mon, Jan 9, 2017 at 2:05 PM, Abilash Menon <[email-masked] <mailto:[email-masked]> > wrote:

Lin,

Thanks,

Abilash

On Jan 9, 2017, at 3:15 PM, Lin Han <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Abilash

Thanks

Lin

Jana,

On Jan 5, 2017, at 10:52 PM, Jana Iyengar < <mailto:[email-masked]> [email-masked]> wrote:

Hi,

 

 

Thanks,

Abilash

- jana

On Thu, Jan 5, 2017 at 4:08 PM, Ted Hardie < <mailto:[email-masked]> [email-masked]> wrote:

Reply in-line.

On Thu, Jan 5, 2017 at 3:38 PM, Abilash Menon < <mailto:[email-masked]> [email-masked]> wrote:

Hey Ted,

On Jan 5, 2017, at 2:57 PM, Ted Hardie < <mailto:[email-masked]> [email-masked]> wrote:

Howdy,

 

 

 

Your draft says this:

 

 

regards,

Ted

Thanks,

Abilash

regards,

Ted

On Thu, Jan 5, 2017 at 7:34 AM, Ritesh Mukherjee < <mailto:[email-masked]> [email-masked]> wrote:

Hi Team,

URL:             <https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt> https://www.ietf.org/internet-drafts/draft-abilash-quic-network-00.txt

Htmlized:        <https://tools.ietf.org/html/draft-abilash-quic-network-00> https://tools.ietf.org/html/draft-abilash-quic-network-00

Thank you in advance!

Ritesh

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Jan 2017 08:44:39 -0800

On Tue, Jan 10, 2017 at 8:26 AM, Ritesh Mukherjee <
[email-masked]> wrote:

> Please see inline…
>
>
>
> *From:* Ian Swett [mailto:[email-masked]]
> *Sent:* Tuesday, January 10, 2017 7:33 AM
> *To:* Abilash Menon <[email-masked]>
> *Cc:* Lin Han <[email-masked]>; Ritesh Mukherjee <
> [email-masked]>; Jana Iyengar <[email-masked]>; Ted Hardie <
> [email-masked]>; IETF QUIC WG <[email-masked]>
> [Ritesh] The Stream IDs and priorities would still be authenticated. Are
> there any specific attacks you are concerned about?
>

Stream IDs are currently not exposed in HTTP/2 over TLS. Your proposal
would effectively expose HTTP/2 stream IDs for QUIC, which, as Ian points
out, would violate the stipulation in the charter. I would encourage having
this conversation in the httpbis wg first, and then bring it to QUIC.

- jana

> privacy properties that are at least as good as a stack composed of TLS 1.3
>  using TCP"
>
>
>
> [Ritesh] There is no specific sequencing of proposing enhancements
> mentioned in the charter or anywhere else. In any case we understand it
> would be good to have a precedent – we are considering making a proposal in
> the HTTP/2 WG.
>
>
>
>
>

---

From: "Ritesh Mukherjee" <[email-masked]>
Date: Tue, 10 Jan 2017 09:00:48 -0800

From: Jana Iyengar [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2017 8:45 AM
To: Ritesh Mukherjee <[email-masked]>
Cc: Ian Swett <[email-masked]>; Abilash Menon <[email-masked]>; Lin Han <[email-masked]>; Ted Hardie <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: soliciting feedback on draft-abilash-quic-network

On Tue, Jan 10, 2017 at 8:26 AM, Ritesh Mukherjee <[email-masked] <mailto:[email-masked]> > wrote:

Please see inline…

From: Ian Swett [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, January 10, 2017 7:33 AM
To: Abilash Menon <[email-masked] <mailto:[email-masked]> >
Cc: Lin Han <[email-masked] <mailto:[email-masked]> >; Ritesh Mukherjee <[email-masked] <mailto:[email-masked]> >; Jana Iyengar <[email-masked] <mailto:[email-masked]> >; Ted Hardie <[email-masked] <mailto:[email-masked]> >; IETF QUIC WG <[email-masked] <mailto:[email-masked]> >
Subject: Re: soliciting feedback on draft-abilash-quic-network

Stream IDs are currently not exposed in HTTP/2 over TLS. Your proposal would effectively expose HTTP/2 stream IDs for QUIC, which, as Ian points out, would violate the stipulation in the charter. I would encourage having this conversation in the httpbis wg first, and then bring it to QUIC.

- jana

[Ritesh] We understand. The charter mentions it needs to be “as good as” HTTP/2 over TLS and we can propose it there too. However I was hoping for why this would make it less secure rather than if httpbis did it then we will too. Anyway…

 

Lin,

Thanks,

Abilash

Hi, Abilash

Thanks

Lin

Jana,

Hi,

 

 

Thanks,

Abilash

- jana

Reply in-line.

Hey Ted,

Howdy,

 

 

 

Your draft says this:

 

 

regards,

Ted

Thanks,

Abilash

regards,

Ted

Hi Team,

Thank you in advance!

Ritesh

---

From: Lin Han <[email-masked]>
Date: Tue, 10 Jan 2017 18:32:58 +0000

Hi,

What I meant is the capability that QUIC can carry the signaling information distributed for the network device on the path, the signaling information will be intercepted at each hop when the QUIC packets are forwarded. The detailed signaling can be designed later by other RFC. As for how the network device knows to start looking for QUIC is another topic which should rely on the IP packet, and QUIC cannot do anything.

Thanks

Lin

From: Abilash Menon [mailto:[email-masked]]
Sent: Monday, January 09, 2017 2:05 PM
To: Lin Han
Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on draft-abilash-quic-network

Lin,

Thanks,
Abilash

On Jan 9, 2017, at 3:15 PM, Lin Han <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Abilash

Thanks

Lin

Jana,

Hi,

Thanks,
Abilash

- jana

Howdy,

Your draft says this:

Thanks,
Abilash

regards,
Ted

Thank you in advance!

Ritesh

---

From: Abilash Menon <[email-masked]>
Date: Tue, 10 Jan 2017 13:47:26 -0500

Lin,

Thanks. What is the signaling information carrying though. I think you are alluding to some kind of metadata/header that QUIC can carry which is public ?  I did not quite understand your use case though. Another option would be to have an optional tlv after the public headers where application can add any app specific data.  The Type would need further discussion though. This could be signaling, identifier or anything for the network elements - a network element header. 

Jana,

It looks like there is sufficient interest for sending information to the network elements via the QUIC packet. There may be multiple use cases and we can probably work towards a consensus by not violating any of the chart goals. Can we discuss this during some upcoming meeting with the interested parties. 

All,

Please let us know if there are others who are interested in the network elements being QUIC aware. We could probably work together to discuss use cases and have a more in-depth technical discussion with Jana and others.

Thanks,
Abilash

> On Jan 10, 2017, at 1:32 PM, Lin Han <[email-masked]> wrote:
> 
> Hi,
>  
> On Jan 9, 2017, at 3:15 PM, Lin Han <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi, Abilash
>  
> From: QUIC [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Abilash Menon

---

From: Lin Han <[email-masked]>
Date: Tue, 10 Jan 2017 19:05:23 +0000

Hi,

The signaling information is some QoS related information for the device programming. Metadata or optional TLV are both fine as long as the space is enough and the detailed format can be defined and extended later.

Thanks

Lin

From: Abilash Menon [mailto:[email-masked]]
Sent: Tuesday, January 10, 2017 10:47 AM
To: Lin Han
Cc: Jana Iyengar; Ritesh Mukherjee; Ted Hardie; IETF QUIC WG
Subject: Re: soliciting feedback on draft-abilash-quic-network

Lin,

Jana,

All,

Thanks,
Abilash

On Jan 10, 2017, at 1:32 PM, Lin Han <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks

Lin

Lin,

Thanks,
Abilash

Hi, Abilash

Thanks

Lin

Jana,

Hi,

Thanks,
Abilash

- jana

Howdy,

Your draft says this:

Thanks,
Abilash

regards,
Ted

Thank you in advance!

Ritesh

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 10 Jan 2017 19:42:10 +0000

Hi,

> It looks like there is sufficient interest for sending information to the network elements via the QUIC packet. There may be multiple use cases and we can probably work towards a consensus by not v…

there may be interest, but my reading of the charter - as chair - is in line with Ian's and Jana's. "Sending information to the network elements via the QUIC packet", if such information includes elements not currently exposed by H2 over TLS, is outside the scope of our current charter.

> Please let us know if there are others who are interested in the network elements being QUIC aware. We could probably work together to discuss use cases and have a more in-depth technical discussio…

This topic can certainly be discussed amongst interested parties. I would like to ask the WG to prioritize work on our currently chartered milestones, however.

Thanks,
Lars

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Jan 2017 12:01:19 -0800

Hi Abhilash,

> It looks like there is sufficient interest for sending information to the
> network elements via the QUIC packet. There may be multiple use cases and
> we can probably work towards a consensus by not violating any of the chart
> goals. Can we discuss this during some upcoming meeting with the interested
> parties.
>

There's always been interest in sending information to network elements via
any/all packets, not just QUIC ones. The prevalence of information exposure
has led us to this juncture where middleboxes have ossified transport
evolution almost completely. Going forward, we have to assume that anything
that is exposed to the network will be ossified for life, and so the bar
for exposing any information is quite high. The information that this
proposal asks for is pretty deep information, and and the justification
does not meet the bar. IMO, I don't think there's any rationale that can
meet the bar for exposing stream IDs. There are too many flawed assumptions
about what stream IDs mean for a design that uses it in-network to make any
sense.

To be clear, please do not engineering a solution before you can
convincingly argue for the existence of the problem and the sanity of the
solution space. I'm not convinced of either.

- jana

---

From: Brian Trammell <[email-masked]>
Date: Wed, 11 Jan 2017 08:46:11 +0100

hi Jana, Abilash, all,

> On 10 Jan 2017, at 21:01, Jana Iyengar <[email-masked]> wrote:

> There are too many flawed assumptions about what stream IDs mean for a design that uses it in-network to make any sense.

This is a very important point, and I want to quote it for emphasis.

Stream identifiers in QUIC (as in HTTP/2) are essentially application-level semantic entities. There is no reason for anything other than the endpoints to know anything about them.

Existing efforts to build in-network functionality have tended to assign properties to flows, and to provide whatever treatment that functionality requires keyed on flow. This isn't really a design feature of the current Internet architecture, it's simply a historical accident. Most of the traffic on most networks is TCP, and TCP is widely assumed to be intolerant of packet reordering. Any attempt to deliver TCP traffic without reordering therefore means you need to treat packets with the same five- (or six-, including DSCP, on networks where it works) tuples the same, and that gives you a natural way to group packets, and to hang other functionality off those groups.

> To be clear, please do not engineering a solution before you can convincingly argue for the existence of the problem and the sanity of the solution space. I'm not convinced of either.

(hi Jana, I'm going to ignore this bit of advice for a moment -- sorry! -- because there does exist an obvious less-insane subset of the solution space for grouping QUIC packets for network treatment than stream exposure. I will leave the argument for the existence of the problem aside at the moment, as well as the messier problems of expressing desired network treatment in network-level semantics.)

Stream identity doesn't carry any information about desired or desirable network treatment of a given packet. Any network treatment information must therefore necessarily be inferred. Implicit assumptions about packet treatment by on-path devices are a large part of how we got into the mess we're in with respect to network manageability in the first place. But even assuming that an application wants to segregate its packets by groups that require different treatment by the network (canonical example, WebRTC channels with different DSCP codepoints), streams aren't the way to do that. In QUIC, if an application determines that different parts of a connection really do need to be distinguishable in the network, we could use existing identifiers already exposed to the network: the five-tuple.

Adding a five-tuple to an existing connection in QUIC is theoretically extremely cheap: just pick a port and send a packet. Of course, running a single connection ID over multiple simultaneous five-tuples is not yet supported by the protocol as specified, but since it's just a generalization of the rebinding case, it's (1) much easier to do in terms of engineering effort, since it doesn't break as many existing assumptions, as well as (2) far less odious for its exposure of undesired information about the application layer semantics than stream ID exposure.

Cheers,

Brian