Re: [Taps] Transport Services (taps) WG Virtual Meeting: 2022-09-26

[Jon Crowcroft]

folks in TAPS might be interested in this
https://www.usenix.org/publications/loginonline/transcending-posix-end-era

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] tapping taps talent for teaching?

[Jon Crowcroft]

> I sent Jon some slides in private - happy to send to others if they want, 
> just get in touch!

they look good to me:)

> Regarding papers, since this seems to be a seminar, here are a few that 
> might be useful:

this is freat - i think those last 3 make for
a really nice session or two!
> 
> 
> A general introduction:
> 
> Michael Welzl, Safiqul Islam, Michael Gundersen, Andreas Fischer: 
> "Transport Services: A Modern API for an Adaptive Internet Transport 
> Layer", IEEE Communications Magazine 59(4), April 2021. DOI 
> 10.1109/MCOM.001.2000870
> https://ieeexplore.ieee.org/document/9433510
> 
> We also have code that people can play with, e.g.:
> https://github.com/theagilepadawan/NEATPy
> https://neatpy.readthedocs.io
> 
> and here are some papers that show how TAPS could, in principle, be used 
> to do quite unusual stuff, like:
> 
> * be an interface to RINA:
> Kristjon Ciko, Michael Welzl, Marcel Marek: "TAPS and RINA: Do they fit 
> together?", 7th International Workshop on the Recursive InterNetwork 
> Architecture (RINA 2020), co-located with IEEE ICIN 2020, Paris, France, 
> 24 February 2020. DOI 10.1109/ICIN48450.2020.9059406
> https://folk.universitetetioslo.no/michawe/research/publications/taps_rina_2020_preprint.pdf
> 
> * be an interface to SCION:
> Thorben Krüger and David Hausheer. 2021. Towards an API for the 
> Path-Aware Internet. In Proceedings of the ACM SIGCOMM 2021 Workshop on 
> Network-Application Integration (NAI'21). Association for Computing 
> Machinery, New York, NY, USA, 68–72. 
> https://doi.org/10.1145/3472727.3472808
> https://dl.acm.org/doi/10.1145/3472727.3472808
> 
> * let end hosts participate in network slicing decisions:
> Alexander Rabitsch, George Xilouris, Themistoklis Anagnostopoulos, 
> Karl-Johan Grinnemo, Thanos Sarlas, Anna Brunstrom, Özgü Alay, and 
> Giuseppe Caso. 2021. Extending network slice management to the end-host. 
> In Proceedings of the 1st Workshop on 5G Measurements, Modeling, and Use 
> Cases (5G-MeMU '21). Association for Computing Machinery, New York, NY, 
> USA, 20–26. https://doi.org/10.1145/3472771.3472775
> https://dl.acm.org/doi/10.1145/3472771.3472775
> 
> 
> Cheers,
> Michael
> 
> 
> 
> > On Sep 13, 2022, at 9:52 AM, Jon Crowcroft  
> wrote:
> >
> > i'm just updating a seminar course i run for masters/1styr PhD students 
> in
> > cambridge and i suddenly realized I have no material on TAPS at all
> > which seems like a missed opportunity...
> >
> > i think i saw an email on this list that someone had been developing 
> materials
> > for teachign (thoguh I think it was code based, whereas, while we have 
> a ton of
> > such teaching materisl, alas, my course is a paper reading one only)
> >
> > anyhow, any pointers to what people might have thought good to teach at 
> grad level
> > would be most appreciated, both arch & impl...
> >
> > cheers
> > jon
> > oh, last years materials
> > https://www.cl.cam.ac.uk/teaching/2021/R02/materials.html
> >
> > ___
> > Taps mailing list
> > Taps@ietf.org
> > https://www.ietf.org/mailman/listinfo/taps
> 
> 
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] tapping taps talent for teaching?

[Jon Crowcroft]

i'm just updating a seminar course i run for masters/1styr PhD students in
cambridge and i suddenly realized I have no material on TAPS at all 
which seems like a missed opportunity...

i think i saw an email on this list that someone had been developing materials
for teachign (thoguh I think it was code based, whereas, while we have a ton of
such teaching materisl, alas, my course is a paper reading one only)

anyhow, any pointers to what people might have thought good to teach at grad 
level
would be most appreciated, both arch & impl...

cheers
jon
oh, last years materials
https://www.cl.cam.ac.uk/teaching/2021/R02/materials.html

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] DTN & TAPS

[Jon Crowcroft]

not exactly DTN, but opportunsitic networks, as envisaged in Haggle
had pluggable protocols at most layers - 

Haggle: Seamless Networking for Mobile Applications
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/haggle-ubicomp2007.pdf

DTN is also sometimes interpreted as "Disruption Tolerant Networking",
(e.g. not just delay between earth and mars, but phobos or deimos
get in the way from time to time, so ingenuity crashes without anyone
seeingg

(or in the terrestrial case, you'ree train goes into a tunel whether
there's no cell phone coverage)...

> Sorry, answering myself:


speaking for and probably to  myself:)

> 
> > On Apr 26, 2021, at 8:29 PM, Michael Welzl  wrote:
> >
> > Hi,
> >
> >
> >> On Apr 25, 2021, at 11:49 PM, Velt, R. (Ronald) in 't 
>  > wrote:
> >>
> >> Hi Aaron,
> >> I was marveling the news about exploration on Mars this week and this 
> caused me to wonder if anyone has looked at DTN as a protocol provided by 
> TAPS. My recollection of DTN is rather rusty and I think it might be an 
> informative thought experiment for the API.
> >> Funny you should mention that.
> >>
> >> A short while ago I had a thought about a TAPS CLA (Convergence Layer 
> Adapter, the layer below the Bundle Protocol and above the Transport 
> Layer) as potentially “one CLA to rule them all”. (It was no more 
> than that: a passing thought, quickly evaporating). This would be more or 
> less the complement of your thinking; DTN-over-TAPS instead of DTN as one 
> of the candidate transports that TAPS might select (if all else fails, 
> presumably).
> >>
> >> Throwing this as bait to the DTN WG, since there could be someone 
> there interested in either thought experiment. (Not sure how much overlap 
> there is between both communities).
> >>
> >> --Ronald in ‘t Velt
> >>
> >
> > Sorry for being negative about what clearly is academically-minded 
> brainstorming… I should be open towards such stuff  :-)
> > But…  aren’t DTN applications special applications, which make 
> implicit assumptions about the network underneath, i.e. they’re written 
> particularly for the use case, because they expect… well, massive delay?
> >
> > I can’t imagine such an application being happy with TAPS swapping in 
> TCP or even QUIC as a replacement… and conversely, going with Aaron’s 
> thought model, I can’t imagine a “normal” application benefiting 
> hugely from DTN?
> >
> > What am I missing in this picture?
> 
> Perhaps, when delay gets a LOT better, the DTN application might in fact 
> be happy to run over e.g. TCP or QUIC. Is this a (the only?) use case?  
> Is it realistic, even?
> 
> Cheers,
> Michael
> 
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
> 
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] conflicting policies

[Jon Crowcroft]

for historical perspective, this is similar to the problem of "feature
interaction" in old private phone exchanges 30 years back - its (in
general) quite a hard problem if you can't just order all the preferences...

On Wed, Mar 21, 2018 at 11:34 AM, Roni Even (A) 
wrote:

> Hi,
>
> I made this comment in the past in QUIC when discussing migration.
>
>
>
> One policy may be prefer wifi over cellular network,
>
> Second policy prefers quic cove TCP
>
>
>
> Now I walk into my house and my cellphone has HTTP over QUIC.
>
> At home will switch to wifi but quic is not supported on the wifi so will
> fall back to TCP. This contradicts the second policy. So two options wifi
> TCP or cellular QUIC , how to decide?
>
>
>
> Roni Even
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] call for agenda items

[Jon Crowcroft]

just one comment - this is confusing to people who care about race
conditions in connection establishment protocols - you need to disambiguate
competing (greedy parallel exploration of options) from "racing" somewhere
in the doc:, i think:)

On Wed, Oct 25, 2017 at 5:54 AM, Tommy Pauly  wrote:

> I've just revised my "guidelines" draft to be "Guidelines for Racing
> During Connection Establishment":
>
> https://datatracker.ietf.org/doc/draft-pauly-taps-guidelines/
> https://tools.ietf.org/html/draft-pauly-taps-guidelines-01
>
> It would be useful to have a quick WG discussion (10-15 minutes?) on how
> this work and the Protocol Happy Eyeballs draft can converge (we're already
> discussing this), and how we want them to relate to other documents.
>
> Best,
> Tommy
>
>
> On Oct 23, 2017, at 8:22 AM, Aaron Falk  wrote:
>
> Please send your interest for TAPS agenda time.
>
> Already have: draft-ietf-taps-minset-00.txt
>
> Thanks,
>
> —aaron
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
>
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Jon Crowcroft]

i dont have any spare time to do it, but maybe someone could have a go at
analyzing all the different TCP offload techniques, which would give
another lens to view this through...

On Sat, Jun 20, 2015 at 9:35 AM, Michael Welzl mich...@ifi.uio.no wrote:


  On 20. jun. 2015, at 00.55, Joe Touch to...@isi.edu wrote:
 
 
 
  On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
 
 
  On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch to...@isi.edu
  mailto:to...@isi.edu wrote:
 
 
 You're getting far ahead of the conversation, IMO. This document
 needs to start by explaining the services we already have before
 jumping into a service of services model.
 
 I don't disagree with the goal, but it's impractical to develop a
 meta-interface when the base interface has not been described.
 
 
  It is just to say that TCP already defines its services, and the goal is
  not to give another definition of these services, but only to change the
  way they are exposed to applications. So the services definition already
  exists, but implicitly.
 
  It's explicit - see section 3.8 of RFC 793. The issue with that variant
 is that it captures the state of TCP in 1981; it has evolved quite a bit
 since then. Although we do have a 793-bis in the works, the update of that
 section hasn't been tackled yet.
 
  Let's put it this way:
 
- if the goal of TAPS is to unify existing APIs,
then those APIs need to be summarized together in one place
 
 
- if TAPS is indeed focused solely on an alternate API,
then it should NOT try to 'restate' the existing TCP API
in a TAPS doc
 
  Do, or do not; there is no try.
- Yoda

 TAPS is focused on an alternate API that it's based on existing
 transports. As a way of analyzing existing transports and creating a
 foundation for this API, document #1 is written. I think this discussion is
 about the approach taken to write document #1.

 So now I wonder what you're complaining about, as you go on about TCP
 already defining its services implicitly in the API. I mean, yes it does,
 okay - and so?  You criticized the SCTP API for not being abstract enough -
 so clearly if we'd just copy+paste the API descriptions of the RFCs of the
 considered transports in a list, that would look pretty messy. You seem to
 want a clean approach, but you're not going to get that unless we focus
 on TCP alone  :-)

 I've been proposing go through transport APIs and then analyze what we
 have, because this way, SCTP is already going to give us a long list of
 services.
 You've been saying that we should start with TCP. Well okay, but the
 service list there is pretty narrow. Maybe the TCP API isn't properly
 described in the current draft, okay, I think we can take that criticism
 for what it is. Still, I don't know what you're really after - in the end,
 we're going to get a list that's pretty similar to what's there now, and
 that's what we want, right?

 - unordered reliable delivery of messages
 - delivery of messages with timed delivery
 - reliable delivery of a data stream (naturally that's ordered)

  and so on. Right? Or what else is it you want / expect?

 Cheers,
 Michael

 ___
 Taps mailing list
 Taps@ietf.org
 https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps