RE: Transport in 0-RTT connections for high BDP: opt-in

[Kuhn Nicolas <[e-mail]>]

Thanks for your comment and sharing the issues in sizing the initial CWND for H1/H2.

The core element in the draft is : if the client knows that the BDP of the network is high, client-level adaptations can be envisioned. 
The draft also presents server-level adaptations that could also improve the time to service (with an increased IW and MTU as examples - following some comments we received from the list).  

So : 
1- How do we inform the client know the BDP is high ?
The actual BDP may not be relevant and difficult to measure - as you mentioned. Using the actual value or a binary based on simple heuristics (e.g. RTT value > 500ms) is still under discussion. 

2- Is increasing the IW safe ? 
As mentioned in other emails by others, server implementations decide how to restart connections. The draft indeed mentions the gains we could have in increasing the initCWND, but along with pacing this increase *should* not hurt yourself. When you send a packet once every five milliseconds, a 50ms RTT would give you an initCWND of 10, while a 500ms RTT would result in a initCWND of 100 without burst-related losses. 

Cheers, 

Nico


-----Message d'origine-----
De : Roberto Peon <[e-mail]> 
Envoyé : mercredi 13 mars 2019 18:07
À : Kuhn Nicolas <[e-mail]>; 'Kazuho Oku' <[e-mail]>; Lars Eggert <[e-mail]>
Cc : Jana Iyengar <[e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>; [e-mail]; [e-mail]; Martin Thomson <[e-mail]>
Objet : Re: Transport in 0-RTT connections for high BDP: opt-in

This may be obvious, but I'll lay it out anyway:

The 1st order benefit of predicting the BW to the client/server is bounded by the error between under-predicted BW and actual BW at the start of a connection. We know that this error last for a longer time with larger RTTs.

The 1st order effects on the network is either better utilization or over-utilization. Both are corrected in some amount of time. Depending on the algorithm, it can be corrected in a single RTT, or it can be corrected in something like RTT * lg(error) time.

The 2nd order effects aren't new-- folks may make more connections because the opportunity cost of spinning up a new connection is lower. We've seen from H1->H2 that applications do this more often anyway when congestion control has non-error-proportional feedback loops (e.g. is a direct function of packet-loss, rather than ratio of packet loss).

From what we saw in the SPDY-experiment era, caching of the prior state worked and showed improvements. The experiments that we did then were imperfect-- we recorded BDP (as CWND). IIRC most clients had surprisingly moderate CWNDs (< 40), and saw benefit from an increased INITCWND.  The benefit at the time was not enough to overcome fears in the H2 era, and thus it was dropped then.

Since the SPDY-era experiment failed to record CWND+RTT (or bandwidth directly), there were hypotheses that this could have been much better and that larger cwnds were probably causal of burst-losses that immediately decreased the effectiveness (at those larger cwnd start sizes). 
There are a bunch of heuristics that attempt to deal with this in various transport stuff (how much should you transmit after you're idle for X seconds? Hint: If you just use the last param you had, you'll potentially initiate a large burst and hurt yourself). In other words, this problem is endemic of long-lived bursty traffic (i.e. web and web-like traffic *including* most video right now) within any congestion control loop and not just at connection initiation.
-=R



On 3/13/19, 9:27 AM, "QUIC on behalf of Kuhn Nicolas" <[e-mail] on behalf of [e-mail]> wrote:

    Hi, 
    
    This email is just an attempt to clarify the potential gain with the proposed solution. 
    In short, the client being also aware of the high BDP connection can help in further improvements of the time-to-service (and does not cost much).
    
    ---
    Potential classic operation with the proposed BCP 
    ---
    During the 1-RTT connection, the server measures MTU, RTT, BDP, etc.
    This information is sent to the client in the NewSessionTicket to the client. 
    The reduced ticket_lifetime  guarantee that the client has not moved (the server is also free to discard this information if the client IP address has changed). 
    -> The server can adapt the CC to the measured characteristics of the network to improve the time to service
    
    ---
    Added signal with the proposed BCP 
    ---
    In addition to a classic operation, with our proposal the client is aware of being on a high BDP path.
    - > The client can adapt the CC to the measured characteristics of the network to improve the time to service (e.g. ACK management (ratio, delayed, etc), better memory management, reestablishment, etc)
    
    While I agree that more data may be required, the purpose is more to let the door open for further concrete proposals initiated by the client knowing it is on a high BDP path.
    
    Cheers,
    
    Nico
    
    -----Message d'origine-----
    De : Kazuho Oku <[e-mail]> 
    Envoyé : mercredi 13 mars 2019 14:23
    À : Lars Eggert <[e-mail]>
    Cc : Mikkel Fahnøe Jørgensen <[e-mail]>; Jana Iyengar <[e-mail]>; Kuhn Nicolas <[e-mail]>; [e-mail]; Martin Thomson <[e-mail]>; [e-mail]
    Objet : Re: Transport in 0-RTT connections for high BDP: opt-in
    
    2019年3月13日(水) 21:00 Lars Eggert <[e-mail]>:
    >
    > Hi,
    >
    > On 2019-3-13, at 0:09, Kazuho Oku <[e-mail]> wrote:
    >
    > To me it seems that the question is if having a client-sent flag that 
    > indicates whether the client is on the same network as the one it 
    > obtained the token helps the server determine the correct send window, 
    > either before path validation or right after path validation.
    >
    >
    > sure, but the server already knows this based on whether the source IP address has changed?
    
    Exactly. That's why I stated in my previous mail that the benefit of the proposed approach depends on the improvement we gain from the added signal (compared to just relying on the client's address).
    
    > Lars
    
    
    
    --
    Kazuho Oku