1 / 9

K nown startup state for a simpler and more robust HTTP 2.0

K nown startup state for a simpler and more robust HTTP 2.0. HTTPbis WG, IETF 85, Orlando 15 March, 2013 Osama Mazahir Matthew Cox Gabriel Montenegro (Microsoft). The issue: unknown startup state.

bethan
Télécharger la présentation

K nown startup state for a simpler and more robust HTTP 2.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Known startup state for a simpler and more robust HTTP 2.0 HTTPbis WG, IETF 85, Orlando 15 March, 2013 Osama Mazahir Matthew Cox Gabriel Montenegro (Microsoft)

  2. The issue: unknown startup state • Needlesscomplexityiftheprotocoldoesnotstart at a knownstate at bothclient/server • Besttonotallowtheprotocolto “overstep” itself • “overstep”: send more thanyouhavecreditfor, open more streamsthanthe receiver allowsfor, etc. • Let’snotabandonprotocolcorrectness in thequestforspeed (besides, no needto) • Can lead to more oversteppingwithfutureextensionswithunpredicableconsequences • We can solvethis

  3. Some related issues #51: Client advertising settings during Upgrade dance • Client sends GET with Upgrade • Server responds with 101 followed by SYN_REPLY, DATA, maybe PUSHed streams • Could blow up client’s buffer’s or PUSH against client wishes • New HTTP header? #38: SETTINGS_MAX_CONCURRENT_STREAMS • TLS case: Client opens too many streams • TLS extra info? • Upgrade case: Server opens too many streams • New HTTP header? #40: Defaulting to no-push via SETTINGS_MAX_CONCURRENT_STREAMS • Mailing list discussion: explicit signal is better • New HTTP header? #?? (new issue): Unknown window credits • TLS case: Client sends too much to the server • TLS extra info? • Upgrade case: Server sends too much to the client • New HTTP header?

  4. Current alternatives and their issues • SETTINGS frame? Too late • Clientcouldsenditsinitialsettingsframe and simultaneously open toomanystreamsorsendtoomuch • In Upgrade scenario, Server couldrespondto HTTP/1.1 GET with 101 followedby PUSH withtoomanystreamstoomuch data • waitfortheother’s SETTINGS frame? • Time wasted • Defaults? Wishfulthinking… • Hardtoagree, discussion can ratholeduetodifferentscenarios • Doesnotallowstartupstatetovaryfrom defaults • DNS? Notalwayspossible • Good plan B, though.

  5. Proposal: set startup state in negotiation • Duringnegotiationallowonepartytoinformtheother of itsdesiredstartupstate • Potentialstateto set (choosewhich, ifany, tocommunicate) 1. Max concurrentstreamsand Receivewindow 2. “Neither PUSH norinliningdesired” • Potential Solutions (choosewhich, ifany, topursue): 1. In Upgrade case: • Clientsends HTTP header(s) to set desiredstate 2. In TLS case • Enhance TLS protocolnegotiationbyallowingsendingthedesiredstartupstate • Reuse“TLS HandshakeMessageforSupplementalData” (RFC4680)?

  6. EXTRA SLIDES

  7. client ignores server maxstreams • client opens toomanystreamstothe server (clientneednotwaitfor SETTINGS) • Server resetsallstreamsoveritslimit • Clientmustkeepcanceledstreams in “backorder”, issuingthem as outstandingrequests are served • Clientmust buffer canceledrequest, sendan error totheapplication, etc, leadingtocomplexity and appissues • Ifmaxstreamsisknown, any server cancel can be dealtwithsimply (shuttingdowntheconnection)

  8. server ignores clientmaxstreams • In Upgrade scenario, clientsends http/1.1 GET, server sends 101, immediatelyfollowedby HTTP/2.0 traffic • Can result in server PUSHingtoomanystreams, beforetheclient has a chance tosend a SETTINGS frame • Wasteful of resources at bothsides(e.g., data allowance, batteryontheclient) • Complexity at the server: pushstreams in backorder, issuedgradually

  9. UnknownWindowCredits(2) • Clientor server (in Upgrade case) sendtoomuch • Mustkeepcount of “negative” credits, increasingcodecomplexity • Worse: hardtoreasonaboutprotocolcorrectness • Sane TransportProtocols DO NOT DO THIS (TCP, etc) • Will Flow Control Algorithmsnowhavetotakeintoaccounthandling of “negative” credit? • Raisesthe bar forflow control algorithms • Defeatsthepurpose of flow control principles • We are creating a transportprotocol: weshouldfollowbestpractices

More Related