[mosh-devel] mosh 1.2.2 released

[Keith Winstein]

Hi Dave,

We have been testing it at MIT for a few weeks with no reported difficulty 
getting packets through. (I didn't put this in the 1.2.2 release though 
because we haven't really tested it enough, and I'm skitting about sending 
ECT when we just ignore ECN -- it seems like cheating.)

I have found:

(a) OS X refuses to let users set the DiffServ codepoint & ECT and returns 
an error. I think OS X may only permit the original IP TOS types. I 
haven't tested whether the DiffServ codepoint or ECT works separately. It 
works fine on Linux and I assume FreeBSD (haven't heard any reports to the 
contrary).

(b) MIT's routers seem to strip the DiffServ codepoint after one hop.

===

Separate question: If we're setting ECT, what do you recommend we _do_ 
when we get ECN? My best idea is that we just alter the timestamp_reply we 
send back, which would be a clean way of getting the other side to 
gradually slow down its transmissions (because it would affect the SRTT, 
which governs our "frame rate").

But I'm a little concerned about the security implications here -- I don't 
want a bad guy to be able to sniff one packet from us and then replay it a 
million times with ECN set to cause a DoS. So my thinking is we would only 
respond to ECN if it's a _new_ packet (with sequence number greater than 
any seen before). We use the same filter to decide whether to update our 
timing statistics so it seems somewhat natural.

Have you seen anybody discuss the appropriate use of ECN in a 
security-sensitive transport protocol? TCP does not seem worried about 
this DoS.

===

Third question for you: I had to take out the "out-of-order delivery" 
warning because we found that MIT's 802.11n network aggressively reordered 
packets, apparently because of the "block acks" feature in the protocol. 
In a full-throttle TCP download, something like 30-50% of all packets will 
be "out of order"! This seems like it will hurt TCP performance (since TCP 
will send an ACK immediately on any out-of-order packet). I have also 
heard a few reports from people outside MIT.

RFC 3366 ("Advice to link designers on link Automatic Repeat reQuest") 
basically says that if a link layer is going to reorder packets, it should 
not cause a huge number of out-of-order deliveries to IP (and should put 
packets back in order itself if necessary and possible without a large 
delay).

Have you heard anything about this and whether it's common in major 
802.11n deployments or was discussed by the IETF community? It seems like 
it may be really hurting TCP performance.

Cheers,
Keith

On Wed, 13 Jun 2012, Dave Taht wrote:

> I am curious if you were able to measure/see
> any differences in network latency (particularly over wifi) by the
> switch to AF42 + ECN, or
> had any difficulties getting packets through?
>
> I saw all sorts of interesting behavior on a recent test across the
> country as to stripping bits (some ended up with ECN set, but nothing
> else, others ended up with CS1 set, some preserved all the bits), but
> lacking a means to compare A/B
>
> all I can say is that it feels better on saturated best effort wifi networks.
>
>
> On Wed, Jun 13, 2012 at 12:31 PM, Keith Winstein <keithw at mit.edu> wrote:
>> Hello Mosh users and developers,
>>
>> mosh 1.2.2 has been released.
>>
>> The source code is at:
>> https://github.com/downloads/keithw/mosh/mosh-1.2.2.tar.gz
>>
>> This is a minor maintenance release that:
>>
>> * Removes the warning on out-of-order packets (this was firing too
>> often on some Wi-Fi networks)
>>
>> * Adds an experimental "--predict=experimental" mode to predict
>> immediately, even if recent predictions were incorrect
>>
>> ===
>>
>> mosh 1.2.2 is backwards-compatible with mosh clients back to 0.96 and
>> mosh servers back to 1.0.9. Please let us know of any problems
>> (https://github.com/keithw/mosh/issues).
>>
>> Best regards from the Mosh team,
>> Keith
>> _______________________________________________
>> mosh-devel mailing list
>> mosh-devel at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
>
> -- 
> Dave Täht
> SKYPE: davetaht
> http://ronsravings.blogspot.com/
>