idnits 2.17.00 (12 Aug 2021) /tmp/idnits20148/draft-kpugin-rush-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TODO Working Group K. Pugin 3 Internet-Draft A. Frindell 4 Intended status: Informational J. Cenzano 5 Expires: 8 September 2022 J. Weissman 6 Facebook 7 7 March 2022 9 RUSH - Reliable (unreliable) streaming protocol 10 draft-kpugin-rush-01 12 Abstract 14 RUSH is an application-level protocol for ingesting live video. This 15 document describes the protocol and how it maps onto QUIC. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the mailing list (), which 22 is archived at . 24 Source for this draft and an issue tracker can be found at 25 https://github.com/afrind/draft-rush. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 8 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 62 3. Theory of Operations . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Connection establishment . . . . . . . . . . . . . . . . 3 64 3.2. Sending Video Data . . . . . . . . . . . . . . . . . . . 4 65 3.3. Receiving data . . . . . . . . . . . . . . . . . . . . . 4 66 3.4. Reconnect . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Frame Header . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Frames . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.2.1. Connect frame . . . . . . . . . . . . . . . . . . . . 8 71 4.2.2. Connect Ack frame . . . . . . . . . . . . . . . . . . 8 72 4.2.3. End of Video frame . . . . . . . . . . . . . . . . . 9 73 4.2.4. Error frame . . . . . . . . . . . . . . . . . . . . . 9 74 4.2.5. Video frame . . . . . . . . . . . . . . . . . . . . . 10 75 4.2.6. Audio frame . . . . . . . . . . . . . . . . . . . . . 11 76 4.2.7. GOAWAY frame . . . . . . . . . . . . . . . . . . . . 13 77 4.3. QUIC Mapping . . . . . . . . . . . . . . . . . . . . . . 13 78 4.3.1. Normal mode . . . . . . . . . . . . . . . . . . . . . 13 79 4.3.2. Multi Stream Mode . . . . . . . . . . . . . . . . . . 13 80 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.1. Connection Errors . . . . . . . . . . . . . . . . . . . . 14 82 5.2. Frame errors . . . . . . . . . . . . . . . . . . . . . . 14 83 6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 9. Normative References . . . . . . . . . . . . . . . . . . . . 15 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 RUSH is a bidirectional application level protocol designed for live 93 video ingestion that runs on top of QUIC. 95 RUSH was built as a replacement for RTMP (Real-Time Messaging 96 Protocol) with the goal to provide support for new audio and video 97 codecs, extensibility in the form of new message types, and multi- 98 track support. In addition, RUSH gives applications option to 99 control data delivery guarantees by utilizing QUIC streams. 101 This document describes the RUSH protocol, wire format, and QUIC 102 mapping. 104 2. Conventions and Definitions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 Frame/Message: logical unit of information that client and server 113 can exchange 115 PTS: presentation timestamp 117 DTS: decoding timestamp 119 AAC: advanced audio codec 121 NALU: network abstract layer unit 123 VPS: video parameter set (H265 video specific NALU) 125 SPS: sequence parameter set (H264/H265 video specific NALU) 127 PPS: picture parameter set (H264/H265 video specific NALU) 129 ADTS header: _Audio Data Transport Stream Header_ 131 ASC: Audio specific config 133 GOP: Group of pictures, specifies the order in which intra- and 134 inter-frames are arranged. 136 3. Theory of Operations 138 3.1. Connection establishment 140 In order to live stream using RUSH, the client establishes a QUIC 141 connection using the ALPN token "rush". 143 After the QUIC connection is established, client creates a new 144 bidirectional QUIC stream, choses starting frame ID and sends Connect 145 frame Section 4.2.1 over that stream. This stream is called the 146 Connect Stream. 148 The client sends mode of operation setting in Connect frame payload, 149 format of the payload is TBD. 151 One connection SHOULD only be used to send one video. 153 3.2. Sending Video Data 155 The client can choose to wait for the ConnectAck frame Section 4.2.2 156 or it can start sending data immediately after sending the Connect 157 frame. 159 A track is a logical organization of the data, for example, video can 160 have one video track, and two audio tracks (for two languages). The 161 client can send data for multiple tracks simultaneously. 163 The encoded audio or video data of each track is serialized into 164 frames (see Section 4.2.6 or Section 4.2.5) and transmitted from the 165 client to the server. Each track has its own monotonically 166 increasing frame ID sequence. The client MUST start with initial 167 frame ID = 1. 169 Depending on mode of operation (Section 4.3), the client sends audio 170 and video frames on the Connect stream or on a new QUIC stream for 171 each frame. 173 In Multi Stream Mode (Section 4.3.2), the client can stop sending a 174 frame by resetting the corresponding QUIC stream. In this case, 175 there is no guarantee that the frame was received by the server. 177 3.3. Receiving data 179 Upon receiving Connect frame, the server replies with ConnectAck 180 frame Section 4.2.2 and prepares to receive audio/video data. 182 It's possible that in Multi Stream Mode (Section 4.3.2), the server 183 receives audio or video data before it receives the Connect frame. 184 The implementation can choose whether to buffer or drop the data. 185 The audio/video data cannot be interpreted correctly before the 186 arrival of the Connect frame. 188 In Normal Mode (Section 4.3.1), it is guaranteed by the transport 189 that frames arrive into the application layer in order they were 190 sent. 192 In Multi Stream Mode, it's possible that frames arrive at the 193 application layer in a different order than they were sent, therefore 194 the server MUST keep track of last received frame ID for every track 195 that it receives. A gap in the frame sequence ID on a given track 196 can indicate out of order delivery and the server MAY wait until 197 missing frames arrive. The server must consider frame lost if the 198 corresponding QUIC stream was reset. 200 Upon detecting a gap in the frame sequence, the server MAY wait for 201 the missing frames to arrive for an implementation defined time. If 202 missing frames don't arrive, the server SHOULD consider them lost and 203 continue processing rest of the frames. For example if the server 204 receives the following frames for track 1: 1 2 3 5 6 and frame #4 205 hasn't arrived after implementation defined timeout, thee server 206 SHOULD continue processing frames 5 and 6. 208 When the client is done streaming, it sends the End of Video frame 209 (Section 4.2.3) to indicate to the server that there won't be any 210 more data sent. 212 3.4. Reconnect 214 If the QUIC connection is closed at any point, client MAY reconnect 215 by simply repeat the Connection establishment process (Section 3.1) 216 and resume sending the same video where it left off. In order to 217 support termination of the new connection by a different server, the 218 client SHOULD resume sending video frames starting with I-frame, to 219 guarantee that the video track can be decoded. 221 Reconnect can be initiated by the server if it needs to "go away" for 222 maintenance. In this case, the server sends a GOAWAY frame 223 (Section 4.2.7) to advise the client to gracefully close the 224 connection. This allows client to finish sending some data and 225 establish new connection to continue sending without interruption. 227 4. Wire Format 229 4.1. Frame Header 231 The client and server exchange information using frames. There are 232 different types of frames and the payload of each frame depends on 233 its type. 235 Generic frame format: 237 0 1 2 3 4 5 6 7 238 +--------------------------------------------------------------+ 239 | Length (64) | 240 +--------------------------------------------------------------+ 241 | ID (64) | 242 +-------+------------------------------------------------------+ 243 |Type(8)| Payload ... | 244 +-------+------------------------------------------------------+ 246 Length(64)`: Each frame starts with length field, 64 bit size that 247 tells size of the frame in bytes (including predefined fields, so 248 if LENGTH is 100 bytes, then PAYLOAD length is 100 - 8 - 8 - 1 = 249 82 bytes). 251 ID(64): 64 bit frame sequence number, every new frame MUST have a 252 sequence ID greater than that of the previous frame within the 253 same track. Track ID would be specified in each frame. If track 254 ID is not specified it's 0 implicitly. 256 Type(8): 1 byte representing the type of the frame. 258 Predefined frame types: 260 +============+====================+ 261 | Frame Type | Frame | 262 +============+====================+ 263 | 0x0 | connect frame | 264 +------------+--------------------+ 265 | 0x1 | connect ack frame | 266 +------------+--------------------+ 267 | 0x2 | reserved | 268 +------------+--------------------+ 269 | 0x3 | reserved | 270 +------------+--------------------+ 271 | 0x4 | end of video frame | 272 +------------+--------------------+ 273 | 0x5 | error frame | 274 +------------+--------------------+ 275 | 0x6 | reserved | 276 +------------+--------------------+ 277 | 0x7 | reserved | 278 +------------+--------------------+ 279 | 0x8 | reserved | 280 +------------+--------------------+ 281 | 0x9 | reserved | 282 +------------+--------------------+ 283 | 0xA | reserved | 284 +------------+--------------------+ 285 | 0XB | reserved | 286 +------------+--------------------+ 287 | 0xC | reserved | 288 +------------+--------------------+ 289 | 0xD | video frame | 290 +------------+--------------------+ 291 | 0xE | audio frame | 292 +------------+--------------------+ 293 | 0XF | reserved | 294 +------------+--------------------+ 295 | 0X10 | reserved | 296 +------------+--------------------+ 297 | 0x11 | reserved | 298 +------------+--------------------+ 299 | 0x12 | reserved | 300 +------------+--------------------+ 301 | 0x13 | reserved | 302 +------------+--------------------+ 303 | 0x14 | GOAWAY frame | 304 +------------+--------------------+ 306 Table 1 308 4.2. Frames 310 4.2.1. Connect frame 312 +--------------------------------------------------------------+ 313 | Length (64) | 314 +--------------------------------------------------------------+ 315 | ID (64) | 316 +-------+-------+---------------+---------------+--------------+ 317 | 0x0 |Version|Video Timescale|Audio Timescale| | 318 +-------+-------+---------------+---------------+--------------+ 319 | Live Session ID(64) | 320 +--------------------------------------------------------------+ 321 | Payload ... | 322 +--------------------------------------------------------------+ 324 Version: version of the protocol (initial version is 0x0). 326 Video Timescale: timescale for all video frame timestamps on this 327 connection. Recommended value 30000 329 Audio Timescale: timescale for all audio samples timestamps on this 330 connection, recommended value same as audio sample rate, for 331 example 44100 333 Live Session ID: identifier of broadcast, when reconnect, client 334 MUST use the same live session ID 336 Payload: application and version specific data that can be used by 337 the server. OPTIONAL 339 This frame is used by the client to initiate broadcasting. The 340 client can start sending other frames immediately after "Connect 341 frame" without waiting acknowledgement from the server. 343 If server doesn't support VERSION sent by the client, the server 344 sends an Error frame with code UNSUPPORTED VERSION. 346 If audio timescale or video timescale are 0, the server sends error 347 frame with error code INVALID FRAME FORMAT and closes connection. 349 If the client receives a Connect frame from the server, the client 350 sends an Error frame with code TBD. 352 4.2.2. Connect Ack frame 353 0 1 2 3 4 5 6 7 354 +--------------------------------------------------------------+ 355 | 17 | 356 +--------------------------------------------------------------+ 357 | ID (64) | 358 +-------+------------------------------------------------------+ 359 | 0x1 | 360 +-------+ 362 The server sends the "Connect Ack" frame in response to "Connect" 363 frame indicating that server accepts "version" and is ready to 364 receive data. 366 If the client doesn't receive "Connect Ack" frame from the server 367 within a timeout, it will close the connection. The timeout value is 368 chosen by the implementation. 370 There can be only one "Connect Ack" frame sent over lifetime of the 371 QUIC connection. 373 If the server receives a Connect Ack frame from the client, the 374 client sends an Error frame with code TBD. 376 4.2.3. End of Video frame 378 +--------------------------------------------------------------+ 379 | 17 | 380 +--------------------------------------------------------------+ 381 | ID (64) | 382 +-------+------------------------------------------------------+ 383 | 0x4 | 384 +-------+ 386 End of Video frame is sent by a client when it's done sending data 387 and is about to close the connection. The server SHOULD ignore all 388 frames sent after that. 390 4.2.4. Error frame 391 +--------------------------------------------------------------+ 392 | 29 | 393 +--------------------------------------------------------------+ 394 | ID (64) | 395 +-------+------------------------------------------------------+ 396 | 0x5 | 397 +-------+------------------------------------------------------+ 398 | Sequence ID (64) | 399 +------------------------------+-------------------------------+ 400 | Error Code (32) | 401 +------------------------------+ 403 Sequence ID: ID of the frame sent by the client that error is 404 generated for, ID=0x0 indicates connection level error. 406 Error Code: 32 bit unsigned integer 408 Error frame can be sent by the client or the server to indicate that 409 an error occurred. 411 Some errors are fatal and the connection will be closed after sending 412 the Error frame. 414 4.2.5. Video frame 416 +--------------------------------------------------------------+ 417 | Length (64) | 418 +--------------------------------------------------------------+ 419 | ID (64) | 420 +-------+-------+----------------------------------------------+ 421 | 0xD | Codec | 422 +-------+-------+----------------------------------------------+ 423 | PTS (64) | 424 +--------------------------------------------------------------+ 425 | Track ID (64) | 426 +---------------+----------------------------------------------+ 427 | I-Frame ID Offset | Video Data ... | 428 +---------------+----------------------------------------------+ 430 Codec: specifies codec that was used to encode this frame. 432 PTS: presentation timestamp in connection video timescale 434 DTS: decoding timestamp in connection video timescale 436 Supported type of codecs: 438 +======+=======+ 439 | Type | Codec | 440 +======+=======+ 441 | 0x1 | H264 | 442 +------+-------+ 443 | 0x2 | H265 | 444 +------+-------+ 445 | 0x3 | VP8 | 446 +------+-------+ 447 | 0x4 | VP9 | 448 +------+-------+ 450 Table 2 452 Track ID: ID of the track that this frame is on 454 I-Frame ID Offset: Distance from sequence ID of the I-frame that is 455 required before this frame can be decoded. This can be useful to 456 decide if frame can be dropped. 458 Video Data: variable length field, that carries actual video frame 459 data that is codec dependent 461 For h264/h265 codec, "Video Data" are 1 or more NALUs in AVCC format: 463 0 1 2 3 4 5 6 7 464 +--------------------------------------------------------------+ 465 | NALU Length (64) | 466 +--------------------------------------------------------------+ 467 | NALU Data ... 468 +--------------------------------------------------------------+ 470 EVERY h264 video key-frame MUST start with SPS/PPS NALUs. EVERY h265 471 video key-frame MUST start with VPS/SPS/PPS NALUs. 473 Binary concatenation of "video data" from consecutive video frames, 474 without data loss MUST produce VALID h264/h265 bitstream. 476 4.2.6. Audio frame 477 +--------------------------------------------------------------+ 478 | Length (64) | 479 +--------------------------------------------------------------+ 480 | ID (64) | 481 +-------+------------------------------------------------------+ 482 | 0xE | Codec | 483 +-------+-------+----------------------------------------------+ 484 | Timestamp (64) | 485 +-------+------------------------------------------------------+ 486 |TrackID| 487 +-------+------------------------------------------------------+ 488 | Audio Data ... 489 +--------------------------------------------------------------+ 491 Codec: specifies codec that was used to encode this frame. 493 Supported type of codecs: 495 +======+=======+ 496 | Type | Codec | 497 +======+=======+ 498 | 0x1 | AAC | 499 +------+-------+ 500 | 0x2 | OPUS | 501 +------+-------+ 503 Table 3 505 Timestamp: timestamp of first audio sample in Audio Data. 507 Track ID: ID of the track that this frame is on 509 Audio Data: variable length field, that carries 1 or more audio 510 frames that is codec dependent. 512 For AAC codec, "Audio Data" are 1 or more AAC samples, prefixed with 513 ADTS HEADER: 515 152 158 ... N 516 +---+---+---+---+---+---+---+... 517 | ADTS(56) | AAC SAMPLE | 518 +---+---+---+---+---+---+---+... 520 Binary concatenation of all AAC samples in "Audio Data" from 521 consecutive audio frames, without data loss MUST produce VALID AAC 522 bitstream. 524 For OPUS codec, "Audio Data" are 1 or more OPUS samples, prefixed 525 with OPUS header as defined in [RFC7845] 527 4.2.7. GOAWAY frame 529 0 1 2 3 4 5 6 7 530 +--------------------------------------------------------------+ 531 | 17 | 532 +--------------------------------------------------------------+ 533 | ID (64) | 534 +-------+------------------------------------------------------+ 535 | 0x14 | 536 +-------+ 538 The GOAWAY frame is used by the server to initiate graceful shutdown 539 of a connection, for example, for server maintenance. 541 Upon receiving GOAWAY, the client MUST send frames remaining in 542 current GOP and stop sending new frames on this connection. The 543 client SHOULD establish a new connection and resume sending frames 544 there. 546 After sending a GOAWAY frame, the server continues processing 547 arriving frames for an implementation defined time, after which the 548 server SHOULD close the connection. 550 4.3. QUIC Mapping 552 One of the main goals of the RUSH protocol was ability to provide 553 applications a way to control reliability of delivering audio/video 554 data. This is achieved by using a special mode Section 4.3.2. 556 4.3.1. Normal mode 558 In normal mode, RUSH uses one bidirectional QUIC stream to send data 559 and receive data. Using one stream guarantees reliable, in-order 560 delivery - applications can rely on QUIC transport layer to 561 retransmit lost packets. The performance characteristics of this 562 mode are similar to RTMP over TCP. 564 4.3.2. Multi Stream Mode 566 In normal mode, if packet belonging to video frame is lost, all 567 packets sent after it will not be delivered to application, even 568 though those packets may have arrived at the server. This introduces 569 head of line blocking and can negatively impact latency. 571 To address this problem, RUSH defines "Multi Stream Mode", in which 572 one QUIC stream is used per audio/video frame. 574 Connection establishment follows the normal procedure by client 575 sending Connect frame, after that Video and Audio frames are sent 576 using following rules: 578 * Each new frame is sent on new bidirectional QUIC stream 580 * Frames within same track must have IDs that are monotonically 581 increasing, such that ID(n) = ID(n-1) + 1 583 The receiver reconstructs the track using the frames IDs. 585 Response Frames (Connect Ack and Error), will be in the response 586 stream of the stream that sent it. 588 The client MAY control delivery reliability by setting a delivery 589 timer for every audio or video frame and reset the QUIC stream when 590 the timer fires. This will effectively stop retransmissions if the 591 frame wasn't fully delivered in time. 593 Timeout is implementation defined, however future versions of the 594 draft will define a way to negotiate it. 596 5. Error Handling 598 An endpoint that detects an error SHOULD signal the existence of that 599 error to its peer. Errors can affect an entire connection (see 600 Section 5.1), or a single frame (see Section 5.2). 602 The most appropriate error code SHOULD be included in the error frame 603 that signals the error. 605 5.1. Connection Errors 607 There is one error code defined in core of the protocol that 608 indicates connection error: 610 1 - UNSUPPORTED VERSION - indicates that the server doesn't support 611 version specified in Connect frame 613 5.2. Frame errors 615 There are two error codes defined in core protocol that indicate a 616 problem with a particular frame: 618 2 - UNSUPPORTED CODEC - indicates that the server doesn't support the 619 given audio or video codec 621 3 - INVALID FRAME FORMAT - indicates that the receiver was not able 622 to parse the frame or there was an issue with a field's value. 624 6. Extensions 626 RUSH permits extension of the protocol. 628 Extensions are permitted to use new frame types (Section 4), new 629 error codes (Section 4.2.4), or new audio and video codecs 630 (Section 4.2.6, Section 4.2.5). 632 Implementations MUST ignore unknown or unsupported values in all 633 extensible protocol elements, except codec id, which returns an 634 UNSUPPORTED CODEC error. Implementations MUST discard frames that 635 have unknown or unsupported types. 637 7. Security Considerations 639 RUSH protocol relies on security guarantees provided by the 640 transport. 642 Implementation SHOULD be prepare to handle cases when sender 643 deliberately sends frames with gaps in sequence IDs. 645 Implementation SHOULD be prepare to handle cases when server never 646 receives Connect frame (Section 4.2.1). 648 A frame parser MUST ensure that value of frame length field (see 649 Section 4.1) matches actual length of the frame, including the frame 650 header. 652 Implementation SHOULD be prepare to handle cases when sender sends a 653 frame with large frame length field value. 655 8. IANA Considerations 657 TODO: add frame type registry, error code registry, audio/video 658 codecs registry 660 9. Normative References 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, 664 DOI 10.17487/RFC2119, March 1997, 665 . 667 [RFC7845] Terriberry, T., Lee, R., and R. Giles, "Ogg Encapsulation 668 for the Opus Audio Codec", RFC 7845, DOI 10.17487/RFC7845, 669 April 2016, . 671 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 672 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 673 May 2017, . 675 Acknowledgments 677 This draft is the work of many people: Vlad Shubin, Nitin Garg, Milen 678 Lazarov, Benny Luo, Nick Ruff, Konstantin Tsoy, Nick Wu. 680 Authors' Addresses 682 Kirill Pugin 683 Facebook 684 Email: ikir@fb.com 686 Alan Frindell 687 Facebook 688 Email: afrind@fb.com 690 Jordi Cenzano 691 Facebook 692 Email: jcenzano@fb.com 694 Jake Weissman 695 Facebook 696 Email: jakeweissman@fb.com