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

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

OK for the way the decoding is done. But at the sender side : does TCP carry the whole traffic redundancy included ?

Emmanuel

--
Emmanuel Lochin 
Professeur ISAE - OSSI 
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) 
Issu du rapprochement SUPAERO et ENSICA 
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 
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" Le 24 mars 2015 17:46, wangjinzhu <[email-masked]> a écrit :
>
> 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
>
> > -----Original Message-----
> > 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'
> > Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
> > 
> > On 24/03/2015 16:57, wangjinzhu wrote:
> > > Dear all
> > 
> > Dear Jinzhu
> > > 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.
> > 
> > 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
> > 
> > > 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
> > >>
> > >> 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:
> > >>> 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é.
> > >>>>
> > >>>> 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:
> > >>>>>
> > >>>>> 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]
> > >>>>> _______________________________________________
> > >>>>> nwcrg mailing list
> > >>>>> [email-masked]
> > >>>>> https://www.irtf.org/mailman/listinfo/nwcrg
> > >>> _______________________________________________
> > >>> nwcrg mailing list
> > >>> [email-masked]
> > >>> https://www.irtf.org/mailman/listinfo/nwcrg
> > >>>
> > >> _______________________________________________
> > >> nwcrg mailing list
> > >> [email-masked]
> > >> https://www.irtf.org/mailman/listinfo/nwcrg
> > >
> > >
> > > _______________________________________________
> > > nwcrg mailing list
> > > [email-masked]
> > > https://www.irtf.org/mailman/listinfo/nwcrg
> > 
> > 
> > --
> > 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"
>
>
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 24 Mar 2015 17:38:41 +0000

And of course what are the delays?

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

> On Mar 24, 2015, at 11:52, Emmanuel Lochin <[email-masked]> wrote:
>

---

From: JinzhuWang <[email-masked]>
Date: Tue, 24 Mar 2015 19:08:49 +0000

> > OK for the way the decoding is
done. But at the sender side : does TCP

> > carry the whole traffic
redundancy included ?

[Jinzhu] Yes, the TCP carry the
redundancy to send. When the redundancies lost, if the receiver can decode the
original packets successfully, then it acks that all packets are received and
thus the lost redundancy will not be retransmitted since the sender do not know
the loss in this case. On the other hand, if the receiver cannot decode the
original packets, the redundancy is retransmitted by the sender. In the sender
side, we ensure that all coded packets are linear independent and thus the
retransmitted redundancy can help the receiver to decode.

Best Regards,

Jinzhu
> Date: Tue, 24 Mar 2015 17:51:55 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]