Subject: [icnrg] Where to locate L, R and CC?

From: Börje Ohlman <[email-masked]>
Date: Tue, 4 Apr 2017 14:02:53 +0000

This email is relating to the presentation I made at the ICNRG interim meeting in Chicago: https://www.ietf.org/proceedings/interim-2017-icnrg-01/slides/slides-interim-2017-icnrg-01-sessa-framework-for-loss-detec0on-retransmission-and-conges0on-control-in-icn-borje-ohlman-00.pdf

I think the discussion on where to locate L, R and CC in ICN is an interesting discussion that merits further elaboration. Personally I don’t have strong opinions on this at this point in time but I’m most interested in hearing what opinions there are on this out there in ICN land. So some questions I would be happy to hear peoples views on are:

  1.  Should  L, R and CC be located in the same layer?
  2.  Where is the best place to do L?
  3.  Where is the best place to do R?
  4.  Where is the best place to do CC?

If you have good pointers to work that you have done in this area, please send them to the list to stimulate the discussion.

Börje

---

From: Klaus Schneider <[email-masked]>
Date: Tue, 4 Apr 2017 12:42:47 -0700

Dear Börje,

This is indeed an interesting discussion.

First a quick clarification about slide 17:

> Approaches to	packet loss
> - "packets are rarely lost" (PCON)	

I cannot find this quote in our paper 
(http://conferences.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf).

Our assumption is that on some (wired) links the loss probability is 
very small and can be handled by the link itself, through forward error 
correction or retransmissions.

On lossy links (wireless), we propose to detect and handle the packet 
loss locally at each hop (see Section "3.5 Local Link Loss Detection"). 
Routers can either retransmit the lost packets or signal the loss in a 
way that indicates it was *not* caused by congestion.

The larger point is that there two causes of packet loss: 1) Drops by a 
lossy link and 2) Drops by some buffer queue in the network that is 
overflowing, which we call "congestion".

End-point solutions like TCP/QUIC cannot distinguish between them, but 
as Dave Oran pointed out, CCN/NDN can. This is one reason why it's 
beneficial to have some of the CC, L, R, N functionality inside the 
routers, not only at the endpoints. I agree that the router part needs 
to be very general and well specified to allow later end-point changes.

Regarding the question about whether functionality should be placed a) 

>>  4. Where is the best place to do CC?

I think "Packet Loss Detection (L)" is only part of the wider goal of 
"Congestion Detection". Active queue management (AQM) schemes like RED 
or CoDel can detect and signal congestion without detecting a single 
packet loss. These ideas can also be applied to ICN.

Moreover, some of these functionalities can and should be placed at 
multiple layers at the same time.

1. Congestion Detection can be done by an AQM that looks at the 
low-level router queues (below the CCN layer), by a CCN overlay that 
checks the link loss (at the CCN layer), or by an end-point application 
that detects packet timeouts (above the CCN layer).

These could be used in a sort of *primary-backup model:* Use the more 
explicit and reliable methods when available (signaling router queue 
status for wired links) and use the others (end-point timeouts) only 
when everything else fails. This is similar to the reasoning to use TCP 
timeouts only as backup from "Why TCP timers don't work well" 
(https://dl.acm.org/citation.cfm?id=18216).

2. Congestion Control (CC), which I assume means "taking some action to 
prevent router buffer overflow", can be done at multiple layers as well, 
as shown in your picture on slide 15. Routers in the network can divert 
traffic to other paths (at the CCN layer) and end-points can slow down 
their Interest rate (above the CCN layer).

3. Retransmissions are used at multiple layers for different reasons. 
Overlay link-layer (or "in the CCN layer") retransmissions can be used 
at each hop to compensate for unreliable links and retrieve data more 
quickly, but they can't provide "end-to-end" reliability. End-points 
still need to have their own retransmission mechanism (above the CCN 
layer), in order to assure that they get the requested data. See 
"End-to-end arguments in system design" 
(https://dl.acm.org/citation.cfm?id=357402).

Thus I think rather than distinguishing "below/in/above the CCN layer", 
a more useful distinction is whether functionality is located "at the 
endpoint" vs. "inside the network".

Best regards,
Klaus

On 04/04/2017 07:02 AM, Börje Ohlman wrote:
> This email is relating to the presentation I made at the ICNRG interim
> meeting in Chicago:
> https://www.ietf.org/proceedings/interim-2017-icnrg-01/slides/slides-interim-2017-icnrg-01-sessa-framework-for-loss-detec0on-retransmission-and-conges0on-control-in-icn-borje-ohlman-00.pdf
>
> I think the discussion on where to locate L, R and CC in ICN is an
> interesting discussion that merits further elaboration. Personally I
> don’t have strong opinions on this at this point in time but I’m most
> interested in hearing what opinions there are on this out there in ICN
> land. So some questions I would be happy to hear peoples views on are:
>
> If you have good pointers to work that you have done in this area,
> please send them to the list to stimulate the discussion.
>
>
> Börje
>
>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 5 Apr 2017 14:21:09 +0200

Hi Börje,

a few comments on the presentation.

You start it by using a congested peering link between  Cogent and Comcast
a few years ago. While these examples exist, this is not the point where I
would start this discussion.

Usually losses happen in the access because of poor radio channel
conditions, router queues overflow and end terminals mobility.

One thing that you never say in your presentation is that you focus on
reliable transport.
For many applications there is not always the need to have reliable
transport.

There is a huge literature on loss management for reliable transport and
your basic
questions have different answers, I would say.

For this list, the implicit question you're asking is if we can have
something better
than what we have today by using ICN.

In the case of NDN/CCN you cite one of our recent work to implement
reliable transport
in mobile wireless networks:

Carofiglio et al. Leveraging ICN In-network Control for Loss Detection and
Recovery in Wireless Mobile networks ACM ICN'16.

In that case there are, IMO, very many things we cannot do just using IP
and the
protocols and mechanisms we have implemented can make WiFi mobile and
provide
reliable transport at the same time w/o application disruption.

If your discussion is about AQM/ECN/CC/Loss recovery there is so much work
done
already that we would just need to cherrypick what is available.

FWIW, in general I would suggest to cherrypick the most recent works and
not on more than 20 years old literature in the topic. Klaus is citing very
old papers.
With all the respect Lixia :)

Regards
Luca

On Tue, Apr 4, 2017 at 9:42 PM, Klaus Schneider <[email-masked]>
wrote:

> I cannot find this quote in our paper (http://conferences.sigcomm.or
> g/acm-icn/2016/proceedings/p21-schneider.pdf).
>
> Our assumption is that on some (wired) links the loss probability is very
> small and can be handled by the link itself, through forward error
> On lossy links (wireless), we propose to detect and handle the packet loss
> locally at each hop (see Section "3.5 Local Link Loss Detection"). Routers
> can either retransmit the lost packets or signal the loss in a way that
> indicates it was *not* caused by congestion.
>
>
> End-point solutions like TCP/QUIC cannot distinguish between them, but as
> Dave Oran pointed out, CCN/NDN can. This is one reason why it's beneficial
> to have some of the CC, L, R, N functionality inside the routers, not only
> at the endpoints. I agree that the router part needs to be very general and
> well specified to allow later end-point changes.
>
>
> "Congestion Detection". Active queue management (AQM) schemes like RED or
> CoDel can detect and signal congestion without detecting a single packet
> loss. These ideas can also be applied to ICN.
>
> 1. Congestion Detection can be done by an AQM that looks at the low-level
> router queues (below the CCN layer), by a CCN overlay that checks the link
> loss (at the CCN layer), or by an end-point application that detects packet
> timeouts (above the CCN layer).
>
> explicit and reliable methods when available (signaling router queue status
> for wired links) and use the others (end-point timeouts) only when
> everything else fails. This is similar to the reasoning to use TCP timeouts
> only as backup from "Why TCP timers don't work well" (
> https://dl.acm.org/citation.cfm?id=18216).
>
> prevent router buffer overflow", can be done at multiple layers as well, as
> shown in your picture on slide 15. Routers in the network can divert
> Overlay link-layer (or "in the CCN layer") retransmissions can be used at
> each hop to compensate for unreliable links and retrieve data more quickly,
> but they can't provide "end-to-end" reliability. End-points still need to
> have their own retransmission mechanism (above the CCN layer), in order to
> assure that they get the requested data. See "End-to-end arguments in
> system design" (https://dl.acm.org/citation.cfm?id=357402).
>
>
> Thus I think rather than distinguishing "below/in/above the CCN layer", a
> more useful distinction is whether functionality is located "at the
>> https://www.ietf.org/proceedings/interim-2017-icnrg-01/
>> slides/slides-interim-2017-icnrg-01-sessa-framework-for-
>> loss-detec0on-retransmission-and-conges0on-control-in-icn-
>> borje-ohlman-00.pdf
>>

---

From: Anders Eriksson E <[email-masked]>
Date: Wed, 12 Apr 2017 09:07:09 +0000

Hi Klaus and Luca,
thanks for your constructive  responses to Börje’s and my presentation.
Here are a few more comments on the reliable and unreliable content retrieval aspects you discussed in your responses.

With legacy TCP/UDP/IP, the traditional socket API allows for both a reliable TCP alternative and an unreliable UDP alternative. In analogy with this, let’s assume that there will be a need for a CCN/NDN consumer API that allows for both reliable and unreliable content retrieval in order to support different types of applications.

Such a CCN/NDN API raises the issue of where to put the congestion control mechanisms relative to this API. Again, in analogy with the TCP/UDP/IP socket API, congestion control would sit under the reliable CCN/NDN consumer API, but above the unreliable API.

However, it may not be self-evident that congestion control should always sit above an unreliable CCN/NDN consumer API. For example, some CCN/NDN congestion control schemes are rather complex and should stay below the API in order not to burden the application. On the other hand, there are constrained devices operating with a low bandwidth which may prefer a minimum of congestion control complexity.

This illustrates that there is a need for some flexibility with regard to the location of congestion control relative to a consumer CCN/NDN API. Likewise,  there is a need for flexibility with regard to selection of congestion control mechanisms in order to allow for new research results in this field.

In addition, some congestion control schemes require support in the CCN/NDN routers. Therefore, flexibility may be limited by the need for backward and forward compatibility between congestion control mechanisms in the routers on the one hand, and in the consumer nodes on the other hand.

In summary, a CCN/NDN consumer API seems to require a number of well-informed design decisions to allow for flexibility with regard to reliability and congestion control.

Comments on this?

Best regards
Anders

From: icnrg [mailto:[email-masked]] On Behalf Of Luca Muscariello
Sent: den 5 april 2017 14:21
To: Klaus Schneider <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; icnrg <[email-masked]>; Beichuan Zhang <[email-masked]>; Lixia Zhang <[email-masked]>
Subject: Re: [icnrg] Where to locate L, R and CC?

Hi Börje,

You start it by using a congested peering link between  Cogent and Comcast a few years ago. While these examples exist, this is not the point where I would start this discussion.

Usually losses happen in the access because of poor radio channel conditions, router queues overflow and end terminals mobility.

One thing that you never say in your presentation is that you focus on reliable transport.
For many applications there is not always the need to have reliable transport.

There is a huge literature on loss management for reliable transport and your basic
questions have different answers, I would say.

For this list, the implicit question you're asking is if we can have something better
than what we have today by using ICN.

In the case of NDN/CCN you cite one of our recent work to implement reliable transport
in mobile wireless networks:

Carofiglio et al. Leveraging ICN In-network Control for Loss Detection and Recovery in Wireless Mobile networks ACM ICN'16.

In that case there are, IMO, very many things we cannot do just using IP and the
protocols and mechanisms we have implemented can make WiFi mobile and provide
reliable transport at the same time w/o application disruption.

If your discussion is about AQM/ECN/CC/Loss recovery there is so much work done
already that we would just need to cherrypick what is available.

FWIW, in general I would suggest to cherrypick the most recent works and not on more than 20 years old literature in the topic. Klaus is citing very old papers.
With all the respect Lixia :)

Regards
Luca

On Tue, Apr 4, 2017 at 9:42 PM, Klaus Schneider <[email-masked]<mailto:[email-masked]>> wrote:
Dear Börje,

I cannot find this quote in our paper (http://conferences.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf).

Our assumption is that on some (wired) links the loss probability is very small and can be handled by the link itself, through forward error correction or retransmissions.

On lossy links (wireless), we propose to detect and handle the packet loss locally at each hop (see Section "3.5 Local Link Loss Detection"). Routers can either retransmit the lost packets or signal the loss in a way that indicates it was *not* caused by congestion.

The larger point is that there two causes of packet loss: 1) Drops by a lossy link and 2) Drops by some buffer queue in the network that is overflowing, which we call "congestion".

End-point solutions like TCP/QUIC cannot distinguish between them, but as Dave Oran pointed out, CCN/NDN can. This is one reason why it's beneficial to have some of the CC, L, R, N functionality inside the routers, not only at the endpoints. I agree that the router part needs to be very general and well specified to allow later end-point changes.

Regarding the question about whether functionality should be placed a) Above the CCN layer, b) In the CCN layer, or c) Below the CCN layer:

I think "Packet Loss Detection (L)" is only part of the wider goal of "Congestion Detection". Active queue management (AQM) schemes like RED or CoDel can detect and signal congestion without detecting a single packet loss. These ideas can also be applied to ICN.

Moreover, some of these functionalities can and should be placed at multiple layers at the same time.

1. Congestion Detection can be done by an AQM that looks at the low-level router queues (below the CCN layer), by a CCN overlay that checks the link loss (at the CCN layer), or by an end-point application that detects packet timeouts (above the CCN layer).

These could be used in a sort of *primary-backup model:* Use the more explicit and reliable methods when available (signaling router queue status for wired links) and use the others (end-point timeouts) only when everything else fails. This is similar to the reasoning to use TCP timeouts only as backup from "Why TCP timers don't work well" (https://dl.acm.org/citation.cfm?id=18216).

2. Congestion Control (CC), which I assume means "taking some action to prevent router buffer overflow", can be done at multiple layers as well, as shown in your picture on slide 15. Routers in the network can divert traffic to other paths (at the CCN layer) and end-points can slow down their Interest rate (above the CCN layer).

3. Retransmissions are used at multiple layers for different reasons. Overlay link-layer (or "in the CCN layer") retransmissions can be used at each hop to compensate for unreliable links and retrieve data more quickly, but they can't provide "end-to-end" reliability. End-points still need to have their own retransmission mechanism (above the CCN layer), in order to assure that they get the requested data. See "End-to-end arguments in system design" (https://dl.acm.org/citation.cfm?id=357402).

Thus I think rather than distinguishing "below/in/above the CCN layer", a more useful distinction is whether functionality is located "at the endpoint" vs. "inside the network".

Best regards,
Klaus

Börje

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 12 Apr 2017 11:35:33 +0200

Anders,

I agree. There is need for a socket API work.
As requirements, it should accomodate today's socket API services and leave
space for
new services.

It is not only a consumer API. It is a consumer/producer API. The producer
exists and has
to be part of the socket API. It does a lot of stuff the producer.

I  believe such an API is a fundamental enabler for ICN adoption and in
CICN we have given it
a dedicated space.

git clone -b libicnet/master     https://gerrit.fd.io/r/cicn libicnet;

You'll find a consumer/producer API for reliable/elastic transport.
You can use this software framework to define a new one.

We are supporting userland transport and many of your concerns vanish once
you
implement this in userland: transport becomes a library for the application
developer.

Best regards
Luca

On Wed, Apr 12, 2017 at 11:07 AM, Anders Eriksson E <
[email-masked]> wrote:

> Here are a few more comments on the reliable and unreliable content
> retrieval aspects you discussed in your responses.
>
>
>
> With legacy TCP/UDP/IP, the traditional socket API allows for both a
> reliable TCP alternative and an unreliable UDP alternative. In analogy with
> this, let’s assume that there will be a need for a CCN/NDN consumer API
> that allows for both reliable and unreliable content retrieval in order to
> support different types of applications.
>
>
>
> Such a CCN/NDN API raises the issue of where to put the congestion control
> mechanisms relative to this API. Again, in analogy with the TCP/UDP/IP
> socket API, congestion control would sit under the reliable CCN/NDN
> consumer API, but above the unreliable API.
>
>
>
> However, it may not be self-evident that congestion control should always
> sit above an unreliable CCN/NDN consumer API. For example, some CCN/NDN
> congestion control schemes are rather complex and should stay below the API
> in order not to burden the application. On the other hand, there are
> constrained devices operating with a low bandwidth which may prefer a
> minimum of congestion control complexity.
>
>
>
> This illustrates that there is a need for some flexibility with regard to
> the location of congestion control relative to a consumer CCN/NDN API.
> Likewise,  there is a need for flexibility with regard to selection of
> congestion control mechanisms in order to allow for new research results in
> this field.
>
>
>
> In addition, some congestion control schemes require support in the
> CCN/NDN routers. Therefore, flexibility may be limited by the need for
> backward and forward compatibility between congestion control mechanisms in
> the routers on the one hand, and in the consumer nodes on the other hand.
>
>
>
> In summary, a CCN/NDN consumer API seems to require a number of
> well-informed design decisions to allow for flexibility with regard to
> reliability and congestion control.
>
>
>
> Comments on this?
>
>
>
> Best regards
>
> Anders
>
>
>
>
>
>
>
> *From:* icnrg [mailto:[email-masked]] *On Behalf Of *Luca
> Muscariello
> *Sent:* den 5 april 2017 14:21
> *To:* Klaus Schneider <[email-masked]>
> *Cc:* Börje Ohlman <[email-masked]>; icnrg <[email-masked]>;
> Beichuan Zhang <[email-masked]>; Lixia Zhang <[email-masked]>
> *Subject:* Re: [icnrg] Where to locate L, R and CC?
>
>
>
> Hi Börje,
>
>
>
> I cannot find this quote in our paper (http://conferences.sigcomm.
> org/acm-icn/2016/proceedings/p21-schneider.pdf).
>
> https://www.ietf.org/proceedings/interim-2017-icnrg-01/slides/slides-
> interim-2017-icnrg-01-sessa-framework-for-loss-detec0on-
> retransmission-and-conges0on-control-in-icn-borje-ohlman-00.pdf
>