- From: Ian Swett <ianswett@google.com>
- Date: Sun, 13 Oct 2019 18:35:20 -0400
- To: Lars Eggert <lars@eggert.org>
- Cc: lionel.morand@orange.com, "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, "allison.mankin@gmail.com" <allison.mankin@gmail.com>, "quic-chairs@ietf.org" <quic-chairs@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "quic@ietf.org" <quic@ietf.org>, "quic-ads@ietf.org" <quic-ads@ietf.org>, "httpbis-ads@ietf.org" <httpbis-ads@ietf.org>
- Message-ID: <CAKcm_gObjr+EQQH1DKsvFWkJ8xkj_50NyzvLeYfkYbjw2X_K5A@mail.gmail.com>
If the main concern is inability to passively measure packet loss and as Lars said this is not for end-to-end user traffic(so support for certain extensions could be assumed), then this could be a good test case for draft-ferrieuxhamchaoui-quic-lossbits <https://tools.ietf.org/html/draft-ferrieuxhamchaoui-quic-lossbits-01> to prove it works as intended and see if the mechanism needs any changes. On Sun, Oct 13, 2019 at 4:34 AM Lars Eggert <lars@eggert.org> wrote: > Hi Lionel, > > On 2019-10-12, at 11:24, <lionel.morand@orange.com> < > lionel.morand@orange.com> wrote: > > Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). > > I do not see this liaison statement posted at > https://datatracker.ietf.org/liaison/. Please make sure to submit it via > the regular process, to keep all relevant entities in the loop. > > > This WG is actually studying the introduction of QUIC as transport > protocol instead of HTTP/2 in the 5G core network. > > The WG has some questions regarding the troubleshooting capabilities > supported by QUIC compared to the ones available with TCP. > > Based on my (limited) understanding of the 5G architecture, this use of > QUIC would be as a protocol for carrying control information inside a 5G > network control plane. In other words, it is not about the end-to-end use > of QUIC over paths that traverse 5G networks. Is my understanding correct? > > Thanks, > Lars > > > The LS is officially addressed to the QUIC WG. However, it was > highlighted that httpbis WG could also be interested in. I will let you > decide if only QUIC or both are relevant in the discussion. > > > > Next CT4 WG meetings: > > 3GPP TSG CT4#95 11th – 15th November 2019 Reno, US > > 3GPP TSG CT4#96 24th – 28th February 2020 Sophia > Antipolis, FR > > > > It would be good to receive an official feedback at the latest for the > February meeting, where the study will be concluded (at least for this > release). > > > > Regards, > > > > <image001.jpg> > > > > Lionel Morand > > Chair of 3GPP TSG CT > > 3GPP Liaison Person to IETF > > Chair of IETF Dime and Radext WGs > > Core Network Senior Architect and Diameter expert > > Cell. +33 6 07 75 89 36 <+33%206%2007%2075%2089%2036> > > lionel.morand@orange.com > > > > > > > > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > > > <Liaison Statement on QUIC network level troubleshooting > capabilities.docx> > >
Received on Sunday, 13 October 2019 22:35:35 UTC