Subject: [edu-team] So....we can do a wireless tutorial, with Donald Eastlake presenting

From: Radia Perlman <[email-masked]>
Date: Sat, 5 Oct 2013 10:07:25 -0700

He gave a wireless tutorial somewhere that I watched, perhaps 10 years ago,
and it was excellent.  He said that some people from 802.11 and
Bluetooth/Zigbee have been helping him update it, so he is all set for 2013
Vancouver, and can do either slot (1 or 3 PM).  I think we should go ahead
and schedule it.

Radia

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Oct 2013 08:07:17 +1300

I hate to be ornery, but which current IETF topics will benefit
(in the sense that WGs will be able to do a better job)?

Regards
   Brian

On 06/10/2013 06:07, Radia Perlman wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> edu-team mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/edu-team

---

From: Radia Perlman <[email-masked]>
Date: Sat, 5 Oct 2013 12:55:05 -0700

Wireless links have somewhat different properties than wired links, and
there are fascinating implications.  For instance, TCP is impacted.  It's
important to understand the properties of the underlying technology.

I was thinking of suggesting a title like
"Wireless links; Properties, Challenges, Solutions, and Implications"

---

From: Mirjam Kuehne <[email-masked]>
Date: Tue, 08 Oct 2013 17:42:29 +0200

Hi all,

Is there any more feedback on this? Can we go ahead and schedule it for 
Vancouver?

Radia, it would be good if Donald Eastlake could share the material with 
the Edu Team. That might also help to answer Brian's question?

Mirjam

On 5/10/13 9:55 PM, Radia Perlman wrote:
> there are fascinating implications.  For instance, TCP is impacted.
>   It's important to understand the properties of the underlying technology.
>
> On Sat, Oct 5, 2013 at 12:07 PM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>      > [email-masked] <mailto:[email-masked]>

---

From: Alice Russo <[email-masked]>
Date: Tue, 8 Oct 2013 12:59:27 -0400

I'm in favor of using the open slot for Donald Eastlake's wireless tutorial because it sounds as though the content has been honed over time and perhaps he's willing update it with the IETF audience in mind. Once there's a summary available, if there are specific WGs that might be interested, it could be announced on those WG mailing lists.

Thanks,
Alice

On Oct 8, 2013, at 11:42 AM, Mirjam Kuehne wrote:

> Hi all,
> 
> Is there any more feedback on this? Can we go ahead and schedule it for Vancouver?
> 
> Radia, it would be good if Donald Eastlake could share the material with the Edu Team. That might also help to answer Brian's question?
> 
> Mirjam
> 
>

---

From: Radia Perlman <[email-masked]>
Date: Tue, 8 Oct 2013 10:08:18 -0700

Thanks Alice.  Our messages crossed in the (e)mail.  I went ahead and told
Stephanie to pencil it in (edu was CC'd).  It's kind of daunting to give
Donald such little lead time. I'll try to help him as much help as possible
with preparation and, if necessary, I might even do some copresenting.

Radia

On Tue, Oct 8, 2013 at 9:59 AM, Alice Russo <[email-masked]> wrote:

> I'm in favor of using the open slot for Donald Eastlake's wireless
> tutorial because it sounds as though the content has been honed over time
> and perhaps he's willing update it with the IETF audience in mind. Once
> there's a summary available, if there are specific WGs that might be
> interested, it could be announced on those WG mailing lists.
>
> Thanks,
> Alice
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Oct 2013 13:45:41 +1300

Radia,

I think you ducked my question. I have taught some of this stuff in
the past, and I recently heard a fascinating talk by Muriel Médard
about how Coded TCP can deal with lossy wireless links. It's very
interesting. But my question for any EDU-sponsored tutorial, whether
on a technical or a procedural topic, is: how will this make the
IETF work better?

(In this case there's a corollary: did the outcome from the PILC
WG a few years ago produce any benefits for IETF protocols?)

To be clear, given the short notice in this case, it seems like
a good way to fill the gap. But I think EDU needs more of a strategic
plan with tight focus on making the IETF work better. That affects
the topics we pick and the direction we give to the speakers.

Positive thought: maybe we need a standard writeup that we send to
all potential speakers. Having said that, I suppose I'd better
draft it...

    Brian

---

From: Radia Perlman <[email-masked]>
Date: Tue, 8 Oct 2013 19:15:06 -0700

Personally, I think helping people catch up on various technology will
definitely "help IETF work better".  Even making people who supposedly know
an area rethink the technology in order to summarize the concepts, the
controversies, etc., will also "help IETF work better". Having people
outside an area be able to understand other areas, both in order to lend
their expertise, and in order to understand the implications of other
technology, will also "help IETF work better".

Even the most technically expert IETF person tends to only know about a
subset of the technical work in IETF. Sure, they could read the mailing
list archives and all the internet drafts for other areas...in theory...but
having them attend a 2 hour tutorial instead, will "help the IETF work
better".

So I am totally befuddled by what you think the phrase "help IETF work
better" means.

If you mean only procedural tutorials (e.g., how to use the tools, what the
rules of IETF are, etc.), I think those are useful too.  But certainly,
facilitating understanding technology, fostering cross-fertilization,
enabling newcomers to have something that they can sit in on, on day one,
and understand, definitely also "helps IETF work better".

Radia

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Oct 2013 08:45:03 +1300

Radia,

I am concerned that we've had a tendency to run tutorials whose
teachers haven't really considered the guidelines that I just
drafted. That's really all - and since we'd never written down
the guidelines, it isn't even surprising. So if Donald explains
what transport protocol designers, application protocol designers,
compression algorithm designers, etc. need to understand about
wireless, that would be great. How does the use of ARQ in 3GPP
and WiFi affect whether or not we need a UDP checksum? Etc.

Donald's very likely to do this without being told, but I'm not
sure that applies to all speakers.

Regards
   Brian

---

From: Radia Perlman <[email-masked]>
Date: Wed, 9 Oct 2013 13:30:35 -0700

Brian...How *does* the use of ARQ in 3GPP and WiFi affect whether or not we
need a UDP checksum?

...since you mentioned it...I don't know what you'd consider a good answer
to that...

do you mean why do we have checksums at multiple layers?

Radia

On Wed, Oct 9, 2013 at 12:45 PM, Brian E Carpenter <
[email-masked]> wrote:

>  It's
> >>>>> He gave a wireless tutorial somewhere that I watched, perhaps 10
> years
> >>>> ago,
> >>>>> Bluetooth/Zigbee have been helping him update it, so he is all set
> for
> >>>> 2013

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Oct 2013 11:37:31 +1300

> do you mean why do we have checksums at multiple layers?

As I understand it, both WiFi and 3GPP go to considerable lengths
to retransmit packets that arrive with errors, and in fact that
leads to great variability in packet latency on links with high error
rates - not something we see these days on wired links. So all the
folk knowledge that led to dropping the header checksum in IPv6 but
mandating the UDP checksum is obsolete. If the least reliable link
layer is doing ARQ, why bother with layer 3 and 4 checksums?

But on the other hand, the Coded TCP work shows that in some
circumstances, e2e performance is significantly better if you disable
ARQ in wireless layer 2 and do the error detection only in layer 4.

Also there might be applications that would prefer lower latency and
some errored packets to variable latency and error-corrected packets.

It was only an example where one part of our technology affects
another, which is where I think EDU should focus.

    Brian