Subject: Re: [Taps] First draft of an article for the IETF journal

From: Aaron Falk <[email-masked]>
Date: Wed, 21 May 2014 09:41:28 -0400

On Wed, May 21, 2014 at 5:11 AM, Michael Welzl <[email-masked]> wrote:

>
> My opinion: at first, we should focus on things that can be installed
> one-sided, on the sender side only. Yes it's limited, but a number of
> things are possible there. E.g., pluggable congestion controls in TCP have
> always worked without involving the receiver - but right now, pluggable
> congestion control isn't an IETF matter. Happy Eyeballs can be done without
> coordinating with a receiver, at least for the case that we're using
> well-known ports and the receiver listens on more than one protocol.

I've forgotten the details of 'Happy Eyeballs'.  Can you provide a cite?

>
> But yes, quite quickly one runs into limitations there; anyway, for
> divide-and-conquer  :-)   reasons, I think we want to go with a
> sender-side-only-installation assumption for now.

Seems worth exploring the implications of such an approach where you have
the same app sitting on top of very different APIs (e.g., Berkeley socket
vs TAPS) at either end of the connection.  That combined with an app where
either endpoint might be a sender.

> Though, I'm not sure if we have had enough discussions on this and if
> absolutely everyone is on the same page (though, indirectly perhaps, as our
> draft charter states that signaling is out of scope, and signaling would be
> needed to align both ends).
>

yup

cheers,

--aaron

---

From: David Ros <[email-masked]>
Date: Wed, 21 May 2014 15:45:02 +0200

On 21 May 2014, at 15:41, Aaron Falk <[email-masked]> wrote:

> My opinion: at first, we should focus on things that can be installed one-sided, on the sender side only. Yes it's limited, but a number of things are possible there. E.g., pluggable congestion controls in TCP have always worked without involving the receiver - but right now, pluggable congestion control isn't an IETF matter. Happy Eyeballs can be done without coordinating with a receiver, at least for the case that we're using well-known ports and the receiver listens on more than one protocol.
> 

Hi,

http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02

Cheers,

David

> 
> But yes, quite quickly one runs into limitations there; anyway, for divide-and-conquer  :-)   reasons, I think we want to go with a sender-side-only-installation assumption for now.
> 
> Seems worth exploring the implications of such an approach where you have the same app sitting on top of very different APIs (e.g., Berkeley socket vs TAPS) at either end of the connection.  That combined with an app where either endpoint might be a sender.
> 
>  
> Though, I'm not sure if we have had enough discussions on this and if absolutely everyone is on the same page (though, indirectly perhaps, as our draft charter states that signaling is out of scope, and signaling would be needed to align both ends).
> 
> yup
> 
> cheers,
> 
> --aaron
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Wed, 21 May 2014 15:46:26 +0200

> I've forgotten the details of 'Happy Eyeballs'.  Can you provide a cite?

e.g. http://www.ipjforum.org/?p=378

it's just a term for "try all protocols and see what comes back".

When that was last discussed in the IETF, the discussion went nowhere because - in my opinion - everybody was too focused on the first round trip. If you assume that you can just use something that comes back *later*, for any later connection, and cache the information meanwhile, things get easier.

(this idea is actually Joe Touch's, he sent it to me in a private email exchange, years ago)

> Seems worth exploring the implications of such an approach where you have the same app sitting on top of very different APIs (e.g., Berkeley socket vs TAPS) at either end of the connection.  That c…

Yes. Anyway, clearly you run into limitations.

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 May 2014 14:50:13 +0100

Happy eyeballs...

The non-reference:
http://en.wikipedia.org/wiki/Happy_Eyeballs

http://tools.ietf.org/html/rfc6555

Dan Wing and Andrew Yourtchenko. "Happy Eyeballs: Improving User 
Experiences with IPv6 and SCTP". Internet Protocol Journal, vol.13 n.3.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 May 2014 14:52:27 +0100

> Yes. Anyway, clearly you run into limitations.

I was personally thinking about the sender/receiver having some 
side-information not communicated in the session, such as a cache as you 
suggest, or a hint from DNS, or something else. The point being that 
this wouldn't "tell" you what works, but would help answer what to try.

gorry