Subject: [multipathtcp] infering DATA ACKs to save option space

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 18 Aug 2010 01:26:20 -0700

Hi folks,

In the current draft, whenever the DATA_ACK advances we need to add DATA ACK
option.
However, this is a bit expensive when we think about option space
limitation.

So, here is an idea.
I tend to think we need to a method to infer DATA ACK from the ACK of
subflow rather than using options.
I believe I basically understand the risk for not using explicit
signalling.
For example, in the example in the design decision doc (
http://nrg.cs.ucl.ac.uk/mjh/design-decisions.pdf) illustrated in figure 1,
the receiver needs to add DATA ACK option when it sends ACK 20, otherwise
we'll encounter several issues.

However, my interpretation here is this is because this ack packet needs to
acknowledge data from other subflows.
In other words, when DATA ACK is advanced, if the advance is caused by the
subflow which is going to send an ack packet,
we can avoid using DATA ACK option. If we use the previous example, when
receiver sends ACK 20, we need to add DATA ACK option,
but when the receiver sends ACK 10, adding DATA ACK is not necessary because
the sender can infer it.

In order to implement this idea, we need to add special rules to sender and
receiver. It will be something like:

 Sender:
    when ACK packets arrive without DATA ACK (and if the ACK seq is covered
by Data Sequence Mapping), it calculates the DATA ACK from the mapping

 Receiver:
    When DATA ACK is advanced, if the advance is caused by the subflow which
is going to send an ack packet, the receiver MAY avoid adding DATA ACK.
    If not, add DATA ACK.

I think this algorithm will be useful at least in the two cases, one is when
mptcp uses only one subflow and the other is when receiver sends acks with
SACK option.
For both cases, we can avoid adding DATA ACK with this algorithm.

--
Yoshifumi Nishida
[email-masked]

---

From: Costin Raiciu <[email-masked]>
Date: Mon, 23 Aug 2010 09:51:54 +0300

Hi Yoshifumi,

I think optimizing option space usage is a worthy goal. I haven't thought through your proposals but they seem sensible.
However, I do think that we may need some sort of modelling to analyze all possible ack reordering types - otherwise we might end up in cases where we are shooting ourselves in the foot with optimizations :).

Cheers,
Costin

On 18 Aug 2010, at 11:26, Yoshifumi Nishida wrote:

> Hi folks,
> 
> In the current draft, whenever the DATA_ACK advances we need to add DATA ACK option.
> However, this is a bit expensive when we think about option space limitation.
> 
> So, here is an idea.
> I tend to think we need to a method to infer DATA ACK from the ACK of subflow rather than using options.
> I believe I basically understand the risk for not using explicit signalling. 
> For example, in the example in the design decision doc (http://nrg.cs.ucl.ac.uk/mjh/design-decisions.pdf) illustrated in figure 1, 
> the receiver needs to add DATA ACK option when it sends ACK 20, otherwise we'll encounter several issues.
> 
> However, my interpretation here is this is because this ack packet needs to acknowledge data from other subflows. 
> In other words, when DATA ACK is advanced, if the advance is caused by the subflow which is going to send an ack packet, 
> we can avoid using DATA ACK option. If we use the previous example, when receiver sends ACK 20, we need to add DATA ACK option, 
> but when the receiver sends ACK 10, adding DATA ACK is not necessary because the sender can infer it.
> 
> In order to implement this idea, we need to add special rules to sender and receiver. It will be something like:
> 
>  Sender:
>     when ACK packets arrive without DATA ACK (and if the ACK seq is covered by Data Sequence Mapping), it calculates the DATA ACK from the mapping
> 
>  Receiver:
>     When DATA ACK is advanced, if the advance is caused by the subflow which is going to send an ack packet, the receiver MAY avoid adding DATA ACK.
>     If not, add DATA ACK.
> 
> I think this algorithm will be useful at least in the two cases, one is when mptcp uses only one subflow and the other is when receiver sends acks with SACK option.
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp