Re: The first octet

[Ian Swett <[e-mail]>]

Thanks Roni, agreed, let's focus on the issues Martin raised.

On Wed, Aug 8, 2018 at 9:55 AM Roni Even (A) <[e-mail]> wrote:

> Hi,
> In London the spin bit and VEC were not discussed in the session, my take
> from the offline discussions we had was that currently we experimented with
> good results only the spin bit. It also seemed that the current VEC as
> proposed in Brians's draft is not good enough and we intend to look at
> other algorithms that will provide better results for packet loss using the
> 2 bits.
> I think that this discussion is pre mature and that it should be discussed
> in the future
> Roni
>
> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Wednesday, August 08, 2018 4:44 PM
> To: Ian Swett
> Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku
> Subject: Re: The first octet
>
> Sure:
>
>   - spin+VEC are documented in draft-trammel-spin-03
>
>   - 7 bits for packet loss were presented at
>       http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf
>
> Re "I'm curious why you'd even want them": please clarify which applies:
>
>   (a) you recognize the criticality of loss location, but you have a
> cleverer algorithm to do the same with fewer than 7 bits
>
>   (b) you don't believe network operators need to locate losses
>
>
> On 08/08/18 15:29, Ian Swett wrote:
> > I'm having a hard time understanding why you'd need 7 bits to measure
> > packet
> > loss(1 seems sufficient in most cases), can you send a link to the
> > spin + VEC and 7 bit proposals you mentioned?
> >
> > I'll also note I think the chances the WG will agree to 7 bits is
> > extremely close to 0, but I'm curious why you'd even want them.
> >
> > On Wed, Aug 8, 2018 at 9:22 AM <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     On 08/08/18 12:05, Martin Thomson wrote:
> >      >
> >      > I know you discussed taking more bits and even bytes, but the case
> >      > hasn't been made in this working group to my knowledge.  I
> certainly
> >      > don't think that's justified; it improved fidelity of
> measurements,
> >      > but the spin bit appears to be pretty good at that without the
> extra
> >      > overheads.
> >
> >     Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin
> bit + VEC)
> >     for RTT measurements, right.
> >
> >     However, measurements also include packet loss, which is typically
> more
> >     widespread than delay in big pipes (which don't have enough RAM to
> keep a
> >     packet
> >     for too long at line rate). And spin+VEC do not address packet loss
> at all,
> >     hence our 7-bit spin counter proposal shown in London.
> >
> >     I admit that 7 is hefty if you're starting from Christian's songle
> spin bit ;
> >     however:
> >
> >        - I assume nobody will emit any doubt about the criticality of
> >     non-delay-related (big pipe) loss location. Unless everybody here
> has perfect
> >     networks and ideal reporting, that is.
> >
> >        - Stick the spin bit on top of these 7, make that an extra
> easurement
> >     byte and
> >     you've got your three spare bits again in the first byte.
> >
> >
> >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> >     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.
> >
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>