Subject: Re: [pcp] I-D Action: draft-vinapamula-flow-ha-03.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Sep 2014 15:17:30 +0000

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, September 18, 2014 11:57 AM
> To: Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked]
> Subject: RE: I-D Action: draft-vinapamula-flow-ha-03.txt
> 
> Hi Tiru,
> 
> There are two approaches to address this issue:
> (1) consider a unified priority level: that is all flows associated with the option
> in the draft should be "processed" equally.
> (2) add another level of granularity among flows that are associated with the
> option in this draft.
> 
> The current version of the I-D argues that adding another level of granularity
> to signal a priority level (i.e., approach (2)) may not be that helpful because
> applications will be tempted to systematically set the priority level to the
> highest value in order to increase the chance to have the corresponding flow
> check-pointed/protected.

I can think of two to three ways to address this problem
1)Applications with required authorization can only signal that it's a high priority flow.
2)End User with the help of a web-portal let's say provided by Home Gateway or ISP can re-arrange priorities of flows. Applications like uTorrent already provide UI so that user can assign priorities for different file downloads.
3)Just like various good background applications use LEDBAT to limit congestion, we can except that such applications in future will explicitly signal that it's a low priority flow. 

> 
> Wouldn't (1) be sufficient to address the case you mentioned in your
> message?

I don't think it is sufficient, it does not provide relative priority.

> 
> BTW, do you think the draft should be updated to call out explicitly the case
> you are mentioning (use of the CHECKPOINT option as a trigger to other
> traffic management blocks than the HA module) ?

Yes, that will help.

-Tiru

> 
> Thank you.
> Cheers,
> Med
> 
> >-----Message d'origine-----
> >De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] Envoyé :
> >jeudi 18 septembre 2014 06:40 À : BOUCADAIR Mohamed IMT/OLN;
> >[email-masked]; [email-masked] Objet : RE: I-D Action:
> >draft-vinapamula-flow-ha-03.txt
> >
> >Hi Med,
> >
> >I think adding priority level will be useful to this draft. For example
> >ISP can use priority level to identify and penalize low-priority flows
> >during congestion. Conex WG in
> >http://tools.ietf.org/html/draft-ietf-conex-mobile-
> >04 explains that Mobile Networks are using DPI to identify dispensable
> >flows for management of congestion.
> >
> >This enhancement will help solve the above problem without DPI (which
> >will anyways not work with HTTP/2.0, Opportunistic security etc.)
> >
> >-Tiru
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]]
> >> Sent: Friday, September 05, 2014 11:36 AM
> >> To: [email-masked]; [email-masked]; Tirumaleswar Reddy (tireddy)
> >> Subject: TR: I-D Action: draft-vinapamula-flow-ha-03.txt
> >>
> >> Dear all,
> >>
> >> This updated version takes into account the comments received during
> >> the interim meeting, particularly:
> >>
> >> * the comment from Tiru about the mis-use of the option to help an
> >attacker
> >> identify critical flows.
> >> * the comment raised by Stuart about PREFER_FAILURE.
> >>
> >> We do think this version is stable enough to consider wg adoption.
> >>
> >> Cheers,
> >> Med
> >>
> >> -----Message d'origine-----
> >> De : I-D-Announce [mailto:[email-masked]] De la part
> >> de [email-masked] Envoyé : vendredi 5 septembre 2014 07:58
> >> À : i-
> >d-
> >> [email-masked] Objet : I-D Action: draft-vinapamula-flow-ha-03.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >>
> >>
> >>         Title           : Application-Initiated Flow High Availability
> >Awareness
> >> through PCP
> >>         Authors         : Suresh Vinapamula
> >>                           Senthil Sivakumar
> >>                           Mohamed Boucadair
> >> 	Filename        : draft-vinapamula-flow-ha-03.txt
> >> 	Pages           : 9
> >> 	Date            : 2014-09-04
> >>
> >> Abstract:
> >>    This document specifies a mechanism for a host to signal via PCP
> >>    which connections should be protected against network failures.
> >>    These connections will be elected to be subject to high availability
> >>    mechanisms enabled at the network side.
> >>
> >>    This approach assumes that aplications/users have more visibility
> >>    about sensitive connections rather than any heuristic that can be
> >>    enabled at the network side to guess which connections should be
> >>    secured.
> >>
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-vinapamula-flow-ha/
> >>
> >> There's also a htmlized version available at:
> >> http://tools.ietf.org/html/draft-vinapamula-flow-ha-03
> >>
> >> A diff from the previous version is available at:
> >> http://www.ietf.org/rfcdiff?url2=draft-vinapamula-flow-ha-03
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> I-D-Announce mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >> Internet-Draft directories: http://www.ietf.org/shadow.html or
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: <[email-masked]>
Date: Fri, 19 Sep 2014 06:08:14 +0000

Hi Tiru, 

Please see inline. 

Cheers,
Med

>De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
>Envoyé : jeudi 18 septembre 2014 17:18
>À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
>Objet : RE: I-D Action: draft-vinapamula-flow-ha-03.txt
>
>2)End User with the help of a web-portal let's say provided by Home Gateway
>or ISP can re-arrange priorities of flows. Applications like uTorrent
>already provide UI so that user can assign priorities for different file
>downloads.
>3)Just like various good background applications use LEDBAT to limit
>congestion, we can except that such applications in future will explicitly
>signal that it's a low priority flow.
>

[Med] Do you mean PCP messages will be modified in path?

>I don't think it is sufficient, it does not provide relative priority.

[Med] Do these flows require check-pointing too? Or you only care about prioritizing these flows during congestion events?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Sep 2014 09:06:47 +0000

> Sent: Friday, September 19, 2014 11:38 AM
> >jeudi 18 septembre 2014 17:18 À : BOUCADAIR Mohamed IMT/OLN;
> >> (1) consider a unified priority level: that is all flows associated
> >> with
> >the option
> >> (2) add another level of granularity among flows that are associated
> >> with
> >the
> >> option in this draft.
> >>
> >> to signal a priority level (i.e., approach (2)) may not be that
> >> helpful
> >because
> >> applications will be tempted to systematically set the priority level
> >> to
> >the
> >> highest value in order to increase the chance to have the
> >> corresponding
> >flow
> >> check-pointed/protected.
> >
> >I can think of two to three ways to address this problem 1)Applications
> >with required authorization can only signal that it's a high priority
> >flow.
> >2)End User with the help of a web-portal let's say provided by Home
> >Gateway or ISP can re-arrange priorities of flows. Applications like
> >uTorrent already provide UI so that user can assign priorities for
> >different file downloads.
> >congestion, we can except that such applications in future will
> >explicitly signal that it's a low priority flow.
> >
> 

No, I meant there will be some applications that will declare that they have low-priority flows just like applications that declare  that HA is not required.

> [Med] Do these flows require check-pointing too? Or you only care about
> prioritizing these flows during congestion events?

These flows could care about both check-pointing and prioritization or care about only one of them.

-Tiru

---

From: <[email-masked]>
Date: Fri, 19 Sep 2014 09:19:09 +0000

Re-,

Please see inline.

Cheers,
Med

>Envoyé : vendredi 19 septembre 2014 11:07
>No, I meant there will be some applications that will declare that they
>have low-priority flows just like applications that declare  that HA is not
>required.

[Med] OK. If we assume a priority level was added, what will be the behavior of the server when it receives a request for high-priority flow but there is no resources to honor the request? Should it remove entries with low-priority from the check-pointing table? I'm afraid this will induce more complexity at the server side. 

>These flows could care about both check-pointing and prioritization or care

[Med] I can understand the priority level for flows that are subject to check-pointing, but I have an issue to generalize this draft to address the prioritization purpose ** only **. The problems are not the same. If prioritization is needed as a requirement in its own (which I understand since I'm for a mean to indicate at least DSCP), then a dedicated option can be defined for that purpose.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Sep 2014 10:46:00 +0000

> Sent: Friday, September 19, 2014 2:49 PM
> >vendredi 19 septembre 2014 11:07 À : BOUCADAIR Mohamed IMT/OLN;
> >have low-priority flows just like applications that declare  that HA is
> >not required.
> 
> [Med] OK. If we assume a priority level was added, what will be the behavior
> of the server when it receives a request for high-priority flow but there is no
> resources to honor the request? Should it remove entries with low-priority
> from the check-pointing table? I'm afraid this will induce more complexity at
> the server side.

I thought servers already have such complexity, for example Mobile Networks already use techniques like ARP (Allocation and Retention priority) to accommodate high-priority flow by penalizing low-priority flows.

> 
> >
> >>
> >> >>
> >> >> Wouldn't (1) be sufficient to address the case you mentioned in
> >> >> your message?
> >> >
> >> [Med] Do these flows require check-pointing too? Or you only care
> >> about prioritizing these flows during congestion events?
> >
> [Med] I can understand the priority level for flows that are subject to check-
> pointing, but I have an issue to generalize this draft to address the
> prioritization purpose ** only **. The problems are not the same. If
> prioritization is needed as a requirement in its own (which I understand since
> I'm for a mean to indicate at least DSCP), then a dedicated option can be
> defined for that purpose.

Works for me.

-Tiru

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Fri, 19 Sep 2014 12:15:50 +0000

ARP is applied at the radio bearer level which often represents multiple IP flows.

A user who is congested because their demand exceeds the radio resources they can receive, e.g. coverage challenge, from the network may never see ARP come into play if the radio network is not itself congested.

-----Original Message-----
From: pcp [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Friday, September 19, 2014 5:46 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pcp] I-D Action: draft-vinapamula-flow-ha-03.txt

> >> >2)End User with the help of a web-portal let's say provided by
> >> >Home Gateway or ISP can re-arrange priorities of flows.
> >> >Applications like uTorrent already provide UI so that user can
> >> >assign priorities for different file downloads.
> >> >3)Just like various good background applications use LEDBAT to
> >> >limit congestion, we can except that such applications in future
> >> >will explicitly signal that it's a low priority flow.
> >> >
> >>
> >No, I meant there will be some applications that will declare that
> >they have low-priority flows just like applications that declare
> >that HA is not required.
>
> [Med] OK. If we assume a priority level was added, what will be the
> behavior of the server when it receives a request for high-priority
> flow but there is no resources to honor the request? Should it remove
> entries with low-priority from the check-pointing table? I'm afraid
> this will induce more complexity at the server side.

> [Med] I can understand the priority level for flows that are subject
> to check- pointing, but I have an issue to generalize this draft to
> address the prioritization purpose ** only **. The problems are not
> the same. If prioritization is needed as a requirement in its own
> (which I understand since I'm for a mean to indicate at least DSCP),
> then a dedicated option can be defined for that purpose.

Works for me.

-Tiru

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: <[email-masked]>
Date: Mon, 22 Sep 2014 05:41:11 +0000

Hi Tiru,

Great!

Lets' discuss offline how that (prioritization) option can be defined.

Cheers,
Med

>Envoyé : vendredi 19 septembre 2014 12:46