Subject: Re: [nwcrg] nwcrg Digest, Vol 24, Issue 28

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 26 Mar 2015 10:20:51 -0500

Just use a standard TCP ladder and add the operations you are proposing for the coding.

> On Mar 26, 2015, at 10:17 AM, [email-masked] wrote:
> 
> Send nwcrg mailing list submissions to
> 	[email-masked] <mailto:[email-masked]>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> or, via email, send a message with subject or body 'help' to
> 	[email-masked] <mailto:[email-masked]>
> 
> You can reach the person managing the list at
> 	[email-masked] <mailto:[email-masked]>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nwcrg digest..."
> Today's Topics:
> 
>   1. Re: draft-wang-tsvwg-tcp-coding-00.txt (wangjinzhu)
> 
> From: "wangjinzhu" <[email-masked] <mailto:[email-masked]>>
> Cc: 'Victor Firoiu' <[email-masked] <mailto:[email-masked]>>, 'Gorry Fairhurst' <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>, 'Vincent Roca' <[email-masked] <mailto:[email-masked]>>, 'JinzhuWang' <[email-masked] <mailto:[email-masked]>>, 'Brian Adamson' <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>, 'Emmanuel Lochin' <[email-masked] <mailto:[email-masked]>>
> To: "'Marie-Jose Montpetit'" <[email-masked] <mailto:[email-masked]>>
> Date: March 26, 2015 at 10:16:28 AM CDT
> Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
> 
> 
> Would you please give me a example of the ladder diagram. I have no idea of what kind of ladder diagram I need to provider.
> Thanks
>  
> Best Regards,
> Jinzhu
>  
> From: nwcrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Marie-Jose Montpetit
> Sent: Thursday, March 26, 2015 10:03 AM
> To: wangjinzhu
> Cc: Victor Firoiu; Gorry Fairhurst; [email-masked] <mailto:[email-masked]>; Vincent Roca; JinzhuWang; Brian Adamson; [email-masked] <mailto:[email-masked]>; Emmanuel Lochin
> Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
>  
> Like I said before a ladder diagram would help. 
>  
> /mjm
> Marie-Jose Montpetit, Ph.D.
> [email-masked] <mailto:[email-masked]>
> @SocialTVMIT
>  
> On Mar 26, 2015, at 9:52 AM, wangjinzhu <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Dear Marie-Jose
> Thanks very much for your introductions, which are important to us J
> As for the “added RTT”, to my understanding, compared to the standard TCP, We don’t bring in the added RTT since the standard TCP also need this RTT.
> I would like to give more  introductions to our implementation on the Friday.
>  
> Best Regards,
> Jinzhu
>  
>  
> From: nwcrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Marie-Jose Montpetit
> Sent: Wednesday, March 25, 2015 3:59 AM
> To: JinzhuWang
> Cc: Victor Firoiu; Gorry Fairhurst; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Vincent Roca; Brian Adamson; [email-masked] <mailto:[email-masked]>; Emmanuel Lochin
> Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
>  
> This was suggested as good to read at the Transport Area Working group meeting yesterday:
> https://tools.ietf.org/html/rfc6077 <https://tools.ietf.org/html/rfc6077>
>  
> There was some discussion on https://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-req-arch-00 <https://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-req-arch-00>; they also have implemented a way to improve the TCP performance by dealing with slow start - but not with coding. Some of the comments were that “slow start” was slow for a reason :-) But there will most  likely be a follow on.
>  
> And of course as you are well aware there is a whole IRTF group on the subject. In my opinion dealing with congestion control. CC is only a nwcrg as far as ensuring that the NC packets “behave”.
>  
> As far as the “problem you encounter” it is also not a nwcrg “specific”. The impact of noise and delay on the tcp behavior is well known - I have actually spent most of my career dealing with it. 
>  
> The pilc wg years ago addressed it (it is now closed): 
> http://www.ietf.org/wg/concluded/pilc.html <http://www.ietf.org/wg/concluded/pilc.html>
> In particular see the RFC on link errors: http://www.ietf.org/rfc/rfc3155.txt <http://www.ietf.org/rfc/rfc3155.txt>
> And the general advice to link designers: http://www.ietf.org/rfc/rfc3819.txt <http://www.ietf.org/rfc/rfc3819.txt> (that one has a nice if not now slighly outdated list of references)
>  
> So “your problem” is everyone’s problem and we have been aware of it for over 15 years ever since WIFI and IP over mobile technologies became prevalent. There is also heritage in adding application layer FEC to improve efficiency. See the FECFRAME (https://datatracker.ietf.org/wg/fecframe/charter/ <https://datatracker.ietf.org/wg/fecframe/charter/>) and even work done before that (this is 1997: http://140.98.202.196/xpl/articleDetails.jsp?tp=&arnumber=581546&searchWithin%3Dp_Authors%3A.QT.Linder%2C+H..QT. <http://140.98.202.196/xpl/articleDetails.jsp?tp=&arnumber=581546&searchWithin=p_Authors:.QT.Linder,+H..QT.>). And adding NC to try to fix the problem is not really new. What all of this showed was that yes using coding helps but TCP is tricky because of the congestion control mechanisms.
>  
> So the added RTTs to ACKs in your solution will eventually reduce the TCP efficiency not improve it. The fact you are showing positive results tells me there is something missing in your document about what was actually done. You have 10 minutes on Friday. My suggestion, having seen your slides is to go directly to the implementation and results and to justify how you got the latter.
>  
>  
> Marie-Jose Montpetit, Ph.D.
> [email-masked] <mailto:[email-masked]>
> @SocialTVMIT
>  
> On Mar 25, 2015, at 2:06 AM, Emmanuel Lochin <[email-masked] <mailto:[email-masked]>> wrote:
>  
> On 24/03/2015 22:29, JinzhuWang wrote:
> I acknowledge my implement change congestion control and I'm not intending to make my approach to be accepted. I just try to clarify the problem we encounter. 
> 
> No worries this is of interest :)
> 
> 
> 
>  
> I do not know whether nwcrg has discussed the congestion control issue in previous coding tcp. I have analyzed  the previous works and can not find the proper solution.  
> 
> Ok but what did you identify, how, and what do you propose?
> It is always interesting to get feedback from people that implement such solution, but you only focus on the way packets are encoded and this is the common part everybody knows.
> The tricky part, I reckon, deals with the interaction between the tranport layer and the coding layer. In particular, the draft does not explain whether:
> - you apply NC to slowstart and how you get out this phase
> - you manage the congestion avoidance phase and the impact of recovered lost packets on the CC
> 
> Emmanuel
> 
> 
> 
>  
> Best Regards,
> Jinzhu
>  
> From: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Date: Tue, 24 Mar 2015 21:15:36 +0000
> CC: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
> 
> Actually my understanding is that you introduce another RTT in case of unrecovered loss - that's why we need a ladder.
>  
> As far as the CC and the 'unfairness' I already said many groups are working on it. Just stating 'other implementations have had it' is not a justification for your approach to be acceptable.
>  
> 
> 
> Marie-José Montpetit
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
> On Mar 24, 2015, at 16:04, JinzhuWang <[email-masked] <mailto:[email-masked]>> wrote:
> 
> The benefit of our project is that if the packet loss can be recovered by the redundancy, the sender no need to retransmit the lost packet. On the other hand, If the packet loss can not be recovered by redundancy, we need the sender to retransmit after timeout. 
>  
> the congestion control is changed because the redundancy recover the lost packet. When packet lost by network congestion, the standard TCP detect the packet loss and reduce the CWND. While the coded TCP recover the packet loss by redundancy and not reduce the CWND. This will change TCP congestion control and make the coding TCP unfair to standard TCP.  To my understanding, this problem exists in other previous proposed coding TCPs.
>  
> Best Regards,
> Jinzhu
>  
> From: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Date: Tue, 24 Mar 2015 20:34:40 +0000
> CC: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
> 
> This needs a ladder diagram as I don't see how this approach can result in gains because of the additional delays (time outs). 
>  
> How were the tests conducted whose results are shown in the draft?
>  
> And of course the congestion control has not been addressed...
> 
> Marie-José Montpetit
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
> On Mar 24, 2015, at 15:25, JinzhuWang <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Yes, if the redundancy can not recover the packet loss, the sender needs one RTT to get this information. 
>  
> Best Regards,
> Jinzhu
> 
> > Date: Tue, 24 Mar 2015 20:54:37 +0100
> > From: [email-masked] <mailto:[email-masked]>
> > To: [email-masked] <mailto:[email-masked]>
> > CC: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
> > 
> > So in this case the performance obtained is the same than if you had retransmitted the missing source data packets because you need one RTT to get this information.
> > I mean you behave exactly as TCP except that you send repair rather than duplicate source packets as redundancy.
> > 
> > EL
> > 
> > --
> > 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/ <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 20:08, JinzhuWang <[email-masked] <mailto:[email-masked]>> a écrit :
> > >
> > > > > 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] <mailto:[email-masked]>
> > > > To: [email-masked] <mailto:[email-masked]>
> > > > CC: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > > > Subject: Re: [nwcrg] draft-wang-tsvwg-tcp-coding-00.txt
> > > > 
> > > > 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/ <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] <mailto:[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] <mailto:[email-masked]>]
> > > > > > Sent: Tuesday, March 24, 2015 11:12 AM
> > > > > > To: wangjinzhu; 'Brian Adamson'; [email-masked] <mailto:[email-masked]>
> > > > > > Cc: 'Gorry Fairhurst'; 'Victor Firoiu'; 'Vincent Roca';
> > > > > > [email-masked] <mailto:[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] <mailto:[email-masked]>] On Behalf Of Brian
> > > > > > >> Adamson
> > > > > > >> Sent: Tuesday, March 24, 2015 9:45 AM
> > > > > > >> To: [email-masked] <mailto:[email-masked]>
> > > > > > >> Cc: Gorry Fairhurst; Victor Firoiu; [email-masked] <mailto:[email-masked]>;
> > > > > > >> Vincent Roca; [email-masked] <mailto:[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] <mailto:[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] <mailto:[email-masked]>
> > > > > > >>> [email-masked] <mailto:[email-masked]>
> > > > > > >>>
> > > > > > >>>> On Mar 24, 2015, at 07:19, Vincent Roca <[email-masked] <mailto:[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] <mailto:[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] <mailto:[email-masked]>
> > > > > > >>>>> [email-masked] <mailto:[email-masked]>
> > > > > > >>>>> _______________________________________________
> > > > > > >>>>> nwcrg mailing list
> > > > > > >>>>> [email-masked] <mailto:[email-masked]>
> > > > > > >>>>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> > > > > > >>> _______________________________________________
> > > > > > >>> nwcrg mailing list
> > > > > > >>> [email-masked] <mailto:[email-masked]>
> > > > > > >>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> > > > > > >>>
> > > > > > >> _______________________________________________
> > > > > > >> nwcrg mailing list
> > > > > > >> [email-masked] <mailto:[email-masked]>
> > > > > > >> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > nwcrg mailing list
> > > > > > > [email-masked] <mailto:[email-masked]>
> > > > > > > https://www.irtf.org/mailman/listinfo/nwcrg <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 <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/ <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] <mailto:[email-masked]>
> > > > > https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> > > > _______________________________________________
> > > > nwcrg mailing list
> > > > [email-masked] <mailto:[email-masked]>
> > > > https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> > _______________________________________________
> > nwcrg mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> 
> _______________________________________________ nwcrg mailing list [email-masked] <mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> 
> _______________________________________________ nwcrg mailing list [email-masked] <mailto:[email-masked]> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> 
> 
> 
> 
> _______________________________________________
> nwcrg mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/nwcrg <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 <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/ <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] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>