Re: [EToSat] about LOOPS(Localized Optimization of Path Segments) and etosat

And just to be clear (at least as clear as I can be, on January 3),

On Thu, Jan 3, 2019 at 3:10 PM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Dear All,
>
> On Thu, Jan 3, 2019 at 1:46 PM Marie-Jose Montpetit <marie@mjmontpetit.com>
> wrote:
>
>> The files also refer to the nwcrg on-going work. It is a common practice
>> to run coded (FEC) sessions over tunnels to isolate the effects of coding
>> across paths. And we have work on nw coding over satellite also. Would this
>> group be open for me to send this thread over to our list?
>>
>> Also in the COIN proposed RG we are also looking at per hop optimization
>> but in the context of in-network computing (and that includes FEC,
>> transcoding, pre-fetching, data decompostion etc.) which I can see are also
>> related. So I could copy there too.
>>
>
I would be fine with these discussions happening where they need to happen.

Do the right thing, of course!

Spencer

>
>> Thanks for copying me.
>>
>> mjm
>>
>>
>> Marie-Jose Montpetit, Ph.D.
>> mariejo@mit.edu
>> marie@mjmontpetit.com
>> +1-781-526-2661
>> @SocialTVMIT
>>
>>
>>
>> On Jan 3, 2019, at 12:48 PM, Border, John <John.Border@hughes.com> wrote:
>>
>>
>>
>> Clearly LOOPS should not focus only on satellite.  But, I think LOOPS is
>> directly relevant to ETOSAT.  Techniques like LOOPS are likely to be a key
>> part of the solution to the performance over satellite problem.
>>
>> I will be sending out an email to ETOSAT in the next couple of days to
>> try to kickstart discussion overall.
>>
>>
>> John
>>
>>
>>
>> -----Original Message-----
>> From: Carsten Bormann <cabo@tzi.org>
>> Sent: Friday, December 07, 2018 5:59 PM
>> To: Border, John <John.Border@hughes.com>
>> Cc: Liyizhou <liyizhou@huawei.com>
>> Subject: Re: about LOOPS(Localized Optimization of Path Segments) and
>> etosat
>>
>> WARNING: The sender of this email could not be validated and may not
>> match the person in the "From" field.
>>
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you recognize the sender and know
>> the content is safe.
>>
>>
>> WARNING: The sender of this email could not be validated and may not
>> match the person in the "From" field.
>>
>> Hi John,
>>
>> On Dec 7, 2018, at 10:37, Liyizhou <liyizhou@huawei.com> wrote:
>>
>> I copied to Carsten who was leading the side meeting. He might provide
>> more information.
>>
>>
>> As Yizhou said, there are no formal minutes of this side meeting, but I
>> did record my impressions in the attached short summary.  I have also
>> attached the slides that we used, as the summary may not be comprehensible
>> without those.
>>
>> Given that Spencer specifically asked us to discuss this in the context
>> of etosat, it would certainly help to know what the intentions were in
>> creating this list and to speculate a bit how a potential etosat activity
>> might cross-pollinate with LOOPS.
>>
>> Grüße, Carsten
>> <Summary of the IETF103 LOOPS side meeting, 2018-11-06.pdf><LOOPS.pdf>
>>
>>
>> _______________________________________________
>> EToSat mailing list
>> EToSat@ietf.org
>> https://www.ietf.org/mailman/listinfo/etosat
>
>
> My intention for creating this mailing list was as a first step toward
> working through the performance implications of encryption in situations
> where end-to-end performance mechanisms may encounter difficulty because of
> path characteristics, which (thinking out loud) could involve one
> problematic hop, or multiple problematic hops, and non-end-to-end
> mechanisms aren't able to assist now, if traffic is encrypted.
>
> (Note - this was in the context of comparing HTTP over QUIC to HTTP over
> TCP, and we all realize (I hope that TCP stacks have decades of hand
> optimization and QUIC implementations do not. My intuition is that even
> with tuning, QUIC may be at a disadvantage on paths containing satellite
> links, so there is a real underlying problem to be solved)
>
> I created this list at John's request during IETF 101, and John's concern
> was specifically related to paths containing at least one satellite link,
> because we know that's broken.
>
> At IETF 103, I started thinking that LOOPS was facing the same problem, in
> an entirely different application, so believe it is appropriate to use this
> mailing list to explore what specific technical challenges the two sets of
> proponents have in common. And I suspect the satellite community and the
> LOOPS community may not be the only two communities with similar problems
> in this space.
>
> I have guesses about where this discussion might go, but for now, I'll let
> people continue to work together. Make good choices!
>
> Spencer
>