Subject: Re: [mif] Happy Eyeballs Extension for MIF

From: GangChen <[email-masked]>
Date: Tue, 5 Apr 2011 23:38:57 +0800

Hello Scott,

Please see my reply inline.

2011/3/28, Scott Brim <[email-masked]>:
> First, there are a lot of issues that go into making a choice between
> interfaces. The ones I can think of immediately are interface cost, policy
> rules, higher layer services sought, and real goodput measurement over time.
> A simple integer preference for using a particular interface to reach a
> particular prefix, based only on how fast a SYNACK comes back, cannot
> reflect those.

[Gang] Agree. The different interfaces may have different policies, so
it is not only the connectivity but also policy.

> I suspect that it would be better do this in two stages: first choose a set
> of interfaces based on other criteria (like those listed above), and then
> run this draft's mechanism on that set.

[Gang] Yes. In first stage, multiple preconditions should be taken
into account.
The problem is how to formulate a function to accurately reflect these impacts.

>
> Second, I can't resist pointing out that goodput over time is more
> significant than initial connectivity so in the long run we're better off
> with MPTCP or SCTP and using real data packets on those interfaces.

[Gang] I guess this goes beyond the scope of this draft.

> Thanks...  Scott
>
> - use multipathing (SCTP CMT, MPTCP) to determine
>
> I have concerns about the usefulness. I like Happy Eyeballs very much in its
> original context. However, in the original context of Happy Eyeballs (IPv4
> vs IPv6, TCP vs SCTP), the goals are clear, the choices are clear, and the
> metrics for the decision are clear. It's purely a problem of devising a good
> mechanism to enable making a technical choice. However, in this case, t

[Gang] Regarding the usefulness, Happy Eyeballs Extension could allow
traffic falls back to suboptimal interface, when there are accidental
problems happened on the optimal interface.

Best Regards

Gang

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 15:39:02 +0200

Hi,

Just a brief comment on happy eyeballs I-D. Basically, I'll second Scott on complexity for choosing an interface.

I agree that interface selection can be made using an interface weighting method. However, weight computation needs to take into account various criteria: obviously network access condition, but also the type of application (applications may have different QoS requirements), user preferences and operator policies, interface cost, L2/L3 authentication/security capabilities, and so on... Interface weight must be computed in advance but also be recomputed during session; network condition may change during the session and interface reselection triggered (if mobility supported). IMHO, the proposed algorithm is too simplistic with regards to interface selection problem in MIF context. Usually, interface selection is performed by a connection manager having interfaces to different layers.

I'm also concerned with DNS requests sent over all interfaces. IMHO, this is a waste of resource; besides draft-ietf-mif-dns-server-selection clearly states that this practice should be avoided. 

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> GangChen
> Envoyé : mardi 5 avril 2011 17:39
> À : Scott Brim
> Cc : [email-masked]
> Objet : Re: [mif] Happy Eyeballs Extension for MIF
> 
> Hello Scott,
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2011 16:25:57 -0400

> I'm also concerned with DNS requests sent over all interfaces. IMHO, this is a waste of resource; besides draft-ietf-mif-dns-server-selection clearly states that this practice should be avoided. 

The DNS server selection draft is a point solution to a very restricted problem: how to deal with situations where DNS servers on different interfaces will give different answers to queries for the same name.   It is not a general solution.

In principal you are right that it would be better not to send duplicate queries if the answers are going to be (as they should be) the same.   However, it is not the case that answers will in fact always be the same, and there are common real-world scenarios where they are not.   One goal of this working group is (or at least IMHO should be) to address those common real-world scenarios.

Also, when you say that sending DNS requests is a waste of resources, I think it's important to be clear about exactly what resources you think are being wasted.   E.g., are you talking about battery, or bandwidth, or server utilization (or some other option I didn't think of:)?

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 11:38:16 +0200

Hi Ted,

[snip]
> 
> Also, when you say that sending DNS requests is a waste of resources,
I
> think it's important to be clear about exactly what resources you
think
> are being wasted.   E.g., are you talking about battery, or bandwidth,
or
> server utilization 

This is what I've in mind actually. I'm particularly concerned about
wasting bandwidth on cellular network where bandwidth, specially for
data services, is limited. Now, I don't know how much traffic is
generated with an approach ala eyeballs.

Br,
Pierrick

(or some other option I didn't think of:)?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2011 12:06:26 +0000

On Apr 7, 2011, at 5:38 AM, "[email-masked]" <[email-masked]> wrote:

> I'm particularly concerned about
> data services, is limited

So specifically to what cell networks where a DNS packet is going to represent a substantial amount of traffic that we need to optimize away?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2011 12:23:32 +0000

> So specifically to what cell networks where a DNS packet is going to represent a substantial amount of traffic that we need to optimize away?

Wow, that was hard for me to parse.  Probably impossible for anyone else.   The question I am asking is, what cell networks exist where in practice DNS traffic actually represents a significant load that we need to eliminate?   I could see this being an issue if we were talking about, say, video traffic, but otherwise it seems like a premature optimization.

---

From: Fred Baker <[email-masked]>
Date: Thu, 7 Apr 2011 14:33:08 +0200

> Wow, that was hard for me to parse.  Probably impossible for anyone else.   The question I am asking is, what cell networks exist where in practice DNS traffic actually represents a significant loa…

I started to reply "networks designed primarily for SMS as opposed to providing 'mobile internet' applications". I would agree that different networks are designed with different levels of bandwidth. In 3GPP, I share 2 MBPS with everyone else in my cell. In its predecessor, I share 56 KBPS with everyone else in my cell. In GSM, I share 9.6. Note that I once worked at a company that had ~100 people behind a single 9.6 link, and the proto-Internet of the early-mid 1980's was entirely 56 KBPS. 

The other thought that went through my mind is "commercially irrelevant networks".

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2011 12:52:21 +0000

> The other thought that went through my mind is "commercially irrelevant networks".

Yes, that's exactly what I was thinking too.  Also, "networks that will not exist by the time we produce a spec.".  IP over SMS sounds intriguing, but at the rate messages are charged at least in the US, it's likely prohibitively expensive.

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 14:56:46 +0200

> De : Ted Lemon [mailto:[email-masked]]
> Envoyé : jeudi 7 avril 2011 14:24
> À : Ted Lemon
> Cc : SEITE Pierrick RD-RESA-REN; [email-masked]
> > So specifically to what cell networks where a DNS packet is going to
> represent a substantial amount of traffic that we need to optimize away?
> 
> Wow, that was hard for me to parse.  Probably impossible for anyone else.
> The question I am asking is, what cell networks exist where in practice
> DNS traffic actually represents a significant load that we need to
> eliminate?   I could see this being an issue if we were talking about, say,
> video traffic, but otherwise it seems like a premature optimization.

You're right. Mobile operators have to face dramatic traffic increase; of course this is not due to DNS traffic :-). I don't know if we really have an issue when many 3GPP subscribers send unnecessary DNS requests (i.e. when the non-3GPP interface is selected)... but I just meant that some access networks (typically mobile/3gpp) have limited bandwidth (while data usage is increasing), so it is preferable to use this bandwidth for useful traffic instead of sending unnecessary signalling (as a general principle). Generally, a mobile operator tries to optimize signalling load and overhead. 

Pierrick.

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 15:09:40 +0200

> De : [email-masked] [mailto:[email-masked]] De la part de Ted
> Lemon
> Envoyé : jeudi 7 avril 2011 14:52
> À : Fred Baker
> Cc : [email-masked]
> Yes, that's exactly what I was thinking too.  Also, "networks that will
> not exist by the time we produce a spec.".  IP over SMS sounds intriguing,

Well, I don't know what "IP over SMS" is... but, each month, data traffic on GPRS network increases significantly: web browsing of course, but also video streaming (a lot). It's surprising, but some people are watching TV on mobile at home. But we are digressing :-).

> but at the rate messages are charged at least in the US, it's likely
> prohibitively expensive.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 07 Apr 2011 09:19:05 -0400

Le 11-04-07 09:09, [email-masked] a écrit :
>> On Apr 7, 2011, at 8:33 AM, "Fred Baker"<[email-masked]>  wrote:
>>

actually not: if users are streaming video over mobile networks, then 
the cost of few additional dns packets is zero.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 15:23:28 +0200

> De : [email-masked] [mailto:[email-masked]] De la part de Marc
> Blanchet
> Envoyé : jeudi 7 avril 2011 15:19
> À : [email-masked]
> Ted
> >>> The other thought that went through my mind is "commercially
> irrelevant
> >> networks".
> >>
> > Well, I don't know what "IP over SMS" is... but, each month, data
> traffic on GPRS network increases significantly: web browsing of course,
> but also video streaming (a lot). It's surprising, but some people are
> watching TV on mobile at home. But we are digressing :-).
> 

For that user, and that connection, yes. But what about the cost for the operator when thousands of users send DNS packets on 3GPP, just to be sure they can use the wifi network...?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2011 13:39:46 +0000

> For that user, and that connection, yes. But what about the cost for the operator when thousands of users send DNS packets on 3GPP, just to be sure they can use the wifi network...?

The problem is that while the scenario you describe does exist, there is no reliable way to distinguish between this scenario and other scenarios where a failure to use the 3G DNS server will result in a dissatisfactory user experience. This is why I call it a premature optimization. It's likely that the scenario you are concerned about will actually be largely eliminated by optimizations like the P/I optimization anyway.  It doesn't make sense to gunk up the protocol to optimize for this. Control traffic is important, and we can't presume that it is wasted.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 7 Apr 2011 09:55:50 -0400

On Thu, Apr 07, 2011 at 09:19:05AM -0400, Marc Blanchet wrote:
> actually not: if users are streaming video over mobile networks,
> then the cost of few additional dns packets is zero.

Exactly right.  To illustrate, the DNSSEC-enabled response for MX for
ietf.org that I did just this second reports ;; MSG SIZE rcvd: 1091.
Optimizing away DNS traffic is the last place to start.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 16:01:37 +0200

> Envoyé : jeudi 7 avril 2011 15:56
> À : [email-masked]

I couldn't agree more. But it's not the purpose; the concern was about sending DNS request on interface I1 to finally start the application on interface I2.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 07 Apr 2011 10:17:52 -0400

> I couldn't agree more. But it's not the purpose; the concern was about sending DNS request on interface I1 to finally start the application on interface I2.

I understand. but:
- I've been working for years with a very humble contribution on trying 
to restore end2end internet, by helping the ipv6 deployment. reality: 
even with ipv6, it won't happen. I have no more dreams...
- we are in a situation here where we have been engineering mechanisms 
to establish connections (which was a given before...): 
STUN/TURN/ICE/Teredo/Nat keepalives/Happy eyeballs/... all of them 
require extra packets where most are triggers, test packets, etc... and 
most are at the end not used for the real connection.
- so yes this is not pretty.
- the fact that some mechanisms may end up sending additional small 
packets on the wrong interface, 3G or not, does not seem to me in any 
way a blocker. especially again that modern 3G trafic and bandwidth is 
many orders of magnitude larger than the little test dns packets. 
Moreover, about the 3G connection itself, just think about background 
notification of gaming/facebook/... that are done in the background for 
the user: maintains the 3G connection up all the time...

It is just a consequence of where we are, and yes there are some 
causalities...

Marc.

---

From: Hui Deng <[email-masked]>
Date: Thu, 7 Apr 2011 22:41:47 +0800

Hello all

I try to explain how mobile signal  behave, mobile vendors could correct
if my explaination is not correct.
1) Compared with real traffic amount, dns resolve signaling is not that
much.
2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP is
still there but air interface is tentatively released)
for 3G connection, if you need send dns resolve message, Mobile has to be
waked up, then it will consume lots of air interface
signaling, and because the control channel and traffic channel are seperated
each other in 3G network, those signalings will
consume control channel resource of air interface. Anyway, if Mobile is in
the stage of connected, it won't consume much about
air resource traffic channel.

So in summary, it might be an issue for mobile network to send  DNS resolve
messages through multiple interfaces.

thanks

-Hui

2011/4/7 Marc Blanchet <[email-masked]>

>> I couldn't agree more. But it's not the purpose; the concern was about
>> sending DNS request on interface I1 to finally start the application on
>> interface I2.
>>
>>
> I understand. but:
> - I've been working for years with a very humble contribution on trying to
> restore end2end internet, by helping the ipv6 deployment. reality: even with
> ipv6, it won't happen. I have no more dreams...
> - we are in a situation here where we have been engineering mechanisms to
> establish connections (which was a given before...):
> STUN/TURN/ICE/Teredo/Nat keepalives/Happy eyeballs/... all of them require
> extra packets where most are triggers, test packets, etc... and most are at
> the end not used for the real connection.
> - the fact that some mechanisms may end up sending additional small packets
> on the wrong interface, 3G or not, does not seem to me in any way a blocker.
> especially again that modern 3G trafic and bandwidth is many orders of
> magnitude larger than the little test dns packets. Moreover, about the 3G
> connection itself, just think about background notification of
> gaming/facebook/... that are done in the background for the user: maintains
> the 3G connection up all the time...
>

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 07 Apr 2011 10:45:20 -0400

Le 11-04-07 10:41, Hui Deng a écrit :
> 2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP
> is still there but air interface is tentatively released)
> for 3G connection, if you need send dns resolve message, Mobile has to
> be waked up, then it will consume lots of air interface
> signaling, and because the control channel and traffic channel are
> seperated each other in 3G network, those signalings will
> consume control channel resource of air interface. Anyway, if Mobile is
> in the stage of connected, it won't consume much about

I know all this. but as I wrote at the end of my previous message:
- "Moreover, about the 3G connection itself, just think about background 
notification of gaming/facebook/... that are done in the background for 
the user: maintains the 3G connection up all the time...
- all the nat traversal/session keepalives/... are all doing the wake up 
too.

> So in summary, it might be an issue for mobile network to send  DNS
> resolve messages through multiple interfaces.

I understand it is a potential issue. What I'm saying is that in 
reality, other stuff/usage/mechanisms already keep the mobile connected 
all the time and there is nothing we can do.

Marc.

> thanks
> -Hui
> 2011/4/7 Marc Blanchet <[email-masked]
> <mailto:[email-masked]>>
>
>     Le 11-04-07 10:01, [email-masked]
>     <mailto:[email-masked]> a écrit :
>
>
>
>             De : [email-masked] <mailto:[email-masked]>
>             [mailto:[email-masked] <mailto:[email-masked]>]
>             De la part de
>             Andrew Sullivan
>             À : [email-masked] <mailto:[email-masked]>
>             ietf.org <http://ietf.org/> that I did just this second
>             reports ;; MSG SIZE rcvd: 1091.
>         I couldn't agree more. But it's not the purpose; the concern was
>         about sending DNS request on interface I1 to finally start the
>         application on interface I2.
>
>
>     I understand. but:
>     - I've been working for years with a very humble contribution on
>     trying to restore end2end internet, by helping the ipv6 deployment.
>     reality: even with ipv6, it won't happen. I have no more dreams...
>     - we are in a situation here where we have been engineering
>     mechanisms to establish connections (which was a given before...):
>     require extra packets where most are triggers, test packets, etc...
>     and most are at the end not used for the real connection.
>     packets on the wrong interface, 3G or not, does not seem to me in
>     any way a blocker. especially again that modern 3G trafic and
>     bandwidth is many orders of magnitude larger than the little test
>     dns packets. Moreover, about the 3G connection itself, just think
>     about background notification of gaming/facebook/... that are done
>     in the background for the user: maintains the 3G connection up all
>     the time...
>
>             [email-masked] <mailto:[email-masked]>
>             Shinkuro, Inc.
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     <http://www.ipv6book.ca/>
>     <http://numb.viagenie.ca/>
>     <http://postellation.viagenie.ca/>
>     <http://ecdysis.viagenie.ca/>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Thu, 7 Apr 2011 23:25:07 +0800

before move, just say you are right, inline please,

> notification of gaming/facebook/... that are done in the background for the
> user: maintains the 3G connection up all the time...

==> Today some smart phones or applications, not all of them, does detect
whether the 3G connection is still there,
if not, they will send message to wake up the connection to keep them always
online. But the number of user allowed to access for one cell is still
limited at least for 3G/2G, and data plane is also shared link for accessed
user. This behavior seems kind of unfair usage of air interface, operators
does have some way to schedule it, and some application are changing their
behavior today as well.
This is the topic people who are working on now, some solutions are under
trial today.

-Hui

> I understand it is a potential issue. What I'm saying is that in reality,
> other stuff/usage/mechanisms already keep the mobile connected all the time
> and there is nothing we can do.
>
> Marc.
>

---

From: GangChen <[email-masked]>
Date: Thu, 7 Apr 2011 23:25:11 +0800

2011/4/6, [email-masked] <[email-masked]>:
> Hi,
> I agree that interface selection can be made using an interface weighting
> method. However, weight computation needs to take into account various
> criteria: obviously network access condition, but also the type of
> application (applications may have different QoS requirements), user
> preferences and operator policies, interface cost, L2/L3
> authentication/security capabilities, and so on... Interface weight must be
> computed in advance but also be recomputed during session; network condition
> may change during the session and interface reselection triggered (if
> mobility supported). IMHO, the proposed algorithm is too simplistic with
> regards to interface selection problem in MIF context. Usually, interface
> selection is performed by a connection manager having interfaces to
> different layers.

I'm trying to catch various criteria into account.
In order to compute interface weighting, it should formulate a function. Like
Iweighting=F (Rule 1, Rule 2, …., Rule n)
Some rules can be quantified and some are not, like user preferences
or operator policies.
It will make algorithm become impractical.

I think Happy Eyeball is targeting to HTTP context. Usage scope has
limitation here.
We can't expect interface weighting to judge interface selection for
all kinds of application.

BRs

Gang

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 7 Apr 2011 11:37:35 -0400

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> GangChen
> Sent: April 7, 2011 11:25 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mif] Happy Eyeballs Extension for MIF
> 
> Iweighting=F (Rule 1, Rule 2, ...., Rule n)

Perhaps not for all kinds of applications, but it should take care of
the main ones and the rest can be treated in a best effort manner. It
should at least regard the most relevant ones, being the ones that cause
more traffic, the ones that require higher QoS, the ones you have paid
for, etc. This is why it is important to take other parameters into
account, like operator policies, user preferences, network conditions,
etc when taking the decision in the connection/session manager, and for
that we need those interfaces with other layers/functions.

Regards,

Juan-Carlos

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2011 21:17:43 +0000

On Apr 7, 2011, at 10:41 AM, "Hui Deng" <[email-masked]> wrote:

> 2) The issue is when Mobile goes to the idle/standby stage (Mobile 3G IP is still there but air interface is tentatively released)
> for 3G connection, if you need send dns resolve message, Mobile has to be waked up, then it will consume lots of air interface
> signaling, and because the control channel and traffic channel are seperated each other in 3G network, those signalings will
> consume control channel resource of air interface. Anyway, if Mobile is in the stage of connected, it won't consume much about
> So in summary, it might be an issue for mobile network to send  DNS resolve messages through multiple interfaces.

It would be nice in this case if the layer two were able to signal to HE what the marginal cost of transmitting the next packet is; if the link is already up, it would be low; if not, high.  It would also be nice if the layer two could be asked to notify the HE implementation when the cost to transmit went low due to other traffic on the 3G link.  However, ultimately this seems like a bug in the layer two that we would hope to see eliminated at some point.

---

From: Hui Deng <[email-masked]>
Date: Fri, 8 Apr 2011 14:31:54 +0800

User won't care much about layer 2 cost, people is always best effort doing
something asap

It's hard to say the layer 2 has some bug today, originally Internet host is
designed to send packet like this,
it seems 2G/3G air interface has different behavior, hope LTE could release
this relief finally.

By the way, what does HE stands for?

-Hui
2011/4/8 Ted Lemon <[email-masked]>

> It would be nice in this case if the layer two were able to signal to HE
> what the marginal cost of transmitting the next packet is; if the link is
> already up, it would be low; if not, high.  It would also be nice if the
> layer two could be asked to notify the HE implementation when the cost to
> transmit went low due to other traffic on the 3G link.  However, ultimately
> this seems like a bug in the layer two that we would hope to see eliminated
> at some point.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Apr 2011 08:27:02 -0400

On Apr 8, 2011, at 2:31 AM, Hui Deng wrote:
> User won't care much about layer 2 cost, people is always best effort doing something asap

Of course.   That's part of why it's important to fix the problem--the users just want it to work.

> It's hard to say the layer 2 has some bug today, originally Internet host is designed to send packet like this,
> it seems 2G/3G air interface has different behavior, hope LTE could release this relief finally.

Right, exactly.   We have to deal with what we have, but we can hope that this isn't a problem that will never go away, and we should do our best to mitigate the user impact.

> By the way, what does HE stands for?

Happy Eyeballs!   :)

---

From: Hui Deng <[email-masked]>
Date: Fri, 8 Apr 2011 21:59:48 +0800

inline please

> Right, exactly.   We have to deal with what we have, but we can hope that
> this isn't a problem that will never go away, and we should do our best to
> mitigate the user impact.
>
Whether we need to do something will depend on how many years those 2G/3G
base station will stand there.
sometime operator would prefer to use VoLTE in how many years later, say
3-5-10?

> > By the way, what does HE stands for?
:)

-Hui