[Nfd-dev] about draft-irtf-icnrg-IPOC

[David R. Oran]

Thanks for taking this up. Since the document is in last call in the 
ICNRG, these comments ought to make it to the whole group (I don’t 
think it’s my place to forward, so Susmit or others can decide how to 
handle this).

As a reminder, Last Call is our formal review process, so the timing is 
excellent, as these will help us decide whether it’s appropriate to 
move IPOC forward, or recommend it be recycled for more work.

For me personally, these points recapitulate the intense conversations 
Ilya Moiseenko and I had when working on our paper a few years ago. Many 
of these issues are what led us to tackle TCP as the Internet protocol 
to tunnel over ICN rather than raw IP. I still think that was the right 
choice (of course today we probably would have QuIC rather than TCP, but 
that’s another possibly relevant discussion).

In general, I think it’s way better to converge a layer 4 protocol on 
top of a different layer 3 protocol than to attempt recursive tunneling 
L3 over L3. For people interested, I think the paper is still fairly 
relevant: 
http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf

Cheers, DaveO.


On 14 Jul 2020, at 20:21, Lixia Zhang wrote:

> Hi Susmit,
>
> thanks a lot for helping out with the specifics regarding the 
> motivations and designs behind IPOC internet-draft that we discussed 
> last Friday.
> To answer the question you asked at the end about which way I’d like 
> to get my comments back to all the authors: my worry about going to 
> ICNRG is that I might not be able to keep up with discussions there:(
> (students and I went thru all email about IPOC this time because 
> it’s just a one-time obligation)
>
> Wonder if you could help pass the following to your coauthors:
>
> 1/ I strongly suggest to avoid abusing interest packets to carry 
> actual payload, IP packets in your design.
>
> a) an interest is meant to retrieve a data packet, that’s why it 
> hangs on PIT at every hop until the data packet comes back (or 
> otherwise timeout).
> Buffering lots IP packet in the PIT is *bad*, as it takes space and 
> totally useless.  Data packet in CS can be useful even for one-one 
> communication: in case the packet lost, retransmitted interest will 
> get it from the CS just before the loss point.
>
> b) signed interest is meant to authenticate interest that causes state 
> changes, not for payload authentication.
>
> 2/ if one must use NDN to carry IP packets, let’s treat each IP 
> packet as a data packet in both directions, instead of just one 
> direction.
>
> You may ask: how to “push” a received IP packet -- may try a 
> combination of a few ways:
> each end could try to fetch *opportunistically*; this could be pretty 
> effective if one can make use of recognized patterns in IP packet 
> arrivals, and the opportunistic fetching interest have a not-too-short 
> lifetime.
> in case needed, send a probe interest to trigger the other end sending 
> an interest; this probe interest could have a very short lifetime as 
> it’s not meant to wait for data. This is still a lot better than 
> buffering IP packets in PIT.
> Yes there could be a bit delay but look, even in your current design, 
> the IPOC gateway has to wait for Interest form IPOC client already.
> The main drawback is doubling packet count, but perhaps not much 
> increase on router memory consumption since
> - interest packets are small in size;
> - using real data packets to carry IP packets is probably more 
> economical in byte count as compared to abusing interests to carry IP 
> packets.
>
> Doing things in the right way would have a better potential to attract 
> others to your work, I believe.
>
> Just my 2 cents,
> Lixia


> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

DaveO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200715/87cb9733/attachment-0001.html>