Subject: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 23 Mar 2015 21:10:52 +0000

Dear all:

this draft was presented this morning at the ICCRG working group. The solution was highly criticized by the attendees as very preliminary and poorly justified. In fact, the draft was not recognizing the work done by the network community in making sure NC does not make congestion worse.

Knowing the draft has already been presented and a number of the nwcrg were in attendance I would suggest to take it out of the agenda and move the discussion to the list.

Thanks

Marie-José Montpetit
[email-masked]
[email-masked]

---

From: Vincent Roca <[email-masked]>
Date: Tue, 24 Mar 2015 07:19:08 -0500

Thanks for Marie-José.

I gave a quick look at the ICCRG slides (but not the I-D). It’s not the first time we have a Coded TCP proposal,
so if additionally there are serious CC issues suspected, it will perhaps be more efficient for the WG to devote
more time on the NC architecture (for instance).

BTW, Jonathan and myself have additional slides for the NC architecture discussion…

Cheers,

  Vincent

> Le 23 mars 2015 à 16:10, Marie-Jose Montpetit <[email-masked]> a écrit :
> 
> Dear all:
> 
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 24 Mar 2015 13:16:43 +0000

If we are going to discuss more on the architecture I would like to start moving into NC for transport and NC for forwarding so we can start having architecture drafts not just slide decks. And NC for transport can inherit from FECFRAME to speedup things even more.

Marie-José Montpetit
[email-masked]
[email-masked]

> On Mar 24, 2015, at 07:19, Vincent Roca <[email-masked]> wrote:
> 
> Thanks for Marie-José.
>

---

From: Brian Adamson <[email-masked]>
Date: Tue, 24 Mar 2015 10:45:20 -0400

I read through the draft.  I notice on the agenda we have assigned 15 minutes to the draft’s presentation.  I propose we reduce this to no more than 10 minutes and request the authors (cc’d) that they focus their presentation on what _differentiates_ their draft from other coded TCP approaches that have already been proposed. 

 If there was already discussion / critique of certain aspects of their proposal in the ICCRG (I wasn’t aware they were presenting there, too until after the fact), we don’t necessarily have to revisit that in NWCRG although I recommend NWCRG members to review the ICCRG minutes to understand those issues from that point of view.

In the beginning of this research group, we have leaned towards being more broadly accepting of presentations / proposals to help bootstrap the community and try to get disparate ideas on a more common footing to be able to more effectively discuss and develop network coding concepts for more general application.  The Internet is very much a multi-disciplinary terrain and so different participants may have different proficiencies and deficiencies with respect to different aspects so I think it’s good have peer review of what people are thinking in this new space (network coding).  However, I agree we are probably going to start being more selective and make sure new participants are pointed towards prior work/presentations as we amass more context with our research group’s progress.

cheers,

Brian

> On Mar 24, 2015, at 9:16 AM, Marie-Jose Montpetit <[email-masked]> wrote:
>

---

From: Victor Firoiu <[email-masked]>
Date: Tue, 24 Mar 2015 11:27:52 -0400

I concur with all. Thanks Brian.

Victor
On Mar 24, 2015 10:46 AM, "Brian Adamson" <[email-masked]>
wrote:

> I read through the draft.  I notice on the agenda we have assigned 15
> minutes to the draft’s presentation.  I propose we reduce this to no more
> than 10 minutes and request the authors (cc’d) that they focus their
> presentation on what _differentiates_ their draft from other coded TCP
> approaches that have already been proposed.
>
>  If there was already discussion / critique of certain aspects of their
> proposal in the ICCRG (I wasn’t aware they were presenting there, too until
> after the fact), we don’t necessarily have to revisit that in NWCRG
> although I recommend NWCRG members to review the ICCRG minutes to
> understand those issues from that point of view.
>
> In the beginning of this research group, we have leaned towards being more
> broadly accepting of presentations / proposals to help bootstrap the
> community and try to get disparate ideas on a more common footing to be
> able to more effectively discuss and develop network coding concepts for
> more general application.  The Internet is very much a multi-disciplinary
> terrain and so different participants may have different proficiencies and
> deficiencies with respect to different aspects so I think it’s good have
> peer review of what people are thinking in this new space (network
> coding).  However, I agree we are probably going to start being more
> selective and make sure new participants are pointed towards prior
> work/presentations as we amass more context with our research group’s
> progress.
>
> cheers,
>
> Brian
>
>
> > If we are going to discuss more on the architecture I would like to
> start moving into NC for transport and NC for forwarding so we can start
> having architecture drafts not just slide decks. And NC for transport can
> inherit from FECFRAME to speedup things even more.
> >
> > Marie-José Montpetit
> > [email-masked]
> > [email-masked]
> >
> >> so if additionally there are serious CC issues suspected, it will
> perhaps be more efficient for the WG to devote
> >>> this draft was presented this morning at the ICCRG working group. The
> solution was highly criticized by the attendees as very preliminary and
> poorly justified. In fact, the draft was not recognizing the work done by
> the network community in making sure NC does not make congestion worse.
> >>>
> >>> Knowing the draft has already been presented and a number of the nwcrg
> were in attendance I would suggest to take it out of the agenda and move
> the discussion to the list.
> >>>
> >>> Thanks
> >>>
> >>> Marie-José Montpetit
> >>> [email-masked]
> >>> [email-masked]

---

From: "wangjinzhu" <[email-masked]>
Date: Tue, 24 Mar 2015 10:57:04 -0500

Dear all
Let me clarify the differences between our project and the existing network
coding proposed:
1. our project try to add coding into TCP with minimal modification to the
current TCP stack. When receiving user data from the application, we first
encode them with redundancy involved, then deliver the coded packets into
the standard TCP stack to send. During the transmission, if packet loss
occurs and the redundancy can recover it, the TCP sender will still send
packets without reducing the CWND. 
2. < Network Coding Meets TCP: Theory and Implementation>: add the network
coding between the TCP stack and IP stack. Using the coding to involve the
redundancy and thus the receiver side can recover the packet loss. 
3. < Network Coded TCP (CTCP) >: based on the UDP, design a transport system
which combining the network coding with TCP functions. Also using the coding
to involve the redundancy and recover the packet loss. 
The common goal of all these methods is similar: using coding to involve the
redundancy. When packet loss occurs during the transmission, the redundancy
can recover the loss and thus throughput will not be reduced. 

In the iccrg, the challenge towards our project is that: we cannot
distinguish the network congestion loss from the link error loss. If the
packet lost is caused by wireless link error and the redundancy erase it, it
is good. However, if the packet loss is caused by the network congestion and
the redundancy recover it, it cannot be accepted. This will lead to : a.
network congestion is increased by pilling more packets into the congested
network; b. the coded TCP is unfair to the standard TCP.

To my understanding, the other coded TCPs already proposed will also
encounter similar problems. 

Best Regards,
Jinzhu

> -----Original Message-----
> From: nwcrg [mailto:[email-masked]] On Behalf Of Brian Adamson
> Sent: Tuesday, March 24, 2015 9:45 AM
> To: [email-masked]
> Cc: Gorry Fairhurst; Victor Firoiu; [email-masked]; Vincent
> Roca; [email-masked]; Marie-Jose Montpetit; 邓灵莉/Lingli
> Deng
> Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
> 
although
> I recommend NWCRG members to review the ICCRG minutes to understand
> those issues from that point of view.
> 
peer
> review of what people are thinking in this new space (network coding).
> However, I agree we are probably going to start being more selective and
> make sure new participants are pointed towards prior work/presentations as
> we amass more context with our research group’s progress.
> 
> cheers,
> 
> Brian
> 
> 
start
> moving into NC for transport and NC for forwarding so we can start having
> architecture drafts not just slide decks. And NC for transport can inherit
from
> FECFRAME to speedup things even more.
> >
> > Marie-José Montpetit
> > [email-masked]
> > [email-masked]
> >
> >> I gave a quick look at the ICCRG slides (but not the I-D). It’s not
> >> the first time we have a Coded TCP proposal, so if additionally there
> >> are serious CC issues suspected, it will perhaps be more efficient for
the
> WG to devote more time on the NC architecture (for instance).
> >>
poorly
> justified. In fact, the draft was not recognizing the work done by the
network
> community in making sure NC does not make congestion worse.
> >>>
> >>> Knowing the draft has already been presented and a number of the
> nwcrg were in attendance I would suggest to take it out of the agenda and
> move the discussion to the list.
> >>>
> >>> Thanks
> >>>
> >>> Marie-José Montpetit
> >>> [email-masked]
> >>> [email-masked]

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 24 Mar 2015 16:11:43 +0000

See below.

Marie-José Montpetit
[email-masked]
[email-masked]

> On Mar 24, 2015, at 10:57, wangjinzhu <[email-masked]> wrote:
> 
> Dear all

You have to explain to me how this works because it is not what your results show.

If you code the application data and THEN put it in TCP all TCP losses will not be recoverable and the CWND will reduce according to standard TCP behavior. TCP does not ack the correct recovery of the application data but the reception of TCP packets.

Since your results show gains you obviously do something else.

Also as was correctly pointed out at ICCRG yesterday not reducing the CWND in times of congestion is a really bad idea.

The determination of losses due to congestion vs. noise and the use of adequate congestion and flow control is an active field. While a lot of the work is proprietary I direct you to the recent work of Prof. Doug Leith of the Hamilton Institute.

snip/snip

---

From: Emmanuel Lochin <[email-masked]>
Date: Tue, 24 Mar 2015 17:12:29 +0100

> Dear all

Dear Jinzhu
> packets without reducing the CWND.

So does it mean that redundancy packets are sent through the TCP socket ?
As a result TCP does not differentiate redundancy from source packets 
and might retransmit redundancy packets if lost.
This approach is not optimal as TCP might already triggered a 
retransmission and I don't see the rationale to retransmit redundancy 
packets in the context of such coding scheme.

Regards

Emmanuel

-- 
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 91 85 - Fax (+33) 5 61 33 83 30
Web : http://personnel.isae.fr/emmanuel-lochin/
---
"This email and any attachments are confidential. They may contain legally privileged information
or copyright material. You should not read, copy, use or disclose them without authorisation.
If you are not an intended recipient, please contact us at once by return email and then delete
both messages. We do not accept liability in connection with computer virus, data corruption,
delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"

---

From: "wangjinzhu" <[email-masked]>
Date: Tue, 24 Mar 2015 11:46:38 -0500

Dear all 
Sorry for the Incomplete introduction. 

At the receiver side, coded TCP firstly check whether the lost packets can
be recovered by redundancy coding. If the lost can be recovered, the
receiver sends acks to senders that it receives all packets and thus the
CWND of sender is not reduced. To my understanding, the "seen ack" proposed
in the previous other coded TCPs is also similar to this.

Best Regards,
Jinzhu

> From: Emmanuel Lochin [mailto:[email-masked]]
> Sent: Tuesday, March 24, 2015 11:12 AM
> To: wangjinzhu; 'Brian Adamson'; [email-masked]
> Cc: 'Gorry Fairhurst'; 'Victor Firoiu'; 'Vincent Roca';
> [email-masked]; 'Marie-Jose Montpetit'; '邓灵莉/Lingli Deng'
> > Let me clarify the differences between our project and the existing
> > network coding proposed:
> > 1. our project try to add coding into TCP with minimal modification to
> > the current TCP stack. When receiving user data from the application,
> > we first encode them with redundancy involved, then deliver the coded
> > packets into the standard TCP stack to send. During the transmission,
> > if packet loss occurs and the redundancy can recover it, the TCP
> > sender will still send packets without reducing the CWND.
> 
> As a result TCP does not differentiate redundancy from source packets and
> might retransmit redundancy packets if lost.
retransmission
> and I don't see the rationale to retransmit redundancy packets in the
context
> of such coding scheme.
> 
> Regards
> 
> Emmanuel
> 
> > 2. < Network Coding Meets TCP: Theory and Implementation>: add the
> > network coding between the TCP stack and IP stack. Using the coding to
> > involve the redundancy and thus the receiver side can recover the packet
> loss.
> > 3. < Network Coded TCP (CTCP) >: based on the UDP, design a transport
> > system which combining the network coding with TCP functions. Also
> > using the coding to involve the redundancy and recover the packet loss.
> > The common goal of all these methods is similar: using coding to
> > involve the redundancy. When packet loss occurs during the
> > transmission, the redundancy can recover the loss and thus throughput
will
> not be reduced.
> > distinguish the network congestion loss from the link error loss. If
> > the packet lost is caused by wireless link error and the redundancy
> > erase it, it is good. However, if the packet loss is caused by the
> > network congestion and the redundancy recover it, it cannot be accepted.
> This will lead to : a.
> > network congestion is increased by pilling more packets into the
> > congested network; b. the coded TCP is unfair to the standard TCP.
> >
> >> Cc: Gorry Fairhurst; Victor Firoiu; [email-masked];
> >> Vincent Roca; [email-masked]; Marie-Jose Montpetit;
> >> 邓灵莉/Lingli
> >> Deng
> >> minutes to the draft’s presentation.  I propose we reduce this to no
> >> more than 10 minutes and request the authors (cc’d) that they focus
> >> their presentation on what _differentiates_ their draft from other
> >> coded TCP approaches that have already been proposed.
> >>
> >>   If there was already discussion / critique of certain aspects of
> >> their proposal in the ICCRG (I wasn’t aware they were presenting
> >> there, too
> > until
> >> In the beginning of this research group, we have leaned towards being
> >> more broadly accepting of presentations / proposals to help bootstrap
> >> the community and try to get disparate ideas on a more common footing
> >> to be able to more effectively discuss and develop network coding
> >> concepts for more general application.  The Internet is very much a
> >> multi-disciplinary terrain and so different participants may have
> >> different proficiencies and deficiencies with respect to different
> >> aspects so I think it’s good have
> > peer
> >> However, I agree we are probably going to start being more selective
> >> and make sure new participants are pointed towards prior
> >> work/presentations as we amass more context with our research
> group’s progress.
> >>
> >> cheers,
> >>
> >> Brian
> >>
> >>
> >> moving into NC for transport and NC for forwarding so we can start
> >> having architecture drafts not just slide decks. And NC for transport
> >> can inherit
> > from
> >>>> the first time we have a Coded TCP proposal, so if additionally
> >>>> there are serious CC issues suspected, it will perhaps be more
> >>>> efficient for
> > the
> >> nwcrg were in attendance I would suggest to take it out of the agenda
> >> and move the discussion to the list.
> >>>>> Thanks
> >>>>>
> >>>>> Marie-José Montpetit
> >>>>> [email-masked]
> >>>>> [email-masked]
> http://www.isae-supaero.fr Tel +33 5 61 33 91 85 - Fax (+33) 5 61 33 83 30
> "This email and any attachments are confidential. They may contain legally
> privileged information or copyright material. You should not read, copy,
use
> or disclose them without authorisation.
> If you are not an intended recipient, please contact us at once by return
> email and then delete both messages. We do not accept liability in
> connection with computer virus, data corruption, delay, interruption,
> unauthorised access or unauthorised amendment. This notice should not be
> removed"