4 ms·

Questions: (Disclaimer, I know only the surface of networking) "For example, PZP is able to identify the device, rather than its IP address, as the endpoint fo

Questions: (Disclaimer, I know only the surface of networking) "For example, PZP is able to identify the device, rather than its IP address, as the endpoint for data packets, allowing it to accommodate the intermittent nature of mobile connections in a fault-tolerant manner": In what way is this different from NAT? Is this somehow aware of the phone switching towers (topology changes)? Or is there another advantage? How do they get that information? "The PacketZoom protocol recovers from dropped packets “gracefully,” with minimal overhead above the amount of data lost in the dropped packets." I don't know signal processing well enough to know how this works, I'm guessing you don't need to do things in order like TCP, so you can ask to resend and then stich it in? Where is the beef? Is it in following devices rather than IPs? What does the interface look like?

signa11 10y ago
> ... I'm guessing you don't need to do things in order like TCP ... kind of tangentially relevant: the problem with tcp is that it conflates congestion loss with error loss. this causes backoff, ergo poor performance under conditions such as lossy links, handovers etc. etc. udp doesn't really suffer from any of this because, well you do everything yourself. another advantage with udp, imho, is that server side can be scaled quite easily :) e.g. you can have multiple processes terminating a udp control protocol, and demuxing connections onto session tasks which can be spread around. i am kind of _surprised_ that ip addresses for devices end up changing. this might _only_ be true if you are handing over from/to different radio access networks wifi -> lte -> wifi etc. etc. roaming within a network would (must ?) not end up changing your addresses at all. for example, in an LTE network, PGW being an ip anchor, assigns addresses to the devices, and there is only one such 'thing' per epc core (slightly convoluted when moving from one operator to another, but the basic idea is still there) from the article linked by GP, it seems that each device needs to register with a cloud based server, via which the device traffic is routed. this initial registration can be used to exchange things like IMEI or somesuch for device identification, which then remains the same as the device moves around.
- chetanahuja 10y ago
  "this initial registration can be used to exchange things like IMEI or somesuch for device identificatio" PacketZoom stack does create our own randomly generated identifier per app install (so two different apps on the same device will have different ids). Nothing at all that would positively identify a device or a user (IMIE, UDID etc.). That's a strict no-no by app/play store policies.
  - signa11 10y ago
    > Nothing at all that would positively identify a device or a user (IMIE, UDID etc.) ... if we ignore (for a moment) that play-store/app-store policies forbid imei use by applications, i am just curious why you think IMEI cannot be used for _device_ identification ? thanks !
    - chetanahuja 10y ago
      "forbid imei use by applications, i am just curious why you think IMEI cannot be used for _device_ identification" I may have phrased it unclearly. I was trying to say that things like UDID or IMEI that can be used to identify individual users and/or devices are strictly verboten by app store policies (and PacketZoom doesn't read or use any of those identifiers)
      - signa11 10y ago
        > I may have phrased it unclearly. cool ! thanks for clarifying the whole thing.
- jabl 10y ago
  > the problem with tcp is that it conflates congestion loss with error loss. this causes backoff, ergo poor performance under conditions such as lossy links, handovers etc. etc. Indeed. But, while there are many other congestion handling protocols that are frequently used on smaller networks [1], is there anything better than TCP style that is thought to work on "Internet scale"? [1] E.g. Infiniband has some kind of credit/token based flow control, producing a lossless fabric. There's even stuff like that for Ethernet, e.g. https://en.wikipedia.org/wiki/Audio_Video_Bridging https://en.wikipedia.org/wiki/Audio_Video_Bridging has 802.1Qav, https://en.wikipedia.org/wiki/Credit-based_fair_queuing https://en.wikipedia.org/wiki/Credit-based_fair_queuing
chetanahuja 10y ago
"In what way is this different from NAT?" I'm not sure how NAT solves this problem at all unless I'm missing something. If you lose a TCP connection from a nat'd device, there's no way to create the same connection ("same" in terms of {IP1, port1, IP2, port1} tuple) again. "I'm guessing you don't need to do things in order like TCP, so you can ask to resend and then stitch it in" Yes that helps. It also helps if the protocol is smart enough to distinguish between congestion based loss vs media error based loss (with a high degree of accuracy). "Where is the beef?" Check out my comment upthread (or downthread... where it's placed on the page now) https://news.ycombinator.com/item?id=12021454 https://news.ycombinator.com/item?id=12021454
fulafel 10y ago
See HIP (host identity protocol) for the IP equivalent.

signa11 10y ago

> ... I'm guessing you don't need to do things in order like TCP ... kind of tangentially relevant: the problem with tcp is that it conflates congestion loss with error loss. this causes backoff, ergo poor performance under conditions such as lossy links, handovers etc. etc. udp doesn't really suffer from any of this because, well you do everything yourself. another advantage with udp, imho, is that server side can be scaled quite easily :) e.g. you can have multiple processes terminating a udp control protocol, and demuxing connections onto session tasks which can be spread around. i am kind of _surprised_ that ip addresses for devices end up changing. this might _only_ be true if you are handing over from/to different radio access networks wifi -> lte -> wifi etc. etc. roaming within a network would (must ?) not end up changing your addresses at all. for example, in an LTE network, PGW being an ip anchor, assigns addresses to the devices, and there is only one such 'thing' per epc core (slightly convoluted when moving from one operator to another, but the basic idea is still there) from the article linked by GP, it seems that each device needs to register with a cloud based server, via which the device traffic is routed. this initial registration can be used to exchange things like IMEI or somesuch for device identification, which then remains the same as the device moves around.

chetanahuja 10y ago
"this initial registration can be used to exchange things like IMEI or somesuch for device identificatio" PacketZoom stack does create our own randomly generated identifier per app install (so two different apps on the same device will have different ids). Nothing at all that would positively identify a device or a user (IMIE, UDID etc.). That's a strict no-no by app/play store policies.
- signa11 10y ago
  > Nothing at all that would positively identify a device or a user (IMIE, UDID etc.) ... if we ignore (for a moment) that play-store/app-store policies forbid imei use by applications, i am just curious why you think IMEI cannot be used for _device_ identification ? thanks !
  - chetanahuja 10y ago
    "forbid imei use by applications, i am just curious why you think IMEI cannot be used for _device_ identification" I may have phrased it unclearly. I was trying to say that things like UDID or IMEI that can be used to identify individual users and/or devices are strictly verboten by app store policies (and PacketZoom doesn't read or use any of those identifiers)
    - signa11 10y ago
      > I may have phrased it unclearly. cool ! thanks for clarifying the whole thing.
jabl 10y ago
> the problem with tcp is that it conflates congestion loss with error loss. this causes backoff, ergo poor performance under conditions such as lossy links, handovers etc. etc. Indeed. But, while there are many other congestion handling protocols that are frequently used on smaller networks [1], is there anything better than TCP style that is thought to work on "Internet scale"? [1] E.g. Infiniband has some kind of credit/token based flow control, producing a lossless fabric. There's even stuff like that for Ethernet, e.g. https://en.wikipedia.org/wiki/Audio_Video_Bridging https://en.wikipedia.org/wiki/Audio_Video_Bridging has 802.1Qav, https://en.wikipedia.org/wiki/Credit-based_fair_queuing https://en.wikipedia.org/wiki/Credit-based_fair_queuing

chetanahuja 10y ago

"In what way is this different from NAT?" I'm not sure how NAT solves this problem at all unless I'm missing something. If you lose a TCP connection from a nat'd device, there's no way to create the same connection ("same" in terms of {IP1, port1, IP2, port1} tuple) again. "I'm guessing you don't need to do things in order like TCP, so you can ask to resend and then stitch it in" Yes that helps. It also helps if the protocol is smart enough to distinguish between congestion based loss vs media error based loss (with a high degree of accuracy). "Where is the beef?" Check out my comment upthread (or downthread... where it's placed on the page now) https://news.ycombinator.com/item?id=12021454 https://news.ycombinator.com/item?id=12021454

fulafel 10y ago

See HIP (host identity protocol) for the IP equivalent.