Yes, that was my idea also. That would mean that we don't have to do
anything special to support rtx for perc, neither on the sfu nor in chrome,
rigth?
Best regards
Sergio
El 31/3/2017 19:29, "Emil Ivov" <emcho@xxxxxxxxx> escribió:
On Fri, Mar 31, 2017 at 12:22 PM, Emil Ivov <emcho@xxxxxxxxx> wrote:
I think I am now of the opinion that we should simply have a padding only
hack for chrome. That can be as simple as:
1. Padding only packets only go through e2e encryption
Sorry, I mean HBH here and not e2e (thanks Boris). In other words, the
content of the packet is in the clear and the zeros are fully visible
after the HBH enc is removed.
Emil
matches
2. When the SFU gets one it checks if it asked for it.
3. If the SFU didn't ask for it, it checks if it matches the pattern of a
padding only packet (i.e., the last two bytes contain a number that
the full lenght of the payload).adn
If we see anyone else than Chrome using such padding differently, we can
think about it then.
Emil
On Fri, 31 Mar 2017 at 12:05, Boris Grozev <boris@xxxxxxxxx> wrote:
Hi,
On 31/03/2017 07:40, Sergio Garcia Murillo wrote:
Yes, I think we agree.
How I plan to implement it in chrome is applying the inner encryption
just after the payload has been set in the packet (as I have just
discovered the hard way that extensions can't be modified after the
payload has been set), and let the packet continue its way. So, RTX
innerFEC will be calculated over the inner encryption (and DTLS/outher
encrypted later). OSN and outer padding will be be HBH encrypted only.
Also, as I won't be touching the RTX code, when it generates a probing
payload, it will not contain any payload at all, so it will not be
encrypted, and padding be set on the "outer packet".
I don't understand what setting padding on the outer packet means. RTX
can not modify the padding of a packet, it shares both the P-bit from
the header (padding present) and the last byte of the payload (padding
length) with the original packet.
One suggestion made during the PERC session on Wednesday was to use the
Original Sequence Number field to decide whether the received packet is
expected (a retransmission was requested) or not. One problem with this
is that there will always be *something* in the OSN field, and if it
happens to match a missing packet, then the RTX receiver will try to
process the packet. Emil suggested that the sender intentionally uses
sequence number which are unlikely to match a missing packet.
Regards,
Boris
--
https://jitsi.org
