-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
2761 lines (2373 loc) · 222 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en-US"><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta charset="UTF-8">
<title>
| MAMI Project – This project received funding from the European
Union’s Horizon 2020 research and innovation programme under grant
agreement No 688421. </title>
<link rel="profile" href="http://gmpg.org/xfn/11">
<link rel="stylesheet" type="text/css" media="all" href="src/style_002.css">
<!--<link rel="pingback" href="https://mami-project.eu/xmlrpc.php">-->
<link rel="dns-prefetch" href="https://cdn.jsdelivr.net/">
<link rel="dns-prefetch" href="https://s.w.org/">
<!--<link rel="alternate" type="application/rss+xml" title=" » Feed" href="https://mami-project.eu/index.php/feed/">
<link rel="alternate" type="application/rss+xml" title=" » Comments Feed" href="https://mami-project.eu/index.php/comments/feed/">
<link rel="alternate" type="text/calendar" title=" » iCal Feed" href="https://mami-project.eu/index.php/events/?ical=1">
<script type="text/javascript">
window._wpemojiSettings = {"baseUrl":"https:\/\/s.w.org\/images\/core\/emoji\/11\/72x72\/","ext":".png","svgUrl":"https:\/\/s.w.org\/images\/core\/emoji\/11\/svg\/","svgExt":".svg","source":{"concatemoji":"https:\/\/mami-project.eu\/wp-includes\/js\/wp-emoji-release.min.js?ver=5.0.3"}};
!function(a,b,c){function d(a,b){var c=String.fromCharCode;l.clearRect(0,0,k.width,k.height),l.fillText(c.apply(this,a),0,0);var d=k.toDataURL();l.clearRect(0,0,k.width,k.height),l.fillText(c.apply(this,b),0,0);var e=k.toDataURL();return d===e}function e(a){var b;if(!l||!l.fillText)return!1;switch(l.textBaseline="top",l.font="600 32px Arial",a){case"flag":return!(b=d([55356,56826,55356,56819],[55356,56826,8203,55356,56819]))&&(b=d([55356,57332,56128,56423,56128,56418,56128,56421,56128,56430,56128,56423,56128,56447],[55356,57332,8203,56128,56423,8203,56128,56418,8203,56128,56421,8203,56128,56430,8203,56128,56423,8203,56128,56447]),!b);case"emoji":return b=d([55358,56760,9792,65039],[55358,56760,8203,9792,65039]),!b}return!1}function f(a){var c=b.createElement("script");c.src=a,c.defer=c.type="text/javascript",b.getElementsByTagName("head")[0].appendChild(c)}var g,h,i,j,k=b.createElement("canvas"),l=k.getContext&&k.getContext("2d");for(j=Array("flag","emoji"),c.supports={everything:!0,everythingExceptFlag:!0},i=0;i<j.length;i++)c.supports[j[i]]=e(j[i]),c.supports.everything=c.supports.everything&&c.supports[j[i]],"flag"!==j[i]&&(c.supports.everythingExceptFlag=c.supports.everythingExceptFlag&&c.supports[j[i]]);c.supports.everythingExceptFlag=c.supports.everythingExceptFlag&&!c.supports.flag,c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.everything||(h=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",h,!1),a.addEventListener("load",h,!1)):(a.attachEvent("onload",h),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),g=c.source||{},g.concatemoji?f(g.concatemoji):g.wpemoji&&g.twemoji&&(f(g.twemoji),f(g.wpemoji)))}(window,document,window._wpemojiSettings);
</script>-->
<script src="src/wp-emoji-release.js" type="text/javascript" defer="defer"></script>
<style type="text/css">
img.wp-smiley,
img.emoji {
display: inline !important;
border: none !important;
box-shadow: none !important;
height: 1em !important;
width: 1em !important;
margin: 0 .07em !important;
vertical-align: -0.1em !important;
background: none !important;
padding: 0 !important;
}
</style>
<link rel="stylesheet" id="wp-block-library-css" href="src/style.css" type="text/css" media="all">
<link rel="stylesheet" id="github-embed-css" href="src/github-embed.css" type="text/css" media="all">
<link rel="stylesheet" id="wppa_style-css" href="src/wppa-style.css" type="text/css" media="all">
<link rel="stylesheet" id="github-profile-octicons-css" href="src/octicons.css" type="text/css" media="all">
<link rel="stylesheet" id="PI_stt_front-css" href="src/stt.css" type="text/css" media="all">
<link rel="stylesheet" id="wptt_front-css" href="src/admin_style.css" type="text/css" media="all">
<script type="text/javascript" src="src/jquery_002.js"></script>
<script type="text/javascript" src="src/jquery-migrate.js"></script>
<script type="text/javascript" src="src/jquery.js"></script>
<script type="text/javascript" src="src/wppa-utils.js"></script>
<script type="text/javascript" src="src/core.js"></script>
<script type="text/javascript" src="src/widget.js"></script>
<script type="text/javascript" src="src/mouse.js"></script>
<script type="text/javascript" src="src/resizable.js"></script>
<script type="text/javascript" src="src/draggable.js"></script>
<script type="text/javascript" src="src/button.js"></script>
<script type="text/javascript" src="src/position.js"></script>
<script type="text/javascript" src="src/dialog.js"></script>
<script type="text/javascript" src="src/wppa.js"></script>
<script type="text/javascript" src="src/wppa-slideshow.js"></script>
<script type="text/javascript" src="src/wppa-ajax-front.js"></script>
<script type="text/javascript" src="src/wppa-popup.js"></script>
<script type="text/javascript" src="src/wppa-init.js"></script>
<!--<link rel="https://api.w.org/" href="https://mami-project.eu/index.php/wp-json/">-->
<!--<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://mami-project.eu/xmlrpc.php?rsd">-->
<!--<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://mami-project.eu/wp-includes/wlwmanifest.xml">-->
<meta name="generator" content="WordPress 5.0.3">
<style type="text/css">
.calnk a:hover {
background-position:0 0;
text-decoration:none;
color:#000000;
border-bottom:1px dotted #000000;
}
.calnk a:visited {
text-decoration:none;
color:#000000;
border-bottom:1px dotted #000000;
}
.calnk a {
text-decoration:none;
color:#000000;
border-bottom:1px dotted #000000;
}
.calnk a span {
display:none;
}
.calnk a:hover span {
color:#333333;
background:#F6F79B;
display:block;
position:absolute;
margin-top:1px;
padding:5px;
width:150px;
z-index:100;
line-height:1.2em;
}
.calendar-table {
border:0 !important;
width:100% !important;
border-collapse:separate !important;
border-spacing:2px !important;
}
.calendar-heading {
height:25px;
text-align:center;
background-color:#E4EBE3;
}
.calendar-next {
width:20%;
text-align:center;
border:none;
}
.calendar-prev {
width:20%;
text-align:center;
border:none;
}
.calendar-month {
width:60%;
text-align:center;
font-weight:bold;
border:none;
}
.normal-day-heading {
text-align:center;
width:25px;
height:25px;
font-size:0.8em;
border:1px solid #DFE6DE;
background-color:#EBF2EA;
}
.weekend-heading {
text-align:center;
width:25px;
height:25px;
font-size:0.8em;
border:1px solid #DFE6DE;
background-color:#EBF2EA;
color:#FF0000;
}
.day-with-date {
vertical-align:text-top;
text-align:left;
width:60px;
height:60px;
border:1px solid #DFE6DE;
}
.no-events {
}
.day-without-date {
width:60px;
height:60px;
border:1px solid #E9F0E8;
}
span.weekend {
color:#FF0000;
}
.current-day {
vertical-align:text-top;
text-align:left;
width:60px;
height:60px;
border:1px solid #BFBFBF;
background-color:#E4EBE3;
}
span.event {
font-size:0.75em;
}
.kjo-link {
font-size:0.75em;
text-align:center;
}
.calendar-date-switcher {
height:25px;
text-align:center;
border:1px solid #D6DED5;
background-color:#E4EBE3;
}
.calendar-date-switcher form {
margin:2px;
}
.calendar-date-switcher input {
border:1px #D6DED5 solid;
margin:0;
}
.calendar-date-switcher input[type=submit] {
padding:3px 10px;
}
.calendar-date-switcher select {
border:1px #D6DED5 solid;
margin:0;
}
.calnk a:hover span span.event-title {
padding:0;
text-align:center;
font-weight:bold;
font-size:1.2em;
margin-left:0px;
}
.calnk a:hover span span.event-title-break {
width:96%;
text-align:center;
height:1px;
margin-top:5px;
margin-right:2%;
padding:0;
background-color:#000000;
margin-left:0px;
}
.calnk a:hover span span.event-content-break {
width:96%;
text-align:center;
height:1px;
margin-top:5px;
margin-right:2%;
padding:0;
background-color:#000000;
margin-left:0px;
}
.page-upcoming-events {
font-size:80%;
}
.page-todays-events {
font-size:80%;
}
.calendar-table table,tbody,tr,td {
margin:0 !important;
padding:0 !important;
}
table.calendar-table {
margin-bottom:5px !important;
}
.cat-key {
width:100%;
margin-top:30px;
padding:5px;
border:0 !important;
}
.cal-separate {
border:0 !important;
margin-top:10px;
}
table.cat-key {
margin-top:5px !important;
border:1px solid #DFE6DE !important;
border-collapse:separate !important;
border-spacing:4px !important;
margin-left:2px !important;
width:99.5% !important;
margin-bottom:5px !important;
}
.cat-key td {
border:0 !important;
}
</style>
<!-- teachPress -->
<script type="text/javascript" src="src/frontend.js"></script>
<link type="text/css" href="src/teachpress_front.css" rel="stylesheet">
<!-- END teachPress -->
<!-- <script type="text/javascript">var wpia_ajaxurl = 'https://mami-project.eu/wp-admin/admin-ajax.php';</script>-->
<!--<script type="text/javascript">
wppaImageDirectory = "https://mami-project.eu/wp-content/plugins/wp-photo-album-plus/img/";
wppaPhotoDirectory = "https://mami-project.eu/wp-content/uploads/wppa/";
wppaNoPreview = "No Preview available";
wppaTxtProcessing = "Processing...";
wppaTxtDone = "Done!";
wppaTxtErrUnable = "ERROR: unable to upload files.";
wppaOutputType = "-none-";
wppaShortcodeTemplate = "<div style="font-size:0;line-height:0;" ><img id="ph-14-0" src="https://mami-project.eu/wp-content/uploads/wppa/14.jpg?ver=1" alt="IMG_1057-e1455185786490.jpg" title="IMG_1057-e1455185786490.jpg" style="width:100%;margin:0;" /></div>";
wppaShortcodeTemplateId = "14.jpg";
</script>
<meta name="tec-api-version" content="v1"><meta name="tec-api-origin" content="https://mami-project.eu"><link rel="https://theeventscalendar.com/" href="https://mami-project.eu/index.php/wp-json/tribe/events/v1/"><meta name="twitter:partner" content="tfwp">-->
<!-- WPPA+ START Page specific urls and browser dependant data -->
<!--<script type="text/javascript">
wppaImageDirectory = "https://mami-project.eu/wp-content/plugins/wp-photo-album-plus/img/";
wppaWppaUrl = "https://mami-project.eu/wp-content/plugins/wp-photo-album-plus";
wppaIncludeUrl = "https://mami-project.eu/wp-includes";
wppaAjaxUrl = "https://mami-project.eu/wp-content/plugins/wp-photo-album-plus/wppa-ajax-front.php";
wppaUploadUrl = "https://mami-project.eu/wp-content/uploads/wppa";
wppaIsIe = false;
wppaIsSafari = false;
wppaUseSvg = true;
wppaSlideshowNavigationType = "icons";
wppaAudioHeight = 40;
</script>-->
<!-- WPPA+ END Page specific urls -->
<meta name="twitter:card" content="summary"><meta name="twitter:description" content="MAMI Project - This project received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 688421.">
<!-- WPPA+ Custom styles -->
<style type="text/css">
</style>
<!-- Rendering enabled -->
<!-- /WPPA Kickoff -->
</head>
<body class="home blog tribe-js tribe-bar-is-disabled">
<div id="wrapper" class="hfeed">
<div id="header">
<div id="masthead">
<div id="branding" role="banner">
<h1 id="site-title">
<span>
<a href="index.html" title="" rel="home"></a>
</span>
</h1>
<div id="site-description">MAMI Project – This project received
funding from the European Union’s Horizon 2020 research and innovation
programme under grant agreement No 688421.</div>
<img src="src/mami-bauhaus-text3.png" alt="" width="620" height="190">
</div><!-- #branding -->
<div id="access" role="navigation">
<div class="skip-link screen-reader-text"><a href="#content" title="Skip to content">Skip to content</a></div>
<div class="menu-header"><ul id="menu-main" class="menu"><li id="menu-item-62" class="menu-item menu-item-type-custom menu-item-object-custom current-menu-item current_page_item menu-item-home menu-item-62"><a href="index.html">Home</a></li>
<li id="menu-item-84" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-has-children menu-item-84"><a href="index.php/about-mami/index.html">About MAMI</a>
<ul class="sub-menu">
<li id="menu-item-177" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-177"><a href="index.php/objectives/index.html">Objectives</a></li>
<li id="menu-item-63" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-63"><a href="index.php/consortium/index.html">Consortium</a></li>
<li id="menu-item-153" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-153"><a href="index.php/workpackages/index.html">Workpackages</a></li>
<li id="menu-item-386" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-386"><a href="index.php/about-mami/external-advisory-board/index.html">External Advisory Board</a></li>
</ul>
</li>
<li id="menu-item-183" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-183"><a href="index.php/standardization-efforts/index.html">Standardization</a></li>
<li id="menu-item-79" class="menu-item menu-item-type-custom menu-item-object-custom menu-item-has-children menu-item-79"><a href="index.php/papers/index.html">Publications</a>
<ul class="sub-menu">
<li id="menu-item-78" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-78"><a href="index.php/deliverables/index.html">Deliverables</a></li>
<li id="menu-item-77" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-77"><a href="index.php/papers/index.html">Papers and Presentations</a></li>
</ul>
</li>
<li id="menu-item-358" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-358"><a href="index.php/weblinks/index.html">Software & Links</a></li>
<li id="menu-item-567" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-has-children menu-item-567"><a href="index.php/events/index.html">Events</a>
<ul class="sub-menu">
<li id="menu-item-626" class="menu-item menu-item-type-custom menu-item-object-custom menu-item-626"><a href="http://tma.ifip.org/2018/mnm-workshop/">MNM’18 Workshop</a></li>
<li id="menu-item-649" class="menu-item menu-item-type-custom menu-item-object-custom menu-item-649"><a href="http://summerschool.mami-project.eu/">MAMI Summer School</a></li>
<li id="menu-item-680" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-680"><a href="index.php/events/mami-management-and-measurement-summit-m3s/index.html">MAMI Management and Measurement Summit (M3S)</a></li>
<li id="menu-item-430" class="menu-item menu-item-type-custom menu-item-object-custom menu-item-430"><a href="http://tma.ifip.org/2017/workshops/mnm17-workshop/">MNM’17 Workshop</a></li>
</ul>
</li>
</ul></div> </div><!-- #access -->
</div><!-- #masthead -->
</div><!-- #header -->
<div id="main">
<div id="container">
<div id="content" role="main">
<div id="post-863" class="post-863 post type-post status-publish format-standard hentry category-uncategorized">
<h2 class="entry-title"><a href="index.php/2019/02/04/thanks-and-good-bye/index.html" rel="bookmark">Thanks and Good Bye!</a></h2>
<div class="entry-meta">
<span class="meta-prep meta-prep-author">Posted on</span> <a href="index.php/2019/02/04/thanks-and-good-bye/index.html" title="1:52 pm" rel="bookmark"><span class="entry-date">February 4, 2019</span></a> <span class="meta-sep">by</span> <span class="author vcard"><a class="url fn n" href="http://mirja.kuehlewind.net/" title="View webpage of Mirja Kühlewind">Mirja Kühlewind</a></span> </div><!-- .entry-meta -->
<div class="entry-content">
<p>As everything good also the MAMI project comes to an end, or actually
came to an end, as it is officially over since Dec 2018. Last week we
also had our final review meeting and that now really means, it’s done! I
guess that’s good and bad news.</p>
<p>The (b/s)ad news, first of all, is that this will be last post on
this blog. However, we will make sure that the webpage stays available
for another few years, so you can come back read the existing posts over
and over again, e.g. about PATHspider (<a href="index.php/2016/11/04/pathspider-plugins/index.html">plugin</a>, <a href="index.php/2017/02/25/2-years-of-pathspider-development/index.html">update</a>, and <a href="index.php/2018/01/12/pathspider-has-exciting-new-features-in-release-2-0-0/index.html" >2.0</a>), ECN (<a href="index.php/2016/06/13/70-of-popular-web-sites-support-ecn/index.html">here</a> and <a href="index.php/2019/01/30/ecn-pto/index.html">here</a>), IETF meeting reports (<a href="index.php/2016/04/15/mami-at-ietf95/index.html">95</a>, <a href="index.php/2016/07/30/mami-at-ietf96/index.html">96</a>, <a href="index.php/2016/07/29/applied-networking-research-workshop-at-ietf-96/index.html">ANRW-96</a>, <a href="index.php/2016/12/01/mami-at-ietf97/index.html">97</a>, <a href="index.php/2017/04/10/what-happened-at-ietf98-in-chicago-march-26-31/index.html">98</a>, <a href="index.php/2017/03/28/frist-prize-at-ietf98-hackathon-for-connection-identifier-in-dtls-group/index.html">hackathon-98</a>, <a href="index.php/2017/08/09/ietf99-quic-taps-panprg-maprg-acme-banana-ippm-a-busy-week-in-prague/index.html">99</a>, <a href="index.php/2017/11/22/ietf-100/index.html">100</a>, <a href="index.php/2018/04/20/ietf101-in-london-march-17-23/index.html">101</a>, <a href="index.php/2018/09/07/ietf-102-montreal/index.html">102</a>, <a href="index.php/2018/12/05/ietf-103-bangkok/index.html">103</a>),
and more meetings, events, and measurement results… also keep watching
our twitter account (@mamiproject) as we will keep you posted with
interesting news about Internet evolution and the usual events (IETF
meetings, research conferences, and there is another edition of the MNM
workshop coming up co-located with <a href="http://tma.ifip.org/2019/">TMA’19</a> in Paris)!</p>
<p>The good news is that I think we can call the project a success.
Looking back at the goals we were aiming for when we started the project
three years ago, it’s not quite were we are now, but many good things
have happened that we can call our achievement. The project was mainly
focused on problems with protocol ossification on the Internet and
subsequently arising limitations for protocol and service evolution.
These problems are still there, and it was never the assumption that we
could make them go away in (just) three years. However, we do understand
the problem and potential solutions to it much better and many small
steps have been taken. </p>
<p>Our initial proposal as a way forward was the introduction of a shim
layer for path cooperation, where the layer boundary is also the
encryption boundary to clearly separate path signaling from end-to-end
information. Chances seemed promising to deploy our approach together
with the introduction of a completely new transport protocol, QUIC, when
we started the project but at the end it didn’t happen that way. Still
the idea of a carefully designed <strong><em>wire image</em></strong> that provides explicit signals to the path has spread the word and is now defined in <a href="https://datatracker.ietf.org/doc/draft-iab-wire-image/">standards</a> and applied by the <a href="https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/311830/spinbit-imc-authors-copy.pdf?sequence=8&isAllowed=y">Spin Bit</a> in <a href="https://datatracker.ietf.org/doc/draft-ietf-quic-transport/">QUIC</a>.</p>
<div class="wp-block-image"><figure class="aligncenter is-resized"><img src="src/QUIC-mic-queue-1024x596.jpg" alt="" class="wp-image-601" width="367" height="213"><figcaption>Discussion at IETF QUIC meeting about the Spin Bit.</figcaption></figure></div>
<p>And then there are also a couple of lessons learnt, or let’s call it
take-aways, that, I’m pretty sure of, not only the MAMI partners will
further apply in their future research work and standardization efforts
but that have also influenced the community as a whole in how we think
about the Internet and protocol design. For example, the main take-away
from the <a href="index.php/2018/10/22/the-mami-management-and-measurement-summit/index.html">M3S workshop</a>,
that we held last year with a bunch of industry stakeholders, is that
future in-network function need to be visible to the endpoints and will
need consensus from both sides (also see the <a href="https://github.com/mami-project/roadshows/blob/master/m3s-london/m3s-white-paper.pdf">M3S report</a>).
That doesn’t sound like a groundbreaking insight, however, it is a
change in how we designed and operated the Internet so far, as without
the wide-spread deployment of encryption or at least (integrity)
protection, the easiest and cheapest way has often not followed this
principle.</p>
<p>Another effort by the MAMI project, that has impacted the way we
design and discuss protocols, is our measurement work. Our approach here
was always to base design decisions on measured evidence. The challenge
here is not only to measure the right thing at the right point of time
but to also to collect enough measurement data in order to draw a
signification conclusion whether an observed impairment will be barrier
for deployment or not. Good engineering decisions require not only
information about the types of impairments that can arise, but estimates
of the risk of encountering them on any particular type of network.
Over the last three year we have performed a whole bunch of measurement
studies, many of them with our own tool for path transparency
measurements <a href="https://pathspider.net/">PATHspider</a> that will further be used and maintained by an ex-MAMIan who is now working with the <a href="https://www.torproject.org/">TOR project</a>. We published our findings as papers, in blog posts, or presented them directly at standardization events (see e.g. <a href="https://datatracker.ietf.org/rg/maprg/meetings/">IRTF maprg</a>) and other industry meetings. And our results on e.g. <a href="http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper12.pdf">ECN</a>, <a href="https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00">DSCP</a>, <a href="http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf">PMTU</a>, or <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones">IP checksum calculation</a> have impacted and are still impacting work in the IETF tsvwg (<a href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/">this</a>, <a href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/">this</a>, and <a href="https://datatracker.ietf.org/doc/draft-fairhurst-udp-options-cco/">this</a>) and <a href="https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/">tcpm</a> as well as operations directly (see <a href="https://blog.cloudflare.com/increasing-ipv6-mtu/">cloudefare blog</a>).</p>
<p>However, doing measurements is hard work and costs time and money.
Therefore we always had this vision of utilizing the measurement data as
a whole that we have collected as a community over so many years. This
idea has driven the work on our own repository system, called the <a href="https://observatory.mami-project.eu/">Path Transparency Observatory (PTO)</a>,
as well as the commitment of some of the MAMI partners to support and
drive efforts to increase repeatability and reproduciblility of
measurement results or actually research results in general in the CS
networking community (see <a href="http://vaibhavbajpai.com/documents/papers/proceedings/reproducibility-sigcomm-workshop-2017.pdf">here</a>, <a href="https://www.dagstuhl.de/en/program/calendar/semhp/?semnr=18412">here</a>, and <a href="https://github.com/hyperpaper/ccr-ednote/raw/master/cccp.pdf">here</a>).</p>
<div class="wp-block-image"><figure class="aligncenter is-resized"><img src="src/IMG_6876-1024x739.jpg" alt="" class="wp-image-712" width="262" height="188"><figcaption>M&Ms and MAMI T-shirt at Mobile Network Measurement (MNM) workshop.</figcaption></figure></div>
<p>So while we will all not work together as a project anymore (and
distribute nice stickers and M&Ms), you can see that the work of the
project will not stop with end of the project funding. I think I can
well speak for everybody in the project and say that we really enjoyed
working together and are at least a little proud of what we have
achieved in the last three years. Thanks for everybody who has worked on
the project, as well as our “MAMI friends” who have not only joint us
for many fun dinners and lunches (e.g. see draft beer tour in Berlin)
but also collaboratively worked with us (see <a href="https://datatracker.ietf.org/doc/draft-trammell-taps-post-sockets/">post socket</a>/<a href="https://datatracker.ietf.org/wg/taps/documents/">taps</a>) or provided good and valuable advise (e.g. the <a href="index.php/about-mami/external-advisory-board/index.html">EAB</a>)!
Other than that, all that’s left to say is: keep enjoying our stickers
if you still have some and see you soon no matter what!</p>
<div class="wp-block-image"><figure class="aligncenter is-resized"><img src="src/IMG_0137-1024x768.jpeg" alt="" class="wp-image-806" width="322" height="242"><figcaption>Last “official” MAMI lunch at IETF-103 in Bangkok.</figcaption></figure></div>
<p></p>
</div><!-- .entry-content -->
</div><!-- #post-## -->
<div id="post-848" class="post-848 post type-post status-publish format-standard hentry category-uncategorized">
<h2 class="entry-title"><a href="index.php/2019/01/30/ecn-pto/index.html" rel="bookmark">Observing the Evolution of ECN Support with the PTO</a></h2>
<div class="entry-meta">
<span class="meta-prep meta-prep-author">Posted on</span> <a href="index.php/2019/01/30/ecn-pto/index.html" title="4:25 pm" rel="bookmark"><span class="entry-date">January 30, 2019</span></a> <span class="meta-sep">by</span> <span class="author vcard"><a class="url fn n" href=" https://trammell.ch/" title="View webpage of Brian Trammell">Brian Trammell</a></span> </div><!-- .entry-meta -->
<div class="entry-content">
<p>If you’ve followed the MAMI project over the past three years,
you know that we are big fans of Explicit Congestion Notification (<a href="index.php/2016/06/13/70-of-popular-web-sites-support-ecn/index.html">ECN</a>).
First, it provides an illustrative case study of the deployment of an
optional transport protocol feature: standardized in 2001, deployment
lagged for a decade due to reports of its signaling crashing certain
routers, and rolled out slowly on the server side due to defaults in the
Linux kernel, until deployment accelerated due to client-side defaults
in Mac OS X. Second, manipulation of ECN is <a href="https://irtf.org/anrw/2017/anrw17-final16.pdf">indicative</a> of other TCP and IP manipulations, especially of DSCP.</p>
<p>Let’s have a look at the evolution of ECN support and problems with ECN in the MAMI <a href="https://observatory.mami-project.eu/">Path Transparency Observatory</a>
front-end. The front page shows a matrix, from which we can see that we
have ECN measurements back to 2014 (including measurements taken before
the project, and before the development of <a href="https://pathspider.net/">PATHspider</a>):</p>
<p><img class="aligncenter size-medium wp-image-849" src="src/pto-matrix-300x279.png" alt="" width="300" height="279"> The <a href="https://observatory.mami-project.eu//static/charts.html?page=ecn">charts page</a> for ECN has charts for raw observations of ECN-dependent connectivity failure (<code>ecn.connectivity</code> conditions), as well as charts of ECN negotiation. Let’s look at connectivity first:</p>
<p><img class="aligncenter size-large wp-image-850" src="src/ecn-connectivity-green-1024x500.png" alt="" width="640" height="313"></p>
<p>The top chart shows the proportion of observations we have of each
condition, and the bottom chart shows the absolute number of
measurements. Green (<code>ecn.connectivity.works</code>) is good: indeed, attempting to ECN does not often cause problems with connectivity<a href="#footnote-1"><sup>1</sup></a>.
By clicking on the conditions above the chart, we can disable the
display of certain states; by doing this for all conditions except <code>ecn.connectivity.broken</code> (i.e., attempts to negotiate ECN cause connectivity failure), we can see the following clear downward trend:</p>
<p><img class="aligncenter size-large wp-image-851" src="src/ecn-connectivity-red-1024x502.png" alt="" width="640" height="314"></p>
<p>Clicking on one of these bars brings up a detail view of the
observations from which it is derived (If the observation query for that
bar has not already been cached, you may have to wait). To learn more
about each target, clicking on the IP address will pull up the <a href="https://stat.ripe.net/">RIPEstat</a> page for that address.</p>
<p><img class="aligncenter size-medium wp-image-852" src="src/ecn-connectivity-obs-300x210.png" alt="" width="300" height="210"></p>
<p>For many measurements, we have data taken from multiple vantage
points toward the same targets, in order to attempt to find “on-path”
(as opposed to “near-server”) interference with ECN; these are
represented in <code>ecn.multipoint</code> conditions:</p>
<p><img class="aligncenter size-large wp-image-853" src="src/multipoint-negotiation-1024x444.png" alt="" width="640" height="278"></p>
<p>Here we see another unsurprising up-and-to-the-right trend: due in
large part to the dominance of Linux web servers and reasonable
practices on upgrading them, of about 800000 measurements we took from
three vantage points (in Toronto, Amsterdam, and Singapore) this week,
more than 86% support ECN negotiation. By zooming in on on <code>ecn.multipoint.negotiation.path_dependent</code> conditions, we can see that there are still a few servers accessible via paths with TCP header manipulation deployed:</p>
<p><img class="aligncenter size-large wp-image-854" src="src/multipoint-path-dependent-1024x442.png" alt="" width="640" height="276"></p>
<p>We invite you to explore the PTO. To learn more about the PTO itself, have a look at our <a href="/wp-content/uploads/2019/01/D12.pdf">Deliverable 1.2,</a>
which details its design. All of the software behind the PTO is
available open source: the core PTO server and tools for running
normalization and analysis are in the <a href="https://github.com/mami-project/pto3-go">pto3-go</a> repository, and the web front-end in <a href="https://github.com/mami-project/pto3-web">pto3-web</a>. Normalizers and analyzers for ECN are in <a href="https://github.com/mami-project/pto3-ecn">pto3-ecn</a>.</p>
<hr>
<p><a name="footnote-1"></a>1: The grey in the
low-volume measurement during the week of 14 January represents a large
number of “offline” measurements, where a site was not reachable with or
without ECN; this represents a transient connectivity We can click on
the</p>
</div><!-- .entry-content -->
</div><!-- #post-## -->
<div id="post-821" class="post-821 post type-post status-publish format-standard hentry category-uncategorized">
<h2 class="entry-title"><a href="index.php/2018/12/20/mami-active-measurement-hackathon-in-aberdeen-scotland/index.html" rel="bookmark">MAMI Active Measurement Hackathon in Aberdeen, Scotland</a></h2>
<div class="entry-meta">
<span class="meta-prep meta-prep-author">Posted on</span> <a href="index.php/2018/12/20/mami-active-measurement-hackathon-in-aberdeen-scotland/index.html" title="10:22 am" rel="bookmark"><span class="entry-date">December 20, 2018</span></a> <span class="meta-sep">by</span> <span class="author vcard"><a class="url fn n" href="https://iain.learmonth.me/" title="View webpage of Iain R. Learmonth">Iain R. Learmonth</a></span> </div><!-- .entry-meta -->
<div class="entry-content">
<p>On the 5th December 2018 we kicked off a two-day hackathon with participants from MAMI and the <a href="https://ooni.torproject.org/">Open Observatory of Network Interference</a> at the University of Aberdeen. The goal of the hackathon was to share experiences in Internet measurement between our projects.</p>
<p></p><center><img src="src/mamiooni-300x120.png" alt="" class="alignnone size-medium wp-image-822" width="300" height="120"></center><p></p>
<p>We started with presentations from the participants to get everyone
up to speed on what each other had been working on. Iain Learmonth
presented <a href="https://pathspider.net/">PATHspider</a>, Simone Basso presented <a href="https://ooni.torproject.org/install/ooniprobe/">ooniprobe</a> and Raffaele Zullo presented <a href="http://www.middleboxes.org/tracemore/">tracemore</a>.</p>
<p>While the MAMI measurements have had an Internet engineering focus
attempting to find broken behavior in the Internet, OONI measurements
focus on finding censorship in the Internet. Typically both broken
behavior and censorship can be found implemented in middleboxes and so
there is overlap between these areas of interest.</p>
<p>In <a href="https://irtf.org/anrw/2017/anrw17-final16.pdf"><em>Tracking transport-layer evolution with PATHspider</em></a>,
we identified with PATHspider that protocol-dependent connectivity
failures can be correlated with networks that have large-scale
censorship infrastructure. This is probably not deliberate, but a side
effect of misconfiguration or poorly written software running on these
boxes. To allow for OONI to leverage this discovery, three of the
PATHspider tests for discovering broken middleboxes have been added to
the <a href="https://github.com/ooni/spec">OONI test specifications</a> repository.</p>
<p>The tests we have added are for protocol-dependent connectivity failure of: <a href="https://github.com/ooni/spec/blob/master/techniques/tq-031-attempt-ecn.md">ECN</a>, <a href="https://github.com/ooni/spec/blob/master/techniques/tq-033-attempt-tfo.md">TCP Fast Open</a> and <a href="https://github.com/ooni/spec/blob/master/techniques/tq-032-attempt-h2-upgrade.md">H2</a>. Support for executing these tests in <a href="https://github.com/measurement-kit">measurement-kit</a>, the measurement library developed for use in ooniprobe, has already been added for <a href="https://github.com/measurement-kit/mkcurl/commit/a5c258b5ecd30692d988cea281487e0daff47600">TCP Fast Open</a> and <a href="https://github.com/measurement-kit/mkcurl/commit/dea2a85fd535192b1cf35af164c97c9eff202de4">H2</a>.</p>
<p>Ana Custura added <a href="https://github.com/mami-project/pathspider/commit/b6a578ac5c96b9f198378f04c10c742074d5cc34">support for using arbitrary socket options</a> for DNS-based plugins in PATHspider that will enable new measurements that previously could only be performed with TCP.</p>
<p>One issue with PATHspider is that many of the tests require
privileged access to the device, while OONI would like to have
volunteers run measurements from their Android devices without requiring
“rooting” or other techniques. We explored whether the ability to <a href="https://lwn.net/Articles/625224/">add eBPF programs to sockets</a>
used for measurements might be a substitute for privileged access and
our initial thought experiments looked promising, however we did not
have time to implement any experiments.</p>
<p>The MAMI project would like to thank <a href="https://www.torproject.org/">Tor Project</a> for partially supporting the costs for this event.</p>
</div><!-- .entry-content -->
</div><!-- #post-## -->
<div id="post-815" class="post-815 post type-post status-publish format-standard hentry category-uncategorized">
<h2 class="entry-title"><a href="index.php/2018/12/11/the-future-of-middlebox-cooperation-in-the-internet-protocol-stack/index.html" rel="bookmark">The Future of Middlebox Cooperation in the Internet Protocol Stack</a></h2>
<div class="entry-meta">
<span class="meta-prep meta-prep-author">Posted on</span> <a href="index.php/2018/12/11/the-future-of-middlebox-cooperation-in-the-internet-protocol-stack/index.html" title="5:22 pm" rel="bookmark"><span class="entry-date">December 11, 2018</span></a> <span class="meta-sep">by</span> <span class="author vcard"><a class="url fn n" href=" https://trammell.ch/" title="View webpage of Brian Trammell">Brian Trammell</a></span> </div><!-- .entry-meta -->
<div class="entry-content">
<p>As you may have read in our last post, the MAMI project is
celebrating the hard-won, long-discussed consensus to add a spin bit to
QUIC. The spin bit was conceived as the minimum useful explicit signal
one could add to a transport protocol, and we think the benefit for the
overhead is quite worth it. Though it exposes “just” RTT, latency
(together with data rate, which is available in QUIC simply by counting
packets and bytes on the wire) is possibly the most important metric for
understanding transport layer performance diagnosing all matter of
transport-relevant network problems, and the spin signal itself can also
be observed to infer loss and other issues with network treatment of a
packet stream. The definition and deployment of the spin bit is
therefore a victory for <a href="https://arxiv.org/pdf/1612.02902v1.pdf">making network protocols more measurable</a> while preserving the privacy gains from encryption, and a victory for network operations and management.</p>
<p>When we started the MAMI project, we had a much more extensive vision for middlebox cooperation: our <a href="https://nsg.ee.ethz.ch/fileadmin/user_upload/CNSM_2017.pdf">Path Layer UDP Substrate (PLUS) proposal</a>
provides a generalized signaling mechanism allowing signals from the
sender to the path element, as well as a mechanism for allowing on-path
elements to communicate information to the receiver (and back to the
sender with the receiver’s assistance) in a safe, limited way, all with
end-to-end integrity protection. However, we failed to achieve consensus
to move forward in the IETF with this proposal by forming a working
group, so we refocused our efforts on a more modest implementation of
the explicit signaling concept.</p>
<p>Selective exposure, however, has a pretty toxic reputation in the
IETF, as it “breaks” TLS, by adding a third-party to a two-party
protocol and changing its security properties, reducing or eliminating
integrity and confidentiality protection with respect to a set of
entities in the network that may or may not be known to one or both
endpoints. In our <a href="https://github.com/mami-project/roadshows/blob/master/m3s-london/m3s-white-paper.pdf">recently published white paper</a>, the outcome of the <a href="index.php/2018/10/22/the-mami-management-and-measurement-summit/index.html">M3S meeting</a>, we argued that all approaches in this space must provide transparency and control to the endpoints.</p>
<p>In hindsight, more important to the controversy around PLUS was (in
our opinion) a fundamental misunderstanding about what is meant by the
term “middlebox cooperation”, as there are two broad approaches to
supporting on-path operations on encrypted traffic being pursued in the
industry:</p>
<ul>
<li>Explicit signaling approaches like PLUS, where information about
encrypted traffic is carried separately from the encrypted traffic
itself.</li>
<li>Selective exposure approaches like mcTLS, mbTLS, eTLS and so on,
which share secrets from the end-to-end cryptographic context with
middleboxes, allowing them to decrypt (and in some cases, modify)
traffic between the endpoints.</li>
</ul>
<p>We focused on explicit signaling in MAMI, in part due to the
difficulty of building selective exposure approaches that still provide
useful security properties for the end-to-end communication. However,
large parts of industry are more interested in selective exposure,
because building and deploying selective exposure approaches promises to
be more easily backward-compatible with existing protocols and network
hardware. PLUS, after all, envisioned deploying a new transport protocol
stack. We examine the tradeoffs in these approaches in <a href="wp-content/uploads/2018/12/white-paper.pdf">another white paper</a>, released today.</p>
<p>Among the arguments presented against PLUS at our BoF in Berlin in
July 2016 were doubts that the protocol was safe in general: that it
provided new side-channels for data exfiltration or hooks for coercion.
We looked into this as part of our own internal study of
integrity-protected, encrypted-payload middlebox cooperation approaches
like PLUS, finding in a <a href="https://github.com/mami-project/roadshows/raw/master/security-white-paper/mcp-security-white-paper.pdf">white paper</a>, also released today, that the additional attack surface presented by PLUS is negligible.</p>
<p>The looming end of the project does not mean the end of the problems
we set out to solve, or interest among the project participants and the
field in general in improving privacy and evolvability through
encryption while retaining limited support for in network functions. So,
we ask ourselves: <em><strong>what’s next?</strong></em></p>
<p>Several threads of work in this space will outlive MAMI:</p>
<p>Our efforts to add measurability to QUIC, which appears to represent
the first real hope of deployable transport evolution in the last three
decades, will of course continue. And QUIC itself will continue to
evolve. The group of implementors and network folks we’ve helped pull
together around the spin bit will keep experimenting with the best ways
to make it possible to do passive measurement and diagnosis, as QUIC
traffic increasingly supplants TCP.</p>
<p>Our work on experimentation with the Loss/Latency Tradeoff (LoLa)
signal continues, as we noted in the previous blog bost. LoLa may enable
better performance for real-time communications traffic and was first
specified as a bit in the PLUS header continues, with a possible
implementation as a DSCP codepoint.</p>
<p>The IRTF Path Aware Networking Research Group (PANRG), founded by the project, is pursuing work both in <a href="https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/">understanding why</a> previous attempts to consider middleboxes in transport layer interactions have failed, and in<a href="https://datatracker.ietf.org/doc/draft-enghardt-panrg-path-properties/"> exploring a set of properties</a> of end-to-end paths on which future explicit signaling methods could be built.</p>
<p>Further, there is ongoing work on UDP options in the <a href="https://datatracker.ietf.org/group/tsvwg/documents/">IETF TSVWG</a>
and a discussion about support for proxying of UDP-based, encrypted
protocol started in the at IETF-103 with some initial presentations
about <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvarea-feature-requests-for-advanced-udp-proxying-katharine-daly-00">requirements</a> and <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvarea-proxying-encrypted-transports-thomas-fossati-00">use cases</a> in the <a href="https://datatracker.ietf.org/meeting/103/materials/agenda-103-tsvarea-02">tsvarea session</a>.</p>
<p>We are very happy that this important discussion is continued and
that we as a project could provide a valuable input based on measurement
and experimentation. And while the project’s time had to come to an end
at some point, the MAMI contributors will keep working on this in order
to keep the Internet operational as well as improve its
robustness in operation, performance, and security.</p>
<p> </p>
</div><!-- .entry-content -->
</div><!-- #post-## -->
<div id="post-770" class="post-770 post type-post status-publish format-standard hentry category-uncategorized">
<h2 class="entry-title"><a href="index.php/2018/12/05/ietf-103-bangkok/index.html" rel="bookmark">IETF 103 Bangkok</a></h2>
<div class="entry-meta">
<span class="meta-prep meta-prep-author">Posted on</span> <a href="index.php/2018/12/05/ietf-103-bangkok/index.html" title="6:31 pm" rel="bookmark"><span class="entry-date">December 5, 2018</span></a> <span class="meta-sep">by</span> <span class="author vcard">Thomas Fossati</span> </div><!-- .entry-meta -->
<div class="entry-content">
<p>The MAMI project was back at the IETF for the last time — as a
project, anyway — last month at IETF 103 in Bangkok. Join us on a trip
through the week!</p>
<p></p><div id="attachment_807" style="width: 310px" class="wp-caption aligncenter"><img class="wp-image-807 size-medium" src="src/IMG_7192-300x225.jpg" alt="" width="300" height="225"><p class="wp-caption-text">the IETF 103 venue in Bangkok</p></div><p></p>
<h2>Hackathon: Loss-Latency Tradeoff in Mobile Networks</h2>
<p>Most of us arrived on the Friday before the meeting in order to
attend the now already traditional hackathon. This time we set up a
table to pull together a few different projects related to measurement
and measurability. Friends of the project Fabio Gulgarella and Mauro
Cociglio ran an experiment running on a 2-bit variant of the spin-bit
they dubbed “delay sample”. Thomas Fossati, as main representative of
the MAMI project, has been doing some measurements on the impact of the
LoLa bit on the mobile network.</p>
<p>This is another instance of the “one-bit signalling” topic we’ve been
working on in MAMI – notably, a Loss/Latency Tradeoff (LoLa) bit was
present in the <a href="https://www.ietf.org/archive/id/draft-trammell-plus-spec-01.txt">original PLUS proposal</a>.
These experiments are concerned with mapping the LoLa signal to a
dedicated low-latency bearer in the LTE core and air interface. This is
different from how mobile networks are deployed today, to actively
ignoring <a href="http://dl.ifip.org/db/conf/tma/tma2017/mnm2017_paper13.pdf">or bleaching</a>
any end-user signal, and bundling all flows to and from the Internet
into a single “default” bearer, whose buffering characteristics that are
not compatible with low-latency traffic. The established behaviour is
partly rooted in the desire to prioritise operators’ voice services over
competing over-the-top services, but that market consideration has lost
relevance in the recent years.</p>
<p>It looks like the incentives are now aligned in the direction of
allowing more suitable treatment of Internet real-time flows. However, a
couple of preconditions need to be satisfied before we can move on from
the status quo. First, the real-time flows must be efficiently
identified so that they can be put on the right queue especially nearby
the bottleneck link, which in 4G mobile networks is typically the air
interface. This is at odds with the rise of encrypted and multiplexed
transports, which has the potential of increasing the cost/accuracy
ratio of DPI over the acceptable threshold. LoLa instead is this simple
clear-text signal set by the endpoints which would enable a super
efficient classifier. The question is how can we trust the endpoints to
set the LoLa signal correctly? What if they lie? Would they get an
advantage at the expenses of other flows? The hackathon experiments were
aimed at answering these core questions. On one hand we wanted to see
whether giving mobile devices a low-latency bearer in addition to the
default one would make a difference in terms of QoE. And secondly, we
wanted to measure what happens when an endpoint lies about the nature of
its flows. So Thomas spent his Saturday and Sunday hacking around the
LTE module of NS-3 and getting these <a href="https://github.com/mami-project/roadshows/blob/master/ietf-103-lola/hotrfc/build/main.pdf">fine results</a>
which he also presented at the HotRFC session on Sunday night. We got
some positive feedback about the idea from a few mobile operators in the
room. Thomas, Gorry Fairhurst and Mirja Kühlewind together with
Vz, AT&T, Orange and Three managed to schedule a side meeting for
later in the week to discuss both the finer points and an overall
coordination strategy also involving and the 3GPP liaison Georg Mayer
and Florin.</p>
<h2>Hackathon: Path MTU Signaling in QUIC</h2>
<p>In addition, Tom Jones worked on Path MTU signaling mechanisms for QUIC at the QUIC hackathon table. Tom’s draft describing <a href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud">“Packetization Layer Path MTU Discovery for Datagram Transports”</a>
will also be incorporated in QUIC. MTU discovery is also under
discussion in the 6MAN Working Group, where there are two competing
proposals to add new mechanisms that allow better signalling of MTU by
routers a long the path, Truncate and Hop By Hop:</p>
<ul>
<li>The Truncate proposal adds a MTU Destination Option, the intention
of this option is that when a router has to discard a packet for being
too large it also truncates the datagram. The MTU Destination Option
carries the original packet length allowing the end host to detect this
packet as ‘truncated’, and the end host uses this packet to send an ICMP
PTB message.</li>
<li>The Hop By Hop proposal creates a new IPv6 Hop By Hop option. This
option is added to small packets, when a router forwards a packet with
this option it examines the MTU field in the option, if the MTU is
larger than the routers out going link it updates the MTU field to match
this link size.</li>
</ul>
<p>Tom implemented the HBH proposal at the IETF 103 Hackathon to get a
sense of how practical it was to add to a real network stack — he had
previously implemented the Truncate proposal on the flight back from
IETF102 in Montreal. His inplementation in FreeBSD achieved self-interop
between end host and router in the two days. Running code is a core
part of the IETF ethos, after IETF 103 we are able to compare how the
HBH and Truncate proposals compare and differ in implementation.</p>
<h2>Monday: Evolving Transport</h2>
<p>On Monday, the official sessions started with an interesting
discussion about the evolution of transport and the role of proxies in
the Transport area open meeting featured with presentations from Lucas
Pardue and Ben Schwartz’s team on <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvarea-quic-addendums-lucas-pardue-00">HiNT</a> and <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvarea-feature-requests-for-advanced-udp-proxying-katharine-daly-00">Helium</a> and a presentation from Thomas on <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvarea-proxying-encrypted-transports-thomas-fossati-00">PEPs role and fate</a>
in an end-to-end encrypted Internet. One of the takeaways of the
session is that if we want to keep PEPs alive, which looks like a
sensible thing to do at least in some scenarios (cfr. <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-quic-and-satcom-nicolas-kuhn">satellite</a>), we need to re-think the security model in particular how the <a href="https://www.ietf.org/archive/id/draft-kuehlewind-crypto-sep-00.txt">transport security association is modelled</a>
and what is its relationship with the security context that sits at the
application layer. QUIC in particular, collapses the two into a single
inextricable blob, making proxying an all-or-nothing option, which is
far from ideal. The “transport proxy” gang (including us, Lucas and
Ben’s team) is going to chat further again in December to discuss next
steps.</p>
<p>Then the first TSVWG session on Monday touched a little on the PMTUD
work happening in other working groups, as already mentioned above. And
we had a presentation by friend-of-the-project Colin Perkins on the <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvwg-sessb-31-impact-of-transport-header-encryption-00">Transport Header Encryption Draft</a>,
recently adopted by the WG, which explores transport-specific
considerations of the trend toward more ubiquitous encryption and
encryption deeper down the stack.</p>
<h2>Tuesday: Measurement and Analysis for Protocols and the MAMI Lunch</h2>
<p>The founded-by-MAMI Measurement and Analaysis for Protocols Research
Group (MAPRG) met on Tuesday. This time we had an 2-hour slot (slightly
shorter than usually) with interesting talk about <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones">UDP checksum issues</a>, <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-quic-and-satcom-nicolas-kuhn">QUIC performance over satellite</a>, <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-evaluating-the-performance-of-coap-mqtt-and-http-in-vehicular-scenarios-jaime-jimenez">comparison of CoAP/MQTT/HTTP in vehicular scenarios</a>, as well as measurements on <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-the-rise-of-certificate-transparency-and-its-implications-on-the-internet-ecosystem-matthias-wahlisch">Certificate Transparency</a> and <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-is-the-web-ready-for-ocsp-must-staple-nick-sullivan">OCSP Must Staple deployment</a>.</p>
<p>Tuesday also saw our traditional lunch for MAMI and friends:</p>
<p><img class="aligncenter wp-image-806 size-large" src="src/IMG_0137-e1544006429835.jpeg" alt="" width="640" height="480"></a></p>
<h2>Tuesday and Wednesday: QUIC and the Spin Bit</h2>
<p>Since MAMI is largely focused on transport evolution, and transport
evolution work in the IETF is now focused on the completion and
deployment of the IETF standard version of QUIC, the “main event” of the
IETF for the project was the QUIC working group. QUIC met on Tuesday
and Wednesday. Tuesday’s meeting covered smaller issues, including the <a href="http://datatracker.ietf.org/doc/draft-ietf-quic-applicability">applicability</a> and <a href="http://datatracker.ietf.org/doc/draft-ietf-quic-manageability">manageability</a> drafts, presented by Mirja.</p>
<p>After 18 months of heated discussion and thorough experimentation, the latency <a href="https://blog.apnic.net/2018/05/11/explicit-passive-measurability-and-the-quic-spin-bit/">spin bit</a>
was been accepted during the second session on Wednesday as a
feature of the base QUIC protocol. Implementation and participation in
signaling are optional, though several large endpoint implementors
indicated they will implement and enable the bit by default. The
consensus is to add just the spin bit, without the Valid Edge counter
described in our recent <a href="https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/311830/spinbit-imc-authors-copy.pdf">IMC paper</a>.</p>
<p></p><div id="attachment_812" style="width: 650px" class="wp-caption aligncenter"><img class="wp-image-812 size-large" src="src/DrXflNFU4AAuoAl.jpeg" alt="" width="640" height="427"><p class="wp-caption-text">QUIC hums on the Spin Bit (image: <a href="https://twitter.com/csperkins">@csperkins</a>)</p></div><p></p>
<p>This proposal has been pretty controversial, not so much technically
but rather from a political perspective – being a proxy for the wider
(and highly flammable) discussion around the tension between protocol
encryption and network functions in the IETF. One key takeaway of this
whole experience (and a key result of the MAMI project as a whole) is
that getting the right balance between opaqueness and transparency a
protocol’s wire image should provide is a very tough job and requires a
great deal of analysis and experimentation along many different axes.</p>
<p>After three years working on these topics, and despite the
hyper-sensitivity to privacy issues in the Internet many of us in the
project have, we are even more then ever convinced that a world of
completely opaque wires is not a place where we would like to spend our
future, and that total privacy and total privatisation of the Internet
infrastructure are two sides of the same coin. The Internet is a common
good and we need to keep it that way, finding the right balance between
what is visible and what is not is a tough job but we need to resist the
temptation to use the encryption hammer for things that are not
necessarily privacy related – e.g., as anti-ossification techniques. We
very much hope that this decision enables now more experimentation and
will lead to more experience with these kind of explicit signals which
can be the basis for more discussion about additional features that
would support measurability.</p>
<h2>Wednesday: UDP Options, MARC, and Encrypted SNI</h2>
<p>Wednesday morning also saw the second TSVWG Working Group session discussing the status of <a href="https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvwg-sessa-51-cco-and-implementation-status-for-udp-options-02">UDP Options</a>,
with Tom presenting an implementation report. Tom also followed up on
questions asked on the TSVWG mailing list about the future and
suitability of <a href="https://mailarchive.ietf.org/arch/msg/tsvwg/83z8i3gGFaVETaihkwheMYsdCmc">FRAG, LITE and AE UDP Options.</a>
This led to an enthusiastic discussion about the suitability and use of
UDP Options at all. Tom continued with another presentation, this time
on Datagram PLPMTUD, this slot was grouped with presentations from the
authors of the 6MAN drafts attempting to address PTMUD. These
presentations led to very productive working group discussion on both
PLPMTUD and PMTUD, with finding the right MTU for a network still being
an open problem.</p>
<p>The video interest group (GGIE) side meeting we presented MARC
(mobile assisted rate controller), the congestion controller developed
by Morteza and Gorry in the project that uses (among others) the <a href="https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-04.txt">mobile throughput guidance</a>
signal from the eNodeB to adapt the sending rate to the (very quickly
and widely) changing conditions of the mobile network. There was an
entertaining discussion around the topic including a nice digression on
how to carry the MTG signal in QUIC using UDP options.</p>
<p>In TLS there was more discussion about the encrypted SNI proposal
which is trying to remove one privacy-critical bit of clear-text from
the TLS wire image. Of course SNI is relevant to policing middleboxes
(enterprise TLS proxies, censorship and parental control filters), hence
some of the usual scuffle. There are a couple of issues with the
current ESNI proposal, one of which is pretty substantial in terms of
the ability to reliably deploy the feature, but there is a huge amount
of energy being poured into finding a good solution so hopefully we are
going to get something done soon-ish. On another topic, the DTLS 1.3
protocol specification is complete and ready for review by the working
group. We need some security analysis there which will take a fair
amount of cycles. In the meantime, the DTLS 1.2 connection identifier is
done and is currently in working group last call. So this should
provide an OK solution (although not ideal because of the higher
correlation properties compared to 1.3) until 1.3 is finalised and
deployed at scale.</p>
<h2>Wednesday: Transport Services (TAPS)</h2>
<p>The Transport Services (TAPS) working group, in which MAMI heavily
contributes, continues its work to standardize an interface to a modern
Internet transport layer. The group had a productive session, solving
some of the <a href="https://github.com/taps-api/drafts/issues">open issues</a> for the <a href="https://datatracker.ietf.org/doc/draft-ietf-taps-interface/">API document</a>.
In addition Tommy Pauly, another friend of the project, presented a
mapping of the TAPS interface to QUIC, leading to a discussion about
mappings for different DNS variants (DoT, DoH, … Do*) as a quite
interesting use case for taps, given it could actually provide an
opportunity to simplify future mappings of DNS to other transports.</p>
<p>If you’d like to help the TAPS effort as well, it’s now the right time to review the <a href="https://datatracker.ietf.org/doc/draft-ietf-taps-arch">architecture document</a> as the first of the taps trilogy, to be published around IETF 104 in March 2019.</p>
<h2>Thursday: ACME, Round Tables, and Not-So-Secret Cabals</h2>
<p>The very last session of the meeting was ACME. MAMI has a couple of drafts there: the <a href="https://datatracker.ietf.org/doc/draft-ietf-acme-star/">STAR</a>
document, which is going through a second LC as we speak due to some
adjustments we had to do related to a pretty big last minute change in
the base ACME spec, and the <a href="https://datatracker.ietf.org/doc/draft-sheffer-acme-star-delegation/">delegation</a>
draft, which we have re-written as an ACME profile (as per request in
Montreal) which – good news everyone! – we got consensus to adopt by the
working group. As per IETF process, the official CfA confirmation is
currently on the mailing list and should be over in a few days.</p>
<p>On Thursday, the long-running Post Sockets Secret Cabal met, though
now this meeting is less an insurgency bent on overthrowing BSD Sockets
and more merely an afterparty for the TAPS meeting where we distribute
issues to work on before the next interim.</p>
<p></p><div id="attachment_811" style="width: 650px" class="wp-caption aligncenter"><img class="size-large wp-image-811" src="src/DrePKOLUwAAIvFo-1024x407.jpg" alt="" width="640" height="254"><p class="wp-caption-text">The Post Sockets Not So Secret Cabal (image: <a href="https://twitter.com/csperkins">@csperkins</a>)</p></div><p></p>
<p>Thursday also saw our LoLa round table. The meeting went well and it
was decided that the coordination for the various activities – which are
likely to span more than one SDO – should happen in the Internet Group
in GSMA. The activity is in progress, and last week I presented the plan
at the GSMA IG plenary.</p>
<p>After that we had a de-brief with the spin-bit folks, including Brian
joining remotely via Thomas’ laptop :-), to plan the next steps in
measurement experimentation on QUIC. This was a fitting end to the
technical part of the meeting in Bangkok, as well as the MAMI project’s
official engagement in the IETF. For us, the IETF crowd of the
project, it definitely has been an incredible pleasure working in MAMI
and progress these important topics in standardization. MAMI has been a
fantastic project, which tackled a core technical and societal tussle
with an abundance of courage (and/or recklessness, you choose), with a
truly amazing group of people! Thanks everybody!</p>
</div><!-- .entry-content -->
</div><!-- #post-## -->
<div id="post-758" class="post-758 post type-post status-publish format-standard hentry category-uncategorized">
<h2 class="entry-title"><a href="index.php/2018/10/22/the-mami-management-and-measurement-summit/index.html" rel="bookmark">The MAMI Management and Measurement Summit</a></h2>
<div class="entry-meta">
<span class="meta-prep meta-prep-author">Posted on</span> <a href="index.php/2018/10/22/the-mami-management-and-measurement-summit/index.html" title="3:44 pm" rel="bookmark"><span class="entry-date">October 22, 2018</span></a> <span class="meta-sep">by</span> <span class="author vcard"><a class="url fn n" href=" https://trammell.ch/" title="View webpage of Brian Trammell">Brian Trammell</a></span> </div><!-- .entry-meta -->
<div class="entry-content">
<p>Just before <a href="index.php/2018/04/20/ietf101-in-london-march-17-23/index.html">IETF 101</a> in London in March, the MAMI project hosted an invitation-only <a href="index.php/events/mami-management-and-measurement-summit-m3s/index.html">MAMI Management and Measurement Summit (M3S)</a>,
bringing together researchers, engineers, and vendors for a focused
discussion on how to meet the challenges posed to network measurement
and network management by the increasing deployment of strong encryption
and the extension of encryption down the stack. Today, we release <a href="https://github.com/mami-project/roadshows/blob/master/m3s-london/m3s-white-paper.pdf">“Challenges in Network Management of Encrypted Traffic”</a>, a white paper covering the discussions and distilling the recommendations that came out of the meeting.</p>
<p>This discussion has played out in multiple forums, including the
IETF, for some time, underpinning discussions and debates from the
(failed) proposal to include static keys in TLS, to continue to provide
for “business as usual” monitoring, to the <a href="https://blog.apnic.net/2018/05/11/explicit-passive-measurability-and-the-quic-spin-bit/">spin bit</a>
proposal in QUIC, which replaces implicit passive measurability of RTT
with an explicit signal. Recognizing that neither business as usual, nor
forging forward with the deployment of strong crypto down the stack and
invalidating most of the current practice of network management, are
tenable positions, the attendees converged on a set of recommendations
for future protocol design and network architecture to partially meet
these challenges:</p>
<ol>
<li>Protocols and networks must provide for <em><strong>independent measurability</strong></em>
of important metrics when these measurements may be contested: one
outcome of increasing encryption is that existing independent passive
measurement techniques will become less effective.</li>
<li>Future secure protocols should support <em><strong>different security associations at different layers</strong></em>:
approaches that integrate transport and application-layer security
(such as QUIC) make limited or no provision for network management that
need to interact with the transport protocol while not breaking
application layer security, in contrast to the TLS-over-TCP status quo.</li>
<li>Transparent middleboxes should be replaced with <em><strong>middlebox transparency</strong></em>:
the dominant architectural pattern for in-network functions today is
that of the “transparent middlebox”, which attempts to the extent
possible to be undetectable to the endpoint(s). While this has benefits
for initial deployment, it makes it impossible to build cooperative
protocols, where the middlebox and its functions are visible to the
endpoints, and the endpoints have some control over how their traffic is
treated by the network (in the last instance by detecting a middlebox
with which they do not wish to cooperate, and cease using the path).</li>
</ol>
</div><!-- .entry-content -->
</div><!-- #post-## -->
<div id="post-734" class="post-734 post type-post status-publish format-standard hentry category-uncategorized">
<h2 class="entry-title"><a href="index.php/2018/09/07/ietf-102-montreal/index.html" rel="bookmark">IETF 102 Montreal</a></h2>
<div class="entry-meta">
<span class="meta-prep meta-prep-author">Posted on</span> <a href="index.php/2018/09/07/ietf-102-montreal/index.html" title="11:06 am" rel="bookmark"><span class="entry-date">September 7, 2018</span></a> <span class="meta-sep">by</span> <span class="author vcard">Thomas Fossati</span> </div><!-- .entry-meta -->
<div class="entry-content">
<p>The IETF week started on Saturday with the hackthon. Diego, Pedro
and I (Thomas) have been working on a variety of topics: a “STAR
Requests” slide deck for the upcoming SecDispatch meeting, an
architecture design for an end-to-end ACME STAR demo, and the one-bit
experiment harness- reproducing and analysing a <a href="https://github.com/esnet/iperf/issues/768">bug</a> in iperf3 which prevents our trafic to produce reliable / precise emulation of a throughput-seeking flow.<span class="Apple-converted-space"> </span>This was pretty quickly done and we got eventually <em>absorbed</em> by the <a href="https://datatracker.ietf.org/wg/suit/about/">SUIT</a> / <a href="https://datatracker.ietf.org/wg/teep/about/">TEEP</a> table.<span class="Apple-converted-space"> </span>The back-story for this is I had brought from Cambridge to Montreal 40 boards with me, done <a href="https://pbs.twimg.com/media/DiEj6fqX0AIsYeA.jpg">especially</a>
for the hackathon by ARM – Cambridge is a very small city where
everyone seems to know everyone else. Though we didn’t get to do much
with the boards and the TEEP protocol, we got to know a bit better the
technology, talk to people involved and, in my case, share my experience
with fellow Nokians IoT folks.<span class="Apple-converted-space"> </span>The
QUIC spin-bit table, with Marcus, Al, Roni and Emile was also active on
experimenting with 1-bit spin signal and a bunch of heuristics to
reject bad RTT samples in presence of reordering. See Marcus
presentations [<a href="https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/SPIN-hackathon-presentation.pptx">1</a>] and [<a href="https://datatracker.ietf.org/meeting/102/materials/slides-102-quic-1-bit-spinning-measurement-results-00">2</a>].) This was, as usual, very useful, ludic, extemporary and genuinely fun!</p>
<p>On Monday, at the SecDispatch session Diego spoke about “<a href="https://datatracker.ietf.org/meeting/102/materials/slides-102-secdispatch-generating-certificate-requests-for-star-certificates-draft-sheffer-acme-star-request-02-00">Generating Certificate Requests for STAR Certificates</a>“.<span class="Apple-converted-space"> </span>This complements <a href="https://tools.ietf.org/html/draft-ietf-acme-star-03">ACME STAR</a> and
is a building block needed for closing the loop in the identity-owner
controlled name delegation workflow using X.509 certs we designed in
MAMI. We need to find a sensible home for this document so that it
can receive a thorough security analysis. The outcome of the discussion
was quite surprising but, IMO, pretty good – even though there is a
fair amount of running code that I’m going to trash as a result.<span class="Apple-converted-space"> </span>Martin
and Ted noted that STAR request could be re-written in terms of pure
ACME, provided the proof of the identifier ownership is not requested by
the IdO.<span class="Apple-converted-space"> </span>So, the
subsequent step was to go back to ACME and discuss adoption of a STAR
Request there, which is what we’ve done on Tuesday (see below).
Earlier that day, at the TLS session, we discussed DTLS connection
ID for 1.2 and 1.3, handling an interesting fallout from the recent
major header refactoring in DTLS 1.3 on to the content type allocation