Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Michael Tuexen <[e-mail]>]

On Apr 24, 2013, at 4:03 PM, Bernard Aboba wrote:

> Michael said:
> > I guess you are considering the case where the OPEN message was dropped by the network multiple times...
>  
> [BA] Right.  That's the case in which the details of the OPEN transport makes a difference.
>  
> > The sender and receiver normally bound the memory for processing data (socket buffers). So
> > your above only applies if the send buffer is larger than 9.6 MB. 
>  
> [BA] The assumption is that the receiving application processes the incoming data, so that the RWIN does not decrease.  If the data is sent unordered and unreliable, and is acknowledged by SACK chunks (e.g. only the OPEN is lost), the sender can send this much data (assuming that it has that much to send).  
That is right for the receiver. But the sender has to buffer the sent messages until they
are acknowledged by the cumack, not only by SACK gat reports. So if the OPEN message
was lost, it is not acked and no TSN after it can be cumacked, only gap-acked. That
is why the sender can't remove it from its send buffer. So the limiting point is
the send buffer size of the sender, not a buffer on the receiver side.
>  
> > Often, the send and receiver buffer are the same and reflect the RWIN, so you are considering on the receiver side a 16 KB buffer, on the sender side a 10 MB buffer.
>  
> [BA] No.  You can have 16 KB on both sides and the sender can end up sending this much, as long as the data isn't lost and the receiving application keeps processing it.  Because of that the RWIN does not limit the sender. 
No. If the send buffer is 16 KB, the sender can only hold up to 16 KB for retransmissions. It has
to buffer TSNs, even if they are gap acked since they can be reneged.
The only way around this is to use the NR-SACK extension (which allows to gap ack
TSN's indicating that they won't be reneged), but this is not an RFC yet...

Best regards
Michael
> 
>